Hvorfor binær-til-tekst-konverteringen din gir feil tegn ut

En streng med enere og nuller ser utvetydig ut — det er binært, det er ingenting å tolke. I praksis feiler binær-til-tekst-konvertering på nøyaktig samme familie av måter som heks-til-tekst gjør, av samme underliggende grunn: en sekvens med bits er ikke tekst før du har gjort flere antakelser om hvordan den skal grupperes og tolkes, og å ta feil i en av disse antakelsene gir en output som er feil på en spesifikk, diagnostiserbar måte.

Årsak 1: feil bitgruppering (7-bit vs. 8-bit)

Standard ASCII trenger bare 7 bit per tegn; de fleste binær-til-tekst-verktøy bruker som standard 8-bit bytes fordi det er slik tekst faktisk lagres på ekte systemer. Hvis en binær streng ble generert med antakelse om 7-bit gruppering (noen lærebokeksempler og eldre systemer gjør fortsatt dette) og du dekoder den som 8-bit bytes, kommer hvert eneste tegn ut forskjøvet — grupperingsgrensen er feil helt fra første bit, så korrupsjonen er jevn over hele output-en i stedet for å starte ren og forverres underveis.

Tegnet å se etter: hvis bokstavelig talt hvert tegn i output-en er feil, ikke bare noen, sjekk bitgrupperingsantakelsen før noe annet.

Årsak 2: en ekstra eller manglende bit forskyver alt etter den

Dette er det binære motstykket til et oddetalls heksadesimalt siffer — en enkelt villfaren 0 eller 1 (et ekstra tegn fra en kopier-lim, et bortfalt siffer, mellomrom som ble tolket som data) forskyver bytegrensen for hver gruppe etter det punktet. I motsetning til årsak 1 gir dette tekst som er korrekt frem til et punkt og forvrengt etterpå — et sterkt signal om at selve bitantallet er feil et sted i strengen, snarere enn at kodeskjemaet er feil gjennomgående.

Tell det totale antallet bits først: strenglengden bør være et rent multiplum av 8 (eller 7, hvis du har bekreftet at det er grupperingen som brukes). Hvis den ikke er det, er den ekstra eller manglende biten feilen, ikke dekoderen.

Årsak 3: tegnkoding, akkurat som med heks

Når bitene først er korrekt gruppert i bytes, må du fortsatt bestemme hva disse byteverdiene betyr som tegn — UTF-8, ASCII, Latin-1. Dette er identisk med heks-til-tekst-tilfellet: multi-byte UTF-8-tegn (bokstaver med aksenter, symboler, ikke-latinske skriftsystemer) dekodet én byte om gangen som om hver byte var sitt eget tegn, gir to eller tre forvrengte symboler i stedet for ett korrekt. Hvis bitgrupperingen er bekreftet korrekt (årsak 1 og 2 utelukket) og output-en fortsatt er feil spesifikt rundt ikke-ASCII-tegn, er dette nesten alltid den gjenværende årsaken.

Årsak 4: byte-rekkefølge (endianness), for binærtall som representerer tall snarere enn tekst

Hvis den binære strengen koder en numerisk verdi snarere enn tegndata — et lengdeprefiks, en sjekksum, en ID innebygd sammen med tekst — spiller bit-/byterekkefølgen en rolle, og det finnes ingen universell standard. 00000001 som en frittstående byte er utvetydig, men flerbyte numeriske verdier kan lagres med mest signifikant byte først eller minst signifikant byte først, avhengig av systemet som produserte dem, og å lese dem med feil antakelse gir stille et annet, plausibelt-utseende feil tall i stedet for en åpenbar feil.

Diagnostisering i rekkefølge

Sjekk at det totale bitantallet er et rent multiplum av din antatte gruppering (8, vanligvis) — et avvikende antall betyr årsak 2, fiks input.
Hvis hvert tegn er jevnt feil helt fra starten, mistenk selve grupperingsstørrelsen (årsak 1) før du rører kodingen.
Hvis output er ren i starten og forverres underveis, peker det ut en villfaren/manglende bit på det punktet (årsak 2), ikke et kodingsproblem.
Hvis både gruppering og bitantall stemmer og bare ikke-ASCII-tegn ser feil ut, er det tegnkoding (årsak 3).
Hvis dataene representerer et tall snarere enn tekst og verdien ser plausibel men feil ut, sjekk byterekkefølgen (årsak 4) før du antar at selve konverteringslogikken er ødelagt.

Som med heks er selve konverteringssteget trivielt — den faktiske feilen bor nesten alltid i en av disse fire antakelsene, ikke i koden som gjør konverteringen.