Как посмотреть структуру файла 1cd

Обновлено: 09.01.2025

«1С:Предприятие» поддерживает два варианта работы:
● файловый,
● клиент-серверный.

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

Ограничения файлового варианта

Особенности работы файлового варианта базы данных с файловой системой

Для корректной работы «1С:Предприятия 8» в файловом варианте и сохранения физической целостности файла базы данных важно, чтобы функции работы с файлами, предоставляемые операционной системой, выполнялись нормально. Некорректное выполнение функций работы с файлами (чтение, запись, установка блокировки, освобождение блокировки) может привести к разрушению файла базы данных. Редко, но случаи некорректного выполнения функций работы с файлами наблюдаются. Наиболее часто неприятности происходят, когда доступ к файлу базы данных осуществляется одновременно с нескольких компьютеров. Например, известен случай, когда при таких условиях результаты операций записи, произведенной «1С:Предприятием 8» на одном из компьютеров, оказались невидимыми для процесса «1С:Предприятия 8», работающего на другом компьютере. В результате произошло разрушение файла базы данных. Поэтому важно обеспечить условия, при которых операционной системе ничто не мешает точно и аккуратно работать с файлами баз данных. Известны следующие источники нарушения нормального функционирования:

Сбои в работе сети,
Влияние антивирусов,
Включенное автономное кэширование.

Могут быть и другие причины. Таким образом, во всех случаях использования файловой базы данных следует:

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

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

Размещение данных 1С:Предприятия 8

Размещение данных в файловом варианте

Данные, которые 1С:Предприятие использует всегда, могут быть разделены на 5 групп в соответствии с их назначением и мерой их ответственности:

Работа с новым форматом файловой базы данных

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

Если Вы хотите проверить параметры Вашей файловой базы данных, используйте следующий вызов утилиты (указав в команде правильный путь к Вашей базе данных):

Утилита тестирования chdbfl

Утилита предназначена для автономной проверки и исправления файлов базы данных.

Данная утилита предназначена для работы только с файловой базой данных. Утилита доступна только в 32-разрядном варианте. Файловая база данных используется:

для хранения информационной базы в файловом варианте;
хранения хранилища конфигурации.

Для запуска утилиты в каталоге установки системы «1С:Предприятие» нужно запустить приложение chdbfl. На экран выводится окно (см. рис.1)

Утилита тестирования и исправления информационных баз

Перед использованием данной утилиты следует обязательно сделать резервную копию файла базы данных.

В поле Имя файла БД указать или выбрать имя файла информационной базы.

Установить флажок Исправлять обнаруженные ошибки, если требуется исправлять обнаруженные при проверке ошибки. Также этот флажок следует установить, если необходимо выполнить оптимизацию размещения служебной информации, ускоряющей открытие информационной базы

Tool_1CD . exe C : \ Users \ Иван \ Documents \ 1c \ DemoSmallBusinessEduc \ 1Cv8.1CD - ExportAllToXML F : \ 1 С _ Аналитика \ db_xml \

Техническое описание внутреннего устройства опубликовано мной в статье Краткое описание формата файлов *.1CD (файловых баз 1Сv8). Однако она достаточно сумбурна, плоха для восприятия, поэтому здесь я попытаюсь описать формат немного более популярно. Чтобы не было путаницы с термином «файл», сразу замечу, что когда я буду иметь в виду файл базы *.1CD, я буду говорить «файл базы», когда же я буду говорить про внутренние файлы, содержащиеся внутри базы, я буду употреблять просто термин «файл».

На самом нижнем уровне файл базы данных 1CD состоит из страниц размером 4 килобайт (0x1000).

По сути, весь файл базы состоит из массива четырехкилобайтных страниц. Каждая страница имеет свой номер (индекс). Здесь и далее каждый прямоугольник с красной рамкой обозначает одну страницу.

Файлы

На более высоком уровне находятся файлы. Файл состоит из одной или более страниц. У каждого файла есть ровно одна заголовочная страница, в которой размещается массив номеров страниц размещения. В каждой странице размещения, в свою очередь, находится массив номеров страниц данных. Заголовочная страница и страницы размещения – это служебные страницы, которые нужны только для хранения служебных данных (сигнатура, длина файла, версия) и для нахождения страниц данных. Собственно содержимое файла хранится в страницах данных.

Структура таблиц

Каждая таблица состоит из нескольких файлов:

файла описания таблицы DESCR;
файла записей DATA;
файла индексов INDEX;
файла данных неограниченной длины BLOB.

Файл описания таблицы DESCR содержит текстовое описание таблицы – имя таблицы, состав полей и индексов. А также файл DESCR содержит номера файлов DATA, INDEX и BLOB. Таблица адресуется с помощью файла описания таблицы. Структуру файлов таблиц мы в данной статье рассматривать не будем, подробности можно узнать из моей статьи, ссылку на которую я приводил выше. Файл индексов может отсутствовать, если в таблице нет ни одного индекса. Файл данных неограниченной длины тоже может отсутствовать, если в таблице нет ни одного поля с данными неограниченной длины.

Адресация

База состоит из таблиц. Таблицы, в свою очередь, состоят из файлов. И наконец, файлы состоят из страниц. Адресом страницы является ее порядковый номер (индекс) в файле базы. Адресом файла является номер его заголовочной страницы. Адресом таблицы является адрес ее файла описания, а значит, номер заголовочной страницы файла описания. Т.е. о каком бы объекте мы бы не говорили – странице, файле или таблице, адресом объекта всегда является просто номер страницы.

Как запустить epf файл для выгрузки из 1С метаданных

for each fileName in FileList ( 'F:\1С_Аналитика\db_xml\*.xml' ) FROM '$(fileName)' ( XmlSimple , Table is [ Table / Fields / Field ] ) ;

После небольшой корректировки получаем отчет, можете скачать (но там ничего не понятно, нужна расшифровка метаданных): Таблицы и поля из 1С Предприятия 8.3 после обработки Tool 1CD.exe и выгрузкой в XML.xlsx

1С Script Builder реализован в виде внешней 1С-обработки и предназначен для автоматизированного проектирования скрипта загрузки данных из БД 1С версии 8.x в аналитическое приложение QlikView. Использование 1С Script Builder позволяет получить максимальную скорость загрузки данных и максимальную гибкость при формировании самых сложных запросов.

ВНИМАНИЕ! В коде последнюю запятую перед SQL надо удалить. Не знаю, как программными средствами убрать.

На вкладке LOAD Script For QlikView приведен загрузочный скрипт. Не забывайте про запятую, которую нужно убрать.

Данное описание не претендует на законченность, безошибочность и понятность.

Начало.

Описание формата приведено в терминах языка C. Размер типа char – 1 байт, размер типа short int – 2 байта, размер типа int и unsigned int – 4 байта. Префиксом 0x обозначаются шестнадцатеричные числа.

Файлы баз *.1CD состоят из блоков длиной 4096 байт (0x1000). Соответственно, длина файла всегда кратна 4096.

Блок 0.

Нулевой блок имеет следующую структуру:

char sig[8]; // сигнатура “1CDBMSV8”

unsigned int length;

Первые 8 байт – сигнатура базы «1CDBMSV8».

Следующие 4 байта - это версия базы. На данный момент мне встречались только версия «8.0.5.0» (ver1 = 8, ver2 = 0, ver3 = 5, ver4 = 0) – это базы 1Cv8.0 и версия «8.1.0.0» (ver1 = 8, ver2 = 1, ver3 = 0, ver4 = 0) – это базы 1Cv8.1 и 1Cv8.2.

Следующие 4 байт – длина базы (файла) в блоках.

Предназначение поля unknown неизвестно, всегда содержит 1.

Объекты.

Вся остальная информация в базе хранится в объектах (файлах базы). Каждый объект состоит из одного или более блоков. У каждого объекта есть один заголовочный блок, блоки с таблицей размещения, и собственно данные. Второе и третье может отсутствовать.

Структура первого блока каждого объекта такова:

char sig[8]; // сигнатура “1CDBOBV8”

int length; // длина содержимого объекта

unsigned int version;

unsigned int blocks[1018];

Первые 8 байт – сигнатура базы «1CDBOBV8».

Есть 2 типа объектов.

Блок 1. Таблица свободных блоков.

Первый тип объекта – это таблица свободных блоков. Признаком этого блока является поле version равное 0. Такой объект в базе всегда один, и его заголовочный блок располагается всегда в блоке со смещением 1 (т.е. по адресу 0x1000). Длина данных такого объекта равна (length * 4) байт.

В blocks содержатся номера блоков, в которых собственно и находится содержимое таблицы свободных блоков. Значащими являются ненулевые значения в массиве blocks. Содержимое таблицы свободных блоков – это просто массив номеров свободных блоков:

unsigned int free_blocks[length];

Таким образом, в базе содержатся ровно length свободных блоков.

Когда системе требуется новый блок для данных, то она берет последний свободный блок из массива free_blocks и уменьшает length на 1. Если свободных блоков нет, то он создается в конце файла базы. Блоки, содержащиеся в массиве blocks, не являются свободными, а принадлежат объекту – таблице свободных блоков. В blocks может содержаться больше блоков, чем необходимо для хранения массива free_blocks.

Остальные объекты.

Второй тип объектов характеризуется ненулевым значением поля version. Вся информация в базе, кроме блока 0 и таблицы свободных блоков хранится именно в таких объектах.

В поле length содержится длина в байтах данных объекта.

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

unsigned int datablocks[1023];

Поле numblocks указывает количество реальных значений в datablocks (от 1 до 1023). В datablocks содержатся индексы блоков, в которых находится собственно содержимое объекта (данные). Так как в одном блоке таблицы размещения может быть указано максимум 1023 блока с данными, то соответственно, максимальная длина данных, указанных в одном блоке таблицы размещения равна 1023 * 4096 = 4190208 байт (0x3ff * 0x1000 = 0x3ff000). Таким образом, из длины содержимого объекта length мы можем определить количество фактических значений в blocks. Если length равен 0, то в blocks нет значащих данных, иначе количество значений в blocks равно (length - 1) / 0x3ff000 + 1 (деление целочисленное, без остатка). А также можно вычислить максимальную длину данных одного объекта: 4190208 * 1018 = 4265631744 байт (1018 – максимальное количество значений в массиве blocks), это совсем немного меньше 4х гигабайт.

Повторим, в заголовочном блоке объекта находится массив blocks, содержащий индексы блоков с таблицей размещения. А в таблице размещения находятся блоки, содержащие сами данные.

Блок 2. Корневой объект.

Последним объектом с предопределенным расположением является корневой объект. Заголовочный блок корневого объекта располагается в блоке с индексом 2. Все остальные объекты базы могут быть получены через корневой объект. Структура данных этого объекта зависит от версии базы, хотя и различается несильно. Для версии базы «8.0.5.0» эта структура выглядит так:

Для версии «8.1.0.0» структура выглядит так:

Т.е. различаются эти структуры только длиной поля lang. В поле lang содержится код языка базы. Код языка базы представляет собой строку в ANSI-кодировке. Мне встречались только базы с кодами «ru_RU» и «en». На что влияют эти коды языка, я не знаю, возможно, на порядок сортировки строк при построении индексов.

В поле numblocks содержится количество элементов в массиве tableblocks. В массиве же tableblocks содержатся индексы объектов, содержащих все таблицы данных. Т.е. таблиц в базе ровно numblocks.

Объект таблицы.

Каждый объект таблицы, указанный в корневом объекте, содержит просто текстовое описание таблицы в Unicode. Вот пример описания таблицы:

Как видно из этого примера, здесь присутствуют имя таблицы (_Reference4), раздел описания полей таблицы (Fields), раздел описания индексов (Indexes), параметр Recordlock и раздел Files.

В разделе Files всегда содержатся три числа, которые содержат индексы заголовочных блоков объектов (по порядку) с записями таблицы, Blob-данными (строки неограниченной длины и двоичные данные) и индексами. Если какого-либо объекта у таблицы нет, то соответствующее число равно нулю.

В разделе Fields содержатся описания полей таблицы. Описание каждого поля содержит (по порядку): имя поля (FieldName), тип поля (FieldType), признак использования NULL (NullExists), длину (FieldLength), точность (FieldPrecision) и признак регистрочувствительности (FieldCaseSensitive).

Сколько байт занимает каждое поле в записи, и как его интерпретировать, зависит от параметров поля. Во-первых, если NullExists у поля равен 1, то первый байт поля является признаком NULL. Значение 0 этого байта означает, что поле не содержит значение (т.е. содержит NULL). В противном случае, поле содержит значение. Если же NullExists равен 0, то такого байта в поле нет.

Далее, размер и формат поля зависит от типа поля. Типы поля бывают такими:

«B» - двоичные данные. Длина поля равна FieldLength байт.
«L» - булево. Длина поля 1 байт. Нулевое значение байта означает Ложь, иначе Истина.
«N» - число. Длина поля в байтах равна Цел((FieldLength + 2) / 2). Числа хранятся в двоично-десятичном виде. Первый полубайт означает знак числа. 0 – число отрицательное, 1 – положительное. Каждый следующий полубайт соответствует одной десятичной цифре. Всего цифр FieldLength. Десятичная точка находится в FieldPrecision цифрах справа. Например, FieldLength = 5, FieldPrecision = 3. Байты 0x18, 0x47, 0x23 означают число 84.723, а байты 0x00, 0x00, 0x91 представляют число -0.091.
«NC» - строка фиксированной длины. Длина поля равна FieldLength * 2 байт. Представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
«NVC» - строка переменной длины. Длина поля равна FieldLength * 2 + 2 байт. Первые 2 байта содержат длину строки (максимум FieldLength). Оставшиеся байты представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
«RV» - версия. Длина поля 16 байт. Предположительно содержит четыре числа int.
«NT» - строка неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob. В объекте Blob содержится строка в формате Unicode.
«I» - двоичные данные неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob.
«DT» - дата-время. Длина поля 7 байт. Содержит данные в двоично-десятичном виде. Первые 2 байта содержат четыре цифры года, третий байт – две цифры месяца, четвертый байт – день, пятый – часы, шестой – минуты и седьмой – секунды, все также по 2 цифры.

Зная теперь длину в байтах каждого поля можно посчитать общую длину одной записи таблицы и смещение каждого поля в записи. Но для этого необходимо учесть следующее. Если в описании полей таблицы нет поля с типом версия (RV), но при этом параметр Recordlock равен 1, то в записи присутствует дополнительное поле, которое я для себя называю короткая скрытая версия. Длина этого поля равна 8 байт. В каждой записи самый первый байт – это признак удаленности записи (признак, что запись не занята). Если этот байт равен 1, то запись свободна, а следующие 4 байта содержат индекс следующей свободной записи. Из этого следует, что запись не может быть короче пяти байт. Если же первый байт записи содержит 0, то далее в записи следуют значения полей. Причем порядок полей определяется таким образом: превым всегда идет поле версии (или описанное в разделе Fields с типом RV или поле скрытой короткой версии), затем все остальные поля в том порядке, как они описаны в разделе Fields.

Объект записей таблицы.

Содержимое объекта записей таблицы содержит просто массив записей. Таким образом, длина данных этого объекта всегда кратна длине одной записи. Первая (точнее нулевая) запись всегда помечена как свободная, она содержит индекс следующей свободной записи (или 0, если таких нет). Т.е. с нее начинается цепочка свободных записей таблицы.

Объект Blob таблицы.

Объект содержит Blob-данные таблицы (строки неограниченной длины и двоичные данные неограниченной длины). Содержимое этого объекта состоит из блоков (не путать с блоками, из которых состоит файл 1CD) длиной 256 байт (0x100). Т.е. это просто массив блоков длиной 256 каждый. Поэтому длина данных объекта всегда кратна 256. Структура каждого блока объекта такова:

unsigned int nextblock;

short int length;

Поле nextblock содержит индекс следующего блока, содержащего продолжение данных, или 0, если следующего блока нет. Поле length содержит длину данных в этом блоке (максимум 250). Поле data содержит сами данные. Нулевой блок всегда считается свободным, в поле nextblock он содержит индекс следующего свободного блока. Таким образом, с нулевого блока начинается цепочка свободных блоков.

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

Объект индексов таблицы.

На данный момент структура индексов до конца не изучена.

Есть ряд утилит для работы с файлами *.1cd
В частности - V8TableSizes.exe (позволяет посмотреть - какая таблица занимает сколько места), Tool_1CD.exe (позволяет увидеть структуру таблиц и полей файловой базы 1Cv8, просмотреть содержимое таблиц).

Но - вот ведь незадача - таблицы представлены не в том виде, в котором мы из наблюдаем в конфигураторе (см. прикреплённую миниатюру).
Стал искать расшифровку. Нашёл [ общее описание ] .
Дальше - сел и написал обработку, которая будет выводить таблицу соответствий (надо было, конечно, сделать не обработку, а отчёт - но лень переделывать).
Сама обработка и результат её выполнения - прикреплены. Обработка выполняется для управляемых форм (т.е. в ЗиУП 2.5 она не запустилась, а в БП 3.0 - работает). Когда (если?) перепишу и для обычных - то выложу.

Переделал обработку - должна работать и с обычными, и с управляемыми формами

Понесло меня во все эти дебри после [ данной статьи ] , с такой, в том числе, информацией:

И так, что оказалось:
Если у вас конфа на базе БСП, как и у меня, то есть и все типовые на УФ (проверено на ут 11.1) то:
1. открываем Общие формы - ПечатьДокументов
2. В свойствах формы видим настройку
АвтоНавигационнаяСсылка = Истина
АвтоматическоеСохранениеДанныхВНастройках = Использовать
То есть что получается, каждый раз открывая эту общую форму (печатая документ) создается форма ПечатьДокументов с динамически сгенеренной ссылкой и при закрытии формы эта ссылка сохраняется в ХранилищеСистемныхНастроек
с миллионами вот таких 0978abfb_8f52_4070_aa7e_849dbe44c184/НастройкиОкна записей
Разумеется эти настройки никогда не будут считаны, а хранятся в базе мертвым грузом.
Что делать:
АвтоматическоеСохранениеДанныхВНастройках устанавливаем в Не использовать

ПС: у меня база похудела до 800мб, с 2,7 гб! просто почистив эти записи
Вот такой вот баг, по всей видимости существующий в БСП давно и до текущего дня не исправленный
ПС2: Баг работает как на 8.2 (хоть там нет свойства АвтоНавигационнаяСсылка, но все равно он ее генерит рандомно по умолчанию) так и на 8.3 где это свойство есть Истина

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

Сначала благодарности:

В первую очередь выражаю огромную благодарность Валерию Агееву (awa) - автору статей о формате файлов 1CD и утилиты Tool_1CD.

Также выражаю благодарность andrewks за статьи о восстановлении работоспособности файловой базы, которые помогли глубже разобраться со структурой файлов 1CD.

Благодарю Алексея Ермилова (Alex_E) за помощь в создании обработки.

Функционал:

Просмотр базы 1CD из любой другой конфигурации на управляемых формах (работает в "Такси")
Поддержка форматов 8.2.14.0 и 8.3.8.0.
Просмотр общей информации о таблицах базы (описание, размер записи, данные, BLOB, индексы и т.д.)
Просмотр общей информации о полях таблицы (тип, длина, NULL и т.д.)
Просмотр записей таблиц
Работа с полями BLOB:
- просмотр в 16-ричном виде
- просмотр в виде текста (используется ВК для распаковки deflate)
- сохранение значения поля BLOB в файл
Для чего можно использовать:
- Изучение физического представления базы
- Выгрузка данных на низком уровне
- Навигация по поврежденным базам (с ограничениями) для выявления повреждений. С помощью этой обработки были выявлены дефекты 3 "битых" баз, 2 из них полностью восстановлены. Для выявления дефектов писались скрипты для консоли кода, исправления вносились через сторонний 16-ричный редактор.
- Можно рассматривать как пример работы с бинарными данными (функции обработки можно использовать для любых других файлов, например, для графических или звуковых)
Интерфейс:
Почти весь функционал этой обработки был написан в рамках рабочей задачи, которая не требовала интерфейса. В итоге для этой обработки интерфейс был просто "прикручен" и дописано немного функций, а чтобы не изобретать велосипед, интерфейс был сделан похожим на интерфейс утилиты Tool_1C, автором которой является awa, без поддержки функций записи в базу из интерфейса.

Информация о таблице:

Информация о полях таблицы:

Операции над файлами таблицы:

Просмотр записей таблиц:

При чтении данных таблицы добавляются поля, начинающиеся с префикса "B1C_". В поле "B1CD_Deleted" записывается признак удаленной записи (для записи, помещенной в таблице на удаление, устанавливается ИСТИНА).

16-ричный просмотр страниц базы:

Консоль кода (КК):

Обработка содержит примеры скриптов. Вот, например, простой скрипт для получения DBNames из таблицы PARAMS:

Ограничения и работоспособность:

Версии до 2.0 тестировались на Windows 8 (32 bit) и на релизе платформы 8.3.5.1119.

Версия 2.0 тестировалась на Windows 10 Home (64 bit) и на релизе платформы 8.3.14.1630.

На данный момент не на все варианты повреждений файла 1CD есть проверка, этот функционал планируется доработать в будущем.

Планы по развитию функционала:

Сделать возможность редактирования страниц базы в 16-ричном режиме;

Для чтения двоичных данных использовать БуферДвоичныхДанных вместо компонент ActiveX;

Автоматическое выявление некоторых повреждений баз;

Работа с базой в "Режиме поврежденной базы";

Запись в базу ранее выгруженных и измененных данных;

Жду содержательных комментариев и замечаний по обработке.

Читайте также: