Datalogics PDF Checker проверяет PDF-файлы на повреждения структуры, не встроенные шрифты, проблемные изображения, JavaScript, вложения, прозрачность, метаданные и несоответствие заявленному PDF/A, а затем формирует читаемый текстовый или машинный JSON-отчёт для ручной проверки и автоматической маршрутизации документов.

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

Главный управляющий элемент — JSON-профиль. В нём для каждой проверки отдельно задаются включение, уровень результата, собственное сообщение и остановка оставшихся тестов; поэтому один и тот же исполняемый файл можно настроить для долговременного хранения, типографии, OCR-маршрута, проверки вложений или первичного контроля повреждённых документов без изменения исходного PDF.

Как устроена проверка PDF

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

В одном запуске проверяется один входной PDF. Для папки документов создают внешний цикл в пакетном файле, PowerShell, Bash, Python или системе управления заданиями. Такой подход делает имя входного файла, имя профиля и место сохранения отчёта явными для каждого задания. Ошибка в отдельном документе не требует объединять остальные файлы в очередь внутри самой утилиты: управляющий сценарий получает код завершения, анализирует отчёт и решает, продолжать обработку, отправить файл на исправление или переместить его в карантин.

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

Первый запуск и обязательные параметры

Минимальная команда содержит исполняемый файл, параметр входного PDF и параметр JSON-профиля. Короткие ключи -i и -j равнозначны длинным вариантам --input и --profile. Без одного из этих аргументов программа не знает, какой документ анализировать или какие условия применять, поэтому завершает запуск с отдельным кодом ошибки.

pdfchecker --input test.pdf --profile everything.json

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

pdfchecker --input "C:\Incoming PDF\report.pdf" --profile "C:\PDF Profiles\archive.json"

Для Linux используются те же длинные ключи; меняется только форма путей и, возможно, способ вызова исполняемого файла. Если каталог программы не добавлен в переменную PATH, перед именем указывают полный путь или запускают файл из его каталога. В автоматизации лучше не полагаться на текущую папку: абсолютные пути уменьшают риск, что служба стартует из другого рабочего каталога и не найдёт PDF либо профиль.

Куда направить результат

Без параметров вывода текстовый отчёт появляется в консоли. Ключ --output сохраняет человекочитаемый вариант, а --json-output создаёт структурированный JSON. В качестве имени результата допустим дефис: он означает вывод соответствующего формата в стандартный поток. Один и тот же формат нельзя одновременно показать в консоли и записать в файл одним запуском, но текстовый и JSON-варианты можно комбинировать.

pdfchecker --input test.pdf --profile everything.json --output result.txt
pdfchecker --input test.pdf --profile everything.json --json-output result.json
pdfchecker --input test.pdf --profile everything.json --output result.txt --json-output result.json
pdfchecker --input test.pdf --profile everything.json --json-output - --output result.txt
pdfchecker --input test.pdf --profile everything.json --output - --json-output result.json

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

JSON-профиль: основная логика настройки

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

Каждая проверка содержит четыре управляющих поля. check включает или исключает тест. report-as-error определяет, попадёт сработавшее условие в раздел ошибок или информации. report-message задаёт понятный текст для отчёта. abort-remaining-checks останавливает оставшиеся тесты после обнаружения выбранного признака. Ключи, строковые значения on и off, а также имена условий пишутся строчными буквами и заключаются в кавычки.

"uses-fonts-not-embedded": {
  "check": "on",
  "report-as-error": "on",
  "report-message": "Uses fonts not embedded in document",
  "abort-remaining-checks": "off"
}

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

Включение и выключение условий

Чтобы исключить дорогую или ненужную проверку, достаточно установить "check": "off". Удаление блока тоже уменьшает профиль, однако выключенный блок сохраняет параметры как подсказку и позволяет быстро вернуть тест. Для нескольких процессов удобно поддерживать базовый профиль и отдельные копии: профиль долговременного хранения включает PDF/A, шрифты и метаданные; профиль безопасности — JavaScript, вложения, частные данные и подписи; допечатный — разрешение изображений, цветовые параметры, прозрачность и встраивание шрифтов.

Не стоит включать всё как ошибку. Наличие метаданных, аннотаций, подписи, слоёв или формы может быть нормальной характеристикой. Ошибкой эти признаки становятся только при конкретном регламенте. Например, в файле для публикации вложение может быть запрещено, а в электронном досье — обязательно. PDF Checker даёт механизм классификации, но бизнес-смысл задаёт профиль.

Остановка оставшихся тестов

Поле abort-remaining-checks экономит время, когда найденное условие делает дальнейший анализ бессмысленным. Типичный пример — входной объект не является открываемым PDF или защищён паролем, который не передан. Для повреждённого документа программа сначала пытается восстановить представление в памяти; если это не удаётся, оставшиеся категории не могут быть исследованы полноценно.

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

Ошибки и информационные признаки

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

В человекочитаемом отчёте ошибки и информация сгруппированы по категориям. В JSON это словари errors и information, где ключом является имя проверки, а значением — массив подробностей. Не рассчитывайте, что массив всегда содержит одну строку: для шрифтов, аннотаций, изображений и других повторяющихся объектов программа может перечислить несколько экземпляров или типов.

Общие признаки документа

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

• Проверка unable-to-open отделяет корректный PDF от файла с неверным форматом, отсутствующего пути или критической порчи.
• password-protected показывает, что для открытия нужен пароль; ключ --password передаёт его в текущем запуске.
• contains-owner-password обнаруживает ограничения владельца, даже если документ открывается без пароля просмотра.
• contains-signature сообщает о цифровой подписи, важной перед любым последующим изменением файла.
• xfa-type и acroforms-type различают XFA и обычные поля AcroForm.
• pdf-v2 отмечает документ PDF 2.0, если принимающая система рассчитана на более старый набор возможностей.
• tagged-pdf показывает наличие структуры тегов, используемой доступностью и логической навигацией.
• born-digital и image-only помогают выбрать прямое извлечение текста либо OCR.

Признак сам по себе не гарантирует качество. Наличие тегов не доказывает правильную семантику и порядок чтения. Наличие подписи не означает, что доверие к сертификату уже проверено. Заявление PDF/A в метаданных не равно соответствию стандарту — для этого существует отдельная проверка фактического соответствия заявленному типу. Профиль должен различать функция присутствует и функция корректна для назначения.

Пароль защищённого PDF

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

pdfchecker --input protected.pdf --profile security.json --password "пароль" --json-output protected-result.json --nopath

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

Повреждение и восстановление в памяти

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

Частичное восстановление способно открыть каталог и шрифты, но завершиться ошибкой на изображениях или пользовательских данных. В таком случае отчёт разделяет завершённые и прерванные проверки. Автоматическая система должна учитывать неполноту: отсутствие найденного JavaScript после прерывания категории объектов не доказывает, что JavaScript в документе отсутствует.

Проверка заявленного соответствия PDF/A и другим стандартам

PDF Checker читает заявления о соответствии PDF/A, PDF/X, PDF/E, PDF/VT и PDF/UA. Для PDF/A он также способен сообщить, что документ не соответствует заявленному типу. Практический сценарий начинается с поля заявленного уровня: например, файл может объявлять PDF/A-2a. Затем результат проверки показывает, подтверждено ли это заявление. Такое разделение полезно, потому что документ без заявления и документ с ложным заявлением требуют разных решений.

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

Для PDF/X, PDF/E, PDF/VT и PDF/UA факт заявления не всегда означает полную валидацию всех требований. Поэтому в профиле не стоит заменять специализированный валидатор простым условием claims-.... Эти ключи удобны для классификации и первичного контроля: они показывают, что автор документа намеревался соблюдать конкретный стандарт, и помогают выбрать следующий инструмент.

Диагностика шрифтов

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

• uses-fonts-not-embedded перечисляет гарнитуры, для которых в документе нет встроенных данных.
• uses-fonts-fully-embedded фиксирует полностью встроенные наборы, что полезно для инвентаризации.
• uses-base14fonts-not-embedded выделяет базовые шрифты, на которые старые процессы нередко полагаются без вложения.
• fontdescriptor-missing-fields обнаруживает отсутствующие обязательные поля описателя.
• fontdescriptor-missing-capheight отдельно показывает отсутствие CapHeight, значимого для латинских символов.

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

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

Проверка изображений и разрешения

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

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

Дополнительно определяются JPEG 2000 для цветных и серых изображений, JBIG2 для монохромных, альтернативные изображения и глубина цветового канала. Шестнадцати- или тридцатидвухбитные данные могут быть несовместимы с конкретным конвейером. Альтернативные изображения увеличивают сложность документа и иногда хранят варианты, которые не используются обычным просмотром.

• Для веб-публикации проверяйте низкий и чрезмерно высокий DPI, чтобы не пропустить размытый контент и неоправданно тяжёлые страницы.
• Для печати разделяйте цветные, серые и монохромные пороги; одинаковое значение для всех типов редко соответствует реальной задаче.
• Для долговременного хранения рассматривайте кодек как признак совместимости, а не только степени сжатия.
• Для OCR-маршрута сочетайте image-only с числом страниц и характеристиками изображений.

Объекты, действия JavaScript и миниатюры страниц

В группе объектов проверяются JavaScript-действия и миниатюры страниц. JavaScript может быть нужен интерактивной форме, но при долговременном хранении, почтовом шлюзе или процессе безопасного просмотра он часто запрещён. Условие contains-javascript-actions не исполняет сценарий и не оценивает его намерение; оно сообщает о наличии механизма, после чего политика решает, разрешить файл, провести дополнительный анализ или удалить действия в отдельном инструменте.

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

Аннотации, вложения, слои и другие пользовательские данные

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

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

Встроенные файлы превращают PDF в контейнер. Они полезны в электронном досье, но могут переносить неожиданные форматы и увеличивать размер. PDF Checker сообщает факт наличия, после чего отдельная система должна извлечь и проверить содержимое. Сам отчёт не является антивирусным заключением и не заменяет анализ вложенных файлов.

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

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

Как читать текстовый отчёт

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

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

Размер в байтах и признак возможности оптимизации полезны для очереди сжатия. Не следует отправлять каждый маленький PDF на повторную обработку только потому, что найдена одна консервативно сжатая структура. Скрипт может сочетать can-be-optimized, размер, число страниц и конкретные рекомендации, чтобы не тратить ресурсы на незначительный выигрыш.

Блок CHECKER_SUMMARY

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

После резюме идут разделы General, Fonts, Color Images, Grayscale Images, Monochrome Images, Objects, Cleanup и Userdata. В каждом показываются ошибки, информационные признаки, завершённые проверки, прерванные проверки и рекомендации. Пустые разделы могут быть сокращены, поэтому парсер текстового отчёта не должен ожидать фиксированное число строк.

Errors, Information и Checks Completed

Раздел Errors содержит условия, которые профиль классифицировал как ошибки. Information включает найденные, но не критические признаки. Checks Completed перечисляет выполненные тесты даже тогда, когда они ничего не нашли. Это различие принципиально: отсутствие ключа в ошибках может означать как чистый результат, так и выключенную либо прерванную проверку. Подтверждение завершения снимает эту неоднозначность.

Раздел Checks Aborted сообщает, какие тесты не были доведены до результата. В автоматическом решении такие проверки должны иметь состояние неизвестно, а не успешно. При прерывании на раннем этапе файл можно пометить как требующий повторного анализа после устранения причины.

Текстовый отчёт после остановки

При остановке в верхней части отчёта указывается вызвавшее её условие. Далее категории показывают то, что успело завершиться, и списки прерванных тестов. Из-за параллельного выполнения порядок и состав завершённых элементов могут немного отличаться. Для оператора главное — причина остановки и наличие непроверенных категорий.

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

Как устроен JSON-отчёт

JSON-формат начинается объектом analysis-summary. В нём находятся дата запуска, входной файл, профиль, размер, число страниц, язык, признаки ошибки и информации, возможность оптимизации и причина прерывания. Затем для каждой категории создаётся объект результатов с массивами завершённых и прерванных проверок, словарями ошибок, информации и рекомендаций.

{
  "analysis-summary": {
    "can-be-optimized": true,
    "errors": ["uses-fonts-not-embedded"],
    "information": ["contains-metadata"],
    "input": "input.pdf",
    "number-of-pages": 42,
    "profile": "everything.json",
    "size-in-bytes": 4389012,
    "triggered-abort": "none"
  }
}

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

Категории и подробности

Объекты fonts-results, general-results, color-images, grayscale-images, monochrome-images, image-results, objects-results, cleanup-results и userdata-results имеют одинаковую общую модель. Это упрощает универсальный обход: сценарий может пройти по всем ключам, заканчивающимся на -results, собрать ошибки и проверить, не остались ли прерванные тесты.

Значения в errors и information часто представлены массивами строк. Например, для шрифтов перечисляются гарнитуры и число экземпляров, для аннотаций — подтипы, для метаданных — тип и размер области обновления. Сохраняйте исходный массив, а не склеивайте его сразу в одну строку: структурированная запись лучше подходит для фильтрации и аналитики.

Рекомендации how-to-optimize

Словарь how-to-optimize объясняет, какие найденные элементы могут быть удалены, сжаты или преобразованы отдельным средством. Примеры относятся к аннотациям, метаданным, заполнителю XMP, прозрачности и консервативно сжатым потокам. Эти строки — рекомендации, а не подтверждение безопасного исправления. Перед изменением проверяйте роль элемента, подписи и требования к сохранению документа.

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

JSON после прерывания

При критической ошибке triggered-abort содержит имя условия, а массивы checks-aborted перечисляют незавершённые тесты. В примере неоткрываемого файла число страниц равно нулю, can-be-optimized ложно, а общая ошибка включает unable-to-open. Такие значения следует воспринимать совместно: ноль страниц здесь не означает корректный пустой документ.

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

Практические профили для разных задач

Приём документов в информационную систему

На входе обычно важны открываемость, пароль просмотра, повреждение, число страниц, размер, JavaScript, вложения и тип формы. Необязательные функции можно записывать как информацию, а невозможность открыть файл — как ошибку с остановкой. Если система не поддерживает XFA, соответствующий признак становится ошибкой маршрутизации: документ отправляется на преобразование или ручную проверку.

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

Контроль перед печатью

Допечатный профиль включает не встроенные шрифты, поля FontDescriptor, разрешение цветных, серых и монохромных изображений, глубину цвета, JPEG 2000, JBIG2, прозрачность, слои, аннотации с флагами печати и заявление PDF/X. Уровни ошибок зависят от конкретного устройства и контракта, поэтому пороги DPI должны быть согласованы с типографией.

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

Маршрутизация на OCR

Связка image-only, born-digital, тегов и извлекаемого текста помогает выбрать обработку. Изображение-only PDF направляют на OCR, цифровой документ с нормальным текстом — сразу на извлечение, а файл с не извлекаемым текстом — на специальный маршрут, потому что видимые символы могут иметь проблемное кодирование или шрифтовое отображение.

Количество страниц и разрешение изображений дополняют решение. Очень низкий DPI предупреждает о слабом качестве OCR, а огромный многостраничный скан можно разбить или поставить в очередь с большим лимитом ресурсов. PDF Checker не распознаёт текст; он выдаёт признаки, по которым внешний процесс выбирает распознаватель.

Контроль долговременного хранения

Для долговременного хранения включают заявление PDF/A, фактическое соответствие заявленному типу, шрифты, метаданные, теги, подписи, вложения и JavaScript. Наличие метаданных обычно не считается ошибкой; важнее их сохранность и соответствие регламенту. JavaScript и внешние зависимости могут быть запрещены, а вложения — разрешены только для определённого уровня PDF/A и состава дела.

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

Проверка перед удалением лишних данных

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

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

Пакетная обработка в Windows

PDF Checker принимает один входной файл за запуск, поэтому папку обходят средствами оболочки. В PowerShell безопасно создавать отдельное имя JSON для каждого PDF и проверять код возврата. Пример ниже показывает принцип; пути и правила хранения журналов следует адаптировать к своей системе.

$profile = "C:\PDF Profiles\ingest.json"
Get-ChildItem "C:\Incoming" -Filter *.pdf | ForEach-Object {
    $result = Join-Path "C:\Reports" ($_.BaseName + ".json")
    & pdfchecker --input $_.FullName --profile $profile --json-output $result --nopath
    if ($LASTEXITCODE -ne 0) {
        Write-Error "PDF Checker завершился с кодом $LASTEXITCODE: $($_.Name)"
    }
}

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

Пакетная обработка в Linux

В Bash используйте нулевые разделители, чтобы корректно обрабатывать пробелы и необычные символы в именах. Выходной каталог создаётся заранее, а ошибка каждого запуска записывается отдельно. Если программа не находится в PATH, переменная checker должна содержать абсолютный путь.

checker="/opt/datalogics/pdfchecker"
profile="/etc/pdfchecker/ingest.json"
mkdir -p /var/reports/pdfchecker
find /var/incoming -type f -iname "*.pdf" -print0 | while IFS= read -r -d "" file; do
  base=$(basename "$file" .pdf)
  report="/var/reports/pdfchecker/${base}.json"
  "$checker" --input "$file" --profile "$profile" --json-output "$report" --nopath
  rc=$?
  if [ $rc -ne 0 ]; then
    printf "%s\t%s\n" "$rc" "$file" >> /var/log/pdfchecker-errors.tsv
  fi
done

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

Разбор результата в Python

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

import json
from pathlib import Path

def read_checker_report(path: str) -> dict:
    data = json.loads(Path(path).read_text(encoding="utf-8"))
    summary = data.get("analysis-summary", {})
    errors = {}
    information = {}
    aborted = []
    for name, value in data.items():
        if not name.endswith("-results") or not isinstance(value, dict):
            continue
        errors.update(value.get("errors", {}))
        information.update(value.get("information", {}))
        aborted.extend(value.get("checks-aborted", []))
    return {
        "input": summary.get("input"),
        "pages": summary.get("number-of-pages"),
        "can_be_optimized": summary.get("can-be-optimized"),
        "triggered_abort": summary.get("triggered-abort"),
        "errors": errors,
        "information": information,
        "aborted_checks": sorted(set(aborted)),
    }

Решение о приёме нельзя строить только на непустом errors. Сначала проверяйте причину остановки и список прерванных тестов. Затем применяйте правила к конкретным ключам: например, не встроенные шрифты блокируют печатный маршрут, но метаданные только создают задачу очистки. Сохраняйте оригинальный JSON для повторного анализа после изменения правил.

Коды ошибок запуска

Отдельные коды завершения помогают отличить дефект документа от ошибки вызова. Код 1001 означает неверный синтаксис команды. 1002 сообщает, что профиль не найден. 1003 указывает на некорректный JSON. 1004 появляется при недопустимом значении флага. 1005 означает невозможность создать или открыть файл результата. Коды 1006 и 1007 соответствуют отсутствующему входному PDF и отсутствующему JSON-профилю.

Код	Причина	Что проверить
1001	Ошибка синтаксиса	Ключи, кавычки, порядок аргументов и лишние символы
1002	Профиль не найден	Имя, каталог CheckerProfiles, текущую папку и абсолютный путь
1003	Профиль не является корректным JSON	Запятые, кавычки, скобки и кодировку файла
1004	Недопустимое значение	Строчные ключи, строки on/off и допустимые имена условий
1005	Нельзя создать результат	Права каталога, существование папки, блокировку и свободное место
1006	Не указан входной PDF	Наличие аргумента --input и его значения
1007	Не указан профиль	Наличие аргумента --profile и его значения

При 1003 сначала проверьте JSON обычным валидатором, затем убедитесь, что профиль содержит ожидаемую структуру PDF Checker. Синтаксически корректный JSON всё равно может иметь неправильное имя параметра или значение, что приводит к 1004. При 1005 попробуйте создать простой файл тем же пользователем службы в том же каталоге; так отделяется проблема программы от прав файловой системы.

Устранение типичных проблем

Профиль не найден

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

Профиль отклонён как некорректный

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

Не создаётся отчёт

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

Пути с пробелами разбиваются

Кавычки должны охватывать весь путь, а не отдельную часть. В PowerShell передавайте аргументы как отдельные элементы вызова, а не собирайте одну длинную строку без экранирования. В Bash всегда заключайте переменные пути в двойные кавычки. Ошибка проявляется как отсутствующий входной файл, профиль или неожиданный лишний аргумент.

Отчёт неполный

Найдите triggered-abort и массивы checks-aborted. Если причиной стал пароль, повторите запуск с разрешённым секретом. Если файл повреждён или не открывается, получите исправленную копию из доверенной системы хранения либо обработайте её отдельным инструментом, затем повторите проверку. Не интерпретируйте пустые разделы как отсутствие проблем, пока не подтверждено завершение соответствующих тестов.

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

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

Документ выглядит нормально, но отмечен повреждённым

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

Совместимость и развёртывание

Для выполнения команд используются 64-разрядная Windows 11 либо Linux на x86_64 и AArch64 с GLIBC 2.28 или новее. Перед развёртыванием на сервере проверьте архитектуру и версию системной библиотеки. Контейнер или образ старого дистрибутива может иметь недостаточную GLIBC даже на современном ядре. Для macOS отдельного исполняемого варианта нет, поэтому процесс размещают на поддерживаемом узле или используют другой инструмент.

Установщик запрашивает ключ активации, который получают перед загрузкой после заполнения формы Datalogics. В Windows запускают файл формата .exe, в Linux — .bsx; ключ вводят во время установки. Для автоматического развёртывания заранее согласуйте хранение ключа и способ установки, чтобы секрет не попадал в общий сценарий или журнал сборки.

В Windows установщик добавляет каталог исполняемого файла в системный PATH, что позволяет вызывать pdfchecker.exe из разных папок. В Linux путь обычно настраивается администратором. Для службы лучше фиксировать абсолютный путь: обновление окружения пользователя не всегда распространяется на уже созданную системную службу.

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

Производительность и устойчивость процесса

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

Ранняя остановка снижает затраты на заведомо неприемлемые файлы. Однако слишком агрессивный abort-remaining-checks лишает отчёт полезной диагностики и создаёт дополнительные повторы. Хороший компромисс: немедленно прекращать работу при невозможности открыть документ или отсутствии пароля, но продолжать после обычных содержательных нарушений, чтобы исправляющий этап получил полный список.

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

Безопасность отчётов и входных файлов

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

Не запускайте исправление только по рекомендации how-to-optimize. Изменение подписанного PDF может сделать подпись недействительной, удаление метаданных — нарушить описание долговременного хранения, а удаление вложения — уничтожить часть дела. PDF Checker даёт инвентарь и диагностику; полномочие на изменение задаётся регламентом и отдельным процессом.

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

Точные пороги разрешения в полном профиле

В полном примере профиля используются отдельные исходные пороги для трёх классов изображений. Цветные и полутоновые изображения считаются низкоразрешёнными ниже 150 DPI и высокоразрешёнными выше 600 DPI. Для монохромных изображений исходные границы составляют 200 и 1200 DPI. Эти числа не являются универсальным стандартом качества: они показывают стартовую конфигурацию, которую необходимо согласовать с реальным способом вывода.

Порог задаётся внутри соответствующего блока resolution-too-low или resolution-too-high. Если в документе несколько копий одного изображения с разными эффективными размерами на странице, результат следует оценивать по фактическому использованию. Растровый объект может иметь достаточное число пикселей, но стать низкоразрешённым после сильного увеличения в макете. PDF Checker считает изображения, попавшие за границу, и помогает найти файлы, для которых требуется детальный префлайт.

"color": {
  "resolution-too-low": {
    "check": "on",
    "trigger-dpi": 150,
    "report-as-error": "on"
  },
  "resolution-too-high": {
    "check": "on",
    "trigger-dpi": 600,
    "report-as-error": "off"
  }
}

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

Результат resolution-too-high лучше сначала считать информационным. Высокое разрешение увеличивает размер, но не делает документ функционально неверным. resolution-too-low чаще назначают ошибкой в печатном маршруте. В процессе долговременного хранения оба условия могут быть информацией, если регламент важнее размера и не требует визуальной оценки каждого изображения.

Консервативное сжатие потоков

Условие suboptimal-compression ищет потоки без сжатия и потоки, использующие менее эффективные способы, включая ASCII, Run Length и LZW. Поток PDF может содержать текстовые команды, изображение или другой объект. Наличие такого потока не означает повреждение: документ открывается, но занимает больше места и может медленнее передаваться или обрабатываться.

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

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

Неизвлекаемый текст и поиск по документу

Проверка found-non-extractible-text выявляет шрифты и кодирование, при которых стандартный PDF-процессор не может извлечь текст ожидаемым способом. Страница при этом может выглядеть правильно. Пользователь замечает проблему позже: поиск не находит видимые слова, копирование создаёт бессмысленные символы, индексатор не строит полнотекстовый индекс, а система анализа документов получает пустой или искажённый результат.

Этот признак отличается от image-only. В сканированном PDF текста как объекта может не быть вообще, и нужен OCR. В файле с неизвлекаемым текстом текстовые объекты присутствуют, но связь кодов символов с Unicode нарушена или неполна. OCR может быть обходным путём, однако сначала стоит проверить возможность повторной генерации PDF с корректным сопоставлением символов или встраиванием шрифта.

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

Формы XFA и AcroForm

Проверки xfa-type и acroforms-type помогают маршрутизировать интерактивные документы. AcroForm поддерживается широким кругом PDF-программ, тогда как XFA зависит от более ограниченного набора средств и может не работать в браузерных просмотрщиках. PDF Checker не заполняет форму и не проверяет бизнес-логику полей; он сообщает тип, чтобы следующая система не пыталась обработать несовместимую структуру.

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

Одновременный учёт формы, JavaScript и подписи даёт более точное решение. XFA без сценариев и неподписанный XFA с динамическими вычислениями — разные по сложности документы, хотя тип формы совпадает. Профиль фиксирует каждый признак отдельно, а маршрутизатор объединяет их в правило.

Пароль владельца и ограничения операций

contains-owner-password показывает наличие пароля владельца, которым задаются ограничения на печать, копирование, изменение, комментирование, извлечение страниц или подпись. Такой PDF может открываться без пароля просмотра, поэтому обычная проверка доступности не обнаружит ограничение. Для процесса редактирования или сборки это существенный признак: следующий инструмент может отказать в операции либо потребовать разрешённый пароль.

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

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

Цифровые подписи в контрольном маршруте

contains-signature обнаруживает наличие одной или нескольких подписей, но не заменяет криптографическую проверку доверия, срока сертификата и целостности. Для PDF Checker подпись — характеристика, влияющая на последующие действия. Любое исправление, оптимизация, удаление метаданных или изменение аннотации может сделать существующую подпись недействительной.

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

Не используйте отсутствие ключа в массиве информации как доказательство отсутствия подписи, если общая группа была прервана. Сначала найдите contains-signature среди checks-completed. Только завершённая проверка без срабатывания даёт корректный отрицательный результат.

Теги и доступность

tagged-pdf проверяет присутствие структурных тегов, описывающих заголовки, текст, примечания и другие элементы. Теги нужны программам чтения с экрана и логической навигации, но сам факт их наличия не гарантирует правильный порядок чтения, альтернативные описания изображений или соответствие PDF/UA. Признак подходит для первичной сортировки, после которой доступность оценивается специализированным валидатором и ручной проверкой.

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

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

Метаданные и поля сводки

Сводка может включать автора, даты создания и изменения, средство создания, производителя PDF, тему, заголовок, ключевые слова и признак trapping. Эти значения помогают выяснить происхождение технической проблемы: документы одного генератора могут иметь одинаковые нарушения шрифтов или структуры. Однако поля задаются авторским ПО и могут быть пустыми, неточными или намеренно изменёнными.

В аналитике разделяйте метаданные документа и технические значения отчёта. Число страниц, размер в байтах и версия PDF получены при анализе файла; поле Author является пользовательским значением. Для маршрутизации используйте метаданные осторожно и не считайте их подтверждённой идентификацией автора.

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

Альтернативные изображения и глубина цвета

Альтернативные изображения позволяют хранить несколько версий одного визуального объекта, например экранную и печатную. Сегодня эта конструкция встречается редко, но способна заметно увеличить размер файла и усложнить предсказуемый рендеринг. alternate-images сообщает о наличии таких вариантов; удалять их следует только после проверки, какая версия используется при выводе.

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

Не путайте глубину канала с DPI. Первое описывает количество уровней цвета на пиксель, второе — пространственную детализацию при размещении на странице. Уменьшение одного параметра решает другую задачу и может по-разному влиять на качество. PDF Checker разделяет признаки, чтобы профиль не сводил оптимизацию изображений к одному общему условию.

Аннотации с флагами просмотра и печати

Аннотация может быть видна на экране и исключена из печати либо, наоборот, скрыта при просмотре. Условия contains-annots-not-for-printing и contains-annots-not-for-viewing обнаруживают эти флаги. В согласованном процессе они полезны, но при передаче в другой просмотрщик создают расхождение между тем, что видел оператор, и тем, что попало на бумагу.

Перед печатью юридического или производственного документа такой признак лучше поднимать до ошибки ручной проверки. Оператор должен решить, является ли скрытие намеренным. Простое удаление аннотации может потерять комментарий; принудительная печать — раскрыть служебную информацию. PDF Checker сообщает состояние, не выбирая за пользователя.

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

Проверка PDF 2.0 и совместимости потребителя

pdf-v2 отмечает документы версии PDF 2.0. Это не ошибка формата, но полезный сигнал для старой системы, встроенного устройства или библиотеки с ограниченной поддержкой. Если потребитель принимает только более ранние версии, маршрут должен выполнить совместимое преобразование или отклонить файл с понятным сообщением.

Не понижайте версию простой заменой заголовка PDF. Документ может использовать возможности, которых нет в предыдущем стандарте. Корректное преобразование выполняет средство, способное переписать несовместимые объекты, после чего PDF Checker повторно проверяет основные признаки. В отчёте сохраняйте исходную и полученную версию, чтобы подтвердить изменение.

Для современной системы наличие PDF 2.0 обычно остаётся информацией. Оно становится ошибкой только при явно заданном ограничении среды. Такое разграничение показывает, почему уровень report-as-error принадлежит профилю, а не жёстко зашит в программу.

Сравнение Datalogics PDF Checker с аналогами

Инструменты ниже пересекаются по диагностике PDF, но решают задачи на разной глубине. Выбор зависит от того, нужен ли программно разбираемый отчёт общего состояния, строгая проверка конкретного стандарта, интерактивное исправление либо низкоуровневая работа со структурой.

Программа	Лучше подходит для	Главное ограничение
Datalogics PDF Checker	Автоматической проверки структуры, шрифтов, изображений, пользовательских данных и маршрутизации по JSON	Диагностирует, но не сохраняет исправленный PDF
PDF Commander	Ручного просмотра, редактирования текста, объединения, конвертации, OCR и исправления отдельных документов	Нет специализированного серверного отчёта о внутренней структуре
veraPDF	Формальной валидации PDF/A и PDF/UA в графическом или командном режиме	Основной фокус ограничен правилами стандартов и политик
Adobe Acrobat Pro Preflight	Интерактивной допечатной проверки, инвентаризации и применения готовых исправлений	Рабочий процесс ориентирован на Acrobat и действия оператора
callas pdfToolbox CLI/Server	Профессионального автоматического префлайта, исправления, цветовых преобразований и конвертации	Сложная коммерческая конфигурация профилей и лицензирования
QPDF	Низкоуровневой проверки синтаксиса, восстановления и структурных преобразований PDF	Не является полным содержательным префлайт-валидатором

Datalogics PDF Checker выбирают, когда нужно быстро классифицировать большой поток по общим техническим признакам и получить предсказуемый JSON без изменения исходного файла. PDF Commander удобнее оператору, который должен увидеть страницу и вручную отредактировать конкретный файл. veraPDF следует применять для доказательной проверки PDF/A или PDF/UA. Acrobat Pro Preflight подходит допечатному специалисту с визуальным контролем и исправлениями. pdfToolbox оправдан в сложном производственном конвейере, где проверка должна сразу переходить в коррекцию. QPDF полезен разработчику для синтаксической диагностики и низкоуровневого переписывания структуры.

Контрольный рабочий процесс от входа до повторной проверки

1. Создайте копию everything.json и оставьте только проверки, связанные с назначением документов.
2. Для каждого условия определите, является ли оно ошибкой, информацией или причиной немедленной остановки.
3. Запустите команду на небольшой репрезентативной выборке: корректных, повреждённых, защищённых и насыщенных изображениями PDF.
4. Сохраните одновременно текстовый и JSON-отчёт, чтобы сравнить удобство оператора и машинного разбора.
5. Проверьте, что автоматизация различает сработавшее условие, успешно завершённый тест без находки и прерванную проверку.
6. Настройте отдельные очереди для исправления, OCR, ручного решения и окончательного приёма.
7. После изменения документа повторите тот же профиль и сопоставьте ошибки, информацию, размер, число страниц и причину остановки.
8. Зафиксируйте версию профиля и правила маршрутизации, чтобы результаты можно было воспроизвести.

Главная ценность процесса заключается не в максимальном числе включённых проверок, а в однозначной связи между результатом и последующим действием. Если найденный JavaScript всегда ведёт в очередь безопасности, не встроенный шрифт — к допечатному исправлению, а image-only — к OCR, отчёт становится частью управляемого конвейера. Условия без владельца решения создают только шум.

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

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

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

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

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