Konwersja hex na tekst poszła źle: błędy kodowania, które zamieniają bajty w bełkot

Konwersja hex na tekst z pozoru wydaje się niezawodna: każda para cyfr szesnastkowych to jeden bajt, zmapuj bajt na znak i gotowe. W praktyce zawodzi to bez przerwy, i prawie nigdy nie dlatego, że konwerter jest zepsuty — zawodzi, ponieważ hex to po prostu sposób zapisu bajtów, a bajty potrzebują uzgodnionego kodowania, zanim będą w ogóle znaczyć jakikolwiek konkretny znak. Oto co naprawdę idzie nie tak, gdy wynik jest zniekształcony.

Przyczyna 1: przyjęto niewłaściwe kodowanie znaków

Zdecydowanie najczęstsza przyczyna. Bajty hex zostały zakodowane jako UTF-8 (gdzie wiele rzeczywistych znaków zajmuje 2–4 bajty), ale konwerter dekoduje bajt po bajcie tak, jakby to był Latin-1 albo zwykłe ASCII (gdzie każdy bajt to dokładnie jeden znak). Rezultat: litery z akcentem, cudzysłowy typograficzne, pauzy em lub jakikolwiek znak spoza angielskiego zamieniają się w dwa lub trzy zniekształcone symbole zamiast jednego poprawnego.

Naprawa zawsze polega na dekodowaniu tym samym kodowaniem, w jakim bajty zostały pierwotnie zapisane — jeśli nie wiadomo którym, UTF-8 jest właściwym domyślnym wyborem dla wszystkiego nowoczesnego (treści webowe, JSON, większość API); Latin-1/Windows-1252 pojawia się głównie w starszych plikach tekstowych pochodzących z Windows lub przestarzałych nagłówkach e-maili.

Przyczyna 2: niezgodność kolejności bajtów (endianness)

Ta konkretnie dotyczy wielobajtowych wartości liczbowych (nie tekstu), ale jest na tyle częsta w narzędziach hex-na-tekst obsługujących mieszane dane binarno-tekstowe, że warto ją wymienić. 00 01 odczytane big-endian to 1; te same dwa bajty odczytane little-endian to 256. Jeśli ciąg hex reprezentuje liczbowy prefiks długości lub pole binarne osadzone w skądinąd tekstowych danych, odczytanie go z niewłaściwą kolejnością bajtów nie tylko błędnie odczytuje liczbę — zaburza każdą pozycję bajtu po niej, ponieważ narzędzie sądzi teraz, że tekst zaczyna się w złym miejscu.

Przyczyna 3: błędy grupowania nibbli

Hex powinien zawsze występować w parach — dwie cyfry szesnastkowe tworzą jeden bajt. Nieparzysta liczba znaków hex (jedna zabłąkana cyfra, kopiuj-wklej, które zgubiło znak, wiodące 0x nieusunięte przed parsowaniem) przesuwa każdą kolejną parę o jeden nibble. Każdy bajt po błędzie dekoduje się na zupełnie inny, niepowiązany znak — wynik nie jest „lekko błędny”, jest całkowicie pomieszany od tego miejsca w dół, co jest właściwie użyteczną wskazówką diagnostyczną: bełkot, który zaczyna się czysto, a degeneruje w połowie ciągu, wskazuje na błąd grupowania w tym dokładnie miejscu, a nie na problem z niewłaściwym kodowaniem (który psuje wszystko bardziej jednolicie).

Przyczyna 4: niewidoczne i niedrukowalne bajty

Nie każdy bajt mapuje się na widoczny znak. Znaki kontrolne (0x00–0x1F), znacznik kolejności bajtów (EF BB BF w UTF-8) oraz różne unikodowe znaki formatujące dekodują się „pomyślnie”, ale renderują się jako nic, kwadrat lub znak zapytania, w zależności od czcionki wyświetlania — co może wyglądać identycznie jak błąd dekodowania, mimo że sama konwersja była całkowicie poprawna. Jeśli długość wyniku wygląda prawidłowo, ale w tekście brakuje znaków, sprawdź bajty kontrolne, zanim uznasz, że logika dekodowania jest błędna.

Szybki sposób na wyizolowanie, z którą przyczyną masz do czynienia

1. Potwierdź, że ciąg hex ma parzystą liczbę znaków — jeśli nie, to przyczyna 3, najpierw napraw wejście.
2. Spróbuj zdekodować najpierw jako UTF-8, potem jako Latin-1 i porównaj — jeśli jedno daje czysty tekst, a drugie nie, to była przyczyna 1.
3. Jeśli wynik jest jednolicie zniekształcony od samego pierwszego znaku, podejrzewaj kodowanie (przyczyna 1); jeśli zaczyna się czysto, a degeneruje w połowie, podejrzewaj błąd grupowania (przyczyna 3) w tym miejscu.
4. Jeśli długość zgadza się z oczekiwaniami, ale konkretne znaki brakują lub pokazują się jako kwadraty, sprawdź bajty kontrolne/formatujące (przyczyna 4), zamiast ponownie sprawdzać kodowanie.

Sama konwersja hex na tekst to jedna linijka kodu w dowolnym języku — rzeczywista praca debugowania niemal zawsze polega na ustaleniu, które z tych czterech założeń zostało po cichu błędne, a nie na logice konwersji.