BookTranslator
BookTranslator

Japanische OCR für vertikalen Text: Spaltenreihenfolge beibehalten und Furigana handhaben

Extrahieren Sie japanischen vertikalen Text mit den richtigen Layouteinstellungen, trennen Sie Furigana vom Fließtext und überprüfen Sie echte OCR-Ergebnisse anhand herunterladbarer Beispiele.

BookTranslator

BookTranslator Team

13 min read

Überprüfen Sie bei der OCR für japanischen vertikalen Text die Schreibrichtung, bevor Sie Bildfilter ändern. Verwenden Sie ein japanisches Modell und eine Segmentierungseinstellung, die vertikalen Text verarbeiten können, überprüfen Sie die Spalten in ihrer beabsichtigten Reihenfolge und entscheiden Sie, ob Sie nur den Haupttext oder auch die Furigana benötigen. Eine Seite voller erkennbarer Zeichen kann immer noch eine unbrauchbare Transkription sein, wenn deren Reihenfolge falsch ist.

Wir haben ein kleines, reproduzierbares lokales Experiment durchgeführt, um diese Entscheidungen zu konkretisieren. Eine horizontale Konfiguration hat unsere drei vertikalen Spalten durcheinandergebracht. Eine vertikale Konfiguration hat den reinen Fließtext wiederhergestellt, aber das Hinzufügen von Furigana hat zwei Satzzeichen verändert und das Herausschneiden der Ruby-Zeichen hat die Satzzeichenfehler nicht beseitigt.

Dies sind Ergebnisse aus einer bewusst kleinen synthetischen Stichprobe und kein Genauigkeitsanspruch für alle japanischen Bücher. Die nützliche Lektion ist enger gefasst: Bewerten Sie Zeichenerkennung, Leserichtung und die Behandlung von Annotationen getrennt. Senden Sie das Ergebnis nicht einfach zur Übersetzung, nur weil es wie Japanisch aussieht.

Identifizieren Sie zuerst den Text, den Sie tatsächlich wollen

In der konventionellen japanischen vertikalen Komposition verlaufen Zeichen eine Zeile nach unten und Zeilen von rechts nach links. Ruby ist der kleinere Text, der mit Basiszeichen verbunden ist; Furigana liefert häufig deren Aussprache. Die W3C-Requirements for Japanese Text Layout beschreibt diese Schreibrichtungen und Ruby-Beziehungen.

Beschriften Sie vor der OCR die bedeutsamen Bereiche der Seite:

  • vertikale Hauptspalten;
  • kleine Ruby-Zeichen neben dem Fließtext;
  • horizontale Überschriften, Bildunterschriften oder Tabellen;
  • Seitenzahlen und Kolumnentitel;
  • Randnotizen oder nicht zusammenhängende benachbarte Seiten.

Behandeln Sie nicht jeden vertikalen Streifen als unabhängigen Absatz. Ein Streifen aus kleinen Kana neben 図書館 ist möglicherweise deren Lesung, としょかん, und nicht der nächste Satz.

Wählen Sie die Ausgaberichtlinie, bevor Sie die OCR bewerten:

Aufgabe des LesersGewünschtes ErgebnisWas als Problem gilt
Text im Haupttext suchen oder übersetzenHaupttext in der richtigen Reihenfolge; nützliche Lesungen separat gespeichertRuby in Fließtext eingefügt, ausgelassener Haupttext, neu geordnete Spalten
Aussprache lernenHaupttext plus korrekt zugeordnete LesungenFehlendes Ruby oder eine Lesung, die dem falschen Wort zugeordnet ist
Eine getreue Transkription erstellenHaupttext, Annotationsbeziehungen und redaktionelle Entscheidungen beibehaltenStille Löschung oder Normalisierung von Material, das Sie behalten wollten

Dasselbe Ergebnis kann die eine Aufgabe bestehen und bei einer anderen scheitern. Unser Experiment verwendet rein auf den Haupttext beschränkte Transkription als Vergleichsziel. Es betrachtet fehlendes Furigana nicht als akzeptabel für eine Ausgabe zum Zweck des Aussprachestudiums.

Ein echtes OCR-Experiment mit drei Sätzen

Das Beispiel verwendet diese selbst verfassten Sätze:

朝の図書館で本を読む。
古い地図には川が見える。
明日は友人と駅で会う。

Sie beschreiben das Lesen in einer Bibliothek, das Sehen eines Flusses auf einer alten Karte und das Treffen eines Freundes an einem Bahnhof. Wenn die Zeilenumbrüche entfernt werden, gibt es 34 Unicode-Codepunkte im Haupttext, einschließlich der drei japanischen Satzzeichen.

Wir haben denselben Haupttext in drei Formen gerendert:

  1. Horizontaler Text.
  2. Drei vertikale Spalten, von rechts nach links gelesen.
  3. Dieselbe vertikale Spalten mit Furigana neben 図書館, 地図, 友人, und 駅.

Synthetisches japanisches OCR-Beispiel mit drei vertikalen Spalten, die von rechts nach links gelesen werden, und kleinerem Furigana rechts von ausgewählten Wörtern.

Dies sind saubere Lehrmotive, keine gescannten Buchseiten. Der Renderer verwendet Noto Sans CJK JP, Haupttextzeichen mit 64 Pixeln, Ruby mit 24 Pixeln und eine vereinfachte zeichenweise vertikale Platzierung. Er zeichnet vertikale Satzzeichen als kleine umrandete Kreise an manuell gewählten Positionen, anstatt die korrekte vertikale Glyphenplatzierung der Schriftart zu verwenden; die Ergebnisse der Interpunktion zeigen daher nicht, wie OCR bei einem korrekt gesetzten Buch abschneidet. Jede japanische Satzregel wird nicht reproduziert. Es gibt weder Unschärfe, Verzerrung, Papierstruktur, Handschrift, historischen Satz noch Seiten mit gemischter Richtung im Test.

Engine, Modelle und Einstellungen

Das Experiment wurde am 7. September 2026 unter Verwendung von Tesseract.js 7.0.0 mit Tesseract.js-core 7.0.0 lokal auf macOS ARM64 durchgeführt. Alle erfolgreichen Aufrufe verwendeten die offizielle tessdata_fast Modelle bei Commit 87416418657359cb625c412a48b6e1d6d41c29bd, mit OEM 1, dem reinen LSTM-Engine-Modus.

Das offizielle Modell-Repository von Tesseract stellt separate jpn und jpn_vert Dateien zur Verfügung. Die Dokumentation beschreibt PSM 5 als einen einheitlichen vertikal ausgerichteten Block und PSM 6 als einen einheitlichen Textblock; wählen Sie eine Segmentierungsannahme, die zu der zu erkennenden Region passt. Siehe die Dokumentation zur Seitensegmentierung.

Unsere aufgezeichneten Fälle verwendeten jpn mit PSM 6 für horizontalen Text, jpn_vert mit PSM 5 für vertikalen Text sowie eine absichtlich nicht übereinstimmende jpn/PSM 6 Vertikalkontrolle. Sowohl das Modell als auch die Segmentierung ändern sich zwischen den beiden vertikalen Konfigurationen, daher handelt es sich hierbei um einen Workflow-Vergleich und nicht um ein Experiment, das die Wirkung der einzelnen Einstellungen isoliert.

Ein erster Versuch mit tessdata_best wurde im verfügbaren WebAssembly-Kern abgebrochen, bevor OCR-Text erzeugt wurde. Wir sind zur Kompatibilität auf die offiziellen Ganzzahl- tessdata_fast Modelle gewechselt und haben diesen Fehlschlag aufgezeichnet. Aus diesem Wechsel lässt sich kein Schluss auf die Genauigkeit einer Modellfamilie ziehen.

Was tatsächlich zurückkam

Der Vergleich entfernt Leerzeichen und wendet die Unicode-NFC-Normalisierung an. Er ersetzt nicht Satzzeichen, korrigiert Kanji oder ordnet Text neu an. Die vollständigen Rohausgaben und Versions-/Modell-Hashes, Body-Vergleichs-CSV, und Fehlerannotationen sind herunterladbar.

Eingabe und KonfigurationBeobachtetes Ergebnis im Vergleich zum reinen Text-Ziel
Horizontal, jpn, PSM 6Alle 34 Codepunkte stimmten nach dem Entfernen der Leerzeichen überein
Vertikal, jpn, PSM 6-KontrolleDie Ausgabe lief über Spalten hinweg und enthielt Zeichenersetzungen; kein brauchbarer Text
Vertikal, jpn_vert, PSM 5Alle 34 Codepunkte stimmten nach dem Entfernen der Leerzeichen überein; die Spaltenreihenfolge war korrekt
Vertikal mit Furigana, jpn_vert, PSM 5Der Haupttext blieb in der richtigen Reihenfolge, aber zwei 。-Zeichen wurden zu ASCII-.; Ruby wurde nicht als separate Lesung zurückgegeben
Drei Ausschnitte von Textspalten aus dem Furigana-Bild, jpn_vert, PSM 5Die erste Spalte endete mit ., die zweite mit ,, die dritte mit 。; das Zuschneiden hat nicht alle Interpunktionsfehler behoben

Zum Beispiel lieferte der Furigana-Fall diese erste Zeile:

Expected: 朝の図書館で本を読む。
Observed: 朝 の 図書 館 で 本 を 読む .

Die Leerzeichen werden von unserer genannten Vergleichsregel ignoriert. Die finale Interpunktion hingegen nicht. Ein reiner Suchworkflow mag diesen Unterschied tolerieren, aber eine getreue Transkription sollte ihn erfassen und korrigieren.

Die nicht übereinstimmende vertikale Steuerung begann mit 明 古 昌, und sprang dabei über die obersten Zeichen der Spalten hinweg, anstatt dem beabsichtigten ersten Satz zu folgen. Ihre Ausgabe verdeutlicht, warum das Erkennen einzelner Symbole nicht dasselbe ist wie das Rekonstruieren einer Lesereihenfolge.

Es gab sieben abgeschlossene OCR-Aufrufe: vier Ganzbild-Fälle und drei Ausschnitte. Wir haben jede Ausgabe behalten. Ein Agent verglich die Ergebnisse mit der erstellten Ground Truth und inspizierte die Bilder visuell; es gab keine verblindete menschliche Überprüfung oder ein breites Benchmark-Korpus. Das Experiment stellt weder eine universell beste Engine noch eine buchweite Genauigkeitsrate oder die Leistung auf Ihrem Scan fest.

Verwenden Sie einen regionsbasierten Workflow auf Ihrer eigenen Seite

1. Bewahren Sie das Original und wählen Sie eine schwierige Seite aus

Lassen Sie das Originalbild oder die PDF unverändert. Arbeiten Sie an einer Kopie und protokollieren Sie die Seitenzummer. Wählen Sie eine Seite aus, die das Problem enthält, das Sie lösen möchten: dichte Ruby-Schrift, einen schmalen Bundsteg, eine horizontale Überschrift über vertikalem Text oder ungewöhnlich kleine Schrift.

Eine saubere Titelseite ist kein nützlicher Abnahmetest für ein Buch, dessen Textseiten ein anderes Layout aufweisen. Wenn es sich bei der Quelle um eine PDF handelt, extrahieren oder rendern Sie die ausgewählte Seite vor der Ausführung eines rein bildbasierten OCR-Workflows mit einem Werkzeug, dem Sie vertrauen. Die Skripte dieses Artikels akzeptieren PNG-Dateien; sie verarbeiten keine PDFs oder erstellen durchsuchbare PDF-Ebenen.

Für den vollständigen Prozess der Vorbereitung und Übersetzung gescannter Dokumente verwenden Sie den umfassenderen Workflow für gescannte PDFs. Dieser Leitfaden konzentriert sich auf japanische Schreibrichtung, Segmentierung, Ruby-Schrift und Transkriptionsentscheidungen.

2. Korrigieren Sie Aufnahmefehler, ohne kleinen Text zu zerstören

Inspizieren Sie die tatsächlichen Zeichen bei einer sinnvollen Zoomstufe. Begradigen Sie unbeabsichtigte Schräglagen, entfernen Sie zusammenhanglose Seitenränder und bewahren Sie genügend Kontrast, um kleine Kana und Interpunktion zu unterscheiden. Vermeiden Sie es, aggressive Schwellenwertbestimmungen oder Schärfungen als automatische Verbesserung zu behandeln: Vergleichen Sie das resultierende Bild vor dem Vertrauen in die OCR mit dem Original.

Tesseracts Leitfaden zur Bildqualität behandelt Auflösung, Rauschen, Schräglage und Ränder. Diese sind von der Schreibrichtung getrennt. Das Ausrichten einer in einem Winkel fotografierten Seite ist nicht derselbe Vorgang wie das seitliche Drehen von aufrechtem, vertikalem japanischem Text.

Die Beispieldateien enthalten 300-DPI-Metadaten, aber diese Zahl erzeugt keine fehlenden Details. Ihre tatsächliche Textglyphengröße beträgt 64 Pixel. Ein Foto mit niedriger Auflösung, das in „300 dpi“ umbenannt wurde, bleibt dasselbe Foto mit niedriger Auflösung.

3. Trennen Sie Regionen, wenn die Seite eine Layout-Annahme verletzt

Probieren Sie den vertikalen Hauptblock einzeln aus, bevor Sie von einem einzigen OCR-Aufrufe verlangen, einen horizontalen Titel, vertikale Prosa, eine Abbildung und eine Seitenzummer gleichzeitig zu verarbeiten. Führen Sie ein einfaches Regionsprotokoll wie „Seite 12, Text, Spalte 1 von rechts“. Dieses Protokoll macht die spätere Zusammenstellung nachvollziehbar.

Erkennen Sie bei Material mit gemischter Richtung die horizontale Region mit der entsprechenden horizontalen Einstellung und die vertikale Region mit einer vertikalen Einstellung und fügen Sie sie dann in der vom Dokument beabsichtigten Reihenfolge zusammen. Dies ist ein empfohlener Workflow zum Testen an Ihrer Datei, keine Fähigkeit für gemischte Layouts, die anhand unserer drei Beispielbilder gemessen wurde.

Unser Ausschnitt-Experiment verwendete exakte, bekannte Koordinaten, um den Ruby-Streifen neben jeder synthetischen Spalte auszuschließen, während der Text und ein weißer Rand erhalten blieben. Es war eine Demonstration der manuellen Regionenauswahl und kein automatischer Algorithmus zum Entfernen von Furigana. Wenden Sie dessen Koordinaten nicht auf eine echte Buchseite an.

4. Überprüfen Sie die Spalten vor dem Korrekturlesen einzelner Zeichen

Vergleichen Sie das erste und letzte Textzeichen jeder Spalte in der beabsichtigten Richtung. Vergewissern Sie sich, dass keine Spalte fehlt, dupliziert, umgekehrt oder mit ihrem Nachbarn vermischt ist. Inspizieren Sie anschließend Sätze an den Spaltengrenzen.

Erst danach solltest du einzelne Kanji, Kana, Satzzeichen, Zahlen und Namen korrigieren. Andernfalls verschwendest du Zeit damit, Fragmente zu polieren, die in den falschen Absatz einsortiert wurden.

Eine sinnvolle dreistufige Überprüfung besteht aus:

  1. Regionen und Reihenfolge: jede beabsichtigte Textregion ist einmal und in der richtigen Reihenfolge vorhanden.
  2. Zeichen: vergleiche das tatsächliche Bild mit dem Text, einschließlich kleiner Satzzeichen und Kana-Zeichen.
  3. Anmerkungen: entscheide, ob jedes Ruby-Element, jede Notiz oder jedes Randlabel beibehalten, getrennt oder bewusst ausgeschlossen wird.

Der Konfidenzwert einer Engine ist kein Ersatz für diese Prüfungen. Unser durcheinandergewierbelter Kontrolltext lieferte dennoch eine von der Engine gemeldete Konfidenzzahl; das machte seine Leserichtung keineswegs akzeptabel.

Entferne Furigana erst, wenn du den Grund dafür kennst

Für eine reine Textextraktion sollte Ruby nicht versehentlich zu einer zweiten Prosa-Ebene werden. Das Löschen jeder kleinen Kana-Zeichenkette ist jedoch keine sichere allgemeine Regel. Eine Lesart kann dabei helfen, einen Namen zu disambiguieren, die vom Autor gewählte Aussprache zu bewahren oder die Lernaufgabe des Lesers zu unterstützen.

In unserem Furigana-Bild enthielt die OCR-Ausgabe zwar die Haupt-Kanji, lieferte die vier Lesarten jedoch nicht als separaten Anmerkungssatz zurück. Das könnte nach einer Satzzeichenkorrektur für eine reine Textsuchaufgabe ausreichen. Es reicht jedoch nicht aus, wenn das Ergebnis Ausspracheinformationen verspricht.

Speichere wichtige Lesarten separat und ordne sie dem jeweiligen Vorkommen zu. Zum Beispiel:

Page: sample 1
Column: 1 from the right
Base text: 図書館
Reading shown: としょかん
Decision: retain body text; save reading in the annotation record

Die separate Ruby-Transkription des Beispiels macht diese Richtlinie explizit. Sie stellt Ground Truth dar, die zusammen mit dem Bild erstellt wurde, und ist keine erfolgreiche OCR-Behauptung.

Wenn die OCR Kana in ein Wort mischt oder die Zuordnung verliert, vergleiche das Ergebnis mit dem Bild und korrigiere die Transkription. Bitte kein Sprachmodell darum, die Quelle zu raten und die Vermutung als wiederhergestellten Text auszugeben. Markiere eine unsichere Lesart stattdessen zur Überprüfung.

Die Ausschnittergebnisse sprechen zudem gegen die vereinfachende Regel „Ruby entfernen und alles wird besser“: Es verblieben zwei Unterschiede bei den Satzzeichen, und die betroffenen Satzenden veränderten sich. Diese Beobachtung gilt für diese spezifische saubere Testumgebung. Sie lehrt uns, das Ergebnis nach der Segmentierung zu überprüfen, bedeutet jedoch nicht, dass ein Zuschnitt OCR-Vorgänge generell verbessert oder verschlechtert.

Den Test reproduzieren oder ein Prüfungsprotokoll führen

Lade das Experiment-README herunter, um fixierte Modell- und Schriftartenquellen, Abhängigkeitsversionen, Dateibeschreibungen und Befehle einzusehen. Der Beispielgenerator, OCR-Runnerund Skript zum Vergleich trennt die Erstellung von Bildern, die Texterkennung und die Auswertung.

Der Runner verwendet die dokumentierte Tesseract.js-Worker-API. Für einen vertikalen Bereich sind die wesentlichen Einstellungen:

const worker = await createWorker("jpn_vert", 1, {
  langPath: modelDirectory,
  gzip: false,
  cacheMethod: "none",
});
await worker.setParameters({
  tessedit_pageseg_mode: "5",
  user_defined_dpi: "300",
});

modelDirectory muss die heruntergeladene, unkomprimierte jpn_vert.traineddata Datei enthalten. Dies ist ein Ausschnitt und nicht das vollständige Programm; der bereitgestellte Runner speichert zudem die Rohergebnisse und beendet die Worker.

Wenn Sie eine andere OCR-Anwendung verwenden, behalten Sie dieselben Nachweise bei, selbst wenn sich die Namen der Einstellungen unterscheiden: Quellbereich, Originaldatei, Modell- oder Tool-Version, Richtung, Segmentierungsauswahl, tatsächliche Ausgabe, korrigierter Text und nicht aufgelöste Zeichen. Die Review-Protokoll-Vorlage ist leer, damit nicht der Eindruck entsteht, Ihre Seiten hätten bereits bestanden.

Verwandeln Sie unser winziges Exakt-Match-Ergebnis nicht in ein versprochenes Prozentziel für einen ganzen Roman. Verschiedene Schriftarten, gedrängte Spalten, historische Formen, Scans von geringer Qualität und Manga-Sprechblasen erfordern eigene repräsentative Tests. Manga-Layouts und die Erkennung von Handschriften sind nicht Teil dieses Experiments.

Übersetzen Sie nur, wenn die wiederhergestellte Quelle vertrauenswürdig ist

Wenn Ihr Ziel in der Suche, dem Kopieren von Zitaten oder dem Nachschlagen in Wörterbüchern besteht, ist verifizierter japanischer Text möglicherweise das Endergebnis. Sie müssen ein Dokument nicht allein deshalb komplett übersetzen, weil OCR im Spiel war.

Wenn eine Sprachbarriere das Lesen weiterhin verhindert und Sie über eine verwendbare Datei verfügen, die Sie hochladen können, fahren Sie mit dem PDF-Übersetzungs-Workflow fort. Bewahren Sie den Originalscan und die überprüfte Transkription auf, damit Sie Erkennungsfehler von Übersetzungsfehlern unterscheiden können. Der Beispiel-Runner erzeugt Text- und TSV-Dateien, kein für den automatischen Upload fertiges PDF; bereiten Sie das eigentliche Eingabeformat vor, das Ihr nächstes Tool benötigt.

Der OCR-Modus von BookTranslator rekonstruiert übersetzte Inhalte, anstatt das ursprüngliche vertikale Layout zu garantieren. Gehen Sie nicht davon aus, dass er jede Ruby-Zuordnung beibehält oder nicht verifizierte Erkennungsfehler korrigiert. Überprüfen Sie die Leserichtung und Formatierung des finalen Dokuments mithilfe des Leitfadens zur PDF-Formatbeibehaltung und der finalen PDF-QS-Checkliste.

Die verlässliche Übergabe lautet nicht „OCR abgeschlossen.“ Sie lautet „der gewünschte japanische Text ist vorhanden, seine Reihenfolge wurde überprüft und der Umgang mit Anmerkungen ist dokumentiert.“

Verwandte Beiträge