我一直在尝试编写一个简单的控制台应用程序或 PowerShell 脚本来从大量 PDF 文档中提取文本。有几个库和 CLI 工具可以做到这一点,但事实证明,没有一个能够可靠地识别文档结构。我特别关心文本列的识别。即使是非常昂贵的 PDFLib TET 工具也经常混淆相邻两列文本的内容。
经常注意到 PDF 格式没有任何列的概念,甚至没有单词。SO上类似问题的几个答案提到了这一点。这个问题是如此之大,以至于它甚至值得学术研究。这篇期刊文章指出:
PDF 文件中的所有数据对象都以面向视觉的方式表示,作为一系列运算符...通常不传达有关更高级别文本单元(如标记、行或列)的信息——有关此类单元之间边界的信息只能通过空格隐式使用
因此,我尝试过的所有提取工具(iTextSharp、PDFLib TET 和 Python PDFMiner)都无法识别文本列边界。在这些工具中,PDFLib TET 表现最好。
然而,SumatraPDF 是一款非常轻量级的开源 PDF 阅读器,以及许多其他类似的工具,可以完美地识别列和文本区域。如果我在其中一个应用程序中打开文档,选择页面上的所有文本(甚至使用 CTRL+A 选择整个文档),将其复制并粘贴到文本文件中,文本将以正确的顺序呈现,几乎完美无瑕。它偶尔会将页脚和页眉文本混合到其中一列中。
所以我的问题是,这些应用程序如何才能完成看似如此困难的事情(即使对于 PDFLib 等昂贵的工具)?
编辑 2014 年 3 月 31 日:值得一提的是,我发现 PDFBox 在文本提取方面比 iTextSharp 好得多(尽管有定制的策略实施),而且 PDFLib TET 比 PDFBox 略好,但它相当昂贵。Python PDFMiner 是无望的。我见过的最好的结果来自谷歌。可以将 PDF(一次 2GB)上传到 Google Drive,然后以文本形式下载。这就是我正在做的事情。我编写了一个小实用程序,可以将我的 PDF 拆分为 10 页文件(Google 只会转换前 10 页),然后在下载后将它们缝合在一起。
编辑 2014 年 4 月 7 日。取消我的最后一个。最好的提取是通过 MS Word 实现的。这可以在 Acrobat Pro 中自动执行(工具 > 动作向导 > 创建新动作)。Word 到文本可以使用 .NET OpenXml 库实现自动化。这是一个可以非常巧妙地进行提取(docx 到 txt)的类。我最初的测试发现,MS Word 转换在文档结构方面要准确得多,但是一旦转换为纯文本,这一点就不那么重要了。