Konversi Encoding & Pemulihan Teks Rusak (Mojibake)

Jawaban singkat

Apa itu mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Apa yang dilakukan alat ini

Contoh kasus

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(hanya sebagian)

Cara memakai alat ini

1. 1

   Tempel teks rusaknya

   Langsung tempel saja — tidak perlu mengidentifikasi encoding lebih dulu. Potongan pendek sudah cukup; belasan karakter biasanya sudah mengunci rantainya.

2. 2

   Baca kandidat teratas dan badge-nya

   Exact berarti rantainya kembali persis ke input Anda. Partial berarti tidak, jadi perlakukan hasilnya sebagai petunjuk.

3. 3

   Periksa rantai encoding-nya

   Setiap kandidat menunjukkan encoding yang sebenarnya menulis teks itu dan encoding yang salah membacanya. Itu memberi tahu apa yang harus diperbaiki di hulu, bukan sekadar isi teksnya.

4. 4

   Periksa byte-nya kalau perlu

   Bagian kedua menampilkan teks apa pun sebagai byte di semua encoding umum, dan mendekode hex mentah ke arah sebaliknya. Pakai untuk menentukan ukuran kolom atau memeriksa frame protokol.

Kesalahan yang justru memperburuk

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Pastikan dulu encoding yang sekarang
file -I correct.txt   # charset=utf-8 → tidak ada yang perlu dikonversi

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Lewati dulu tipe biner agar byte-nya dipertahankan, bukan ditafsirkan ulang
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Ambil kandidat pertama, apa pun kata badge-nya
db.update(row.id, candidates[0].text);

// Hanya tulis kembali yang lolos uji bolak-balik
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Dekode sekali di batas sistem, dengan encoding yang benar-benar dipakai berkasnya
with open(path, encoding='gbk') as f:
    text = f.read()

Kapan Anda membutuhkannya

Migrasi database menghasilkan sampah

Tabel MySQL lawas yang dideklarasikan latin1 padahal sebenarnya menyimpan byte UTF-8 adalah sumber tunggal yang paling umum. Tempel satu baris rusak di sini untuk memastikan rantai yang sebenarnya sebelum Anda menulis ALTER TABLE — menjalankan konversi ke arah yang salah mengubah masalah yang masih bisa dipulihkan menjadi permanen.

CSV yang dibuka di Excel tampil kacau

Excel di Windows masih mengasumsikan code page sistem untuk berkas CSV tanpa BOM, sehingga hasil ekspor UTF-8 keluar sebagai mojibake. Pastikan rantainya di sini, lalu ekspor ulang dengan BOM atau impor lewat text wizard dengan encoding yang disetel eksplisit.

Berkas log dari layanan lawas

Aplikasi yang dibangun untuk GBK atau Shift_JIS menulis log dalam encoding tersebut, sementara agregator log modern membaca semuanya sebagai UTF-8. Tempel satu baris untuk memulihkannya — dan karena tidak ada yang diunggah, Anda bisa melakukannya dengan log produksi.

Nama berkas rusak gara-gara arsip ZIP

Format ZIP tidak punya field encoding, jadi arsip yang dibuat di Windows Tiongkok atau Jepang membawa nama berkas dalam GBK atau Shift_JIS yang dibaca perkakas Unix sebagai UTF-8. Pulihkan nama aslinya di sini sebelum Anda mengganti nama apa pun.

Menentukan ukuran kolom database

Tampilan byte menunjukkan teks yang sama di setiap encoding sekaligus. Satu karakter Mandarin butuh 3 byte di UTF-8 tetapi 2 di GBK, dan perbedaan semacam itulah yang mengubah VARCHAR(50) menjadi bug pemotongan.

Bagaimana mojibake terjadi

Byte bertahan, maknanya tidak

Encoding memetakan karakter ke byte; dekode memetakan byte kembali ke karakter. Mojibake adalah dekode dengan peta yang keliru. Byte-nya sendiri tidak pernah rusak, dan itulah sebabnya menjalankan dekode yang keliru itu secara mundur memulihkan teks asli dengan persis — sepanjang dekode yang keliru tadi tidak membuang apa pun.

Mengapa teks CJK paling menderita

ASCII menempati 0x00–0x7F dan semua encoding umum sepakat soal itu, jadi teks Inggris lewat tanpa cedera. Mandarin, Jepang dan Korea butuh urutan multi-byte, dan encoding-encoding itu tidak sepakat soal cara mengelompokkannya. UTF-8 memakai tiga byte per karakter Mandarin; GBK memakai dua. Umpankan byte UTF-8 ke decoder GBK dan pengelompokannya bergeser, menghasilkan jumlah karakter yang berbeda dengan isi yang berbeda pula.

Uji bolak-balik

Untuk setiap rantai kandidat, alat ini mengodekan ulang teks hasil pemulihan dengan encoding pertama lalu mendekodenya lagi dengan encoding kedua. Kalau itu mereproduksi input dengan persis, rantai tersebut menjelaskan setiap karakter dan kandidatnya ditandai Exact. Kandidat yang gagal tetap ditampilkan, karena pemulihan sebagian sering sudah cukup untuk mengenali teksnya meski tidak bisa mereproduksinya.

Dari mana tabel encoding-nya berasal

TextDecoder milik browser yang menyediakan tabelnya. Arah sebaliknya lebih rumit, karena TextEncoder hanya mendukung UTF-8 — jadi alat ini membangun peta balik dengan menyusuri ruang byte dan menanyakan arti setiap urutan kepada decoder. Pemetaannya karena itu selalu konsisten dengan perilaku browser itu sendiri, dan tidak ada tabel pencarian yang dikirim ke perangkat Anda.

Heuristik pemeringkatan, dan batasnya

Di luar uji bolak-balik, kandidat dinilai dari seberapa banyak teksnya berupa karakter Mandarin umum (yang lead byte GBK-nya jatuh di 0xB0–0xF7), dikurangi penalti untuk karakter pengganti, katakana setengah lebar dan karakter kontrol. Katakana setengah lebar adalah sinyal Shift_JIS yang kuat karena teks Jepang normal nyaris tidak pernah memakainya. Ini heuristik; ia memecah seri, ia tidak menetapkan kebenaran.

Mencegahnya terulang

Perbaiki sumbernya, bukan cuma string-nya

Rantai encoding yang tertera di bawah setiap kandidat memberi tahu komponen mana yang salah konfigurasi. Menambal teksnya tanpa membetulkan charset koneksi, pembaca berkas, atau setelan ekspor berarti mengulang pekerjaan yang sama besok dengan data baru.

Pastikan arahnya sebelum mengonversi satu berkas utuh

Jalankan dulu satu baris yang representatif lewat halaman ini. Mengonversi ke arah yang salah bisa memunculkan karakter pengganti, dan tidak seperti kekeliruan aslinya, langkah itu tidak bisa dibalik.

Setel encoding secara eksplisit di mana-mana

Charset koneksi database, Content-Type HTTP, pemanggilan pembuka berkas, ekspor CSV. Setiap tempat yang jatuh ke "encoding sistem" adalah tempat bug yang sama muncul lagi begitu kodenya pindah ke mesin lain.

Pilih utf8mb4 alih-alih utf8 di MySQL

utf8 di MySQL menyimpan paling banyak tiga byte per karakter, sehingga emoji dan sebagian karakter Mandarin yang jarang dipakai terpotong diam-diam. utf8mb4 adalah UTF-8 yang sebenarnya. Ini kegagalan yang berbeda dari mojibake dan alat pemulihan tidak bisa membantu, karena byte-nya memang benar-benar hilang.

Simpan byte aslinya sampai perbaikannya terverifikasi

Buat salinan sebelum mengonversi apa pun. Selama byte aslinya masih ada, setiap dekode yang salah bisa dibalik — begitu tertimpa karakter pengganti, tidak ada alat di halaman ini atau di mana pun yang bisa mengembalikannya.

Pertanyaan yang sering diajukan