टेक्स्ट अंतर जाँचकर्ता

टेक्स्ट तुलना के बारे में

यह diff टूल दो टेक्स्ट की पंक्ति-दर-पंक्ति तुलना के लिए Longest Common Subsequence (LCS) एल्गोरिथम का उपयोग करता है। जोड़ हरे रंग में, हटाव लाल रंग में हाइलाइट होते हैं।

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

• कमिट करने से पहले कोड परिवर्तनों की तुलना करें
• संशोधित दस्तावेज़ों या अनुबंधों की समीक्षा करें
• अनुवाद के अंतर की जाँच करें
• कॉन्फ़िगरेशन फ़ाइल परिवर्तनों को सत्यापित करें
• API प्रतिक्रियाओं की तुलना करें

अक्सर पूछे जाने वाले प्रश्न

क्या यह वर्ण-दर-वर्ण तुलना करता है?

यह टूल पंक्ति-दर-पंक्ति तुलना करता है। यदि एक पंक्ति में कोई भी परिवर्तन है (यहाँ तक कि एक भी वर्ण), तो पूरी पंक्ति को संशोधित के रूप में चिह्नित किया जाता है। यह Git और अधिकांश diff टूल्स द्वारा उपयोग किया जाने वाला दृष्टिकोण है।

क्या कोई आकार सीमा है?

कोई सख्त सीमा नहीं है, लेकिन बहुत बड़े टेक्स्ट (10,000 से अधिक पंक्तियाँ) को प्रोसेस करने में एक पल लग सकता है, क्योंकि तुलना पूरी तरह आपके ब्राउज़र में चलती है।

«diff» का वास्तव में क्या मतलब है

एक diff describe करता है कि insertions और deletions के smallest set का उपयोग करके एक text को दूसरे में कैसे बदलें। ऐसा करने के infinitely many तरीके हैं, trivial तरीका है «A के हर character को delete करें और फिर B के हर character को insert करें।» एक useful diff shortest edit script है, जो Longest Common Subsequence problem का dual है: वह longest sequence of lines find करें जो दोनों texts में (order में) appear हो, और बाकी सब एक addition या deletion है। अधिकांश diff algorithms अलग hat पहने हुए LCS algorithms हैं।

एक subtle point: longest common subsequence longest common substring नहीं है। Subsequence order preserve करता है लेकिन adjacency नहीं, इसलिए «ABCDE» और «AXBYCZD» subsequence «ABCD» share करते हैं भले ही तीन characters का कोई contiguous run दोनों में न हो।

Diff algorithms का एक संक्षिप्त इतिहास

पहला widely-used file-comparison program Unix diff था जो Bell Labs में Douglas McIlroy ने लिखा था, जिसका underlying algorithm James W. Hunt और McIlroy द्वारा June 1976 में Bell Labs Computing Science Technical Report #41 के रूप में publish किया गया था। McIlroy ने खुद four-month development को «a desperate effort.» के रूप में describe किया। Hunt-McIlroy approach ने file B की हर line को hash किया, index किया कि हर unique line कहां occur हुई, और matches की longest monotonically increasing chain ढूंढी। यह Version 6 Unix में ship हुआ और decades तक अधिकांश Unix systems पर /usr/bin/diff में essentially same algorithm रहा।

Eugene W. Myers ने 1986 में आधुनिक industry standard publish किया, «An O(ND) Difference Algorithm and Its Variations» in Algorithmica Vol. 1, No. 2। Myers ने LCS को एक edit graph के through shortest-path problem के रूप में reframe किया: A को top axis पर और B को side पर रखें, जब भी दो lines match हों एक diagonal draw करें, और top-left से bottom-right तक fewest non-diagonal edges वाला path search करें। हर non-diagonal edge एक insertion या deletion है; हर diagonal free है। Crucially, algorithm O((N+M)·D) time में run करता है जहां D edit script का size है, यानी files जितनी similar होती हैं यह उतना ही faster होता है। Typical version-control diffs के लिए D, N+M की तुलना में tiny है, इसलिए Myers practice में O(N·M) worst case से dramatically faster है। उनके paper में divide-and-conquer trick का उपयोग करके एक linear-space refinement भी है। Myers' algorithm GNU diff, git diff, Mercurial, Subversion, jsdiff, Python के difflib, और अधिकांश GUI diff viewers के default backing है।

Bram Cohen (बाद में BitTorrent के inventor के रूप में बेहतर जाने गए) ने 2002 के आसपास Bazaar version-control system के लिए patience diff design किया। Motivating problem: Myers diff किसी भी matching line को align करता है, common ones सहित, इसलिए C में एक function move करने से एक noisy diff produce हो सकता है जिसमें moved function का closing brace किसी unrelated function के closing brace से align होता है। Patience diff diff को उन lines पर anchor करता है जो हर file में exactly एक बार occur होती हैं (typically function signatures, comment headers, distinctive log messages), केवल उन anchors के LCS को patience sort का उपयोग करके compute करता है, और gaps पर recurse करता है। Result meaningful lines पर align होता है और source code के लिए बेहतर reads होता है। Git इसे git diff --patience के माध्यम से support करता है। Histogram diff git में 2010 के आसपास add किया गया एक refinement है जो line occurrences का histogram build करता है और strictly unique की बजाय low-frequency anchors prefer करता है; git 2.45 से यह कई configurations के लिए default है।

Levenshtein बनाम LCS

जानने योग्य एक related concept। Levenshtein distance (Vladimir Levenshtein, 1965) एक string को दूसरे में बदलने के लिए single-character insertions, deletions, और substitutions की minimum number count करता है। LCS-based diff closely related लेकिन slightly different है: classic diff एक change को single substitution की बजाय delete-then-insert pair के रूप में treat करता है, क्योंकि यह line-oriented files पर better map होता है। Levenshtein का जवाब है «how different are these strings?» और एक number देता है; LCS का जवाब है «what specifically changed?» और एक actual edit script देता है। Spell-checkers और «did you mean?» features पहला चाहते हैं; diff tools दूसरा चाहते हैं। Damerau-Levenshtein variant (1964) typo detection के लिए transposition operator के साथ Levenshtein को extend करता है।

Granularity: line, word, और character

Diff को different granularities पर compute किया जा सकता है, हर एक के trade-offs हैं:

• Line-level: हर line एक token है; दो lines या तो exactly match करती हैं या नहीं। Fast, map होता है cleanly पर कि programmers code कैसे edit करते हैं, concise patches produce करता है जिन्हें patch(1) apply कर सकता है। Cost: एक 200-character line में एक character reformat करने से पूरी line changed mark हो जाती है। diff, git, SVN, और इस tool के लिए default।
• Word-level: हर whitespace-delimited token एक unit है, इसलिए एक word change करने वाली एक line केवल वह word highlighted show करती है। Prose, contracts, blog drafts के लिए excellent। git diff --word-diff, Google Docs «Suggesting» mode, Microsoft Word «Track Changes,» Diffchecker के compare-words mode द्वारा use किया जाता है।
• Character-level: हर Unicode code point एक unit है। Single-character typos catch करता है, legal redlining के लिए ideal जहां एक word meaning flip कर सकता है। Large inputs पर slow और कभी-कभी long edits के लिए unreadable।

Modern diff UIs में एक common pattern है पहले line level पर diff compute करना, फिर removed/added neighbours के किसी भी pair के लिए केवल उन दो lines पर एक secondary word-level diff run करना और intra-line changes highlight करना। Exactly यही GitHub के PR view और diff-match-patch library दोनों काम करते हैं।

तीन diff display modes जो आप देखेंगे

• Unified diff (हर .patch file का format), hunks जो default रूप से ऊपर और नीचे तीन lines of context के साथ @@ -oldStart,oldLen +newStart,newLen @@ द्वारा introduce होते हैं। Wayne Davison के GNU diff -u flag के साथ 1990 के आसपास originate हुआ। Compact और machine-readable है patch(1) द्वारा, इसीलिए git, kernel-style email patches और SVN सभी इसे use करते हैं।
• Side-by-side: original left पर, modified right पर, line by line aligned। diff -y एक primitive ASCII version produce करता है; Beyond Compare, Meld, WinMerge और ऊपर का «Side by Side» view सभी इस format use करते हैं। Visual review और prose proofreading के लिए best।
• Inline (stacked): एक single column जहां deleted और added lines interleaved हैं। GitHub का PR view default रूप से यही है। Narrow screens और small edits के लिए सबसे space-efficient format।

उपयोगी git diff variants

• git diff: index vs working tree।
• git diff --staged: HEAD vs index।
• git diff main..feature: branch tips। main...feature merge base के against compare करता है, जो PR land करेगा।
• git diff --word-diff और --color-words: markup-friendly और colour-tinted word-level diff।
• git diff --no-index a.txt b.txt: किसी भी git repo के बाहर files पर काम करता है। Patience या histogram algorithms के साथ poor-man's standalone diff के रूप में handy।
• git diff -w: सभी whitespace ignore करता है (ऊपर «Ignore whitespace» checkbox से match करता है)।
• git diff --histogram: per command algorithm switch करें।

Browser diff के लिए कब reach करें

• Code review। एक file के दो versions paste करें, देखें क्या बदला, decide करें कि change sense बनाता है या नहीं।
• AI-edited code review। LLM के refactored version के against अपना original diff करें, drift या hallucinations spot करने के लिए।
• Legal contract redlining। Confirm करें कि version 3 और version 4 के बीच केवल agreed clauses बदले।
• Translation QA। Same paragraph के दो French translations compare करें, या previous और updated localisation files diff करें जब केवल handful of strings बदने चाहिए थे।
• Configuration drift। Prod के nginx.conf को staging के against compare करें।
• SQL schema comparison। दो databases से CREATE TABLE statements dump करें और missing indexes या column-type drift find करने के लिए diff करें।
• Spec drift। Breaking changes documented हैं यह verify करने के लिए OpenAPI / Swagger YAML के दो versions diff करें।
• Markdown blog drafts। Co-author ने क्या edit किया spot करें।
• Compliance audits। Regulators के लिए privacy policy को month-over-month diff करें।
• Lock-file forensics। Dependency upgrade समझने के लिए package-lock.json या yarn.lock diff करें।

वास्तविक सीमाएं

• Plain text diff में कोई semantic awareness नहीं है। एक file भर foo को bar rename करना totally unrelated rewrite के समान cost में दिखता है। difftastic जैसे tools language के AST parse करते हैं और structural diffs produce करते हैं («function added,» «argument reordered»)। यह page नहीं करता, यह एक plain LCS line diff है।
• Whitespace और line-endings spurious diffs cause करते हैं। CRLF vs LF, trailing whitespace, tabs vs spaces। ऊपर का «Ignore whitespace» toggle git के -w से match करता है।
• Binary files fit नहीं होती। Diff एक text concept है। Binary diff के लिए bsdiff, xdelta, या VBinDiff जैसे tools हैं।
• Order sensitivity। Line diff assume करता है कि documents line by line edit किए गए थे। Unsorted CSVs या JSON object key reorderings के लिए, पहले sort या canonicalise करना चाहिए।
• Move detection। Classic LCS diff recognize नहीं करता कि एक function file के अंदर move किया गया था, यह move को एक delete plus एक insert के रूप में show करता है। Beyond Compare, Meld और difftastic move detection attempt करते हैं; यह page नहीं करता।

अधिक प्रश्न

यह page changed lines के अंदर character-level highlights क्यों नहीं show करता?

क्योंकि line-level pass अधिकांश use cases के लिए enough है और long inputs पर much faster run करता है। Intra-line word-by-word highlighting के लिए, two-step refinement standard practice है लेकिन latency add करती है। यदि पूरा line difference आपके लिए matter करता है (legal redlining, prose proofreading), तो एक dedicated word-level tool (command line पर git diff --word-diff सहित) better fit है।

Unified diff और side-by-side में क्या अंतर है?

Unified diff वह compact, machine-readable format है जो हर .patch file use करती है, context की तीन lines, hunks @@ के साथ marked। Side-by-side दोनों versions को parallel columns में display करता है, जो visual review के लिए eye पर easier है लेकिन अधिक horizontal space लेता है। Unified वह है जो आप email या commit करते; side-by-side वह है जो आप wide monitor पर read करते।

क्या Myers से source code के लिए बेहतर algorithms हैं?

Moved functions या large rearrangements वाले source code के लिए, हां, patience diff (Bram Cohen, 2002) और histogram diff (git, around 2010) common ones की बजाय meaningful unique lines पर align करने के लिए designed हैं, more readable output produce करते हैं। दोनों git diff --patience और git diff --histogram के माध्यम से available हैं। difftastic जैसे AST-aware tools आगे जाते हैं और actual language structure parse करते हैं।

क्या यहां confidential text paste करना safe है?

हां, diff पूरी तरह आपके browser में एक JavaScript LCS implementation का उपयोग करके run होता है। कुछ upload नहीं होता, input पर कोई analytics नहीं, text का कोई server-side log नहीं। यह एकमात्र category का diff tool है जो NDAs, internal source code, या unreleased contract clauses के लिए safe है; cloud-based diff services जो भी आप paste करते हैं वह देखती हैं।

संबंधित टूल