dav*_*004 18 pdf itext pdf-extraction
我一直在尝试编写一个简单的控制台应用程序或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云端硬盘,然后将其作为文本下载.这就是我在做的事情.我写了一个小工具,将我的PDF分成10个页面文件(Google只会转换前10页),然后在下载后将它们拼接回来.
编辑2014年4月7日.取消我的最后一次.最好的提取是通过MS Word实现的.这可以在Acrobat Pro中自动执行(工具>操作向导>创建新操作).可以使用.NET OpenXml库自动化Word到文本.这是一个非常巧妙地进行提取(docx到txt)的类.我的初始测试发现MS Word转换在文档结构方面要准确得多,但是一旦转换为纯文本就不那么重要了.
Dav*_*che 15
我曾经写过一个算法,它完全按照你提到的PDF编辑器产品的方式完成,这个产品仍然是今天使用的头号PDF编辑器.你提到的(我认为)有几个原因,但重要的是焦点.
你是对的,PDF(通常)不包含任何结构信息.PDF对页面的可视化表示感兴趣,而不一定是页面"意味着".这意味着它最纯粹的形式不需要有关行,段落,列或类似内容的信息.实际上,它甚至不需要有关文本本身的信息,并且有大量PDF文件,您甚至无法复制和粘贴文本而不会出现乱码.
因此,如果您希望能够提取格式化文本,您必须确实查看页面上的所有文本片段,也可能考虑到一些线条艺术信息,并且您必须将它们重新组合在一起.通常情况下,通过编写一个查看空白区域的引擎,然后首先确定哪些是线条,什么是段落等等.众所周知,表格很难,因为它们非常多样化.
替代战略可以是:
那么为什么有些产品比其他产品更好呢？专注我猜.PDF规范非常广泛,一些工具更多地关注较低级别的PDF任务,更多关注更高级别的PDF任务.一些用于"办公室"使用 - 一些用于"图形艺术"使用.根据您的注意力,您可能会决定某项功能是否值得关注.
此外,这似乎是一个糟糕的答案,但我相信它确实是真的,这是一个算法上很难的问题,只需要一个天才开发人员实现一个比市场上的普通产品好得多的算法.这是其中一个领域 - 如果你很聪明,而且你有足够的注意力集中注意力,特别是如果你很清楚目标市场是什么,你就是这样写的 - 你会做对的,而其他人都会让它变得平庸.
(不,当我编写代码时,我当时没有理解它 - 我们从来没有足够的重点跟进并制作非常好的东西)
要正确提取格式化文本,库/实用程序应该:
我不是你在问题中提到的产品的专家,所以下面的结论应该用一些盐.
不绘制 PDF 的工具往往在前两个要求中具有较少的专业知识.他们没有必要在更深层次上处理字体细节,他们可能没有在维护图形状态方面经过良好测试.
任何将PDF转换为图像的体面工具都可能迟早会意识到它在文本定位方面的缺点.修复这些将有助于在文本提取方面表现出色.
| 归档时间： |
|
| 查看次数： |
14833 次 |
| 最近记录： |