Чому конвертація з двійкового коду в текст видає неправильні символи

Рядок з одиниць і нулів виглядає однозначно — це двійковий код, тут начебто нічого інтерпретувати. На практиці конвертація з двійкового коду в текст ламається точно так само, як і конвертація з hex у текст, з тієї ж причини: послідовність бітів не є текстом, поки ви не зробили кілька припущень про те, як її групувати й інтерпретувати, і якщо хоча б одне з цих припущень помилкове, результат буде неправильним конкретним, діагностованим способом.

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

Стандартному ASCII потрібно лише 7 бітів на символ; більшість інструментів для конвертації двійкового коду в текст за замовчуванням використовують 8-бітні байти, бо саме так текст реально зберігається в системах. Якщо двійковий рядок було згенеровано з припущенням про 7-бітне групування (деякі приклади з підручників і старіші системи досі так роблять), а ви декодуєте його як 8-бітні байти, кожен символ виходить зі зсувом — межа групування неправильна вже з першого біта, тому спотворення однорідне по всьому виводу, а не починається чисто і псується десь посередині.

Ознака: якщо буквально кожен символ у результаті неправильний, а не лише частина, спершу перевіряйте припущення про групування бітів, а вже потім усе інше.

Причина 2: зайвий або відсутній біт зсуває все, що йде далі

Це двійковий еквівалент непарної кількості шістнадцяткових цифр — один зайвий чи відсутній 0 або 1 (зайвий символ через копіювання-вставлення, пропущена цифра, пробіл, який розпізнався як дані) зсуває межу байта для кожної групи після цієї точки. На відміну від причини 1, це дає текст, який правильний до певного моменту й спотворений після нього — сильна ознака того, що проблема саме в кількості бітів у рядку, а не в самій схемі кодування.

Спершу порахуйте загальну кількість бітів: довжина рядка має бути точно кратна 8 (або 7, якщо ви підтвердили, що використовується саме таке групування). Якщо це не так, зайвий чи відсутній біт — це і є баг, а не декодер.

Причина 3: кодування символів, так само як і з hex

Коли біти вже правильно згруповані в байти, все одно потрібно вирішити, що ці значення байтів означають як символи — UTF-8, ASCII, Latin-1. Це ідентично випадку з hex-у-текст: багатобайтові символи UTF-8 (літери з діакритичними знаками, символи, нелатинські писемності), декодовані побайтово, ніби кожен байт — це окремий символ, дають два-три спотворені символи замість одного правильного. Якщо групування бітів підтверджено правильне (причини 1 і 2 виключені), а результат все одно неправильний саме навколо символів поза ASCII — майже завжди залишається саме ця причина.

Причина 4: порядок байтів, для двійкового коду, що представляє числа, а не текст

Якщо двійковий рядок кодує числове значення, а не символьні дані — префікс довжини, контрольну суму, ідентифікатор, вбудований поряд із текстом — порядок бітів/байтів має значення, і універсального стандарту немає. 00000001 як окремий байт однозначний, але багатобайтові числові значення можуть зберігатися як від старшого байта до молодшого, так і навпаки, залежно від системи, що їх створила, і читання з неправильним припущенням мовчки дає інше, правдоподібне на вигляд, але неправильне число замість очевидної помилки.

Діагностика по порядку

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

Як і з hex, сам крок конвертації тривіальний — реальний баг майже завжди ховається в одному з цих чотирьох припущень, а не в коді, що виконує конвертацію.