Hvorfor din binær-til-tekst-konvertering giver de forkerte tegn

En streng af 1-taller og 0-er ser entydig ud — det er binært, der er intet at fortolke. I praksis fejler binær-til-tekst-konvertering på præcis samme familie af måder som hex-til-tekst, af den samme underliggende grund: en sekvens af bits er ikke tekst, før du har foretaget flere antagelser om, hvordan den skal grupperes og fortolkes, og hvis du tager fejl i bare én af de antagelser, giver det et output, der er forkert på en specifik, diagnosticerbar måde.

Årsag 1: forkert bit-gruppering (7-bit vs. 8-bit)

Standard-ASCII skal kun bruge 7 bit pr. tegn; de fleste binær-til-tekst-værktøjer bruger som standard 8-bit bytes, fordi det er sådan, tekst faktisk gemmes på rigtige systemer. Hvis en binær streng blev genereret ud fra en antagelse om 7-bit-grupperinger (nogle lærebogseksempler og ældre systemer gør stadig det), og du dekoder den som 8-bit bytes, kommer hvert eneste tegn ud forskudt — grupperingsgrænsen er forkert helt fra den første bit, så korruptionen er ensartet over hele outputtet i stedet for at starte rent og forringes hen ad vejen.

Kendetegnet: hvis bogstaveligt talt hvert tegn i outputtet er forkert, ikke bare nogle, så tjek bit-grupperingsantagelsen, før du gør noget andet.

Årsag 2: en ekstra eller manglende bit forskyder alt derefter

Det her er den binære pendant til et ulige hex-ciffer — en enkelt overflødig 0 eller 1 (et ekstra tegn fra en copy-paste, et tabt ciffer, mellemrum der blev parset som data) forskyder byte-grænsen for hver gruppe efter det punkt. I modsætning til årsag 1 giver det tekst, der er korrekt indtil et vist punkt og forvrænget derefter — et stærkt signal om, at selve bit-antallet er forkert et sted i strengen, snarere end at encoding-skemaet er forkert hele vejen igennem.

Tæl det samlede antal bits først: strengens længde bør være et rent multiplum af 8 (eller 7, hvis du har bekræftet, at det er den gruppering, der bruges). Hvis det ikke er tilfældet, er den ekstra eller manglende bit fejlen, ikke dekoderen.

Årsag 3: tegn-encoding, nøjagtig som med hex

Når bitsene først er korrekt grupperet i bytes, skal du stadig afgøre, hvad de byte-værdier betyder som tegn — UTF-8, ASCII, Latin-1. Det er identisk med hex-til-tekst-tilfældet: multi-byte UTF-8-tegn (bogstaver med accenter, symboler, ikke-latinske skriftsystemer) dekodet én byte ad gangen, som om hver byte var sit eget tegn, giver to eller tre forvrængede symboler i stedet for ét korrekt. Hvis bit-grupperingen er bekræftet korrekt (årsag 1 og 2 udelukket), og outputtet stadig er forkert specifikt omkring ikke-ASCII-tegn, er dette næsten altid den resterende årsag.

Årsag 4: byte-rækkefølge (endianness), for binært der repræsenterer tal frem for tekst

Hvis den binære streng koder en numerisk værdi frem for tegndata — en længdeangivelse, en checksum, et ID indlejret sammen med tekst — betyder bit-/byte-rækkefølge noget, og der findes ingen universel standard. 00000001 som en enkeltstående byte er entydig, men multi-byte numeriske værdier kan gemmes med den mest signifikante byte først eller den mindst signifikante byte først, afhængigt af hvilket system der producerede dem, og at læse den med den forkerte antagelse giver stille og roligt et andet, plausibelt udseende, men forkert tal, i stedet for en åbenlys fejl.

Diagnosticering i rækkefølge

1. Tjek at det samlede antal bits er et rent multiplum af din antagne gruppering (typisk 8) — et forkert antal betyder årsag 2, ret input.
2. Hvis hvert tegn er forkert ensartet fra starten, mistænk selve grupperingsstørrelsen (årsag 1), før du rører ved encodingen.
3. Hvis output er rent i starten og forringes undervejs, peger det direkte på en overflødig/manglende bit på det tidspunkt (årsag 2), ikke et encoding-problem.
4. Hvis gruppering og bit-antal begge stemmer, og kun ikke-ASCII-tegn ser forkerte ud, er det tegn-encoding (årsag 3).
5. Hvis dataen repræsenterer et tal frem for tekst, og værdien ser plausibel, men forkert ud, tjek byte-rækkefølge (årsag 4), før du antager, at selve konverteringslogikken er i stykker.

Som med hex er selve konverteringstrinnet trivielt — den egentlige fejl bor næsten altid i én af disse fire antagelser, ikke i koden, der udfører konverteringen.