Miksi binääri-tekstimuunnoksesi tuottaa vääriä merkkejä

Ykkösten ja nollien jono näyttää yksiselitteiseltä — sehän on binääriä, ei siinä ole mitään tulkittavaa. Käytännössä binäärin muuntaminen tekstiksi epäonnistuu täsmälleen samalla tavalla kuin heksan muuntaminen tekstiksi, samasta taustasyystä: bittijono ei ole tekstiä ennen kuin olet tehnyt useita oletuksia siitä, miten se ryhmitellään ja tulkitaan, ja minkä tahansa näistä oletuksista mennessä väärin tulos on väärä tietyllä, diagnosoitavissa olevalla tavalla.

Syy 1: väärä bittiryhmittely (7-bittinen vs. 8-bittinen)

Standardi ASCII tarvitsee vain 7 bittiä per merkki; useimmat binääri-tekstityökalut käyttävät oletuksena 8-bittisiä tavuja, koska tekstiä säilytetään todellisissa järjestelmissä juuri niin. Jos binäärimerkkijono on tuotettu olettaen 7-bittinen ryhmittely (osa oppikirjaesimerkeistä ja vanhemmista järjestelmistä tekee näin edelleen) ja purat sen 8-bittisinä tavuina, jokainen ainoa merkki tulee ulos siirtyneenä — ryhmittelyn raja on väärässä kohdassa jo ensimmäisestä bitistä lähtien, joten vääristymä on tasainen koko tuloksen läpi eikä ala puhtaana ja huonone kesken.

Tunnusmerkki: jos kirjaimellisesti jokainen merkki tuloksessa on väärin, ei vain osa, tarkista bittiryhmittelyoletus ennen mitään muuta.

Syy 2: ylimääräinen tai puuttuva bitti siirtää kaiken sen jälkeisen

Tämä on binäärin vastine parittomalle heksanumerolle — yksittäinen ylimääräinen 0 tai 1 (ylimääräinen merkki kopioinnista, pudonnut numero, dataksi tulkittu välilyönti) siirtää tavurajaa jokaisessa ryhmässä kyseisen kohdan jälkeen. Toisin kuin syyssä 1, tämä tuottaa tekstiä, joka on oikein tiettyyn pisteeseen asti ja sotkeutuu sen jälkeen — vahva merkki siitä, että bittimäärä itsessään on väärä jossain merkkijonon kohdassa, ei koodaustapa läpikotaisin.

Laske bittien kokonaismäärä ensin: merkkijonon pituuden pitäisi olla siisti kahdeksan (tai seitsemän, jos olet vahvistanut sen olevan käytössä oleva ryhmittely) kerrannainen. Jos ei ole, ylimääräinen tai puuttuva bitti on bugi, ei purkaja.

Syy 3: merkistökoodaus, aivan kuten heksan tapauksessa

Kun bitit on ryhmitelty oikein tavuiksi, sinun täytyy silti päättää, mitä nämä tavuarvot tarkoittavat merkkeinä — UTF-8, ASCII, Latin-1. Tämä on identtinen heksa-tekstitapauksen kanssa: monitavuiset UTF-8-merkit (aksentilliset kirjaimet, symbolit, ei-latinalaiset kirjoitusjärjestelmät), jotka puretaan tavu kerrallaan ikään kuin jokainen tavu olisi oma merkkinsä, tuottavat kaksi tai kolme sotkeutunutta symbolia yhden oikean sijaan. Jos bittiryhmittely on vahvistettu oikeaksi (syyt 1 ja 2 suljettu pois) ja tulos on silti väärä nimenomaan ei-ASCII-merkkien kohdalla, tämä on lähes aina jäljellä oleva syy.

Syy 4: tavujärjestys (endianness), kun binääri esittää lukuja eikä tekstiä

Jos binäärimerkkijono koodaa numeerisen arvon eikä merkkidataa — pituusetuliitteen, tarkistussumman, tekstin ohessa upotetun ID:n — bitti-/tavujärjestyksellä on väliä eikä universaalia oletusta ole. 00000001 yksittäisenä tavuna on yksiselitteinen, mutta monitavuiset numeeriset arvot voidaan tallentaa merkitsevin tavu ensin tai vähiten merkitsevä tavu ensin riippuen ne tuottaneesta järjestelmästä, ja väärällä oletuksella lukeminen tuottaa hiljaisesti eri, uskottavalta näyttävän mutta väärän luvun sen sijaan että virhe olisi ilmeinen.

Diagnosointi järjestyksessä

1. Tarkista, että bittien kokonaismäärä on siisti oletetun ryhmittelysi (yleensä 8) kerrannainen — väärä määrä tarkoittaa syytä 2, korjaa syöte.
2. Jos jokainen merkki on väärin tasaisesti alusta asti, epäile ryhmittelykokoa itseään (syy 1) ennen kuin kosket koodaukseen.
3. Jos tulos on puhdas alussa ja huononee kesken, se osoittaa harha-/puuttuvan bitin tuossa kohdassa (syy 2), ei koodausongelmaa.
4. Jos ryhmittely ja bittimäärä ovat molemmat kunnossa ja vain ei-ASCII-merkit näyttävät väärältä, kyseessä on merkistökoodaus (syy 3).
5. Jos data esittää lukua eikä tekstiä ja arvo näyttää uskottavalta mutta väärältä, tarkista tavujärjestys (syy 4) ennen kuin oletat itse muunnoslogiikan olevan rikki.

Kuten heksankin kanssa, muunnosvaihe itsessään on triviaali — varsinainen bugi asuu lähes aina jossain näistä neljästä oletuksesta, ei muunnosta tekevässä koodissa.