Какая кодировка используется в 1С и как исправить проблемы с отображением

Вопрос о кодировке в 1С возникает чаще всего в трёх ситуациях: при обмене данными с внешними системами, при выгрузке файлов (CSV, XML, TXT) и когда вместо русского текста появляются «кракозябры» — нечитаемые символы. Чтобы решить проблему, нужно понимать, какие кодировки платформа 1С использует внутри себя и какие применяет при работе с файлами.

Внутри платформа 1С хранит строки в Unicode — это означает, что в памяти и в базе данных текст не привязан к однобайтовой кодировке вроде Windows-1251. Проблемы начинаются на границе системы: когда 1С читает или записывает текстовый файл, отправляет HTTP-запрос, формирует печатную форму для сторонней программы или обменивается данными с сайтом.

Наиболее частые внешние кодировки, с которыми сталкиваются пользователи и разработчики 1С — UTF-8, UTF-16, Windows-1251 (ANSI), KOI8-R и DOS-кодировка CP866. Каждая из них появляется в своих сценариях: банковские выгрузки, старые базы данных, файлы от поставщиков, интеграция с Linux-системами.

Какие кодировки использует платформа 1С

Строки в памяти и в полях базы данных 1С хранятся в Unicode. В клиент-серверном варианте конкретное представление зависит от СУБД: MS SQL Server использует типы NVARCHAR (UTF-16), PostgreSQL обычно работает с базой в UTF-8. Для пользователя и разработчика это прозрачно — внутри конфигуратора и режима «Предприятие» с кодировкой сталкиваться не приходится.

При файловых операциях ситуация иная. Объекты ЧтениеТекста, ЗаписьТекста, ЧтениеXML, ЗаписьJSON позволяют явно указать кодировку. Если кодировка не указана, платформа применяет значение по умолчанию — как правило, UTF-8, но поведение зависит от конкретного объекта и версии платформы, поэтому полагаться на умолчание при обмене с внешними системами рискованно.

Отдельный случай — файловая база и служебные файлы. Файл 1Cv8.1CD имеет собственный внутренний формат, и «сменить его кодировку» нельзя. А вот настройки списка баз в файле ibases.v8i хранятся в UTF-8, что важно при его ручном редактировании.

Где чаще всего возникают проблемы с кодировкой

Первая типовая ситуация — обмен с банками и старыми учётными системами. Некоторые банковские форматы и выгрузки из программ, работающих ещё с DOS-времён, используют Windows-1251 или CP866. Если такой файл открыть как UTF-8, кириллица превратится в последовательности вида «РџСЂРёРІРµС‚».

Вторая ситуация — выгрузка CSV для Excel или сторонних аналитических инструментов. Excel в русской локали Windows по умолчанию ожидает ANSI (Windows-1251) для CSV-файлов без BOM. Файл, записанный из 1С в UTF-8 без BOM, Excel может открыть с искажёнными русскими буквами, хотя сам файл корректен.

Третья — интеграция через HTTP и веб-сервисы. Если тело запроса или ответа передаётся в одной кодировке, а заголовок Content-Type указывает другую (или не указывает её вовсе), приёмник интерпретирует байты неверно. Четвёртая — печатные формы и отчёты, выгружаемые в PDF или отправляемые на печать через внешние компоненты, где шрифт не содержит нужных глифов.

Как определить кодировку файла

Прежде чем менять настройки обмена, определите фактическую кодировку проблемного файла. Самый простой способ — открыть файл в редакторе Notepad++: в меню «Кодировки» видно текущее определение, а переключение между UTF-8 и ANSI позволяет быстро проверить, в каком варианте текст становится читаемым.

Второй признак — наличие BOM (Byte Order Mark), служебных байтов в начале файла. UTF-8 с BOM начинается с байтов EF BB BF, UTF-16 LE — с FF FE. Файл в Windows-1251 не имеет BOM в принципе. Просмотреть первые байты можно любым hex-редактором или командой в терминале.

Из самой 1С кодировку можно проверить программно: прочитать файл как двоичные данные и посмотреть первые байты, либо перебрать чтение с разными кодировками и проверить, при какой строка содержит ожидаемый текст. Это полезно при автоматической загрузке файлов от контрагентов, формат которых не стабилен.

// Пример: чтение файла с явным указанием кодировки
Чтение = Новый ЧтениеТекста("C:\Обмен\bank.txt", КодировкаТекста.UTF8);
Строка = Чтение.ПрочитатьСтроку();
Чтение.Закрыть();
// Для старых банковских форматов: КодировкаТекста.ANSI или КодировкаТекста.OEM

Как явно задать кодировку при чтении и записи

Правило номер один при разработке обменов: всегда указывайте кодировку явно, даже если значение по умолчанию сейчас работает. Версии платформы и настройки окружения меняются, а явный параметр делает поведение предсказуемым на любом сервере.

Для текстовых файлов используйте перечисление КодировкаТекста: UTF8, UTF16, ANSI (соответствует системной однобайтовой кодировке, в русской Windows — 1251), OEM (CP866), UTF8БезBOM. Для XML-документов кодировка указывается в объявлении документа и параметрах ЗаписьXML; для JSON — в параметрах ЗаписьJSON и настройках сериализации.

При HTTP-обмене кодировка задаётся через заголовок Content-Type, например application/xml; charset=utf-8, и должна совпадать с фактической кодировкой тела запроса. Расхождение заголовка и содержимого — частая причина «кракозябр» на стороне приёмника даже при корректном файле.

1. 1
   Сохраните исходный проблемный файл и сделайте его копию для экспериментов
2. 2
   Откройте копию в Notepad++ и определите фактическую кодировку
3. 3
   Сверьте её с кодировкой, указанной в коде чтения или настройках обмена 1С
4. 4
   Укажите правильную кодировку явно (UTF8, ANSI, OEM)
5. 5
   Повторите загрузку и проверьте кириллицу, цифры и спецсимволы
6. 6
   Зафиксируйте согласованный формат с контрагентом письменно

Настройка кодировки в типовых обменах

В типовых конфигурациях (УТ, ERP, Бухгалтерия) обмены с банками, ЕГАИС, ЭДО и сайтами уже настроены, и менять кодировку в коде не требуется. Если проблема возникает в типовом обмене, сначала проверьте версию конфигурации и формат обмена — устаревший формат может не совпадать с текущими требованиями внешней системы.

При выгрузке на сайт (например, по протоколу CommerceML) файлы формируются в UTF-8. Если на стороне сайта русские названия искажены, проблема почти всегда в настройках веб-сервера или базы сайта, а не в 1С — исправлять нужно там.

Для собственных обработок выгрузки в Excel выбирайте: либо CSV в Windows-1251 (ANSI) с разделителем «точка с запятой» для русской локали, либо UTF-8 с BOM — такой файл современный Excel распознаёт корректно. UTF-8 без BOM для Excel — худший вариант.

Ограничения и риски при работе с кодировками

Главный риск — необратимая порча данных. Если текст один раз сохранён с потерей символов (например, кириллица заменена на знаки вопроса при конвертации в Latin-1), восстановить его из испорченного файла невозможно. Поэтому любые эксперименты с перекодированием делайте на копии, а исходники обмена храните.

Второй риск — двойная перекодировка в цепочке систем: 1С → промежуточный сервис → сайт. На каждом шаге кодировка может преобразовываться, и диагностировать нужно всю цепочку, снимая файл на каждом этапе. Третье ограничение — BOM: некоторые парсеры и API отвергают файлы с BOM, поэтому для машинного обмена предпочтителен UTF-8 без BOM, а для человеческого открытия в Excel — с BOM.

Частые ошибки и как их избежать

Самая распространённая ошибка — «лечение симптома»: разработчик подбирает кодировку перебором, пока текст не станет читаемым на его машине, но не фиксирует согласованный формат с внешней системой. На другом компьютере с иной локалью проблема возвращается.

Вторая ошибка — игнорирование BOM при сравнении файлов и контрольных сумм: два визуально одинаковых файла в UTF-8 с BOM и без него различаются байтами, что ломает проверки целостности. Третья — смешение кодировок внутри одного файла, когда части документа формируют разные механизмы; такой файл не читается корректно ни в одной кодировке.

Частые вопросы о кодировках в 1С