我一直在尝试编写一个简单的控制台应用程序或PowerShell脚本来从大量PDF文档中提取文本。有几个库和CLI工具可以实现这一点，但事实证明，没有一个能够可靠地识别文档结构。特别是我关注文本列的识别。即使非常昂贵的PDFLib TET工具也经常混淆两个相邻文本列的内容。
经常注意到PDF格式没有任何列，甚至是单词的概念。关于SO的类似问题的几个答案提到了这一点。这个问题非常严重，甚至可以保证学术研究。 This journal article注意：
PDF文件中的所有数据对象都以a表示 视觉导向的方式，作为一般的操作者序列 不要传达有关更高级别文本单位的信息，例如 令牌，行或列 - 关于这些之间的边界的信息 单位只能通过空格隐式提供
因此，我尝试过的所有提取工具（iTextSharp，PDFLib TET和Python PDFMiner）都无法识别文本列边界。在这些工具中，PDFLib TET表现最佳。
然而，非常轻量级的开源PDF阅读器SumatraPDF以及其他许多类似的用户可以完美地识别列和文本区域。如果我在其中一个应用程序中打开文档，选择页面上的所有文本（甚至整个文档用CTRL + A）复制并粘贴到文本文件中，文本将以正确的顺序呈现几乎完美无缺。它偶尔会将页脚和标题文本混合到其中一列中。
所以我的问题是，这些应用程序如何做看似困难的事情（即使是像PDFLib这样昂贵的工具）？
EDIT 2014年3月31日：值得注意的是，我发现PDFBox在文本提取方面要比iTextSharp好得多（尽管有一个定制的策略实现），而且PDFLib TET略胜PDFBox，但它和＃相当昂贵。 Python PDFMiner是没有希望的。我见过的最好的结果来自谷歌。可以将PDF（每次2GB）上传到Google云端硬盘，然后将其作为文本下载。这就是我在做的事情。我写了一个小工具，将我的PDF分成10个页面文件（Google只会转换前10页），然后在下载后将它们拼接回来。
2014年4月7日编辑。取消我的上一次。最好的提取是通过MS Word实现的。这可以在Acrobat Pro中自动完成（工具＆gt;操作向导＆gt;创建新操作）。可以使用.NET OpenXml库自动化Word到文本。 Here is a class将非常巧妙地进行提取（docx到txt）。我的初始测试发现MS Word转换在文档结构方面要准确得多，但是一旦转换为纯文本就不那么重要了。
答案 0 :(得分：15)
我曾经写过一个算法，它完全按照你所提到的PDF编辑器产品的方式完成，这个产品仍然是今天使用的头号PDF编辑器。你提到的（我认为）有几个原因，但重要的是焦点。
你是对的，PDF（通常）不包含任何结构信息。 PDF对页面的可视化表示感兴趣，而不一定是页面＆＃34;表示＆＃34;。这意味着它最纯粹的形式并不需要有关行，段落，列或类似内容的信息。实际上，它甚至不需要有关文本本身的信息，并且有大量的PDF文件，你甚至无法复制和粘贴文本而不会出现乱码。
因此，如果您希望能够提取格式化文本，您必须确实查看页面上的所有文本片段，也可能考虑到一些线条艺术信息，并且您必须要他们一起回来了。通常情况下，通过编写一个查看空白区域的引擎，然后首先决定什么是线条，什么是段落等等。众所周知，表格很难，因为它们非常多样化。
替代策略可能是：
那么为什么有些产品比其他产品更好？专注我猜。 PDF规范非常广泛，有些工具更多地关注较低级别的PDF任务，更多关注更高级别的PDF任务。有些人面向＆＃34;办公室＆＃34;使用 - 一些朝向＆＃34;图形艺术＆＃34;使用。根据您的关注点，您可能会认为某个功能值得关注与否。
此外，这似乎是一个糟糕的答案，但我相信它确实是真的，这是一个算法上难以解决的问题，只需要一位天才开发人员实现比平均产品好得多的算法在市场上。它是其中一个领域 - 如果你很聪明并且你有足够的注意力集中注意力，特别是如果你很清楚目标市场是什么，那么你就是这样写的 - 你和＃ 39;做得对，而其他人都会说得平庸。
（不，当我编写代码时，我当时没有做到这一点 - 我们从来没有足够的注意力来跟进并制作非常好的东西）
答案 1 :(得分：6)
要正确提取格式化文本，库/实用程序应该：
我不是你在问题中提到的产品的专家，所以下面的结论应该带有一点点。
不绘制 PDF的工具往往在前两个要求中缺乏专业知识。他们不必在更深层次上处理字体细节，而且在维护图形状态方面可能没有经过良好测试。
将PDF转换为图像的任何体面工具迟早都可能会意识到它在文本定位方面的缺点。修复这些将有助于在文本提取方面表现出色。