小编dav*_*004的帖子

我一直在尝试编写一个简单的控制台应用程序或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转换在文档结构方面要准确得多,但是一旦转换为纯文本就不那么重要了.

我对BDD的理解是,用户故事中描述了一个系统,然后开发人员将这些用户故事转化为一个应用程序,旨在为每个"sprint"(软件开发时期)增加真正的商业价值.结果(据我所知)是域模型在整个开发过程中从用户故事中浮现出来.也就是说,在第一次'sprint'之后,很多域模型都不会被设计出来.

我对DDD的理解是软件开发继续参考完整的域模型,尽管是一个不断发展的模型.在DDD中,模型预计会发生变化,但它始终是"完整的".

这似乎是两种方法之间的根本区别.人们如何处理这个问题？

我正在考虑在一个项目中使用图形数据库，该项目需要对关系之间的关系进行建模。例如，A 和 B 之间的平局可能以 C 和 D 之间的平局为条件。

我还需要对节点之间的关系和其他关系进行建模。催化关系可能是一个很好的例子。代理 X 加速了代理 Y 和 Z 之间的关系。这些关系需要包含描述该关系的属性。

我可以通过使节点和关系继承同一类型来生成关系数据库来实现此目的。因此，每个类型数据库结构的表在 BaseType 表中具有主键，并且与子类型表具有一对一的关系：节点和关系。然后，Relationship 表具有 BaseType 表的三个外键。一个是其主键，另外两个构成关系的源和目标。因此，源和目标之一或两者可以是关系类型。

但这包含许多小对象的连接，这符合对图数据库应该表现最佳的数据库的描述。

根据要求提供图表 - 包括尝试的解决方案。

我尝试通过创建关系节点来解决问题。

所以我在这里提出的解决方案涉及创建更多节点。我想这可行，但想知道我是否让它变得不必要的复杂化。

最后一张图 - 关系数据库解决方案。这看起来更干净一些，但不如图形数据库方法灵活。也许效率不高？