Почему при преобразовании двоичного кода в текст выводятся неверные символы

Последовательность единиц и нулей выглядит однозначно — это двоичный код, и интерпретировать здесь нечего. На практике преобразование двоичного кода в текст заканчивается неудачей точно так же, как и преобразование шестнадцатеричного кода в текст, по той же самой причине: последовательность битов не является текстом, пока вы не сделаете несколько допущений о том, как её группировать и интерпретировать, и ошибка в любом из этих допущений приводит к выводу, который является неправильным конкретным и диагностируемым образом.

Причина 1: неправильная группировка битов (7-битные против 8-битных)

Стандартный ASCII требует всего 7 бит на символ; большинство инструментов для преобразования двоичного кода в текст по умолчанию используют 8-битные байты, поскольку именно так текст фактически хранится в реальных системах. Если двоичная строка была сгенерирована с учетом 7-битных групп (в некоторых учебниках и старых системах это до сих пор так делается), а вы декодируете её как 8-битные байты, то каждый символ будет сдвинут — граница группировки неверна с самого первого бита, поэтому повреждение будет равномерным по всему выводу, а не начинаться с исправного текста и ухудшаться по ходу.

Признак: если буквально каждый символ в выводе неверный, а не только некоторые, прежде всего проверьте допущение о группировке битов.

Причина 2: лишний или отсутствующий бит сдвигает всё, что находится после него

Это двоичный эквивалент нечетной шестнадцатеричной цифры — один-единственный лишний 0 или 1 (лишний символ при копировании-вставке, пропущенная цифра, пробел, который был интерпретирован как данные) сдвигает границу байта для каждой группы после этой точки. В отличие от причины 1, это приводит к тексту, который до определённого момента правильный, а далее искажён — явный признак того, что проблема заключается в неверном подсчёте количества битов в какой-то части строки, а не в том, что схема кодирования неверна на протяжении всей строки.

Сначала подсчитайте общее количество битов: длина строки должна быть кратной 8 (или 7, если вы убедились, что именно такая группировка используется). Если это не так, то причиной ошибки является лишний или недостающий бит, а не декодер.

Причина 3: кодировка символов, точно так же, как и в случае с шестнадцатеричным кодом

После того как биты правильно сгруппированы в байты, вам всё равно нужно определить, что означают эти значения байтов в качестве символов — UTF-8, ASCII, Latin-1. Это идентично случаю с преобразованием шестнадцатеричного кода в текст: многобайтовые символы UTF-8 (буквы с диакритическими знаками, символы, нелатинские алфавиты), декодируемые по одному байту за раз, как если бы каждый байт был отдельным символом, приводят к появлению двух или трёх искажённых символов вместо одного правильного. Если правильность группировки битов подтверждена (причины 1 и 2 исключены), а результат по-прежнему неверный, особенно в отношении не-ASCII-символов, то почти всегда причиной является именно это.

Причина 4: порядок байтов (endianness) для двоичных данных, представляющих числа, а не текст

Если двоичная строка кодирует числовое значение, а не символьные данные — префикс длины, контрольную сумму, идентификатор, встроенный в текст — порядок битов/байтов имеет значение, и универсального значения по умолчанию не существует. 00000001 в качестве отдельного байта не вызывает неоднозначности, но многобайтовые числовые значения могут храниться с самым старшим байтом впереди или с самым младшим байтом впереди в зависимости от системы, в которой они были сгенерированы, и чтение с неверным допущением незаметно приводит к получению другого, правдоподобно выглядящего, но неверного числа, а не к очевидной ошибке.

Последовательность диагностики

Проверьте, является ли общее количество битов чистым кратным предполагаемой группировки (обычно 8) — несоответствие означает причину 2, исправьте входные данные.
Если все символы одинаково неверны с самого начала, прежде чем обращаться к кодировке, подозревайте сам размер группировки (причина 1).
Если вывод сначала корректный, а затем ухудшается на определенном участке, это указывает на случайный/пропущенный бит в этой позиции (причина 2), а не на проблему с кодировкой.
Если и группировка, и количество битов в порядке, а неправильно отображаются только не-ASCII-символы, дело в кодировке символов (причина 3).
Если данные представляют собой число, а не текст, и значение выглядит правдоподобно, но неверно, проверьте порядок байтов (причина 4), прежде чем предполагать, что сама логика преобразования не работает.

Как и в случае с шестнадцатеричным кодом, этап преобразования тривиален — фактическая ошибка почти всегда кроется в одном из этих четырёх допущений, а не в коде, выполняющем преобразование.