OCR PDF引擎是围绕从左到右的文本流构建的。当您向它们提供以从右到左的脚本（例如阿拉伯语、希伯来语、波斯语或乌尔都语）编写的文档时，引擎必须检测脚本方向，以正确的视觉和逻辑顺序识别字符，并输出以目标语言自然阅读的文本。如果其中一个步骤出错，就会产生技术上可识别但功能上无法使用的文本：单词向后拼写、句子从末尾开始以及数字出现在周围文本的错误一侧。
针对从右到左语言的正确 OCR 需要选择明确支持目标脚本的 OCR 引擎，使用正确的语言参数对其进行配置，并通过双向文本感知工具验证输出。对于从左到右的语言，该过程并不比 OCR 困难，但许多用户跳过的配置步骤（告诉引擎需要哪种语言）对于从右到左的脚本来说不是可选的。保留默认设置（通常是英语）的引擎将从阿拉伯语或希伯来语文档中产生无意义的输出。
WukongPDF 的扫描 PDF OCR 工具支持多种语言，包括从右到左的脚本。在运行 OCR 之前选择正确的语言是提取可用文本和生成字符噪声之间的区别。
为什么从右到左 OCR 在没有显式配置的情况下会失败
OCR 引擎分析形状并将其映射到指定语言字符集中的字符。当引擎需要英语时，它会将形状解释为拉丁字母。 B 的阿拉伯字母在许多字体中看起来与拉丁字母 B 有点相似，但 Ayn 的阿拉伯字母没有对应的拉丁字母。英语模式下的引擎遇到 Ayn 时会输出随机标点符号或完全跳过该字符。在整个文档中，这种逐字符的错误识别会产生与原始文本没有任何关系的输出。
即使选择了正确的脚本，文本方向也会带来第二层复杂性。默认情况下，OCR 引擎从左到右处理图像，从左边缘到右边缘跨过每行像素。从右到左的文档应该从右到左处理，以便引擎按照写入的顺序读取字符。如果引擎不反转从右到左脚本的处理方向，则识别的字符在每个单词中将按相反顺序排列。设置语言参数后，某些引擎会自动处理方向反转。其他则需要明确的文本方向标志。
为从右到左的 OCR 配置 Tesseract
Tesseract 是开源 OCR 引擎，通过特定于语言的数据文件支持阿拉伯语、希伯来语、波斯语、乌尔都语和其他几种从右到左的脚本。安装目标脚本的语言数据。在 Linux 上，该软件包通常命名为 tesseract-ocr-ara（阿拉伯语）或 tesseract-ocr-heb（希伯来语）。在 Windows 上，从 Tesseract GitHub 存储库下载经过训练的数据文件并将其放置在 tessdata 目录中。
运行 Tesseract，并将语言标志设置为正确的脚本：tesseract input.pdf 输出 -l ara 表示阿拉伯语，-l heb 表示希伯来语，或 -l ara+eng 表示阿拉伯语-英语双语文档。当语言参数指定从右到左的脚本时，Tesseract 会自动处理文本方向。识别的文本输出保留正确的阅读顺序。要进行验证，请打开输出文本文件并确认单词以预期方向读取并且句子从右向左排列。
对于具有混合脚本的文档，例如包含英语技术术语的阿拉伯语研究论文，请指定用加号分隔的两种语言：-l ara+eng。 Tesseract 以每个单词为基础在语言模型之间切换，将阿拉伯语模型应用于阿拉伯语脚本单词，将英语模型应用于拉丁语脚本单词。每个单词的切换并不完美，特别是对于可能属于任一脚本的短单词，但它足以处理大多数混合脚本文档。
使用 Google Cloud Vision 进行自动检测
Google Cloud Vision 的 OCR 功能包括自动语言检测，当您不确定确切的语言或文档包含多种从右到左的语言时，这对于从右到左的脚本特别有用。 API 接受文档图像并返回识别的文本，其中包含每个单词的边界框、每个文本块检测到的语言以及文本方向。对于从右到左的脚本，返回的文本已经是正确的阅读顺序。
Cloud Vision 的阿拉伯语和希伯来语识别质量通常高于 Tesseract，因为底层模型是在更大、更多样化的数据集上进行训练的。代价是文档图像必须上传到 Google 的服务器进行处理，这对于敏感或机密文档来说可能是不可接受的。对于公开文档或批准云处理的内部文档，Cloud Vision 提供最准确的从右到左 OCR，无需购买专门的桌面 OCR 软件。
| 语言 | OCR引擎支持 | 准确度注释 |
|---|---|---|
| 阿拉伯 | Tesseract、谷歌云视觉、ABBYY | 变音符号可能会被删除，连字处理有所不同 |
| 希伯来语 | Tesseract、谷歌云视觉、ABBYY | Nikud 元音点在 OCR 过程中经常丢失 |
| 波斯语/乌尔都语 | Tesseract、谷歌云视觉 | Nastaliq 脚本变体挑战大多数引擎 |
验证从右到左文本的 OCR 输出
OCR 后，在支持双向文本渲染的文本编辑器中打开识别的文本，例如启用了双向插件的 Notepad++ 或安装了 RTL 语言包的 Visual Studio Code。如果实现了 Unicode 双向算法，假设从左到右文本的标准文本编辑器可以正确显示从右到左的文本，但行尾的标点符号以及文本中数字的相对顺序是常见的故障点。具有显式双向支持的文本编辑器以母语人士期望阅读的方式显示文本。
根据原始扫描文档在三个级别对输出进行抽查：单个单词，特别是包含变音符号或连字的单词；完整的句子，确认词序在目标语言中自然地读起来；以及数字和日期，确认它们出现在周围文本的正确一侧。每个单词都被正确识别但每个句子中的单词顺序相反的文档与根本没有单词被识别的文档一样无法用于翻译或搜索。
当设置正确的语言参数时，从右到左语言的 OCR 是一个已解决的技术问题。最重要的一步是告诉引擎需要什么脚本。该决定的下游一切，从识别准确性到阅读顺序再到混合脚本处理，都取决于正确的语言配置。配置语言参数并打开双向文本编辑器进行验证后，从右到左的语言文档的 OCR 不需要比任何其他语言的 OCR 花费更多的时间或精力。
从右到左语言文本的 OCR 后翻译
准确识别文本后，翻译从右到左的语言内容需要一个能够正确处理双向文本的翻译引擎。 Google Translate 和 DeepL 都支持阿拉伯语、希伯来语和波斯语。将识别出的文本粘贴到翻译界面中，并确认源语言被正确识别。翻译引擎检测脚本方向并将其保留在输出中。对于翻译将由母语人士审阅的文档，将原始识别文本和翻译文本并排导出到两列表中，以便进行有效比较。
从右到左语言的机器翻译通常不如从左到右欧洲语言之间的翻译准确，因为许多从右到左语言对的训练数据较小。对于重要文档，请先让母语人士审阅翻译，然后再对其内容采取行动。 OCR 步骤可生成准确的源文本。翻译步骤增加了一层解释。将 OCR 输出视为文档内容的基本事实，将机器翻译视为其含义的指南，并进行验证。
批处理从右到左语言 PDF
当您有一个从右到左语言的 PDF 到 OCR 的文件夹时，Tesseract 的命令行界面接受批量输入。单个 shell 命令可以处理每个 PDF： for f in *.pdf;做 tesseract $f ${f%.pdf} -l ara;完毕。该命令循环遍历所有 PDF，使用阿拉伯语模型运行 OCR，并使用匹配的基本文件名将识别的文本与每个 PDF 一起保存。
对于混合语言批次，请在 OCR 之前使用语言检测步骤。带有 langdetect 库的 Python 脚本对文本的第一页进行采样以预测语言。根据预测，脚本选择适当的 Tesseract 语言参数并运行 OCR。自动语言检测消除了在批处理之前按语言对 PDF 进行手动排序的情况。从右到左语言的批量 OCR 将繁琐的每个文档过程转换为单个命令，无论输入文件夹中有多少文档，该命令都可以在几分钟内完成。
从右到左语言的 OCR 并不是需要特殊工具的特殊情况。它需要与从左到右 OCR 相同的工具，并配置正确的语言参数。许多用户跳过的配置步骤是因为他们认为 OCR 默认值可以工作，这是可用的提取文本和完整字符噪声之间的全部区别。设置语言标志，运行 OCR，在双向文本编辑器中验证输出，整个过程就完成了。从右到左脚本的 OCR 奖励那些花时间正确配置语言参数并验证双向文本编辑器中的输出的用户，从文档中生成准确、可用的文本，否则任何不阅读源语言的人都无法访问这些文本。