PDF は自分自身について何を知っているか — メタデータと XMP パケット

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

概要

現代の PDF を開くと、それは自分自身について 2 回語るかもしれません。Document Information ディクショナリと呼ばれる小さく古いキー/値のリストがあり、そして XML のブロック — XMP パケット — がほぼ同じことをより豊かで構造化された形で告げることがあります。このページは、それら 2 つの並行するシステムについて、なぜ両方が生き残るのか、そしてなぜアーカイブと検索のパイプラインが両者の合意を主張するのかについてです。

タイトルへの短い答えは、こうです。PDF は、自分のタイトル、作成者、サブジェクト、キーワード、それを作ったツール、そして時刻を知っています。その知識を 2 つの場所に同時に格納し、面白いエンジニアリングはそれらを正直に保つところにあります。

なぜこれが重要か

メタデータは、人間がめったに目にせず、機械がほとんど常に読む文書の部分です。あなたの OS のファイルプレビュー、デジタルアセットマネージャ、図書館の目録、検索インデックス、リーガルディスカバリのツール — その多くが、文書テキストの前に、あるいはそれと並んでメタデータを読み、書かれている内容を信頼します。

だから 2 つのシステムが食い違うとき — Info ディクショナリがある作成者を言い、XMP パケットが別の作成者を言うとき — 下流の何かが一方を選び、あなたはどちらかを選べません。検索インデックスが誤ったタイトルを表に出すかもしれません。アーカイブバリデータがファイルをそのまま却下するかもしれません。そのずれは、パイプラインがつまずくまで見えず、それは発見するには最悪の時です。

要点

• PDF はメタデータを 2 つの並行するシステム で携えられます。レガシーな Document Information ディクショナリ と、RDF/XML の現代的な XMP パケット です。
• XMP パケットは xpacket 処理命令 — begin ヘッダーと end トレーラー — で包まれます。だからツールは、ファイル全体を再パースせずに、それを見つけ、その場で書き換えることさえできます。
• プロパティは 名前空間 に存在します。タイトルと作成者には dc（Dublin Core）、作成日と変更日には xmp、生成元には pdf、文書のアイデンティティと履歴には xmpMM です。
• PDF/A は XMP メタデータを要求し、XMP に対応物を持つ DocInfo エントリはそれと一致しなければなりません — 食い違いは検証の失敗です。
• NextPDF は両者を 1 つの仕事として扱います。両方を書き、XMP を読み戻し、パケットのサイズを守り、不正なファイルを送出するよりフェイルクローズします。

NextPDF のアプローチ

正直な枠組みで言えば、これは整形の問題に見せかけた同期の問題です。Document Information ディクショナリ（SpecSpec: ISO 32000-2, §14.3.3ISO 32000-2 §14.3.3）は、トレーラーから /Info エントリによって参照され、文字列のフラットなリストです。Title、Author、Subject、Keywords、Creator、Producer、そしていくつかの日付です。それは単純で、XML より前から存在し、いまもほぼすべてのファイルに乗り続けています。あまりに多くのツールがいまだそれを最初に読むからです。

XMP パケット（SpecSpec: ISO 16684-1:2019, §7ISO 16684-1:2019 §7）は現代側の半分です。それは XML 文書 — 正確には RDF/XML — であり、ファイルを スキーマ にグループ化された名前付き プロパティ の集合としてモデル化し、各スキーマは名前空間に結びつきます（SpecSpec: ISO 16684-1:2019, §6ISO 16684-1:2019 §6）。その構造こそ、フラットなディクショナリにはできないことです。値は、順序付きリスト、言語タグ付きの代替（「英語のタイトル、フランス語のタイトル」）、または構造化レコードになり得ます。PDF では、その XML は文書カタログに添付された メタデータストリーム に存在し（SpecSpec: ISO 32000-2, §14.3.2ISO 32000-2 §14.3.2）、それが現在のリーダーが見る正準の場所です。

分解する価値のある詳細が 3 つあります。そこがツールがパケットを取り違える場所だからです。

ラッパー。 XMP パケットは処理命令で囲まれます。これは、パケットが直接検索可能なバイトとして格納される形式において、プログラムが完全なパースなしにメタデータを位置特定できるようにするためです。PDF では特に、カタログのメタデータストリームが正準のロケータです。begin ヘッダーはテキストエンコーディングを宣言するバイトオーダーマークを携え、end トレーラーはパケットが読み取り専用か、その場で編集できるかを述べるフラグを携えます。書き込み可能なとき、シリアライザは XML の後に一連の空白パディングを残します。だからエディタは、後続のすべてのバイトをずらすことなく、コンテンツをわずかに増やせます。そのパディングは装飾ではありません — それこそが、その場でのメタデータ編集を可能にするものです。

名前空間。 プロパティはその名前空間に対してのみ意味を持ち、ひと握りがほぼ普遍的です。Dublin Core（dc）はタイトルと作成者を保持します。XMP basic スキーマ（xmp）は作成日と変更日、そして作成ツールを保持します。PDF スキーマ（pdf）は生成元の文字列とキーワードを保持します。メディア管理スキーマ（xmpMM）は文書のアイデンティティとその派生履歴 — 「このファイルはあのファイルから来た」と告げる足跡 — を保持します。これらの名前空間 URI とプロパティ名 — 通常は慣例的なプレフィックスで示される — に合意することこそが、コアスキーマの全目的です（SpecSpec: ISO 16684-1:2019, Annex BISO 16684-1:2019 Annex B）。Dublin Core のタイトルプロパティを共に話す 2 つのツールは、事前の取り決めなしに相互運用します。

整合性ルール。 両方のシステムが同じプロパティを名付けられるため、両者は食い違うことがあります。アーカイブプロファイルはそれを許しません。PDF/A ファイルは XMP メタデータストリームを携えなければならず、XMP に対応物を持つ Document Information エントリはそれと一致しなければなりません。食い違いは検証の失敗です。実践的な要点は端的です。アーカイブパイプラインでは、両者は独立したフィールドではなく、2 度書かれた 1 つの事実であり、足並みをそろえていなければなりません。

NextPDF はこの 3 つすべてを 1 つの関心事として扱います。メタデータのフローは 1 本の経路であって、競合する 2 本ではありません。

1. 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.
2. Write the Info dictionaryThe DocInfo writer emits the legacy Title, Author, Subject, Keywords, Creator, Producer and date entries that older tools read first.
3. 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.
4. 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.
5. 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.

実践例

下記の形は、メタデータを一度設定し、エンジンに両方のシステムへ展開させ、それからパイプラインが検査できるよう 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.');
}

ここには、2 つのシステムがひそかに分岐する経路はありません。値は一度入り、両方のライターが同じソースを消費し、リーダーはパイプラインに結果をチェックさせます。

よくある誤解

よくある思い込みは、Info ディクショナリは時代遅れで無視してよいというものです。無視できません — まだです。OS のファイルプレビューや古いアーカイブツールを含め、大量のインストール済みソフトウェアが、いまだ Info ディクショナリを最初に、あるいはそれだけを読みます。それを落とすことはファイルを現代化しません。XMP を採用していないあらゆるものに対して、ファイルを無題に見せるだけです。

鏡像の間違いは、両者をそれぞれ別々に埋める独立したフィールドとして扱うことです。それこそが両者がずれる仕組みそのものです。両者は 1 つの事実の 2 つのシリアライゼーションです。それらを 1 つのソースから書くか、さもなくば下流の何かが、あなたが意図しなかった版を選ぶことを受け入れてください。

限界と境界

• NextPDF は両方のシステムを書き、XMP を読み戻します。 その範囲は XMP メタデータビルダー、DocInfo ライター、そして XMP リーダーです。汎用の RDF/XML クエリエンジンであることを約束はしません。
• XMP パケットはサイズが守られ、フェイルクローズします。 エンジンの境界を超えるパケットは型付き例外を送出します。エンジンは、過大なリクエストを「収める」ために、切り詰められた、境界を超えてパディングされた、あるいはその他の不正なパケットを送出しません。
• 整合性は 1 つのソースから書き込み時に強制されます。それはあなたが生成しなかったファイルの魔法のような調停ではありません。 2 つのシステムがすでに食い違う文書をインポートした場合、それを解決するのはあなたの判断であり、暗黙の書き換えではありません。
• PDF/A のメタデータ要件はアーカイブプロファイルの一部です。 このページはルールを説明します。適合性の判定はバリデータに属します。アーカイブの仕事では常にそうであるように、です。その境界についてはアーカイブのページを参照してください。

メタデータビルダー、DocInfo ライター、そして XMP リーダーは Core の機能です。正直な但し書きは、下記のサイズガードとともにあります。

Human-factors note:Human-factors note

The size guard is an operability decision, not a limitation to apologize for. An XMP packet sits in a metadata stream, and a packet that grows without bound is a denial-of-service surface and a corruption risk for any in-place editor that relied on the writable padding. So the engine sets a bound and, when a request would exceed it, raises a typed exception (SpecSpec: ISO 16684-1:2019, §7ISO 16684-1:2019 §7) instead of writing a malformed stream. The failure is loud, named, and at write time — where you can trim the metadata deliberately — rather than silent and discovered later by a validator that simply rejects the file.

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.

関連ドキュメント

• Archival and PDF/A — XMP パケットが任意でなくなり、DocInfo と XMP の整合性ルールが合否要件になる場所。
• Compliance you can hand to an auditor — ラウンドトリップし自分自身と合意するメタデータが、なぜ監査可能なアーティファクトの一部なのか。
• The anatomy of a PDF file — トレーラー、カタログ、そしてメタデータストリームが、ファイル構造のどこに位置するか。
• Streams and filters — メタデータストリームはストリームである。これは、PDF ストリームがどうエンコードされ、決定論的に保たれるかである。

用語集

• Document Information ディクショナリ（Document Information dictionary） — トレーラーから /Info エントリによって参照される、レガシーでフラットなキー/値メタデータ。Title、Author、Subject、Keywords、Creator、Producer、そして日付。XMP より前から存在し、いまも広く読まれる。
• XMP — Extensible Metadata Platform。名前付きプロパティをスキーマにグループ化してリソースを記述する XML（RDF/XML）形式。ISO 16684-1 として標準化されている。
• xpacket — XMP パケットを包む処理命令。begin ヘッダー（エンコーディングマーカー）と end トレーラー（読み取り専用または書き込み可能フラグ）を持ち、ツールが完全なパースなしにパケットを位置特定し編集できるようにする。
• 名前空間 / スキーマ（Namespace / schema） — URI に結びついた名前付きプロパティ語彙。一般的なプレフィックス: dc（Dublin Core）、xmp（XMP basic）、pdf（PDF 固有）、xmpMM（メディア管理 / 文書アイデンティティ）。
• メタデータストリーム（Metadata stream） — XMP パケットを携える、文書カタログに添付された PDF オブジェクト。現代のリーダーが最初にチェックする正準の場所。
• PDF/A — アーカイブ PDF プロファイルのファミリ（ISO 19005）。XMP メタデータストリームを要求し、XMP に対応物を持つ Document Information エントリがそれと一致することを要求する。さもなくば検証は失敗する。