Keď konverzia hex na text zlyhá: chyby v kódovaní, ktoré menia bajty na spleť znakov

Konverzia hex na text pôsobí, akoby sa nemala dať pokaziť: každý pár hex číslic je jeden bajt, bajt sa namapuje na znak, hotovo. V praxi zlyháva neustále, a takmer nikdy nie preto, že by bol konvertor pokazený — zlyháva preto, lebo hex je len spôsob zápisu bajtov, a bajty potrebujú dohodnuté kódovanie, aby vôbec znamenali nejaký konkrétny znak. Tu je to, čo sa v skutočnosti deje, keď je výstup poškodený.

Príčina 1: predpokladá sa nesprávne kódovanie znakov

Vôbec najčastejšia príčina. Hex bajty boli zakódované ako UTF-8 (kde mnoho bežných znakov zaberá 2–4 bajty), ale konvertor dekóduje bajt po bajte, akoby išlo o Latin-1 alebo čisté ASCII (kde je každý bajt presne jeden znak). Výsledok: písmená s diakritikou, typografické úvodzovky, dlhé pomlčky alebo akýkoľvek neanglický znak sa zmenia na dva-tri poškodené symboly namiesto jedného správneho.

Riešením je vždy dekódovať tým istým kódovaním, v akom boli bajty pôvodne zapísané — ak neviete ktorým, UTF-8 je správny predvolený tip pre čokoľvek moderné (webový obsah, JSON, väčšina API); Latin-1/Windows-1252 sa objavuje väčšinou len v starších textových súboroch z Windows alebo v legacy e-mailových hlavičkách.

Príčina 2: nesúlad poradia bajtov (endianness)

Táto sa týka konkrétne viacbajtových číselných hodnôt (nie textu), ale v hex-to-text nástrojoch, ktoré spracúvajú zmiešané binárno-textové dáta, je dosť častá na to, aby stálo za to ju pomenovať. 00 01 čítané ako big-endian je 1; tie isté dva bajty čítané ako little-endian sú 256. Ak hex reťazec predstavuje číselný prefix dĺžky alebo binárne pole vložené do inak textových dát, čítanie s nesprávnym poradím bajtov nielenže zle prečíta číslo — posunie aj každú ďalšiu pozíciu bajtu, pretože nástroj si teraz myslí, že text začína na nesprávnom offsete.

Príčina 3: chyby zoskupovania nibblov

Hex by mal vždy chodiť v pároch — dve hex číslice tvoria jeden bajt. Nepárny počet hex znakov (jedna zatúlaná číslica, kopírovanie, pri ktorom vypadol znak, alebo úvodné 0x, ktoré sa pred parsovaním neodstránilo) posunie každý ďalší pár o jeden nibble. Každý bajt za chybou sa dekóduje na úplne iný, nesúvisiaci znak — výstup nie je „mierne nesprávny“, od toho bodu je úplne premiešaný, čo je vlastne užitočná diagnostika: spleť, ktorá začína čisto a kazí sa až v priebehu reťazca, ukazuje na chybu zoskupovania presne na tej pozícii, nie na problém s kódovaním (ten kazí text rovnomernejšie v celom rozsahu).

Príčina 4: neviditeľné a netlačiteľné bajty

Nie každý bajt sa mapuje na viditeľný znak. Riadiace znaky (0x00–0x1F), byte-order-mark (EF BB BF v UTF-8) a rôzne formátovacie znaky Unicode sa dekódujú „úspešne“, ale zobrazia sa ako nič, štvorček alebo otáznik podľa použitého fontu — čo môže vyzerať identicky ako zlyhanie dekódovania, hoci samotná konverzia bola úplne správna. Ak dĺžka výstupu vyzerá v poriadku, ale zdá sa, že v texte chýbajú znaky, skontrolujte riadiace bajty skôr, než začnete pochybovať o dekódovacej logike.

Rýchly spôsob, ako zistiť, na ktorú z nich sa pozeráte

Overte, že hex reťazec má párny počet znakov — ak nie, je to príčina 3, najprv opravte vstup.
Skúste dekódovať najprv ako UTF-8, potom ako Latin-1, a porovnajte — ak jedno dá čistý text a druhé nie, bola to príčina 1.
Ak je výstup poškodený rovnomerne od úplne prvého znaku, podozrievajte kódovanie (príčina 1); ak začína čisto a kazí sa v priebehu, podozrievajte chybu zoskupovania (príčina 3) na danej pozícii.
Ak dĺžka sedí s očakávaním, ale konkrétne znaky chýbajú alebo sa zobrazujú ako štvorčeky, skontrolujte riadiace/formátovacie bajty (príčina 4) namiesto opätovného preverovania kódovania.

Samotná konverzia hex na text je jeden riadok kódu v akomkoľvek jazyku — skutočná ladiaca práca je takmer vždy v zisťovaní, ktorý z týchto štyroch predpokladov bol potichu nesprávny, nie v konverznej logike.