Amikor a hex–szöveg konvertálás félremegy: a kódolási hibák, amelyek a bájtokból szemetet csinálnak

A hexből szöveggé alakítás elvileg bombabiztos: minden hexjegy-pár egy bájt, a bájtot leképezzük egy karakterre, kész. A gyakorlatban folyamatosan elbukik, és szinte soha nem azért, mert a konvertáló hibás — azért bukik el, mert a hex csupán a bájtok egy leírási módja, a bájtoknak pedig egy közösen elfogadott kódolásra van szükségük ahhoz, hogy egyáltalán bármilyen konkrét karaktert jelentsenek. Íme, mi romlik el valójában, amikor a kimenet zagyva.

1. ok: rossz karakterkódolás feltételezése

Messze a leggyakoribb ok. A hex-bájtok UTF-8-ban lettek kódolva (ahol sok valós karakter 2–4 bájtot foglal), de a konvertáló bájtonként dekódol, mintha Latin-1 vagy sima ASCII lenne (ahol minden bájt pontosan egy karakter). Az eredmény: az ékezetes betűk, kunkori idézőjelek, gondolatjelek és bármilyen nem angol karakter egy helyes jel helyett két-három zagyva szimbólummá változik.

A megoldás mindig az, hogy ugyanazzal a kódolással dekódolj, amellyel a bájtok eredetileg íródtak — ha nem tudod, melyik volt az, minden modern dologhoz (webes tartalom, JSON, a legtöbb API) az UTF-8 a helyes alapértelmezés; a Latin-1/Windows-1252 többnyire csak régebbi, Windowsról származó szövegfájlokban vagy örökölt e-mail-fejlécekben bukkan fel.

2. ok: bájtsorrend (endianness) eltérés

Ez kifejezetten a többbájtos numerikus értékeket érinti (nem a szöveget), de elég gyakori a vegyes bináris/szöveges adatot kezelő hex–szöveg eszközöknél ahhoz, hogy megérdemelje a említést. A 00 01 big-endian olvasatban 1; ugyanaz a két bájt little-endian olvasatban 256. Ha egy hex-string numerikus hosszprefixet vagy egyébként szöveges adatba ágyazott bináris mezőt reprezentál, rossz bájtsorrenddel olvasva nemcsak a számot olvasod félre — az utána következő összes bájtpozíció is elcsúszik, mert az eszköz mostantól rossz eltolásnál gondolja a szöveg kezdetét.

3. ok: nibble-csoportosítási hibák

A hexnek mindig párokban kell érkeznie — két hexjegy egy bájt. Páratlan számú hexkarakter (egy kósza számjegy, egy karaktert elvesztő másolás-beillesztés, egy parse-olás előtt le nem vágott 0x prefix) minden ezt követő párt egy nibble-lel eltol. A hiba utáni minden bájt teljesen más, össze nem függő karakterré dekódolódik — a kimenet nem „kicsit rossz“, hanem attól a ponttól kezdve teljesen összekevert, ami valójában hasznos diagnosztika: ha a szemét tisztán indul, és a string közepén romlik el, az pontosan azon a pozíción lévő csoportosítási hibára utal, nem rossz kódolásra (amely egyenletesebben rontja el az egészet).

4. ok: láthatatlan és nem nyomtatható bájtok

Nem minden bájt képződik le látható karakterre. A vezérlőkarakterek (0x00–0x1F), a byte-order-mark (UTF-8-ban EF BB BF) és különféle Unicode-formázó karakterek „sikeresen“ dekódolódnak, de a megjelenítő betűtípustól függően semmiként, dobozként vagy kérdőjelként jelennek meg — ami pont úgy nézhet ki, mint egy dekódolási hiba, holott maga a konvertálás teljesen helyes volt. Ha a kimenet hossza rendben van, de a szövegből mintha karakterek hiányoznának, ellenőrizd a vezérlőbájtokat, mielőtt a dekódolási logikát hibáztatnád.

Gyors módszer annak eldöntésére, melyikkel állsz szemben

1. Ellenőrizd, hogy a hex-string páros számú karakterből áll-e — ha nem, az a 3. ok; először a bemenetet javítsd.
2. Először próbáld UTF-8-ként dekódolni, majd Latin-1-ként, és hasonlítsd össze — ha az egyik tiszta szöveget ad, a másik nem, az 1. ok volt.
3. Ha a kimenet a legelső karaktertől egyenletesen zagyva, gyanakodj kódolásra (1. ok); ha tisztán indul és menet közben romlik el, gyanakodj csoportosítási hibára (3. ok) azon a pozíción.
4. Ha a hossz megfelel a várakozásnak, de bizonyos karakterek hiányoznak vagy dobozként jelennek meg, vezérlő-/formázóbájtokat keress (4. ok), ne a kódolást ellenőrizd újra.

Maga a hex–szöveg konvertálás bármely nyelven egyetlen sor kód — az igazi hibakeresési munka szinte mindig annak kiderítése, hogy e négy feltételezés közül melyik volt csendben rossz, nem a konvertálási logika.