Как исправить искажение русских символов (кракозябры) при подключении 1С к Oracle через ODBC?

Программист 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

При интеграции 1С с внешними базами данных на платформе Oracle через драйверы ODBC программисты часто сталкиваются с проблемой некорректного отображения кириллицы. Вместо привычного русского текста в 1С приходят «кракозябры» (например, ÁÎËÒ вместо БОЛТ). В этой статье мы подробно разберем причины этой проблемы и рассмотрим пошаговые решения, основанные на практическом опыте и технических нюансах работы клиента Oracle в среде Windows.

Анализ исходной ситуации

Рассмотрим типовой сценарий: в 1С используется внешняя обработка, которая через COM-объект подключается к базе данных Oracle. Используется стандартная строка соединения с указанием драйвера, пути к базе и учетных данных. Проанализируем пример кода, который обычно применяется для таких задач:


Соединение = Новый COMОбъект("ADODB.Connection");
Команда = Новый COMОбъект("ADODB.Command");
Выборка = Новый COMОбъект("ADODB.RecordSet");

Соединение.ConnectionString ="DRIVER={Oracle in OraClient11g_home1};DBQ=DB1;UID=user;PWD=password";
Соединение.ConnectionTimeout = 30;
Соединение.CommandTimeout = 600;
Соединение.Open();

Команда.ActiveConnection = Соединение;
Выборка = Команда.Execute();

Если Выборка.BOF = Ложь Тогда
    Пока Выборка.EOF = Ложь Цикл
        // Здесь получаем значение поля с кириллицей
        parent_name = Выборка.Fields("parent_name").Value;
        Выборка.MoveNext();
    КонецЦикла;
КонецЕсли;

Проблема заключается в том, что на одном сервере этот код работает корректно, а на другом — возвращает искаженные данные, несмотря на идентичные версии клиента Oracle. Это указывает на то, что причина кроется в настройках окружения Windows или конфигурации клиента Oracle.

Решение 1: Настройка системной локали Windows

Одной из наиболее частых причин возникновения «кракозябр» является некорректная настройка системной локали для программ, не поддерживающих Юникод. Поскольку драйверы ODBC (особенно старых версий) могут полагаться на системную кодировку ANSI, важно убедиться, что Windows правильно интерпретирует не-юникодные символы.

Рассмотрим, как изменить эту настройку:

  1. Откроем «Панель управления» — «Региональные стандарты» (Region).
  2. Перейдем на вкладку «Дополнительно» (Administrative).
  3. В разделе «Язык программ, не поддерживающих Юникод» (Language for non-Unicode programs) нажмем кнопку «Изменить локаль системы» (Change system locale).
  4. Выберем Русский (Россия).
  5. Важный нюанс: Убедимся, что галочка «Бета-версия: Использовать UTF-8 для поддержки языков во всем мире» снята. Если она установлена, это принудительно переводит систему в UTF-8, что часто конфликтует с драйверами Oracle, ожидающими кодировку win1251.

Решение 2: Настройка параметра NLS_LANG

Параметр NLS_LANG определяет язык, территорию и кодировку, которую клиент Oracle использует для обмена данными с базой. Если этот параметр не совпадает с кодировкой базы данных или системной кодировкой Windows, происходит искажение символов.

Проанализируем структуру параметра NLS_LANG. Он состоит из трех частей: [Язык]_[Территория].[Кодировка]. Для корректной работы с кириллицей в Windows обычно используется значение RUSSIAN_RUSSIA.CL8MSWIN1251.

Разберем, где необходимо проверить и установить этот параметр:

  1. Реестр Windows:

    Параметры могут находиться в разных ветках в зависимости от разрядности клиента и системы:

    • Для 64-битного клиента: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient...
    • Для 32-битного клиента в 64-битной системе: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ORACLE\KEY_OraClient...

    Необходимо найти ключ NLS_LANG и установить значение RUSSIAN_RUSSIA.CL8MSWIN1251.

  2. Переменные окружения:

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

    • Нажмем правой кнопкой на «Этот компьютер» — «Свойства» — «Дополнительные параметры системы» — «Переменные среды».
    • Создадим в разделе «Системные переменные» (это критично для работы сервера 1С) переменную NLS_LANG со значением RUSSIAN_RUSSIA.CL8MSWIN1251 или RUSSIAN_CIS.CL8MSWIN1251.

Решение 3: Контекст службы 1С:Предприятие и перезагрузка

Часто программисты вносят изменения в переменные окружения, но не видят результата. Это происходит потому, что служба «Агент сервера 1С:Предприятие» запускается при старте системы и кэширует переменные окружения.

Выполним следующие шаги:

После изменения любых настроек (реестра или переменных среды) необходимо либо полностью перезагрузить сервер, либо как минимум перезапустить службу 1С в консоли services.msc. Только после этого служба «увидит» новые настройки NLS_LANG.

Решение 4: Использование кодировки AL32UTF8 для ADO

В некоторых случаях, особенно при использовании ADODB.Connection, может помочь установка клиентской кодировки в AL32UTF8. Это заставляет драйвер Oracle конвертировать данные в Unicode (UTF-8), который является «родным» форматом для строк в 1С. Рассмотрим вариант установки переменной:

NLS_LANG = RUSSIAN_RUSSIA.AL32UTF8

Это исключает промежуточную перекодировку в ANSI (win1251) на уровне драйвера, что часто убирает проблему искажения символов.

Рекомендации по диагностике

Если вышеуказанные шаги не помогли, проанализируем ситуацию глубже:

Подводя итог, можно сказать, что в большинстве случаев проблема решается комбинацией установки правильной системной локали в Windows и жестким заданием NLS_LANG в системных переменных окружения с последующим перезапуском всех связанных служб.

← На главную