我有一个关于从 pdf 文件中提取文本、精确的表格数据的一般问题。
pdf 查看器如何能够阅读和显示表格？为什么我们不能以同样的方式获取必要的列信息？
我现在正在搜索一个星期，主要是使用 pdftoxml 卡住令牌坐标和太宽的表格单元格（这样一个准确的中间空表格单元格识别变得不可能）。
我通过正则表达式文本来解决我的一堆pdf文件（顺便说一句。如果忽略一些行间距离并“粘贴回一起”，那么逐行非常成功），但这当然只是一个实例解决方案。
这让我很头疼。pdf 查看器为单元格绘制线条并知道单元格的开始和结束位置，但我们无法从 pdf 源中读取它。这怎么可能？他们知道什么是我们无法推断的？
您的误解是一列作为一列存储在 PDF 文件中。事实并非如此。PDF 查看器不理解表格、列、段落、文本行或单词。
PDF 是作为页面描述语言创建的，它非常擅长在许多不同的设备上复制完全相同的页面。因为这是它的目标，所以它不关心结构，你所指的都是结构。
PDF 绘制文本的方式非常非常简单。页面上的说明将是这样的：
虽然也可以将一些结构信息与这些说明一起存储在 PDF 中，但通常不会这样做，并且无论如何都是在事后才以 PDF 格式实现的。
当您查看上面的（伪）说明时，很容易理解表格是如何绘制的。文件中将简单地说明将一个单元格移动到某个位置并绘制文本。然后更多的指令移动到另一个单元格并绘制该文本。
如果要反转操作并从 PDF 页面中提取结构化信息，则必须“重新发明”结构信息。这意味着诸如找出哪些文本在同一基线上并因此可能属于同一行之类的事情。哪个文本在该基线上足够接近，以至于它可能是单词或列......等等......
正如您所想的那样，这根本不是一件容易的事！
在未压缩的 pdf 文档中，存在以下不确定格式的“流对象”（(0,0) 为左下角），伪正则表达式形式：
(x1 y1 m x2 y2 l [whitespace or blank or newline seperator symbol])* S (BT .* ET)*
在哪里
x1, y1, x2, y2 are coordinates
l probably for "draw line"
m move to, "from to" or "merge"
S is the command for "draw" or the like
BT Begin Text
ET End Text
所有命令后缀。
编辑：
一种可能的 Java 正则表达式是（参考 PDF32000_2008.pdf），在未压缩的 pdf 源中用空格替换换行符后：
((\s+\d+(\.\d+)?){2}(\s+m|\s+l|(\s+\d+(\.\d+)?){2}(\s+re|\s+y|\s+v|(\s+\d+(\.\d+)?){2}\s+c))\s+)+([SsFn]|[fBb](\*)?)
流中还有其他元素，如“W*”或“Q q”，它们似乎在一般情况下调整线条粗细或字体属性。由于我无法找到特定的语言规范，这就是我从实验中推断出来的。
使用此信息和文本标记的坐标（在 ET 和 BT 之间），可以推断表格单元格宽度、表格起始结束位置（用于识别不同表格）。
问题仍然是解压缩任何类型的流。使用 pdftk 我能够解压缩从 openoffice writer 创建的 pdf 文件，但任意 pdf 文件中仍然有神秘符号。
更多信息：
http://www.gnupdf.org/Introduction_to_PDF
http://blog.idrsolutions.com/2012/03/understanding-the-pdf-file-format-names-locations/