Magcompare ng dalawang piraso ng teksto _

Paano gumagana ang mga diff algorithm

Ang bawat diff view sa page na ito ay ginawa ng Myers algorithm — isang teknik mula 1986 ni Eugene W. Myers na naghahanap ng pinakamaikling edit script sa pagitan ng dalawang token sequence sa O((N+M)D) na oras, kung saan ang D ay ang edit distance. Ang algorithm ay nakabatay sa Longest Common Subsequence problem, at ang engine ay tumatakbo nang buo sa iyong browser gamit ang open-source na jsdiff library.

1. I-tokenise ang mga input — Bago magcompare, hinahati ng algorithm ang bawat input sa isang sequence ng mga token. Ang line granularity ay naghahati sa mga newline; ang word granularity ay naghahati sa whitespace at punctuation boundaries; ang character granularity ay itinuturing ang bawat Unicode code point bilang sariling token.
2. Buuin ang edit graph — Ini-model ng Myers algorithm ang comparison bilang isang landas sa isang 2D grid kung saan ang paglipat sa kanan ay nangangahulugang "tanggalin mula sa orihinal", ang paglipat pababa ay nangangahulugang "isingit mula sa binago", at ang paglipat nang pahilis ay nangangahulugang "ang token ay tugma sa magkasama". Hinahanap ng algorithm ang pinakamaikling landas na may maraming pahilis na galaw.
3. Kunin ang LCS — Ang mga pahilis na galaw sa pinakamaikling landas ay sumusubaybay sa Longest Common Subsequence — ang mga token na lumabas sa parehong input sa parehong relatibong pagkakasunod. Ang bawat token sa LCS ay "walang pagbabago"; ang lahat ng iba pa ay dagdag o tanggal.
4. Ilapat ang mga opsyon sa preprocessing — Kung i-enable ang "Huwag pansinin ang case", ang parehong input ay iko-lowercase bago ang LCS pass para mabilang ang "HELLO" at "hello" bilang magkapareho. Ang "Huwag pansinin ang whitespace" ay nagcocompress ng maraming espasyo sa isa. Ang "Trim ang bawat linya" ay nag-aalis ng nangunguna at sumusunod na whitespace sa bawat linya bago icompare.
5. I-render ang napiling view — Ang output ay ang parehong resulta ng LCS na ipinapakita sa tatlong paraan: Ang Side-by-side ay nagpapakita ng orihinal sa kaliwa at binago sa kanan sa isang two-column na grid na may pula at berdeng row highlights. Ang Unified ay nagpapakita ng isang column na may − at + prefix na mga linya, tulad ng output ng git diff. Ang Inline ay nagpapakita ng mga tanggal bilang pulang strikethrough at mga dagdag bilang berdeng underline sa loob ng parehong text flow.
6. Kalkulahin ang summary strip — Pagkatapos mag-render, binibilang ng tool kung ilang token ang naidagdag, natanggal, at walang pagbabago, pagkatapos ay kinakalkula ang pagkakatulad bilang ratio ng mga hindi nagbagong token sa mas malaki sa dalawang input length. Ang pagkakatulad na 100% ay nangangahulugang magkapareho ang mga input pagkatapos ng preprocessing.

Bakit gumamit ng diff checker

• Code review nang walang Git client — Mag-paste ng dalawang bersyon ng config file, SQL migration, o shell script at tingnan kung ano ang nagbago nang hindi kailangang mag-clone ng repo, mag-switch ng branch, o maghintay sa CI pipeline. Kapaki-pakinabang ang tool para sa mabilis na review sa panahon ng pair programming, para sa contractor handoffs kung saan hindi pa nagbabahagi ang kabilang panig ng kanilang Git history, at para sa mga legacy na codebase na nauna pa sa version control. Nagpo-produce ang unified view ng output na maaaring direktang i-kopya sa isang chat thread o ticket.
• Mga redline sa kontrata at dokumento — Ang word-level diff ay nagpapakita kung aling mga termino ang nagbago sa pagitan ng mga draft ng kontrata nang mas mabilis kaysa sa Track Changes panel ng Word. Mag-paste ng clause A mula sa unang draft at clause B mula sa isinagawang kopya at ang substitusyon ay magiging malinaw sa eksakto kung saan nagbago. Ginagamit ito ng mga paralegal at procurement team para i-verify na hindi nakalusot ang mga last-minute na redline bago mapirmahan ang kontrata.
• Mga revision sa sanaysay at draft — Ang mga manunulat na nagkocompare ng unang draft laban sa na-edit na bersyon ay maaaring lumipat sa word granularity para makita ang bawat substitusyon, pagsingit, at paggupit nang hindi muling binabasa ang parehong kopya. Ang parehong workflow ay gumagana para sa mga tagasalin na nagsusuri ng mga pagbabago laban sa source text, para sa mga editor na tinitingnan na napreserba ng isang copy edit ang boses ng may-akda, at para sa mga koponan ng peryodismo na nagpapatupad ng isang nailathala na artikulo laban sa naihain na draft.
• Paghahambing ng log at config — Ang mga sysadmin na nagkocompare ng dalawang server config snapshot, dalawang cron schedule, o dalawang ps aux na output ay maaaring gumamit ng line granularity para mahanap ang iisang nagbagong parameter sa isang 200-linya na file sa loob ng ilang segundo. Pagsabayin ito sa Ignore-whitespace na opsyon at ang isang maingay na alignment-only na diff ay mababawasan sa mga pagbabago ng parameter na talagang mahalaga.

Mga karaniwang aplikasyon

Lumalabas ang text diff sa dulo ng bawat ikot ng pag-edit sa pagsulat, pagpapaunlad, at operasyon.

• Pull request review: mag-paste ng dalawang function implementation nang magkatabi para maunawaan ang pagbabago ng lohika bago mag-approve, nang walang overhead ng pag-checkout ng branch.
• Internationalisation QA: icompare ang isang English source string laban sa katumbas na isinalin sa antas ng salita para ma-detect ang mga pagsingit, pagkawala, o pagpapalit ng terminolohiya na maaaring isinagawa ng tagapagsalin.
• Pagsusuri ng insidente: mag-diff ng dalawang Kubernetes manifest snapshot o dalawang "docker inspect" na output sa antas ng linya para maihiwalay ang pagbabago ng configuration na nauna sa isang outage.

Isang halimbawa

Isaalang-alang ang isang limang-linya na server config. Orihinal: host=localhost, port=5432, dbname=app_db, user=app, password=secret. Binago: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Sa line granularity at Side-by-side view, ang linya 1 ay nagpapakita ng pula sa kaliwa (host=localhost) at berde sa kanan (host=db.prod.example.com), ang linya 4 ay nagpapakita ng pula (user=app) at berde (user=app_prod), at ang mga linya 2, 3, at 5 ay nananatiling hindi nagbabago sa magkabilang panig. Ang summary strip ay nag-uulat ng 2 dagdag, 2 tanggal, 3 walang pagbabago, at isang pagkakatulad na 60% — tatlo sa limang linya ay napanatili. Lumipat sa word granularity at ang diff ay lalo pang nagiging tiyak: tanging ang mga halaga sa kanan ng = sa mga linya 1 at 4 lamang ang nagliwanag, ang mga key ay nanatiling hindi nagbabago, at ang pagkakatulad ay umaangat sa humigit-kumulang 85% dahil ang LCS ay binibilang na ngayon ang host, user, at ang nakapaligid na bantas bilang napanatili.

Tumatakbo ba ito sa aking browser?

Oo. Ang buong diff computation ay tumatakbo sa client-side gamit ang open-source na jsdiff library na ini-load kasama ang page. Walang iyong tina-type, pina-paste, o kinocompare ang ipinapadala sa anumang server. Maaari mong i-verify ito mismo: buksan ang browser DevTools, lumipat sa Network tab, linisin ang log, i-click ang Icompare, at kumpirmahin na zero network request ang sumusunog para sa comparison step.

Ano ang ibig sabihin ng porsyento ng pagkakatulad?

Kinakalkula ang pagkakatulad bilang hindi nagbagong mga token / max(kabuuang mga token sa orihinal, kabuuang mga token sa binago). Ang iskor na 100% ay nangangahulugang magkapareho ang dalawang input pagkatapos ilapat ang iyong mga opsyon sa preprocessing (case folding, whitespace collapsing, line trimming). Ang iskor na 0% ay nangangahulugang walang pagkakaparehong token sa pagitan ng mga input. Ang sukatan ay isang magaspang na pagtatantya ng edit distance — kapaki-pakinabang bilang mabilis na sukatan — hindi isang plagiarism o originality na iskor.

Maaari bang mag-diff ng JSON / YAML / XML nang semantiko?

Hindi sa tool na ito. Ito ay isang text-level na diff, kaya ang whitespace-only na pag-reformat ng JSON o XML ay nagpapakita pa rin ng maraming pagbabago kahit na lohikal na magkapareho ang data. Ang muling pag-aayos ng mga object key sa JSON ay nagpapakita rin bilang mga pagbabago kahit na itinuturing ng karamihang parser ang key order bilang hindi mahalaga. Para sa isang tunay na semantic diff na nagkocompare ng mga parsed object tree at nagwawalang-bahala sa key order at pag-format, nagpaplanong maglabas ng dedicated na JSON Diff tool. Sa ngayon, i-normalize ang parehong input sa parehong indentation at key order bago i-paste dito.

Paano naiiba ang unified at side-by-side na view?

Ang Side-by-side ay nagre-render ng dalawang column: ang orihinal sa kaliwa at ang binagong bersyon sa kanan, na may mga tinanggal na linya na naka-highlight na pula sa kaliwa at mga naidagdag na linya na naka-highlight na berde sa kanan. Ang mga hindi nagbagong linya ay lumalabas sa magkabilang column na nakahanay sa parehong row. Ang Unified ay nagre-render ng isang column na may − prefix at pulang background para sa mga tinanggal na linya at isang + prefix at berdeng background para sa mga naidagdag na linya — ang parehong layout na nii-print ng git diff sa iyong terminal. Gamitin ang unified kapag gusto mong kopyahin ang resulta bilang isang patch file o i-paste ito sa isang code review thread. Gamitin ang side-by-side kapag mas mahalaga ang visual na pagkakaisa ng kung ano ang pumalit sa anong bagay kaysa sa raw patch text.

Mag-paste ng orihinal sa kaliwa, ang binagong bersyon sa kanan, pumili ng view at granularity, at ang comparison ay lalabas sa loob ng ilang millisecond. I-on ang Live mode at ang diff ay muling tatakbo sa bawat keystroke habang ine-edit mo ang alinmang panig. I-download ang resulta bilang isang standard na unified .patch file na direktang kinukuha ng git apply. Walang upload, walang account, walang vendor API key, walang quota.