1c-export

Утилита для выгрузки конфигурации 1С:Предприятие 8.3 в исходники (XML + BSL) с последующей отправкой в Git. Один исполняемый файл на Windows, три режима работы:

Режим	Как запускается	Для чего
GUI	`1c-export.exe` без аргументов	Ручная выгрузка с кнопки, история выгрузок, коммит и push
CLI	`1c-export.exe --export-base ...`	Разовая выгрузка из скрипта или планировщика
watch	`1c-export.exe watch --bases bases.json`	Служба: следит за базами и выгружает только когда конфигурация реально изменилась

Что умеет выгружать:

Основную конфигурацию через ibcmd infobase config export, с инкрементальным режимом --sync (пишутся только изменившиеся файлы) и бинарным снимком base.cf.
Расширения через ibcmd, инкрементально по контрольным суммам из config extension list: выгружаются только изменённые, удалённые из базы удаляются из папки, для каждого сохраняется бинарный .cfe.
Дополнительные отчёты и обработки БСП (справочник ДополнительныеОтчетыИОбработки) напрямую из MS SQL Server по протоколу TDS, без Конфигуратора: распаковка ХранилищеЗначения, сверка MD5 с реквизитом КонтрольнаяСумма, затем нативный разбор .epf/.erf в дерево BSL + JSON (формат совместим с v8unpack).

Требования: Windows, платформа 1С 8.3 с ibcmd.exe, MS SQL Server как СУБД (PostgreSQL не поддерживается), git в PATH.

Содержание

Установка и сборка
Структура выгрузки
GUI
CLI
Режим watch
Выгрузка дополнительных обработок из MS SQL
Локальное состояние: state.db, state/, логи
Коды возврата и типовые ошибки
Безопасность
Разработка и тесты

1. Установка и сборка

Готовый бинарник

Скачайте 1c-export.exe из раздела Releases и положите в отдельную папку, например C:\1c-export\. Рядом с ним утилита создаёт state.db (см. раздел 7), поэтому папка должна быть доступна на запись.

Сборка из исходников

Нужен Rust stable (toolchain x86_64-pc-windows-gnu или -msvc).

cd C:\1c-export-src && cargo build --release

Результат: target\release\1c-export.exe (около 6–7 МБ: внутри клиент MS SQL, SQLite, HTTP-клиент, GUI на Win32).

Особенности:

В release-сборке консольное окно скрыто (windows_subsystem = "windows"). В CLI-режиме вывод идёт в stdout, в watch-режиме дублируется в файл. В debug-сборке консоль остаётся.
Если путь к исходникам содержит кириллицу, компоновщик MinGW (ld.exe) падает. Вынесите каталог сборки в ASCII-путь через локальный .cargo/config.toml (файл не хранится в репозитории):
```
[build]
target-dir = "C:/rust-target"
```

Запуск от администратора

Для доменной (Windows-интегрированной) авторизации в MS SQL и для записи в защищённые каталоги может потребоваться запуск с повышенными правами. Обёртка scripts/run-1c-export.bat сама перезапускает себя через UAC и передаёт все аргументы дальше.

2. Структура выгрузки

outputPath (он же каталог Git-репозитория выгрузки) после полного цикла:

<outputPath>/
├── base/                       ← XML-исходники основной конфигурации (ibcmd config export)
│   └── ConfigDumpInfo.xml      ← служебный файл ibcmd, нужен для режима --sync
├── extensions/
│   ├── <ИмяРасширения>/        ← XML-исходники каждого расширения
│   └── .extensions-hashes.json ← контрольные суммы расширений на момент выгрузки
├── External/                   ← дополнительные отчёты и обработки БСП
│   ├── <ИмяОбработки>/         ← разобранная обработка: *.json, *.bsl, макеты
│   │   ├── ExternalDataProcessor.json
│   │   ├── ExternalDataProcessor.obj.bsl
│   │   ├── Form/<ИмяФормы>/Form.json, Form.elem.json, Form.obj.bsl
│   │   └── Template/<ИмяМакета>/Template.json, Template.mxl | .html | .bin | .c1b64
│   └── <Имя>.epf | .erf        ← только то, что нативный разбор не смог обработать
└── _artifacts/                 ← только при saveArtifacts: true (или --save-artifacts)
    ├── base.cf                 ← бинарный снимок конфигурации (ibcmd config save)
    └── extensions/<Имя>.cfe    ← бинарные снимки расширений

Каталог _artifacts/ появляется только при включённой настройке saveArtifacts (или ключе --save-artifacts); по умолчанию бинарные снимки не сохраняются и каталог не создаётся. Они нужны для надёжного развёртывания на тестовый стенд через ibcmd config load + apply. В режиме watch с changeDetection = sql снимок base.cf обновляется только когда менялась основная конфигурация (если снимка ещё нет, он делается в любом случае). Если снимки включены, они большие — в репозитории выгрузки стоит подключить Git LFS:

_artifacts/**/*.cf  filter=lfs diff=lfs merge=lfs -text
_artifacts/**/*.cfe filter=lfs diff=lfs merge=lfs -text

Служебные каталоги External/processings/ (сырые .epf из базы) и External/processings_src/ удаляются в конце цикла и в репозиторий не попадают.

3. GUI

Запуск без аргументов. Окно на нативных контролах Windows (GDI), работает в RDP-сессиях и на серверах без видеокарты и OpenGL.

Вкладки:

Настройки — подключение: сервер MS SQL, сервер 1С (если кластер и СУБД на разных машинах), база, авторизация в ИБ (Windows или логин/пароль), путь к ibcmd.exe, путь выгрузки, адрес удалённого Git-репозитория (origin). Кнопки «Сохранить настройки» и «Сбросить по умолчанию».
Выгрузка — что выгружать и как: для каждой из трёх операций (основная конфигурация, расширения, дополнительные обработки) переключатель «Инкрементально / Полностью». «Полностью» очищает папку операции и выгружает заново. Отдельно: число потоков ibcmd, способ подключения к СУБД (доменная авторизация или логин/пароль SQL), авторизация Git (доменная через Credential Manager или логин/пароль), концы строк git (core.autocrlf: false, true, input, «как на машине»), флаг --rediscover. Кнопки «Начать выгрузку», «Остановить», «Git commit && push», «Пушить принудительно (с ошибками)».
Лог — вывод текущей операции, «Копировать лог», «Очистить лог».
История — журнал выгрузок из state.db: время, база, статус, длительность, что выгружено, текст ошибки. Двойной щелчок открывает окно подробностей.

Если рядом с исполняемым файлом (или в текущем каталоге, или в deploy/) лежит bases.json из режима watch, GUI показывает выпадающий список «База» и подставляет настройки выбранной базы. Поле «Git remote (origin)» при сохранении пишется обратно в bases.json для этой базы.

4. CLI

Полный список ключей: 1c-export.exe --help. Ключи переопределяют значения из файла конфигурации.

Файл конфигурации

По умолчанию ищется config\config.json рядом с исполняемым файлом, явно задаётся через --config. Пример (см. config/config.example.json):

{
  "sqlServer": "sql-server",
  "server1C": "app-server-1c",
  "database": "demo-ut",
  "sqlDatabase": "demo-ut",
  "authentication": { "type": "password", "login": "export_user", "password": "" },
  "ibcmdPath": "C:/Program Files/1cv8/8.3.27.1786/bin/ibcmd.exe",
  "outputPath": "C:/Repos/demo-ut",
  "logLevel": "info",
  "extensions": []
}

Поле	Назначение
`sqlServer` (синоним `server`)	Сервер MS SQL. Используется для прямого TDS-подключения при выгрузке обработок и для `ibcmd --db-server`
`server1C`	Сервер кластера 1С для `ibcmd --ibconnection` и команд `1cv8.exe`. Пусто — берётся `sqlServer`
`database`	Имя информационной базы в кластере
`sqlDatabase`	Имя физической базы в MS SQL. Пусто — берётся `database`
`authentication.type`	`os` (Windows-аутентификация в ИБ) или `password`
`ibcmdPath`	Полный путь к `ibcmd.exe`. `1cv8.exe` берётся из той же папки, когда нужен
`outputPath`	Каталог выгрузки, он же Git-репозиторий
`mcpUrl`, `mcpApiKey`	Адрес и ключ HTTP-сервиса базы (нужен только режиму `changeDetection = eventlog` в watch и запасному пути определения структуры хранения, см. разделы 5 и 6)
`gitRemoteUrl`	`origin` для кнопки «Git commit && push» в GUI
`gitAutocrlf`	Значение `core.autocrlf` для git-команд программы. `false` по умолчанию: файлы хранятся как выдал ibcmd, без перекодировки концов строк. Допустимо `true`, `input`, пусто — настройка машины
`logLevel`	Подробность журнала: `info` (по умолчанию) — старт, найденные настройки, ход выгрузки, ошибки; `debug` — плюс пошаговая трассировка запуска GUI для разбора зависаний
`formEventsPath`	Путь к JSON-файлу с именами событий форм для раскладки в формат Конфигуратора: `{"<uuid события>": "ИмяСобытия"}`. Пусто (по умолчанию) — `form-events.json` рядом с exe. Файла нет — используется встроенная таблица. Записи файла дополняют её и переопределяют совпадающие; негодные записи (идентификатор не uuid, пустое имя или имя с пробелами) отбрасываются поимённо с предупреждением в журнал
`saveArtifacts`	`false` по умолчанию; бинарные снимки `.cf`/`.cfe` в `_artifacts/` для развёртывания на стенд через `ibcmd config load`

Ключи подключения

--server, --server-1c, --database, --auth-type os|password, --login, --password, --ibcmd-path, --output-path, --config.

Что выгружать

Ключ	Действие
`--export-base`	Основная конфигурация в `base/`
`--export-extensions`	Все расширения в `extensions/`
`--export-processings`	Дополнительные отчёты и обработки в `External/` (раздел 6)
`--save-artifacts`	Дополнительно сохранять бинарные снимки `.cf`/`.cfe` в `_artifacts/`. По умолчанию выключено

Хотя бы один из первых трёх обязателен.

Параметры ibcmd

Ключ	Действие
`--ibcmd-db-auth-windows`	Доменная авторизация в СУБД. Без ключа нужны `--ibcmd-db-user` и `--ibcmd-db-pwd`
`--ibcmd-use-connection-string`	Подключение через кластер (`--ibconnection=Srvr=..;Ref=..`) вместо прямого к СУБД
`--ibcmd-dbms`	Тип СУБД, по умолчанию `MSSQLServer`
`--ibcmd-jobs N`	Число потоков ibcmd, `0` = автоматически
`--ibcmd-sync`	Инкрементальная выгрузка основной конфигурации. При первой выгрузке в пустую папку `--force` подмешивается автоматически
`--ibcmd-force`	`--force` для ibcmd: при несовпадении формата `ConfigDumpInfo.xml` делает полный дамп вместо ошибки
`--ibcmd-incremental`	Инкрементальная выгрузка расширений по контрольным суммам
`--processings-full`	Полная перезапись `External/` вместо инкремента
`--rediscover`	Заново определить SQL-имена таблицы и полей справочника обработок
`--discovery sql\|mcp\|auto`	Источник SQL-имён: напрямую из MS SQL, через HTTP-сервис базы, либо сначала MS SQL с откатом на сервис (по умолчанию)
`--verbose`	Печать итоговой конфигурации перед запуском

Git после выгрузки

Ключ	Действие
`--git-push`	После успеха: `git add -A`, `git commit`, `git push` в `--git-repo` (по умолчанию `--output-path`)
`--git-auth-type domain\|password`	`domain` — Credential Manager, SSH-агент или другой credential helper. `password` — логин и пароль подставляются в URL `origin` на время push, спецсимволы кодируются
`--git-user`, `--git-password`	Для `--git-auth-type password`
`--git-message`	Сообщение коммита, по умолчанию `Update_ГГГГММДД`

Примеры

Полная выгрузка конфигурации и расширений с настройками из файла:

C:\1c-export\1c-export.exe --config C:\1c-export\config\config.json --export-base --export-extensions --ibcmd-db-auth-windows

Инкрементальная выгрузка всего, 8 потоков, затем push:

C:\1c-export\1c-export.exe --config C:\1c-export\config\config.json --export-base --ibcmd-sync --export-extensions --ibcmd-incremental --export-processings --ibcmd-db-auth-windows --ibcmd-jobs 8 --git-push

Всё в ключах, без файла конфигурации, SQL-логин:

C:\1c-export\1c-export.exe --server sql-server --database demo-ut --auth-type password --login export_user --password <пароль> --ibcmd-path "C:\Program Files\1cv8\8.3.27.1786\bin\ibcmd.exe" --output-path C:\Repos\demo-ut --export-base --ibcmd-sync --ibcmd-db-user sa --ibcmd-db-pwd <пароль>

5. Режим watch

1c-export.exe watch --bases <путь>\bases.json [--once]

Один процесс обслуживает несколько баз. Каждые N минут для каждой базы:

Проверяет, изменилась ли база. Способ задаётся полем changeDetection: sql (по умолчанию) — опрос служебных таблиц MS SQL, HTTP-сервис в базе не нужен; eventlog — журнал регистрации через HTTP-сервис базы, триггером считаются события применения конфигурации и изменения расширений (список trigger_events).
Если изменений нет, переходит к следующей базе.
Если есть, выполняет выгрузку по флагам базы теми же функциями, что CLI (без запуска дочернего 1c-export.exe).
Делает git add -A, git commit -m "auto: <alias> <дата время>", git push в gitRemoteUrl. При необходимости git init и git remote add origin выполняются автоматически.
Запоминает новое состояние базы: закладку журнала (eventlog) либо отпечатки служебных таблиц (sql). Запоминание происходит только после успешного push, поэтому при сбое изменения будут обработаны повторно в следующем цикле.
Пишет строку в журнал выгрузок state.db.

--once выполняет один цикл и завершает процесс. Так удобно запускать из планировщика задач Windows с внешним расписанием. Второй экземпляр watch одновременно не запустится (именованный мьютекс).

Что нужно от базы 1С

Watch не подключается к 1С через COM или Конфигуратор.

Режим sql (по умолчанию): только доступ к СУБД. Тот же доступ, по которому и так читается справочник обработок, — ничего публиковать в базе не нужно. Каждый цикл watch читает три служебные таблицы и сравнивает результат с сохранённым в state/<alias>.json:

Что отслеживается	Что читается	Признак изменения
Основная конфигурация	`MAX(Modified)` и число строк таблицы `Config`	Изменилась пара «время \| количество». Даты в `Config` хранятся со сдвигом на 2000 лет и берутся как строка, без толкования
Расширения	`_ExtName`, `_UpdateTime`, `_Version` из `_ExtensionsInfo`	Изменилась свёртка всего списка. Именно списка, а не максимума по времени: удаление расширения откатывает максимум назад
Дополнительные обработки	`_IDRRef` и поле-маркер изменения (`КонтрольнаяСумма` либо `ВерсияДанных`) таблицы справочника	Изменилась свёртка пар «ссылка \| маркер»

Читаются только те из трёх, что база реально выгружает (флаги exportBase, exportExtensions, exportProcessings). Первый цикл после запуска всегда делает выгрузку — сравнивать ещё не с чем.

Режим eventlog: HTTP-сервис внутри базы. Журнал регистрации и структуру хранения watch получает через HTTP-сервис, который вы публикуете на веб-сервере. Сервис должен принимать JSON-RPC по адресу <mcpUrl>/rpc с методом tools/call (протокол MCP) и поддерживать два инструмента:

Инструмент	Аргументы	Что должен вернуть
`eventlog_query`	`from` (строка `ГГГГ-ММ-ДДTЧЧ:ММ:СС`, включительно), `limit`, `filter.events` (массив имён событий)	JSON-массив записей журнала с полями `Дата`, `Событие`, `ИмяПользователя`, `Метаданные`, `Комментарий`, `ПредставлениеДанных`, `Уровень`
`db_table_fields`	`table` (полное имя объекта метаданных, например `Справочник.ДополнительныеОтчетыИОбработки`)	Текст со структурой хранения: строка `<SQL-имя таблицы> (<полное имя>, <назначение>):`, далее строки `<SQL-имя поля> = <имя реквизита>`

Ответ ожидается в стандартном формате MCP: result.content[0].text. Авторизация: Basic Auth логином и паролем пользователя ИБ плюс заголовок X-MCP-Key со значением mcpApiKey.

Инструмент db_table_fields нужен только если у базы включена выгрузка дополнительных обработок. Ответ кешируется в state/<alias>.json и обновляется раз в refetch_storage_mapping_after_days дней. В режиме sql структура хранения определяется прямо по служебным таблицам (раздел 6), сервис для этого не требуется.

bases.json

Пример с описанием всех полей: deploy/bases.example.json. Относительные пути (state_dir, log_dir, outputPath, ibcmdPath) считаются от каталога самого bases.json, так что папку службы можно переносить целиком.

Глобальные поля:

Поле	По умолчанию	Назначение
`check_interval_minutes`	30	Пауза между циклами
`lookback_hours_first_run`	168	Окно журнала для первого запуска базы (когда закладки ещё нет). Только для `changeDetection = eventlog`
`refetch_storage_mapping_after_days`	30	Как часто обновлять кеш SQL-имён справочника обработок
`state_dir`	`./state`	Каталог закладок журнала по базам
`log_dir`	`./logs`	Каталог файлов `watch-ГГГГ-ММ-ДД.log`
`logLevel`	`info`	Подробность журнала: `info` — старт, найденные настройки, ход выгрузки, ошибки; `debug` — плюс пошаговая трассировка запуска GUI для разбора зависаний
`trigger_events`	четыре события `_$InfoBase$_.DBConfig*`	Какие события журнала запускают выгрузку. Только для `changeDetection = eventlog`
`processingsMetaName`	`Справочник.ДополнительныеОтчетыИОбработки`	Имя справочника обработок в метаданных
`cache_proxy_url`	пусто	Если задан, после успешного push отправляется `POST <url>/flush?base=<alias>`

Поля записи в bases[]:

Поле	Назначение
`alias`	Уникальное имя базы: ключ в `state.db`, имя файла закладки, префикс в логе
`sqlServer`, `sqlDatabase`	Сервер и физическая база MS SQL
`server1C`	Сервер кластера 1С, если отличается от `sqlServer`
`ibcmdDbAuthWindows`	`true` — доменная авторизация в СУБД, `false` — нужны `dbUser` и `dbPwd`
`login`, `password`	Пользователь ИБ: используется и в `ibcmd --user`, и в Basic Auth к HTTP-сервису
`changeDetection`	Как узнавать об изменениях: `sql` (по умолчанию) — опрос служебных таблиц MS SQL, `eventlog` — журнал регистрации через HTTP-сервис базы
`mcpUrl`, `mcpApiKey`	Адрес HTTP-сервиса базы (`http://host/<база>/hs/mcp`) и ключ. Только для `changeDetection = eventlog`
`ibcmdPath`	Путь к `ibcmd.exe`
`outputPath`	Каталог выгрузки и Git-репозиторий
`gitRemoteUrl`	`origin`. Пусто — должен быть настроен в репозитории заранее
`gitAutocrlf`	Значение `core.autocrlf` для git-команд программы. `false` по умолчанию: файлы хранятся как выдал ibcmd, без перекодировки концов строк. Допустимо `true`, `input`, пусто — настройка машины
`gitAuthType`, `gitUser`, `gitPassword`	`domain` или `password`, как в CLI
`exportBase`, `exportExtensions`, `exportProcessings`	Что выгружать (по умолчанию `true`, `true`, `false`)
`ibcmdSync`, `ibcmdIncremental`, `processingsIncremental`	Инкрементальные режимы (по умолчанию `true`)
`saveArtifacts`	`false` по умолчанию; бинарные снимки `.cf`/`.cfe` в `_artifacts/` для развёртывания на стенд через `ibcmd config load`
`ibcmdJobs`	Потоки ibcmd
`gitGcAfterPush`, `gitGcAggressive`	Запускать `git gc` после push; `--aggressive` держит репозиторий плотным, но в разы медленнее. Автоматическая упаковка git внутри коммита отключена (`gc.auto=0`), упаковкой управляет `gitGcAfterPush`

Регистрация службы

Вариант с планировщиком задач Windows (запуск раз в 30 минут, скрытое окно, учётная запись с доступом к СУБД и Git):

schtasks /Create /TN "1c-export-watch" /SC MINUTE /MO 30 /RU "DOMAIN\svc-export" /RP * /RL HIGHEST /TR "C:\1c-export\1c-export.exe watch --bases C:\1c-export\bases.json --once"

Вариант постоянного процесса: зарегистрировать 1c-export.exe watch --bases ... без --once как службу через nssm или аналог. Логи в log_dir, состояние в state_dir.

6. Выгрузка дополнительных обработок из MS SQL

Справочник ДополнительныеОтчетыИОбработки хранит файлы обработок в реквизите ХранилищеОбработки типа ХранилищеЗначения. Утилита читает его напрямую из таблицы справочника:

Лёгкий запрос: ссылка, наименование, вид, контрольная сумма всех непомеченных элементов.
Сравнение с прошлым состоянием из state.db: новые, изменённые, неизменные, удалённые.
Тяжёлый запрос только по новым и изменённым: поле хранилища, пакетами по 1000.
Распаковка ХранилищеЗначения (сжатый DEFLATE или несжатый вариант заголовка), сверка MD5 с КонтрольнаяСумма. При расхождении файл пропускается с предупреждением и в состояние не записывается.
Запись .epf/.erf (расширение по виду из перечисления ВидыДополнительныхОтчетовИОбработок), затем нативный разбор в дерево исходников в External/<Имя>/.
Удаление папок обработок, которых больше нет в базе.

В конфигурациях с БСП без реквизита КонтрольнаяСумма вместо него используется стандартное поле ВерсияДанных (rowversion).

Чем и как обработки разбираются на файлы

Разбор .epf/.erf делает сама утилита, встроенным разборщиком контейнера 1CV8 на Rust (src/v8container/). Внешние инструменты не нужны: ни v8unpack, ни Конфигуратор, ни клиент 1С; для этого шага платформа 1С на машине не требуется.

Как идёт разбор одного файла:

Контейнер → внутренние файлы. Читаются заголовок контейнера, оглавление и цепочки блоков; каждый внутренний файл распаковывается из DEFLATE (или берётся как есть, если не сжат).
Внутренние файлы → значения. Содержимое внутренних файлов — «скобочные» сериализованные списки 1С вида {…, "…", …} в UTF-8 или CP1251. Они разбираются в дерево значений.
Значения → объект метаданных. По идентификаторам типов в заголовке определяется, что это внешняя обработка или внешний отчёт, и собираются его части: модуль объекта, формы (управляемые и обычные) с модулями и описанием элементов, макеты (табличные документы .mxl, HTML, схемы компоновки, двоичные данные, макеты в base64 .c1b64).
Запись дерева в External/<Имя>/ — JSON-описатели, .obj.bsl, файлы макетов (состав каталога — раздел 2).

Формат вывода совпадает байт в байт с v8unpack 1.2.6 (saby): деревья можно сравнивать git diff с выгрузками, сделанными той утилитой, а имеющиеся потребители такого формата продолжают работать. Поддерживаются контейнеры платформ 8.2 и 8.3 (заголовок версии не ниже 216). Разбор идёт параллельно, до четырёх файлов одновременно.

Если файл разобрать не удалось (неподдержанный тип вложенного объекта, старый формат, повреждённый контейнер), он остаётся бинарём в корне External/, причина пишется в лог и в журнал выгрузок, обработка учитывается в failed и повторяется в следующем цикле.

Откуда берутся SQL-имена таблицы и полей

Имена _ReferenceNNN, _FldNNN уникальны для каждой базы и меняются при обновлении конфигурации. Источники, по приоритету:

Ключи CLI --processings-table, --processings-field-storage, --processings-field-hash, --processings-field-kind (указываются все четыре вместе). Имена можно посмотреть в Конфигураторе: «Все функции → Стандартные → Структура хранения базы данных».
Кеш в state.db от прошлого запуска (сбрасывается ключом --rediscover).
Определение напрямую из MS SQL — способ по умолчанию. Ни 1С, ни HTTP-сервис в базе для него не нужны, достаточно того же доступа к СУБД, по которому и так читается справочник:
- Params.DBNames — карта «идентификатор объекта метаданных → номер физической таблицы». Части блоба склеиваются по PartNo и разворачиваются DEFLATE.
- Описание каждого справочника берётся из Config по идентификатору из карты; в тексте описания ищется имя справочника в кавычках. Найденный номер даёт таблицу _ReferenceNNN.
- Имя реквизита стоит в описании в кавычках, а идентификатор реквизита — непосредственно перед ним; по карте он превращается в _FldNNN (или _FldNNNRRef для ссылочных). Кандидат сверяется с sys.columns — это и есть проверка правильности разбора.
- Тем же способом определяется таблица перечисления ВидыДополнительныхОтчетовИОбработок.
Инструмент db_table_fields HTTP-сервиса базы (раздел 5) — запасной путь: используется, только если определение по MS SQL не удалось и в конфигурации заданы mcpUrl с mcpApiKey. Если не сработали оба пути, выгрузка обработок завершается ошибкой, в тексте которой указана причина отказа определения по MS SQL.

Ключ --discovery задаёт источник принудительно: sql — только прямое определение по MS SQL, mcp — только HTTP-сервис базы, auto (по умолчанию) — порядок выше. Ключи CLI и кеш имеют приоритет над --discovery в любом режиме.

Если после обновления конфигурации запрос падает с Invalid column name, утилита сама запускает повторное определение имён и повторяет выгрузку.

В resources/ лежат тексты BSL для расширения, которое отдаёт структуру хранения по команде BatchGetProcessingsStructure через запуск 1cv8.exe ENTERPRISE. Этот путь в текущей версии из кода не вызывается и оставлен как задел.

Ограничения

Обработки БСП, защищённые паролем, пропускаются (MD5 не сходится).
Справочник ВнешниеОбработки старых конфигураций (УПП) не поддерживается.
Файл, который нативный разбор не смог обработать, остаётся бинарём в корне External/, причина пишется в лог и в журнал выгрузок.

7. Локальное состояние

state.db

SQLite-файл рядом с исполняемым файлом. Общий для всех баз, данные разделены по alias. Содержит:

ext_hashes — контрольные суммы расширений на момент последней выгрузки;
proc_items — состояние дополнительных обработок (UUID, MD5, путь);
proc_discovery — кеш SQL-имён справочника обработок и таблицы видов;
export_log — журнал выгрузок, который показывает вкладка «История».

Удаление файла означает полную перевыгрузку всех баз при следующем запуске. В Git-репозиторий выгрузки он не попадает.

state/.json (только watch)

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

Логи

CLI: stdout с отметками времени [ЧЧ:ММ:СС].
GUI: вкладка «Лог», плюс файл logs/gui-ГГГГ-ММ-ДД.log рядом с exe — в него пишутся шаги запуска окна и весь ход выгрузки (по последней строке видно, где программа встала, если окно перестало отвечать).
watch: log_dir/watch-ГГГГ-ММ-ДД.log, файл переоткрывается при смене даты. Паники также пишутся в файл.

Подробность задаётся полем logLevel в bases.json (или в config.json для одиночного режима): info по умолчанию, debug добавляет пошаговую трассировку запуска GUI.

8. Коды возврата и типовые ошибки

Код	Значение
0	Успех
1	Ошибка конфигурации или выгрузки
2	Выгрузка прошла, `git push` не удался

Сообщение	Причина и что делать
`Не выбрано ни одного действия для выгрузки`	Нет ни одного из `--export-*`
`--export-processings требует либо --ibcmd-db-auth-windows, либо связки --ibcmd-db-user/--ibcmd-db-pwd`	Не задан способ подключения к СУБД
`ошибка синхронизации` от ibcmd при `--sync`	Папка `base/` не пустая, но `ConfigDumpInfo.xml` от другой версии. Добавьте `--ibcmd-force` или выгрузите полностью
`Invalid column name '_FldNNN'`	Имена полей устарели после обновления конфигурации. Повторное определение запускается автоматически, вручную — `--rediscover`
`Для определения структуры хранения справочника допобработок нужен HTTP-сервис MCP в ИБ`	В конфигурации пустые `mcpUrl` или `mcpApiKey`. Задайте их, либо передайте четыре имени через ключи `--processings-*`, либо отключите выгрузку обработок
`alias '<база>': changeDetection=eventlog требует mcpUrl и mcpApiKey`	В `bases.json` выбран режим `eventlog`, но адрес или ключ HTTP-сервиса не заданы. Заполните их либо переключите базу на `changeDetection: "sql"`
`Authentication failed for 'https://...'` при push	Неверные учётные данные Git. Пароль в сообщении маскируется
`уже запущен другой экземпляр 1c-export watch`	Второй процесс watch в той же сессии. Дождитесь завершения первого

9. Безопасность

Пароли хранятся в открытом виде. Проект писался для личного использования на машинах, доступ к которым имеет один человек, поэтому логины, пароли и ключи лежат в config.json и bases.json открытым текстом, шифрование не реализовано. Если такой режим вам не подходит, ограничьте доступ к папке правами NTFS и запускайте службу от отдельной учётной записи, либо сделайте форк и добавьте шифрование полей (например, через DPAPI Windows или отдельный файл ключа).
Пароли передаются через ключи командной строки, файл конфигурации и bases.json. Держите эти файлы вне репозитория выгрузки и вне этого репозитория.
При --git-auth-type password логин и пароль подставляются в URL origin только на время push и затем возвращаются к прежнему значению. В логе URL с паролем маскируется.
Для доменной авторизации в СУБД и Git пароли нигде не хранятся: используются учётная запись процесса и Windows Credential Manager. Это предпочтительный вариант для службы watch.

10. Разработка и тесты

cd C:\1c-export-src && cargo test

Модули:

Файл	Назначение
`src/main.rs`	Разбор ключей (`clap`), выбор режима GUI / CLI / watch
`src/config.rs`, `src/bases_config.rs`	Форматы `config.json` и `bases.json`
`src/command_builder.rs`	Сборка командных строк `ibcmd.exe` и `1cv8.exe`
`src/runner.rs`	Запуск дочерних процессов, чтение логов 1С (UTF-8 и CP1251)
`src/export.rs`	Координатор: основная конфигурация, расширения, обработки, чистка, артефакты
`src/processings.rs`	TDS-подключение к MS SQL, распаковка `ХранилищеЗначения`, MD5
`src/storage_mapping.rs`	Разбор ответа `db_table_fields`
`src/v8container/`	Нативный разбор контейнера `.epf`/`.erf` в дерево BSL + JSON
`src/watch.rs`, `src/eventlog_watcher.rs`, `src/mcp_client.rs`	Режим watch
`src/git_push.rs`	Коммит, push, подстановка учётных данных, `git gc`
`src/state_db.rs`, `src/state.rs`	Локальное состояние
`src/gui.rs`	Окно на `native-windows-gui`
`src/logging.rs`	Логгер с ротацией файла по дате

Golden-тесты распаковщика (src/v8container/saby.rs) сравнивают результат байт в байт с эталонными деревьями в tests/fixtures/<Имя>/expected/. Сами фикстуры в репозитории не хранятся, при их отсутствии тесты пропускаются с сообщением. Чтобы прогнать их локально, положите в tests/fixtures/<Имя>/ файл <Имя>.epf и эталонное дерево, полученное v8unpack 1.2.6.

Лицензия: MIT.

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
config		config
deploy		deploy
resources		resources
scripts		scripts
src		src
CHANGELOG.md		CHANGELOG.md
Cargo.lock		Cargo.lock
Cargo.toml		Cargo.toml
LICENSE		LICENSE
README.md		README.md
build.rs		build.rs

Navigation Menu

Repository files navigation

1c-export

Содержание

1. Установка и сборка

Готовый бинарник

Сборка из исходников

Запуск от администратора

2. Структура выгрузки

3. GUI

4. CLI

Файл конфигурации

Ключи подключения

Что выгружать

Параметры ibcmd

Git после выгрузки

Примеры

5. Режим watch

Что нужно от базы 1С

bases.json

Регистрация службы

6. Выгрузка дополнительных обработок из MS SQL

Чем и как обработки разбираются на файлы

Откуда берутся SQL-имена таблицы и полей

Ограничения

7. Локальное состояние

state.db

state/.json (только watch)

Логи

8. Коды возврата и типовые ошибки

9. Безопасность

10. Разработка и тесты

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

1c-export

Содержание

1. Установка и сборка

Готовый бинарник

Сборка из исходников

Запуск от администратора

2. Структура выгрузки

3. GUI

4. CLI

Файл конфигурации

Ключи подключения

Что выгружать

Параметры ibcmd

Git после выгрузки

Примеры

5. Режим watch

Что нужно от базы 1С

bases.json

Регистрация службы

6. Выгрузка дополнительных обработок из MS SQL

Чем и как обработки разбираются на файлы

Откуда берутся SQL-имена таблицы и полей

Ограничения

7. Локальное состояние

state.db

state/.json (только watch)

Логи

8. Коды возврата и типовые ошибки

9. Безопасность

10. Разработка и тесты

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages