Неудачное преобразование шестнадцатеричного кода в текст: ошибки кодировки, превращающие байты в бессмысленный набор символов

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

Причина 1: предположение о неправильной кодировке символов

Самая распространённая причина. Шестнадцатеричные байты были закодированы в UTF-8 (где многие реальные символы занимают 2–4 байта), но конвертер декодирует их побайтно, как если бы это был Latin-1 или простой ASCII (где каждый байт соответствует ровно одному символу). Результат: буквы с диакритическими знаками, фигурные кавычки, длинные тире или любые неанглийские символы превращаются в два или три искажённых символа вместо одного правильного.

Решением всегда является декодирование с использованием той же кодировки, в которой байты были изначально записаны — если вы не знаете, какая это кодировка, UTF-8 является правильным значением по умолчанию для всего современного (веб-контент, JSON, большинство API); Latin-1/Windows-1252 в основном встречается только в старых текстовых файлах, созданных в Windows, или в устаревших заголовках электронных писем.

Причина 2: несоответствие порядка байтов (эндианности)

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

Причина 3: ошибки группировки нибблов

Шестнадцатеричные символы всегда должны идти парами — две шестнадцатеричные цифры составляют один байт. Нечётное количество шестнадцатеричных символов (одна лишняя цифра, копирование-вставка, при которой пропущен символ, начальные символы 0x, которые не были удалены перед разбором) сдвигает каждую последующую пару на один ниббл. Каждый байт после ошибки декодируется в совершенно другой, не имеющий отношения к тексту символ — результат не будет «слегка неверным», а полностью искажён с этого момента и далее, что на самом деле является полезным диагностическим признаком: мусор, который начинается чисто, но портится в середине строки, указывает на ошибку группировки именно в этой позиции, а не на проблему с неправильным кодированием (которая приводит к более равномерному повреждению по всей длине).

Причина 4: невидимые и непечатаемые байты

Не каждый байт сопоставляется с видимым символом. Управляющие символы (0x00–0x1F), маркер порядка байтов ( EF BB BF в UTF-8) и различные символы форматирования Unicode декодируются «успешно», но отображаются как пустое место, квадратик или вопросительный знак в зависимости от шрифта дисплея — что может выглядеть идентично сбою декодирования, даже если само преобразование прошло совершенно правильно. Если длина вывода выглядит правильно, но в тексте, похоже, отсутствуют символы, проверьте наличие управляющих байтов, прежде чем делать вывод о неверности логики декодирования.

Быстрый способ определить, с какой из причин вы имеете дело

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

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