İçeriğe geç
getnextpdf.com

Bir PDF'nin kendisi hakkında bildikleri: meta veri ve XMP paketi

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

Modern bir PDF açın ve size kendisi hakkında iki kez anlatabilir. Document Information sözlüğü adı verilen küçük, eski bir anahtar/değer listesi vardır ve aynı şeyi büyük ölçüde daha zengin, yapılandırılmış bir biçimde söyleyen bir XML bloğu — XMP paketi — olabilir. Bu sayfa, bu iki paralel sistem hakkındadır; ikisinin neden hayatta kaldığı ve arşivleme ile arama hatlarının ikisinin uyuşmasında neden ısrar ettiği hakkında.

Başlığa kısa yanıt: bir PDF, başlığını, yazarını, konusunu, anahtar sözcüklerini, onu yapan aracı ve ne zaman yapıldığını bilir. Bu bilgiyi aynı anda iki yerde saklar ve ilginç mühendislik, onları dürüst tutmaktadır.

Meta veri, bir belgenin bir insanın nadiren gördüğü ve bir makinenin neredeyse her zaman okuduğu kısmıdır. İşletim sisteminizin dosya önizlemesi, bir dijital-varlık yöneticisi, bir kütüphane kataloğu, bir arama dizini, bir hukuki-keşif aracı — bunların çoğu, meta veriyi belge metninden önce ya da onunla birlikte okur ve söylediğine güvenir.

Dolayısıyla iki sistem uyuşmadığında — Info sözlüğü bir yazar, XMP paketi başka bir yazar diyorsa — bir noktada bir şey birini seçer ve hangisi olacağını seçmek size düşmez. Bir arama dizini yanlış başlığı öne çıkarabilir. Bir arşivleme doğrulayıcısı dosyayı doğrudan reddedebilir. Sürüklenme, bir hat ona takılana dek görünmezdir ki bu da onu keşfetmenin en kötü zamanıdır.

  • Bir PDF, meta veriyi iki paralel sistemde taşıyabilir: eski Document Information sözlüğü ve modern, RDF/XML’den oluşan XMP paketi.
  • XMP paketi, bir xpacket işleme yönergesine sarılır — bir begin başlığı ve bir end sonlandırıcısı — böylece bir araç, tüm dosyayı yeniden ayrıştırmadan onu bulup, yerinde, hatta yeniden yazabilir.
  • Özellikler ad alanlarında yaşar: başlık ve oluşturan için dc (Dublin Core), oluşturma ve değiştirme tarihleri için xmp, üreten için pdf, belge kimliği ve geçmişi için xmpMM.
  • PDF/A, XMP meta verisi gerektirir ve XMP karşılığı olan DocInfo girdileri onunla eşleşmek zorundadır — bir uyuşmazlık, bir doğrulama hatasıdır.
  • NextPDF, ikisini tek bir iş olarak ele alır: her ikisini de yazar, XMP’yi geri okur ve paketin boyutunu korur; bozuk bir dosya üretmek yerine kapalı başarısız olur.

Dürüst çerçeve şudur: bu, bir biçimlendirme sorunu kılığına girmiş bir eşitleme sorunudur. Document Information sözlüğü (Spec: ISO 32000-2, §14.3.3), trailer’dan /Info girdisiyle referanslanan, düz bir dizgeler listesidir: Title, Author, Subject, Keywords, Creator, Producer ve birkaç tarih. Basittir, XML’den eskidir ve neredeyse her dosyada hâlâ yolculuk eder; çünkü pek çok araç onu hâlâ önce okur.

XMP paketi (Spec: ISO 16684-1:2019, §7) modern yarıdır. Bir XML belgesidir — tam olarak RDF/XML — ve dosyayı, her biri bir ad alanına bağlı şemalara gruplanmış adlandırılmış özellikler kümesi olarak modeller (Spec: ISO 16684-1:2019, §6). İşte düz sözlüğün yapamadığı şey bu yapıdır: bir değer, sıralı bir liste, dil-etiketli bir alternatif (“İngilizce başlık, Fransızca başlık”) ya da yapılandırılmış bir kayıt olabilir. Bir PDF’de o XML, belge kataloğuna iliştirilen bir meta veri akışında yaşar (Spec: ISO 32000-2, §14.3.2); bu, güncel bir okuyucunun baktığı kanonik yerdir.

İncelemeye değer üç ayrıntı vardır; çünkü araçların paketi yanlış yaptığı yerler bunlardır.

Sarmalayıcı. Bir XMP paketi, bir işleme yönergesiyle paranteze alınır; böylece paketin doğrudan aranabilir byte’lar olarak saklandığı biçimlerde bir program, meta veriyi tam bir ayrıştırma olmadan bulabilir; PDF’de özellikle kanonik bulucu, katalog meta veri akışıdır. begin başlığı, metin kodlamasını bildiren bir byte-sıra işareti taşır; end sonlandırıcısı, paketin salt-okunur mu olduğunu yoksa yerinde düzenlenebilir mi olduğunu belirten bir bayrak taşır. Yazılabilir olduğunda, serileştirici XML’den sonra bir dizi boşluk dolgusu bırakır; böylece bir düzenleyici, ardından gelen her byte’ı kaydırmadan içeriği biraz büyütebilir. O dolgu süs değildir — yerinde meta veri düzenlemesini olanaklı kılan şeydir.

Ad alanları. Bir özellik yalnızca kendi ad alanına karşı anlamlıdır ve bir avucu neredeyse evrenseldir. Dublin Core (dc), başlığı ve oluşturanı tutar. XMP temel şeması (xmp), oluşturma ve değiştirme tarihlerini ve yazma aracını tutar. PDF şeması (pdf), üreten dizgesini ve anahtar sözcükleri tutar. Medya-yönetimi şeması (xmpMM), belgenin kimliğini ve türetilme geçmişini tutar — “bu dosya şundan geldi” diyen izi. Bu ad alanı URI’leri ve özellik adları üzerinde — genellikle geleneksel ön eklerle gösterilen — anlaşmak, çekirdek şemaların bütün amacıdır (Spec: ISO 16684-1:2019, Annex B); Dublin Core başlık özelliğini ikisi de konuşan iki araç, önceden bir düzenleme olmadan birlikte çalışır.

Tutarlılık kuralı. İki sistem de aynı özelliği adlandırabildiği için uyuşmayabilirler. Arşivleme profilleri buna izin vermeyi reddeder. Bir PDF/A dosyası bir XMP meta veri akışı taşımak zorundadır ve XMP karşılığı olan herhangi bir Document Information girdisi onunla eşleşmek zorundadır; bir uyuşmazlık, bir doğrulama hatasıdır. Pratik çıkarım dolaysızdır: bir arşivleme hattında, ikisi bağımsız alanlar değil, iki kez yazılmış tek bir olgudur ve adım adım uyum içinde kalmak zorundadırlar.

NextPDF, üçünü de tek bir mesele olarak ele alır. Meta veri akışı, birbiriyle yarışan iki yol değil, tek bir yoldur.

  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.

Aşağıdaki şekil, meta veriyi bir kez ayarlar ve motorun onu her iki sisteme dağıtmasına izin verir, sonra bir hattın inceleyebilmesi için XMP başlığını geri okur. Boyut koruması, “muhtemelen iyi”yi “değilse kanıtlanabilir biçimde reddedildi”ye çeviren satırdır.

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

Burada iki sistemin sessizce ayrıştığı hiçbir yol yoktur: değerler bir kez girer, her iki yazıcı da aynı kaynağı tüketir ve okuyucu, bir hattın sonucu denetlemesine olanak tanır.

Sık görülen inanç, Info sözlüğünün artık geçersiz olduğu ve onu yok sayabileceğinizdir. Yok sayamazsınız — henüz değil. Bazı işletim-sistemi dosya önizlemeleri ve daha eski arşivleme araçları da dâhil, kurulu yazılımların büyük bir kısmı Info sözlüğünü hâlâ önce ya da yalnızca okur. Onu düşürmek bir dosyayı modernleştirmez; XMP’yi benimsememiş her şeye dosyanın başlıksız görünmesine yol açar.

Ayna görüntüsü hatası, ikisini ayrı ayrı doldurduğunuz bağımsız alanlar gibi ele almaktır. Tam olarak böyle sürüklenirler. İkisi, tek bir olgunun iki serileştirmesidir. Onları tek bir kaynaktan yazın ya da bir noktada bir şeyin sizin kastetmediğiniz sürümü seçeceğini kabul edin.

  • NextPDF her iki sistemi de yazar ve XMP’yi geri okur. Kapsamı, XMP meta veri oluşturucusu, DocInfo yazıcısı ve bir XMP okuyucusudur. Genel amaçlı bir RDF/XML sorgu motoru olmayı vaat etmez.
  • XMP paketi boyut korumalıdır ve kapalı başarısız olur. Motorun sınırını aşan bir paket, tipli bir istisna fırlatır. Motor, fazla büyük bir isteği “sığdırmak” için kırpılmış, sınırın ötesine dolgulanmış ya da başka türlü bozuk bir paket üretmez.
  • Tutarlılık, yazma zamanında tek bir kaynaktan zorunlu kılınır; sizin üretmediğiniz bir dosyanın sihirli uzlaştırması değildir. İki sistemi zaten uyuşmayan bir belgeyi içe aktarırsanız, bunu çözmek sizin kararınızdır, örtük bir yeniden yazma değil.
  • PDF/A’nın meta veri gereksinimleri, arşivleme profilinin bir parçasıdır. Bu sayfa kuralı açıklar; uygunluk hükmü, arşivleme işinde her zaman olduğu gibi bir doğrulayıcıya aittir. O hudut için arşivleme sayfasına bakın.

Meta veri oluşturucusu, DocInfo yazıcısı ve XMP okuyucusu Çekirdek yetenekleridir. Dürüst niteleyici, aşağıdaki boyut korumasıyla birlikte durur.

Metadata: Info dictionary and XMP packet — edition availability
EditionAvailability
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.

  • Document Information sözlüğü — trailer’dan /Info girdisiyle referanslanan, eski, düz anahtar/değer meta verisi: Title, Author, Subject, Keywords, Creator, Producer ve tarihler. XMP’den eskidir; hâlâ yaygın biçimde okunur.
  • XMP — Extensible Metadata Platform; bir kaynağı, şemalara gruplanmış adlandırılmış özelliklerle tanımlamak için bir XML (RDF/XML) biçimi. ISO 16684-1 olarak standartlaştırılmıştır.
  • xpacket — bir XMP paketini saran işleme yönergesi; bir begin başlığı (kodlama işareti) ve bir end sonlandırıcısı (salt-okunur ya da yazılabilir bayrağı) ile, böylece bir araç paketi tam bir ayrıştırma olmadan bulup düzenleyebilir.
  • Ad alanı / şema — bir URI’ye bağlı, adlandırılmış bir özellikler sözcük dağarı. Yaygın ön ekler: dc (Dublin Core), xmp (XMP temel), pdf (PDF’ye özgü), xmpMM (medya yönetimi / belge kimliği).
  • Meta veri akışı — belge kataloğuna iliştirilen ve XMP paketini taşıyan PDF nesnesi. Modern bir okuyucunun önce baktığı kanonik konum.
  • PDF/A — arşivleme PDF profili ailesi (ISO 19005). Bir XMP meta veri akışı gerektirir ve XMP karşılığı olan herhangi bir Document Information girdisinin onunla eşleşmesini ister, yoksa doğrulama başarısız olur.