Når hex til tekst går galt: kodingsfeilene som gjør bytes til søppel

Å konvertere hex til tekst føles som noe som burde være idiotsikkert: hvert par av hex-sifre er én byte, koble byten til et tegn, ferdig. I praksis feiler det hele tiden, og nesten aldri fordi konvertereren er ødelagt — det feiler fordi hex bare er en måte å skrive bytes på, og bytes trenger en avtalt koding før de betyr noe spesifikt tegn i det hele tatt. Her er hva som faktisk går galt når resultatet er uleselig.

Årsak 1: feil tegnkoding antatt

Den desidert vanligste årsaken. Hex-bytene ble kodet som UTF-8 (der mange virkelige tegn tar 2–4 bytes), men konvertereren dekoder byte for byte som om det var Latin-1 eller ren ASCII (der hver byte er nøyaktig ett tegn). Resultatet: bokstaver med aksent, krøllete anførselstegn, tankestreker eller ethvert ikke-engelsk tegn blir til to eller tre forvrengte symboler i stedet for ett riktig.

Fiksen er alltid å dekode med den samme kodingen bytene opprinnelig ble skrevet i — vet du ikke hvilken, er UTF-8 riktig standardvalg for alt moderne (webinnhold, JSON, de fleste API-er); Latin-1/Windows-1252 dukker stort sett bare opp i eldre Windows-tekstfiler eller gamle e-posthoder.

Årsak 2: mismatch i byterekkefølge (endianness)

Denne rammer spesifikt numeriske verdier på flere bytes (ikke tekst), men den er vanlig nok i hex-til-tekst-verktøy som håndterer blandede binær-/tekstdata til at den fortjener et navn. 00 01 lest big-endian er 1; de samme to bytene lest little-endian er 256. Hvis en hex-streng representerer et numerisk lengdeprefiks eller et binærfelt innebygd i ellers tekstlige data, gjør feil byterekkefølge mer enn å feillese tallet — den forskyver hver byteposisjon etterpå, fordi verktøyet nå tror teksten starter på feil offset.

Årsak 3: grupperingsfeil på nibbler

Hex skal alltid komme i par — to hex-sifre utgjør én byte. Et oddetall hex-tegn (ett løst siffer, en kopiering som mistet et tegn, et innledende 0x som ikke ble fjernet før parsing) forskyver hvert påfølgende par med én nibble. Hver byte etter feilen dekodes til et helt annet, urelatert tegn — resultatet er ikke «litt feil», det er fullstendig forvrengt fra det punktet og utover, noe som faktisk er et nyttig diagnostisk tegn: søppel som starter rent og degenererer et stykke ut i strengen peker på en grupperingsfeil på nøyaktig den posisjonen, ikke et kodingsproblem (som ødelegger mer jevnt gjennom hele).

Årsak 4: usynlige og ikke-utskrivbare bytes

Ikke hver byte tilsvarer et synlig tegn. Kontrolltegn (0x00–0x1F), byte-order-mark (EF BB BF i UTF-8) og diverse Unicode-formateringstegn dekodes «vellykket», men vises som ingenting, en boks eller et spørsmålstegn avhengig av skjermfonten — noe som kan se identisk ut med en dekodingsfeil selv om selve konverteringen var helt korrekt. Ser lengden på resultatet riktig ut, men teksten later til å mangle tegn, sjekk for kontrollbytes før du antar at dekodelogikken er feil.

En rask måte å isolere hvilken du står overfor

1. Bekreft at hex-strengen har et partall antall tegn — hvis ikke, er det årsak 3; fiks inndataene først.
2. Prøv å dekode som UTF-8 først, deretter Latin-1, og sammenlign — gir den ene ren tekst og den andre ikke, var det årsak 1.
3. Er resultatet jevnt forvrengt fra aller første tegn, mistenk koding (årsak 1); starter det rent og degenererer et stykke ut, mistenk en grupperingsfeil (årsak 3) på den posisjonen.
4. Stemmer lengden med forventningene, men bestemte tegn mangler eller vises som bokser, sjekk for kontroll-/formateringsbytes (årsak 4) i stedet for å sjekke kodingen på nytt.

Selve hex-til-tekst-konverteringen er én linje kode i et hvilket som helst språk — det egentlige feilsøkingsarbeidet ligger nesten alltid i å finne ut hvilken av disse fire antakelsene som stille var feil, ikke i konverteringslogikken.