Что PDF знает о себе: метаданные и пакет XMP

Spec: ISO 16684-1:2019Spec: ISO 32000-2

Кратко

Откройте современный PDF — и он может рассказать о себе дважды. Есть небольшой старый список ключ/значение под названием словарь Document Information, и может быть блок XML — пакет XMP, — который говорит во многом то же самое в более богатой, структурированной форме. Эта страница — об этих двух параллельных системах, о том, почему обе уцелели и почему конвейеры архивации и поиска настаивают на их согласии.

Краткий ответ на заголовок: PDF знает свой заголовок, автора, тему, ключевые слова, инструмент, который его создал, и когда. Он хранит это знание в двух местах одновременно, и интересная инженерия — в том, чтобы держать их честными.

Почему это важно

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

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

Если коротко

PDF может нести метаданные в двух параллельных системах: устаревшем словаре Document Information и современном пакете XMP из RDF/XML.
Пакет XMP обёрнут в инструкцию обработки xpacket — заголовок begin и трейлер end, — так что инструмент может найти его и даже переписать на месте, не разбирая весь файл заново.
Свойства живут в пространствах имён: dc (Dublin Core) для заголовка и создателя, xmp для дат создания и изменения, pdf для производителя, xmpMM для идентичности и истории документа.
PDF/A требует метаданных XMP, и записи DocInfo, у которых есть эквиваленты в XMP, должны им соответствовать — расхождение является сбоем валидации.
NextPDF трактует обе как одну задачу: он записывает обе, читает XMP обратно и охраняет размер пакета, давая сбой закрыто, а не выдавая некорректный файл.

Как NextPDF подходит к этому

Честная формулировка в том, что это проблема синхронизации, наряженная в проблему форматирования. Словарь Document Information (Spec: ISO 32000-2, §14.3.3), на который ссылается трейлер через запись /Info, — это плоский список строк: Title, Author, Subject, Keywords, Creator, Producer и пара дат. Он прост, он предшествует XML, и он всё ещё едет почти в каждом файле, потому что слишком многие инструменты по-прежнему читают его первым.

Пакет XMP (Spec: ISO 16684-1:2019, §7) — это современная половина. Это документ XML — точнее, RDF/XML, — который моделирует файл как набор именованных свойств, сгруппированных в схемы, каждая из которых привязана к пространству имён (Spec: ISO 16684-1:2019, §6). Именно эту структуру плоский словарь не может: значение может быть упорядоченным списком, размеченной по языку альтернативой («заголовок на английском, заголовок на французском») или структурированной записью. В PDF этот XML живёт в потоке метаданных, прикреплённом к каталогу документа (Spec: ISO 32000-2, §14.3.2), — это каноническое место, куда смотрит современная программа чтения.

Стоит разобрать три детали, потому что именно в них инструменты ошибаются с пакетом.

Обёртка. Пакет XMP заключён в инструкцию обработки так, что в форматах, где пакет хранится как напрямую обыскиваемые байты, программа может найти метаданные без полного разбора; в PDF, в частности, каноническим локатором является поток метаданных каталога. Заголовок begin несёт метку порядка байтов, объявляющую кодировку текста; трейлер end несёт флаг, указывающий, доступен ли пакет только для чтения или может редактироваться на месте. Когда он доступен для записи, сериализатор оставляет после XML серию пробельного заполнения, чтобы редактор мог слегка нарастить содержимое, не сдвигая каждый следующий байт. Это заполнение — не украшение, оно и делает возможным редактирование метаданных на месте.

Пространства имён. Свойство осмысленно только относительно своего пространства имён, и горстка из них почти универсальна. Dublin Core (dc) держит заголовок и создателя. Базовая схема XMP (xmp) держит даты создания и изменения и инструмент авторства. Схема PDF (pdf) держит строку производителя и ключевые слова. Схема управления медиа (xmpMM) держит идентичность документа и историю его происхождения — след, который говорит «этот файл произошёл из того». Согласие по этим URI пространств имён и именам свойств — обычно показываемым с условными префиксами — это и есть весь смысл основных схем (Spec: ISO 16684-1:2019, Annex B); два инструмента, которые оба говорят на свойстве заголовка Dublin Core, взаимодействуют без предварительной договорённости.

Правило согласованности. Поскольку обе системы могут именовать одно и то же свойство, они могут расходиться. Архивные профили отказываются это допускать. Файл PDF/A обязан нести поток метаданных XMP, и любая запись Document Information, у которой есть эквивалент в XMP, должна ему соответствовать; расхождение является сбоем валидации. Практический вывод прям: в архивном конвейере эти две — не независимые поля, а один факт, записанный дважды, и они обязаны идти в ногу.

NextPDF обрабатывает все три как одну заботу. Поток метаданных — это один путь, а не два конкурирующих.

Collect the values onceTitle, author, subject, keywords, creator, producer and dates are set on the document a single time, so there is one source of truth, not two.
Write the Info dictionaryThe DocInfo writer emits the legacy Title, Author, Subject, Keywords, Creator, Producer and date entries that older tools read first.
Build the XMP packetThe XMP builder serializes the same values as RDF/XML under dc, xmp, pdf and xmpMM, wrapped in the xpacket header and trailer with writable padding.
Guard the packet sizeBefore serialization is accepted, the engine checks the packet against a size bound and fails closed with a typed exception rather than emit a malformed or oversized stream.
Read XMP back to verifyThe XMP reader parses the packet so a pipeline can confirm the engine wrote the metadata it was given — the kind of check an archival validator builds on.

Как NextPDF держит две системы метаданных документа согласованными: один набор значений записывается и в словарь Info, и в пакет XMP, размер пакета охраняется перед сериализацией, и тот же пакет можно прочитать обратно, чтобы конвейер подтвердил, что метаданные сериализовались как задумано.

Практический пример

Приведённая ниже форма задаёт метаданные один раз и позволяет движку разнести их по обеим системам, затем читает заголовок XMP обратно, чтобы конвейер мог его проверить. Защита размера — это та строка, что превращает «вероятно, нормально» в «доказуемо отклонено, если нет».

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Metadata\Exception\XmpPacketTooLargeException;

$document = Document::createStandalone();

// Set the values ONCE. The engine writes them to both the Info dictionary
// and the XMP packet, so the two systems cannot drift apart at the source.
$document->setTitle('Annual Report 2026');
$document->setAuthor('Records Office');
$document->setSubject('Statutory annual filing');
$document->setKeywords('annual report, statutory, 2026');

try {
    // Building the document serializes the XMP packet. The engine guards the
    // packet size and fails closed: a packet that exceeds the bound is a
    // typed exception, never a silently truncated or malformed stream.
    $bytes = $document->getPdfData();
} catch (XmpPacketTooLargeException $e) {
    // Decide deliberately: trim the metadata, not the guarantees.
    error_log('XMP packet exceeded the size bound: ' . $e->getMessage());
    throw $e;
}

// Read the packet back. This confirms the XMP the engine serialized carries the
// value you set — the kind of integrity check an archival pipeline runs before
// it trusts the file. (Both systems are written from one source, so they agree
// by construction; reading the XMP back proves it serialized as intended.)
$xmp = $document->readXmpMetadata($bytes);
$xmpTitle = $xmp->get('dc', 'title'); // 'Annual Report 2026'

if ($xmpTitle !== $document->getTitle()) {
    throw new \RuntimeException('XMP title does not match the value that was set.');
}

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

Распространённое заблуждение

Частое убеждение в том, что словарь Info устарел и его можно игнорировать. Нельзя — пока нет. Огромное количество установленного ПО, включая некоторые предпросмотры файлов в операционных системах и старые инструменты архивации, по-прежнему читает словарь Info первым или только его. Отбрасывание его не модернизирует файл; оно делает файл озаглавленным как «без названия» для всего, что ещё не приняло XMP.

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

Пределы и границы

NextPDF записывает обе системы и читает XMP обратно. Его область — это построитель метаданных XMP, писатель DocInfo и читатель XMP. Он не обещает быть движком запросов RDF/XML общего назначения.
Пакет XMP охраняется по размеру и даёт сбой закрыто. Пакет, превышающий предел движка, вызывает типизированное исключение. Движок не станет выдавать усечённый, дополненный сверх предела или иначе некорректный пакет, чтобы «уместить» чрезмерный запрос.
Согласованность обеспечивается во время записи из одного источника; это не волшебное примирение файла, который вы не производили. Если вы импортируете документ, чьи две системы уже расходятся, разрешение этого — ваше решение, а не неявная перезапись.
Требования PDF/A к метаданным — часть архивного профиля. Эта страница объясняет правило; вердикт о соответствии принадлежит валидатору, как всегда в архивной работе. См. страницу об архивации об этой границе.

Построитель метаданных, писатель DocInfo и читатель XMP — это возможности ядра (Core). Честная оговорка относится к защите размера, ниже.

Защита размера — это решение об эксплуатационности, а не ограничение, за которое нужно извиняться. Пакет XMP находится в потоке метаданных, а пакет, который растёт без предела, — это поверхность отказа в обслуживании и риск повреждения для любого редактора на месте, который полагался на доступное для записи заполнение. Поэтому движок задаёт предел и, когда запрос его превысил бы, вызывает типизированное исключение (Spec: ISO 16684-1:2019, §7) вместо записи некорректного потока. Сбой громкий, именованный и во время записи — там, где вы можете осознанно урезать метаданные, — а не тихий и обнаруженный позже валидатором, который просто отклоняет файл.

Metadata: Info dictionary and XMP packet — edition availability
Edition	Availability
Core	Построитель метаданных XMP, писатель словаря Document Information и читатель XMP поставляются в Core, с защитой размера, которая даёт сбой закрыто на чрезмерном пакете, — включая вывод соответствия PDF/A и валидацию, которые делают поток метаданных XMP обязательным и требуют, чтобы DocInfo ему соответствовал.
Pro	Добавляет пакетные и шаблонные рабочие процессы метаданных поверх того же писателя и читателя Core.
Enterprise	Добавляет более широкую политику соответствия и поверхность отчётности по всему массиву документов.

Связанная документация

Архивация и PDF/A — где пакет XMP перестаёт быть необязательным, а правило согласованности DocInfo-к-XMP становится требованием «прошёл или не прошёл».
Соответствие, которое можно передать аудитору — почему метаданные, которые проходят туда-обратно и согласуются с собой, являются частью пригодного для аудита артефакта.
Анатомия файла PDF — где в структуре файла находятся трейлер, каталог и поток метаданных.
Потоки и фильтры — поток метаданных — это поток; вот как потоки PDF кодируются и держатся детерминированными.

Глоссарий

Словарь Document Information — устаревшие плоские метаданные ключ/значение, на которые ссылается трейлер через запись /Info: Title, Author, Subject, Keywords, Creator, Producer и даты. Предшествует XMP; до сих пор широко читается.
XMP — Extensible Metadata Platform, формат XML (RDF/XML) для описания ресурса именованными свойствами, сгруппированными в схемы. Стандартизирован как ISO 16684-1.
xpacket — инструкция обработки, которая обёртывает пакет XMP, с заголовком begin (маркер кодировки) и трейлером end (флаг «только для чтения» или «для записи»), так что инструмент может найти и отредактировать пакет без полного разбора.
Пространство имён / схема — именованный словарь свойств, привязанный к URI. Распространённые префиксы: dc (Dublin Core), xmp (базовый XMP), pdf (специфичный для PDF), xmpMM (управление медиа / идентичность документа).
Поток метаданных — объект PDF, прикреплённый к каталогу документа, который несёт пакет XMP. Каноническое расположение, которое современная программа чтения проверяет первым.
PDF/A — семейство архивных профилей PDF (ISO 19005). Оно требует поток метаданных XMP и требует, чтобы любая запись Document Information с эквивалентом в XMP ему соответствовала, иначе валидация проваливается.