При работе с криптографией, хэшированием или интеграцией со сторонними веб-сервисами в 1С разработчики часто сталкиваются с неожиданным поведением. Выполняя преобразование бинарных данных (например, хэша SHA-512) с помощью встроенной функции Base64Строка, мы можем обнаружить в результате странный символ перевода строки (визуально он может отображаться как символ "¶" или создавать разрыв). Разберем по шагам, откуда берется этот символ и как получить чистую строку.
Для начала проанализируем, почему платформа 1С добавляет эти символы. Ответ кроется в общепринятых веб-стандартах, которым следует платформа.
Функция Base64Строка реализует алгоритм кодирования в строгом соответствии со спецификацией MIME (RFC 2045) и стандартом XML Schema (тип xs:base64Binary). Согласно этим стандартам, длинный закодированный поток данных не должен быть сплошным — он разбивается на строки ограниченной длины для удобной передачи и отображения в текстовых форматах.
В платформе «1С:Предприятие» длина строки Base64 жестко ограничена блоком в 64 символа. Как только длина достигает этого предела, платформа автоматически вставляет разделитель строк. В ОС Windows это возврат каретки и перевод строки (CR+LF), а в Linux — только перевод строки (LF).
Рассмотрим конкретный пример с алгоритмом SHA-512. Хэш SHA-512 имеет длину 64 байта. При кодировании в Base64 объем данных увеличивается, и мы получаем ровно 88 символов (включая символы выравнивания == в конце). Поскольку 88 символов больше лимита в 64 символа, платформа неизбежно разрезает строку и вставляет невидимый перенос каретки после 64-го знака.
Иногда возникает предположение, что формат вывода можно настроить через региональные установки информационной базы. Это заблуждение. Настройки региональных установок или сеанса никак не влияют на формирование Base64 — они управляют исключительно визуальным представлением чисел (например, разбиением по разрядам), дат и булевых значений.
Также у функции Base64Строка (и у метода XMLСтрока для двоичных данных) нет управляющих параметров или флагов форматирования (аналога режима NoWrap в других языках программирования), которые позволили бы отключить вставку разделителей "из коробки".
Поскольку встроенного параметра для отключения переносов нет, мы решим эту задачу с помощью постобработки полученного результата. Нам потребуется удалить служебные символы программно.
Рассмотрим наиболее надежный и кроссплатформенный подход. Мы будем использовать функцию СтрЗаменить, причем удалять Символы.ВК (возврат каретки) и Символы.ПС (перевод строки) следует отдельными вызовами. Это гарантирует корректную работу кода как на серверах под управлением Windows, так и на Linux.
Посмотрим на пример реализации:
// Получаем бинарные данные, например, хэш SHA-512
ДвоичныеДанныеХэша = ПолучитьХэшДанных();
// Конвертируем в Base64
СтрBase64 = Base64Строка(ДвоичныеДанныеХэша);
// Очищаем строку от нежелательных переносов каретки и строк
СтрBase64 = СтрЗаменить(СтрBase64, Символы.ВК, "");
СтрBase64 = СтрЗаменить(СтрBase64, Символы.ПС, "");
Важное замечание: не используйте конструкцию вида СтрЗаменить(СтрBase64, Символы.ВК + Символы.ПС, ""). На серверах Linux платформа формирует только символ LF (то есть Символы.ПС). Если вы попытаетесь найти и заменить связку CR+LF, замена на Linux не сработает, и перенос строки останется в переменной.
Проанализируем ситуации, когда наличие переносов строк критично, а когда на них можно не обращать внимания.
Base64Значение, очистка не требуется. По стандарту парная функция Base64Значение успешно игнорирует незначащие пробельные символы, переводы строк и возвраты каретки при восстановлении бинарных данных.Authorization: Basic ...), символы CR и LF вызовут фатальную ошибку. По спецификации HTTP они недопустимы внутри значений заголовков и приведут к отказу веб-сервера или падению парсера запросов. Здесь очистка строго обязательна.+ меняется на минус -, а слэш / меняется на подчеркивание _), а также удаляются символы выравнивания = в конце.Если вы формируете хэш для передачи внешней системе, обязательно проверьте документацию API. Возможно, сторонний сервис ожидает хэш не в формате Base64, а в шестнадцатеричном виде (hex-представление). Для SHA-512 это будет сплошная строка из 128 символов от 0 до f.
Если требуется именно hex-строка, кодирование через Base64Строка неприменимо в принципе. В этом случае двоичные данные хэша необходимо переводить в шестнадцатеричную строку побайтово с помощью специализированных алгоритмов или функций глобального контекста, если они доступны в вашей версии платформы.