Waarom je binair-naar-tekst-conversie de verkeerde tekens oplevert

Een reeks enen en nullen oogt ondubbelzinnig — het is binair, er valt niets te interpreteren. In de praktijk mislukt binair naar tekst omzetten op precies dezelfde familie van manieren als hex-naar-tekst, om dezelfde onderliggende reden: een reeks bits is pas tekst als je verschillende aannames hebt gedaan over hoe je haar groepeert en interpreteert, en één verkeerde aanname levert uitvoer op die op een specifieke, diagnosticeerbare manier fout is.

Oorzaak 1: verkeerde bitgroepering (7-bit vs. 8-bit)

Standaard ASCII heeft maar 7 bits per teken nodig; de meeste binair-naar-tekst-tools gaan standaard uit van 8-bit bytes, want zo wordt tekst op echte systemen daadwerkelijk opgeslagen. Is een binaire string gegenereerd met 7-bit groepen (sommige studieboekvoorbeelden en oudere systemen doen dit nog) en decodeer je hem als 8-bit bytes, dan komt elk afzonderlijk teken verschoven uit de bus — de groeperingsgrens zit vanaf de allereerste bit fout, dus de corruptie is gelijkmatig over de hele uitvoer in plaats van dat hij schoon begint en halverwege ontspoort.

Het verklikkersignaal: als letterlijk elk teken in de uitvoer fout is, niet slechts een deel, controleer dan eerst de aanname over bitgroepering.

Oorzaak 2: één bit te veel of te weinig verschuift alles erna

Dit is het binaire equivalent van een oneven hexcijfer — één losgeslagen 0 of 1 (een extra teken uit een copy-paste, een weggevallen cijfer, witruimte die als data is geparset) verschuift de bytegrens voor elke groep na dat punt. Anders dan bij oorzaak 1 levert dit tekst op die tot een bepaald punt correct is en daarna verhaspeld — een sterk signaal dat het bitaantal zelf ergens in de string niet klopt, in plaats van dat het encodingschema over de hele linie fout is.

Tel eerst het totale aantal bits: de stringlengte moet een net veelvoud van 8 zijn (of van 7, als je hebt bevestigd dat dat de gebruikte groepering is). Is dat niet zo, dan is de extra of ontbrekende bit de bug, niet de decoder.

Oorzaak 3: tekenencoding, precies zoals bij hex

Zodra de bits correct in bytes zijn gegroepeerd, moet je nog beslissen wat die bytewaarden als tekens betekenen — UTF-8, ASCII, Latin-1. Dit is identiek aan het hex-naar-tekst-geval: multi-byte UTF-8-tekens (letters met accenten, symbolen, niet-Latijnse schriften) die byte voor byte worden gedecodeerd alsof elke byte een eigen teken is, leveren twee of drie verhaspelde symbolen op in plaats van één correct teken. Is de bitgroepering aantoonbaar correct (oorzaak 1 en 2 uitgesloten) en is de uitvoer nog steeds fout, specifiek rond niet-ASCII-tekens, dan is dit vrijwel altijd de overgebleven oorzaak.

Oorzaak 4: endianness, bij binair dat getallen voorstelt in plaats van tekst

Codeert de binaire string een numerieke waarde in plaats van tekengegevens — een lengteprefix, een checksum, een ID naast tekst — dan doet bit-/bytevolgorde ertoe en bestaat er geen universele standaard. 00000001 als losse byte is ondubbelzinnig, maar numerieke waarden van meerdere bytes kunnen worden opgeslagen met de meest significante byte eerst of juist de minst significante byte eerst, afhankelijk van het systeem dat ze produceerde — en met de verkeerde aanname lezen levert stilletjes een ander, plausibel ogend fout getal op in plaats van een duidelijke fout.

Diagnosticeren in volgorde

1. Controleer of het totale bitaantal een net veelvoud is van je aangenomen groepering (meestal 8) — een afwijkend aantal betekent oorzaak 2; herstel de invoer.
2. Is elk teken vanaf het begin gelijkmatig fout, verdenk dan de groepsgrootte zelf (oorzaak 1) voordat je aan de encoding komt.
3. Is de uitvoer eerst schoon en ontspoort hij halverwege, dan wijst dat op een losse/ontbrekende bit op die positie (oorzaak 2), geen encodingprobleem.
4. Kloppen groepering en bitaantal allebei en zien alleen niet-ASCII-tekens er fout uit, dan is het de tekenencoding (oorzaak 3).
5. Stelt de data een getal voor in plaats van tekst en oogt de waarde plausibel maar fout, controleer dan de bytevolgorde (oorzaak 4) voordat je aanneemt dat de conversielogica zelf kapot is.

Net als bij hex is de conversiestap triviaal — de echte bug zit vrijwel altijd in een van deze vier aannames, niet in de code die het omzetten doet.