Når hex til tekst går galt: encodingfejlene der forvandler bytes til volapyk

At konvertere hex til tekst føles, som om det burde være idiotsikkert: hvert par hex-cifre er én byte, map byten til et tegn, færdig. I praksis fejler det konstant, og næsten aldrig fordi konverteren er i stykker — det fejler, fordi hex bare er en måde at skrive bytes på, og bytes kræver en aftalt encoding, før de overhovedet betyder noget bestemt tegn. Her er, hvad der faktisk går galt, når outputtet er forvansket.

Årsag 1: forkert antaget tegnkodning

Den suverænt hyppigste årsag. Hex-bytene blev kodet som UTF-8 (hvor mange virkelige tegn fylder 2–4 bytes), men konverteren afkoder byte for byte, som var det Latin-1 eller ren ASCII (hvor hver byte er præcis ét tegn). Resultatet: bogstaver med accenter, typografiske anførselstegn, tankestreger og alle ikke-engelske tegn bliver til to eller tre forvanskede symboler i stedet for ét korrekt.

Løsningen er altid at afkode med den samme encoding, som bytene oprindeligt blev skrevet i — ved du ikke hvilken, er UTF-8 det korrekte standardvalg for alt moderne (webindhold, JSON, de fleste API’er); Latin-1/Windows-1252 dukker stort set kun op i ældre Windows-tekstfiler eller gamle e-mail-headers.

Årsag 2: forkert byterækkefølge (endianness)

Denne rammer specifikt numeriske værdier på flere bytes (ikke tekst), men den er hyppig nok i hex-til-tekst-værktøjer, der håndterer blandede binær-/tekstdata, til at fortjene et navn. 00 01 læst big-endian er 1; de samme to bytes læst little-endian er 256. Hvis en hex-streng repræsenterer et numerisk længde-præfiks eller et binært felt indlejret i ellers tekstlige data, giver forkert byterækkefølge ikke bare et forkert tal — den forskyder hver eneste byteposition derefter, fordi værktøjet nu tror, teksten starter ved den forkerte offset.

Årsag 3: nibble-grupperingsfejl

Hex skal altid komme i par — to hex-cifre udgør én byte. Et ulige antal hex-tegn (et vildfarent ciffer, en copy-paste, der tabte et tegn, et indledende 0x, der ikke blev fjernet før parsing) forskyder hvert efterfølgende par med én nibble. Hver byte efter fejlen afkodes til et helt andet, urelateret tegn — outputtet er ikke “lidt forkert”, det er fuldstændig forvrænget fra det punkt og fremad. Det er faktisk en nyttig diagnose: volapyk, der starter rent og bryder sammen midt i strengen, peger på en grupperingsfejl netop dér — ikke et encoding-problem (som ødelægger mere ensartet hele vejen igennem).

Årsag 4: usynlige og ikke-printbare bytes

Ikke alle bytes mapper til et synligt tegn. Kontroltegn (0x00–0x1F), byte-order-mark (EF BB BF i UTF-8) og diverse Unicode-formateringstegn afkodes “korrekt”, men vises som ingenting, en boks eller et spørgsmålstegn afhængigt af skrifttypen — hvilket kan ligne en afkodningsfejl til forveksling, selvom konverteringen i sig selv var helt korrekt. Ser outputlængden rigtig ud, men teksten synes at mangle tegn, så tjek for kontrolbytes, før du antager, at afkodningslogikken er forkert.

En hurtig metode til at finde ud af, hvilken du står med

1. Bekræft, at hex-strengen har et lige antal tegn — hvis ikke, er det årsag 3; ret inputtet først.
2. Prøv at afkode som UTF-8 først, derefter Latin-1, og sammenlign — giver den ene ren tekst og den anden ikke, var det årsag 1.
3. Er outputtet forvansket ensartet fra allerførste tegn, så mistænk encoding (årsag 1); starter det rent og bryder sammen undervejs, så mistænk en grupperingsfejl (årsag 3) på netop den position.
4. Passer længden med forventningen, men bestemte tegn mangler eller vises som bokse, så tjek for kontrol-/formateringsbytes (årsag 4) i stedet for at tjekke encodingen igen.

Selve hex-til-tekst-konverteringen er én linje kode i ethvert sprog — det egentlige debug-arbejde ligger næsten altid i at finde ud af, hvilken af disse fire antagelser der i det stille var forkert, ikke i konverteringslogikken.