Anda menyalin teks dari basis data atau dokumen dan tampak seperti ini: "échéance" atau "‘kutip tipografis’". Itulah mojibake — teks yang dikodekan dalam satu set karakter dan didekodekan dalam set lain. Panduan ini menjelaskan secara persis mengapa hal itu terjadi, cara mengidentifikasi ketidakcocokan pengodean yang Anda hadapi, dan cara memperbaikinya dalam hitungan detik dengan alat yang tepat.
Apa itu mojibake?
Mojibake (文字化け) adalah istilah Jepang yang berarti "transformasi karakter": menggambarkan teks kacau yang muncul saat sebuah string ditafsirkan dengan pengodean karakter yang salah. Alih-alih "résumé", Anda melihat "résumé". Alih-alih apostrof tipografis, Anda melihat "’". Karakternya tidak rusak pada level byte — byte-nya baik-baik saja. Masalahnya, perangkat lunak yang membacanya memakai buku aturan yang salah untuk menerjemahkan byte menjadi karakter.
Masalah penerjemahan byte-ke-karakter
Setiap pengodean karakter adalah pemetaan antara angka (byte) dan karakter. Huruf "e" adalah byte 0x65 di hampir semua pengodean. Namun "é" beraksen direpresentasikan secara berbeda tergantung pengodean: di UTF-8 berupa urutan dua byte 0xC3 0xA9, sedangkan di Latin-1 berupa byte tunggal 0xE9. Ketika sebuah program membaca byte UTF-8 0xC3 0xA9 menggunakan aturan Latin-1, ia menghasilkan dua karakter terpisah — Ã dan © — alih-alih satu karakter é. Substitusi itulah mojibake.
- é menjadi é — byte UTF-8 dibaca sebagai Latin-1 (pola paling umum)
- ü menjadi ü — ketidakcocokan yang sama untuk umlaut u Jerman
- ’ (kutip tunggal kanan) menjadi ’ — kutip tipografis UTF-8 salah baca sebagai Latin-1
- – (en dash) menjadi – — umum pada teks yang ditempel dari Word atau PDF
- Karakter pengganti Unicode — karakter valid dipaksa ke konteks yang tidak mampu merepresentasikannya
Note
Mengapa kesalahan pengodean terjadi
Kesalahan pengodean adalah masalah batas sistem. Mereka terjadi saat teks melintasi batas — antara berkas dan aplikasi, antara basis data dan API, antara server web dan peramban — dan sisi pengirim serta penerima tidak sepakat tentang pengodean teksnya. Di dunia di mana UTF-8 adalah standar universal, kesalahan ini seharusnya jarang. Namun mereka umum karena sistem warisan, alat Windows, dan basis data tertentu masih memakai pengodean lama secara bawaan.
Sumber-sumber paling umum
- Berkas CSV dari Excel — Excel menyimpan CSV sebagai Windows-1252 di Windows secara bawaan, bukan UTF-8. Saat dibuka di Linux atau Python, karakter beraksennya kacau.
- Basis data MySQL dengan charset latin1 — instalasi MySQL lama memakai `latin1` bawaan untuk charset kolom. Menyimpan data UTF-8 di dalamnya memicu mojibake saat dibaca.
- Header dan isi surel — klien surel yang tidak mendeklarasikan charset, atau salah membaca deklarasi charset, menghasilkan mojibake pada kolom Dari, Subjek, dan isi.
- Ekstraksi teks PDF — berkas PDF menyematkan font dengan pemetaan glif kustom yang tidak selalu sesuai titik kode Unicode standar, menghasilkan keluaran kacau saat disalin.
- Respons HTTP tanpa charset di Content-Type — server yang mengirim `Content-Type: text/html` tanpa `; charset=utf-8` membiarkan peramban menebak, dan seringnya tebakannya salah.
UTF-8 vs Windows-1252 — ketidakcocokan paling sering
Windows-1252 (juga disebut CP1252) adalah superset Latin-1 yang dikembangkan Microsoft untuk bahasa-bahasa Eropa Barat. Ia memakai satu byte per karakter dan mencakup 256 titik kode — cukup untuk karakter Inggris, Prancis, Jerman, Spanyol, dan Portugis. UTF-8 memakai satu hingga empat byte per karakter dan mencakup seluruh 1,1 juta titik kode Unicode. Ketika teks UTF-8 dibaca sebagai Windows-1252, urutan multibyte menghasilkan pola mojibake khas dua-tiga karakter. Sebaliknya — teks Windows-1252 dibaca sebagai UTF-8 — menghasilkan karakter pengganti (□ atau ?) karena byte tinggi tunggal bukan urutan UTF-8 yang valid.
Teks tanpa metadata pengodean bukanlah teks — ia adalah urutan byte yang menunggu untuk disalahartikan.
Cara mendeteksi masalah pengodean
Mendeteksi masalah pengodean biasanya mudah — penampilan visual mojibake cukup khas untuk mengidentifikasi pola ketidakcocokan. Namun untuk deteksi terprogram, atau untuk teks yang tampak benar tetapi mengandung masalah tak terlihat, Anda butuh teknik khusus.
Pengenalan pola visual
Diagnostik paling andal adalah pola mojibake itu sendiri. Teks UTF-8 yang dibaca sebagai Latin-1 menghasilkan prefiks khas "Ã" diikuti karakter kedua — misalnya é untuk é, à untuk à, ü untuk ü. Tanda baca tipografis dari Word atau editor teks kaya menghasilkan urutan yang diawali †— misalnya ’ untuk ’ dan “ untuk “. Jika Anda melihat urutan-urutan ini, perbaikannya adalah mengodekan ulang byte dari Latin-1 kembali ke UTF-8.
Deteksi pengodean terprogram
Untuk berkas dan aliran data yang isinya tidak bisa Anda lihat secara visual, gunakan pustaka `chardet` (Python) atau paket `jschardet` (Node.js) untuk mendeteksi pengodean otomatis dari pola byte. Pustaka-pustaka ini menganalisis frekuensi dan distribusi nilai byte untuk mengidentifikasi pengodean yang paling mungkin. Mereka tidak 100% akurat — string pendek dan string dengan sedikit karakter non-ASCII lebih sulit diklasifikasi dengan percaya diri — tetapi menangani kasus umum dengan baik. Gunakan Pencari Karakter Unicode untuk memeriksa titik kode individual beserta representasi byte yang diharapkan saat men-debug karakter tertentu.
Tip
Cara memperbaiki mojibake secara online
Cara tercepat memperbaiki teks mojibake adalah Alat Perbaikan Unicode dan Pengodean. Ia berjalan sepenuhnya di peramban Anda — tanpa unggah server, tanpa registrasi — dan menangani secara otomatis ketidakcocokan UTF-8/Latin-1 paling umum, kekacauan kutip tipografis, dan penghapusan karakter tak terlihat.
Identifikasi pola ketidakcocokan pengodean
Sebelum memperbaiki mojibake, identifikasi ketidakcocokan apa yang Anda hadapi. Perhatikan karakter kacau: jika Anda melihat urutan é atau ü, teksnya adalah UTF-8 yang dibaca sebagai Latin-1. Jika melihat urutan ’ atau “, teks memuat kutip tipografis atau tanda baca tipografis yang kacau dengan cara yang sama. Jika melihat tanda tanya atau simbol □, pengodeannya terbalik — byte non-UTF-8 dipaksa ke konteks UTF-8.
Tempel teks yang rusak ke alat perbaikan
Buka Alat Perbaikan Unicode dan Pengodean dan tempel teks mojibake Anda ke kolom masukan. Alat ini langsung menganalisis teks dan mengidentifikasi perbaikan yang paling mungkin: pengodean ulang dari Latin-1 ke UTF-8, perbaikan urutan kutip tipografis, penghapusan karakter lebar nol, normalisasi bentuk Unicode, atau pembersihan tanda urut byte. Deteksinya terjadi di peramban Anda — teks Anda tidak meninggalkan perangkat Anda.
Pilih pasangan pengodean dan terapkan perbaikan
Jika deteksi otomatis benar, klik Perbaiki untuk menerapkan perbaikan. Jika pilihan otomatis tidak cocok dengan kasus Anda, pilih secara manual pengodean sumber (yang dipakai saat teks dibaca salah) dan pengodean target (yang seharusnya dipakai). Untuk kebanyakan konten web, pasangannya Latin-1 → UTF-8. Untuk berkas CSV Windows, seringnya Windows-1252 → UTF-8.
Salin teks hasil perbaikan dan verifikasi
Setelah perbaikan, salin keluarannya dan tempel kembali ke konteks asli Anda — editor dokumen, antarmuka basis data, atau berkas kode. Verifikasi bahwa semua karakter beraksen, tanda kutip, dan simbol khusus tampil benar sebelum menyimpan atau melakukan commit perubahan. Untuk perbaikan data massal di basis data, uji polanya pada sampel baris sebelum menjalankan perbaikan ke seluruh tabel.
Alat Perbaikan Unicode dan Pengodean
Perbaiki mojibake, pulihkan artefak pengodean, normalisasi Unicode, dan bersihkan karakter tak terlihat — gratis, berbasis peramban, tanpa unggah berkas.
Pola mojibake umum dan perbaikannya
Ketidakcocokan pengodean yang berbeda menghasilkan pola visual yang berbeda. Mengenali polanya memberi tahu Anda penyebab sekaligus perbaikan yang benar — pasangan pengodean mana yang diterapkan atau operasi perbaikan mana yang dijalankan.
| Pola mojibake | Karakter asli | Penyebab | Perbaikan |
|---|---|---|---|
| é | é (e akut) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| ü | ü (u umlaut) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| À | À (a gravis) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| ’ | ’ (kutip kanan) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| “ | “ (kutip ganda kiri) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| – | – (en dash) | UTF-8 dibaca sebagai Latin-1 | Kodekan ulang Latin-1 → UTF-8 |
| ’ | ’ (kutip kanan) | UTF-8 dibaca sebagai Windows-1252 | Kodekan ulang Windows-1252 → UTF-8 |
| ? atau □ | Karakter non-ASCII apa pun | Non-UTF-8 dalam konteks UTF-8 | Temukan pengodean asli dengan chardet |
Masalah pengodean ganda
Varian yang terutama merusak adalah mojibake ganda — teks yang salah dikodekan dua kali. Ini menghasilkan urutan seperti © alih-alih ©, atau Æ¢ alih-alih ¢. Terjadi ketika teks yang sudah mojibake disimpan lalu dibaca lagi dengan pengodean salah untuk kedua kalinya. Proses perbaikannya memerlukan dua putaran pengodean ulang dalam urutan terbalik. Alat Perbaikan Unicode dan Pengodean mendeteksi dan menangani pola pengodean ganda paling umum secara otomatis.
Warning
Mencegah kesalahan pengodean
Solusi jangka panjang mojibake adalah menerapkan UTF-8 di setiap batas sistem Anda — penyimpanan berkas, basis data, API, dan lapisan web. Inilah tempat-tempat spesifik di mana deklarasi pengodean harus eksplisit.
Basis data — deklarasikan UTF-8 di mana-mana
Di MySQL dan MariaDB, tetapkan charset bawaan ke `utf8mb4` (bukan `utf8` — `utf8` milik MySQL hanya mencakup urutan 3 byte dan mengecualikan emoji serta karakter Unicode langka). Tetapkan pada tiga level: bawaan server di `my.cnf`, charset basis data, dan charset kolom individual. Di PostgreSQL, bawaannya sudah UTF-8 untuk instalasi baru. Di SQLite, teks selalu UTF-8 secara bawaan.
-- MySQL: set all levels to utf8mb4
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Berkas — selalu simpan sebagai UTF-8
Saat menyimpan berkas teks, ekspor CSV, atau berkas konfigurasi, selalu pilih UTF-8 sebagai pengodean. Di VS Code, pengodean tampil di bilah status — klik untuk mengubahnya. Di Excel, ekspor CSV memakai "CSV UTF-8 (Dipisahkan koma)" alih-alih bawaan "CSV (Dipisahkan koma)". Untuk skrip Python yang menulis berkas, selalu berikan `encoding='utf-8'` secara eksplisit pada panggilan `open()`, jangan bergantung pada bawaan sistem. Bersihkan teks setelah menempel dari sumber eksternal dengan Pembersih Teks Surel yang menghapus karakter tak terlihat dan menormalisasi spasi secara otomatis.
API dan HTTP — deklarasikan charset di Content-Type
Setiap respons HTTP yang memuat teks wajib menyertakan deklarasi charset: `Content-Type: application/json; charset=utf-8` atau `Content-Type: text/html; charset=utf-8`. Tanpanya, klien menebak — dan klien HTTP lama memakai Latin-1 bawaan untuk respons `text/html`. Untuk halaman HTML, tambahkan juga `<meta charset="UTF-8">` sebagai elemen pertama di dalam `<head>`. Untuk API JSON, `Content-Type: application/json` sudah mengimplikasikan UTF-8 menurut RFC, tetapi kejelasan eksplisit menghilangkan ambiguitas dan mencegah masalah dengan klien yang tidak patuh.
Daftar periksa pengodean per konteks
- Berkas Python: tambahkan header `# -*- coding: utf-8 -*-` untuk Python 2; di Python 3 tidak perlu tetapi tidak berbahaya
- String koneksi MySQL: sertakan `charset=utf8mb4` di DSN — mis. `mysql+pymysql://user:pass@host/db?charset=utf8mb4`
- Pembacaan berkas Node.js: berikan `encoding: "utf8"` pada `fs.readFile()` atau gunakan `Buffer.from(data).toString("utf8")`
- Dokumen XML dan HTML: selalu sertakan `<?xml version="1.0" encoding="UTF-8"?>` dan `<meta charset="UTF-8">`
- Pustaka pengiriman surel: tetapkan `Content-Type: text/plain; charset=utf-8` dan `Content-Transfer-Encoding: 8bit` atau `quoted-printable`
Normalisasi Unicode dan karakter tak terlihat
Melampaui ketidakcocokan klasik UTF-8/Latin-1, dua masalah Unicode lain memicu bug halus yang lebih sulit dideteksi: ketidakcocokan normalisasi dan karakter tak terlihat. Keduanya bisa membuat perbandingan string gagal, pencarian basis data meleset, dan hasil pencarian tidak lengkap — bahkan ketika teks tampak identik di layar.
Bentuk normalisasi Unicode
Unicode mengizinkan karakter tampak yang sama direpresentasikan dengan beberapa cara. Huruf "é" dapat dikodekan sebagai satu titik kode praketik (U+00E9) atau sebagai kombinasi "e" (U+0065) diikuti aksen akut kombinatorik (U+0301). Keduanya tampak identik di layar tetapi merupakan urutan byte berbeda yang gagal dalam perbandingan kesamaan string. Inilah sebabnya pencarian "résumé" di basis data kadang melewatkan hasil — teks tersimpan memakai bentuk normalisasi berbeda. NFC (Dekomposisi Kanonik, diikuti Komposisi Kanonik) adalah bentuk normal yang direkomendasikan untuk kebanyakan aplikasi. Alat Perbaikan Unicode dan Pengodean menormalisasi teks ke NFC sebagai bagian dari proses perbaikannya.
Karakter tak terlihat dan lebar nol
Karakter lebar nol adalah titik kode Unicode yang menempati ruang dalam string tetapi dirender tanpa apa pun yang terlihat. Sering disisipkan oleh pengolah kata, aplikasi obrolan, dan operasi salin-tempel dari PDF atau halaman web. Pelaku umumnya adalah spasi lebar nol (U+200B), spasi non-breaking lebar nol (U+FEFF, juga tanda urut byte), dan berbagai karakter kontrol teks dua arah (U+200E, U+200F, U+202A-U+202E). Karakter-karakter ini mematahkan pola regex, membingungkan tokeniser, dan membuat string yang tampak identik terbanding sebagai tidak sama. Gunakan Pencari Karakter Unicode untuk mengidentifikasi titik kode mencurigakan dalam sebuah string.
Note
Pencari Karakter Unicode
Cari karakter Unicode mana pun berdasarkan titik kode atau nama, atau tempel sebuah karakter untuk mengidentifikasi titik kode tak terlihat atau mencurigakan dalam teks Anda.
Key takeaways
- Mojibake disebabkan oleh pembacaan byte teks dengan pengodean yang salah — paling sering byte UTF-8 dibaca sebagai Latin-1 atau Windows-1252.
- Pola é (untuk é) adalah tanda diagnostik mojibake UTF-8-sebagai-Latin-1 — mengenali polanya memberi tahu perbaikan persis yang diperlukan.
- Alat Perbaikan Unicode dan Pengodean mendeteksi dan memperbaiki pola mojibake umum, karakter tak terlihat, dan masalah normalisasi Unicode secara otomatis di peramban Anda.
- Jangan pernah memperbaiki mojibake dengan find-and-replace pada urutan kacau — selalu perbaiki di level pengodean dengan mengodekan ulang byte dengan benar.
- Cegah kesalahan pengodean dengan mendeklarasikan UTF-8 secara eksplisit di setiap batas sistem: berkas, basis data, respons API, dan header HTTP.
- Karakter tak terlihat (spasi lebar nol, BOM, kontrol dua arah) memicu kegagalan perbandingan dan pencarian meski teks tampak benar — harus dibersihkan secara terprogram.
- Ketidakcocokan bentuk normalisasi Unicode (NFC vs NFD) membuat string yang tampak identik gagal dalam perbandingan kesamaan — normalisasi ke NFC sebelum menyimpan atau membandingkan teks.