Hex tekstiksi -muunnos pieleen: enkoodausvirheet, jotka muuttavat tavut roskaksi

Hexin muuntaminen tekstiksi tuntuu siltä, että sen pitäisi olla idioottivarmaa: jokainen heksanumeropari on yksi tavu, kuvaa tavu merkiksi, valmis. Käytännössä se epäonnistuu jatkuvasti — eikä juuri koskaan siksi, että muunnin olisi rikki. Se epäonnistuu, koska hex on vain tapa kirjoittaa tavuja, ja tavut tarvitsevat yhteisesti sovitun enkoodauksen ennen kuin ne tarkoittavat mitään tiettyä merkkiä. Tässä se, mikä oikeasti menee pieleen, kun tulos on sekaisin.

Syy 1: oletettu väärä merkistökoodaus

Ylivoimaisesti yleisin syy. Hex-tavut enkoodattiin UTF-8:na (jossa monet oikean maailman merkit vievät 2–4 tavua), mutta muunnin dekoodaa tavu kerrallaan ikään kuin kyseessä olisi Latin-1 tai pelkkä ASCII (jossa jokainen tavu on tasan yksi merkki). Tulos: aksentilliset kirjaimet, kaarevat lainausmerkit, ajatusviivat ja kaikki ei-englantilaiset merkit muuttuvat kahdeksi tai kolmeksi sekavaksi symboliksi yhden oikean sijaan.

Korjaus on aina dekoodata samalla enkoodauksella, jolla tavut alun perin kirjoitettiin — jos et tiedä millä, UTF-8 on oikea oletus kaikkeen moderniin (verkkosisältö, JSON, useimmat API:t); Latin-1/Windows-1252 näkyy lähinnä vain vanhemmissa Windows-peräisissä tekstitiedostoissa tai legacy-sähköpostiotsakkeissa.

Syy 2: tavujärjestyksen (endianness) ristiriidat

Tämä koskee erityisesti monitavuisia numeerisia arvoja (ei tekstiä), mutta se on riittävän yleinen hex-tekstiksi-työkaluissa, jotka käsittelevät binäärin ja tekstin sekadataa, että se kannattaa mainita. 00 01 big-endian-järjestyksessä luettuna on 1; samat kaksi tavua little-endian-järjestyksessä on 256. Jos hex-merkkijono edustaa numeerista pituusetuliitettä tai binäärikenttää muuten tekstimuotoisen datan seassa, väärällä tavujärjestyksellä lukeminen ei vain tulkitse lukua väärin — se siirtää jokaista sen jälkeistä tavupaikkaa, koska työkalu luulee nyt tekstin alkavan väärästä kohdasta.

Syy 3: nibble-ryhmittelyvirheet

Hexin pitäisi aina tulla pareina — kaksi heksanumeroa muodostaa yhden tavun. Pariton määrä heksamerkkejä (yksi eksynyt numero, kopiointi joka pudotti merkin, 0x-etuliite jota ei poistettu ennen jäsentämistä) siirtää jokaista seuraavaa paria yhden nibblen verran. Jokainen virheen jälkeinen tavu dekoodautuu täysin eri, asiaan liittymättömäksi merkiksi — tulos ei ole “hieman väärin” vaan täysin sekaisin siitä kohdasta eteenpäin. Tämä on itse asiassa hyödyllinen diagnoosi: roska, joka alkaa puhtaana ja hajoaa kesken merkkijonon, viittaa ryhmittelyvirheeseen juuri siinä kohdassa, ei väärään enkoodaukseen (joka sotkee tasaisemmin koko matkalta).

Syy 4: näkymättömät ja tulostumattomat tavut

Jokainen tavu ei kuvaudu näkyväksi merkiksi. Ohjausmerkit (0x00–0x1F), byte-order-mark (EF BB BF UTF-8:ssa) ja erilaiset Unicoden muotoilumerkit dekoodautuvat “onnistuneesti” mutta näkyvät tyhjänä, laatikkona tai kysymysmerkkinä näyttöfontista riippuen — mikä voi näyttää identtiseltä dekoodausvirheen kanssa, vaikka muunnos itsessään oli täysin oikein. Jos tulosteen pituus näyttää oikealta mutta tekstistä tuntuu puuttuvan merkkejä, tarkista ohjaustavut ennen kuin oletat dekoodauslogiikan olevan väärin.

Nopea tapa selvittää, mistä näistä on kyse

Varmista, että hex-merkkijonossa on parillinen määrä merkkejä — jos ei, kyseessä on syy 3; korjaa ensin syöte.
Kokeile dekoodata ensin UTF-8:na, sitten Latin-1:nä, ja vertaa — jos toinen tuottaa siistiä tekstiä ja toinen ei, kyseessä oli syy 1.
Jos tulos on tasaisesti sekaisin heti ensimmäisestä merkistä, epäile enkoodausta (syy 1); jos se alkaa puhtaana ja hajoaa kesken matkan, epäile ryhmittelyvirhettä (syy 3) siinä kohdassa.
Jos pituus vastaa odotuksia mutta tietyt merkit puuttuvat tai näkyvät laatikkoina, tarkista ohjaus- ja muotoilutavut (syy 4) sen sijaan, että tarkistaisit enkoodauksen uudelleen.

Hex-tekstiksi-muunnos itsessään on yksi rivi koodia millä tahansa kielellä — varsinainen debuggaustyö on lähes aina sen selvittämistä, mikä näistä neljästä oletuksesta oli hiljaisesti väärin, ei muunnoslogiikassa.