Kad hex uz tekstu konvertēšana noiet greizi: kodēšanas kļūdas, kas baitus pārvērš draņķī

Šķiet, ka hex konvertēšanai uz tekstu vajadzētu būt drošai pret kļūdām: katrs hex ciparu pāris ir viens baits, baitu attēlojam kā rakstzīmi, gatavs. Praksē tas neizdodas nemitīgi, un gandrīz nekad tāpēc, ka konvertētājs būtu bojāts — tas neizdodas tāpēc, ka hex ir tikai veids, kā pierakstīt baitus, un baitiem vajadzīgs saskaņots kodējums, pirms tie vispār apzīmē kādu konkrētu rakstzīmi. Lūk, kas patiesībā notiek, kad izvade ir sakropļota.

1. cēlonis: pieņemts nepareizs rakstzīmju kodējums

Viens visbiežākais cēlonis. Hex baiti tika kodēti kā UTF-8 (kur daudzas reālas rakstzīmes aizņem 2–4 baitus), bet konvertētājs dekodē pa baitam, it kā tas būtu Latin-1 vai vienkāršs ASCII (kur katrs baits ir tieši viena rakstzīme). Rezultāts: burti ar diakritiskajām zīmēm, izliektās pēdiņas, garās domuzīmes vai jebkura ne-angļu rakstzīme pārvēršas divos vai trijos sakropļotos simbolos vienas pareizas vietā.

Labojums vienmēr ir dekodēt ar to pašu kodējumu, kādā baiti sākotnēji tika rakstīti — ja nezināt, kurš tas ir, UTF-8 ir pareizais noklusējums visam modernajam (tīmekļa saturs, JSON, vairums API); Latin-1/Windows-1252 pārsvarā parādās tikai vecākos Windows izcelsmes teksta failos vai mantotos e-pasta galvenēs.

2. cēlonis: baitu secības (endianness) nesakritība

Šis skar tieši daudzbaitu skaitliskās vērtības (ne tekstu), bet hex-uz-tekstu rīkos, kas apstrādā jauktus binārus/teksta datus, tas ir pietiekami bieži, lai to nosauktu. 00 01, lasīts big-endian, ir 1; tie paši divi baiti, lasīti little-endian, ir 256. Ja hex virkne satur skaitlisku garuma prefiksu vai bināru lauku, kas iegults citādi tekstuālos datos, tā nolasīšana nepareizā baitu secībā ne tikai kļūdaini nolasa skaitli — tā nobīda katru nākamo baita pozīciju, jo rīks tagad domā, ka teksts sākas nepareizā nobīdē.

3. cēlonis: nibblu grupēšanas kļūdas

Hex vienmēr jānāk pāros — divi hex cipari veido vienu baitu. Nepāra hex rakstzīmju skaits (viens lieks cipars, kopēšana, kurā pazuda rakstzīme, 0x prefikss, kas pirms parsēšanas netika noņemts) nobīda katru nākamo pāri par vienu nibblu. Katrs baits pēc kļūdas dekodējas par pilnīgi citu, nesaistītu rakstzīmi — izvade nav “nedaudz nepareiza”, tā no šī punkta ir pilnībā sajaukta, kas patiesībā ir noderīga diagnostika: draņķis, kas sākas tīri un sabojājas virknes vidū, norāda uz grupēšanas kļūdu tieši tajā pozīcijā, nevis uz nepareiza kodējuma problēmu (kas bojā vienmērīgāk visā garumā).

4. cēlonis: neredzami un nedrukājami baiti

Ne katrs baits atbilst redzamai rakstzīmei. Vadības rakstzīmes (0x00–0x1F), baitu secības marķieris (EF BB BF UTF-8) un dažādas Unicode formatēšanas rakstzīmes dekodējas “veiksmīgi”, bet atkarībā no attēlošanas fonta tiek renderētas kā nekas, kastīte vai jautājuma zīme — kas var izskatīties identiski dekodēšanas kļūmei, lai gan pati konvertēšana bija pilnīgi pareiza. Ja izvades garums izskatās pareizs, bet tekstā šķietami trūkst rakstzīmju, pārbaudiet vadības baitus, pirms pieņemat, ka dekodēšanas loģika ir nepareiza.

Ātrs veids, kā noteikt, ar kuru no tiem jums ir darīšana

1. Pārliecinieties, ka hex virknē ir pāra skaits rakstzīmju — ja nav, tas ir 3. cēlonis; vispirms izlabojiet ievadi.
2. Mēģiniet dekodēt vispirms kā UTF-8, tad kā Latin-1, un salīdziniet — ja viens dod tīru tekstu, bet otrs ne, tas bija 1. cēlonis.
3. Ja izvade ir vienmērīgi sakropļota no pašas pirmās rakstzīmes, aizdomas krīt uz kodējumu (1. cēlonis); ja tā sākas tīri un sabojājas vidū, aizdomas krīt uz grupēšanas kļūdu (3. cēlonis) tajā pozīcijā.
4. Ja garums atbilst gaidītajam, bet konkrētas rakstzīmes trūkst vai rādās kā kastītes, pārbaudiet vadības/formatēšanas baitus (4. cēlonis), nevis vēlreiz kodējumu.

Pati hex-uz-tekstu konvertēšana jebkurā valodā ir viena koda rindiņa — īstais atkļūdošanas darbs gandrīz vienmēr ir noskaidrot, kurš no šiem četriem pieņēmumiem klusībā bija nepareizs, nevis konvertēšanas loģikā.