Wie PDF-Dateien funktionieren

Ein PDF ist ein Graph nummerierter Objekte – Seiten, Schriftarten, Bilder –, deren Byte-Offsets in einer Xref-Tabelle am Ende der Datei verzeichnet sind. Viewer lesen den Trailer, durchlaufen den Seitenbaum und rendern. Werden die Offsets beschädigt, baut ein toleranter Viewer die Tabelle durch Scannen neu auf; ein strenger lehnt die Datei ab.

Nur lokal

PDF sieht aus wie ein Seitenbeschreibungsformat, und das ist es auch – darunter steckt jedoch eine kleine Datenbank: nummerierte Objekte, von denen jedes auf jedes andere verweisen kann. Eine Schriftart, die auf vierzig Seiten benutzt wird, wird einmal gespeichert, ein wiederverwendetes Kopfbild ebenfalls, und die Seiten selbst sind Knoten in einem Baum, der festlegt, was in welcher Reihenfolge angezeigt wird.

Seit 2008 ist das Format ein ISO-Standard (ISO 32000, überarbeitet 2017), und sein Kernmodell hat sich seit der Originalfassung von 1993 nicht bewegt: ein Header, ein Körper aus Objekten, eine Xref-Tabelle, die verzeichnet, wo jedes Objekt beginnt, und ein Trailer, der auf die Wurzel zeigt. Zwei Jahrzehnte Features wurden aufgesetzt, ohne dieses Fundament zu verschieben – deshalb kann ein Viewer von heute einen Scan von 1998 öffnen.

Wer die Struktur versteht, profitiert sofort: Sie erklärt, warum zusammengefügte Dateien weiter funktionieren, warum gelöschte Seiten in einer Datei zurückbleiben, warum Viewer bei beschädigten Dokumenten unterschiedlicher Meinung sind und was eine Reparatur wirklich tut. Jedes hier verlinkte Tool – Zusammenfügen, Teilen – nimmt diese Objekt-Chirurgie lokal in Ihrem Browser vor.

Zusammenfügen ist die Struktur-Lektion zum Anschauen, denn ein Merge ist der neu gebaute Objektgraph: Sehen Sie dem Merge-PDF-Tool beim Kombinieren mehrerer Dateien zu, und Sie sehen live, wie neue Seitenbaum-Knoten entstehen und eine frische Xref-Tabelle abgelegt wird.

Extraktion durchläuft dieselbe Operation in umgekehrter Richtung – es wird entschieden, welche Objekte die behaltenen Seiten brauchen – und das Split-PDF-Tool schreibt genau diese in eine neue Datei mit eigener Xref-Tabelle und rührt Ihre Originale nie an.

Ein Graph aus nummerierten Objekten

Eine PDF-Datei beginnt mit einem Header wie %PDF-1.7 und besteht danach aus nichts als Objekten: Blöcken, die mit einer Nummer, einer Generationsnummer und dem Schlüsselwort obj beginnen, Inhalt tragen und mit endobj enden. Objekt 1 ist vielleicht der Katalog, die Wurzel des Dokuments; Objekt 2 der Seitenbaum; Objekt 9 ein Content Stream mit den Zeichenbefehlen für eine Seite. Jedes Objekt kann ein anderes benennen, indem es dessen Nummer und den Buchstaben R schreibt – 12 0 R –, was eine indirekte Referenz ist.

Indirektion ist das gesamte Design. Alles ist eine Referenz, sodass Struktur geteilt statt kopiert wird: ein Katalog, geteilte Ressourcen-Wörterbücher und ein 300-Seiten-Dokument, das dieselbe eingebettete Schriftart über ein einziges Objekt referenziert. Das macht PDFs zu einem echten Graphen – und deshalb betreiben Tools, die sie bearbeiten, Graphen-Chirurgie, keine Textverarbeitung.

Die ersten beiden Objekte einer PDF-Datei

1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj

2 0 obj
<< /Type /Pages
   /Kids [3 0 R]
   /Count 1 >>
endobj

Wie sich der Graph auflöst

catalog (object 1)
└─ page tree (object 2)
   └─ page (object 3)

Der Seitenbaum

Seiten leben in einem Baum, nicht in einer Liste: Ein Wurzelknoten vom Typ Pages hält ein Array namens Kids, dessen Einträge Page-Objekte oder weitere Pages-Knoten sind, die genauso verschachteln. Jedes Kind trägt eine Parent-Referenz nach oben. Ein Viewer findet Seite eins, indem er vom Katalog den ersten Ast hinabläuft – und weil Knoten Teilbäume sein können, ist das Einfügen eines 40-Seiten-Abschnitts ein neuer Knoten und ein bearbeitetes Kids-Array.

Im Baum wohnt auch die Vererbung. MediaBox (die Größe der Seite), Rotate (ihre 90-Grad-Ansichtsdrehungen) und Resources (ihre Schriftarten und Bilder) dürfen einmal an einem Pages-Knoten deklariert werden und fließen zu jedem Nachfahren hinab, der sie nicht überschreibt. Ein Dokument, dessen Seiten alle A4 sind, deklariert diese Größe einmal an der Wurzel – deshalb kann ein einzelnes Seitenobjekt so kurz ausfallen.

Ein Seitenbaum mit Vererbung

2 0 obj
<< /Type /Pages
   /Kids [3 0 R 4 0 R]
   /Count 2
   /MediaBox [0 0 595 842] >>
endobj

3 0 obj
<< /Type /Page
   /Parent 2 0 R
   /Contents 9 0 R >>
endobj

Was das Seitenobjekt 3 erbt

MediaBox  [0 0 595 842]   (A4, inherited)
Contents  9 0 R           (its own)

Die Xref-Tabelle und der Trailer

Gegen Ende der Datei sitzt die Xref-Tabelle: eine Zeile pro Objekt, mit dem Byte-Offset, an dem das Objekt beginnt. Ein Eintrag wie 0000000123 00000 n sagt, dass ein Objekt 123 Bytes in der Datei startet; n markiert es als benutzt, f als freien Platz. Es folgt ein Trailer-Wörterbuch, dessen Root-Eintrag auf den Katalog zeigt; danach verzeichnet startxref, wo die Tabelle selbst beginnt, und die Datei schließt mit %%EOF.

Die Absicht ist wahlfreier Zugriff. Ein Viewer, der Seite 240 will, liest nicht von vorn; er springt ans Ende, folgt startxref zur Tabelle und landet direkt bei den Bytes, die er braucht. Alles an der Schwanzstruktur des Formats – auch, warum das Anhängen von Daten sicher ist und das Voranstellen nicht – folgt daraus, dass die Landkarte am hinteren Ende des Gebiets liegt.

Baustein	Sieht aus wie	Rolle
Header	%PDF-1.7	Versionsstempel, erste Zeile der Datei
Objekt	12 0 obj … endobj	Ein nummerierter Knoten mit Inhalt
Indirekte Referenz	12 0 R	Ein Zeiger von einem Objekt zum nächsten
Xref-Eintrag	0000000123 00000 n	Byte-Offset, an dem ein Objekt beginnt
Trailer	<< /Root 1 0 R >>	Zeigt auf den Katalog; die Wurzel des Dokuments
startxref	startxref 12054	Byte-Offset der Xref-Tabelle selbst
EOF-Markierung	%%EOF	Ende des letzten Aktualisierungsabschnitts

Inkrementelle Updates: anhängen, nie umschreiben

Wird ein PDF bearbeitet – ein Formular ausgefüllt, eine Seite gelöscht –, schreibt ein sauber arbeitendes Programm die Datei nicht um. Es hängt an: Neue und geänderte Objekte kommen ans Ende, gefolgt von einer neuen Xref-Tabelle und einem Trailer, die den aktualisierten Zustand beschreiben, dann ein weiteres %%EOF. Die ursprünglichen Bytes bleiben unangetastet, und die neue Tabelle ersetzt die alte.

Dieses Design ist elegant für Aufzeichnungen – und es erklärt drei Phänomene der Praxis. Signierte Dokumente brechen, wenn ein Tool sie umschreibt, denn eine Signatur deckt bestimmte Bytes ab; ein inkrementelles Update kann die Gültigkeit wahren, ein Umschreiben nicht. Gelöschter Inhalt bleibt liegen: Eine Seite, die Sie entfernt haben, sitzt meist noch in der Datei, von der neuesten Tabelle unreferenziert, aber lesbar für jeden, der scannt. Und Dateien wachsen mit jedem Speichern, denn nichts wird zurückgewonnen, bis eine vollständige Neuschreibung passiert – genau das leisten Bereinigen oder Linearisieren.

Warum manche Viewer beschädigte Dateien reparieren

Die Xref-Tabelle ist die tragende Wand des Formats und seine beliebteste Bruchstelle. Eine Datei, die als Text verschickt wurde (was Binärbytes zerstört), die durch eine abgebrochene Übertragung beschnitten wurde oder von einem zu viel versprechenden Tool geschrieben wurde, kann mit Offsets enden, die an die falschen Stellen zeigen. Folgt der Viewer startxref und findet Unsinn, ist die Datei kaputt – strikt nach Lehrbuch.

Was danach passiert, ist eine Richtlinienentscheidung, keine Vorgabe der Spezifikation. Tolerante Viewer rufen einen Neuaufbau auf: Sie durchsuchen die ganze Datei nach allem, was wie ein gültiger Objekt-Header geformt ist (eine Nummer, eine Generation, das Schlüsselwort obj), sammeln die Funde in einer frischen Xref im Speicher und öffnen das Dokument trotzdem. Die Wiederherstellung ist bei großen Dateien langsam und kann bei mehrdeutigen Objekten falsch liegen, funktioniert aber meist – deshalb bietet Acrobat eine Reparatur an, während strengere Viewer schlicht ablehnen. Alles, was ein PDF zurückschreibt, beendet die Mehrdeutigkeit, indem es eine saubere Tabelle über genau die Objekte legt, die es behalten hat.

Verhalten des Viewers	Was er tut	Abwägung
Strikt	Weist die Datei zurück, wenn xref oder startxref falsch ist	Schnell, ehrlich, für die Wiederherstellung unhilfreich
Tolerant	Sucht nach obj-Markierungen und baut eine Tabelle im Speicher neu auf	Langsam bei großen Dateien; rät bei Mehrdeutigkeit
Umschreibende Tools	Schreiben ein neues xref über die Objekte, die sie behalten haben	Beseitigt die Mehrdeutigkeit; neue Datei, neue Offsets

Linearisierung und Schriftart-Subsets

Zwei Verfeinerungen vervollständigen das Bild. Ein linearisiertes PDF – vermarktet als Fast Web View – hat seine Objekte physisch umgeordnet, sodass die von Seite eins zuerst kommen, plus eine Hint-Tabelle, die einem Viewer das Rendern erlaubt, bevor der Rest ankommt. An der Logik des Dokuments ändert sich nichts; nur das Layout auf der Platte ändert sich. Deshalb ist die Linearisierung eine vollständige Neuschreibung – und deshalb verkürzt sie die Zeit bis zum ersten Bild auf langsamen Verbindungen und bei Byte-Serving-Servern.

Schriftarten folgen derselben Philosophie des Teilens: Eine eingebettete Schriftart ist ein Objekt, auf das jede Seite verweist, die sie benutzt, und sauber arbeitende Programme betten nur die tatsächlich verwendeten Glyphen ein – ein Subset. Ein 40-Seiten-Bericht trägt oft nur Dutzende Kilobyte an Schriftdaten statt Megabytes. Der Preis: Die Textextraktion hängt an der ToUnicode-Map des Subsets; ohne sie zeigen Viewer die Glyphen perfekt, während Kopieren und Einfügen Kauderwelsch liefert.

Häufig gestellte Fragen

Wird mein PDF hochgeladen, wenn ich es hier zusammenfüge oder teile?

Nein. Parsen, Seitenbaum-Chirurgie und Xref-Neuschreibung geschehen alle in Ihrem Browser-Tab; die Datei verlässt Ihren Rechner nie. Prüfen Sie es in den DevTools: Öffnen Sie das Netzwerk-Panel, fügen Sie zwei Dateien zusammen und beobachten Sie, wie die Anfrageliste leer bleibt. Die Content-Security-Policy der Website blockiert außerdem ausgehende Verbindungen aus Seitenskripten.

Warum ist mein PDF größer geworden, nachdem ich Seiten gelöscht habe?

Weil ein sauber arbeitender Editor anhängt statt umzuschreiben: Die neue Xref-Tabelle markiert die Seiten als entfernt, aber ihre Objekte sitzen weiter in der Datei, unreferenziert und nicht zurückgewonnen. Der entfernte Inhalt lässt sich möglicherweise auch noch aus den alten Bytes wiederherstellen – gut zu wissen, falls das Dokument jemals vertraulich war. Eine vollständige Neuschreibung ist es, was die Datei tatsächlich schrumpfen lässt.

Lässt sich ein beschädigtes PDF reparieren?

Oft ja. Die meisten Schäden sind eine defekte Xref-Tabelle oder ein defekter startxref-Zeiger, und tolerante Viewer bauen die Tabelle wieder auf, indem sie nach gültigen Objekt-Headern suchen. Nicht wiederherstellbar ist, was die Suche nicht findet: Objekte, die durch Binärkorruption überschrieben wurden oder mittendrin abgeschnitten sind, sind einfach weg. Deshalb liefert eine Reparatur manchmal nur ein teilweises Dokument – die ehrliche Grenze der Suche.

Warum liefert Kopieren und Einfügen bei manchen PDFs Kauderwelsch?

Text wird mit Glyphen-Codes gezeichnet, nicht mit Buchstaben, und die Wiederherstellung von Buchstaben hängt an einer ToUnicode-Map, die mit der eingebetteten Schriftart mitkommt. Subset-Schriftarten ohne gute Map rendern wunderschön, fügen aber Unsinn ein, und gescannte Seiten haben überhaupt keinen Text, bis OCR ihn erfindet. Wenn sich ein PDF schlecht einfügen lässt, stimmt das Rendern – es fehlt die Zuordnung von Glyphe zu Zeichen.

Was bedeutet ein linearisiertes PDF, und brauche ich eines?

Linearisierung (Fast Web View) ordnet die Datei um, sodass die Objekte von Seite eins zuerst kommen, und fügt eine Hint-Tabelle hinzu, die Viewern das Rendern erlaubt, bevor die ganze Datei ankommt. Sie ändert die Auslieferung, nicht den Inhalt. Relevant ist sie, wenn PDFs über Netzwerke mit Byte-Serving ausgeliefert werden; lokal geöffnet ändert sie nichts Sichtbares, hat aber als Nebeneffekt eine aufgeräumte, vollständig neu geschriebene Datei zur Folge.

Warum sieht dasselbe PDF in verschiedenen Viewern unterschiedlich aus?

ISO 32000 lässt bewusst Spielraum: Schriftartersatz, wenn eine eingebettete Schriftart fehlt, viewerspezifische Behandlung beschädigter Strukturen, Farbmanagement-Voreinstellungen und Transparenz-Rendering. Ein PDF mit eingebetteten Subsets und ohne Schäden rendert nahezu überall identisch; Abweichungen entstehen, wenn Dateien auf lokale Schriftarten setzen oder strukturelle Probleme tragen, die jeder Viewer auf seine eigene Art löst.

ToolsByUs-Team · Wie wir unsere Tools prüfen