Разделите полезную нагрузку на три уровня
Главная ошибка при работе с двоичными сообщениями состоит в том, что текстовую оболочку принимают за формат данных. Сначала зафиксируйте источник, границы сообщения и ожидаемого потребителя: структурированные значения сериализуются в байты, а байты иногда дополнительно упаковываются Base64, ASCII85, Base91 или шестнадцатеричным экранированием. Каждый уровень нужно сохранять отдельно, особенно если внутренний формат ещё не подтверждён документацией.
Подготовьте повторяемый эталонный образец. В нём должны быть обычный текст, символы вне ASCII, дробные числа, null, нулевые байты, вложенные объекты и массивы. Запишите исходную длину и несколько контрольных шестнадцатеричных фрагментов: они помогут отличить ошибку сериализации от ошибки доставки.
Сначала снимите транспортную оболочку
Если протокол явно называет внешнее представление, примените соответствующий преобразователь и получите исходные байты. Когда источник неясен, сохраняйте доказательства и проверяйте полноту кандидата, а не делайте вывод по одному набору символов. Успешное декодирование Base64 ещё не говорит, что внутри находится JSON: там может быть Protobuf, CBOR или прикладной двоичный кадр.
Внутренний формат выбирают только после анализа байтов, документации отправителя, типа содержимого, schema или кода получателя. Для форматов со schema версия, номера полей и значения по умолчанию являются частью контракта. Их нельзя заменять догадками при конвертации.
Проверьте смысл данных и границы байтов
Преобразуйте эталонный образец в целевой формат и восстановите его обратно в проверяемое представление. Сначала сравните бизнес-смысл: наличие полей, типы, точность чисел, Unicode, null, порядок массивов и вложенность. Затем проверьте границы: длину сообщения, нулевые байты, двоичные поля и контрольные фрагменты. Если формат допускает несколько эквивалентных кодировок, заранее определите правило сравнения, а не требуйте побитового совпадения там, где оно не гарантируется.
После этого заново примените требуемую транспортную оболочку и немедленно декодируйте результат. Такая последняя проверка отделяет ошибку выбора сериализации от ошибки текстовой упаковки и оставляет воспроизводимую цепочку для расследования.
Проверка перед доставкой и типичные сбои
Успех нельзя определять только отсутствием ошибки в конвертере. Целевой потребитель или совместимый декодер должен прочитать результат; сохраните образец, версию schema, формат, способ упаковки, длину и итог сравнения. Частые проблемы: принятие Base64 за внутренний формат, потеря номера поля Protobuf, повторное текстовое кодирование двоичного поля или двойная транспортная упаковка без требования канала.
Если получатель отклоняет сообщение, возвращайтесь к последнему подтверждённому уровню: проверьте полноту оболочки, соответствие schema и поддержку формата, затем сократите вход до минимального воспроизводимого образца. Чёткая запись трёх уровней надёжнее случайного перебора конвертеров.