CodeKitHub
Varför din binär-till-text-konvertering ger fel tecken

Varför din binär-till-text-konvertering ger fel tecken

Publicerad 24 juli 2026

En sträng av ettor och nollor ser entydig ut — det är binärt, det finns inget att tolka. I praktiken misslyckas konvertering från binärt till text på exakt samma sätt som hex-till-text gör, av samma underliggande skäl: en sekvens av bitar är inte text förrän du har gjort flera antaganden om hur den ska grupperas och tolkas, och att ha fel i något av dessa antaganden ger output som är fel på ett specifikt, diagnostiserbart sätt.

Orsak 1: fel bitgruppering (7-bit vs. 8-bit)

Vanlig ASCII behöver bara 7 bitar per tecken; de flesta binär-till-text-verktyg använder 8-bitars byte som standard eftersom det är så text faktiskt lagras på riktiga system. Om en binär sträng genererades med antagandet om 7-bitars gruppering (vissa läroboksexempel och äldre system gör fortfarande så) och du avkodar den som 8-bitars byte, blir varje enskilt tecken förskjutet — grupperingsgränsen är fel redan från första biten, så korruptionen är jämn genom hela outputen istället för att börja rent och sedan försämras.

Tecknet att leta efter: om bokstavligen varje tecken i outputen är fel, inte bara vissa, kontrollera antagandet om bitgruppering före allt annat.

Orsak 2: en extra eller saknad bit förskjuter allt efter den

Det här är den binära motsvarigheten till en udda hex-siffra — en enstaka felplacerad 0 eller 1 (ett extra tecken från en kopiering, en tappad siffra, blanksteg som tolkades som data) förskjuter bytegränsen för varje grupp efter den punkten. Till skillnad från orsak 1 ger detta text som är korrekt fram till en viss punkt och sedan förvrängd — ett starkt tecken på att det är själva bitantalet som är fel någonstans i strängen snarare än att kodningsschemat är fel genomgående.

Räkna det totala antalet bitar först: strängens längd bör vara en jämn multipel av 8 (eller 7, om du har bekräftat att det är den gruppering som används). Om inte, är den extra eller saknade biten buggen, inte avkodaren.

Orsak 3: teckenkodning, precis som med hex

När bitarna väl är korrekt grupperade i byte måste du fortfarande avgöra vad dessa bytevärden betyder som tecken — UTF-8, ASCII, Latin-1. Detta är identiskt med hex-till-text-fallet: multi-byte UTF-8-tecken (bokstäver med diakritiska tecken, symboler, icke-latinska skriftsystem) som avkodas en byte i taget som om varje byte vore sitt eget tecken ger två eller tre förvrängda symboler istället för ett korrekt. Om bitgrupperingen är bekräftat korrekt (orsak 1 och 2 uteslutna) och outputen fortfarande är fel specifikt kring icke-ASCII-tecken, är detta nästan alltid den återstående orsaken.

Orsak 4: byteordning (endianness), för binärt som representerar tal snarare än text

Om den binära strängen kodar ett numeriskt värde snarare än teckendata — en längdprefix, en checksumma, ett ID inbäddat tillsammans med text — spelar bit-/byteordning roll och det finns ingen universell standard. 00000001 som en fristående byte är entydigt, men multi-byte numeriska värden kan lagras med mest signifikanta byten först eller minst signifikanta byten först beroende på systemet som producerade dem, och att läsa det med fel antagande ger tyst ett annat, trovärdigt utseende men felaktigt tal istället för ett uppenbart fel.

Felsökning i ordning

  1. Kontrollera att det totala bitantalet är en jämn multipel av din antagna gruppering (8, oftast) — ett fel antal betyder orsak 2, fixa indatan.
  2. Om varje tecken är fel jämnt från början, misstänk själva grupperingsstorleken (orsak 1) innan du rör kodningen.
  3. Om outputen är ren till en början och sedan försämras, pekar det på en felplacerad/saknad bit vid den positionen (orsak 2), inte ett kodningsproblem.
  4. Om både gruppering och bitantal stämmer och bara icke-ASCII-tecken ser fel ut, är det teckenkodning (orsak 3).
  5. Om datan representerar ett tal snarare än text och värdet ser trovärdigt men fel ut, kontrollera byteordningen (orsak 4) innan du antar att själva konverteringslogiken är trasig.

Precis som med hex är själva konverteringssteget trivialt — den faktiska buggen finns nästan alltid i ett av dessa fyra antaganden, inte i koden som gör konverteringen.

← Tillbaka till bloggen