Was ein PDF über sich selbst weiß: Metadaten und das XMP-Paket

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

Auf einen Blick

Öffnen Sie ein modernes PDF, und es erzählt Ihnen womöglich zweimal von sich selbst. Es gibt eine kleine, alte Schlüssel/Wert-Liste namens Document-Information-Dictionary, und es kann einen Block XML geben – das XMP-Paket –, der in einer reichhaltigeren, strukturierten Form weitgehend dasselbe aussagt. Auf dieser Seite geht es um diese beiden parallelen Systeme, warum beide fortbestehen und warum Archivierungs- und Suchpipelines darauf bestehen, dass sie übereinstimmen.

Die Kurzantwort auf den Titel: Ein PDF kennt seinen Titel, seinen Autor, sein Thema, seine Schlüsselwörter, das Werkzeug, das es erstellt hat, und wann. Es speichert dieses Wissen an zwei Stellen zugleich, und die interessante Ingenieursarbeit besteht darin, sie ehrlich zu halten.

Warum das wichtig ist

Metadaten sind der Teil eines Dokuments, den ein Mensch selten sieht und eine Maschine fast immer liest. Die Dateivorschau Ihres Betriebssystems, ein Digital-Asset-Manager, ein Bibliothekskatalog, ein Suchindex, ein E-Discovery-Werkzeug – viele von ihnen lesen die Metadaten vor oder neben dem Dokumenttext und vertrauen darauf, was sie sagen.

Wenn die beiden Systeme also uneins sind – das Info-Dictionary nennt einen Autor und das XMP-Paket einen anderen –, wählt etwas weiter unten in der Kette eines aus, und Sie haben nicht die Wahl, welches. Ein Suchindex zeigt womöglich den falschen Titel an. Ein Archivvalidator lehnt die Datei möglicherweise rundweg ab. Die Abweichung ist unsichtbar, bis eine Pipeline darüber stolpert, was der schlechteste Zeitpunkt ist, sie zu entdecken.

Die Kurzfassung

Ein PDF kann Metadaten in zwei parallelen Systemen tragen: dem alten Document-Information-Dictionary und dem modernen XMP-Paket aus RDF/XML.
Das XMP-Paket ist in eine xpacket-Verarbeitungsanweisung eingehüllt – einen begin-Header und einen end-Trailer –, sodass ein Werkzeug es finden und sogar an Ort und Stelle umschreiben kann, ohne die gesamte Datei erneut zu parsen.
Eigenschaften leben in Namespaces: dc (Dublin Core) für Titel und Ersteller, xmp für Erstellungs- und Änderungsdaten, pdf für den Producer, xmpMM für Dokumentidentität und -historie.
PDF/A verlangt XMP-Metadaten, und DocInfo-Einträge, die XMP-Entsprechungen haben, müssen mit ihnen übereinstimmen – eine Abweichung ist ein Validierungsfehler.
NextPDF behandelt die beiden als eine Aufgabe: Es schreibt beide, liest XMP zurück und schützt die Größe des Pakets, indem es fail-closed verfährt, statt eine fehlerhafte Datei auszugeben.

Wie NextPDF dabei vorgeht

Die ehrliche Einordnung ist, dass dies ein Synchronisationsproblem ist, verkleidet als ein Formatierungsproblem. Das Document-Information-Dictionary (Spec: ISO 32000-2, §14.3.3), vom Trailer über den /Info-Eintrag referenziert, ist eine flache Liste von Strings: Title, Author, Subject, Keywords, Creator, Producer und ein paar Daten. Es ist einfach, es ist älter als XML, und es reist immer noch in fast jeder Datei mit, weil so viele Werkzeuge es immer noch zuerst lesen.

Das XMP-Paket (Spec: ISO 16684-1:2019, §7) ist die moderne Hälfte. Es ist ein XML-Dokument – RDF/XML, um genau zu sein –, das die Datei als eine Menge benannter Eigenschaften modelliert, gruppiert in Schemas, wobei jedes Schema an einen Namespace gebunden ist (Spec: ISO 16684-1:2019, §6). Diese Struktur ist das, was das flache Dictionary nicht kann: Ein Wert kann eine geordnete Liste sein, eine sprachgetaggte Alternative („Titel auf Englisch, Titel auf Französisch”) oder ein strukturierter Datensatz. In einem PDF lebt dieses XML in einem Metadaten-Stream, der an den Dokumentkatalog angehängt ist (Spec: ISO 32000-2, §14.3.2), was die kanonische Stelle ist, an der ein aktueller Reader nachsieht.

Drei Details sind es wert, seziert zu werden, denn hier verstehen Werkzeuge das Paket falsch.

Die Hülle. Ein XMP-Paket wird von einer Verarbeitungsanweisung eingeklammert, sodass in Formaten, in denen das Paket als unmittelbar durchsuchbare Bytes gespeichert ist, ein Programm die Metadaten ohne vollständiges Parsen lokalisieren kann; in PDF speziell ist der Metadaten-Stream des Katalogs der kanonische Lokator. Der begin-Header trägt eine Byte-Order-Mark, die die Textkodierung deklariert; der end-Trailer trägt ein Flag, das angibt, ob das Paket schreibgeschützt ist oder an Ort und Stelle bearbeitet werden darf. Wenn es beschreibbar ist, lässt der Serialisierer einen Lauf Leerraum-Padding nach dem XML, sodass ein Editor den Inhalt leicht vergrößern kann, ohne jedes nachfolgende Byte zu verschieben. Dieses Padding ist keine Dekoration – es ist das, was das An-Ort-und-Stelle-Bearbeiten von Metadaten ermöglicht.

Die Namespaces. Eine Eigenschaft ist nur gegen ihren Namespace bedeutsam, und eine Handvoll sind nahezu universell. Dublin Core (dc) hält den Titel und den Ersteller. Das XMP-Basisschema (xmp) hält die Erstellungs- und Änderungsdaten und das Erstellungswerkzeug. Das PDF-Schema (pdf) hält den Producer-String und die Schlüsselwörter. Das Medienverwaltungs-Schema (xmpMM) hält die Identität des Dokuments und seine Ableitungshistorie – die Spur, die sagt „diese Datei stammt von jener”. Sich auf diese Namespace-URIs und Eigenschaftsnamen zu einigen – üblicherweise mit konventionellen Präfixen gezeigt –, ist der ganze Sinn der Kernschemas (Spec: ISO 16684-1:2019, Annex B); zwei Werkzeuge, die beide die Dublin-Core-Titeleigenschaft sprechen, sind ohne vorherige Absprache interoperabel.

Die Konsistenzregel. Weil beide Systeme dieselbe Eigenschaft benennen können, können sie uneins sein. Die Archivierungsprofile lehnen es ab, das zuzulassen. Eine PDF/A-Datei muss einen XMP-Metadaten-Stream tragen, und jeder Document-Information-Eintrag, der eine XMP-Entsprechung hat, muss mit ihr übereinstimmen; eine Abweichung ist ein Validierungsfehler. Die praktische Erkenntnis ist direkt: In einer Archivierungspipeline sind die beiden keine unabhängigen Felder, sondern eine Tatsache, die zweimal geschrieben wird, und sie müssen im Gleichschritt bleiben.

NextPDF behandelt alle drei als eine einzige Angelegenheit. Der Metadatenfluss ist ein Pfad, nicht zwei konkurrierende.

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.

How NextPDF keeps a document's two metadata systems consistent: one set of values is written to both the Info dictionary and the XMP packet, the packet is size-guarded before it is serialized, and the same packet can be read back so a pipeline can confirm the metadata serialized as intended.

Praktisches Beispiel

Die Form unten setzt die Metadaten einmal und lässt die Engine sie auf beide Systeme fächern, dann liest sie den XMP-Titel zurück, sodass eine Pipeline ihn inspizieren kann. Der Größenschutz ist die Zeile, die „wahrscheinlich in Ordnung” in „nachweislich abgelehnt, falls nicht” verwandelt.

<?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.');
}

Es gibt hier keinen Pfad, auf dem die beiden Systeme leise auseinanderlaufen: Die Werte treten einmal ein, beide Writer verbrauchen dieselbe Quelle, und der Reader lässt eine Pipeline das Ergebnis prüfen.

Häufiges Missverständnis

Der häufige Glaube ist, dass das Info-Dictionary veraltet ist und Sie es ignorieren können. Können Sie nicht – noch nicht. Eine Menge installierter Software, darunter einige Dateivorschauen von Betriebssystemen und ältere Archivierungswerkzeuge, liest immer noch das Info-Dictionary zuerst oder ausschließlich. Es wegzulassen modernisiert eine Datei nicht; es lässt die Datei für alles, was XMP noch nicht übernommen hat, ohne Titel aussehen.

Der spiegelbildliche Fehler besteht darin, die beiden als unabhängige Felder zu behandeln, die Sie separat ausfüllen. Genau so laufen sie auseinander. Sie sind zwei Serialisierungen einer Tatsache. Schreiben Sie sie aus einer Quelle, oder nehmen Sie hin, dass etwas weiter unten in der Kette die Version wählt, die Sie nicht gemeint haben.

Grenzen und Abgrenzungen

NextPDF schreibt beide Systeme und liest XMP zurück. Sein Geltungsbereich ist der XMP-Metadaten-Builder, der DocInfo-Writer und ein XMP-Reader. Es verspricht nicht, eine universelle RDF/XML-Abfrage-Engine zu sein.
Das XMP-Paket ist größengeschützt und verfährt fail-closed. Ein Paket, das die Grenze der Engine überschreitet, löst eine typisierte Ausnahme aus. Die Engine wird kein abgeschnittenes, über die Grenze hinaus gepaddetes oder anderweitig fehlerhaftes Paket ausgeben, um eine übergroße Anfrage „passend zu machen”.
Konsistenz wird zur Schreibzeit aus einer Quelle erzwungen; sie ist keine magische Versöhnung einer Datei, die Sie nicht erzeugt haben. Wenn Sie ein Dokument importieren, dessen beide Systeme bereits uneins sind, ist das Auflösen dessen Ihre Entscheidung, kein implizites Umschreiben.
Die Metadatenanforderungen von PDF/A sind Teil des Archivprofils. Diese Seite erklärt die Regel; das Konformitätsurteil gehört einem Validator, wie es bei Archivierungsarbeit immer der Fall ist. Siehe die Archivierungsseite für diese Grenze.

Der Metadaten-Builder, der DocInfo-Writer und der XMP-Reader sind Core-Fähigkeiten. Die ehrliche Einschränkung liegt beim Größenschutz, unten.

Der Größenschutz ist eine Betriebsentscheidung, keine Einschränkung, für die man sich entschuldigen müsste. Ein XMP-Paket sitzt in einem Metadaten-Stream, und ein Paket, das unbegrenzt wächst, ist eine Denial-of-Service-Oberfläche und ein Korruptionsrisiko für jeden An-Ort-und-Stelle-Editor, der sich auf das beschreibbare Padding verlassen hat. Daher setzt die Engine eine Grenze und löst, wenn eine Anfrage sie überschreiten würde, eine typisierte Ausnahme aus (Spec: ISO 16684-1:2019, §7), statt einen fehlerhaften Stream zu schreiben. Der Fehler ist laut, benannt und zur Schreibzeit – wo Sie die Metadaten bewusst kürzen können – statt leise und später von einem Validator entdeckt, der die Datei schlicht ablehnt.

Metadata: Info dictionary and XMP packet — edition availability
Edition	Availability
Core	Der XMP-Metadaten-Builder, der Document-Information-Dictionary-Writer und der XMP-Reader sind im Core enthalten, mit dem Größenschutz, der bei einem übergroßen Paket fail-closed verfährt – einschließlich der PDF/A-Konformitätsausgabe und -validierung, die den XMP-Metadaten-Stream verpflichtend machen und verlangen, dass DocInfo mit ihm übereinstimmt.
Pro	Fügt Batch- und vorlagenbasierte Metadaten-Workflows über demselben Core-Writer und -Reader hinzu.
Enterprise	Fügt die umfassendere Konformitätsrichtlinie und Berichtsoberfläche über einen Dokumentbestand hinweg hinzu.

Glossar

Document-Information-Dictionary – die alten, flachen Schlüssel/Wert-Metadaten, vom Trailer über den /Info-Eintrag referenziert: Title, Author, Subject, Keywords, Creator, Producer und Daten. Älter als XMP; immer noch weit verbreitet gelesen.
XMP – die Extensible Metadata Platform, ein XML-Format (RDF/XML) zur Beschreibung einer Ressource mit benannten Eigenschaften, gruppiert in Schemas. Standardisiert als ISO 16684-1.
xpacket – die Verarbeitungsanweisung, die ein XMP-Paket einhüllt, mit einem begin-Header (Kodierungsmarkierung) und einem end-Trailer (Flag für schreibgeschützt oder beschreibbar), sodass ein Werkzeug das Paket ohne vollständiges Parsen lokalisieren und bearbeiten kann.
Namespace / Schema – ein benanntes Vokabular von Eigenschaften, gebunden an eine URI. Gängige Präfixe: dc (Dublin Core), xmp (XMP basic), pdf (PDF-spezifisch), xmpMM (Medienverwaltung / Dokumentidentität).
Metadaten-Stream – das an den Dokumentkatalog angehängte PDF-Objekt, das das XMP-Paket trägt. Die kanonische Stelle, die ein moderner Reader zuerst prüft.
PDF/A – die Archiv-PDF-Profilfamilie (ISO 19005). Sie verlangt einen XMP-Metadaten-Stream und fordert, dass jeder Document-Information-Eintrag mit einer XMP-Entsprechung mit ihm übereinstimmt, andernfalls schlägt die Validierung fehl.