Ko pretvorba hex v besedilo gre narobe: napake kodiranja, ki spremenijo bajte v neumnosti

Pretvorba hex v besedilo se zdi, kot da bi morala biti nezmotljiva: vsak par hex števk je en bajt, bajt preslikaš v znak, konec. V praksi pa nenehno odpove, in skoraj nikoli zato, ker bi bil pretvornik pokvarjen — odpove, ker je hex le način zapisovanja bajtov, bajti pa potrebujejo dogovorjeno kodiranje, preden sploh pomenijo kakšen določen znak. Tukaj je, kaj dejansko gre narobe, ko je izhod popačen.

Vzrok 1: napačno predpostavljeno kodiranje znakov

Najpogostejši vzrok od vseh. Bajti hex so bili kodirani kot UTF-8 (kjer marsikateri resnični znak zavzame 2–4 bajte), a jih pretvornik dekodira bajt za bajtom, kot da bi šlo za Latin-1 ali navaden ASCII (kjer je vsak bajt natanko en znak). Rezultat: naglašene črke, ukrivljeni narekovaji, pomišljaji ali kateri koli neangleški znak se spremenijo v dva ali tri popačene simbole namesto v enega pravilnega.

Popravek je vedno dekodiranje z istim kodiranjem, v katerem so bili bajti prvotno zapisani — če ne veš, katero je bilo, je UTF-8 pravilna privzeta izbira za vse sodobno (spletna vsebina, JSON, večina API-jev); Latin-1/Windows-1252 se pojavlja predvsem v starejših, iz Windows izvirajočih besedilnih datotekah ali zastarelih glavah e-pošte.

Vzrok 2: neujemanja vrstnega reda bajtov (endianness)

Ta specifično prizadene večbajtne številske vrednosti (ne besedila), a je dovolj pogost pri orodjih za pretvorbo hex v besedilo, ki obravnavajo mešane binarne/besedilne podatke, da je vreden omembe. 00 01, prebrano kot big-endian, je 1; ista dva bajta, prebrana kot little-endian, je 256. Če hex niz predstavlja številsko predpono dolžine ali binarno polje, vgrajeno v sicer besedilne podatke, branje z napačnim vrstnim redom bajtov ne popači le številke — zamakne vsak naslednji položaj bajta, ker orodje zdaj misli, da se besedilo začne na napačnem odmiku.

Vzrok 3: napake pri združevanju nibblov

Hex bi moral vedno priti v parih — dve hex števki tvorita en bajt. Liho število hex znakov (en zablodel znak, kopiranje in lepljenje, ki je izgubilo znak, vodilni 0x, ki pred razčlenjevanjem ni bil odstranjen) zamakne vsak naslednji par za en nibble. Vsak bajt po napaki se dekodira v popolnoma drugačen, nepovezan znak — izhod ni “malce narobe”, od te točke naprej je popolnoma pomešan, kar je pravzaprav koristen diagnostični znak: neumnost, ki se začne čisto in se popači nekje sredi niza, kaže na napako pri združevanju na tem točno določenem mestu, ne na napačno kodiranje (ki popači bolj enakomerno skozi celoto).

Vzrok 4: nevidni in netiskani bajti

Ne preslika se vsak bajt v viden znak. Kontrolni znaki (0x00–0x1F), oznaka vrstnega reda bajtov (EF BB BF v UTF-8) in razni znaki za oblikovanje Unicode se “uspešno” dekodirajo, a se izrišejo kot nič, kvadratek ali vprašaj, odvisno od pisave prikaza — kar je lahko videti povsem enako kot napaka pri dekodiranju, čeprav je bila sama pretvorba popolnoma pravilna. Če je dolžina izhoda videti pravilna, a se zdi, da besedilu manjkajo znaki, preveri kontrolne bajte, preden posumiš, da je logika dekodiranja napačna.

Hiter način, kako izolirati, s katerim se ukvarjaš

1. Preveri, da ima hex niz sodo število znakov — če ne, gre za vzrok 3, najprej popravi vhod.
2. Poskusi najprej dekodirati kot UTF-8, nato kot Latin-1, in primerjaj — če eden da čisto besedilo, drugi pa ne, je šlo za vzrok 1.
3. Če je izhod popačen enakomerno že od prvega znaka, posumi na kodiranje (vzrok 1); če se začne čisto in se popači nekje sredi niza, posumi na napako pri združevanju (vzrok 3) na tistem mestu.
4. Če se dolžina ujema s pričakovanji, a določeni znaki manjkajo ali se prikažejo kot kvadratki, preveri kontrolne/oblikovalne bajte (vzrok 4), namesto da bi znova preverjal kodiranje.

Pretvorba hex v besedilo je sama po sebi ena vrstica kode v katerem koli jeziku — dejansko razhroščevanje je skoraj vedno v tem, da ugotoviš, katera od teh štirih predpostavk je bila tiho napačna, ne v sami logiki pretvorbe.