PDF 表格提取为何要先重建几何布局

PDF 转 Markdown，最容易误判的故障之一，是把「表格提取错了」当成「解析器漏了数据」。作者花了一周排查，发现解析器拿到的是带坐标的文本，而人眼看到的表格，需要程序根据位置关系重新拼出来。

这篇短文的价值在于解释了一条排障思路：先检查输入里有没有可用的结构，再决定怎样恢复结构。作者给出了列边界、单元格和合并表头的处理办法，但没有提供准确率或对照测试，适合作为实现线索。

为什么文字没丢，表格还是乱了

作者开发 PDF 转 Markdown 工具时，agent 不断把财务报告交给它处理，结果却是一团乱序文字。多列内容被挤到同一行，作者最初怀疑解析器丢了数据。

排查后，他发现解析器忠实返回了文本，只是这些文本没有附带他期待的表格结构。原文用「带绝对坐标的文本片段」描述这种输入：程序知道一段文字画在哪里，却未必知道它属于第几行、第几列。

提取出文字，不等于恢复了阅读顺序和表格关系。

人能从对齐、留白和线条中看出表格，程序却需要把这些视觉线索变成规则。若直接把文本串起来，多列布局就可能塌成一行；继续追查「少了哪个字段」，很可能查错方向。

怎么从坐标里拼出列、单元格和合并表头

作者的修正是先处理几何关系，再组织内容。

第一步，测量文本块之间的间距，用较明显的空隙推断列边界，再根据垂直对齐关系，把文本归入相应的单元格。这里的大白话是：先看文字摆在哪，再判断哪些文字应该放在一起。

第二步，区分表格有没有边框。有边框时，作者寻找 PDF 中的矢量线条，把它们作为结构线索；没有边框时，则根据空白区域聚类，并用字符宽度调整阈值。阈值不能只理解成一个固定距离，因为文字大小会影响什么样的空隙才算列间隔。原文没有给出具体公式和参数。

第三步，处理合并单元格。一个横跨三列的表头，在输入中可能只是一个较宽的文本框。作者的办法是比较单元格宽度与已经推断出的列网格，宽度超出列网格对应范围时，将它识别为跨列单元格，即 span。

这个办法依赖前面的列网格足够可靠。网格本身偏了，宽文本框就可能被误判；原文没有展开这些冲突如何消解，也没有说明最终怎样在 Markdown 中表达合并单元格。

作者由此得出的认识是：PDF 解析需要在位置模式之上推测排版意图，每次提取都包含判断。他最后将这套处理封装成了 PDF 转 Markdown 工具。

我的判断

我认同作者对排障方向的修正。面对财务报告这类输入，先区分「文本是否提取完整」与「行列关系是否重建正确」，比笼统地更换解析器更有针对性。

但标题中的「PDF 根本没有表格」说得太满。原文展示的是作者遇到的输入和处理方式，没有交代 PDF 的来源、生成方式或样本范围，不能凭这段经历判断所有 PDF 都只提供同一种结构。

几何规则的好处是判断依据明确：列为何被切开、文本为何被归组，都能回到坐标和间距上检查。代价是阈值与版式有关，换一批文档是否仍有效，需要验证。

至于它和更换提取库、使用版面识别模型相比效果如何，作者没有给对照数据。这是一份有用的工程经验，不是一份足以证明方案优劣的评测。

能拿来做什么

• 给 PDF 转换流程保留文本块坐标和中间分组结果。遇到多列挤成一行时，先检查文本是否完整，再定位列边界或归组规则。
• 按有边框、无边框、跨三列表头准备回归样本，分别检查线条识别、空白聚类和 span 判断，避免只用一种表格验证整个工具。
• 如果 agent 会调用 PDF 转 Markdown 工具，就检查转换结果中的表格关系。工具成功返回文本，还不足以证明这些文本能供后续分析可靠使用。