Penukaran hex ke teks yang tersasar: kesilapan pengekodan yang menukar bait kepada karut

Menukar hex ke teks terasa seperti sepatutnya tanpa cela: setiap pasangan digit hex adalah satu bait, petakan bait itu kepada aksara, selesai. Pada hakikatnya ia kerap gagal, dan hampir tidak pernah kerana penukar itu rosak — ia gagal kerana hex hanyalah cara menulis bait, dan bait memerlukan pengekodan yang dipersetujui sebelum ia bermaksud sebarang aksara tertentu. Ini yang sebenarnya berlaku apabila output menjadi kacau.

Punca 1: pengekodan aksara yang salah diandaikan

Punca paling biasa. Bait hex itu dikodkan sebagai UTF-8 (di mana banyak aksara sebenar mengambil 2–4 bait), tetapi penukar menyahkod bait demi bait seolah-olah ia Latin-1 atau ASCII biasa (di mana setiap bait tepat satu aksara). Hasilnya: huruf beraksen, tanda petik melengkung, sengkang panjang (em dash), atau mana-mana aksara bukan Inggeris bertukar menjadi dua atau tiga simbol kacau dan bukannya satu yang betul.

Pembaikannya sentiasa menyahkod dengan pengekodan yang sama seperti bait itu ditulis asalnya — jika anda tidak tahu yang mana satu, UTF-8 adalah lalai yang betul untuk apa-apa yang moden (kandungan web, JSON, kebanyakan API); Latin-1/Windows-1252 kebanyakannya hanya muncul dalam fail teks lama daripada Windows atau pengepala e-mel warisan.

Punca 2: ketidakpadanan susunan bait (endianness)

Ini secara khusus menjejaskan nilai berangka pelbagai-bait (bukan teks), tetapi cukup biasa dalam alat hex-ke-teks yang mengendalikan data campuran binari/teks untuk dinamakan. 00 01 dibaca big-endian ialah 1; dua bait yang sama dibaca little-endian ialah 256. Jika rentetan hex mewakili awalan panjang berangka atau medan binari yang dibenamkan dalam data yang sebahagian besarnya teks, membacanya dengan susunan bait yang salah bukan sahaja tersalah baca nombor — ia menyasarkan setiap kedudukan bait selepasnya, kerana alat itu kini menyangka teks bermula pada offset yang salah.

Punca 3: kesilapan pengelompokan nibble

Hex sepatutnya sentiasa berpasangan — dua digit hex membentuk satu bait. Bilangan aksara hex yang ganjil (satu digit tersasar, salin-tampal yang menjatuhkan satu aksara, 0x di hadapan yang tidak dibuang sebelum dihurai) mengalihkan setiap pasangan seterusnya sebanyak satu nibble. Setiap bait selepas ralat itu dinyahkod kepada aksara yang sama sekali berbeza dan tidak berkaitan — outputnya bukan “sedikit salah”, ia sepenuhnya kucar-kacir dari titik itu ke hadapan, yang sebenarnya diagnostik berguna: karut yang bermula bersih dan merosot separuh jalan menunjukkan kesilapan pengelompokan pada kedudukan tepat itu, bukan masalah pengekodan yang salah (yang merosakkan secara lebih seragam di seluruh teks).

Punca 4: bait tidak kelihatan dan tidak boleh dicetak

Bukan setiap bait dipetakan kepada aksara yang kelihatan. Aksara kawalan (0x00–0x1F), byte-order-mark (EF BB BF dalam UTF-8), dan pelbagai aksara pemformatan Unicode “berjaya” dinyahkod tetapi dipaparkan sebagai kosong, kotak, atau tanda soal bergantung pada fon paparan — yang boleh kelihatan sama seperti kegagalan penyahkodan walaupun penukaran itu sendiri betul sepenuhnya. Jika panjang output kelihatan betul tetapi teks nampak seperti kehilangan aksara, semak bait kawalan sebelum menganggap logik penyahkodan itu salah.

Cara pantas mengasingkan mana satu yang anda hadapi

1. Sahkan rentetan hex mempunyai bilangan aksara genap — jika tidak, itu punca 3, betulkan input dahulu.
2. Cuba nyahkod sebagai UTF-8 dahulu, kemudian Latin-1, dan bandingkan — jika satu menghasilkan teks bersih dan satu lagi tidak, itu punca 1.
3. Jika output kacau secara seragam dari aksara pertama, syak pengekodan (punca 1); jika ia bermula bersih dan merosot separuh jalan, syak kesilapan pengelompokan (punca 3) pada kedudukan itu.
4. Jika panjang sepadan dengan jangkaan tetapi aksara tertentu hilang atau dipaparkan sebagai kotak, semak bait kawalan/pemformatan (punca 4) dan bukannya menyemak semula pengekodan.

Penukaran hex ke teks itu sendiri hanyalah satu baris kod dalam mana-mana bahasa pengaturcaraan — kerja penyahpepijatan sebenar hampir selalu adalah mencari yang mana satu daripada empat andaian ini yang tersilap secara senyap, bukan dalam logik penukaran itu sendiri.