สิ่งที่ PDF รู้เกี่ยวกับตัวเอง: เมตาดาตาและ XMP packet

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

ภาพรวมโดยสังเขป

เปิด PDF สมัยใหม่ขึ้นมา มันอาจบอกคุณเกี่ยวกับตัวเองถึงสองครั้ง มีรายการคู่คีย์/ค่าขนาดเล็กแบบเก่าที่เรียกว่า Document Information dictionary และอาจมีบล็อก XML — XMP packet — ที่บอกสิ่งเดียวกันในรูปแบบที่ร่ำรวยและมีโครงสร้างกว่า หน้านี้ว่าด้วยสองระบบที่ขนานกันนั้น เหตุใดทั้งสองจึงยังคงอยู่ และเหตุใดไปป์ไลน์การเก็บถาวรและการค้นหาจึงยืนกรานว่าทั้งสองต้องสอดคล้องกัน

คำตอบสั้นๆต่อชื่อหัวข้อ: PDF รู้ชื่อเรื่อง ผู้แต่ง หัวเรื่อง คำสำคัญ เครื่องมือที่สร้างมันขึ้น และเมื่อใด มันจัดเก็บความรู้นั้นไว้ในสองที่พร้อมกัน และวิศวกรรมที่น่าสนใจอยู่ที่การทำให้ทั้งสองซื่อตรงต่อกัน

เหตุใดเรื่องนี้จึงสำคัญ

เมตาดาตาคือส่วนของเอกสารที่มนุษย์แทบไม่เห็นและเครื่องจักรอ่านแทบทุกครั้ง การแสดงตัวอย่างไฟล์ของระบบปฏิบัติการ ตัวจัดการสินทรัพย์ดิจิทัล แคตตาล็อกห้องสมุด ดัชนีการค้นหา เครื่องมือสืบค้นทางกฎหมาย — หลายตัวอ่านเมตาดาตาก่อน หรือควบคู่ไปกับ ข้อความของเอกสาร และเชื่อในสิ่งที่มันบอก

ดังนั้นเมื่อสองระบบไม่ตรงกัน — Info dictionary บอกผู้แต่งคนหนึ่งและ XMP packet บอกอีกคนหนึ่ง — บางสิ่งที่อยู่ปลายทางจะเลือกข้างหนึ่ง และคุณไม่ได้เป็นคนเลือกว่าข้างไหน ดัชนีการค้นหาอาจแสดงชื่อเรื่องที่ผิด ตัวตรวจสอบการเก็บถาวรอาจปฏิเสธไฟล์ไปเลย การคลาดเคลื่อนมองไม่เห็นจนกว่าไปป์ไลน์จะสะดุดกับมัน ซึ่งเป็นช่วงเวลาที่เลวร้ายที่สุดในการค้นพบมัน

ฉบับย่อ

• PDF สามารถพกเมตาดาตาใน สองระบบที่ขนานกัน: Document Information dictionary แบบดั้งเดิม และ XMP packet แบบ RDF/XML ที่ทันสมัย
• XMP packet ถูกห่อหุ้มไว้ใน processing instruction แบบ xpacket — ส่วนหัว begin และส่วนท้าย end — เพื่อให้เครื่องมือค้นหาและแก้ไขมันในที่เดิมได้ แม้กระทั่งเขียนทับ โดยไม่ต้องแจงรูปทั้งไฟล์ใหม่
• พร็อพเพอร์ตี้อยู่ใน namespace: dc (Dublin Core) สำหรับชื่อเรื่องและผู้สร้าง, xmp สำหรับวันที่สร้างและแก้ไข, pdf สำหรับ producer, xmpMM สำหรับเอกลักษณ์และประวัติของเอกสาร
• PDF/A กำหนดให้มีเมตาดาตา XMP และรายการ DocInfo ที่มีคู่เทียบใน XMP ต้องตรงกับมัน — ความไม่ตรงกันคือความล้มเหลวในการตรวจสอบ
• NextPDF ปฏิบัติต่อทั้งสองในฐานะงานเดียว: มัน เขียนทั้งสอง อ่าน XMP กลับมา และคุ้มกันขนาดของ packet โดยล้มเหลวแบบ fail closed แทนที่จะปล่อยไฟล์ที่ผิดรูปออกมา

NextPDF จัดการเรื่องนี้อย่างไร

กรอบที่ซื่อสัตย์คือ นี่เป็นปัญหาการซิงโครไนซ์ที่แต่งตัวเป็นปัญหาการจัดรูปแบบ Document Information dictionary (SpecSpec: ISO 32000-2, §14.3.3ISO 32000-2 §14.3.3) ที่อ้างอิงจาก trailer ด้วยรายการ /Info เป็นรายการสตริงแบบแบน: Title, Author, Subject, Keywords, Creator, Producer และวันที่อีกสองสามค่า มันเรียบง่าย มีมาก่อน XML และยังคงพ่วงอยู่ในแทบทุกไฟล์เพราะเครื่องมือจำนวนมากยังคงอ่านมันก่อน

XMP packet (SpecSpec: ISO 16684-1:2019, §7ISO 16684-1:2019 §7) คือครึ่งที่ทันสมัย มันเป็นเอกสาร XML — RDF/XML ให้แม่นยำ — ที่จำลองไฟล์เป็นชุดของ พร็อพเพอร์ตี้ ที่มีชื่อ จัดกลุ่มไว้ใน schema แต่ละ schema ผูกอยู่กับ namespace (SpecSpec: ISO 16684-1:2019, §6ISO 16684-1:2019 §6) โครงสร้างนั้นคือสิ่งที่ dictionary แบบแบนทำไม่ได้: ค่าหนึ่งสามารถเป็นรายการที่เรียงลำดับ ทางเลือกที่กำกับภาษา (“ชื่อเรื่องเป็นภาษาอังกฤษ ชื่อเรื่องเป็นภาษาฝรั่งเศส”) หรือบันทึกที่มีโครงสร้างได้ ใน PDF นั้น XML นี้อยู่ใน metadata stream ที่แนบกับ document catalog (SpecSpec: ISO 32000-2, §14.3.2ISO 32000-2 §14.3.2) ซึ่งเป็นที่ตามแบบฉบับที่โปรแกรมอ่านปัจจุบันมองหา

มีสามรายละเอียดที่ควรแยกแยะ เพราะเป็นจุดที่เครื่องมือทำ packet ผิด

ตัวห่อหุ้ม XMP packet ถูกครอบด้วย processing instruction เพื่อให้ ในรูปแบบที่เก็บ packet เป็นไบต์ที่ค้นหาได้โดยตรง โปรแกรมหนึ่งสามารถระบุตำแหน่งเมตาดาตาได้โดยไม่ต้องแจงรูปทั้งหมด ใน PDF โดยเฉพาะ metadata stream ของ catalog คือตัวระบุตำแหน่งตามแบบฉบับ ส่วนหัว begin พก byte-order mark ที่ประกาศการเข้ารหัสข้อความ ส่วนท้าย end พกแฟล็กที่ระบุว่า packet เป็นแบบอ่านอย่างเดียวหรือแก้ไขในที่เดิมได้ เมื่อมันเขียนได้ ตัว serializer จะทิ้งช่องว่าง whitespace ปิดท้ายไว้หลัง XML เพื่อให้ตัวแก้ไขขยายเนื้อหาได้เล็กน้อยโดยไม่ขยับทุกไบต์ที่ตามมา ช่องว่างนั้นไม่ใช่เครื่องประดับ — มันคือสิ่งที่ทำให้การแก้ไขเมตาดาตาในที่เดิมเป็นไปได้

Namespace พร็อพเพอร์ตี้มีความหมายก็ต่อเมื่อเทียบกับ namespace ของมันเท่านั้น และมีอยู่จำนวนหนึ่งที่แทบเป็นสากล Dublin Core (dc) เก็บชื่อเรื่องและผู้สร้าง XMP basic schema (xmp) เก็บวันที่สร้างและแก้ไขและเครื่องมือสร้าง PDF schema (pdf) เก็บสตริง producer และคำสำคัญ media-management schema (xmpMM) เก็บเอกลักษณ์ของเอกสารและประวัติการสืบเนื่องของมัน — ร่องรอยที่บอกว่า “ไฟล์นี้มาจากไฟล์นั้น” การตกลงกันเรื่อง namespace URI และชื่อพร็อพเพอร์ตี้เหล่านี้ — ซึ่งมักแสดงด้วย prefix ตามแบบแผน — คือจุดประสงค์ทั้งหมดของ core schema (SpecSpec: ISO 16684-1:2019, Annex BISO 16684-1:2019 Annex B) เครื่องมือสองตัวที่ต่างก็พูดภาษาพร็อพเพอร์ตี้ชื่อเรื่องของ Dublin Core ทำงานร่วมกันได้โดยไม่ต้องนัดหมายล่วงหน้า

กฎความสอดคล้อง เนื่องจากทั้งสองระบบสามารถตั้งชื่อพร็อพเพอร์ตี้เดียวกันได้ ทั้งสองจึงไม่ตรงกันได้ โปรไฟล์การเก็บถาวรปฏิเสธที่จะยอมให้เกิดเช่นนั้น ไฟล์ PDF/A ต้องพก XMP metadata stream และรายการ Document Information ใดๆที่มีคู่เทียบใน XMP ต้องตรงกับมัน ความไม่ตรงกันคือความล้มเหลวในการตรวจสอบ ข้อสรุปเชิงปฏิบัติตรงไปตรงมา: ในไปป์ไลน์การเก็บถาวร ทั้งสองไม่ใช่ฟิลด์อิสระต่อกันแต่เป็นข้อเท็จจริงเดียวที่เขียนสองครั้ง และต้องคงให้ตรงกัน

NextPDF จัดการทั้งสามอย่างในฐานะข้อกังวลเดียว ขั้นตอนเมตาดาตาเป็นเส้นทางเดียว ไม่ใช่สองเส้นทางที่แข่งกัน

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

ไม่มีเส้นทางใดตรงนี้ที่สองระบบจะแยกตัวออกจากกันอย่างเงียบๆ: ค่าต่างๆเข้ามาเพียงครั้งเดียว ตัวเขียนทั้งสองบริโภคแหล่งเดียวกัน และตัวอ่านปล่อยให้ไปป์ไลน์ตรวจสอบผลลัพธ์

ความเข้าใจผิดที่พบบ่อย

ความเชื่อที่พบบ่อยคือ Info dictionary ล้าสมัยแล้วและคุณละเลยมันได้ คุณทำไม่ได้ — ยังไม่ได้ตอนนี้ ซอฟต์แวร์ที่ติดตั้งใช้งานจำนวนมาก รวมถึงการแสดงตัวอย่างไฟล์ของบางระบบปฏิบัติการและเครื่องมือการเก็บถาวรรุ่นเก่า ยังคงอ่าน Info dictionary ก่อนหรืออ่านเฉพาะมัน การทิ้งมันไม่ได้ทำให้ไฟล์ทันสมัยขึ้น มันทำให้ไฟล์ดูเหมือนไม่มีชื่อเรื่องสำหรับสิ่งใดก็ตามที่ยังไม่ได้รับเอา XMP มาใช้

ความผิดพลาดที่เป็นภาพสะท้อนกลับคือการปฏิบัติต่อทั้งสองในฐานะฟิลด์อิสระที่คุณกรอกแยกกัน นั่นคือวิธีที่ทั้งสองคลาดเคลื่อนกันพอดี ทั้งสองคือการ serialize ข้อเท็จจริงเดียวกันสองแบบ เขียนทั้งสองจากแหล่งเดียว หรือยอมรับว่าบางสิ่งที่ปลายทางจะเลือกเวอร์ชันที่คุณไม่ได้ตั้งใจ

ขีดจำกัดและขอบเขต

• NextPDF เขียนทั้งสองระบบและอ่าน XMP กลับมา ขอบเขตของมันคือตัวสร้างเมตาดาตา XMP, ตัวเขียน DocInfo และตัวอ่าน XMP มันไม่ได้สัญญาว่าจะเป็นเอนจินสืบค้น RDF/XML แบบใช้งานทั่วไป
• XMP packet ถูกคุ้มกันขนาดและล้มเหลวแบบ fail closed packet ที่เกินขอบเขตของเอนจินจะทำให้เกิดข้อยกเว้นที่ระบุชนิด เอนจินจะไม่ปล่อย packet ที่ถูกตัดทอน ถูกเติมเกินขีดจำกัด หรือผิดรูปด้วยวิธีอื่นออกมาเพื่อให้คำขอที่ใหญ่เกิน “พอดี”
• ความสอดคล้องถูกบังคับใช้ ณ เวลาเขียนจากแหล่งเดียว มันไม่ใช่การประสานข้อมูลแบบเวทมนตร์ของไฟล์ที่คุณไม่ได้ผลิต หากคุณนำเข้าเอกสารที่สองระบบไม่ตรงกันอยู่แล้ว การแก้ไขนั้นเป็นการตัดสินใจของคุณ ไม่ใช่การเขียนทับโดยปริยาย
• ข้อกำหนดเมตาดาตาของ 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.

เอกสารที่เกี่ยวข้อง

• การเก็บถาวรและ PDF/A — จุดที่ XMP packet เลิกเป็นทางเลือกและกฎความสอดคล้องระหว่าง DocInfo กับ XMP กลายเป็นข้อกำหนดที่ผ่านหรือไม่ผ่าน
• ความสอดคล้องที่คุณยื่นให้ผู้ตรวจสอบได้ — เหตุใดเมตาดาตาที่ไป-กลับได้และสอดคล้องกับตัวเองจึงเป็นส่วนหนึ่งของอาร์ติแฟกต์ที่ตรวจสอบได้
• กายวิภาคของไฟล์ PDF — ตำแหน่งที่ trailer, catalog และ metadata stream ตั้งอยู่ในโครงสร้างของไฟล์
• สตรีมและฟิลเตอร์ — metadata stream เป็นสตรีม นี่คือวิธีที่สตรีม PDF ถูกเข้ารหัสและรักษาให้กำหนดผลแน่นอน

อภิธานศัพท์

• Document Information dictionary — เมตาดาตาคู่คีย์/ค่าแบบแบนรุ่นเก่าที่อ้างอิงจาก trailer ด้วยรายการ /Info: Title, Author, Subject, Keywords, Creator, Producer และวันที่ มีมาก่อน XMP; ยังคงถูกอ่านอย่างกว้างขวาง
• XMP — Extensible Metadata Platform รูปแบบ XML (RDF/XML) สำหรับอธิบายทรัพยากรด้วยพร็อพเพอร์ตี้ที่มีชื่อ จัดกลุ่มไว้ใน schema มาตรฐานเป็น ISO 16684-1
• xpacket — processing instruction ที่ห่อหุ้ม XMP packet พร้อมส่วนหัว begin (เครื่องหมายการเข้ารหัส) และส่วนท้าย end (แฟล็กอ่านอย่างเดียวหรือเขียนได้) เพื่อให้เครื่องมือระบุตำแหน่งและแก้ไข packet ได้โดยไม่ต้องแจงรูปทั้งหมด
• Namespace / schema — ชุดคำศัพท์ที่มีชื่อของพร็อพเพอร์ตี้ที่ผูกกับ URI prefix ที่พบบ่อย: dc (Dublin Core), xmp (XMP basic), pdf (เฉพาะ PDF), xmpMM (media management / เอกลักษณ์เอกสาร)
• Metadata stream — อ็อบเจกต์ PDF ที่แนบกับ document catalog ซึ่งพก XMP packet ตำแหน่งตามแบบฉบับที่โปรแกรมอ่านสมัยใหม่ตรวจก่อน
• PDF/A — ตระกูลโปรไฟล์ PDF การเก็บถาวร (ISO 19005) มันกำหนดให้มี XMP metadata stream และเรียกร้องว่ารายการ Document Information ใดๆที่มีคู่เทียบใน XMP ต้องตรงกับมัน มิฉะนั้นการตรวจสอบจะล้มเหลว