При разработке обменов данными с внешними системами через формат DBF мы часто сталкиваемся с ситуацией, когда файл, сформированный средствами 1С, кажется "битым" или некорректным. Рассмотрим распространенную проблему: файл создается на сервере, передается на клиент, но при открытии сторонним редактором (DBF Viewer, Excel и др.) мы видим пустые поля, сдвиг данных или "кашу" в текстовых полях. Разберем причины этого явления и способы решения.
Рассмотрим типичный сценарий. Мы формируем файл на сервере, используя объект XBase. Код выглядит абсолютно стандартно и корректно, ошибок при выполнении не возникает. Далее файл передается на клиент через временное хранилище.
Однако, открыв полученный файл в специализированном редакторе DBF, мы наблюдаем странную картину:
Первая мысль, которая возникает — файл повредился при передаче с сервера на клиент (через ДвоичныеДанные). Но давайте проанализируем код создания файла.
Взглянем на пример кода, который используется для генерации файла:
ИмяВременногоФайла = КаталогВременныхФайлов() + "temp.dbf";
ДБФ = Новый XBase;
// Определение структуры полей
ДБФ.Поля.Добавить("CODE", "N", 10, 0);
ДБФ.Поля.Добавить("LASTNAME", "S", 100);
ДБФ.Поля.Добавить("FIRSTNAME", "S", 100);
// ... добавление других полей ...
ДБФ.СоздатьФайл(ИмяВременногоФайла);
// Заполнение данными
Для Каждого СтрокаДанных Из ИсточникДанных Цикл
ДБФ.Добавить();
ДБФ.CODE = СтрокаДанных.Код;
ДБФ.LASTNAME = СтрокаДанных.Фамилия;
ДБФ.FIRSTNAME = СтрокаДанных.Имя;
// ...
ДБФ.Записать();
КонецЦикла;
ДБФ.ЗакрытьФайл();
Код выглядит правильным. Передача на клиент также выполняется стандартно:
Двоичное = Новый ДвоичныеДанные(ИмяВременногоФайла);
Адрес = ПоместитьВоВременноеХранилище(Двоичное, УникальныйИдентификатор);
УдалитьФайлы(ИмяВременногоФайла);
Возврат Адрес;
Если код верен, почему происходит сдвиг?
Чтобы понять истинную причину, необходимо исключить фактор "кривой передачи". Для этого выполним простую проверку: попробуем прочитать этот же файл средствами самой 1С сразу после скачивания.
Если мы напишем небольшую обработку чтения:
ДБФЧтение = Новый XBase;
ДБФЧтение.ОткрытьФайл(СкачанныйФайл);
Пока ДБФЧтение.Следующая() Цикл
Сообщить(ДБФЧтение.LASTNAME); // Проверяем вывод
КонецЦикла;
В большинстве случаев оказывается, что 1С читает этот файл абсолютно корректно. Все поля на своих местах, данные не искажены. Это означает, что:
Следовательно, проблема кроется в несовместимости формата, который генерирует 1С, с тем, как его интерпретируют сторонние программы (вьюверы).
В ходе обсуждения проблемы выяснилось, что часто причиной "сдвига" является использование строковых полей большой длины. Например, в конфигурации могут быть строки длиной 300, 500 или более символов.
Важно знать: Классический стандарт формата dBase III (на который ориентируется большинство драйверов) имеет жесткое ограничение на длину строкового поля — 254 байта.
Рассмотрим, что происходит "под капотом":
XBase в 1С достаточно гибок. Он позволяет создать поле типа "Строка" длиной, например, 300 символов, и успешно записывает туда данные. Платформа 1С при чтении такого файла также корректно обрабатывает эти 300 байт.Предположим, у нас есть поле DESCRIPTION длиной 300 символов, за которым идет поле DATE.
DESCRIPTION вьювер начинает интерпретировать как начало следующего поля (или следующей записи).Помимо длины строк, сдвиг или "кракозябры" могут быть вызваны некорректной интерпретацией заголовка файла.
Объект XBase позволяет задать кодировку:
ДБФ.Кодировка = КодировкаXBase.ANSI; // Или OEM
Однако даже при явном указании кодировки, 1С не всегда проставляет специфический байт "Language Driver ID" (LDID) в заголовке файла так, как этого ожидают некоторые драйверы Microsoft (например, Jet OLEDB) или BDE. Из-за этого "умные" вьюверы пытаются угадать кодировку или используют DOS-кодировку (CP866) для файла в Windows-кодировке (CP1251), что визуально портит данные, хотя структурно они могут быть верны.
Если вы столкнулись с проблемой отображения DBF файла, сформированного в 1С, выполните следующие шаги:
Как показала практика, один вьювер может показывать "кашу", второй — пустые поля, а третий (или Excel) — откроет файл идеально. Если файл читается хотя бы одной программой (особенно самой 1С) корректно — файл структурно цел. Проблема на стороне программы-читателя.
Если файл предназначен для загрузки в чужую систему (например, банк-клиент или государственную систему), строго следуйте спецификации:
XBase в 1С имеет ограниченную поддержку Memo.Если программное создание структуры через ДБФ.Поля.Добавить() приводит к ошибкам совместимости, используйте проверенный метод:
ДБФ.ОткрытьФайл() и просто добавляйте записи.Это гарантирует, что заголовок файла будет на 100% соответствовать ожиданиям принимающей стороны.
Если XBase не справляется (нужны специфические типы полей или строгая совместимость с драйверами Microsoft), используйте COM-объект ADODB.Connection и работу через SQL-запросы к драйверу Microsoft.Jet.OLEDB.4.0 или VFPOLEDB. Это более сложный, но надежный путь для интеграции с legacy-системами.
Подводя итог: если вы видите сдвиг данных в стороннем редакторе, первым делом проверьте длину строковых полей в вашей выгрузке. Скорее всего, вы вышли за пределы 254 символов, и "классические" парсеры DBF не могут корректно обработать такой файл.