Když se převod hex na text pokazí: chyby v kódování, které mění bajty v nesmysly

Převod hex na text vypadá jako něco, co nemůže selhat: každá dvojice hexových číslic je jeden bajt, bajt se namapuje na znak, hotovo. V praxi to selhává neustále, a téměř nikdy proto, že by byl rozbitý převodník — selhává to proto, že hex je jen způsob zápisu bajtů a bajty potřebují dohodnuté kódování, aby vůbec znamenaly nějaký konkrétní znak. Tady je, co se doopravdy děje, když je výstup rozsypaný.

Příčina 1: předpokládané špatné kódování znaků

Zdaleka nejčastější příčina. Hexové bajty byly zakódovány jako UTF-8 (kde mnoho běžných znaků zabírá 2–4 bajty), ale převodník dekóduje bajt po bajtu, jako by šlo o Latin-1 nebo čisté ASCII (kde je každý bajt přesně jeden znak). Výsledek: písmena s diakritikou, typografické uvozovky, dlouhé pomlčky nebo jakýkoli neanglický znak se promění ve dva až tři rozsypané symboly místo jednoho správného.

Oprava je vždy stejná: dekódovat stejným kódováním, jakým byly bajty původně zapsány — a pokud nevíte kterým, správnou výchozí volbou pro cokoli moderního je UTF-8 (webový obsah, JSON, většina API); Latin-1/Windows-1252 se objevuje většinou jen ve starších textových souborech z Windows nebo v hlavičkách starých e-mailů.

Příčina 2: nesoulad pořadí bajtů (endianita)

Tohle se týká konkrétně vícebajtových číselných hodnot (ne textu), ale u nástrojů hex-na-text pracujících se smíšenými binárně-textovými daty je to dost běžné na to, aby to stálo za zmínku. 00 01 čteno jako big-endian je 1; tytéž dva bajty čtené jako little-endian jsou 256. Pokud hexový řetězec představuje číselný prefix délky nebo binární pole vložené do jinak textových dat, čtení se špatným pořadím bajtů nejen špatně přečte číslo — rozhodí i každou další pozici bajtu, protože nástroj si teď myslí, že text začíná na špatném offsetu.

Příčina 3: chyby v seskupení nibblů

Hex má vždy chodit v párech — dvě hexové číslice tvoří jeden bajt. Lichý počet hexových znaků (jedna zatoulaná číslice, copy-paste, který ztratil znak, úvodní 0x, které nebylo před parsováním odstraněno) posune každý následující pár o jeden nibble. Každý bajt za chybou se dekóduje na úplně jiný, nesouvisející znak — výstup není „trochu špatně“, je od toho místa dál kompletně rozházený, což je vlastně užitečná diagnostika: nesmysly, které začínají čistě a rozpadají se v půlce řetězce, ukazují na chybu seskupení přesně na té pozici, ne na problém se špatným kódováním (to kazí výstup rovnoměrněji po celé délce).

Příčina 4: neviditelné a netisknutelné bajty

Ne každý bajt se mapuje na viditelný znak. Řídicí znaky (0x00–0x1F), byte-order-mark (EF BB BF v UTF-8) a různé unicodové formátovací znaky se dekódují „úspěšně“, ale podle zobrazovacího fontu se vykreslí jako nic, čtvereček nebo otazník — což může vypadat úplně stejně jako selhání dekódování, přestože samotný převod byl naprosto správný. Pokud délka výstupu vypadá správně, ale v textu jako by chyběly znaky, zkontrolujte nejdřív řídicí bajty, než začnete podezírat dekódovací logiku.

Rychlý postup, jak zjistit, o kterou příčinu jde

1. Ověřte, že hexový řetězec má sudý počet znaků — pokud ne, je to příčina 3, nejdřív opravte vstup.
2. Zkuste dekódovat nejdřív jako UTF-8, pak jako Latin-1, a porovnejte — pokud jedno dá čistý text a druhé ne, byla to příčina 1.
3. Pokud je výstup rozsypaný rovnoměrně už od prvního znaku, podezírejte kódování (příčina 1); pokud začíná čistě a rozpadá se v průběhu, podezírejte chybu seskupení (příčina 3) na tom místě.
4. Pokud délka odpovídá očekávání, ale konkrétní znaky chybí nebo se zobrazují jako čtverečky, zkontrolujte řídicí/formátovací bajty (příčina 4), místo abyste znovu prověřovali kódování.

Samotný převod hex na text je v jakémkoli jazyce jeden řádek kódu — skutečná ladicí práce spočívá téměř vždy ve zjištění, který z těchto čtyř předpokladů byl potichu špatně, ne v převodní logice.