Kad pretvorba iz hexa u tekst pođe po zlu: pogreške kodiranja koje bajtove pretvaraju u smeće

Pretvaranje hexa u tekst djeluje kao da bi trebalo biti nepogrešivo: svaki par hex znamenki jedan je bajt, bajt se preslika u znak, gotovo. U praksi to stalno zakazuje, i gotovo nikad zato što je pretvarač pokvaren — zakazuje zato što je hex samo način zapisivanja bajtova, a bajtovima treba dogovoreno kodiranje da bi uopće značili neki konkretan znak. Evo što zapravo ide po zlu kad je izlaz iskrivljen.

Uzrok 1: pretpostavljeno pogrešno kodiranje znakova

Daleko najčešći uzrok. Hex bajtovi kodirani su kao UTF-8 (gdje mnogi stvarni znakovi zauzimaju 2–4 bajta), ali pretvarač dekodira bajt po bajt kao da je riječ o Latin-1 ili čistom ASCII-ju (gdje je svaki bajt točno jedan znak). Rezultat: slova s dijakritikom, tipografski navodnici, crtice ili bilo koji ne-engleski znak pretvore se u dva ili tri iskrivljena simbola umjesto jednog ispravnog.

Popravak je uvijek dekodirati istim kodiranjem kojim su bajtovi izvorno zapisani — ako ne znate kojim, UTF-8 je ispravan zadani izbor za sve moderno (web sadržaj, JSON, većinu API-ja); Latin-1/Windows-1252 uglavnom se pojavljuje samo u starijim tekstualnim datotekama nastalim na Windowsima ili u naslijeđenim zaglavljima e-pošte.

Uzrok 2: neusklađen redoslijed bajtova (endianness)

Ovo posebno pogađa višebajtne numeričke vrijednosti (ne tekst), ali dovoljno je često u hex-u-tekst alatima koji obrađuju miješane binarno-tekstualne podatke da ga vrijedi imenovati. 00 01 pročitano kao big-endian je 1; ista dva bajta pročitana kao little-endian su 256. Ako hex string predstavlja numerički prefiks duljine ili binarno polje ugrađeno u inače tekstualne podatke, čitanje pogrešnim redoslijedom bajtova ne samo da pogrešno pročita broj — pomiče svaku poziciju bajta nakon njega, jer alat sada misli da tekst počinje na pogrešnom pomaku.

Uzrok 3: pogreške grupiranja nibbleova

Hex bi uvijek trebao dolaziti u parovima — dvije hex znamenke čine jedan bajt. Neparan broj hex znakova (jedna zalutala znamenka, copy-paste kojem je ispao znak, vodeći 0x koji nije uklonjen prije parsiranja) pomiče svaki sljedeći par za jedan nibble. Svaki bajt nakon pogreške dekodira se u potpuno drugačiji, nepovezani znak — izlaz nije “malo pogrešan”, nego potpuno izmiješan od te točke nadalje, što je zapravo koristan dijagnostički znak: smeće koje počinje čisto pa se negdje usred stringa raspadne upućuje na pogrešku grupiranja na točno tom mjestu, a ne na problem pogrešnog kodiranja (koje kvari ravnomjernije kroz cijeli tekst).

Uzrok 4: nevidljivi i neispisivi bajtovi

Ne preslikava se svaki bajt u vidljiv znak. Kontrolni znakovi (0x00–0x1F), byte-order-mark (EF BB BF u UTF-8) i razni Unicode znakovi za oblikovanje dekodiraju se “uspješno”, ali se prikazuju kao ništa, kvadratić ili upitnik ovisno o fontu — što može izgledati identično neuspjelom dekodiranju iako je sama pretvorba bila potpuno ispravna. Ako duljina izlaza izgleda ispravno, ali se čini da tekstu nedostaju znakovi, provjerite kontrolne bajtove prije nego što zaključite da je logika dekodiranja pogrešna.

Brz način da izolirate o kojem se radi

1. Provjerite ima li hex string paran broj znakova — ako nema, to je uzrok 3, prvo popravite ulaz.
2. Pokušajte dekodirati prvo kao UTF-8, zatim kao Latin-1, i usporedite — ako jedno daje čist tekst a drugo ne, bio je to uzrok 1.
3. Ako je izlaz ravnomjerno iskrivljen od prvog znaka, sumnjajte na kodiranje (uzrok 1); ako počinje čisto pa se raspada usred teksta, sumnjajte na pogrešku grupiranja (uzrok 3) na tom mjestu.
4. Ako duljina odgovara očekivanjima, ali pojedini znakovi nedostaju ili se prikazuju kao kvadratići, provjerite kontrolne/formatirajuće bajtove (uzrok 4) umjesto ponovnog provjeravanja kodiranja.

Sama pretvorba hexa u tekst jedan je redak koda u bilo kojem jeziku — pravi posao debugiranja gotovo je uvijek u otkrivanju koja je od ove četiri pretpostavke tiho bila pogrešna, a ne u logici pretvorbe.