Text Diff Online: Bandingkan Dua Teks dengan LCS/Myers + 6 Use Case
Alat text diff online menjawab satu pertanyaan dengan cepat: apa yang berubah antara versi A dan versi B? Tempel dua blok teks, alatnya menjalankan algoritma Longest Common Subsequence, dan Anda akan melihat tampilan side-by-side atau unified untuk setiap penyisipan, penghapusan, dan suntingan, biasanya dalam waktu kurang dari satu milidetik.
Panduan ini untuk developer yang melakukan code review, SRE yang membandingkan potongan log, pengacara yang merevisi kontrak, dan penulis yang meninjau hasil suntingan. Isinya mencakup algoritma (LCS, Myers, Patience), dua tampilan standar, opsi ignore yang menyelesaikan 95% keluhan “semua kelihatan berubah”, kapan beralih ke JSON diff, enam use case copy-paste, dan jebakan yang justru dijelaskan oleh algoritmanya sendiri.
Mau langsung membandingkan dua teks sekarang? Buka Bandingkan Teks Online. Semuanya berjalan di browser Anda, tanpa unggah.
1. Apa Itu Text Diff?
Text diff adalah himpunan terkecil dari penyisipan dan penghapusan yang mengubah satu teks menjadi teks lain, dengan setiap baris ditandai sebagai ditambahkan, dihapus, atau tidak berubah. Diff modern menambahkan tahap kedua di level kata atau karakter agar satu suntingan satu-karakter hanya menyorot token itu, bukan seluruh baris.
1.1 Kenapa kesetaraan karakter (===) tidak cukup
Sisipkan satu baris di bagian atas file konfigurasi 200 baris, dan perbandingan karakter naif akan melaporkan setiap byte setelah titik penyisipan sebagai berbeda. Teksnya tidak berubah, posisinya yang bergeser. Algoritma diff harus mengenali bahwa “199 baris berikutnya masih baris yang sama, hanya bergeser satu” dan melaporkannya sebagai satu penyisipan. Pengenalan itulah yang diberikan LCS, dan itu sebabnya git, GitHub, dan setiap alat code review menyertakannya.
1.2 Side-by-side vs unified diff
Side-by-side menempatkan kedua versi dalam kolom paralel dan mewarnai sel-selnya: hijau untuk yang ditambahkan, merah untuk yang dihapus, kuning untuk yang dimodifikasi. Unified diff adalah format teks yang lebih tua dari GNU diff: satu kolom, penanda - dan +, tiga baris konteks di sekitar setiap hunk. Perbandingannya sama, tampilannya berbeda. Bagian 4 membahas kapan memakai masing-masing.
1.3 Di mana text diff digunakan
Code review di GitHub dan GitLab. Output git diff lokal. Patch yang ditempel di Slack. Revisi kontrak. Tinjauan terjemahan. CI snapshot test yang gagal dengan output +/-. Investigasi timeline log. Membandingkan dua file .env. Apa pun yang menuntut dua blok teks dicocokkan baris demi baris.
Buka Bandingkan Teks Online dan tempel dua teks untuk melihatnya bekerja. Setiap perbandingan berjalan secara lokal di browser Anda.
2. Algoritma di Balik Text Diff (LCS + Myers + Patience)
2.1 Longest Common Subsequence
Diberikan dua urutan baris A dan B, Longest Common Subsequence adalah daftar baris terpanjang yang muncul di keduanya, dalam urutan yang sama, tanpa harus berdampingan. Setelah Anda punya LCS, diff-nya langsung terlihat: baris di A tapi tidak di LCS adalah yang dihapus, baris di B tapi tidak di LCS adalah yang ditambahkan, baris di LCS tidak berubah.
LCS klasik berjalan sebagai tabel pemrograman dinamis berukuran N × M. Sel (i, j) menyimpan panjang LCS dari i baris pertama A dan j baris pertama B. Isi tabelnya dari kiri ke kanan, atas ke bawah, lalu telusuri mundur dari sel kanan-bawah untuk merekonstruksi script suntingannya. Waktu dan ruangnya O(N×M): wajar untuk dua file seribu baris, lambat untuk log seratus ribu baris.
2.2 Myers (1986)
Makalah Eugene Myers tahun 1986 berjudul “An O(ND) Difference Algorithm and Its Variations” merumuskan ulang masalahnya sebagai pencarian jalur terpendek melalui graf suntingan: node adalah posisi (i, j) di kedua input, gerakan horizontal adalah penghapusan, gerakan vertikal adalah penyisipan, gerakan diagonal adalah pencocokan. Jalur terpendeknya adalah script suntingan minimum.
Myers berjalan dalam waktu O((N+M)D), dengan D sebagai ukuran script suntingan. Kalau kedua teksnya mirip (kasus yang biasa terjadi pada diff), D bernilai kecil dan algoritmanya pada dasarnya linier. Algoritma ini default di git diff, GNU diff, dan renderer PR GitHub. Untuk sembilan puluh sembilan persen input web, jawabannya tepat.
2.3 Patience diff (Bram Cohen, 2005)
Patience diff mengambil pendekatan berbeda: cari baris yang muncul tepat sekali di setiap input (disebut “unique anchor lines”), pasangkan, lalu lakukan rekursi pada celah antar-anchor. Matematikanya lebih berantakan (kasus terburuknya tetap buruk), tetapi output-nya jauh lebih enak dibaca pada kode.
Kenapa begitu? Myers meminimumkan jarak suntingan, yang secara matematis optimal tetapi tampilannya jelek saat penyelarasan optimal melewati kurung kurawal atau baris kosong yang tidak terkait. Patience menolak menyelaraskan pada boilerplate umum (setiap file punya baris }, setiap file punya baris kosong), sehingga batas fungsi tetap utuh. Bram Cohen membuatnya untuk Bazaar; Git menyertakannya sebagai git diff --patience. Algoritma Histogram yang erat kaitannya (git diff --histogram) sedikit lebih cepat dengan kualitas output serupa.
Bayangkan dua versi file yang sama dengan sebuah fungsi yang sudah dipindahkan. Myers mungkin menyelaraskan kurung penutup fungsi A dengan kurung penutup fungsi B dan melaporkan badan fungsinya benar-benar berbeda. Patience menjangkar pada nama fungsi yang unik dan melaporkan perpindahan yang bersih. Input yang sama, pengalaman review yang sangat berbeda.
2.4 Perbandingan algoritma
| Properti | Myers (default) | Patience | Histogram |
|---|---|---|---|
| Kompleksitas waktu | O((N+M)D) | ~O(N log N) kasus umum | mirip Patience |
| Jarak suntingan optimal | Ya, script terpendek | Tidak, mungkin lebih panjang | Tidak, mungkin lebih panjang |
| Terbaca alami pada kode | Kadang salah menyelaraskan kurung dan baris kosong | Sangat baik — menjangkar pada baris unik | Sangat baik |
| Digunakan oleh | default git, GNU diff, UI GitHub | git diff --patience, Bazaar | git diff --histogram |
| Paling cocok untuk | Kecepatan dan ketepatan pada sebagian besar input | Code review, diff refactor | Sama seperti Patience, sedikit lebih cepat |
2.5 Apa yang dilakukan alat ini
Bandingkan Teks Online memakai LCS pemrograman dinamis klasik dengan dua optimasi agresif: pemangkasan prefix dan suffix yang sama, plus tahap LCS kedua di tingkat token untuk diff kata-tingkat dalam baris. Diff dari dua config dua-ribu baris dengan satu baris yang berubah menyusut menjadi tabel DP 1×1 setelah trimming dan dirender dalam waktu kurang dari satu milidetik. Untuk input web tipikal, pilihan antara Myers dan DP tidak terlihat. Keduanya selesai lebih cepat dari kemampuan browser merender hasilnya.
3. Diff Kata-Tingkat dalam Baris: Kenapa Perubahan Satu Karakter Menyorot Seluruh Baris
Anda mengubah satu identifier di sebuah baris dan seluruh baris menyala merah dan hijau. Bug? Bukan, ini desain.
Diff pertama-tama menjalankan LCS di tingkat baris: “baris 14 diganti.” Lalu untuk setiap pasangan yang diganti, ia menjalankan LCS kedua di tingkat token. Token dihasilkan dengan memisahkan pada batas kata Unicode: rangkaian huruf dan digit tetap menyatu, whitespace dan tanda baca masing-masing menjadi token tersendiri. LCS kedua ini memberi Anda script suntingan minimal di tingkat token di dalam baris itu.
Renderer menggambar baris lengkap dengan warna sorot agar mata Anda menemukannya, lalu hanya melukis token yang berubah dengan latar belakang terang. Token tidak berubah di sekitarnya membawa versi yang lebih redup dari warna yang sama: hadir, tetapi tenang secara visual. Mata Anda mendarat tepat di lokasi suntingan.
Contoh 1: penggantian nama identifier. function getUser(id) menjadi function getUser(userId). Seluruh baris ditandai sebagai dimodifikasi. Di dalam baris itu, hanya id (dicoret merah) dan userId (hijau cerah) yang membawa sorot inline. Sisanya tetap redup.
Contoh 2: perubahan latensi log. POST /api/orders 201 88ms menjadi POST /api/orders 201 4200ms. Baris dimodifikasi. Secara inline, hanya 88 dan 4200 yang terang. Path, method, dan status code tetap redup, persis yang dibutuhkan pembaca timeline insiden.
Saat terlalu banyak token berubah, penyorotan di tingkat kata berubah menjadi kebisingan. Alatnya jatuh balik ke penyajian pasangan remove + add: baris aslinya ditampilkan sebagai dihapus, baris barunya ditampilkan sebagai ditambahkan, tanpa pewarnaan dalam baris. Ambang batasnya kira-kira “lebih dari setengah token berbeda.”
Ringkasnya: diff tingkat-baris memberi tahu baris mana yang berubah; diff tingkat-kata memberi tahu karakter mana di baris itu yang membawa perubahan. Klik Sample di Bandingkan Teks Online untuk melihat kedua tampilan pada input yang sama.
4. Side-by-Side vs Unified Diff: Dua Tampilan, Satu Diff
4.1 Tampilan side-by-side
Dua kolom: asli di kiri, modifikasi di kanan. Baris yang cocok diselaraskan secara horizontal. Baris yang ditambahkan hanya muncul di kolom kanan dengan latar hijau; baris yang dihapus hanya muncul di kolom kiri dengan latar merah; pasangan yang dimodifikasi duduk berdampingan dengan gutter kuning dan sorot kata-tingkat dalam baris.
Pakai side-by-side saat manusia akan membaca diff-nya: review PR, mengajar, demo, atau menelusuri perubahan kontrak bersama pemangku kepentingan non-teknis. Ini tampilan untuk mata.
Kekurangannya: tidak portabel. Anda tidak bisa menempel rendering side-by-side ke Slack lalu ada orang yang bisa menerapkannya. Anda juga tidak bisa mengalirkannya ke patch. Untuk berbagi dan menerapkan, Anda butuh unified.
4.2 Format unified diff
Unified diff adalah format teks polos berusia lima puluh tahun yang didefinisikan oleh GNU diff dan distandarisasi di POSIX. Contoh lengkap:
--- original
+++ modified
@@ -1,3 +1,4 @@
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
+2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.Dua baris pertama menamai file sumber. Baris @@ -L,C +L,C @@ adalah header hunk: -L,C berarti mulai dari baris L pada original, ada C baris yang terlibat; +L,C artinya sama untuk versi modifikasi. Di dalam hunk, baris yang diawali spasi adalah konteks (tidak berubah), - adalah dihapus, + adalah ditambahkan.
Tiga baris konteks di atas dan di bawah setiap perubahan adalah default GNU. Sebagian besar alat memungkinkan Anda mengubahnya dengan -U n: diff -U0 untuk tanpa konteks, diff -U10 untuk sepuluh baris. Header hunk mengikuti pilihan Anda.
Di Bandingkan Teks Online, klik tab Unified untuk berganti tampilan atau klik Copy unified diff untuk meletakkan patch di clipboard Anda.
4.3 Di mana unified diff portabel
Unified diff bisa dibawa ke mana-mana. Ini adalah mata uang universal untuk perubahan teks.
| Tujuan | Menerima unified diff? | Caranya |
|---|---|---|
GNU patch | Ya | patch -p1 < diff.patch |
git apply | Ya | git apply diff.patch |
| Komentar review PR GitHub | Ya (dalam blok ```diff) | Dirender berwarna |
| Komentar MR GitLab | Ya | Blok kode bertanda sama |
| PR Bitbucket / Azure DevOps | Ya | Blok kode bertanda sama |
| Tempel ke Slack / Discord | Sebagian | Dirender sebagai teks di blok kode, tanpa warna |
| VS Code “Open Patch” | Ya | Apply patch via Source Control |
| Body issue Jira / Linear | Sebagian | Bekerja di blok kode, tanpa tombol apply |
Sembilan baris ---/+++/@@ yang sama berlaku di patch, di git apply, dirender di tiga platform PR, dan selamat di Slack saat ditempel. Tidak ada format diff lain yang punya jangkauan sebesar itu.
4.4 Kapan memilih yang mana
Side-by-side untuk review, unified untuk berbagi dan menerapkan. Kalau Anda sendiri yang membaca diff-nya, kolom lebih cepat. Kalau ada orang atau alat di hilir yang perlu mengonsumsinya (reviewer, alat, perintah patch), salin format unified.
5. Opsi Ignore: Whitespace, Case, Baris Kosong, Akhir Baris
Sebagian besar keluhan “semua kelihatan berubah” sebenarnya hanya kebisingan. Empat tombol menyelesaikan 95% di antaranya.
- Ignore case memetakan
Akea. Setara dengangit diff -i. Pakai untuk perbandingan environment variable, audit gaya kata kunci SQL, di mana pun konvensinya adalah huruf besar berteriak versus huruf kecil tenang tetapi maknanya identik. - Ignore all whitespace mengempiskan setiap spasi, tab, dan baris baru sebelum perbandingan. Setara dengan
git diff -w. Obat untuk reformatting tab vs spasi, penulisan ulang indentasi, dan diff “kami beralih ke Prettier” yang menghancurkan hitungan baris. Diff yang mengabaikan whitespace pada perubahan semacam itu biasanya turun dari 87 modifikasi menjadi 4. - Ignore trailing spaces and tabs hanya menghapus whitespace di akhir baris. Setara dengan
git diff -b. Obat untuk kebisingan CRLF setelah menyalin antar mesin Windows dan Unix: karakter\rdi akhir disaring keluar dan konten aslinya menjadi sejajar. - Ignore blank lines menghilangkan baris kosong sebelum melakukan diff. Obat untuk “saya menambahkan satu jeda paragraf dan sekarang paragraf 12 terlihat sangat berbeda” pada diff prosa.
Konfigurasi 200 baris yang melaporkan “87 modifikasi” biasanya turun menjadi “4 modifikasi” setelah Ignore all whitespace. Salinan Windows-ke-Unix yang menandai setiap baris turun menjadi nol dengan Ignore trailing spaces. Setiap tombol berdiri sendiri dan dipertahankan antar sesi.
CRLF vs LF. Akhir baris Windows adalah \r\n; Unix adalah \n; Mac klasik adalah \r. Buka file Windows di editor Unix yang tidak melakukan normalisasi dan Anda akan menyimpan \r di akhir. Setiap baris akan ter-diff sebagai “kontennya cocok tetapi ada \r di akhir.” Ignore trailing spaces membungkam ini tanpa kehilangan perubahan yang sesungguhnya.
Satu peringatan. Opsi ignore adalah pisau bermata dua. Aktifkan Ignore case dan refactor yang mengubah LOG.error menjadi log.Error akan kelihatan identik. Aktifkan Ignore all whitespace dan bug indentasi Python jadi tak terlihat. Pilih tombol untuk pertanyaan yang sedang Anda ajukan, lalu matikan saat selesai.
6. Text Diff vs JSON Diff vs Git Diff: Matriks Keputusan
Text diff adalah pencocokan baris-dan-kata tanpa pemahaman tentang struktur. Itu persis yang Anda mau untuk prosa, dan persis yang Anda tidak mau untuk JSON.
6.1 Matriks keputusan
| Tipe input | Text diff | JSON diff | Git diff |
|---|---|---|---|
| Prosa / Markdown / kontrak | Terbaik | Salah alat | Sebagian (hanya pada file yang dilacak) |
| Snippet kode (paste satu file) | Terbaik | Salah alat | Sebagian (perlu repo) |
| Kode dalam repo (multi-file) | Sebagian | Salah alat | Terbaik |
| Respons API JSON | Salah alat (false positive pada urutan key) | Terbaik | Salah alat |
| Konfigurasi YAML / TOML | Sebagian (false positive pada urutan key) | Terbaik (setelah konversi) | Sebagian |
| CSV baris demi baris | Sebagian | Salah alat | Salah alat |
| Log / heredoc | Terbaik | Salah alat | Salah alat |
| File biner | Salah alat | Salah alat | git diff --binary |
6.2 Saat text diff adalah alat yang salah
Tiga kesalahan klasik.
JSON dengan key yang diurutkan ulang. {"a":1,"b":2} dan {"b":2,"a":1} adalah dokumen JSON yang sama. Text diff melaporkan setiap baris sebagai berubah karena memang berbeda. Pakai Bandingkan JSON Online: alat ini paham bahwa key JSON tidak berurutan.
Konfigurasi YAML yang diformat ulang. Ubah satu nilai, jalankan file melalui formatter, dan indentasi, urutan key, serta gaya quoting semuanya bergeser. Text diff melaporkan penulisan ulang lengkap. Konversikan kedua file ke JSON dulu, lalu bandingkan dengan JSON Diff.
Refactor multi-file dengan penggantian nama. Git melacak penggantian nama; text diff tidak. Kalau Anda membandingkan dua tree dengan menggabungkan file ke satu blob, setiap perpindahan lintas-file akan kelihatan sebagai dihapus + ditambahkan. Pakai git diff (atau git diff --find-renames=80%) sebagai gantinya.
6.3 Saat text diff persis tepat
Prosa. Snippet kode yang ditempel dari mana saja. Revisi kontrak. Potongan log. Tinjauan terjemahan saat Anda mencocokkan kalimat bahasa alami. File .env yang urutannya penting karena shell membacanya dari atas ke bawah. Apa pun yang barisnya sendiri membawa makna.
Untuk pembahasan mendalam soal menyaring kebisingan dari JSON diff (timestamp, ID request, UUID yang dihasilkan otomatis), baca Cara Mengabaikan Timestamp dan ID dalam JSON Diff.
7. Enam Use Case Dunia Nyata (dengan Input Copy-Paste)
7.1 Snippet code review: penggantian nama fungsi
Anda sedang me-review sebuah PR. Penulis mengganti nama id menjadi userId dan menambahkan guard clause. Tempel kedua versinya:
// Original
function getUser(id) {
const u = db.users.find(x => x.id === id);
return u;
}// Modified
function getUser(userId) {
if (!userId) return null;
const u = db.users.find(x => x.id === userId);
return u;
}Diff menampilkan tiga baris yang dimodifikasi plus satu baris yang ditambahkan. Sorot kata inline menandai setiap token id → userId; guard clause baru muncul dengan latar hijau. Opsi ignore mati. Coba di Bandingkan Teks Online dan salin output unified-nya untuk ditinggalkan sebagai komentar review.
7.2 Revisi kontrak atau kebijakan: satu klausul disisipkan
Lima puluh paragraf kontrak, satu klausul disisipkan. Tempel versi kemarin di kiri dan versi hari ini di kanan:
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.Diff merender empat puluh sembilan baris tidak berubah dan satu baris ditambahkan (+2a. Termination notice must be in writing.). Ekspor unified diff sebagai jejak tinjauan hukum.
7.3 Investigasi timeline log
Anda menduga ada regresi latensi. Ambil potongan access log dari sebelum dan selama insiden:
GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21msGET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21msSorot inline memunculkan 88 → 4200 (lompatan latensi 50×) dan 200 → 500 (endpoint detail pesanan mulai gagal). Untuk pekerjaan log yang lebih kaya (menarik field, mengelompokkan per endpoint, menghitung persentil), pasangkan diff dengan Cheat Sheet jq kalau log Anda dalam format JSON.
7.4 Tinjauan terjemahan: menjaga placeholder
Anda merekrut agensi terjemahan baru dan ingin memverifikasi bahwa salinan barunya cocok dengan yang lama dalam hal struktur. Tempel terjemahan lama di kiri, yang baru di kanan. Aktifkan Ignore trailing spaces / tabs karena penerjemah rutin menambahkan spasi liar di akhir string.
Diff mengonfirmasi setiap placeholder {username}, {count}, dan %s tetap di tempatnya; hanya teks bahasa alami yang berubah. Placeholder yang hilang akan muncul sebagai token yang dihapus di diff inline, ketahuan sebelum Anda merilis. Kalau Anda perlu membandingkan format placeholder itu sendiri, Cheat Sheet Regex mencakup \{\w+\} dan kawan-kawan. Coba di Bandingkan Teks Online.
7.5 Audit konfigurasi atau .env: produksi vs staging
Bandingkan dua file .env. Aktifkan Ignore blank lines supaya pengelompokan bergaya paragraf tidak salah menyelaraskan bagian. Diff menampilkan key mana yang berbeda nilainya, key mana yang ada di satu environment tapi tidak di yang lain, dan di mana komentar sudah keluar dari sinkron. Lima menit yang mencegah sesi debugging “ini jalan di staging tapi tidak di prod.”
7.6 Revisi prosa atau draft
Editor Anda mengembalikan sebuah draft. Tempel naskah asli Anda di kiri dan versi yang sudah disunting di kanan. Diff kata-tingkat dalam baris menampilkan kalimat mana yang ditulis ulang, mana yang tidak disentuh, dan paragraf mana yang disisipkan. Terima atau tolak perubahan satu per satu, tanpa fitur Track Changes, tanpa file Word, tanpa format proprietary.
8. Jebakan Umum dan Cara Membacanya Sebagai Gejala
Perilaku algoritma menjelaskan sebagian besar keluhan pengguna. Lima keluhan umum dan arti sebenarnya.
Jebakan 1: “Setiap baris merah setelah salinan Windows-ke-Unix.” Gejala: setiap baris di diff kelihatan berubah padahal kontennya tampak identik. Penyebab: karakter \r di akhir dari akhir baris CRLF. Perbaikan: aktifkan Ignore trailing spaces / tabs. Diff akan turun ke perubahan yang sesungguhnya.
Jebakan 2: “Saya menempel JSON dan 100% baris berbeda.” Gejala: dua objek JSON yang seharusnya setara kelihatan berubah seluruhnya. Penyebab: key diurutkan ulang. Text diff memperlakukan urutan baris sebagai signifikan; JSON tidak. Perbaikan: pakai Bandingkan JSON Online untuk setiap input JSON.
Jebakan 3: “Reformatting tab vs spasi meledakkan diff.” Gejala: 87 modifikasi, semuanya indentasi. Penyebab: formatter Anda mengubah whitespace di awal setiap baris. Perbaikan: Ignore all whitespace akan mengempiskan kebisingannya dan memunculkan perubahan semantik yang sesungguhnya.
Jebakan 4: “Diff bilang identik tapi cmp tidak setuju.” Gejala: diff melaporkan tidak ada perbedaan tapi perbandingan tingkat byte mengatakan file-nya berbeda. Penyebab: opsi ignore yang tertinggal aktif dari sesi sebelumnya menutupi perubahan yang nyata. Perbaikan: buka panel opsi Ignore dan matikan setiap tombol, lalu jalankan diff lagi.
Jebakan 5: “Satu suntingan pendek muncul sebagai remove + add.” Gejala: perubahan kecil muncul sebagai baris yang dihapus terpisah dan baris yang ditambahkan terpisah, bukan sorot inline. Penyebab: proporsi token yang berubah melewati ambang batas inline dan renderer jatuh balik ke penyajian baris berpasangan. Ini desain, bukan bug. Beralih ke tampilan Unified untuk melihat pasangan klasik -/+ yang diharapkan oleh alat patch.
9. Privasi, Performa, dan Kapan Beralih ke Command Line
Setiap perbandingan di Bandingkan Teks Online berjalan dalam JavaScript di browser Anda. Tanpa unggah, tanpa file sementara, tanpa server log, tanpa analitik pada teks yang Anda tempel. Aman untuk kode proprietary, kontrak internal, log privat, apa pun yang tidak mau Anda tempel ke server pihak ketiga.
Batas praktis: sekitar 5.000 baris atau 1 MB per sisi. Live diff dinonaktifkan di atas 200 KB gabungan dan beralih ke tombol Diff manual supaya mengetik tidak memblokir halaman. Di atas 5.000 baris, input dipotong dan peringatan ditampilkan. Batas-batas ini ada karena diff berjalan di main thread (tanpa web worker), dan serah-terima ke worker plus serialisasi akan lebih mahal daripada diff itu sendiri pada input kecil.
Saat input Anda melebihi browser, beralihlah ke command line:
# Unified diff antara dua file
diff -u a.txt b.txt
# Sama, tapi pakai mesin diff git (Patience, Histogram, warna)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt
# Diff viewer streaming untuk file besar (Rust, side-by-side, syntax-aware)
delta a.txt b.txtBeralihlah ke command line untuk log multi-megabyte, file biner, diff repositori multi-file, apa pun yang Anda inginkan dengan pewarnaan syntax-aware seperti delta, atau di mana pun Anda perlu mengalirkan output diff ke alat lain.
10. Unicode, CJK, dan RTL: Catatan Text Diff Internasional
Tokenizer memisahkan pada batas kata Unicode dengan tiga kategori: rangkaian kata (huruf \p{L} dan angka \p{N}), tanda baca non-kata, dan whitespace. Setiap kategori menghasilkan tokennya sendiri, jadi hello, world! menjadi hello, ,, , world, !: lima token.
Untuk konten CJK (Tionghoa, Jepang, Korea), setiap ideograf atau kana adalah token tersendiri. Ubah satu karakter dalam kalimat Tionghoa dan hanya karakter itu yang membawa sorot inline sementara sisa baris tetap redup. Struktur tingkat paragraf masih berbasis baris, jadi penulisan ulang kalimat yang menambahkan jeda baris muncul sebagai suntingan tingkat-baris, bukan tingkat-token.
Untuk bahasa RTL (Arab, Ibrani), diff memakai arah CSS logis (ms-, me- bukan ml-, mr-). Pada locale RTL, gutter dan kolom baris membalik secara alami; di setiap sel diff, arah teks mengikuti konten, sehingga string Arab dirender kanan-ke-kiri sementara penanda + dan - tetap sejajar dengan gutter awal.
Normalisasi akhir baris mengenali \r\n (Windows), \n (Unix), dan \r telanjang (Mac OS lama hingga versi 9). Ketiganya dipisah sebagai baris terpisah, sehingga file yang dikonversi dari satu platform ke platform lain tidak menyusut menjadi satu mega-baris.
11. FAQ
Bagaimana cara kerja text diff online?
Text diff memisahkan kedua input menjadi baris, menjalankan algoritma Longest Common Subsequence (biasanya O((N+M)D) milik Myers) untuk menemukan himpunan terkecil dari penyisipan dan penghapusan, lalu menyorot baris yang ditambahkan (hijau), dihapus (merah), dan tidak berubah (abu-abu). LCS kedua di tingkat token menandai kata yang berubah di setiap baris yang dimodifikasi. Bandingkan Teks Online menjalankan seluruh perbandingan secara lokal di browser Anda.
Apa perbedaan text diff dan JSON diff?
Text diff membandingkan baris demi baris: ideal untuk prosa, kode, log, dan kontrak. Bandingkan JSON Online memahami model data JSON: urutan key tidak relevan, tipe ketat (1 ≠ "1"), array bisa dicocokkan dengan key. Tempel JSON ke text diff dan urutan key atau whitespace akan muncul sebagai perubahan yang diabaikan JSON Diff. Pakai text diff untuk konten tidak terstruktur, JSON Diff untuk respons API dan konfigurasi.
Kenapa diff menampilkan seluruh baris berubah padahal saya hanya mengedit satu kata?
Sebenarnya tidak: barisnya disorot karena ada sesuatu di dalamnya yang berubah, tapi di dalam sorot itu hanya token yang berubah yang membawa latar terang (hijau untuk yang ditambahkan, dicoret merah untuk yang dihapus). Inilah diff kata-tingkat dalam baris: konteks baris tetap terbaca sementara mata Anda mendarat tepat di lokasi suntingan. Saat terlalu banyak bagian baris yang berubah sehingga penyorotan tingkat kata tidak berguna, diff jatuh balik ke pasangan remove + add yang terpisah supaya strukturnya tetap bersih.
Bagaimana cara mengabaikan whitespace, case, atau baris kosong dalam diff?
Aktifkan panel opsi Ignore. Ignore case membuat A dan a setara. Ignore all whitespace mengempiskan setiap spasi, tab, dan baris baru, setara dengan git diff -w. Ignore trailing spaces and tabs mencerminkan git diff -b dan membungkam kebisingan CRLF. Ignore blank lines menghilangkan baris kosong sehingga penataan ulang spasi paragraf berhenti salah menyelaraskan diff. Setiap opsi berdiri sendiri dan dipertahankan antar sesi.
Apa itu format unified diff?
Unified diff adalah format teks ---/+++/@@ -L,C +L,C @@ yang diperkenalkan oleh GNU diff di akhir 1980-an dan dipakai oleh git, GitHub, GitLab, serta perintah patch Unix. Setiap hunk menampilkan tiga baris konteks di sekitar perubahan, dengan - untuk yang dihapus dan + untuk yang ditambahkan. Salin output unified ke komentar PR, tempel ke git apply, atau jalankan patch -p1 < diff.patch: semuanya akan diterapkan dengan bersih.
Myers vs Patience: algoritma diff mana yang lebih baik untuk code review?
Myers adalah default di git diff dan GNU diff: cepat dan minimal secara matematis, tetapi kadang menyelaraskan baris kosong atau kurung penutup yang tidak terkait, menghasilkan diff yang “terbaca aneh.” Patience (Bram Cohen, 2005) menjangkar pada baris yang muncul tepat sekali di setiap input dan melakukan rekursi antar-anchor, sehingga batas fungsi tetap utuh. Pakai git diff --patience (atau --histogram untuk hasil serupa, sedikit lebih cepat) saat me-review refactor.
Apakah teks yang saya tempel dikirim ke server?
Tidak. Setiap perbandingan di Bandingkan Teks Online berjalan secara lokal dalam JavaScript di browser Anda. Teks Anda tidak pernah diunggah, dicatat, disimpan di disk, atau dikirim ke pihak ketiga mana pun. Hanya preferensi UI Anda (mode tampilan dan tombol opsi ignore) yang disimpan ke localStorage supaya halaman mengingatnya pada kunjungan berikutnya, tidak pernah teksnya. Verifikasi dengan DevTools → Network: nol request tercipta saat Anda mengklik Diff.
Seberapa besar kedua input bisa?
Batas praktisnya sekitar 5.000 baris atau 1 MB per sisi. Live diff dinonaktifkan di atas 200 KB gabungan dan beralih ke tombol Diff manual. Di atas 5.000 baris, input dipotong dengan peringatan. Untuk file multi-megabyte, beralih ke diff -u a.txt b.txt, git diff --no-index a.txt b.txt, atau delta: semuanya melakukan streaming dan menangani gigabyte.