Разработка и Конфигурация · 10 мин
Как сравнить две обработки 1С
Как сравнить две внешние обработки 1С: сравнение файлов конфигурации, выгрузка в XML, сравнение модулей и кода. Пошаговые способы и частые ошибки.
Внешние обработки 1С (файлы .epf) часто существуют в нескольких версиях: одна лежит на сервере, другая — у коллеги, третья — в архиве. Когда поведение обработки меняется, первым делом нужно понять, чем именно отличаются файлы. Сравнить две обработки можно штатными средствами конфигуратора, через выгрузку в файлы XML или с помощью внешних инструментов сравнения кода.
Главная сложность в том, что .epf — бинарный контейнер: внутри него упакованы модули, формы, макеты и метаданные. Простое построчное сравнение файлов в блокноте ничего не даст — нужно либо распаковать обработку, либо использовать механизмы платформы. Ниже разобраны рабочие способы для разных ситуаций: от быстрой проверки «одинаковые ли файлы» до детального анализа различий в коде модулей.
Определите цель сравнения
Способ сравнения зависит от того, какой ответ вам нужен. Если требуется просто убедиться, что два файла идентичны, достаточно сравнить их контрольные суммы — это занимает секунды и не требует конфигуратора. Если нужно понять, что изменил разработчик в коде, придётся распаковывать обработки и сравнивать модули построчно.
Третья ситуация — сравнение обработки с версией, встроенной в конфигурацию, или с другой обработкой похожего назначения. Здесь важны не только модули, но и состав форм, макетов и реквизитов. Определите заранее, что именно сравниваете: код, структуру метаданных или и то и другое.
Как выбрать способ
Быстрая проверка идентичности через хеши
Если задача — выяснить, совпадают ли два файла побайтово, сравните их хеш-суммы. В Windows это делается штатной командой PowerShell без установки дополнительных программ. Одинаковый хеш означает, что файлы идентичны полностью; разный — что файлы отличаются, но не говорит, чем именно.
Get-FileHash "C:\Обработки\Обработка_v1.epf" -Algorithm MD5
Get-FileHash "C:\Обработки\Обработка_v2.epf" -Algorithm MD5Учтите важный нюанс: одинаковая по логике обработка, сохранённая повторно, может иметь другой хеш — платформа может менять служебные данные внутри контейнера при пересохранении. Поэтому различие хешей ещё не доказывает различие кода. А вот совпадение хешей — надёжное доказательство идентичности.
Сравнение через выгрузку в файлы XML
Основной рабочий метод — распаковать обе обработки в текстовое представление и сравнить результат. Платформа 1С умеет выгружать внешние обработки в набор XML-файлов через пакетный режим конфигуратора: в результате получается дерево папок с модулями, формами и макетами в читаемом виде.
Для выгрузки используется команда конфигуратора с параметром /DumpExternalDataProcessorOrReportToFiles. Её нужно выполнить для каждой обработки в отдельный каталог. Также существуют популярные инструменты сообщества (например, на базе OneScript и библиотеки v8unpack), которые делают то же самое удобнее и быстрее.
"C:\Program Files\1cv8\8.3.x.xxxx\bin\1cv8.exe" DESIGNER /F"C:\База" /DumpExternalDataProcessorOrReportToFiles "C:\Выгрузка\V1" "C:\Обработки\Обработка_v1.epf"После выгрузки обеих версий сравните полученные каталоги любым diff-инструментом: WinMerge, Beyond Compare, KDiff3 или встроенным сравнением папок в VS Code. Различия в модулях будут видны построчно, а изменённые формы и макеты — по отличающимся XML-файлам.
- 1Создайте два пустых каталога для выгрузки, например C:\Выгрузка\V1 и C:\Выгрузка\V2
- 2Выполните команду DumpExternalDataProcessorOrReportToFiles для первой обработки
- 3Повторите команду для второй обработки с указанием второго каталога
- 4Откройте оба каталога в WinMerge или VS Code и запустите сравнение папок
- 5Просмотрите различия: сначала модули (файлы Module.bsl), затем формы и макеты
- 6Зафиксируйте найденные отличия и решите, какая версия рабочая
Сравнение модулей в конфигураторе вручную
Если обработки небольшие и различий ожидается немного, можно обойтись без пакетного режима. Откройте обе обработки в двух окнах конфигуратора (Файл → Открыть), перейдите в модуль объекта или формы и скопируйте текст каждого модуля в отдельный текстовый файл. Затем сравните эти файлы в любом инструменте сравнения.
Этот способ подходит для точечной проверки одного-двух модулей, но плохо масштабируется: в обработке могут быть десятки форм, и вручную легко пропустить изменённый модуль. Кроме того, ручное копирование не покажет различия в настройках форм, реквизитах и макетах — только в коде.
Сравнение обработки с объектом конфигурации
Частая задача — понять, отличается ли внешняя обработка от аналогичной, встроенной в конфигурацию (например, доработанная типовая обработка). Прямого штатного механизма «сравнить epf с объектом конфигурации» нет, поэтому действуют обходным путём.
Практический приём: выгрузите внешнюю обработку в XML-файлы, а встроенный объект — через выгрузку конфигурации в файлы (Конфигурация → Выгрузить конфигурацию в файлы). Найдите в выгрузке нужный объект и сравните его модули с модулями внешней обработки. Структура файлов у обоих выгрузок похожая, поэтому diff-инструмент корректно покажет различия.
Инструменты сравнения и их выбор
Выбор diff-инструмента влияет на удобство анализа. Для разовой проверки достаточно бесплатных программ, для регулярной работы с версиями удобнее связка из системы контроля версий и скриптов распаковки.
| Инструмент | Что умеет | Когда выбрать |
|---|---|---|
| WinMerge | Сравнение файлов и папок, подсветка различий | Быстрое сравнение двух выгрузок XML |
| VS Code | Сравнение файлов и папок, подсветка синтаксиса 1С через расширения | Регулярный анализ кода модулей |
| Git + v8unpack/precommit1c | Автоматическая распаковка epf и история изменений | Постоянная работа с версиями обработок |
| 1C:EDT | Сравнение версий проектов, интеграция с Git | Обработки разрабатываются в EDT-формате |
Если обработки развиваются постоянно, имеет смысл хранить их в Git в распакованном виде: тогда сравнение любых двух версий сводится к стандартному git diff, а история изменений сохраняется автоматически. Это избавляет от ручной распаковки при каждом сравнении.
При сравнении выгрузок обращайте внимание не только на изменённые файлы, но и на появившиеся или удалённые: добавленный модуль формы или новый макет легко пропустить, если смотреть только на построчные различия. WinMerge и VS Code показывают такие файлы отдельным цветом.
Типичные ошибки и ограничения
Самая распространённая ошибка — попытка сравнить .epf-файлы напрямую в текстовом редакторе или обычным diff. Бинарный контейнер нечитаем, и такое сравнение не даст никакой полезной информации, даже если файлы визуально «почти одинаковые».
Вторая ошибка — сравнение обработок, сохранённых в разных версиях платформы, без учёта режима совместимости. Файл, пересохранённый в более новой версии платформы, может отличаться служебными данными, и diff покажет массу «шумовых» различий. В таком случае сравнивайте только файлы модулей (Module.bsl), игнорируя служебные XML.
Третий подводный камень — защищённые (паролем) модули. Если разработчик поставил пароль на модуль, при выгрузке код будет недоступен, и сравнить логику штатными средствами не получится. Единственный легальный путь — запросить исходную версию у автора обработки.
Как проверить результат
В обоих каталогах есть файлы модулей и XML структуры, размеры сопоставимы
Один каталог пустой или содержит только часть файлов — выгрузка завершилась с ошибкой, смотрите журнал
Diff показывает осмысленные различия в процедурах и функциях
Различия только в служебных строках и GUID — вероятно, обработки идентичны по логике, но пересохранены
Обработка открывается и выполняет нужное действие на тестовой базе
Ошибки при открытии или выполнении — версия повреждена или несовместима с релизом конфигурации
Часто задаваемые вопросы
Можно ли сравнить две обработки без конфигуратора?
Да. Инструменты на базе OneScript (например, v8unpack или precommit1c) распаковывают .epf в текстовые файлы без запуска конфигуратора. Дальше сравнение выполняется в любом diff-инструменте. Это удобно для автоматизации в скриптах.
Чем сравнение обработок отличается от сравнения отчётов (.erf)?
Технически — ничем: внешние отчёты (.erf) и обработки (.epf) имеют одинаковый формат контейнера. Та же команда DumpExternalDataProcessorOrReportToFiles работает для обоих типов файлов, и весь описанный порядок применим без изменений.
Почему после пересохранения обработки diff показывает много изменений, хотя код не трогали?
Платформа при пересохранении может обновлять служебные данные внутри контейнера: идентификаторы, порядок элементов в XML, метаданные форм. Отфильтруйте сравнение до файлов модулей (Module.bsl) — они отражают реальные изменения логики.
Как сравнить обработки, если одна из них встроена в конфигурацию поставщика?
Выгрузите конфигурацию в файлы, найдите нужный объект в структуре выгрузки и сравните его модули с модулями распакованной внешней обработки. Учтите, что встроенный объект использует контекст конфигурации, поэтому небольшие различия в обращениях к метаданным — норма.
Можно ли автоматически объединить изменения из двух версий обработки?
Штатного механизма слияния внешних обработок нет. Объединение делается вручную: по результатам diff переносите нужные фрагменты кода в рабочую версию. Если обработки хранятся в Git в распакованном виде, можно использовать стандартное трёхстороннее слияние Git, но конфликты в модулях всё равно разрешаются вручную.
Что важно запомнить
Для проверки идентичности двух обработок достаточно сравнить хеши файлов. Для анализа различий распакуйте оба .epf в XML-файлы пакетным режимом конфигуратора или через OneScript-инструменты и сравните результат в WinMerge или VS Code, концентрируясь на файлах модулей. Сравнение выполняйте на копиях, а проверенную версию запускайте сначала на тестовой базе.