3-Heights PDF Validator проверяет документы по требованиям PDF 1.x, PDF 2.0 и PDF/A-1, PDF/A-2 или PDF/A-3, определяет заявленный уровень соответствия, разбирает нарушения по степени важности и возвращает подробности вплоть до номера страницы, объекта и количества повторений. Через API можно принимать файл, блок памяти или поток, задавать глубину отчёта, останавливать анализ на первой ошибке и применять собственные правила к шрифтам, изображениям, вложениям, страницам и цифровым подписям.

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

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

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

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

Приложение выбирает режим до открытия документа. Если передать конкретное значение, например PDF/A-2b, проверка выполняется именно против этого профиля. Если использовать режим определения заявленного соответствия, валидатор читает метаданные файла, извлекает заявленный профиль и применяет его при последующем вызове Validate. После открытия фактическое значение можно получить через свойство Compliance; читать его следует до закрытия документа, потому что после Close оно уже не относится к активному файлу.

Ключевое практическое отличие от проверки расширения заключается в том, что анализируется содержимое. Наличие суффикса .pdf, заголовка PDF и метаданных PDF/A не гарантирует корректности. Проверка проходит по объектам и зависимостям, фиксирует нарушения в шрифтах, профилях ICC, потоках изображений, структуре тегов, аннотациях и других элементах. Это позволяет использовать результат как формальное условие в маршруте обработки: прошедший документ отправить в хранилище, документ с исправимыми нарушениями — в конвертер, повреждённый или защищённый неизвестным паролем — в отдельную очередь.

Открытие файла, памяти и потока

Для входных данных предусмотрены три варианта: Open получает имя файла, OpenMem принимает блок памяти, а OpenStream работает с потоком. Выбор зависит от архитектуры системы. Файловый вызов удобен в пакетной обработке папок и при интеграции с сетевыми каталогами. Блок памяти уменьшает число промежуточных операций, когда PDF уже загружен из базы данных или сообщения. Поток подходит для сервисов, где документ поступает через собственный слой хранения и не должен сначала записываться в рабочий каталог.

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

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

Выбор PDF и PDF/A-профиля

Поддерживаются обычные документы PDF 1.3–1.7, PDF 2.0, а также профили PDF/A-1a, PDF/A-1b, PDF/A-2a, PDF/A-2b, PDF/A-2u, PDF/A-3a, PDF/A-3b и PDF/A-3u. Буква определяет не качество файла, а набор обязательств. Уровень B сосредоточен на надёжном визуальном воспроизведении. Уровень U добавляет требования к однозначному соответствию символов Unicode, что важно для поиска и извлечения текста. Уровень A включает структурные требования, необходимые для логического порядка содержимого и более полной интерпретации документа.

PDF/A-1 основан на более ранней модели PDF и запрещает ряд возможностей, которые допустимы в следующих частях стандарта. PDF/A-2 опирается на PDF 1.7 и допускает, в частности, возможности, для которых PDF/A-1 слишком ограничителен; поэтому документы со слоями или прозрачностью часто следует проверять и формировать как PDF/A-2, а не пытаться объявить их PDF/A-1 без преобразования. PDF/A-3 дополняет PDF/A-2 возможностью связывать с документом вложенные файлы произвольного формата, но сам факт допуска вложений не делает вложенный объект архивным или безопасным.

Перед массовой проверкой целевой профиль необходимо закрепить в правилах приёма. Если система принимает и PDF/A-1b, и PDF/A-2b, стоит проверять каждый разрешённый профиль последовательно либо использовать заявленный уровень только как начальную подсказку, а затем сопоставлять результат с политикой архива. Нельзя автоматически повышать документ до подходящего статуса лишь потому, что он прошёл более мягкий вариант: например, соответствие уровню B не доказывает наличие логической структуры, требуемой уровнем A.

Профиль	Что проверяется в первую очередь	Практическое применение
PDF 1.x / PDF 2.0	Корректность структуры и требований соответствующей спецификации	Входной контроль обычных PDF
PDF/A-1b	Визуальная воспроизводимость в рамках первой части PDF/A	Архивы с консервативными правилами
PDF/A-2b	Визуальная воспроизводимость с возможностями PDF 1.7	Современное долговременное хранение
PDF/A-2u	Дополнительно корректное отображение символов Unicode	Поиск и извлечение текста
PDF/A-3a	Структура уровня A и разрешённые связанные вложения	Контейнеры с исходными данными и документом

Уровни отчётности и состав результата

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

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

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

validator.ReportingLevel = 2;
if (!validator.Open(fileName, password, compliance))
    return HandleOpenError(validator.ErrorCode, validator.ErrorMessage);

bool conforms = validator.Validate();
for (PdfError item = validator.GetFirstError(); item != null; item = validator.GetNextError())
{
    Save(item.ErrorCode, item.Message, item.PageNumber,
         item.ObjectNumber, item.Count);
}
validator.Close();

Остановка на первой ошибке

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

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

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

Последовательность вызовов API

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

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

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

Подключение к проекту .NET

В .NET используются пространства имён Pdftools.Pdf и Pdftools.PdfValidate. Пакет содержит управляемые сборки для поддерживаемых вариантов .NET и нативные библиотеки для целевых систем. Проект должен получить не только ссылку на управляемую DLL: при выполнении рядом должна оказаться нативная PdfValidatorAPI с разрядностью, совпадающей с процессом. Установка через NuGet автоматически решает большую часть раскладки файлов, но итоговый каталог публикации всё равно нужно проверить на тестовой машине.

При ручном развёртывании копируют сборки проекта, управляемую обёртку и подходящую нативную библиотеку. Для AnyCPU выбор зависит от того, каким процессом фактически запускается приложение. Для x86 требуется 32-разрядная библиотека, для x64 — 64-разрядная. Если в одном пакете поставки находятся обе, их обычно раскладывают по отдельным подкаталогам и загружают вариант, соответствующий архитектуре процесса. Простое переименование DLL не меняет её разрядность.

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

Пример каркаса на C#

using Pdftools.Pdf;
using Pdftools.PdfValidate;

public ValidationResult Check(string fileName, PDFCompliance target)
{
    using var validator = new PdfValidator();
    validator.ReportingLevel = 3;

    if (!validator.Open(fileName, string.Empty, target))
        return ValidationResult.TechnicalFailure(
            validator.ErrorCode, validator.ErrorMessage);

    validator.StopOnError = false;
    bool conforms = validator.Validate();
    var messages = ReadMessages(validator);
    validator.Close();
    return new ValidationResult(conforms, messages);
}

Каркас намеренно разделяет технический отказ и несоответствие. Метод Open сообщает, удалось ли подготовить документ к анализу, а Validate отвечает за результат проверки. В производственном коде список сообщений лучше преобразовать в собственную модель, не передавая наружу нативный объект PdfError после закрытия валидатора. Поля кода, страницы, объекта и количества достаточно скопировать в неизменяемую запись, которую можно сериализовать, положить в очередь или показать оператору.

Интеграция через Java

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

Рабочая последовательность в Java повторяет другие интерфейсы: создать PdfValidatorAPI, установить reporting level, открыть файл с константой COMPLIANCE, выполнить проверку и прочитать PdfError. Ошибки и предупреждения следует преобразовывать в объекты приложения до освобождения нативного ресурса. Для пакетной обработки удобно использовать ограниченный пул рабочих задач: это даёт параллелизм, но не создаёт неуправляемое количество нативных экземпляров и временных файлов.

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

PdfValidatorAPI doc = new PdfValidatorAPI();
doc.setReportingLevel(2);
if (!doc.open(fileName, password, NativeLibrary.COMPLIANCE.ePDFA2b)) {
    throw new ValidationStartupException(doc.getErrorCode(), doc.getErrorMessage());
}
boolean conforms = doc.validate();
for (PdfError e = doc.getFirstError(); e != null; e = doc.getNextError()) {
    collect(e);
}
doc.close();

Интеграция через C и COM

Интерфейс C требует явной инициализации библиотеки, создания объекта, вызова функций открытия и проверки, а затем освобождения объекта и общей деинициализации. Это даёт полный контроль над временем жизни, но цена ошибки выше: пропущенное освобождение приводит к утечкам, а преждевременная деинициализация делает оставшиеся объекты недействительными. Лучше завернуть последовательность в собственную функцию с единой секцией очистки, куда управление попадает при любом коде возврата.

COM-интерфейс полезен для приложений, которые уже работают с компонентной моделью Windows. Перед использованием компонент регистрируется, после чего тип доступен в списке ссылок среды разработки. В старых проектах Visual Basic объект создаётся через зарегистрированную библиотеку типов, затем вызываются те же операции Open, Validate и перебор ошибок. При переносе на новую машину нужно учитывать регистрацию COM и разрядность процесса: 32-разрядный клиент не увидит только 64-разрядную регистрацию и наоборот.

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

Пользовательские профили проверки

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

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

Правила сгруппированы по разделам File, Document, Pages, Graphics, Fonts, Interactive Features и Digital Signatures. Такая структура помогает отделить транспортные ограничения от содержания. Например, размер файла и минимальная версия PDF относятся к File, разрешённые типы вложений — к Document, форматы страниц — к Pages, разрешение сканов — к Graphics, требования встраивания — к Fonts, допустимые аннотации и действия — к Interactive Features.

Раздел File: размер, версия, шифрование и линейность

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

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

Encryption позволяет запретить или потребовать шифрование в зависимости от политики. Для долговременного архива часто нужен незашифрованный PDF/A, чтобы доступ не зависел от пароля или алгоритма, а для промежуточного обмена организация может требовать защиту. Linearization проверяет наличие структуры быстрого веб-просмотра. Линейность влияет на способ загрузки по частям, но не является доказательством PDF/A; поэтому эти правила должны существовать рядом, не подменяя друг друга.

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

Раздел Document: создатель, производитель и вложения

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

EmbeddedFiles и пронумерованные EmbeddedFile задают разрешённые типы вложений. Для PDF/A-3 это особенно важно: стандарт допускает связанный файл, но корпоративная политика может принимать только XML-счёт, исходный текст или определённый формат данных. Проверка расширения вложения недостаточна для антивирусной защиты, поэтому валидатор дополняют сканированием содержимого и правилами MIME. ProhibitEmbeddedFiles полностью запрещает вложенные файлы, когда архив хранит только самодостаточные страницы.

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

Раздел Pages: допустимые размеры и пустые страницы

PageSizes и PageSize задают перечень разрешённых размеров. SizeTolerance определяет допустимое отклонение при сравнении, потому что документы могут хранить размеры в пунктах с небольшими погрешностями. Для деловых документов обычно разрешают A4 и, при необходимости, A3 или Letter. Если не задать разумный допуск, скан с дробным размером будет отклонён, хотя визуально соответствует формату. Если допуск слишком велик, правило перестаёт различать близкие, но нежелательные размеры.

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

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

Раздел Graphics: DPI, цвет, прозрачность и слои

ImageMinDPI и ImageMaxDPI задают пределы разрешения для изображений. Нижняя граница помогает не принимать нечитаемые сканы, верхняя — выявлять избыточные ресурсы, увеличивающие размер и нагрузку без полезного выигрыша. Фактический DPI зависит от размера изображения на странице, а не только от числа пикселей, поэтому правило анализирует контекст размещения. Один и тот же растр может иметь приемлемое разрешение на небольшой области и недостаточное после растягивания на всю страницу.

ScanMinDPI и ScanMaxDPI применяются к изображениям, распознанным как сканированное содержимое. ScanColor позволяет установить допустимый цветовой режим, а OCRText — требование к наличию текстового слоя. Такой набор полезен для оцифровки: можно потребовать, например, не слишком низкое разрешение и наличие распознанного текста. Однако валидатор не оценивает смысловую точность OCR; бессмысленный текстовый слой формально присутствует, поэтому качество распознавания проверяют отдельными методами и выборочным контролем.

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

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

Раздел Fonts: допустимые гарнитуры и встраивание

Fonts и Font задают белый список разрешённых гарнитур, NonFonts — чёрный список. Имена могут содержать шаблоны, поэтому правило подходит для семейства шрифтов, но требует осторожности с похожими названиями и подмножествами. Белый список полезен для фирменного документооборота, однако он не заменяет проверку встраивания. Разрешённая гарнитура, отсутствующая в файле, всё равно создаёт зависимость от внешней системы и может нарушить PDF/A.

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

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

Интерактивные функции: аннотации и действия

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

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

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

Проверка цифровых подписей

Для проверки подписи требуется криптографический провайдер. Поддерживается конфигурация через PKCS#11 и механизмы Windows, включая CryptoAPI и CNG. Разрядность библиотеки PKCS#11 должна совпадать с разрядностью процесса и нативного валидатора. Если проверка подписи включена, но провайдер настроен неверно, анализ не начинается; это техническая ошибка конфигурации, а не доказательство недействительности подписи документа.

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

В конфигурации Windows пустое значение может использовать доступный провайдер по умолчанию, а явное имя фиксирует конкретную реализацию. Для алгоритмов SHA-2 рекомендуется провайдер, который их поддерживает. В среде с HSM или токеном путь к PKCS#11 задаётся точно и тестируется под учётной записью службы. Нельзя проверять только интерактивный запуск администратора: фоновый процесс может не иметь доступа к устройству, контейнеру ключей или системному хранилищу сертификатов.

Обработка ошибок API

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

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

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

Типичные ошибки загрузки .NET

System.TypeInitializationException при первом создании объекта часто является оболочкой для двух разных причин. DllNotFoundException означает, что нативная PdfValidatorAPI не найдена по пути загрузки или отсутствует одна из её зависимостей. BadImageFormatException обычно указывает на несовпадение разрядности: 32-разрядный процесс пытается загрузить 64-разрядную DLL либо наоборот. Лечить обе ситуации копированием случайной библиотеки из другой машины опасно — нужно восстановить корректную структуру поставки.

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

При BadImageFormatException сверяют платформу проекта и фактическую архитектуру процесса. AnyCPU не означает универсальную нативную DLL: на 64-разрядной системе процесс обычно 64-разрядный, если не включено предпочтение 32-bit. Для служб IIS архитектура зависит от пула приложений. После исправления требуется перезапустить процесс, потому что уже загруженная нативная библиотека остаётся в адресном пространстве. Автотест должен выводить разрядность и путь реально загруженного файла.

Лицензия и запуск проверки

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

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

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

Временные файлы и память

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

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

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

Пакетная проверка и высокая нагрузка

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

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

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

Сценарий архивного шлюза

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

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

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

Контроль документов из сканирующей системы

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

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

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

Проверка документов перед электронной подписью

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

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

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

Как читать сообщения о нарушениях

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

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

При передаче отчёта пользователю технические детали переводят в понятную инструкцию, но не удаляют исходный код. Например, шрифт не встроен дополняют рекомендацией экспортировать документ с включённым встраиванием; использовано устройство-зависимое цветовое пространство — повторно создать PDF/A с корректным выходным профилем. Разработчику источника отправляют полный код, объект и пример файла, потому что краткого объяснения для исправления генератора недостаточно.

Сравнение 3-Heights PDF Validator с аналогами

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

Программа	Лучше подходит для	Главное ограничение
3-Heights PDF Validator	Встраивания проверки PDF и PDF/A в серверные процессы, приложения и архивные шлюзы	Не исправляет документ и требует разработки интерфейса
veraPDF	Открытой проверки PDF/A через GUI, CLI или программные интерфейсы	Сосредоточен на валидации и не заменяет редактор или конвертер
Adobe Acrobat Pro Preflight	Ручной диагностики и исправления отдельных файлов специалистом	Плохо подходит как лёгкий безоператорный компонент для большого потока
callas pdfaPilot	Профессиональной проверки, коррекции и преобразования PDF/A в настольных и серверных сценариях	Широкая функциональность требует более сложной настройки
Apache PDFBox Preflight	Java-проектов, которым нужна базовая программная проверка PDF/A	Поддерживает более узкий набор профилей и сценариев

Для автоматического приёма большого числа документов выбирают 3-Heights PDF Validator, когда нужны детальные структурированные ошибки и корпоративный INI-профиль. veraPDF подходит, если приоритетом является открытая реализация и прозрачные правила PDF/A. Adobe Acrobat Pro удобен специалисту, который вручную находит и исправляет проблему. callas pdfaPilot выбирают, когда в одном процессе требуются проверка и сложная коррекция. PDFBox Preflight разумен для Java-систем с ограниченным профилем и готовностью дорабатывать обработку результатов.

Практические ограничения

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

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

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

Настройка собственного интерфейса для оператора

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

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

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

Проверка в CI/CD для генератора PDF

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

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

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

Диагностика расхождений между валидаторами

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

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

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

Чек-лист перед вводом в эксплуатацию

1. Зафиксировать разрешённые профили PDF и PDF/A и определить, допускаются ли предупреждения.
2. Подготовить положительный и отрицательный тестовый корпус для каждого корпоративного правила.
3. Проверить открытие файла, памяти и потока, включая неверный пароль и повреждённый PDF.
4. Настроить отчётность, сохранение кода, страницы, объекта, количества и текста сообщения.
5. Разделить несоответствие документа и техническую ошибку инфраструктуры.
6. Проверить лицензию, разрядность нативной библиотеки и публикацию на чистой машине.
7. Настроить временный каталог либо оценить память при NoTempFiles.
8. Ограничить параллелизм по CPU, памяти и скорости хранилища.
9. Версионировать INI-профиль и сохранять его идентификатор вместе с результатом.
10. После любого преобразования выполнять повторную проверку окончательного файла.

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

Частые вопросы о 3-Heights PDF Validator

Можно ли проверить один PDF без разработки большого приложения?

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

Определяет ли программа профиль PDF/A автоматически?

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

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

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

Почему PDF открывается, но не проходит проверку?

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

Что выбрать: полный отчёт или остановку на первой ошибке?

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

Как обрабатывать зашифрованные документы?

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

Нужен ли интернет для проверки?

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

Как понять, что ошибка относится к странице?

PdfError возвращает PageNumber. Значение больше нуля указывает страницу, которую можно открыть в просмотрщике. Ноль означает, что нарушение не привязано к одной странице или номер недоступен. ObjectNumber помогает локализовать структуру. В операторском интерфейсе нулевую страницу показывают как документ целиком, а не как первую страницу, чтобы не вводить пользователя в заблуждение.

Можно ли запретить конкретные шрифты и вложения?

Да. В INI-профиле раздел Fonts содержит списки разрешённых и запрещённых гарнитур, а Document — правила для встроенных файлов и полный запрет вложений. Списки тестируют на реальных именах и вариантах подмножеств. Для вложений дополнительно нужен анализ содержимого: разрешённое расширение не доказывает безопасность файла. Результат профиля сохраняют вместе с версией политики.

Как убедиться, что развёртывание корректно?

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

Проверка воспроизводимости результата

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

Итоговый рабочий подход

3-Heights PDF Validator приносит наибольшую пользу там, где проверка является формальным этапом процесса, а не разовой визуальной операцией. Его подключают к источнику файлов, задают точный профиль, сохраняют структурированные сообщения и отделяют нарушения документа от ошибок инфраструктуры. Пользовательские правила превращают общие требования ISO в конкретную политику организации: допустимые размеры страниц, шрифты, вложения, DPI, интерактивность и подписи.

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

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