Files
cc-1c-skills/docs/1c-support-state-spec.md
T
Nick Shirokov 75a97d51ea docs(support-state): распознавание расширения (CFE) как безопасного пути
У расширения нет Ext/ParentConfigurations.bin, поэтому правки его
исходников не ограничиваются состоянием поддержки базовой конфигурации.
Расширение распознаётся позитивно — по <ConfigurationExtensionPurpose>
в Configuration.xml, что отделяет его от случая полностью снятой
поддержки (там bin тоже почти пуст) и даёт корректную диагностику.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 13:58:58 +03:00

14 KiB
Raw Blame History

Состояние поддержки конфигурации 1С — Ext/ParentConfigurations.bin

Спецификация формата файла Ext/ParentConfigurations.bin из XML-выгрузки конфигурации 1С (DumpConfigToFiles). Файл хранит состояние поддержки конфигурации: глобальную «возможность изменения», список конфигураций поставщика и пообъектные правила поддержки (на замке / редактируется с сохранением поддержки / снят с поддержки).

Это единственный исходник состояния поддержки в выгрузке: ни Configuration.xml, ни ConfigDumpInfo.xml, ни файлы объектов его не содержат. Знание формата нужно, чтобы статически (без запуска конфигуратора и без ИБ) определить, разрешено ли редактировать конкретный объект конфигурации поставщика.

Формат восстановлен реверс-инжинирингом на размеченных выгрузках (одиночная поддержка и образец с несколькими поставщиками), а не из документации 1С. Значения, помеченные наблюдаемые, подтверждены на конкретных объектах; помеченные (не до конца разобрано) — требуют дополнительных образцов.


1. Где лежит и когда есть

<configSrc>/
    Ext/
        ParentConfigurations.bin    # состояние поддержки (если конфигурация на поддержке)
Состояние Файл
Конфигурация на поддержке присутствует, размер от сотен КБ до единиц МБ (запись на каждый объект конфигурации поставщика)
Поддержка снята полностью присутствует, но усечён до ~16 байт (пустой контейнер)
Своя конфигурация (без поставщика) файла нет
Расширение (CFE) файла нет; редактирование исходников расширения не ограничивается состоянием поддержки базовой конфигурации

Грубый признак «это конфигурация поставщика» берётся независимо — из Configuration.xml: непустой <Vendor> + <Version>.

Расширение распознаётся позитивно по Configuration.xml: наличие <ConfigurationExtensionPurpose> (Customization / Patch / …). Это надёжнее, чем «отсутствие bin», и отделяет расширение от случая «поддержка снята полностью» (там bin тоже почти пустой). Правки исходников расширения всегда допустимы — это и есть безопасный путь доработки.


2. Кодировка и общий вид

  • Кодировка: UTF-8 с BOM (EF BB BF). Несмотря на расширение .bin, содержимое — текст.
  • Формат: 1С-овский фигурноскобочный контейнер { ... }, элементы через запятую, строки в двойных кавычках (внутренняя кавычка удваивается: "Фирма ""1С"""). Ровно одна пара { } на весь файл — вложенности нет.
{ 6, G, K,
    <блок поставщика 1>
    0,0
    <блок поставщика 2>
    0,0
    ...
    <блок поставщика K> }
  • 6 — маркер формата.
  • G — глобальная «возможность изменения» (§ 3).
  • K — число конфигураций поставщика на поддержке (§ 5). При одиночной поддержке K = 1.
  • Между блоками поставщиков — разделитель из двух токенов 0,0 (после последнего блока его нет).

Каждый блок поставщика:

guidA, X, guidПоставщика, "версия", "вендор", "имя", count,
   f1,f2,<uuidLocal>,<uuidVendor>,        ← записи объектов, count штук
   f1,f2,<uuidLocal>,<uuidVendor>,
   ...

Ключевая особенность: флаги f1,f2 стоят ПЕРЕД своим uuid, а не после. Это легко перепутать при наивном regex uuid,uuid,int,int.

Парсер, разбирающий весь файл по этой грамматике, потребляет 100% токенов на образце с K = 7 (458107 токенов, остатка нет) — грамматика подтверждена.


3. Глобальная «возможность изменения» (G)

Токен #2 контейнера (сразу после маркера формата 6):

  • G = 0 — изменение конфигурации поставщика включено; смотреть пообъектные правила f1 (§ 4).
  • G = 1 — изменение запрещено целиком. Вся конфигурация read-only независимо от пообъектных правил. В этом режиме f1 наблюдается равным 1 у всех объектов (значение неинформативно).

В блоке поставщика есть токен X (сразу после guidA), во всех образцах равный G (оба 1 при выключенной возможности, оба 0 при включённой). Отделить X от G по имеющимся образцам нельзя — для проверки достаточно трактовать G. (не до конца разобрано)


4. Блок поставщика и пообъектные правила

Поля заголовка блока:

Поле Значение
guidA GUID блока, меняется от выгрузки к выгрузке (идентификатор снимка)
X флаг, наблюдается равным G (§ 3)
guidПоставщика стабильный GUID конфигурации поставщика
"версия" версия конфигурации поставщика
"вендор" поставщик
"имя" имя конфигурации поставщика
count число записей объектов далее

Каждая запись объекта: f1, f2, <uuidLocal>, <uuidVendor>.

  • uuidLocal — uuid объекта в текущей конфигурации (совпадает с uuid="…" на корневом элементе файла объекта).
  • uuidVendor — uuid объекта в конфигурации поставщика. При одиночной поддержке обычно uuidLocal == uuidVendor; могут различаться.
  • Первая запись блока — корень конфигурации; при одиночной поддержке записывается одним uuid (без пары uuidVendor).
  • Присутствуют записи и на под-элементы (реквизиты, табличные части, формы и т.п.), поэтому записей кратно больше, чем объектов верхнего уровня.

Правило поддержки f1 (при G = 0)

f1 Правило 1С Редактирование
0 объект поставщика не редактируется (на замке) запрещено
1 объект поставщика редактируется с сохранением поддержки разрешено
2 объект снят с поддержки / не включён в поддержку данного поставщика разрешено

f2 во всех образцах = 0 (вторичный флаг; кейса на его переключение не встретилось — не до конца разобрано).

Проверка кодировки на диффе двух выгрузок одной конфигурации (включена возможность изменения → точечные правки правил):

…, 0→1 ,0, <uuid корня>           ← включение редактирования корня
…, 0→1 ,0, <uuid объекта>         ← редактируется с сохранением поддержки
…, 0→2 ,0, <uuid объекта>         ← снят с поддержки

Размер файла при смене правила не меняется (значения однозначные) — диффы точечные.


5. Несколько поставщиков (K > 1)

Когда конфигурация стоит на поддержке нескольких конфигураций поставщика, K > 1, и в контейнере идут K блоков подряд (через разделитель 0,0). Каждый блок — свой поставщик со своим count и своим набором записей.

Один и тот же объект (по uuidLocal) может присутствовать в нескольких блоках с разными правилами f1 — у каждого поставщика своё правило относительно его поставки. В образце с K = 7 таких объектов с расходящимися правилами — 166; наблюдаемые комбинации:

Комбинация f1 у разных поставщиков Сколько объектов Трактовка
0 и 1 127 у одного на замке, у другого редактируется с сохранением поддержки
1 и 2 38 у одного редактируется, у другого снят / не включён
0 и 2 1 у одного на замке, у другого снят / не включён

Объект, отсутствующий в блоке поставщика, в поддержку этого поставщика не входит.

Эффективное правило при конфликте

Для гейта «можно ли редактировать объект» важно: редактирование любого из поставщиков, где f1 = 0, нарушит поддержку этого поставщика. Поэтому консервативное (безопасное) правило свёртки:

объект считается на замке, если хотя бы у одного поставщика f1 = 0; иначе редактирование допустимо (1/2 у всех включающих его поставщиков).

Точная семантика «эффективного» правила, которую показывает сам конфигуратор при конфликте поставщиков, по имеющимся образцам не подтверждена — (не до конца разобрано). Для guardrail рекомендуется консервативная свёртка выше.


6. Алгоритм определения «можно ли редактировать объект» (статически)

1. Прочитать заголовок ParentConfigurations.bin в configSrc.
     файла нет / размер ≈16 байт  → поддержки нет          → редактирование РАЗРЕШЕНО
     G = 1                        → возможность выключена   → read-only ВСЁ (запрет)
     G = 0                        → перейти к шагу 2
2. Путь редактируемого файла → корневой .xml объекта:
     - сам файл объекта (Catalogs/X.xml, Documents/Y.xml) несёт uuid на корневом элементе;
     - файл внутри каталога объекта (Catalogs/X/Ext/ObjectModule.bsl,
       Catalogs/X/Forms/F/Ext/Form.xml) → подняться к корневому Catalogs/X.xml.
   ConfigDumpInfo.xml для этого НЕ нужен (его может не быть в выгрузке/гите).
3. Собрать f1 по этому uuid (как uuidLocal) во ВСЕХ блоках поставщиков:
     есть f1 = 0 хотя бы у одного   → на замке              → редактирование ЗАПРЕЩЕНО
     иначе (только 1/2)             → редактируется/снят     → РАЗРЕШЕНО
     uuid не найден ни в одном блоке → не на поддержке       → РАЗРЕШЕНО

Под-элемент (отдельный реквизит, форма) отдельно проверять не обязательно: его XML нельзя отредактировать, не затронув файл объекта, поэтому достаточно правила верхнего объекта.


7. Связанные форматы

Файл Спецификация
Configuration.xml (Vendor, Version) 1c-configuration-spec.md § 2
Ext/ (где лежит .bin) 1c-configuration-spec.md § 4.5
Расширения как альтернатива правке поставщика 1c-extension-spec.md