Kesalahan konversi hex ke text: kenapa byte berubah jadi karakter acak

Mengonversi hex ke text terasa seperti hal yang seharusnya tidak mungkin salah: setiap dua digit hex adalah satu byte, petakan byte itu ke karakter, selesai. Kenyataannya sering gagal, dan hampir tidak pernah karena converter-nya rusak — gagal karena hex hanyalah cara menuliskan byte, dan byte butuh kesepakatan encoding dulu sebelum bisa dimaknai sebagai karakter tertentu. Berikut apa yang sebenarnya terjadi saat hasilnya berantakan.

Penyebab 1: asumsi encoding karakter yang salah

Penyebab paling umum. Byte hex tersebut awalnya dienkode sebagai UTF-8 (di mana banyak karakter yang umum dipakai memerlukan 2–4 byte), tapi converter mendekodekannya byte per byte seolah-olah itu Latin-1 atau ASCII biasa (di mana setiap byte persis satu karakter). Hasilnya: huruf beraksen, tanda kutip melengkung, tanda pisah panjang (em dash), atau karakter non-Inggris apa pun berubah jadi dua atau tiga simbol acak, bukan satu karakter yang benar.

Solusinya selalu sama: dekode dengan encoding yang sama seperti saat byte itu pertama kali ditulis — kalau tidak tahu encoding-nya apa, UTF-8 adalah pilihan default yang tepat untuk hampir semua hal modern (konten web, JSON, kebanyakan API); Latin-1/Windows-1252 biasanya hanya muncul di file teks lawas asal Windows atau header email lama.

Penyebab 2: ketidakcocokan urutan byte (endianness)

Yang satu ini khusus memengaruhi nilai numerik multi-byte (bukan teks), tapi cukup umum terjadi pada tool hex-to-text yang menangani campuran data biner dan teks sehingga perlu disebutkan. 00 01 dibaca big-endian bernilai 1; dua byte yang sama dibaca little-endian bernilai 256. Kalau sebuah string hex merepresentasikan prefix panjang numerik atau field biner yang tertanam di tengah data yang sebagian besar berupa teks, membacanya dengan urutan byte yang salah bukan cuma salah membaca angkanya — ini menggeser posisi setiap byte setelahnya, karena tool jadi mengira teks dimulai dari offset yang salah.

Penyebab 3: kesalahan pengelompokan nibble

Hex seharusnya selalu berpasangan — dua digit hex membentuk satu byte. Jumlah karakter hex yang ganjil (satu digit nyasar, hasil copy-paste yang kehilangan satu karakter, awalan 0x yang belum dihapus sebelum di-parse) menggeser setiap pasangan berikutnya sebanyak satu nibble. Setiap byte setelah titik kesalahan akan didekode menjadi karakter yang sama sekali berbeda dan tidak berhubungan — hasilnya bukan “sedikit salah”, tapi benar-benar acak mulai dari titik itu dan seterusnya. Ini sebenarnya petunjuk diagnostik yang berguna: teks acak yang mulai bersih lalu rusak di tengah jalan menunjukkan kesalahan pengelompokan tepat di posisi tersebut, bukan masalah encoding yang salah (yang biasanya merusak secara lebih merata di sepanjang teks).

Penyebab 4: byte yang tidak terlihat dan tidak bisa dicetak

Tidak semua byte memiliki karakter yang bisa ditampilkan. Karakter kontrol (0x00–0x1F), byte-order-mark (EF BB BF di UTF-8), dan berbagai karakter format Unicode berhasil “didekode” tapi tampil sebagai kosong, kotak, atau tanda tanya tergantung font yang dipakai — yang bisa terlihat persis seperti kegagalan decoding padahal proses konversinya sendiri sepenuhnya benar. Kalau panjang hasil sudah sesuai tapi teks terlihat kehilangan karakter, periksa dulu adanya byte kontrol sebelum menganggap logika decoding-nya yang salah.

Cara cepat mengenali mana penyebabnya

1. Pastikan string hex punya jumlah karakter genap — kalau tidak, itu penyebab 3, perbaiki dulu inputnya.
2. Coba dekode sebagai UTF-8 dulu, lalu Latin-1, dan bandingkan — kalau salah satunya menghasilkan teks bersih dan yang lain tidak, berarti itu penyebab 1.
3. Kalau hasilnya acak secara merata sejak karakter pertama, curigai masalah encoding (penyebab 1); kalau mulai bersih lalu rusak di tengah jalan, curigai kesalahan pengelompokan (penyebab 3) di titik tersebut.
4. Kalau panjang hasil sudah sesuai ekspektasi tapi ada karakter tertentu yang hilang atau tampil sebagai kotak, periksa byte kontrol/format (penyebab 4), bukan mengecek ulang encoding-nya.

Konversi hex ke text itu sendiri hanya satu baris kode di bahasa pemrograman mana pun — pekerjaan debugging sesungguhnya hampir selalu terletak pada mencari tahu asumsi mana dari keempat hal di atas yang diam-diam salah, bukan pada logika konversinya.