Разработка и Конфигурация · 9 мин
Как сравнить внешние обработки 1С и найти различия
Как сравнить две версии внешней обработки 1С: сравнение модулей, форм и макетов через конфигуратор, EDT и сторонние инструменты. Пошаговая инструкция.
Внешние обработки 1С (файлы с расширением .epf) часто живут в нескольких копиях: одна версия лежит у разработчика, другая — в рабочей базе, третья — в архиве на сервере. Когда нужно понять, чем отличаются две версии, простое сравнение размера файла ничего не даст: epf — это бинарный контейнер, и текстовые diff-утилиты с ним не справятся.
Правильный подход — сравнивать не сами файлы, а их содержимое: тексты модулей, формы, макеты и реквизиты. Для этого есть штатные средства платформы (конфигуратор, 1C:EDT), а также сторонние инструменты и приём с выгрузкой обработки в исходные файлы XML. Ниже разберём все рабочие способы и ситуации, в которых каждый из них оптимален.
Важно понимать заранее: сравнение «в лоб» через «Сравнить файлы» в конфигураторе покажет только, что бинарные данные различаются, но не покажет, в каком месте кода. Поэтому почти всегда задача сводится к предварительной выгрузке обработки в текстовый вид.
Что именно нужно сравнивать в обработке
Внешняя обработка состоит из нескольких типов объектов, и различия могут скрываться в любом из них. Прежде чем сравнивать, стоит определить, что вас интересует: логика работы, внешний вид формы или данные макетов.
- Модуль объекта — основной код обработки: процедуры, функции, экспортные методы.
- Модули форм — код обработчиков событий каждой формы.
- Макеты — табличные документы, схемы компоновки данных, двоичные данные.
- Реквизиты и табличные части — состав и типы данных обработки.
- Формы как структура — состав элементов, их свойства, привязки к данным.
На практике чаще всего сравнивают именно тексты модулей: именно там находится прикладная логика. Но если обработка «перестала работать» после обновления, различие может быть и в составе реквизитов или в макете печатной формы — это стоит проверять отдельно.
Способ 1. Выгрузка в исходные файлы и сравнение diff-утилитой
Это самый универсальный и надёжный способ. Идея: обе обработки выгружаются в текстовое представление (XML-файлы и файлы модулей .bsl), после чего два каталога сравниваются любой программой сравнения — WinMerge, Beyond Compare, KDiff3 или встроенным сравнением в VS Code.
В конфигураторе выгрузка выполняется через меню Конфигурация → Выгрузить файлы конфигурации — но это работает для конфигурации целиком. Для внешней обработки удобнее пакетный режим запуска конфигуратора с параметром /DumpExternalDataProcessorOrReportToFiles, который выгружает указанный epf-файл в каталог с исходниками.
- 1Создайте два пустых каталога: для старой и новой версии обработки.
- 2Запустите конфигуратор в пакетном режиме с параметром /DumpExternalDataProcessorOrReportToFiles для каждого epf-файла, указав свой каталог выгрузки.
- 3Откройте оба каталога в diff-утилите (WinMerge, Beyond Compare) в режиме сравнения папок.
- 4Просмотрите различающиеся файлы: модули лежат в подкаталогах Forms и Ext, макеты — в Templates.
- 5Зафиксируйте найденные отличия и при необходимости перенесите нужные изменения в рабочую версию.
Пример команды пакетной выгрузки для типовой файловой базы:
"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Test" /DumpExternalDataProcessorOrReportToFiles "D:\Compare\v1" "D:\Processors\Obработка_v1.epf"Путь к исполняемому файлу зависит от установленной версии платформы — подставьте свой каталог bin. Если база серверная, вместо /F используйте параметр /S с адресом сервера и именем базы, а также укажите пользователя и пароль параметрами /N и /P.
Способ 2. Сравнение через 1C:EDT
Если вы работаете в 1C:EDT, сравнение упрощается: EDT хранит внешние обработки в проектах как набор исходных файлов. Импортируйте обе обработки в два проекта (или в один проект под разными именами) и сравните файлы штатными средствами среды — через контекстное меню Сравнить с или через интеграцию с Git.
Вариант с Git особенно удобен при регулярной работе: поместите исходники обработки в репозиторий, и каждая новая версия будет сравниваться с предыдущей автоматически через историю коммитов. Это решает проблему «что изменилось между версиями» раз и навсегда, а не разово.
Способ 3. Сравнение модулей вручную в конфигураторе
Когда нужно быстро посмотреть отличия в одном-двух модулях, можно обойтись без выгрузки. Откройте обе обработки в двух окнах конфигуратора, скопируйте текст модуля из каждой в отдельные текстовые файлы и сравните их — либо вставьте оба текста в любой онлайн-сервис сравнения текстов.
Этот способ подходит для разовой проверки, но у него есть ограничения: легко пропустить отличия в формах и макетах, а при копировании больших модулей можно случайно захватить не весь текст. Для систематической работы лучше выгрузка в файлы.
Сравнение способов
Универсально, показывает все отличия включая макеты. Требует пакетного запуска конфигуратора и установки программы сравнения.
Лучший вариант при постоянной разработке: история версий и сравнение из коробки. Избыточен для разовой задачи.
Быстро для одного модуля, но не показывает формы, макеты и реквизиты, легко ошибиться.
Есть готовые инструменты с Инфостарта, автоматизирующие выгрузку и сравнение. Требуют проверки на совместимость с вашей версией платформы.
Частые ошибки и ограничения
Первая типичная ошибка — попытка сравнить epf-файлы побайтово. Даже две идентичные по содержимому обработки, сохранённые в разное время или на разных версиях платформы, будут отличаться бинарно. Вывод «файлы разные» не даёт никакой полезной информации.
Вторая ошибка — сравнение выгрузок, сделанных разными версиями платформы. Формат XML-выгрузки может меняться между релизами, и вы получите массу ложных отличий в служебных атрибутах. Выгружайте обе версии одной и той же платформой.
Третья ошибка — игнорирование макетов с двоичными данными. Картинки и некоторые макеты выгружаются как бинарные файлы, и текстовое сравнение покажет только факт различия без деталей. Такие отличия придётся проверять визуально, открыв обе обработки.
Как проверить результат и не сломать рабочую базу
После того как различия найдены и вы решили перенести изменения, работайте только с копией. Откройте обработку из рабочей базы, сохраните её резервную копию под новым именем и только потом вносите правки. Если обработка подключена к базе через механизм дополнительных отчетов и обработок (БСП), обновляйте её через регистрацию новой версии, а не заменой файла напрямую.
Контрольные точки после переноса изменений: обработка открывается без ошибок синтаксиса, основная функция выполняется на тестовых данных, печатная форма формируется корректно. Проверяйте именно те сценарии, где были найдены различия.
Как проверить результат
Открывается без ошибок, модуль компилируется
Синтаксические ошибки, не найдены процедуры или переменные
Основной сценарий выполняется, результат совпадает с ожидаемым
Ошибки времени выполнения, неверные данные в результате
Макет формируется как в эталонной версии
Пустые области, отсутствующие параметры, съехавшая структура
FAQ
Можно ли сравнить обработки без конфигуратора?
Напрямую — нет, так как epf является бинарным форматом. Нужна хотя бы одна выгрузка в исходные файлы через конфигуратор или EDT. Дальше сами исходники можно сравнивать в любой среде без платформы 1С.
Чем сравнение внешних отчетов (.erf) отличается от сравнения обработок (.epf)?
Технически — ничем. Тот же параметр пакетного режима /DumpExternalDataProcessorOrReportToFiles выгружает и отчёты, и обработки. Отличие только в содержимом: у отчётов чаще критичны схемы компоновки данных, которые выгружаются в виде XML и тоже сравниваются текстово.
Почему после выгрузки diff-утилита показывает отличия во всех файлах?
Скорее всего, версии выгружены разными релизами платформы или разными инструментами (конфигуратор и EDT). Повторите выгрузку обеих версий одним инструментом одной версии — ложные отличия исчезнут.
Как сравнить обработку из базы с файлом на диске?
Откройте обработку из базы в конфигураторе, сохраните её как epf-файл, затем выгрузите оба файла в исходники и сравните каталоги. Дополнительно учтите: обработка в базе могла быть изменена встроенным редактором без обновления исходного файла.
Есть ли смысл хранить обработки в Git?
Да, если обработка регулярно дорабатывается. Храните в репозитории не сам epf, а выгрузку в исходные файлы: тогда история изменений, сравнение версий и откат работают штатными средствами Git, а epf собирается из исходников обратной командой загрузки.
Что делать, если отличия только в макете с картинкой?
Двоичные макеты текстово не сравниваются. Откройте обе обработки в конфигураторе, перейдите к макету и сверьте содержимое визуально. Если картинка не влияет на логику, отличие можно проигнорировать или перенести макет целиком из нужной версии.
Что важно запомнить
EPF-файлы бинарные — сравнивайте не файлы, а выгруженные исходники. Используйте один инструмент и одну версию платформы для выгрузки обеих версий, сравнивайте каталоги diff-утилитой, а изменения переносите только после проверки на копии базы.