दोन मजकूर तुलना करा _

Diff algorithms कसे कार्य करतात

या पानावरील प्रत्येक diff view Myers algorithm द्वारे तयार होतो — Eugene W. Myers यांनी 1986 मध्ये विकसित केलेले तंत्र जे O((N+M)D) वेळेत दोन token sequences मधील सर्वात छोटा edit script शोधते, जेथे D म्हणजे edit distance. Algorithm Longest Common Subsequence समस्येवर आधारित आहे आणि open-source jsdiff library वापरून पूर्णपणे तुमच्या ब्राउझरमध्ये चालते.

1. Inputs Tokenise करा — तुलना करण्यापूर्वी, algorithm प्रत्येक इनपुट tokens च्या अनुक्रमात विभाजित करतो. Line granularity newlines वर विभाजित करते; word granularity whitespace आणि punctuation सीमांवर; character granularity प्रत्येक Unicode code point ला स्वतःचा token मानते.
2. Edit Graph तयार करा — Myers algorithm तुलना 2D grid मधून path म्हणून मॉडेल करतो जेथे उजवे जाणे म्हणजे "मूळातून काढा", खाली जाणे म्हणजे "बदललेल्यातून घाला" आणि कर्णावर जाणे म्हणजे "दोन्हीत token जुळतो". Algorithm सर्वात छोटा diagonal-heavy path शोधतो.
3. LCS काढा — सर्वात छोट्या path मधील diagonal moves Longest Common Subsequence trace करतात — दोन्ही inputs मध्ये एकाच सापेक्ष क्रमाने दिसणारे tokens. LCS मधील प्रत्येक token "अपरिवर्तित" आहे; बाकी सर्व एकतर addition किंवा deletion आहे.
4. Preprocessing पर्याय लागू करा — "केस दुर्लक्षित करा" सक्षम केल्यास, LCS pass आधी दोन्ही inputs lowercase केले जातात जेणेकरून "HELLO" आणि "hello" एकसारखे मोजले जातात. "Whitespace दुर्लक्षित करा" अनेक spaces एकत्र करते. "प्रत्येक ओळ Trim करा" तुलनापूर्वी प्रति ओळ leading आणि trailing whitespace काढते.
5. निवडलेला View Render करा — आउटपुट तोच LCS result तीन प्रकारे दाखवतो: Side-by-side डावीकडे मूळ आणि उजवीकडे बदललेले दोन-column grid मध्ये लाल आणि हिरव्या row highlights सह दाखवते. Unified एकच column − आणि + prefix ओळींसह दाखवते, जसे git diff चे आउटपुट. Inline एकाच text flow मध्ये deletions लाल strikethrough आणि additions हिरव्या underline म्हणून दाखवते.
6. Summary Strip मोजा — Render केल्यानंतर, साधन किती tokens जोडले, काढले आणि अपरिवर्तित राहिले ते मोजते, नंतर दोन्ही input lengths मधील मोठ्याच्या तुलनेत अपरिवर्तित tokens चे प्रमाण म्हणून similarity मोजते. 100% similarity म्हणजे preprocessing नंतर दोन्ही inputs एकसारखे आहेत.

Diff checker का वापरावा

• Git client शिवाय Code Review — Config file, SQL migration किंवा shell script च्या दोन आवृत्त्या paste करा आणि repo clone न करता, branches न बदलता किंवा CI pipeline ची वाट न पाहता काय बदलले ते पाहा. हे साधन pair programming दरम्यान त्वरित reviews साठी, contractor handoffs साठी जेथे दुसऱ्या बाजूने Git history शेअर केली नाही, आणि पूर्णपणे pre-version control legacy codebases साठी उपयुक्त आहे.
• Contract आणि Document Redlines — Word-level diff contract drafts मधील कोणते terms बदलले ते Word च्या Track Changes panel पेक्षा जलद दाखवतो. पहिल्या draft मधील clause A आणि executed copy मधील clause B paste करा आणि substitution नक्की कोणत्या phrase वर आहे ते लाल-हिरव्यात उजळते. Paralegals आणि procurement teams हे contract sign करण्यापूर्वी last-minute redlines review नंतर सुटल्या नाहीत हे verify करण्यासाठी वापरतात.
• Essay आणि Draft Revisions — लेखक पहिला draft edited आवृत्तीशी तुलना करताना word granularity वर जाऊन दोन्ही copies पुन्हा न वाचता प्रत्येक substitution, insertion आणि cut पाहू शकतात. हाच workflow translators साठी source text विरुद्ध बदल audit करण्यासाठी, editors साठी copy edit ने लेखकाचा आवाज जतन केला हे तपासण्यासाठी उपयुक्त आहे.
• Log आणि Config तुलना — दोन server config snapshots, दोन cron schedules किंवा दोन ps aux outputs तुलना करणारे sysadmins line granularity वापरून 200-ओळींच्या file मध्ये एकट्या बदललेल्या parameter ला सेकंदांत शोधू शकतात. Ignore-whitespace पर्यायासह हे जोडा आणि noisy alignment-only diff फक्त खऱ्या parameter बदलांपर्यंत कमी होतो.

सामान्य उपयोग

Text diff लेखन, development आणि operations कामात प्रत्येक edit cycle च्या शेवटी दिसते.

• Pull request review: approve करण्यापूर्वी दोन function implementations बाजूबाजूने paste करा logic बदल समजण्यासाठी, branch checkout च्या overhead शिवाय.
• Internationalisation QA: translator ने आणलेल्या insertions, omissions किंवा terminology swaps शोधण्यासाठी English source string ची word level वर translated equivalent शी तुलना करा.
• Incident analysis: outage च्या आधी झालेला configuration बदल वेगळा करण्यासाठी दोन Kubernetes manifest snapshots किंवा दोन "docker inspect" outputs line level वर diff करा.

एक व्यावहारिक उदाहरण

पाच-ओळींचा server config घ्या. मूळ: host=localhost, port=5432, dbname=app_db, user=app, password=secret. बदललेले: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Line granularity आणि Side-by-side view सह, ओळ 1 डावीकडे लाल (host=localhost) आणि उजवीकडे हिरवी (host=db.prod.example.com) दाखवते, ओळ 4 लाल (user=app) आणि हिरवी (user=app_prod) दाखवते, आणि ओळी 2, 3 आणि 5 दोन्ही बाजूंनी अपरिवर्तित राहतात. Summary strip 2 additions, 2 deletions, 3 unchanged आणि 60% similarity नोंदवते.

हे माझ्या ब्राउझरमध्ये चालते का?

होय. संपूर्ण diff computation open-source jsdiff library वापरून client-side चालते. तुम्ही टाइप, पेस्ट किंवा तुलना केलेले काहीही कोणत्याही सर्व्हरला पाठवले जात नाही. तुम्ही स्वतः verify करू शकता: browser DevTools उघडा, Network tab वर जा, log clear करा, Compare वर click करा आणि तुलना टप्प्यासाठी शून्य network requests उडतात हे confirm करा.

Similarity percentage चा अर्थ काय?

Similarity अपरिवर्तित tokens / max(मूळातील एकूण tokens, बदललेल्यातील एकूण tokens) म्हणून मोजली जाते. 100% score म्हणजे preprocessing पर्याय (case folding, whitespace collapsing, line trimming) लागू केल्यानंतर दोन्ही inputs एकसारखे आहेत. 0% score म्हणजे inputs मध्ये कोणताही token सामायिक नाही. हे metric edit distance चे अंदाजे मोजमाप आहे — त्वरित मापक म्हणून उपयुक्त — plagiarism किंवा originality score नाही.

मी JSON / YAML / XML semantically diff करू शकतो का?

या साधनात नाही. हे text-level diff आहे, त्यामुळे JSON किंवा XML चे केवळ-whitespace reformatting अजूनही अनेक बदल दाखवते जरी data logically एकसारखे असले तरी. JSON मध्ये object keys reordering देखील बदल म्हणून दाखवते जरी बहुतेक parsers key order अनिश्चित मानतात. खरे semantic diff साठी जे parsed object trees तुलना करते आणि key order आणि formatting दुर्लक्षित करते, आम्ही एक dedicated JSON Diff tool planned करत आहोत. सध्या, येथे paste करण्यापूर्वी दोन्ही inputs एकाच indentation आणि key order ला normalise करा.

Unified vs side-by-side views मध्ये फरक काय?

Side-by-side दोन columns render करते: डावीकडे मूळ आणि उजवीकडे बदललेली आवृत्ती, डावीकडे काढलेल्या ओळी लाल highlighted आणि उजवीकडे जोडलेल्या ओळी हिरव्या highlighted. अपरिवर्तित ओळी दोन्ही columns मध्ये एकाच row वर aligned दिसतात. Unified एकच column render करतो − prefix आणि लाल background काढलेल्या ओळींसाठी आणि + prefix आणि हिरवा background जोडलेल्या ओळींसाठी — git diff terminal वर जसे print करते तसेच layout. Unified वापरा जेव्हा तुम्हाला result patch file म्हणून copy करायचा असेल किंवा code review thread मध्ये paste करायचा असेल. Side-by-side वापरा जेव्हा काय बदलले ते visual alignment raw patch text पेक्षा जास्त महत्त्वाचे असते.

डावीकडे मूळ, उजवीकडे बदललेली आवृत्ती paste करा, view आणि granularity निवडा आणि तुलना मिलिसेकंदांत येते. Live mode चालू करा आणि तुम्ही दोन्ही बाजू संपादित करताना प्रत्येक keystroke वर diff पुन्हा चालतो. Result standard unified .patch file म्हणून download करा जे git apply थेट वापरते. Upload नाही, account नाही, vendor API key नाही, quota नाही.