Dlaczego twoja konwersja binarna na tekst wypisuje niewłaściwe znaki

Ciąg jedynek i zer wygląda jednoznacznie — to binarne, nie ma czego interpretować. W praktyce konwersja binarna na tekst zawodzi dokładnie w tej samej rodzinie sposobów co konwersja hex na tekst, z tego samego powodu: sekwencja bitów nie jest tekstem, dopóki nie przyjmiesz kilku założeń co do grupowania i interpretacji, a błędne przyjęcie któregokolwiek z nich daje wynik błędny w konkretny, diagnozowalny sposób.

Przyczyna 1: niewłaściwe grupowanie bitów (7-bitowe vs 8-bitowe)

Standardowe ASCII potrzebuje tylko 7 bitów na znak; większość narzędzi binarne-na-tekst domyślnie używa 8-bitowych bajtów, ponieważ tak faktycznie przechowywany jest tekst w rzeczywistych systemach. Jeśli ciąg binarny wygenerowano zakładając grupowanie 7-bitowe (niektóre przykłady podręcznikowe i starsze systemy nadal tak robią), a dekodujesz go jako 8-bitowe bajty, każdy pojedynczy znak wychodzi przesunięty — granica grupowania jest błędna od pierwszego bitu, więc zniekształcenie jest jednolite w całym wyniku, zamiast zaczynać się czysto i degenerować w połowie.

Wskazówka: jeśli dosłownie każdy znak w wyniku jest błędny, nie tylko niektóre, sprawdź najpierw założenie dotyczące grupowania bitów.

Przyczyna 2: dodatkowy lub brakujący bit przesuwa wszystko po nim

To binarny odpowiednik nieparzystej cyfry hex — pojedynczy zabłąkany 0 lub 1 (dodatkowy znak z kopiuj-wklej, zgubiona cyfra, białe znaki sparsowane jako dane) przesuwa granicę bajtu dla każdej grupy po tym punkcie. W przeciwieństwie do przyczyny 1, daje to tekst poprawny do pewnego miejsca, a potem zniekształcony — silny sygnał, że to sama liczba bitów jest gdzieś w ciągu nie taka, a nie że schemat kodowania jest błędny w całości.

Policz najpierw łączną liczbę bitów: długość ciągu powinna być czystą wielokrotnością 8 (lub 7, jeśli potwierdziłeś, że takie grupowanie jest w użyciu). Jeśli nie jest, dodatkowy lub brakujący bit jest błędem, nie dekoderem.

Przyczyna 3: kodowanie znaków, dokładnie jak przy hex

Gdy bity są już poprawnie zgrupowane w bajty, nadal trzeba zdecydować, co te wartości bajtów znaczą jako znaki — UTF-8, ASCII, Latin-1. To identyczne z przypadkiem hex-na-tekst: wielobajtowe znaki UTF-8 (litery z akcentem, symbole, pisma niełacińskie) dekodowane bajt po bajcie, jakby każdy bajt był osobnym znakiem, dają dwa lub trzy zniekształcone symbole zamiast jednego poprawnego. Jeśli grupowanie bitów jest potwierdzone jako poprawne (przyczyny 1 i 2 wykluczone), a wynik nadal jest błędny konkretnie wokół znaków spoza ASCII, to niemal zawsze pozostała przyczyna.

Przyczyna 4: endianness, dla danych binarnych reprezentujących liczby, a nie tekst

Jeśli ciąg binarny koduje wartość liczbową, a nie dane znakowe — prefiks długości, sumę kontrolną, ID osadzone obok tekstu — kolejność bitów/bajtów ma znaczenie i nie ma uniwersalnej wartości domyślnej. 00000001 jako samodzielny bajt jest jednoznaczny, ale wielobajtowe wartości liczbowe mogą być przechowywane od najbardziej znaczącego bajtu lub od najmniej znaczącego, zależnie od systemu, który je wyprodukował, a odczytanie z niewłaściwym założeniem po cichu daje inną, wiarygodnie wyglądającą, ale błędną liczbę zamiast oczywistego błędu.

Diagnozowanie po kolei

Sprawdź, czy łączna liczba bitów jest czystą wielokrotnością zakładanego grupowania (zwykle 8) — nierówna liczba oznacza przyczynę 2, napraw wejście.
Jeśli każdy znak jest jednolicie błędny od samego początku, podejrzewaj rozmiar grupowania (przyczyna 1), zanim tkniesz kodowanie.
Jeśli wynik jest czysty na początku, a degeneruje się w połowie, to wskazuje na zabłąkany/brakujący bit w tym miejscu (przyczyna 2), nie na problem z kodowaniem.
Jeśli grupowanie i liczba bitów się zgadzają, a błędnie wyglądają tylko znaki spoza ASCII, to kodowanie znaków (przyczyna 3).
Jeśli dane reprezentują liczbę, a nie tekst, a wartość wygląda wiarygodnie, ale błędnie, sprawdź kolejność bajtów (przyczyna 4), zanim uznasz, że sama logika konwersji jest zepsuta.

Podobnie jak przy hex, sam krok konwersji jest trywialny — rzeczywisty błąd niemal zawsze tkwi w jednym z tych czterech założeń, nie w kodzie wykonującym konwersję.