Как устранить появление знаков вопроса при передаче грузинского текста из 1С в MS SQL?

При работе с внешними источниками данных в 1С программисты часто сталкиваются с проблемой некорректного отображения национальных алфавитов, таких как грузинский. Вместо ожидаемых символов в таблицу MS SQL попадают знаки вопроса (??????). Ситуация осложняется тем, что в самой 1С данные отображаются корректно, а поля в базе-приемнике имеют правильный тип nvarchar. Давайте разберем эту проблему по шагам, проанализируем причины и найдем способы ее решения.

Разбор архитектуры взаимодействия

Прежде всего, проанализируем путь прохождения данных. Когда мы вызываем хранимую процедуру внешнего источника из 1С, строка проходит через несколько уровней:

1. Платформа 1С:Предприятие. Здесь строка хранится в формате Unicode (UTF-16).
2. Драйвер подключения (ODBC или OLE DB). На этом этапе происходит передача параметров от клиента к серверу.
3. Слой трансляции SQL Server. Сервер принимает данные и распределяет их по переменным внутри хранимой процедуры.
4. Логика хранимой процедуры. Тело процедуры выполняет вставку или обновление данных в таблицах.

Появление знаков вопроса сигнализирует о том, что на одном из этих этапов произошла потеря кодировки — "сужение" Unicode-строки до обычной 8-битной кодировки (ANSI), которая не содержит грузинских символов.

Проверка драйвера подключения и параметров строки соединения

Одной из самых частых причин является использование устаревшего драйвера SQL Server (файл sqlsrv32.dll), который поставляется вместе с операционной системой. Рассмотрим альтернативные варианты. Рекомендуется использовать современные драйверы:

• ODBC Driver 17 for SQL Server (или более новая 18-я версия).
• Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL).

При использовании этих драйверов важно обратить внимание на параметр AutoTranslate. Разберем ситуацию: если в настройках соединения или в строке подключения указано AutoTranslate=Yes, драйвер пытается автоматически конвертировать символы из Unicode в кодовую страницу системной локали. Поскольку грузинский алфавит не входит в стандартную кириллическую (CP1251) или латинскую кодировки, происходит подмена символов на знаки вопроса.

Для исправления ситуации в строке подключения внешнего источника в 1С следует явно прописать AutoTranslate=No;.

Анализ кода хранимой процедуры

Даже если драйвер настроен верно, данные могут "испортиться" внутри самой базы данных MS SQL. Проанализируем типичную ошибку, которую может допустить SQL-разработчик. Если внутри процедуры Unicode-строка попадает в переменную или параметр типа varchar, она мгновенно теряет свои специфические символы.

Посмотрим на пример кода, демонстрирующий эту проблему:

DECLARE @n nvarchar(100); -- Правильный тип для Unicode
DECLARE @v varchar(100);  -- Неправильный тип (ANSI)

SET @n = N'გამარჯობა გენაცвалე'; -- Грузинский текст с префиксом N
SET @v = @n; -- Происходит неявное преобразование и потеря данных

PRINT @n; -- Выведет: გამარჯობა გენაცвалე
PRINT @v; -- Выведет: ????????? ?????????

При работе с грузинским языком крайне важно, чтобы все параметры хранимой процедуры, которые принимают текстовые данные, имели тип nvarchar. Если процедура использует динамический SQL (через EXEC или sp_executesql), убедитесь, что перед строковыми литералами всегда стоит префикс N. Это указывает SQL-серверу, что константа должна интерпретироваться как Unicode.

Настройка сопоставления (Collation)

Хотя тип данных nvarchar хранит символы в кодировке UTF-16 и теоретически независим от Collation (сопоставления) базы данных, на практике сопоставление влияет на операции сравнения и сортировки. Рассмотрим, какие настройки будут наиболее подходящими.

Для корректной работы с грузинским языком можно использовать специализированное сопоставление Georgian_Modern_Sort_CI_AS. Однако, если база данных должна быть универсальной, часто достаточно использовать Cyrillic_General_100_BIN2 или Latin1_General_100_CI_AS_SC (с поддержкой дополнительных символов). Главное — убедиться, что данные передаются именно как nvarchar.

Диагностика с помощью SQL Server Profiler

Чтобы точно выяснить, на каком этапе ломается кодировка, воспользуемся инструментом SQL Server Profiler. Проанализируем шаги диагностики:

1. Запустите профилировщик и подключитесь к экземпляру SQL Server.
2. Выберите шаблон Standard и убедитесь, что включены события RPC:Completed и SQL:BatchCompleted.
3. Выполните действие в 1С, которое вызывает запись данных во внешний источник.
4. Найдите в списке захваченных событий вызов вашей хранимой процедуры.

Анализ результатов:

• Если в тексте запроса в колонке TextData вы уже видите знаки вопроса (например, EXEC MyProc @Param1 = '?????'), значит, проблема на стороне 1С или драйвера. 1С отправляет данные неверно.
• Если в профилировщике видны корректные грузинские символы (например, EXEC MyProc @Param1 = N'გამარჯობა'), но в таблице после выполнения процедуры оказываются вопросы — проблема на 100% в логике самой процедуры или структуре таблицы-приемника.

Обновление метаданных внешнего источника в 1С

Иногда платформа 1С "запоминает" старые типы данных, которые были у таблицы SQL на момент первого подключения. Если вы изменили поле с varchar на nvarchar в SQL-сервере, 1С может продолжать считать его обычным строковым полем без поддержки Unicode.

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

1. Откройте состав внешнего источника.
2. Удалите проблемную таблицу из списка.
3. Нажмите кнопку "Добавить" (из внешнего источника) и заново выберите эту таблицу.
4. Проверьте свойства полей: тип данных в 1С должен соответствовать строке неограниченной или фиксированной длины, которая сопоставляется с nvarchar в SQL.

Такое пересоздание метаданных гарантирует, что драйвер 1С будет правильно типизировать параметры при вызове процедур.

Итоги и рекомендации

Мы проанализировали основные причины искажения грузинских символов при интеграции 1С и MS SQL. Подведем итоги нашей совместной работы:

Во-первых, всегда используйте типы данных nvarchar вместо varchar на всех этапах: в параметрах процедур, в локальных переменных и в самих таблицах.

Во-вторых, проверьте драйвер подключения. Рекомендуется использовать ODBC Driver 17 for SQL Server и обязательно добавлять параметр AutoTranslate=No в строку соединения.

В-третьих, используйте SQL Server Profiler для локализации ошибки. Это сэкономит время, четко указав, где именно (в 1С или в SQL) происходит подмена символов.

Соблюдение этих правил обеспечит надежную работу с многоязычными данными и исключит появление "знаков вопроса" в ваших базах данных.