При проектировании веб-сервисов и интеграционных решений перед разработчиком часто встает задача передачи бинарных данных (файлов, изображений, электронных подписей, хэшей или архивов) через текстовые протоколы, такие как XML (SOAP) или JSON. Поскольку эти протоколы текстовые, передать «сырые» бинарные данные напрямую невозможно — их необходимо закодировать в текстовый вид. Для этого стандарт XML Schema (W3C) предоставляет два основных типа данных: hexBinary и base64Binary.
В этой статье мы подробно разберем фундаментальные различия между этими типами кодирования, проанализируем их влияние на сетевой трафик и производительность систем, а также рассмотрим практические примеры применения в экосистеме решений на платформе 1С:Предприятие.
Для того чтобы сделать осознанный выбор в пользу того или иного формата, давайте сначала разберем математику и логику работы обоих алгоритмов кодирования.
Шестнадцатеричное кодирование (hexBinary / Base16) представляет каждый байт исходных двоичных данных в виде двух шестнадцатеричных символов. Алфавит кодирования состоит всего из 16 символов: цифр от 0 до 9 и латинских букв от A до F (или от a to f).
С точки зрения объема данных математика здесь предельно проста: один байт исходного файла (8 бит) превращается в два текстовых символа (каждый символ кодирует 4 бита информации). Таким образом, объем данных при кодировании в hexBinary увеличивается ровно в 2 раза (на 100%).
Кодирование Base64 (base64Binary) использует гораздо более широкий алфавит, состоящий из 64 символов: прописные и строчные латинские буквы (A-Z, a-z), цифры (0-9) и два спецсимвола (обычно это "+" и "/"). Для выравнивания в конце строки может использоваться символ "=".
При кодировании Base64 каждые 3 байта исходных бинарных данных (всего 24 бита) разбиваются на 4 группы по 6 бит. Каждая 6-битная группа транслируется в один символ из 64-символьного алфавита. В итоге каждые 3 байта превращаются в 4 символа. Математически объем данных увеличивается примерно на 33.3% (в 1.33 раза), что значительно эффективнее, чем при шестнадцатеричном кодировании.
Рассмотрим наглядный пример. Допустим, нам необходимо передать через веб-сервис файл объемом 1 Мегабайт (1 048 576 байт):
base64Binary размер закодированной строки составит примерно 1.33 МБ. Мы получаем незначительный оверхед (избыточность) по трафику.hexBinary размер закодированной строки составит ровно 2 МБ. Объем передаваемой информации удваивается.На масштабах больших файлов (десятки и сотни мегабайт) разница становится колоссальной. Именно поэтому для передачи документов, картинок, PDF-файлов и архивов общепринятым индустриальным стандартом является именно base64Binary.
Возникает закономерный вопрос: если base64Binary настолько эффективнее по размеру, зачем вообще в стандартах XML Schema сохраняется поддержка hexBinary? Существует целый ряд практических задач, где шестнадцатеричный формат предпочтительнее или даже незаменим.
1. Передача коротких идентификаторов, хэшей и контрольных сумм
Если вам нужно передать MD5-хэш (16 байт), SHA-256 (32 байта), UUID объекта или MAC-адрес сетевого устройства, разница в трафике между Base64 и Hex составит считанные байты. В абсолютных величинах это абсолютно незаметно для сетевой инфраструктуры. Однако данные сущности в СУБД, операционных системах и криптографических утилитах традиционно хранятся и отображаются именно в шестнадцатеричном виде. Использование hexBinary в данном случае является естественным и логичным решением.
2. Простота отладки и «человекочитаемость» (Human-Readability)
При интеграции систем разработчики часто анализируют логи веб-сервисов, перехватывают XML-пакеты через прокси-серверы или просматривают SOAP-запросы вручную. Строку в формате Hex (например, 414243) очень легко сопоставить с исходными кодами символов в таблице ASCII (это буквы "ABC") или открыть в любом Hex-редакторе. Строка в формате Base64 абсолютно не поддается человеческому анализу без специализированных декодеров.
3. Минимальные требования к вычислительным ресурсам (CPU и RAM Overhead)
Алгоритм кодирования и декодирования Hex невероятно прост. Для преобразования байта в Hex не требуются сложные побитовые сдвиги или работа с буфером некратных байтов. Достаточно разделить байт на два полубайта и сопоставить их со статическим массивом из 16 символов. Если ваш веб-сервис взаимодействует с микроконтроллерами, IoT-устройствами, датчиками или старыми терминалами сбора данных с низкой производительностью процессора, обработка hexBinary потребует в разы меньше тактов процессора и оперативной памяти, чем base64Binary.
Давайте проанализируем, как эти типы применяются на практике в экосистеме 1С. Отличным примером служит стандарт DirectBank, разработанный фирмой 1С для прямого обмена электронными документами с банками без установки дополнительных программ-клиентов.
В рамках интеграционных пакетов DirectBank оба типа данных используются совместно для решения своих профильных задач:
hexBinary. Это короткая строка фиксированной длины, которую администраторы и специалисты техподдержки могут легко скопировать из лога веб-сервиса и сопоставить с установленным в системе сертификатом безопасности.base64Binary. Поскольку объем подписи и сопутствующих данных может достигать десятков килобайт, а самих транзакций за день отправляются тысячи, использование Base64 критически важно для экономии сетевого трафика банка и клиента.При расчете избыточности трафика разработчики часто упускают из виду один критически важный фактор — кодировку самого транспортного XML-документа.
Если обмен данными происходит в стандартной кодировке UTF-8, то каждый символ текстовой строки (как в Base64, так и в Hex) занимает в потоке ровно 1 байт. В этом случае наши теоретические расчеты верны: Hex дает увеличение объема в 2 раза, Base64 — в 1.33 раза.
Однако в некоторых корпоративных enterprise-системах XML-документы по умолчанию сериализуются в кодировку UTF-16, где под каждый символ отводится ровно 2 байта. Посмотрим, что произойдет с нашими данными при передаче в UTF-16:
hexBinary каждый исходный байт превращается в 2 символа, каждый из которых весит по 2 байта. Итоговый объем данных увеличивается **в 4 раза** (на 300% избыточности)!base64Binary каждые 3 байта превращаются в 4 символа, каждый из которых также весит по 2 байта. Итоговый объем данных увеличивается **в 2.66 раза**.Поэтому при проектировании высоконагруженных веб-сервисов всегда контролируйте кодировку исходящего XML-пакета, чтобы не перегружать каналы связи избыточными данными.
Платформа «1С:Предприятие 8» берет на себя большую часть рутины по сериализации и десериализации XML. При импорте WSDL-описания веб-сервиса типы схемы XDTO hexBinary и base64Binary автоматически сопоставляются платформенному типу данных ДвоичныеДанные.
Когда вы передаете объект типа ДвоичныеДанные в качестве параметра метода веб-сервиса, платформа сама кодирует его в нужный формат в зависимости от типа, указанного в схеме XDTO. При получении ответа происходит обратный автоматический процесс.
Тем не менее, иногда разработчику требуется выполнить ручную конвертацию бинарных данных в строку определенного формата непосредственно в коде конфигурации.
Работа с Base64 в коде 1С
Для работы с Base64 в платформе 1С реализованы специализированные и очень быстрые встроенные функции, выполняющие конвертацию на уровне ядра платформы:
// Кодирование двоичных данных в строку Base64
ИмяФайла = "C:\temp\document.pdf";
ДвоичныеДанныеФайла = Новый ДвоичныеДанные(ИмяФайла);
СтрокаBase64 = ПолучитьBase64СтрокуИзДвоичныхДанных(ДвоичныеДанныеФайла);
// Обратное декодирование из строки Base64 в двоичные данные
ДвоичныеДанныеОбратно = ПолучитьДвоичныеДанныеИзBase64Строки(СтрокаBase64);
ДвоичныеДанныеОбратно.Записать("C:\temp\restored_document.pdf");
Работа с Hex (hexBinary) в коде 1С
В отличие от Base64, специализированных встроенных функций вроде "ПолучитьHexСтрокуИзДвоичныхДанных" в платформе долгое время не существовало. Разработчикам приходилось писать собственные алгоритмы деления и взятия остатка по модулю 16 для каждого байта, что работало крайне медленно на больших массивах данных.
Однако существует изящный платформенный способ выполнить преобразование в Hex и обратно мгновенно, задействовав механизмы Фабрики XDTO. Проанализируем пример кода, реализующий этот подход:
// Функция быстрого преобразования Двоичных Данных в Hex-строку
Функция ДвоичныеДанныеВHexСтроку(ВашиДвоичныеДанные) Экспорт
// Получаем тип hexBinary из глобального пространства имен XML Schema
ТипHex = ФабрикаXDTO.Тип("http://www.w3.org/2001/XMLSchema", "hexBinary");
// Создаем объект XDTO на основе двоичных данных
ОбъектHex = ФабрикаXDTO.Создать(ТипHex, ВашиДвоичныеДанные);
// Извлекаем строковое шестнадцатеричное представление
Возврат ОбъектHex.ЛексическоеЗначение;
КонецФункции
// Функция обратного преобразования Hex-строки в Двоичные Данные
Функция HexСтрокуВДвоичныеДанные(Знач HexСтрока) Экспорт
ТипHex = ФабрикаXDTO.Тип("http://www.w3.org/2001/XMLSchema", "hexBinary");
// Восстанавливаем объект XDTO из строкового представления
ОбъектHex = ФабрикаXDTO.Создать(ТипHex, HexСтрока);
// Получаем исходные ДвоичныеДанные
Возврат ОбъектHex.Значение;
КонецФункции
Этот способ примечателен тем, что всю низкоуровневую работу по кодированию и декодированию берет на себя оптимизированный C++ код платформы 1С, что обеспечивает максимальную скорость выполнения операции без лишней нагрузки на сервер.
Подводя итог нашему анализу, сформулируем простые и понятные правила для выбора типа данных при проектировании интеграций:
base64Binary по умолчанию во всех случаях, когда планируется передача файлов, изображений, документов, медиа-контента или любых других бинарных данных объемом более нескольких килобайт. Это сбережет до 66% вашего трафика.hexBinary для передачи коротких служебных данных: хэш-сумм файлов (MD5, SHA), UUID идентификаторов систем, токенов авторизации, аппаратных адресов или ключей шифрования. Это упростит чтение логов и отладку интеграции.