Tabellen aus PDF in Markdown extrahieren
Fragen Sie jemanden, der regelmäßig PDFs konvertiert, was am häufigsten kaputtgeht – die Antwort ist fast immer dieselbe: Tabellen. Überschriften, Absätze und Listen werden zuverlässig konvertiert; Tabellen sind der Teil, der jedes einzelne Mal nachgeprüft werden muss.
Dieser Artikel erklärt, warum Tabellen im PDF-Format strukturell schwierig sind, wie moderne Konverter sie in Markdown-Pipe-Tables wieder aufbauen, welche Tabellenfunktionen Markdown gar nicht ausdrücken kann und wie Sie eine konvertierte Tabelle überprüfen, statt ihr blind zu vertrauen.
PDF kennt keine Tabellen – das ist das ganze Problem
Word-Dokumente, HTML-Seiten und Tabellenkalkulationen haben ein echtes Tabellenobjekt: Zeilen, Spalten, Zellen, Verbindungen. Das PDF-Format hat nichts davon. Was in einer PDF wie eine Tabelle aussieht, ist eine Menge von Textfragmenten an Koordinaten, plus optional ein paar gezeichnete Linien und Rechtecke in der Nähe.
Das bedeutet: Eine Tabelle zu extrahieren ist kein Abrufen, sondern ein Schlussfolgern. Der Konverter muss entscheiden, welche Fragmente zur selben Zeile gehören, zu welcher Spalte jedes gehört, ob eine nahe Linie ein Zellenrand oder eine Seitendekoration ist und wo die Tabelle endet und der nächste Absatz beginnt.
Das erklärt auch, warum dieselbe Tabelle in einer PDF perfekt und in einer anderen miserabel konvertiert wird. Der Unterschied liegt nicht in der Komplexität der Tabelle, sondern darin, wie viele Anhaltspunkte das Dokument liefert: Deutliche Linien und konsistente Ausrichtung geben der Erkennung etwas zum Arbeiten; fehlen sie, bleibt nur Raten.
Liniertabellen vs. Leerraumtabellen
Liniertabellen – solche mit sichtbaren Linien zwischen den Zellen – sind der dankbare Fall. Die Linien unterteilen die Seite in Bereiche, jeder Bereich enthält den Text einer Zelle, und das Strukturerkennungsproblem reduziert sich auf die Lesereihenfolge innerhalb eines bekannten Rasters. Die meisten Konverter, auch der auf dieser Website, kommen damit gut zurecht.
Rahmenlose, an Leerräumen ausgerichtete Tabellen sind das Gegenteil. Ohne Linien als Orientierung clustert die Erkennung Textfragmente nach ihren Koordinaten: Fragmente mit ausgerichteten Grundlinien bilden eine Zeile, Fragmente mit gruppierten x-Positionen eine Spalte. Schon eine minimal inkonsistente Ausrichtung – eine Zelle, die zwei Punkte neben ihrer Spalte liegt – kann falsch zugeordnete Werte zur Folge haben.
Aus Berichtssoftware exportierte Finanzausweise sind meist liniert und werden sauber konvertiert. Aus Präsentationen kopierte Tabellen, nur mit Abständen gesetzte Tabellen und über Seitenumbrüche verteilte Tabellen mit wiederholten Kopfzeilen sind die rahmenlosen, fragmentierten Fälle, bei denen eine Kontrolle unverzichtbar ist.
Wie die Strukturerkennung das Raster wieder aufbaut
Die PDF-Engine hinter dem Konverter dieser Website führt die Tabellenstrukturerkennung als Teil der Extraktion durch: Sie erkennt Tabellenbereiche auf der Seite, segmentiert sie in Zeilen und Spalten, ordnet jedes Textfragment einer Zelle zu und gibt das Ergebnis als GitHub-Flavored-Markdown-Pipe-Table aus.
Diese Ausgabe ist der ehrliche, verlustbehaftete, aber nützliche gemeinsame Nenner. Eine Pipe-Table bewahrt die wesentliche Semantik – welcher Wert zu welcher Zeilen- und Spaltenüberschrift gehört – und verwirft dabei visuelle Details wie Spaltenbreiten, Zellenschattierungen und Ausrichtung, für die Markdown keine Ausdrucksmöglichkeit hat.
Die Erkennungsqualität hat sich in öffentlichen Benchmarks zur Tabellenextraktion in den letzten Jahren deutlich verbessert, und Engines wie diese liegen weit über dem naiven Ansatz, eine PDF zu kopieren und den Text einzufügen. Aber ein Benchmark-Wert ist ein Durchschnitt – und Ihre Tabelle könnte unterdurchschnittlich sein. Hinweise zur Überprüfung folgen unten, und sie haben ihren Grund.
Was in Ihrem Markdown ankommt
Eine saubere Konvertierung sieht genau so aus, wie es ein Mensch schreiben würde: eine Kopfzeile, eine Trennlinie und eine Pipe-Zeile pro Datenzeile. Leere Zellen bleiben leer, numerische Spalten behalten ihre Werte, und die Tabelle wird auf GitHub, in Obsidian und in jedem gängigen Markdown-Renderer als echte Tabelle dargestellt.
Auch der umgebende Kontext bleibt erhalten. Der Absatz über der Tabelle, die Tabellenüberschrift, sofern sie als normaler Text gesetzt war, und die Fußnoten darunter werden als normale Inhalte konvertiert – die Tabelle behält also ihren Kontext, statt unerklärt für sich zu stehen.
Was nicht überlebt, ist jede zweidimensionale Struktur jenseits von Zeilen und Spalten. Spaltengruppen, über die gesamte Tabellenbreite reichende Summenzeilen und verschachtelte Unterüberschriften werden zu zusätzlichen Zeilen verflacht oder in Zellentext eingearbeitet. Die Daten sind noch da; die Form, die sie im Original hatten, nicht.
Verbundene Zellen und andere GFM-Grenzen
GitHub-Flavored-Markdown-Pipe-Tables sind bewusst minimal gehalten. Sie haben genau eine Kopfzeile, keine Zellverbindungen, keine Zeilenverbindungen und keine Ausrichtung außer links/zentriert/rechts pro Spalte. Alles Reichhaltigere in der Quell-PDF muss verflacht werden, um zu passen.
Eine über drei Spalten verbundene Zelle wird zu Text in der ersten Zelle mit leeren Zellen danach – oder zu in jeder Zelle wiederholtem Text. Eine zweistufige Kopfzeile wird zu einer einzigen Kopfzeile, in der die Ebenen verbunden sind, manchmal mit einem Trennzeichen. Ob diese Verflachung akzeptabel ist, hängt ganz davon ab, was Sie als Nächstes tun: lesbar in einem Dokument, verlustbehaftet beim Import in eine Tabellenkalkulation.
Wenn das Ziel die verbundene Struktur tatsächlich braucht, ist die Tabelle über Markdown hinausgewachsen, nicht über den Konverter. Ein CSV-Export aus der Originalquelle oder der eigene PDF-Import eines Tabellenprogramms ist für diese eine Tabelle der bessere Weg – ein Konverter sollte nicht gezwungen werden, so zu tun, als hätte die Semantik überlebt.
Kontrollieren Sie die Zahlen stichprobenartig
Die Fehlermodi der Tabellenkonvertierung sind von Natur aus leise. Eine verschobene Spalte wird als völlig normale Tabelle mit einem Wert an der falschen Stelle dargestellt. Eine durch einen Seitenumbruch geteilte Zeile kann zu zwei Zeilen werden. Ein als Bindestrich gelesenes Minuszeichen macht aus einer negativen eine positive Zahl, ohne das Erscheinungsbild der Tabelle zu ändern.
Überprüfen Sie also proportional zur Tragweite. Bei einer Tabelle in einem Blogbeitrag genügt ein Blick auf die gerenderte Version. Bei einer Finanz- oder Wissenschaftstabelle, die in einen Bericht einfließt, vergleichen Sie Zeilenanzahl, Spaltensummen und eine Stichprobe von Zellen mit dem Original. Bei allem, was in ein Modell oder eine Datenbank fließt, ist diese Prüfung Teil der Pipeline, kein optionaler Schritt.
Der Konverter hilft, wo er kann: Seiten, deren Tabellen überprüfungsbedürftig wirken, werden in den Konvertierungswarnungen markiert, statt stillschweigend übergangen zu werden. Behandeln Sie diese Markierungen als Hinweise auf genau die Zeilen, die zuerst geprüft werden sollten.
Tabellen mit Pandoc weiterreichen
Sobald eine Tabelle eine Markdown-Pipe-Table ist, ist sie ein erstklassiger Bestandteil der Pandoc-Engine, die die anderen Ausgabeformate dieser Website antreibt. Wählen Sie HTML als Ausgabe, wird die Tabelle zu echtem <table>-Markup; wählen Sie LaTeX, wird sie zu einer tabular-Umgebung; wählen Sie RST, wird sie zu Grid-Syntax.
Diese zweite Stufe ist insofern verlustfrei, als Pandoc die Pipe-Table vor dem Schreiben in ein Dokumentmodell parst, sodass Spaltenausrichtung und Kopfstruktur in jedem Format erhalten bleiben. Was beim PDF-zu-Markdown-Schritt verloren ging, kommt nicht zurück – aber es geht auch nichts weiter verloren.
Für die meisten Workflows endet die Kette bei Markdown, weil das Ziel Markdown spricht. Wenn nicht – eine LaTeX-Arbeit, eine Sphinx-Site –, ist der Konvertierungspfad bereits da, einen Dropdown-Eintrag entfernt, und läuft auf derselben lokalen, privaten Pipeline.