Miért ad rossz karaktereket a bináris–szöveg konvertálásod

Egy 1-esekből és 0-kból álló string egyértelműnek tűnik — bináris, nincs mit értelmezni rajta. A gyakorlatban a bináris szöveggé alakítása pontosan ugyanabban a hibacsaládban bukik el, mint a hex–szöveg konvertálás, ugyanabból a mögöttes okból: egy bitsorozat addig nem szöveg, amíg nem hoztál meg több feltételezést arról, hogyan csoportosítod és értelmezed, és ha ezek közül bármelyik rossz, az kimenet egy konkrét, diagnosztizálható módon lesz hibás.

1. ok: rossz bitcsoportosítás (7 bit vs. 8 bit)

A szabványos ASCII-nak karakterenként csak 7 bit kell; a legtöbb bináris–szöveg eszköz 8 bites bájtokat feltételez alapból, mert a valós rendszereken így tárolódik a szöveg. Ha egy bináris string 7 bites csoportosítást feltételezve készült (egyes tankönyvi példák és régebbi rendszerek ma is ezt teszik), és 8 bites bájtokként dekódolod, minden egyes karakter eltolva jön ki — a csoportosítási határ a legelső bittől kezdve rossz, így a torzulás az egész kimeneten egyenletes, nem pedig tisztán indul és menet közben romlik el.

Az árulkodó jel: ha a kimenet szó szerint minden karaktere rossz, nem csak néhány, mindenek előtt a bitcsoportosítási feltételezést ellenőrizd.

2. ok: egy plusz vagy hiányzó bit mindent eltol maga után

Ez a páratlan hexjegy bináris megfelelője — egyetlen kósza 0 vagy 1 (másolás-beillesztésből származó extra karakter, kiesett számjegy, adatként értelmezett szóköz) minden azt követő csoport bájthatárát eltolja. Az 1. októl eltérően ez olyan szöveget ad, amely egy pontig helyes, utána zagyva — erős jel arra, hogy maga a bitszám csúszott el valahol a stringben, nem a kódolási séma rossz végig.

Először számold meg az összes bitet: a string hosszának 8 tiszta többszörösének kell lennie (vagy 7-nek, ha megerősítetted, hogy az a használt csoportosítás). Ha nem az, a plusz vagy hiányzó bit a hiba, nem a dekóder.

3. ok: karakterkódolás, pontosan úgy, mint a hexnél

Ha a bitek már helyesen bájtokba vannak csoportosítva, még mindig el kell döntened, mit jelentenek ezek a bájtértékek karakterként — UTF-8, ASCII, Latin-1. Ez azonos a hex–szöveg esettel: a többbájtos UTF-8 karakterek (ékezetes betűk, szimbólumok, nem latin írások) bájtoként dekódolva, mintha minden bájt önálló karakter lenne, egy helyes jel helyett két-három zagyva szimbólumot adnak. Ha a bitcsoportosítás bizonyítottan helyes (1. és 2. ok kizárva), és a kimenet kifejezetten a nem ASCII karakterek körül rossz, szinte mindig ez a megmaradó ok.

4. ok: endianness, ha a bináris számot reprezentál, nem szöveget

Ha a bináris string numerikus értéket kódol karakteradat helyett — hosszprefixet, ellenőrzőösszeget, szöveg mellé ágyazott azonosítót —, a bit-/bájtsorrend számít, és nincs univerzális alapértelmezés. A 00000001 önálló bájtként egyértelmű, de a többbájtos numerikus értékek tárolhatók a legjelentősebb vagy a legkevésbé jelentős bájttal elöl, attól függően, milyen rendszer állította elő őket — és rossz feltételezéssel olvasva csendben egy másik, hihetőnek tűnő rossz számot kapsz, nem nyilvánvaló hibát.

Diagnosztizálás sorrendben

1. Ellenőrizd, hogy az összes bit száma a feltételezett csoportosítás (általában 8) tiszta többszöröse-e — az elcsúszott szám a 2. okot jelenti; javítsd a bemenetet.
2. Ha minden karakter egyenletesen rossz a kezdettől, magára a csoportméretre gyanakodj (1. ok), mielőtt a kódoláshoz nyúlnál.
3. Ha a kimenet eleinte tiszta, és menet közben romlik el, az azon a pozíción lévő kósza/hiányzó bitre mutat (2. ok), nem kódolási problémára.
4. Ha a csoportosítás és a bitszám is rendben van, és csak a nem ASCII karakterek tűnnek rossznak, karakterkódolásról van szó (3. ok).
5. Ha az adat számot reprezentál szöveg helyett, és az érték hihetőnek tűnik, de rossz, a bájtsorrendet ellenőrizd (4. ok), mielőtt magát a konvertálási logikát hibáztatnád.

Ahogy a hexnél is, a konvertálási lépés triviális — az igazi hiba szinte mindig e négy feltételezés egyikében lakik, nem a konvertálást végző kódban.