日语竖排文本OCR：保留分栏顺序并处理假名注音

进行日语竖排文本OCR时，请在更改图像滤镜之前检查书写方向。使用能够处理竖排文本的日语模型和分词/分割设置，按预期的顺序验证分栏，并决定您需要纯正文还是连同假名注音一起提取。即使满页都是可识别的字符，如果其先后顺序错了，依然会变成无法使用的转录结果。

我们进行了一项小型且可复现的本地实验，使这些决策更加具体。横排配置打乱了我们的三个竖排分栏。竖排配置恢复了纯正文，但加上假名注音后改变了两个标点符号，而裁剪掉注音并未能消除标点错误。

这些结果来自一个刻意缩小的合成样本，并非针对所有日语书籍的准确率声明。有用的教训更为具体：应分别评估字符识别、阅读顺序和注释处理。 不要仅仅因为结果看起来像日语就将其发送去翻译。

首先确定您真正想要提取的文本

在传统的日语竖排版式中，字符自上而下逐行排列，行则由右向左推进。注音（Ruby）是与基础字符相关联的较小文本；假名注音通常提供其发音。W3C的日语文本排版需求文档 描述了这些书写方向与注音关系。

在进行OCR之前，请标记页面上有意义的区域：

• 主竖排分栏；
• 正文旁的小字注音；
• 横排标题、图注或表格；
• 页码和书眉；
• 边缘批注或不相关的相邻页面。

不要将每个竖条都当作独立的段落来对待。紧挨着図書館 的一小条假名としょかん 可能是它的读音，而不是下一句话。

在评判OCR之前，请先选择输出策略：

同样的输出可能在一个任务中通过，而在另一个任务中失败。我们的实验使用 仅正文转写 作为对比目标。对于发音学习版本，它不认为缺少注音假名是可以接受的。

一个真实的三个句子的 OCR 实验

该样本使用了以下自创的句子：

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

它们描述了在图书馆阅读、在旧地图上看到河流以及在车站与朋友见面。去除换行符后，共有 34 个正文文本 Unicode 码点，包括三个日文句号。

我们将同一正文渲染为三种形式：

1. 横排文本.
2. 三列竖排，从右向左阅读。
3. 带有注音假名的相同竖排列 旁边的 図書館, 地図, 友人，以及 駅.

这些是清晰的教学图像，而不是书中扫描的页面。渲染器使用了 Noto Sans CJK JP、64 像素的正文汉字、24 像素的注音以及简化的逐字竖排布局。它将竖排句号绘制为手动选定位置的小空心圆，而不是使用字体自身的正排字形定位；因此，标点符号的结果并不能确立 OCR 在正确排版的书籍上的表现。它并未复现所有的日语排版规则。测试中没有模糊、倾斜、纸张纹理、手写体、历史字体或混合方向的页面。

引擎、模型与设置

该实验于 2026 年 9 月 7 日在 macOS ARM64 本地环境使用 Tesseract.js 7.0.0 及 Tesseract.js-core 7.0.0 进行。所有成功的调用均使用了官方的 tessdata_fast 模型，提交版本为 87416418657359cb625c412a48b6e1d6d41c29bd，并启用了 OEM 1（仅 LSTM 引擎模式）。

Tesseract 的官方模型仓库提供了独立的 jpn 和 jpn_vert 文件。其文档将 PSM 5 描述为垂直对齐的均匀文本块，将 PSM 6 描述为均匀文本块；请选择适合待识别区域的分段假设。请参阅 页面分段文档.

我们记录的案例在处理水平文本时使用了带有 PSM 6 的 jpn，在处理垂直文本时使用了带有 PSM 5 的 jpn_vert，以及一个故意不匹配的 jpn/PSM 6 垂直对照组。由于这两种垂直配置既改变了模型又改变了分段方式，因此这是一项工作流比较实验，而非孤立探究任一设置影响的实验。

最初尝试使用 tessdata_best 时，在生成 OCR 文本之前便在可用的 WebAssembly 核心中中断了。为了兼容性，我们切换到了官方的整型 tessdata_fast 模型并记录了该失败情况。不能根据该切换得出关于某一模型系列准确性的任何结论。

实际返回的结果

该比较移除了空白字符并应用了 Unicode NFC 规范化。它不会替换标点符号、纠正汉字或重新排列文本。完整的原始输出与版本/模型哈希值, 主体比较 CSV以及错误批注 是可以下载的。

例如，振假名案例返回了如下第一行：

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

我们规定的比较规则忽略了这些空格，但不会忽略最终的标点符号。纯搜索工作流程可能会容忍这种差异，但忠实的转写应当对其进行记录和修正。

不匹配的垂直控制始于 明 古 昌，它跨越了各列顶部字符，而不是遵循预期的第一句。其输出说明了识别单个符号并不等于重建阅读顺序。

共有七次完整的 OCR 调用：四次全图案例和三次局部裁剪。我们保留了每一个输出。一位代理将结果与人工编写的标准答案进行了对比，并对图像进行了视觉检查；其中没有盲法人工审查或广泛的基准语料库。该实验并未确定普遍最佳的引擎、书本级的准确率，也没有评估在您的扫描件上的性能。

在您自己的页面上使用区域优先的工作流程

1. 保留源文件并选择一个困难页面

保持原始图像或 PDF 不变。在副本上操作，并记录页码。选择一个包含您试图解决的问题的页面：密集的注音（ruby）、狭窄的栏间距、垂直文本上方的水平标题，或异常小的字号。

对于正文页面布局不同的书籍，干净的标题页并不是一个有用的验收测试。如果源文件是 PDF，请在运行仅图像的 OCR 工作流程之前，使用您信任的工具提取或渲染所选页面。本文的脚本接受 PNG 文件；它们不处理 PDF 或构建可搜索的 PDF 层。

有关完整的扫描文档准备和翻译流程，请使用更广泛的 扫描 PDF 工作流程。本指南重点介绍日语书写方向、分词、注音（ruby）和转写决策。

2. 纠正捕获缺陷而不破坏小字

在有用的缩放级别检查实际字符。拉直无意的倾斜，移除不相关的页面边距，并保持足够的对比度以区分小假名和标点符号。避免将激进的阈值处理或锐化视为自动改进：在信任 OCR 之前，将生成的图像与原图进行比较。

Tesseract 的 图像质量指南 涵盖了分辨率、噪点、倾斜和边距。这些与书写方向是分开的。对以一定角度拍摄的页面进行纠偏，与将正立的竖排日语文本横向旋转并不是同一个操作。

示例文件带有 300 dpi 元数据，但该数字并不会创造丢失的细节。它们实际的正文图符大小为 64 像素。重新标记为“300 dpi”的低分辨率照片依然是同一张低分辨率照片。

3. 当页面违反某个布局假设时进行区域分离

在要求单次 OCR 调用处理水平标题、垂直正文、插图和页码之前，先单独尝试主要的垂直块。保留简单的区域记录，例如“第 12 页，正文，从右数第 1 列”。该记录使后续的拼接具有可审计性。

对于混排方向的材料，使用适当的水平设置识别水平区域，使用垂直设置识别垂直区域，然后按照文档预期的顺序进行组装。这是建议在您的文件上进行测试的工作流程，而不是由我们的三个示例图像所衡量的混排布局功能.

我们的裁剪实验使用了精确的已知坐标，以排除每个合成列旁边的注音（ruby）条，同时保留其正文文本和白色边距。这是一次手动区域选择演示，而不是自动的日文假名去除算法。请勿将其坐标应用于真实的书籍页面。

4. 在校对单个字符之前检查列

按预期的方向，比较每一列的第一和最后一个正文字符。确认没有遗漏、重复、颠倒或与相邻列混淆的列。然后检查列边界处的句子。

只有在此之后，您才应该校对单个汉字、假名、标点符号、数字和名称。否则，您可能会把时间浪费在润色那些被组合到错误段落中的片段上。

一个实用的三轮复查流程是：

1. 区域与顺序： 确保每个预期的正文区域都出现且仅出现一次，并且顺序正确。
2. 字符： 将实际图像与文本进行对比，包括小型的标点符号和假名标记。
3. 注释： 决定每个注音假名（ruby）、注释或页边标签是予以保留、分离，还是故意排除。

引擎的置信度值并不能替代这些检查。我们的乱序对照测试仍然返回了一个引擎报告的置信度数值，但这并未使其阅读顺序变得可以接受。

在弄清楚原因之前，切勿移除注音假名

对于纯正文提取，注音假名不应意外变成第二层散文。但删除每一个小型假名字符串并不是一条安全的通用规则。注音有助于消除名字的歧义、保留作者选择的发音，或支持读者的学习任务。

在我们注音假名的图像中，OCR 输出包含了主要汉字，但没有将四个读音作为单独的注释集返回。对于纯正文搜索任务来说，这在标点符号校正后可能就足够了。但如果交付成果承诺提供发音信息，这就远远不够了。

应将重要的读音单独存储，并将其与正确的位置关联起来。例如：

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

示例的独立注音转写 使该策略变得明确。这是随图像一同创建的基准真相，而不是 OCR 成功的声明。

如果 OCR 将假名混入单词中或丢失了关联，请对照图像进行修复并修正转写。不要要求大语言模型去猜测来源，并将猜测当作恢复的文本呈现。对于不确定的读音，应标记以便复查。

裁剪结果也反驳了“去掉注音假名，一切都会变好”这种简单化的规则：仍有两个标点符号存在差异，受影响的句尾也发生了变化。这一观察结果仅适用于这个特定的干净测试装置。它告诉我们要在分割后验证结果，而不是裁剪通常对 OCR 有益或有害。

复现测试或保留复查日志

下载实验 README 以获取固定的模型和字体来源、依赖项版本、文件说明以及命令。样本生成器, OCR 运行程序，以及对比脚本 分别进行图像创建、识别和评估。

运行程序使用了有文档记录的 Tesseract.js worker API。对于垂直区域，其关键设置为：

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 必须包含已下载且解压的 jpn_vert.traineddata 文件。这是一个片段，而非完整程序；提供的运行程序还会保存原始结果并终止 worker。

如果您使用其他 OCR 应用程序，即使设置名称不同，也请保留相同的凭证：源区域、原始文件、模型或工具版本、方向、分段选择、实际输出、校正文本和未解析字符。复查日志模板 是空白的，因此它并不意味着您的页面已经通过验证。

不要将我们微小的精确匹配结果转化为对整部小说的承诺百分比。不同的字体、拥挤的栏目、历史字体、低质量扫描件以及漫画对话框都需要各自具有代表性的测试。漫画排版和手写识别不在本实验范围内。

仅在恢复的来源可靠时进行翻译

如果您的目标是搜索、复制引文或查字典，经过验证的日语文本可能就是最终结果。您无需仅仅因为涉及 OCR 就翻译整篇文档。

如果语言障碍仍然妨碍阅读，且您拥有可上传的可用文件，请继续使用 PDF 翻译工作流。请保留原始扫描件和核对过的转录文本，以便您区分识别错误与翻译错误。示例运行程序生成的是文本和 TSV 文件，而不是可供自动上传的 PDF；请准备好下一个工具所需的实际输入格式。

BookTranslator 的 OCR 模式会重建翻译内容，而不是保证原始的垂直排版。请不要假设它会保留每个注音关联或修复未经验证的识别错误。使用 PDF 格式保留指南 和 最终 PDF 质量保证检查清单.

可靠的交接不是“OCR 已完成”，而是“所需的日语文本已存在，其顺序已核对，注释的处理方式已记录。”