1c-conf-db-extractor (confdb)

Экстрактор конфигурации 1С:Предприятие 8 в базу данных SQLite.

Назначение: распаковать бинарный файл конфигурации (.cf, .cfe, .epf) без технологической платформы 1С и разложить его содержимое в реляционную базу, пригодную для генерации кода 1С (LLM/RAG и скрипты).

Алгоритм распаковки портирован из проекта v8unpack (MIT, см. NOTICE.md) — только в одну сторону: распаковка и разбор, без обратной сборки.

Использование

:: установка в venv (один раз)
.venv\Scripts\python.exe -m pip install -e .

:: распаковка cf в базу данных (+ дерево распакованных файлов для отладки)
confdb extract file.cf --db out.db --dump _out\file

:: то же через confdb.bat
confdb.bat extract file.cf --db out.db

:: текстовый консольный интерфейс (меню с обновлением экрана:
:: извлечение, запросы, проверка СКД, запуск MCP-сервера
:: с одной базой/несколькими/именованной группой, опции)
confdb-ui.bat

:: проверка корректности запросов СКД в готовой базе (пункт 5 в confdb-ui)
confdb check out.db

:: бенчмарк: подбор числа процессов под железо
:: (в confdb-ui — внутри пункта 3 «Опции извлечения»)
confdb bench file.cf

По умолчанию любая ошибка декодирования объекта прерывает извлечение. Флаг --skip-errors (в консольном интерфейсе — опция 6 «Пропускать ошибки объектов») пропускает сбойные объекты и продолжает разбор: каждый пропуск печатается с внутренней причиной, в конце — итоговое число. Дамп и база при этом неполные (пропущенные объекты и их подобъекты отсутствуют) — режим для больших конфигураций, где единичный сбойный объект не должен блокировать всю выгрузку.

Related MCP server: 1C MCP Server

Проверка запросов СКД

confdb check <база> (и пункт 5 консольного интерфейса) прогоняет все запросы таблицы skd_query через встроенный разборщик языка запросов 1С (src/confdb/query_lang.py):

• синтаксис: ПОМЕСТИТЬ/УНИЧТОЖИТЬ, ОБЪЕДИНИТЬ [ВСЕ], соединения (включая вложенные и перечислением), вложенные запросы, ВЫБОР/ВЫРАЗИТЬ, виртуальные таблицы с аргументами, параметры &…, необязательные области СКД {…}, ДЛЯ ИЗМЕНЕНИЯ;

• семантика по метаданным: существование таблиц (Справочник.Х, РегистрНакопления.Х.Обороты и т.п.), существование полей первого уровня (meta_attribute + стандартные поля + общие реквизиты, без учёта регистра), цепочки разыменования ссылок через attribute_ref (второй и далее уровни — мягко: составные/абстрактные типы не всегда раскрываются).

Код возврата 1 и список сообщений — если какой-то запрос не прошёл.

1confdb-knw — MCP-сервер для внешних LLM

:: сервер знаний по конфигурации 1С и BSL; stdio (JSON-RPC, read-only)
1confdb-knw.bat out.db
:: то же через CLI: confdb 1confdb-knw out.db
:: несколько баз сразу: основная конфигурация + расширения/обработки
1confdb-knw.bat main.db extension.db processor.db

Путь к базе можно не указывать: 1confdb-knw.bat без аргумента берёт last_db из ~/.confdb/config.json, а при его отсутствии сам ищет *.db/*.sqlite — в текущем каталоге, db/ и _out/ (и в корне установки при запуске из venv). Одна база — запускается; несколько — сервер печатает список и просит указать путь явно. Несуществующий путь — сразу «Файл базы не найден» (код 2), без падения на первом запросе. Свежая установка с базой, привезённой с другого компьютера, работает без ручной правки конфига: достаточно положить файл в db/ рядом с 1confdb-knw.bat.

16 инструментов: find_objects, object_card (паспорт объекта: реквизиты, табличные части, модули, ссылки), object_tree, find_field, refs_of, module_outline, get_method, find_methods, skd_of, find_skd, check_query (валидатор запроса 1С), sql (только SELECT) и управление базами db_list / db_open / db_use / db_close. Инструкции протокола (initialize.instructions) и описания инструментов содержат справочник по схеме базы, глоссарий 1С и рекомендуемый рабочий процесс — любая модель пользуется сервером без контекста этого проекта.

Несколько баз одновременно (расширения и обработки)

Сервер держит несколько баз сразу: перечислите их при запуске либо открывайте на ходу инструментом db_open (без перезапуска сервера). Каждая база получает алиас (по умолчанию — имя файла без расширения; при совпадении — с суффиксом _2, _3…). Все инструменты по умолчанию работают с активной базой (при запуске — первая указанная); чтобы запросить другую базу без переключения, передайте её алиас параметром db (есть у всех инструментов). Переключение активной базы — db_use, список открытых баз со статистикой — db_list, закрытие — db_close.

Типовой сценарий: извлечь основную конфигурацию, расширение и обработку в отдельные базы и запустить сервер со всеми тремя —

confdb extract main.cf --db main.db
confdb extract ext.cfe --db ext.db
confdb extract proc.epf --db proc.db
1confdb-knw.bat main.db ext.db proc.db

— после чего LLM видит метаданные и код всех трёх и может, например, искать методы расширения (find_methods с db='ext') поверх основной конфигурации. Специальное значение db='*' выполняет инструмент сразу по всем открытым базам (ответ приходит секциями по базам) — один вызов, чтобы сравнить основную конфигурацию с расширениями. Если база пересобрана (повторный extract), её достаточно закрыть и открыть заново: db_close + db_open.

В консольном интерфейсе наборы баз можно сохранить в именованные группы (пункт 6): одна база может входить в несколько групп; пункт 1 запускает сервер с группой или с выбранными вручную базами (одной или несколькими), а в сетевом режиме панель после запуска позволяет подключать/закрывать базы и применять группу (перезагружать набор) без перезапуска сервера.

Пример конфигурации MCP-клиента, в т.ч. через SSH:

{
  "mcpServers": {
    "1confdb-knw": {
      "command": "ssh",
      "args": ["user@host", "python", "-m", "confdb.mcp_server", "/path/out.db"]
    }
  }
}

Сетевой режим (когда stdio не подходит)

Сервер слушает порт и отдаёт MCP по HTTP (Streamable HTTP: POST /mcp; legacy SSE для старых клиентов: GET /sse + POST /messages):

1confdb-knw.bat out.db --port 8765

С другой машины подключение — через SSH-туннель:

ssh -L 8765:127.0.0.1:8765 user@host

{
  "mcpServers": {
    "1confdb-knw": { "url": "http://127.0.0.1:8765/mcp" }
  }
}

По умолчанию слушает 127.0.0.1 (без аутентификации, база read-only); --host 0.0.0.0 открывает порт наружу — используйте только в доверенной сети. В консольном интерфейсе — пункт 1 → «Сеть (HTTP-порт)».

Опции extract:

• --db FILE — записать результат в SQLite;

• --dump DIR — сохранить распакованное дерево файлов (нужен хотя бы один из --db/--dump);

• --temp-dir DIR, --keep-temp — рабочий каталог стадий 0–1 и его сохранение;

• --prefix STR — снять префикс с имён объектов;

• --store-blobs — хранить бинарные файлы (картинки, макеты) в БД как BLOB;

• --workers N — число процессов стадии 3 и записи БД (по умолчанию — результат confdb bench или 1; на многоядерной машине несколько процессов ускоряют разбор в несколько раз). В консольном интерфейсе — меню «Опции извлечения». При вызове extract() из собственного скрипта на Windows с workers > 1 вызов должен быть обёрнут в if __name__ == '__main__': (требование multiprocessing spawn).

Бенчмарк и автонастройка

confdb bench <file> один раз прогоняет стадии 0/1, затем нелинейный сэмпл объектов верхнего уровня (шаг по всему списку + покрытие всех типов объектов, чтобы задеть и лёгкие справочники, и тяжёлые формы/отчёты) через стадию 3 и запись БД при 1/2/4/8/CPU процессах. Лучшее число процессов сохраняется в ~/.confdb/config.json и подставляется по умолчанию в extract и в консольный интерфейс; --workers N переопределяет вручную.

Стадии конвейера (повторяют v8unpack, только распаковка):

1. чтение внешних V8-контейнеров (32/64-бит) в файлы как есть;

2. inflate (raw deflate) + рекурсивные вложенные контейнеры;

3. декодирование метаданных: скобкофайлы {} → JSON, тексты модулей → .bsl.

Схема базы данных

• source — исходный файл: путь, дата, тип/имя/uuid корневого объекта;

• meta_object — объект метаданных: path (например Catalog/Контрагенты/CatalogForm/ФормаЭлемента), type (Catalog, Document, CommonModule, …), type_ru (русское имя «как в конфигураторе»: Справочник, Документ, Общий модуль, …), name, uuid, comment, obj_version, header_json (полный разобранный заголовок), parent_id + ord (иерархия и порядок братьев — как в дереве конфигуратора);

• meta_attribute — реквизиты объекта: ord, name, type_str в порядке объявления. Примитивы — Строка(50)/Число/Дата/Булево; ссылки — Ссылка: <путь> (таблица ссылочных uuid из потока .10 корневого объекта, коллизии имён дизамбигуируются по типу объекта); определяемые типы — ОпределяемыйТип: <путь> (<состав>) (состав раскрывается); составные типы — члены через |; абстрактные («ЛюбаяСсылка» и т.п.) — Ссылка;

• attribute_ref — связи реквизитов с объектами метаданных: uuid (ссылочный uuid из дескриптора типа, для составных/определяемых типов — по строке на член) и object_id — объект, на который ведёт ссылка (NULL для абстрактных типов); зависимость «реквизит ↔ объекты» строится join'ом без разбора строк type_str;

• enum_value — значения перечислений (ord, name) в порядке объявления;

• predefined — предопределённые элементы (ord, name, code, display) из «Предустановленные данные.bin»;

• common_target — привязка общих реквизитов к объектам метаданных;

• meta_tabular — табличные части объекта (ord, name) в порядке объявления; поля табличных частей лежат в meta_attribute с заполненной колонкой tabular (имя секции) — цепочки вида Т.Товары.Наименование в запросах проверяются по этим данным.

• module — паспорт модуля: code_name (obj, mgr, mod, con, app …) и для общих модулей context (Сервер/Клиент/Вызов сервера/…), плюс body — текст модуля как есть без кода методов: комментарии, препроцессор #Если…, #Область…, директивы и сигнатуры вида Процедура Имя(п1, п2) Экспорт сохранены; подстановка method.body вместо каждой сигнатуры восстанавливает исходный модуль;

• method — только процедуры/функции: вид, имя, сигнатура, is_export, directives (строка &НаКлиенте, &НаСервере без скобок), description (блок комментариев непосредственно над методом, как есть с //), line_start/line_end, body — строго с Процедура/Функция по КонецПроцедуры/КонецФункции; #… и комментарии вне тела в метод не попадают;

• subsystem_content — состав подсистем (ссылки на объекты в порядке объявления) — для обхода дерева подсистем, как в конфигураторе;

• skd_query — запросы, извлечённые из макетов СКД объекта (ord, query), — для проверки корректности запросов 1С;

• file — прочие файлы дампа (help.html, инфо-JSON, картинки): путь, тип, размер, содержимое для текстовых (BLOB — только при --store-blobs).

Пример запроса:

-- реквизиты справочника с типами
SELECT a.name, a.type_str
FROM meta_attribute a JOIN meta_object o ON o.id = a.object_id
WHERE o.path = 'Catalog/Контрагенты' ORDER BY a.ord;

-- краткое представление модуля (текст без кода методов)
SELECT m.body FROM module m JOIN meta_object o ON o.id = m.object_id
WHERE o.path = 'Catalog/Контрагенты' AND m.code_name = 'obj';

-- тело конкретного метода
SELECT mt.body FROM method mt JOIN module m ON m.id = mt.module_id
JOIN meta_object o ON o.id = m.object_id
WHERE o.path = 'Document/Заказ' AND m.code_name = 'obj'
  AND mt.name = 'ПриПроведении';

Состав

• src/confdb/v8 — ядро распаковки (контейнеры 1С, inflate, скобкофайлы, метаданные);

• src/confdb/db — схема SQLite и запись результата;

• src/confdb/extract.py — конвейер стадий;

• src/confdb/query_lang.py — разбор и семантический контроль языка запросов 1С (подкоманда confdb check);

• tests — тесты на малых фикстурах (test.bat).

Требования

• Python 3.9+, только стандартная библиотека.