Какая кодировка используется в 1С: 8.3 и более ранних версиях

Вопрос о том, какая кодировка используется в 1С, часто возникает при попытке импорта или экспорта данных, а также при столкновении с «кракозябрами» в выгружаемых файлах. Понимание принципов работы с символами критически важно для разработчиков и администраторов, так как неверный выбор параметров может привести к потере данных или невозможности прочитать файлы в сторонних системах. В современных версиях платформы ситуация кардинально изменилась по сравнению с ранними релизами.

Основная сложность заключается в том, что сама платформа 1С:Предприятие 8 внутренне оперирует строками в кодировке UTF-16. Это означает, что любой текст внутри системы уже хранится в уникод-формате, поддерживающем практически все языки мира. Однако при обмене данными с внешним миром (файловой системой, веб-сервисами, базами данных) происходит преобразование, и именно на этом этапе чаще всего возникают ошибки. Важно различать внутреннее представление данных и формат их сериализации при выгрузке.

Рассмотрим детально, как управлять этими процессами, какие стандарты де-факто используются в экосистеме 1С и как избежать типичных проблем с кодировкой при работе с текстовыми файлами и базами данных.

Внутреннее представление строк в платформе 1С

Как уже упоминалось, ядро платформы 1С использует UTF-16 для хранения строковых переменных. Это обеспечивает полную совместимость с международными стандартами и позволяет корректно отображать символы кириллицы, латиницы, иероглифов и специальных знаков без дополнительных настроек со стороны пользователя. Для разработчика это означает, что внутри кода конфигурации вы можете свободно оперировать текстом любой сложности.

Проблемы начинаются тогда, когда данные покидают пределы управляемого приложения. Например, при чтении текстового файла через объект ЧтениеТекста или при формировании отчета в формате HTML. Если внешняя система ожидает однобайтовую кодировку (например, Windows-1251), а 1С отдает байты в UTF-8 без маркера BOM, целевая система может некорректно интерпретировать байты.

Стоит отметить, что в версиях платформы до 8.3 существовали нюансы с именами файлов и путями в операционной системе, но в актуальных релизах эти вопросы решены на уровне драйверов и API операционной системы. Разработчику остается лишь контролировать параметры конвертации при явном чтении или записи потоков данных.

⚠️ Внимание: Никогда не полагайтесь на автоматическое определение кодировки при чтении «сырых» бинарных файлов. Всегда явно указывайте параметр кодировки в конструкторе объекта чтения, чтобы избежать скрытых ошибок интерпретации байтов.

Стандарты кодировок при обмене данными (XML, JSON, CSV)

При интеграции 1С с другими информационными системами выбор кодировки становится вопросом стандарта протокола обмена. Для формата XML стандартом де-факто является UTF-8. Большинство веб-сервисов, SOAP-интерфейсов и REST-API ожидают получение данных именно в этом формате. Платформа 1С при использовании объекта ЗаписьXML по умолчанию часто предлагает UTF-8, что является правильным выбором для современной веб-разработки.

Ситуация с форматом CSV (Comma Separated Values) гораздо сложнее и зависит от региональных настроек и требований принимающей системы. В русскоязычном сегменте исторически сложилось использование кодировки Windows-1251 (CP1251) для CSV-файлов, открываемых в Microsoft Excel. Если вы выгрузите файл в UTF-8 без BOM (Byte Order Mark), Excel может открыть его, отображая русский текст в виде непонятных символов.

• 📄 UTF-8 — универсальный стандарт для веб-интерфейсов, JSON и современных баз данных.
• 💾 Windows-1251 — стандарт для обмена с устаревшими системами и работы с Excel в локальной среде Windows.
• 🔧 OEM866 — используется крайне редко, в основном для совместимости со старым консорным ПО или специфическим оборудованием.
• 🌐 UTF-8 with BOM — специфический вариант для корректного открытия CSV файлов в Excel без потери кириллицы.

При работе с JSON ситуация наиболее прозрачная: стандарт RFC 8259 предписывает использование UTF-8. Объект ЧтениеJSON и ЗаписьJSON в 1С автоматически обрабатывают этот формат, и ручное вмешательство в кодировку требуется редко, разве что при работе с низкоуровневыми потоками.

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

Для корректной работы с файлами в коде конфигурации необходимо использовать объекты ЧтениеТекста и ЗаписьТекста. Ключевым моментом здесь является второй параметр конструктора, отвечающий за кодировку. Если этот параметр опущен, система попытается определить кодировку автоматически по BOM (маркеру порядка байтов), но такой механизм не всегда срабатывает корректно, особенно если файл был создан в другой системе без маркера.

Рассмотрим пример явного указания кодировки при чтении файла. Это гарантирует, что байты будут преобразованы в строки платформы корректно, независимо от настроек операционной системы сервера или клиента.

ИмяФайла ="C:\Data\export.csv";
Чтение = Новый ЧтениеТекста(ИмяФайла, КодировкаТекста.Windows1251);
// Дальнейшая обработка данных...
Чтение.Закрыть;

Аналогично происходит запись. Если вы формируете отчет для бухгалтера, который будет открывать его в Excel двойным кликом, использование КодировкаТекста.UTF8 без BOM приведет к тому, что пользователь увидит иероглифы вместо фамилий и названий товаров. В таких случаях лучше использовать КодировкаТекста.Windows1251 или добавить BOM к UTF-8 файлу, хотя стандартные средства записи текста в 1С не всегда позволяют легко добавить BOM без работы с байтовыми потоками.

Проблемы кодировки в базах данных SQL и файлах dt

При миграции данных или выгрузке информационной базы в формат .dt (файл выгрузки) кодировка играет второстепенную роль, так как это бинарный формат, понятный только платформе 1С. Однако при работе напрямую с базой данных MS SQL Server или PostgreSQL через ODBC/JDBC драйверы могут возникать коллизии.

В СУБД текст обычно хранится в кодировке, заданной при создании базы данных (Collation). Для корректной работы 1С с SQL Server рекомендуется использовать collation с суффиксом _CI_AS (Case Insensitive, Accent Sensitive) и кодировкой, поддерживающей кириллицу. В PostgreSQL по умолчанию используется UTF-8, что идеально сочетается с внутренним форматом 1С, минимизируя потери при конвертации.

СУБД	Рекомендуемая кодировка	Типичные проблемы	Решение
MS SQL Server	CP1251 (Russian)	Потеря данных при вставке символов вне диапазона	Использование полей типа NVARCHAR
PostgreSQL	UTF-8	Конфликты сортировки (Collation)	Настройка локали при создании БД
Oracle	AL32UTF8	Ошибки длины строки (байты vs символы)	Учет многбайтовых символов в длине
IBM DB2	UTF-8 / CP1251	Сложности с драйверами	Обновление клиентской части

Особое внимание стоит уделить длине строковых полей. В однобайтовых кодировках один символ занимает один байт, тогда как в UTF-8 кириллический символ может занимать два байта. Если в базе данных поле ограничено 50 байтами, то строка из 50 русских букв в UTF-8 просто не поместится, что вызовет ошибку записи.

Конвертация данных из 1С 7.7 в 1С 8

Процесс переноса данных из старых версий 1С:Предприятие 7.7 в современные платформы 8.х является одним из самых критичных моментов, где кодировка может стать препятствием. В версии 7.7 доминировала кодировка CP866 (DOS) или Windows-1251 в зависимости от операционной системы и настроек запуска.

При использовании стандартной обработки конвертации данных (КД 2.0 или 3.0) процесс преобразования кодировки происходит автоматически. Однако, если вы пишете собственные обработчики выгрузки/загрузки для специфических справочников, необходимо помнить о разнице в представлении символов. Строки, пришедшие из «семерки», могут содержать символы в старой кодировке, которые при прямой записи в базу 8.3 без конвертации превратятся в нечитаемый набор знаков.

⚠️ Внимание: При ручной миграции данных через текстовые файлы обязательно проверяйте кодировку исходного файла из 1С 7.7. Часто это OEM866, который современные редакторы могут не распознать автоматически.

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

Как исправить кракозябры в базе?

Существуют обработки типа"Конвертация кодировки текста", которые проходят по всем строковым полям базы и выполняют переконвертацию байтов. Использовать их нужно с осторожностью и только после полного резервного копирования базы (бекапа).

Диагностика и решение проблем с отображением символов

Как понять, что проблема именно в кодировке? Первым признаком является появление символов вида «ÃоÃл