В veraPDF можно проверить PDF на соответствие PDF/A и PDF/UA, выбрать точный профиль или автоматическое определение, обработать один файл, папку либо ZIP-контейнер, получить HTML, XML, JSON или краткий текстовый отчёт, извлечь сведения о шрифтах, изображениях и метаданных, а также выполнить ограниченное исправление XMP-метаданных. Основные инструменты сосредоточены в одном окне: выбор документов, тип задания, профиль проверки, параметры отчёта, запуск и кнопки сохранения результатов.

Обычная проверка строится в три шага: укажите документ или набор документов, оставьте Auto-detect либо задайте ожидаемый уровень соответствия, затем нажмите Execute. После обработки строка состояния сразу сообщает, прошёл ли файл выбранный профиль, а кнопки Save XML, View XML, Save HTML и View HTML дают сохранить результат для хранилища, открыть его для разбора или передать в автоматизированный процесс.

Главная ценность результата не сводится к зелёному или красному сообщению. В отчёте veraPDF связывает каждое несоответствие с правилом, пунктом спецификации, типом PDF-объекта, проверяемым условием и контекстом конкретного объекта, поэтому специалист может отделить ошибочную декларацию PDF/A от проблемы со шрифтом, цветовым пространством, действием, аннотацией, структурным деревом или XMP-пакетом.

Главное окно и логика задания

После запуска veraPDF показывает компактную форму без панели просмотра страниц. Верхняя строка предназначена для пути к входному объекту, рядом находится кнопка Choose PDF. Ниже расположены два ключевых списка: Report type задаёт состав операции, а PDF flavour выбирает нормативный профиль. Поля Validation profile и Policy file остаются неактивными, пока пользователь не переключится на пользовательский профиль или проверку политики. Кнопка Execute также заблокирована, пока не выбран хотя бы один входной объект; это полезный диагностический признак, когда запуск кажется недоступным.

В списке Report type доступны Validation, Features, Validation & Features и Policy. Validation выполняет только проверку соответствия. Features отключает оценку профиля и формирует сведения о внутреннем устройстве документа. Validation & Features совмещает оба результата в машиночитаемом отчёте. Policy добавляет проверку собственных требований организации и автоматически опирается на извлечение признаков, потому что правило политики должно получить данные, с которыми оно сравнивает документ.

Флажок Fix metadata не следует воспринимать как универсальную кнопку ремонта PDF. Он относится к узкому набору операций с XMP и словарём сведений: может добавить отсутствующий пакет, исправить идентификатор соответствия, удалить ложную декларацию или синхронизировать часть полей. Если в файле одновременно найдены нарушения шрифтов, графики, действий, аннотаций или структуры, автоматическое исправление не превращит такой документ в корректный PDF/A или PDF/UA.

Что означают четыре кнопки отчёта

После успешного завершения становятся активными Save XML, View XML, Save HTML и View HTML. Команды Save сохраняют копию результата в выбранное место, а View передаёт временный файл приложению, назначенному в системе для соответствующего типа. XML подходит для дальнейшего разбора, сопоставления партий и загрузки в систему контроля качества. HTML удобнее читать человеку: он группирует правила и проверки, показывает итог по каждому файлу и позволяет перейти от общей статистики к конкретным причинам отказа.

Интерфейс не показывает сам PDF и не подсвечивает проблемный объект на странице. Контекст в отчёте описывается через модель документа: номер косвенного объекта, путь внутри структуры, тип сущности и проверяемое свойство. Поэтому veraPDF лучше использовать рядом с редактором или средством исправления: валидатор указывает нормативную причину, а изменение содержимого выполняется в другой программе, после чего файл проверяется повторно.

Выбор одного файла, папки и ZIP-контейнера

Кнопка Choose PDF открывает системный диалог, в котором можно отметить один или несколько документов. То же действие выполняется перетаскиванием файлов в область с текстом PDF file not chosen. Допускаются файлы с отсутствующим или нестандартным расширением, однако при пакетной работе через командную строку для таких объектов нужно явно разрешить обработку параметром --nonpdfext. Это различие важно, когда система долговременного хранения хранит объекты по идентификаторам без суффикса .pdf.

Папка выбирается как единый вход для серии документов. При рекурсивном режиме veraPDF проходит вложенные каталоги и формирует один общий отчёт с отдельным job для каждого обнаруженного PDF. В batchSummary затем видны общее число заданий, количество корректных и некорректных файлов, ошибки разбора, зашифрованные документы, нехватка памяти и внутренние исключения. Итог партии нельзя оценивать только по числу nonCompliant: failedToParse и encrypted требуют отдельного маршрута обработки.

ZIP-контейнер можно передать напрямую. Валидатор рекурсивно просматривает папки внутри контейнера и проверяет найденные PDF без предварительной ручной распаковки. Это удобно при входном контроле поставки, но не отменяет проверки состава пакета: veraPDF оценивает PDF-объекты, а не полноту сопроводительных файлов, структуру именования или отсутствие посторонних форматов. Для таких требований следует добавить Schematron-политику либо внешний контроль списка файлов.

Перед запуском большой партии полезно сделать пробный проход на нескольких типичных файлах. Так можно убедиться, что выбран нужный профиль, что зашифрованные документы открываются, что отчёт не разрастается из-за регистрации успешных проверок и что каталог назначения доступен. Для хранилища из тысяч файлов пробный отчёт также показывает, какие поля удобнее использовать как ключи при импорте результата в базу данных.

Автоматическое определение и явный выбор профиля

Режим Auto-detect читает декларации соответствия в XMP-метаданных и на их основании выбирает профиль. Он удобен для смешанного набора, где рядом встречаются PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4 и PDF/UA. Автоматическое определение не анализирует намерение автора по визуальному содержимому: если корректная декларация отсутствует или повреждена, применяется профиль по умолчанию. Поэтому результат “не соответствует PDF/A-1b” у обычного PDF без XMP ещё не доказывает, что именно PDF/A-1b был требуемым целевым стандартом.

Явный профиль нужен, когда приёмные требования известны заранее. В интерфейсе перечислены PDF/A-1a, PDF/A-1b, PDF/A-2a, PDF/A-2b, PDF/A-2u, PDF/A-3a, PDF/A-3b, PDF/A-3u, PDF/A-4, PDF/A-4e, PDF/A-4f, PDF/UA-1 и PDF/UA-2. В командной строке дополнительно используются короткие обозначения 1a, 1b, 2a, 2b, 2u, 3a, 3b, 3u, 4, 4e, 4f, ua1 и ua2, а также профили WTPDF 1.0 для accessibility и reuse.

Если документ заявляет несколько видов соответствия, автоматический режим способен выполнить несколько проверок, когда декларации основаны на одной базовой версии PDF. Группа PDF/A-4, PDF/UA-2 и WTPDF относится к PDF 2.0; PDF/A-2, PDF/A-3 и PDF/UA-1 — к PDF 1.7; PDF/A-1 — к PDF 1.4. При декларациях на разных базовых версиях приоритет получает PDF/A, затем PDF/UA и совместимые с выбранной основой профили. В отчёте появляется предупреждение о найденной, но не проверенной декларации.

Для обязательной проверки конкретного договора или регламента указывайте профиль явно. Это исключает ситуацию, когда некорректный XMP-пакет заставляет применить запасной PDF/A-1b. Если же задача состоит в инвентаризации уже накопленного массива, сначала полезен Auto-detect: он показывает фактические декларации, а затем подозрительные группы можно перепроверить фиксированными профилями.

Пользовательский validation profile

Пункт Custom profile активирует поле и кнопку Choose Profile. Внешний XML-профиль переопределяет выбор из списка и позволяет применять набор правил, подготовленный для особой процедуры тестирования. Файл профиля должен соответствовать модели veraPDF; произвольный XML или Schematron сюда не подходит. Schematron используется в поле Policy, тогда как validation profile описывает нормативные ограничения на объекты модели PDF.

Если Execute остаётся недоступной после выбора Custom profile, проверьте два обязательных входа: документ и внешний профиль. При ошибке загрузки профиль следует открыть как XML, проверить целостность, кодировку и ссылки на ожидаемые типы модели. Для повторяемой проверки храните профиль вместе с процедурой контроля и фиксируйте его контрольную сумму, иначе одинаковая команда в разные даты может означать разные наборы правил.

Как читать итог соответствия

В главном окне после обработки появляется краткая фраза: документ соответствует требованиям профиля либо не соответствует им. Красное сообщение означает хотя бы одну проваленную проверку, но не объясняет масштаб проблемы. Один failed rule может повториться на сотнях объектов, например для каждого использования не встроенного шрифта; наоборот, несколько правил могут относиться к одной первопричине, такой как некорректный XMP-пакет.

В машиночитаемом отчёте атрибут isCompliant содержит итог true или false. В details указываются passedRules, failedRules, passedChecks и failedChecks. Rule — нормативное условие, а check — применение этого условия к конкретному объекту. Поэтому failedRules показывает разнообразие нарушений, а failedChecks — их распространённость. Для приоритизации ремонта сначала группируйте по правилу и объекту, а уже затем оценивайте количество повторов.

Каждый провал может включать specification, clause и testNumber, текстовое описание требования, object, выражение test и context. Поле context особенно полезно разработчику конвертера: оно ведёт к объекту модели, на котором условие оказалось ложным. Пользователю редактора PDF этот путь может быть непонятен, но тип объекта и описание правила обычно достаточно точно указывают область: PDAction относится к действиям, font — к шрифтам, colour space — к цветам, StructTreeRoot и structure element — к тегированной структуре.

Не смешивайте “файл не соответствует профилю” с “файл не читается”. При синтаксической ошибке, нехватке памяти, исключении парсера или невозможности расшифрования job может завершиться без полноценного validationReport. В batchSummary такие случаи учитываются отдельно. Автоматический процесс должен проверять одновременно наличие отчёта, isCompliant и счётчики ошибок партии.

Форматы отчёта: HTML, XML, JSON, RAW и TEXT

XML используется по умолчанию и рассчитан на машинный разбор. Он содержит сведения о сборке компонентов, список jobs, описание каждого входного элемента, validationReport, featuresReport, repairReport при наличии и сводку партии. Для обмена между системами это наиболее полный и стабильный вариант: по нему можно построить собственную панель, сравнить результаты до и после исправления и сохранить нормативное доказательство вместе с объектом.

JSON передаёт те же основные сущности в форме, удобной для веб-приложений и скриптов. Перед внедрением не стоит писать проверку, которая ищет отдельную строку в консоли: используйте структурные поля итогового отчёта. При обновлении валидатора тестируйте десериализацию на наборе корректных, некорректных, повреждённых и зашифрованных файлов, потому что разные ветви обработки заполняют отчёт неодинаково.

HTML предназначен для чтения человеком. Он показывает результат, правила и контекст в более наглядном виде, но в интерфейсе HTML-вывод ориентирован прежде всего на validation information; подробные результаты feature extraction следует брать из XML или JSON. Кроме того, HTML может содержать переходы к пояснениям правил. Если отчёты должны открываться в изолированной сети, настройте собственный корень справочных материалов либо сохраняйте локальную копию описаний правил.

TEXT даёт краткий вывод и полезен для журнала сборки, когда полный отчёт сохраняется отдельным артефактом. Без verbose он в основном перечисляет номера проваленных правил; параметр --verbose добавляет сведения о неудачных тестах. RAW содержит внутреннее представление с несгруппированными проверками и конфигурацией, поэтому подходит для глубокой диагностики и API-сценариев, но менее удобен для обычного аудита.

Почему стандартный вывод может повредить XML

Сообщения журнала отправляются в stderr. В некоторых оболочках stderr и stdout отображаются вместе, из-за чего скопированный из терминала XML оказывается смешан с предупреждениями. Для автоматизации направляйте отчёт в один файл, а журнал — в другой поток. Опция --addlogs, напротив, намеренно включает логи в XML, JSON или HTML; её используют, когда вся диагностическая информация должна храниться внутри одного результата.

Уровень журнала задаётся от OFF до ALL. Для приёмного конвейера обычно достаточно WARNING и SEVERE: так сохраняются важные сообщения без потока служебных деталей. Уровни CONFIG и INFO помогают разобраться, какой профиль, файл конфигурации и режим были применены. ALL имеет смысл при воспроизводимой ошибке парсера, но резко увеличивает объём и может раскрыть внутренние пути к файлам, что следует учитывать при передаче отчёта внешней стороне.

Расширенные настройки проверки

Диалог Settings открывается из меню Configs. Параметр Include passed rules добавляет в результат успешные правила и проверки. По умолчанию он выключен, потому что список успехов во много раз больше списка нарушений. Включайте его для сертификационного протокола, где требуется доказать выполнение конкретного правила, либо для отладки собственного профиля; для массового входного контроля достаточно регистрировать ошибки и итоговые счётчики.

Add logs to xml and html reports помещает сообщения журнала в отчёт. Add detailed errors to report управляет подробными пояснениями для каждого провала. Отключение подробных сообщений способно ускорить обработку очень проблемного документа и уменьшить результат, но усложняет диагностику. Практичный порядок таков: первый проход ограничивает количество провалов и сообщения, второй проход выполняется только для выбранных файлов с полными деталями.

Halt validation after failed checks задаёт предел всех неудачных проверок, после которого работа с файлом прекращается. Значение по умолчанию фактически означает отсутствие лимита. Display failed checks for rule ограничивает число показанных повторов каждого правила, не прекращая саму проверку; стандартный предел равен ста. Эти два параметра решают разные задачи: первый экономит время, второй уменьшает отчёт, сохраняя итоговую оценку остальных правил.

Поля Save repaired files with prefix и Save repaired files into the folder действуют только при включённом Fix metadata. Префикс предотвращает перезапись исходника и помогает отличить исправленную копию. Путь назначения лучше размещать вне входной папки, особенно при рекурсивной обработке: иначе новый PDF может быть повторно подобран следующим запуском сценария или ошибочно принят как оригинал.

Validation Profiles wiki root задаёт базовый адрес пояснений к правилам в HTML-отчёте. Default flavour определяет запасной профиль для документов, у которых автоматическое определение не сработало. Logging level регулирует подробность журнала. После изменения настроек выполните тест на файле без декларации PDF/A: так легко проверить, что запасной профиль действительно соответствует политике организации, а не остался равным PDF/A-1b по умолчанию.

Проверка из командной строки

Командная строка удобна для каталогов, планировщика, серверного задания и контроля перед публикацией. На Windows используется verapdf.bat, на macOS и Linux — verapdf. Простейший вызов с путём к PDF запускает автоматический выбор профиля и выводит XML. Параметр -l показывает встроенные профили, --version сообщает сведения о компонентах, а --help печатает полный набор опций установленной сборки.

Чтобы потребовать конкретный стандарт, добавьте -f и короткий код, например -f 2b или -f ua1. Значение -f 0 равнозначно автоматическому выбору. Параметр --defaultflavour задаёт запасной профиль, если XMP не позволяет определить декларацию. Внешний XML-профиль передаётся через --profile; он имеет приоритет над -f, поэтому одновременно указывать оба режима без специальной причины не следует.

Формат задаётся конструкцией --format xml, json, html, text или raw. Параметр --success включает успешные проверки, --maxfailuresdisplayed ограничивает число отображаемых повторов на правило, --maxfailures останавливает проверку после заданного количества провалов, --disableerrormessages убирает подробные сообщения, --progress показывает ход работы, а --debug перечисляет имена обрабатываемых файлов.

Для папки передайте путь к каталогу; --recurse добавит вложенные директории. ZIP передаётся как обычный входной файл. Параметр --processes задаёт число параллельных процессов для партии, причём итог остаётся единым отчётом. Значение нужно подбирать по числу ядер, доступной памяти и сложности документов: увеличение процессов ускоряет независимые jobs, но каждый процесс требует собственных ресурсов парсера.

Практические команды

• verapdf -f 3b document.pdf — проверить документ строго как PDF/A-3b.
• verapdf --format json --recurse incoming — обработать PDF во всех вложенных папках и получить JSON.
• verapdf --maxfailures 50 --maxfailuresdisplayed 5 large.pdf — быстро оценить сильно повреждённый файл без огромного отчёта.
• verapdf --password "пароль" protected.pdf — передать пользовательский пароль зашифрованному документу.
• verapdf --off --extract font,imageXobject,metadata document.pdf — отключить валидацию и извлечь выбранные признаки.
• verapdf --policyfile policy.sch document.pdf — добавить проверку организационной политики.

В скриптах заключайте пути с пробелами в кавычки и не помещайте пароль непосредственно в общий журнал команд. Результат следует записывать в отдельный файл, а stderr — в диагностический лог. После выполнения проверяйте не только код завершения процесса, но и batchSummary: один общий запуск способен содержать одновременно соответствующие документы, несоответствующие документы и задания, которые не удалось разобрать.

Пакетная обработка и производительность

Большой PDF может породить сотни тысяч проверок, а одна ошибка шрифта или цветового пространства — тысячи одинаковых failed checks. Первый способ сократить нагрузку — не включать успешные правила. Второй — уменьшить Display failed checks for rule или --maxfailuresdisplayed. Это не меняет итог соответствия и не прекращает обход других правил, но удерживает размер отчёта в разумных пределах.

Если нужен быстрый фильтр заведомо плохих документов, используйте Halt validation after failed checks или --maxfailures. После достижения порога результат остаётся достаточным, чтобы признать файл непрошедшим, но не является полной картой нарушений. Поэтому такой проход годится для маршрутизации “принять/отклонить”, а перед исправлением потребуется повторная проверка без ранней остановки.

Опция --processes распараллеливает независимые файлы, а не отдельные правила одного PDF. Максимальный эффект получается на партии из множества документов. Для одного огромного файла увеличение значения не обязательно ускорит работу. Начинайте с небольшого числа процессов, следите за памятью и длительностью, затем повышайте значение. В контейнере или CI учитывайте фактический лимит CPU, а не число ядер физического узла.

В сводке партии duration показывает общее время, а каждый job содержит собственную длительность. Эти значения помогают обнаружить выбросы: сложные шрифты, огромные изображения, повреждённые потоки или многократные инкрементальные обновления. Не удаляйте медленный файл из процесса без анализа: именно необычная структура может указывать на проблему конвертера или попытку обойти проверку.

При outOfMemory сначала уменьшите число процессов и отключите ненужное извлечение признаков. Затем ограничьте подробность отчёта и выделите JVM больше памяти через JAVA_OPTS в сценарии запуска. Повышение лимита без изменения пакетного режима может лишь отложить сбой, если одновременно запускается слишком много тяжёлых jobs. Для воспроизводимости фиксируйте размер памяти и число процессов в журнале контроля.

Извлечение признаков PDF

Feature extraction отвечает на вопрос, что находится внутри PDF, независимо от итогового соответствия. В режиме Features валидация не выполняется; в Validation & Features оба набора данных попадают в один машиночитаемый отчёт. В CLI проверку отключают параметром --off и перечисляют признаки через --extract. Несколько имён пишутся через запятую без пробелов.

Доступны actions, annotations, colorSpace, ds, embeddedFile, exGSt, font, formXobject, iccProfile, imageXobject, informationDict, interactiveFormField, lowLevelInfo, metadata, outlines, outputIntent, page, pattern, postscriptXobject, properties, shading, signature и error. Этот список охватывает не визуальные страницы как картинки, а структурированные сведения об объектах и ресурсах PDF.

Information Dictionary даёт Title, Author, Subject, Keywords, Creator, Producer, CreationDate и ModDate, если эти поля присутствуют. Metadata возвращает XMP-пакет, включая пространства имён и идентификаторы. Одновременное извлечение обоих наборов данных полезно для поиска расхождений: создатель может быть указан в Info, но отсутствовать в XMP, даты могут отличаться, а декларация PDF/A может не соответствовать фактическому содержимому.

Font показывает тип, базовое имя, диапазон символов, кодировку, дескриптор, семейство, начертание, вес, признаки serif, symbolic и embedded data, доступные модели. Эти сведения помогают выявить подмножества, неожиданные шрифты, отсутствие Unicode-сопоставления и неоднородность партии. Image XObject сообщает параметры встроенных изображений, а ICC Profile и Output Intent позволяют контролировать управление цветом.

Форма Features Config позволяет включить только необходимые категории. Это важнее, чем отмечать всё подряд: полный отчёт по страницам, изображениям, шрифтам, аннотациям и формам может стать значительно больше исходного документа. Для политики по обязательному заголовку достаточно Information Dictionary; для запрета конкретного шрифта нужен Fonts; для контроля вложений — Embedded Files; для проверки подписей — Signatures.

Сценарии использования feature report

• Инвентаризация фонда: сгруппировать документы по Producer, версиям PDF, наличию XMP, шрифтам и выходным профилям.
• Контроль миграции: сравнить ресурсы оригинала и конвертированной копии, не ограничиваясь итогом PDF/A.
• Поиск рискованных объектов: действия, JavaScript-подобные конструкции, вложения, формы, аннотации и PostScript XObject.
• Подготовка политики: сначала выяснить, какие поля стабильно извлекаются, затем написать проверяемые Schematron-условия.
• Разбор дефекта: связать проваленное правило с фактическими параметрами шрифта, изображения, метаданных или цветового профиля.

Извлечение признаков не является полнотекстовым поиском и не оценивает визуальное сходство страниц. Оно также не доказывает смысловую корректность метаданных: наличие Title не означает, что заголовок точен, а наличие Alt не означает, что альтернативное описание полезно. Для таких требований нужна ручная оценка или специализированная семантическая проверка.

Организационные политики и Schematron

Стандарты PDF/A и PDF/UA не покрывают все внутренние требования. Хранилище может требовать непустой Title, конкретный набор Producer, отсутствие вложений, ограничение на шрифты или нулевой поворот страниц. veraPDF позволяет применить Schematron либо XSL к своему feature report. Сначала извлекаются необходимые признаки, затем выражения политики проверяют узлы отчёта и формируют policyReport с passedChecks и failedChecks.

В интерфейсе выберите Policy в Report type, после чего станет активной кнопка Choose Policy. Затем загрузите .sch или подходящий XSL, включите нужные категории в Features Config и выберите PDF. Если правило обращается к informationDict, а категория Information Dictionary выключена, политика не получает ожидаемые узлы и результат будет ошибочным или неполным. Связь между политикой и конфигурацией признаков должна храниться как единый комплект.

Пример проверки заголовка использует контекст featuresReport/informationDict и утверждение, что количество entry с key=Title больше нуля. Аналогично можно проверить конкретное имя шрифта в documentResources/fonts, число страниц, наличие Output Intent или отсутствие определённого типа объекта. Schematron оценивает то, что попало в отчёт; он не обращается напрямую к произвольному байту PDF.

Policy Creator открывается через Configs и помогает собрать распространённые условия визуально. Каждая строка состоит из категории, свойства, операции сравнения и значения; кнопка плюс добавляет условие, крестик удаляет его. В показанном сценарии можно потребовать нулевой поворот страницы и отсутствие даты создания. Мастер сохраняет результат как Schematron и одновременно назначает его текущей политикой в главном окне.

Визуальный мастер не заменяет ревизию правила. Перед применением к фонду протестируйте политику на положительных и отрицательных контрольных файлах, изучите сгенерированный Schematron и убедитесь, что условие применяется к каждому нужному узлу, а не только к первому. Отдельно проверьте документы, где категория отсутствует: “поле не найдено” и “поле найдено с запрещённым значением” могут требовать разных сообщений.

Как поддерживать политики

1. Храните файл Schematron, features.xml и набор контрольных PDF в системе версий.
2. Присваивайте политике собственный идентификатор и дату вступления, не полагаясь на имя файла.
3. При изменении модели или валидатора запускайте регрессионный набор и сравнивайте policyReport.
4. В отчёте партии фиксируйте использованную политику и конфигурацию извлечения признаков.
5. Разделяйте нормативную проверку PDF/A или PDF/UA и внутренние требования, чтобы причина отказа была понятна.

Исправление XMP-метаданных

Metadata fixer выполняет только операции, которые можно безопасно определить по результатам проверки. Он способен добавить документный XMP-пакет, если тот отсутствует; добавить идентификацию PDF/A или PDF/UA, когда других нарушений нет и после добавления документ станет соответствующим; удалить ложную идентификацию, если файл не отвечает заявленному профилю; для PDF/A-1 синхронизировать часть свойств между Info dictionary и XMP.

Условие “нет других нарушений” принципиально. Валидатор не встраивает шрифты, не перестраивает теги, не создаёт альтернативные описания, не заменяет цветовые пространства, не удаляет запрещённые действия и не исправляет визуальное содержимое. Поэтому флажок Fix metadata полезен для документа, который уже технически соответствует профилю, но имеет недостающую или ошибочную декларацию, а не для общей конвертации в PDF/A.

Исправленный файл сохраняется как копия с заданным префиксом, стандартно veraFixMd_. В Settings укажите отдельную папку. После создания копии обязательно проведите повторную валидацию именно нового файла и сохраните оба отчёта: repairReport показывает выполненную операцию, а новый validationReport подтверждает итог. Не заменяйте оригинал до проверки контрольной суммы, размера и открываемости.

Удаление ложной идентификации тоже является исправлением метаданных, но не делает документ PDF/A или PDF/UA. Оно устраняет вводящую в заблуждение декларацию, после чего файл следует направить на полноценную ремедиацию. В процессе долговременного хранения полезно различать три результата: соответствующая копия после добавления идентификатора, обычный PDF после удаления ложной декларации и файл, для которого исправление не выполнено из-за других нарушений.

Если новая копия не появляется, проверьте права на папку, заданный savefolder, префикс и наличие других провалов. В отчёте ищите repairReport и сообщения журнала. Пустая папка при красном validationReport часто означает не ошибку записи, а сознательный отказ fixer изменять документ, который всё равно не станет соответствующим после правки XMP.

PDF/A: практическая проверка документа долговременного хранения

Для входного контроля PDF/A сначала определите требуемую часть и уровень. PDF/A-1 ограничен возможностями PDF 1.4; PDF/A-2 и PDF/A-3 основаны на PDF 1.7, причём PDF/A-3 допускает связанные вложения; PDF/A-4 относится к PDF 2.0, а варианты 4e и 4f учитывают инженерные данные и вложенные файлы. Выбор “самого нового” профиля вместо договорного даст нерелевантный результат.

Проверка оценивает требования к шрифтам, цветам, метаданным, действиям, аннотациям, встроенным файлам и другим объектам согласно выбранному профилю. Например, отчёт способен показать запрещённое действие через объект PDAction и условие допустимых значений S. Для шрифтов один нормативный провал может повторяться на множестве объектов; ограничьте отображаемые повторы, но сохраните полное число failedChecks.

После конвертации скана в PDF/A не ограничивайтесь валидатором. veraPDF подтверждает техническое соответствие, но не проверяет читаемость мелкого текста, порядок страниц, поворот изображения, качество OCR и совпадение с оригиналом как человек. Добавьте визуальный контроль и, при наличии OCR, выборочную проверку текста. Policy Creator может проверять поворот страниц как числовое свойство, но не определяет, правильно ли изображение ориентировано по смыслу.

Для PDF/A-3 и PDF/A-4f отдельно инвентаризируйте Embedded Files и отношения вложений. Соответствие профилю не гарантирует, что вложенный XML принадлежит этому документу, что его схема правильна или что бизнес-процесс получил полный набор. Feature report помогает увидеть контейнеры и свойства, а содержательную связь проверяет специализированная система.

Результат храните рядом с объектом или в системе метаданных: идентификатор профиля, дата проверки, версия компонентов из buildInformation, итог, число правил и проверок, контрольная сумма PDF и полный машиночитаемый отчёт. Без контрольной суммы нельзя доказать, что отчёт относится к неизменённому файлу; без buildInformation сложнее воспроизвести расхождение после обновления правил.

PDF/UA: что проверяется автоматически

Профили PDF/UA-1 и PDF/UA-2 формализуют машинно проверяемые требования к доступному PDF. Валидатор анализирует декларацию, структуру тегов, допустимые отношения элементов, аннотации, формы, Unicode-сопоставление, метаданные и другие объективные свойства. В отчёте правила привязаны к пунктам спецификации и объектам модели, что удобно для разработчика генератора или специалиста по тегированию.

Автоматическая проверка не охватывает требования, для которых нужна человеческая оценка. Наличие альтернативного текста не доказывает, что он передаёт смысл изображения; корректная структура таблицы не подтверждает удобство чтения сложной шапки; формально допустимый порядок элементов не всегда совпадает с логическим порядком восприятия. После зелёного результата необходима ручная проверка содержимого и тестирование с программой чтения с экрана.

При выборе Auto-detect документ без корректной декларации PDF/UA может быть проверен запасным PDF/A-1b. Для аудита доступности задавайте ua1 или ua2 явно. Если файл одновременно заявляет PDF/A и PDF/UA на совместимой базовой версии, возможны несколько validationReport; если базовые версии различаются, часть деклараций будет только отмечена предупреждением. Это особенно важно при сочетании PDF/A-3 и PDF/UA-2.

Отчёты PDF/UA могут содержать большое число повторов для структуры, ссылок, аннотаций и шрифтов. Сначала устраните нарушения верхнего уровня: отсутствие обязательной декларации, сломанное дерево структуры, циклические role maps или неверные родительские связи. После исправления базовой структуры повторная проверка часто сокращает каскад вторичных ошибок.

veraPDF не редактирует дерево тегов и не предлагает визуальный порядок чтения. Используйте отчёт как перечень формальных дефектов, внесите изменения в средство ремедиации, затем повторите проверку тем же профилем. Для регрессионного контроля сравнивайте не только итог, но и набор rule specification, clause и testNumber: один зелёный файл может после изменения стать красным по совершенно новой причине.

Зашифрованные и повреждённые документы

При встрече с зашифрованным PDF veraPDF сначала пытается использовать пустой пользовательский пароль. Если требуется непустой пароль, в CLI применяется --password. В графическом сценарии возможность обработки зависит от доступного способа передачи учётных данных; для партий с разными паролями удобнее внешний сценарий, который получает секрет из защищённого хранилища и запускает отдельный job для каждого файла.

Не записывайте пароль в общий командный файл, историю оболочки или публичный отчёт. Кроме того, успешное расшифрование не делает защищённый документ допустимым PDF/A: конкретный профиль может запрещать шифрование или требовать иные свойства. Разделяйте ошибку “не удалось открыть” и нормативное несоответствие после открытия.

Повреждённый PDF может попасть в failedToParse, вызвать veraException или сформировать error feature. В таком случае отсутствует надёжный полный validationReport. Сначала попробуйте открыть файл в независимом просмотрщике, проверить размер и контрольную сумму, получить повторную копию от поставщика. Автоматическое пересохранение редактором может изменить объект настолько, что диагностика первоначального дефекта станет невозможной; храните исходник.

Если ошибка воспроизводится только на одном документе, запустите его отдельно с подробным журналом и одним процессом. Если сбой появляется на всей партии, проверьте Java, память, права на временный каталог и конфигурационные XML. При сообщении outOfMemory уменьшите --processes и объём извлекаемых признаков, затем задайте больший heap через JAVA_OPTS. При внутреннем исключении сохраните минимальный проблемный файл, отчёт и сведения о компонентах.

Конфигурационные файлы

Настройки GUI и CLI хранятся в четырёх XML: app.xml, validator.xml, fixer.xml и features.xml. app.xml задаёт тип обработки, формат отчёта, verbose, папку исправлений, корень справки и политику. validator.xml содержит профиль, запасной flavour, регистрацию успехов, лимиты провалов, подробные сообщения, журналы, уровень логирования и показ прогресса. fixer.xml управляет исправлением, а features.xml — категориями извлечения.

При первом запуске конфигурация создаётся автоматически, если файлов ещё нет. Команда с --config без иных параметров применяет эти значения; явно указанные CLI-опции имеют приоритет. Это удобно для интерактивной работы, но в автоматизации может привести к скрытой зависимости от пользовательского профиля. Для воспроизводимого процесса храните копию конфигурации рядом со сценарием и явно задавайте критические параметры.

Местоположение конфигурации зависит от установки и профиля пользователя. Команда verapdf --config без входных файлов может вывести используемый каталог конфигурации, а документация также указывает подпапку config в установочном или пользовательском расположении. При неожиданном поведении сначала убедитесь, какой именно набор XML прочитан: правка файла в другом каталоге не влияет на запуск.

validator.xml позволяет установить maxFails=-1 для полного прохода, maxNumberOfDisplayedFailedChecks=100 для ограничения повторов, showErrorMessages, isLogsEnabled и loggingLevel. Не редактируйте XML при работающем приложении и проверяйте его синтаксис после изменения. Ошибка в конфигурации может помешать запуску или привести к возврату значений по умолчанию.

features.xml обычно содержит enabledFeatures. Названия в XML записываются в форме модели, например INFORMATION_DICTIONARY, METADATA, FONT или IMAGE_XOBJECT, тогда как CLI принимает informationDict, metadata, font и imageXObject. Не копируйте регистр и написание между форматами механически. После изменения выполните один файл и убедитесь, что ожидаемый узел действительно появился в featuresReport.

Установка и запуск

Перед установкой должна быть доступна Java 8, 11, 17 или 21. ZIP-пакет содержит JAR установщика и сценарии запуска для Windows, macOS и Linux. На Windows запускается verapdf-install.bat, на Unix-подобных системах — verapdf-install; тот же JAR можно открыть командой java -jar. Если система сообщает, что java не найдена, проверьте PATH и результат java -version.

Мастер сначала показывает сведения, затем предлагает каталог, набор компонентов, выполняет распаковку и при необходимости создаёт XML для повторной автоматической установки. В наборе компонентов можно выбрать GUI и сценарии, документацию, модель и дополнительные материалы; для минимального серверного окружения предусмотрена установка только CLI. Каталог должен быть доступен на запись и не требовать прав, которых нет у пользователя или службы.

Если сценарий на Linux или macOS не запускается, проверьте право исполнения и окончания строк. Запуск JAR через java -jar помогает отделить проблему сценария от проблемы Java. На Windows при нескольких Java убедитесь, что batch-файл видит поддерживаемую версию той же разрядности, которую вы проверили в терминале. Разрядность самой Java важнее разрядности ZIP, потому что пакет содержит переносимые JAR и сценарии.

После установки GUI запускается verapdf-gui или verapdf-gui.bat, CLI — verapdf или verapdf.bat. Параметры JVM передаются через JAVA_OPTS либо непосредственно сценарию. Это место используется для увеличения heap, задания системных свойств и диагностики. Изменяйте память постепенно и документируйте настройку, чтобы результат на рабочем месте и сервере можно было сопоставить.

Автоматическая установка использует XML с выбранным путём и компонентами. Она полезна для одинакового развёртывания на нескольких узлах, но файл конфигурации не содержит Java. Сначала обеспечьте поддерживаемый runtime, затем запускайте установщик с XML. После развёртывания выполняйте verapdf --version и контрольную проверку известного файла, а не ограничивайтесь наличием папки bin.

Ошибки интерфейса и способы устранения

Кнопка Execute не активна

Убедитесь, что строка входного файла заполнена. Для Custom profile нужен ещё и внешний validation profile; для Policy — файл политики и необходимые features. Если файл перетащен, но путь не появился, попробуйте Choose PDF и проверьте доступ к документу. В сетевой папке сначала скопируйте небольшой тестовый PDF локально, чтобы исключить задержку, блокировку и особенности прав.

Auto-detect выбирает неожиданный профиль

Автоматический выбор опирается на XMP-декларацию, а при её отсутствии или ошибке использует Default flavour. Откройте XML-отчёт и посмотрите profileName и предупреждения. Для обязательной процедуры задайте профиль явно. Если документ должен заявлять другой стандарт, сначала проверьте фактическое содержимое, а затем исправляйте идентификатор; простое изменение XMP без устранения остальных нарушений создаст ложную декларацию.

Отчёт слишком большой

Отключите Include passed rules, уменьшите Display failed checks for rule, не включайте все features, используйте TEXT для консоли и полный XML как отдельный файл. Для первичного фильтра задайте maxFailures. Помните, что ранняя остановка делает перечень нарушений неполным; такой результат нельзя использовать как исчерпывающий план ремонта.

HTML открылся, но нет подробных features

HTML ориентирован на validation information. Сохраните XML или JSON и найдите featuresReport. Если узел отсутствует, проверьте Report type и Features Config. Выбор Validation не запускает извлечение, а Policy извлекает только данные, нужные активной конфигурации. Для полного технического инвентаря используйте Validation & Features или отдельный проход Features.

Исправленный файл не создан

Проверьте Fix metadata, каталог назначения, права записи и repairReport. Исправление выполняется лишь для поддерживаемых метаданных и не применяется, если остаются другие нарушения, мешающие соответствию. Красный итог по шрифтам или структуре означает, что fixer сознательно не создаёт якобы исправленную PDF/A-копию.

Результаты различаются на двух компьютерах

Сравните buildInformation, выбранный профиль, custom profile, конфигурационные XML, Java, параметры отчёта и исходную контрольную сумму. Auto-detect может использовать разные default flavour, если XMP невалиден. Кроме того, один запуск может включать успешные checks, а другой — нет; это меняет объём отчёта, но не должно менять isCompliant при одинаковых правилах.

Интеграция в контроль качества и CI

Для автоматизированной проверки сохраняйте структурный отчёт как артефакт каждой сборки. Скрипт должен определить все jobs, проверить наличие validationReport, значение isCompliant и счётчики failedToParse, encrypted, outOfMemory и veraExceptions. Логика “в отчёте встречается false” слишком хрупка: JSON и XML могут содержать несколько профилей и несколько файлов, а отсутствие результата из-за сбоя нельзя считать успехом.

Закрепляйте профиль явно, когда формат является требованием продукта. Auto-detect полезен для исследования входных файлов, но в CI генератор должен выпускать конкретный PDF/A или PDF/UA. Команда фиксируется вместе с кодом, а внешний profile и policy получают контрольные суммы. Так изменение пользовательских настроек на агенте не меняет критерии сборки.

Для партии формируйте два уровня результата: краткий статус для разработчика и полный XML или JSON для анализа. В кратком сообщении достаточно имени файла, profileName, isCompliant, failedRules и первых нескольких clause. Полный отчёт не обрезайте, если он нужен для расследования; вместо этого ограничьте повторы через maxfailuresdisplayed ещё во время проверки.

В контейнере монтируйте входной каталог только для чтения, а отчёты — в отдельный том. Не помещайте исправленные файлы рядом с входными. Версию образа фиксируйте тегом или digest, иначе “latest” может изменить правила между двумя сборками. Даже при закреплённом образе сохраняйте buildInformation в артефакте.

Порог допуска лучше выражать через профили и политики, а не через разрешённое число ошибок. Один failed check означает несоответствие стандарту, даже если остальные тысячи прошли. Дополнительная бизнес-политика может разделять предупреждения и блокирующие требования, но нормативный isCompliant не следует превращать в процент качества.

Что veraPDF не заменяет

Программа не предназначена для редактирования текста, перестановки страниц, объединения документов, распознавания сканов, создания форм, наложения подписи или конвертации офисных файлов. Она анализирует структуру и формирует доказуемый результат. Для изменения содержимого нужен редактор или конвертер, после которого veraPDF выполняет независимую повторную проверку.

Metadata fixer не является полноценным преобразователем в PDF/A. Он не внедряет отсутствующие шрифты и ICC-профили, не удаляет запрещённые мультимедийные объекты, не перестраивает XRef, не создаёт логическое дерево тегов и не пишет осмысленные альтернативные описания. Его безопасная область ограничена XMP и согласованием отдельных метаданных.

Зелёный PDF/UA-отчёт не заменяет ручную оценку доступности. Зелёный PDF/A-отчёт не доказывает визуальную идентичность оригиналу, качество OCR или полноту пакета долговременного хранения. Feature report не подтверждает истинность Title, Author и других значений. Для каждого из этих вопросов нужен отдельный контроль с собственным критерием.

Наконец, валидатор не определяет, какой профиль должен требоваться организацией. Это решение зависит от нормативного документа, назначения хранилища, наличия вложений, доступности и базовой версии PDF. Указывать случайный flavour только ради зелёного результата неправильно: профиль должен быть выбран до проверки и отражать реальное требование.

От правила стандарта к исправлению файла

Профиль veraPDF представляет требования стандарта как набор формализованных правил. Каждое правило описывает тип объекта модели, проверяемое выражение и область применения. Во время разбора PDF создаются модельные объекты, после чего одно правило выполняется столько раз, сколько подходящих объектов найдено. Именно поэтому отчёт различает rule и check: правило соответствует нормативному требованию, а проверка — конкретному экземпляру этого требования в документе.

Разбор причины удобно начинать с specification и clause. Эти поля отвечают, к какому документу и пункту относится ограничение. Description пересказывает требование, object называет сущность модели, test показывает формальное условие, context указывает место провала. Для специалиста по PDF наиболее информативна связка object, test и context; для владельца процесса — specification, clause и человеческое описание. Сохраняйте обе части, иначе разработчик не найдёт объект, а аудитор не увидит нормативное основание.

Не пытайтесь исправлять все checks по отдельности. Сначала сгруппируйте их по specification, clause, testNumber и object. Затем возьмите несколько разных context и найдите общую первопричину. Например, десятки провалов на текстовых объектах могут происходить из одного отсутствующего ToUnicode CMap; множество ошибок изображения — из общего DeviceN или выходного профиля; каскад структуры PDF/UA — из неверного role mapping. После одной целевой правки повторный запуск покажет, исчезла ли группа целиком.

Если description кажется слишком общим, включите detailed errors и изучите журнал. При этом не включайте passed rules для проблемного многополосного документа без необходимости: успешные проверки затрудняют поиск и увеличивают файл. Полезнее сохранить два результата — компактный полный проход по всем правилам и отдельный диагностический проход конкретного PDF с полными сообщениями, но ограниченным числом повторов на правило.

После исправления сравнивайте набор идентификаторов правил до и после, а не только число failedChecks. Уменьшение повторов с тысячи до десяти не означает, что документ почти соответствует: пока остаётся хотя бы один обязательный failed check, isCompliant будет false. Одновременно новый набор ошибок может появиться потому, что редактор изменил структуру или декларацию. Такой регрессионный эффект виден только при сравнении групп правил.

Сводка партии и контроль каждого задания

Элемент batchSummary нужен для быстрой оценки всей обработки, но он не заменяет просмотр jobs. totalJobs сообщает количество принятых объектов. failedToParse учитывает файлы, которые не удалось разобрать как PDF. encrypted показывает задания, остановленные из-за защиты. outOfMemory отделяет нехватку памяти от нормативного отказа. veraExceptions фиксирует внутренние исключения. Любой ненулевой технический счётчик означает, что партия обработана не полностью, даже если среди сформированных validationReports все документы соответствуют профилю.

Внутри validationReports отдельно считаются compliant, nonCompliant и failedJobs. featureReports и repairReports имеют собственные failedJobs, потому что валидация, извлечение и исправление являются разными этапами одного задания. Документ может успешно пройти профиль, но вызвать проблему при извлечении выбранной редкой категории; либо feature report сформируется, а validation report отсутствует из-за неверного custom profile. Автоматический импорт должен проверять каждый ожидаемый раздел.

Для сопоставления отчёта с реестром используйте имя входного объекта и размер из item, но не считайте их криптографическим идентификатором. Два разных файла могут иметь одинаковое имя и размер. До запуска вычисляйте SHA-256 и связывайте его с job во внешней таблице либо переименовывайте временную копию по идентификатору. После проверки убедитесь, что файл не менялся; особенно это важно для сетевой папки, куда другой процесс продолжает записывать документы.

Duration на уровне job позволяет построить профиль производительности. Слишком быстрый результат иногда указывает на раннюю остановку или failedToParse, а необычно медленный — на сложную структуру, огромное число объектов или нехватку ресурсов. Сравнивайте длительность только при одинаковом профиле, features, числе процессов, Java и лимитах отчёта. Включение passed checks или подробных ошибок само по себе способно существенно увеличить время сериализации.

При повторном запуске партии не объединяйте отчёты простой конкатенацией XML. Сформируйте отдельный документ результата или загрузите jobs в базу с идентификатором запуска. Так можно отличить первоначальный отказ, результат после ремедиации и контрольную перепроверку. Для каждого запуска фиксируйте команду, профиль, policy, конфигурацию и buildInformation, иначе сравнение будет недостоверным.

Несколько деклараций соответствия в одном PDF

Один PDF может содержать несколько идентификационных схем XMP, например PDF/A и PDF/UA. veraPDF пытается проверить совместимые декларации, основанные на одной версии ядра PDF. Это позволяет получить несколько validationReport в одном job. При обработке такого результата нельзя брать только первый элемент: система должна перечислить profileName и isCompliant для каждого выполненного профиля.

Когда декларации опираются на разные базовые версии, все проверки одновременно невозможны в рамках одного разбора по заявленной логике. Тогда приоритет получает PDF/A, затем PDF/UA и другие профили той же основы, а несовместимая декларация отмечается предупреждением. Например, сочетание профиля на PDF 1.7 с PDF/UA-2 на PDF 2.0 требует внимательного чтения журнала. Отсутствие второго validationReport не означает, что второе соответствие подтверждено.

Для юридически или контрактно значимого контроля запускайте каждый обязательный профиль явно отдельной командой. Это устраняет неоднозначность приоритета и создаёт самостоятельный отчёт. Если один профиль требует другой базовой версии PDF, уже сам факт противоречивых деклараций может быть причиной отправить документ автору или конвертеру, а не пытаться добиться двух зелёных итогов случайным выбором настроек.

Запасной Default flavour применяется только тогда, когда автоматическое определение не получает пригодной декларации. Он не добавляет декларацию и не угадывает наиболее вероятную часть по используемым функциям. Поэтому в смешанной папке обычные PDF без XMP будут проверяться по одному запасному профилю. Чтобы не спутать их с заявленными PDF/A, извлекайте metadata и разделяйте “профиль выбран из XMP” и “профиль применён по умолчанию” в собственном отчёте.

После metadata fixing снова изучите список деклараций. Добавление идентификатора допустимо только когда остальные требования уже выполнены; удаление ложного идентификатора оставляет обычный PDF. Если документ заявлял два профиля, исправление одного XMP-узла может изменить автоматический выбор для следующего запуска. Поэтому финальную проверку выполняйте всеми требуемыми явными flavour, а не только Auto-detect.

Безопасная обработка недоверенных PDF

Валидатор разбирает сложные двоичные структуры, шрифты, CMap, формы, Rich Text, XFA, изображения и потоки. Документы из внешнего контрагента следует обрабатывать как недоверенные данные. Запускайте пакет под отдельной учётной записью без доступа на запись к исходному фонду, ограничивайте рабочую папку и не используйте каталог с секретами как временное пространство. Исправленные копии и отчёты направляйте в отдельный доступный каталог.

Не открывайте автоматически входной PDF в просмотрщике после красного или зелёного результата. Кнопки View XML и View HTML относятся к отчётам, тогда как сам PDF может содержать активные элементы, вложения и необычные конструкции. Feature extraction по actions, embeddedFile, interactiveFormField и postscriptXobject помогает инвентаризации, но не является антивирусной проверкой. Для вредоносного содержимого нужен отдельный защитный контур.

Ограничения памяти и времени полезны не только для производительности. Специально подготовленный файл может вызвать огромный объём проверок и отчёта. Устанавливайте разумный heap, число процессов, размер входного файла и лимит времени внешним оркестратором. maxfailures и maxfailuresdisplayed сокращают работу и вывод, но не заменяют системные лимиты. При срабатывании ограничения помечайте документ как не полностью проверенный.

HTML-отчёт открывается браузером и может содержать справочные переходы, сформированные из настраиваемого wiki root. В закрытом контуре используйте доверенный внутренний корень либо анализируйте XML без открытия внешних переходов. Не публикуйте отчёт без просмотра: context, журналы и item способны раскрыть имена файлов, пользовательские каталоги и внутреннюю структуру хранилища.

Для воспроизводимого расследования сохраняйте проблемный PDF в карантине, его SHA-256, канал поступления, точную команду, stderr и полный отчёт. Не пересохраняйте файл перед передачей разработчику валидатора, потому что редактор может нормализовать повреждённую структуру. Если содержимое конфиденциально, подготовьте минимальный воспроизводимый пример только после разрешения владельца данных.

Контрольный набор и регрессионное тестирование

Перед внедрением соберите небольшой набор, который отражает реальные документы организации: корректные представители каждого требуемого профиля, файлы с известными ошибками шрифтов, XMP, цветов, вложений и структуры, зашифрованный пример, повреждённый PDF и ZIP с вложенными папками. Для Policy добавьте положительные и отрицательные случаи каждого собственного условия.

Эталон не должен состоять только из файлов, которые когда-то прошли проверку. Нужны отрицательные примеры с ожидаемыми specification, clause и testNumber. Иначе обновление, которое перестало находить конкретную ошибку, останется незаметным. Для каждого теста храните ожидаемый isCompliant, допустимые технические счётчики и минимальный набор обязательных failed rules.

После изменения Java, конфигурации, профиля, Schematron или самого валидатора прогоните весь набор и сравните структурные поля. Различие текста сообщения может быть редакционным, а изменение clause, object или числа проверок — функциональным. Автоматическое сравнение должно допускать заведомо нестабильные значения duration и пути, но строго проверять профиль, итог и ожидаемые правила.

Особое внимание уделите Auto-detect. Добавьте файл с корректной декларацией, файл без XMP, файл с повреждённой идентификацией и документ с несколькими совместимыми и несовместимыми декларациями. Это проверит Default flavour, предупреждения и число validationReport. Такой набор предотвращает скрытую смену профиля при переносе конфигурации на другой компьютер.

Для производительности храните несколько крупных представителей и измеряйте время при фиксированных --processes, памяти и параметрах отчёта. Цель теста — не абсолютный рекорд, а обнаружение резкого ухудшения. Если время выросло, сначала сравните число checks и объём результата: новые правила или включённые features могут объяснить изменение без ошибки парсера.

Сравнение veraPDF с аналогами

Прямые аналоги различаются не только точностью правил, но и задачей вокруг проверки. Одни рассчитаны на валидацию для долговременного хранения, другие совмещают preflight с исправлением, третьи предоставляют библиотеку для разработчика или проверяют общую целостность формата. Таблица помогает выбрать инструмент по рабочему процессу, а не по одному названию функции.

Программа	Лучше подходит для	Главное ограничение
veraPDF	Независимой проверки PDF/A, PDF/UA и пакетной автоматизации	Не редактирует содержимое PDF
Adobe Acrobat Pro Preflight	Проверки и исправлений внутри знакомого PDF-редактора	Требуется коммерческая лицензия
callas pdfaPilot	Профессиональной конвертации, валидации и серверных процессов долговременного хранения	Коммерческий продукт
Apache PDFBox Preflight	Встраивания PDF/A-1b-проверки в Java-проект	Узкий охват профилей
JHOVE PDF-hul	Идентификации, характеризации и проверки общей структуры PDF	Не заменяет проверку PDF/A

Для специалиста по долговременному хранению, которому нужен открытый воспроизводимый отчёт по PDF/A и PDF/UA, разумной отправной точкой будет veraPDF. Acrobat Pro удобнее, когда тот же специалист должен сразу открыть проблемный объект и применить preflight fixup. pdfaPilot выбирают для промышленного преобразования и исправления больших потоков. PDFBox Preflight подходит разработчику с узкой задачей PDF/A-1b, а JHOVE дополняет профильную проверку оценкой общей корректности и технической характеризацией PDF.

PDF Commander решает другой этап работы: редактирует и собирает пользовательские документы, но не является профильным валидатором ISO 19005 или PDF/UA. Его можно применять до проверки для правки страниц и содержимого, однако итоговое подтверждение профиля долговременного хранения или доступности следует получать специализированным средством.

Типовые рабочие процессы

Приём документов в электронное хранилище

1. Вычислите контрольную сумму входного PDF и запишите канал поставки.
2. Запустите veraPDF с профилем, указанным в регламенте, а не с произвольным Auto-detect.
3. Сохраните XML или JSON и отдельно краткий статус для оператора.
4. Проверьте failedToParse, encrypted, outOfMemory и исключения, затем isCompliant.
5. Некорректные файлы направьте на исправление; соответствующие свяжите с отчётом и контрольной суммой.

Для смешанного наследуемого фонда сначала выполните инвентаризационный проход Auto-detect с feature extraction. Сгруппируйте декларации, версии PDF, Producer и типичные нарушения. После этого установите целевые профили по сериям. Такой порядок предотвращает массовую проверку всех документов как PDF/A-1b только потому, что запасной flavour оставлен по умолчанию.

Контроль после конвертации в PDF/A

Сохраните исходник и конвертированную копию, извлеките из обеих основные признаки, проверьте целевой профиль и сравните число страниц, метаданные, шрифты, изображения и вложения. Затем выполните визуальную выборку. Если конвертер исправляет документ повторно, создавайте новый идентификатор копии и новый отчёт; не перезаписывайте файл, к которому уже относится предыдущая контрольная сумма.

Проверка доступности публикации

Запустите явный ua1 или ua2, устраните формальные ошибки, затем проверьте порядок чтения, заголовки, таблицы, формулы, альтернативные описания и поведение с экранным диктором. Сохраните veraPDF-отчёт как машинную часть доказательства, а ручную оценку оформите отдельным протоколом. Отсутствие failed checks не отменяет человеческие checkpoints.

Контроль корпоративной политики

Определите измеримые требования, включите только необходимые features, создайте Schematron и положительный/отрицательный тестовый набор. Запускайте policy вместе с нормативным профилем и разделяйте причины отказа в отчётности. Например, документ может быть корректным PDF/A-2b, но не пройти внутреннее требование о Title или разрешённом Producer; эти результаты не противоречат друг другу.

Практические ответы на вопросы

Можно ли проверить обычный PDF без декларации PDF/A?

Да, но нужно осознанно выбрать профиль. В Auto-detect при отсутствии пригодной XMP-декларации применяется Default flavour, стандартно PDF/A-1b. Если вашей целью является PDF/A-2b или PDF/UA-1, задайте его явно; иначе отчёт будет корректным для применённого профиля, но бесполезным для вашей задачи.

Можно ли одним запуском проверить PDF/A и PDF/UA?

Автоматический режим способен обработать несколько деклараций, основанных на одной базовой версии PDF. Для несовместимых базовых версий действует приоритет, и часть деклараций только отмечается предупреждением. В строгом контроле проще выполнить два явных запуска и сохранить два validationReport, чтобы отсутствие одной проверки нельзя было пропустить.

Почему один rule создаёт тысячи ошибок?

Rule применяется к каждому подходящему объекту. Один не встроенный шрифт, повторённый на страницах или в ресурсах, может дать множество failed checks. Ограничьте отображение повторов, но изучите context нескольких первых случаев и общее число. После исправления первопричины повторный запуск покажет, исчезла ли вся группа.

Можно ли проверить вложения внутри ZIP?

Да, ZIP сканируется рекурсивно на PDF. Однако вложения внутри самих PDF анализируются как Embedded Files и зависят от профиля и feature extraction. Это два разных уровня контейнера: ZIP для транспортного пакета и embedded files в структуре документа.

Проверяет ли veraPDF электронную подпись криптографически?

Feature extraction может сообщать сведения о signature-объектах, а профиль проверяет относящиеся к формату требования. Это не следует приравнивать к полной проверке доверительной цепочки, статуса сертификата, метки времени и юридической силы. Для криптографической верификации используйте специализированное средство и доверенное хранилище сертификатов.

Можно ли получить только сведения о шрифтах?

Да. В GUI выберите Features и отметьте Fonts в Features Config. В CLI отключите validation и укажите --extract font. Такой отчёт показывает параметры ресурсов, но его объём может быть значительным для документов с множеством подмножеств.

Почему HTML и XML отличаются по содержанию?

HTML оптимизирован для чтения validation information, тогда как XML хранит составной machine-readable report, включая features и repair. Для технического анализа исходным доказательством лучше считать XML или JSON, а HTML использовать как представление для специалиста.

Можно ли исправить файл одной кнопкой?

Только поддерживаемые проблемы XMP и согласования метаданных, причём при отсутствии других препятствий соответствию. Для шрифтов, цветов, тегов, действий, аннотаций и содержимого нужна внешняя ремедиация. После любой правки необходим новый полный запуск.

Как проверить файлы без расширения .pdf?

В GUI их можно выбрать или перетащить. В CLI добавьте --nonpdfext. Не включайте этот режим для произвольного каталога без фильтра: парсер будет получать неподходящие объекты, а отчёт заполнится failedToParse.

Как сохранить доказательство проверки?

Храните исходную контрольную сумму, профиль, policy, configuration, buildInformation, дату, полный XML или JSON и краткий итог. Если создаётся исправленная копия, вычислите новую сумму и свяжите оба отчёта. Один снимок красной или зелёной строки из GUI недостаточен для воспроизводимого аудита.

Итоговый порядок работы

Начинайте с требования: определите PDF/A-часть и уровень либо PDF/UA-профиль. Затем выберите один файл, папку или ZIP, настройте Report type и объём деталей. Для первичной ручной проверки достаточно Validation и HTML; для хранилища или автоматизации сохраняйте XML или JSON. При смешанном фонде используйте Auto-detect как исследовательский режим, но не как замену формальному критерию.

При красном результате переходите от failedRules к failedChecks и context: сначала найдите разнообразие причин, затем оцените количество повторов. Для огромных отчётов ограничьте отображение повторов, а не удаляйте правила. Если job не разобран, зашифрован или завершён исключением, не классифицируйте его как просто non-compliant — это отдельная техническая ошибка.

Используйте feature extraction для понимания внутреннего состава, Policy — для измеримых требований организации, Fix metadata — только для поддерживаемых XMP-операций. Все изменения проверяйте заново. В процессе PDF/UA добавляйте ручную оценку доступности, в процессе PDF/A — визуальный контроль, проверку OCR и полноты пакета.

Завершённая проверка должна оставлять воспроизводимый след: неизменённый PDF, его контрольную сумму, точный профиль, конфигурацию, сведения о компонентах и полный структурный отчёт. Такой комплект позволяет не просто увидеть итог veraPDF, а доказать, какой файл, по каким правилам и с каким результатом был проверен.