Ce qu'un PDF sait de lui-même : les métadonnées et le paquet XMP

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

En bref

Ouvre un PDF moderne et il peut te parler de lui-même deux fois. Il y a une petite liste clé/valeur ancienne appelée dictionnaire d’information du document, et il peut y avoir un bloc de XML — le paquet XMP — qui dit à peu près la même chose sous une forme plus riche et structurée. Cette page traite de ces deux systèmes parallèles, de la raison de leur survie à tous les deux, et de pourquoi les chaînes d’archivage et de recherche insistent pour qu’ils s’accordent.

La réponse courte au titre : un PDF connaît son titre, son auteur, son sujet, ses mots-clés, l’outil qui l’a créé, et quand. Il stocke ce savoir à deux endroits à la fois, et l’ingénierie intéressante consiste à les garder honnêtes.

Pourquoi c’est important

Les métadonnées sont la partie d’un document qu’un humain voit rarement et qu’une machine lit presque toujours. L’aperçu de fichier de ton système d’exploitation, un gestionnaire d’actifs numériques, un catalogue de bibliothèque, un index de recherche, un outil de découverte juridique — nombre d’entre eux lisent les métadonnées avant, ou en même temps que, le texte du document, et font confiance à ce qu’elles disent.

Alors, quand les deux systèmes divergent — le dictionnaire Info dit un auteur et le paquet XMP en dit un autre — quelque chose en aval en choisit un, et tu n’as pas voix au chapitre. Un index de recherche peut faire remonter le mauvais titre. Un validateur d’archivage peut rejeter le fichier purement et simplement. La dérive est invisible jusqu’à ce qu’une chaîne bute dessus, ce qui est le pire moment pour la découvrir.

La version courte

Un PDF peut porter des métadonnées dans deux systèmes parallèles : le dictionnaire d’information du document hérité et le paquet XMP moderne de RDF/XML.
Le paquet XMP est enveloppé dans une instruction de traitement xpacket — un en-tête begin et un trailer end — pour qu’un outil puisse le trouver et même, sur place, le réécrire sans réanalyser tout le fichier.
Les propriétés vivent dans des espaces de noms : dc (Dublin Core) pour le titre et le créateur, xmp pour les dates de création et de modification, pdf pour le producteur, xmpMM pour l’identité et l’historique du document.
PDF/A exige des métadonnées XMP, et les entrées DocInfo qui ont des équivalents XMP doivent y correspondre — un désaccord est un échec de validation.
NextPDF traite les deux comme un seul travail : il écrit les deux, relit le XMP, et garde la taille du paquet, en échouant de manière fermée plutôt que d’émettre un fichier malformé.

L’approche de NextPDF

Le cadrage honnête, c’est qu’il s’agit d’un problème de synchronisation déguisé en problème de mise en forme. Le dictionnaire d’information du document (Spec: ISO 32000-2, §14.3.3), référencé depuis le trailer par l’entrée /Info, est une liste plate de chaînes : Title, Author, Subject, Keywords, Creator, Producer, et quelques dates. Il est simple, il est antérieur à XML, et il voyage encore avec presque tous les fichiers parce que tant d’outils le lisent encore en premier.

Le paquet XMP (Spec: ISO 16684-1:2019, §7) est la moitié moderne. C’est un document XML — du RDF/XML, pour être exact — qui modélise le fichier comme un ensemble de propriétés nommées regroupées en schémas, chaque schéma lié à un espace de noms (Spec: ISO 16684-1:2019, §6). Cette structure est ce que le dictionnaire plat ne peut pas faire : une valeur peut être une liste ordonnée, une alternative étiquetée par langue (« titre en anglais, titre en français »), ou un enregistrement structuré. Dans un PDF, ce XML vit dans un flux de métadonnées attaché au catalogue du document (Spec: ISO 32000-2, §14.3.2), qui est l’endroit canonique où un lecteur actuel regarde.

Trois détails méritent d’être disséqués, car c’est là que les outils se trompent sur le paquet.

L’enveloppe. Un paquet XMP est encadré par une instruction de traitement de sorte que, dans les formats où le paquet est stocké sous forme d’octets directement cherchables, un programme peut localiser les métadonnées sans une analyse complète ; dans le cas du PDF en particulier, le flux de métadonnées du catalogue est le localisateur canonique. L’en-tête begin porte une marque d’ordre des octets qui déclare l’encodage du texte ; le trailer end porte un drapeau indiquant si le paquet est en lecture seule ou peut être édité sur place. Lorsqu’il est inscriptible, le sérialiseur laisse une suite d’espaces de remplissage après le XML afin qu’un éditeur puisse faire croître légèrement le contenu sans décaler chaque octet qui suit. Ce remplissage n’est pas une décoration — c’est ce qui rend l’édition de métadonnées sur place possible.

Les espaces de noms. Une propriété n’a de sens que par rapport à son espace de noms, et une poignée sont quasi universels. Dublin Core (dc) détient le titre et le créateur. Le schéma de base XMP (xmp) détient les dates de création et de modification et l’outil de création. Le schéma PDF (pdf) détient la chaîne de producteur et les mots-clés. Le schéma de gestion de médias (xmpMM) détient l’identité du document et son historique de dérivation — la trace qui dit « ce fichier provient de celui-là ». S’accorder sur ces URI d’espace de noms et noms de propriété — généralement présentés avec des préfixes conventionnels — est tout l’objet des schémas fondamentaux (Spec: ISO 16684-1:2019, Annex B) ; deux outils qui parlent tous deux la propriété de titre Dublin Core interopèrent sans arrangement préalable.

La règle de cohérence. Parce que les deux systèmes peuvent nommer la même propriété, ils peuvent diverger. Les profils d’archivage refusent de le permettre. Un fichier PDF/A doit porter un flux de métadonnées XMP, et toute entrée du dictionnaire d’information du document qui a un équivalent XMP doit y correspondre ; un désaccord est un échec de validation. La conclusion pratique est directe : dans une chaîne d’archivage, les deux ne sont pas des champs indépendants mais un seul fait écrit deux fois, et ils doivent rester en phase.

NextPDF gère les trois comme une seule préoccupation. Le flux de métadonnées est un seul chemin, pas deux chemins concurrents.

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.

Comment NextPDF garde cohérents les deux systèmes de métadonnées d'un document : un seul jeu de valeurs est écrit à la fois dans le dictionnaire Info et dans le paquet XMP, la taille du paquet est gardée avant sa sérialisation, et le même paquet peut être relu pour qu'une chaîne confirme que les métadonnées ont été sérialisées comme prévu.

Exemple pratique

La forme ci-dessous définit les métadonnées une seule fois et laisse le moteur les déployer vers les deux systèmes, puis relit le titre XMP pour qu’une chaîne puisse l’inspecter. La garde de taille est la ligne qui transforme « probablement bon » en « prouvablement refusé si ce n’est pas le cas ».

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

Il n’y a ici aucun chemin où les deux systèmes divergent en silence : les valeurs entrent une fois, les deux écrivains consomment la même source, et le lecteur permet à une chaîne de vérifier le résultat.

Idée fausse courante

La croyance fréquente est que le dictionnaire Info est obsolète et que tu peux l’ignorer. Tu ne peux pas — pas encore. Une grande quantité de logiciels installés, y compris certains aperçus de fichiers de systèmes d’exploitation et des outils d’archivage anciens, lit encore le dictionnaire Info en premier ou exclusivement. Le supprimer ne modernise pas un fichier ; cela rend le fichier sans titre aux yeux de tout ce qui n’a pas adopté XMP.

L’erreur inverse est de traiter les deux comme des champs indépendants que tu remplis séparément. C’est exactement ainsi qu’ils dérivent. Ce sont deux sérialisations d’un seul fait. Écris-les à partir d’une seule source, ou accepte que quelque chose en aval choisisse la version que tu ne voulais pas.

Limites et frontières

NextPDF écrit les deux systèmes et relit le XMP. Sa portée est le constructeur de métadonnées XMP, l’écrivain DocInfo et un lecteur XMP. Il ne promet pas d’être un moteur de requête RDF/XML à usage général.
Le paquet XMP est gardé en taille et échoue de manière fermée. Un paquet qui dépasse la borne du moteur lève une exception typée. Le moteur n’émettra pas de paquet tronqué, rempli au-delà de la limite, ou autrement malformé pour faire « tenir » une requête surdimensionnée.
La cohérence est imposée au moment de l’écriture à partir d’une seule source ; ce n’est pas une réconciliation magique d’un fichier que tu n’as pas produit. Si tu importes un document dont les deux systèmes divergent déjà, le résoudre est ta décision, pas une réécriture implicite.
Les exigences de métadonnées de PDF/A font partie du profil d’archivage. Cette page explique la règle ; le verdict de conformité revient à un validateur, comme toujours pour le travail d’archivage. Vois la page d’archivage pour cette frontière.

Le constructeur de métadonnées, l’écrivain DocInfo et le lecteur XMP sont des capacités Core. Le qualificatif honnête se situe avec la garde de taille, ci-dessous.

Metadata: Info dictionary and XMP packet — edition availability
Edition	Availability
Core	The XMP metadata builder, the Document Information dictionary writer, and the XMP reader ship in Core, with the size guard that fails closed on an oversized packet — including the PDF/A conformance output and validation that make the XMP metadata stream mandatory and require DocInfo to match it.
Pro	Adds batch and templated metadata workflows over the same Core writer and reader.
Enterprise	Adds the broader conformance policy and reporting surface across a document estate.

Documents liés

Archivage et PDF/A — là où le paquet XMP cesse d’être facultatif et où la règle de cohérence DocInfo-vers-XMP devient une exigence qui réussit ou échoue.
Une conformité que tu peux remettre à un auditeur — pourquoi des métadonnées qui font un aller-retour et s’accordent avec elles-mêmes font partie d’un artefact auditable.
L’anatomie d’un fichier PDF — où se situent le trailer, le catalogue et le flux de métadonnées dans la structure du fichier.
Flux et filtres — le flux de métadonnées est un flux ; voici comment les flux PDF sont encodés et maintenus déterministes.

Glossaire

Dictionnaire d’information du document — les métadonnées clé/valeur héritées et plates référencées depuis le trailer par l’entrée /Info : Title, Author, Subject, Keywords, Creator, Producer, et des dates. Antérieur à XMP ; encore largement lu.
XMP — l’Extensible Metadata Platform, un format XML (RDF/XML) pour décrire une ressource avec des propriétés nommées regroupées en schémas. Normalisé sous le nom ISO 16684-1.
xpacket — l’instruction de traitement qui enveloppe un paquet XMP, avec un en-tête begin (marqueur d’encodage) et un trailer end (drapeau lecture seule ou inscriptible), pour qu’un outil puisse localiser et éditer le paquet sans une analyse complète.
Espace de noms / schéma — un vocabulaire nommé de propriétés lié à une URI. Préfixes courants : dc (Dublin Core), xmp (base XMP), pdf (spécifique au PDF), xmpMM (gestion de médias / identité du document).
Flux de métadonnées — l’objet PDF, attaché au catalogue du document, qui porte le paquet XMP. L’emplacement canonique qu’un lecteur moderne consulte en premier.
PDF/A — la famille de profils PDF d’archivage (ISO 19005). Elle exige un flux de métadonnées XMP et impose que toute entrée du dictionnaire d’information du document ayant un équivalent XMP y corresponde, faute de quoi la validation échoue.

Ce qu'un PDF sait de lui-même : les métadonnées et le paquet XMP