При автоматизации обмена данными часто используется выгрузка в формат DBF. Однако администраторы и программисты 1С часто сталкиваются с неприятной ситуацией: при запуске обработки вручную всё работает корректно, но стоит настроить автоматический запуск через Планировщик заданий Windows (Task Scheduler), как вместо русских букв в файле появляются знаки вопроса «?». Особенно остро эта проблема проявляется на современных операционных системах, таких как Windows Server 2019.
В этой статье мы подробно разберем причины возникновения этой ошибки и рассмотрим несколько способов её решения — от простых настроек планировщика до глубокой правки реестра и программного кода.
Прежде всего, проанализируем ситуацию. Появление знаков вопроса означает, что система не может правильно сопоставить символы кириллицы с кодовой страницей целевого файла. В Windows Server 2019 механизмы работы с не-Unicode программами (к которым относится драйвер DBF в 1С) стали более строгими.
Когда вы запускаете .bat файл вручную, процесс выполняется в вашей текущей пользовательской сессии. В этой сессии загружены все региональные настройки, включая переменные окружения и настройки кодовых страниц. Однако планировщик заданий часто запускает процессы в так называемой Сессии 0 (Session 0 Isolation). Это неинтерактивная сессия, где окружение может отличаться от пользовательского. Если в настройках планировщика выбрана опция «Выполнять вне зависимости от того, вошел пользователь в систему или нет», система может использовать системный профиль по умолчанию, где кодировка кириллицы не настроена должным образом.
Самый быстрый и эффективный способ, который помог автору темы, заключается в изменении режима запуска задачи. Рассмотрим этот процесс по шагам:
Почему это работает? В этом режиме задание запускается в контексте полноценного пользовательского сеанса, где гарантированно подгружаются корректные региональные стандарты. Однако помните, что в этом случае пользователь, под которым настроена задача, должен быть авторизован на сервере (хотя бы в режиме заблокированного экрана).
Если вам критически важно, чтобы задача выполнялась без активного входа пользователя (режим «Run whether user is logged on or not»), нам нужно заставить системные учетные записи «увидеть» русскую кодировку. Проанализируем, как это сделать:
Перейдите в Панель управления — Региональные стандарты — вкладка Дополнительно. Здесь вы уже наверняка установили «Язык для программ, не поддерживающих Unicode» как Русский. Но этого недостаточно для фоновых заданий.
Нажмите кнопку «Копировать параметры». В открывшемся окне вы увидите, какие настройки установлены для текущего пользователя, а какие — для системной учетной записи (Welcome screen / System account). Скорее всего, в колонке системной записи будет стоять английский язык. Установите галочки внизу окна:
После нажатия «ОК» система потребует перезагрузку. Это обязательный шаг, так как изменения вступают в силу на уровне ядра и системных служб.
Никогда не стоит полагаться только на системные настройки, если объект 1С XBase позволяет явно указать кодировку. Разберем пример кода, который гарантирует правильное создание файла:
ПутьКФайлу = "C:\Obrabotki\Data.dbf";
ФайлDBF = Новый XBase;
// Явно указываем кодировку.
// КодировкаXBase.OEM обычно соответствует кодовой странице 866 (DOS)
// КодировкаXBase.Ansi соответствует 1251 (Windows)
ФайлDBF.Кодировка = КодировкаXBase.OEM;
// Добавляем поля
ФайлDBF.Поля.Добавить("NAME", "S", 50);
ФайлDBF.Поля.Добавить("VALUE", "N", 10, 2);
// Создаем файл на диске
ФайлDBF.СоздатьФайл(ПутьКФайлу);
// Записываем данные
ФайлDBF.Добавить();
ФайлDBF.NAME = "Тестовая строка";
ФайлDBF.VALUE = 100.50;
ФайлDBF.Записать();
ФайлDBF.ЗакрытьФайл();
Проанализируем этот фрагмент: установка свойства Кодировка должна происходить ДО вызова метода СоздатьФайл. Если вы открываете существующий файл, убедитесь, что его внутренняя кодировка совпадает с той, которую вы указываете в коде.
В Windows Server 2019 появилась настройка, которая часто становится причиной «поломки» старых механизмов обмена. Проверим её состояние:
Важный момент: если эта опция включена, Windows пытается форсировать UTF-8 для всех процессов. Объект XBase, будучи старой технологией, не понимает этого и начинает записывать символы некорректно, что и приводит к появлению знаков вопроса.
Если вышеперечисленные методы не помогают, рассмотрим радикальный вариант — проверку кодовых страниц в реестре Windows. Это поможет, если планировщик упорно игнорирует региональные настройки.
Откройте редактор реестра (regedit) и перейдите в ветку:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
Проверьте следующие параметры:
ACP (ANSI Code Page) — должно быть значение 1251.OEMCP (OEM Code Page) — должно быть значение 866.Иногда помогает «подмена» западноевропейской кодировки русской на уровне системы. Для этого параметр 1252 меняют со значения c_1252.nls на c_1251.nls. Будьте осторожны с этим методом, так как он влияет на всю операционную систему.
Как отметили участники обсуждения, формат DBF и объект XBase являются морально устаревшими. Они сильно зависят от настроек операционной системы и драйверов. Если у вас есть возможность изменить формат обмена, рассмотрим альтернативы:
Подводя итог, можно сказать, что наиболее вероятная причина вашей проблемы на Windows Server 2019 — это работа задачи в Сессии 0 при включенной опции UTF-8 Beta или отсутствии синхронизации региональных настроек для System account. Проверьте эти настройки в первую очередь, и ваши файлы DBF снова станут читаемыми.