PDF 转 Markdown 后表格乱了,这不是你操作的问题。根本原因是 PDF 格式本身通常不保存表格的逻辑结构。这篇文章解释表格错乱的原理,展示 7 个真实文档的实测数据,以及发现表格出错后该怎么处理。
PDF 通常不保存表格的结构
PDF 内部存储的不是文档逻辑结构,而是渲染指令序列。页面内容保存在 content stream 中,里面只有"在这个坐标放这个字符""从这里画一条线到那里"这类绘图运算符和参数(参见 Adobe PDF Reference 1.7在新标签页中打开 的 Graphics / Text 章节)。表格的边框只是画线指令,单元格里的内容是画在那些线附近的字符。把这两者关联为"某个单元格的某个值"的信息,在标准 PDF 中并不存在。
PDF 解析库返回的数据也能说明这一点。pdf.js 的 getTextContent() 返回的 TextItem 对象只有 str(字符串)、transform(变换矩阵)、width、height、hasEOL 等字段,没有行号、列号或单元格 ID(PDF.js API 文档在新标签页中打开)。所以 Markdown 转换工具只能根据字符坐标和线条位置来推断表格结构。
有例外。为了无障碍访问而标记过的 PDF(Tagged PDF)可以包含 Table、TR、TH、TD 等结构元素,合并单元格也可以有 RowSpan 和 ColSpan 属性(W3C 技术文档 PDF6: Using table elements for table markup in PDF Documents在新标签页中打开)。但这是 PDF 制作者有意标注的结果,普通 PDF 不保证有这些标记。没有的话,转换工具只能回到坐标推断。
7 个文档、两条管线、实测结果
为了看推断失败时到底发生什么,我选了 7 个性质不同的文档——学术论文、政府技术文档、填写表单、统计表、幻灯片、央行报告——分别跑了两条转换管线:
- 文本提取管线:pdf.js(pdfjs-dist 6.2.108)+ pdf2md(@opendocsg/pdf2md 0.2.7)。没有表格组装步骤。
- 结构推断管线:pdf-inspector(@firecrawl/pdf-inspector-wasm 0.1.3)。分析矩形边框、字体和坐标来推断表格结构。
测量日期 2026-08-02,运行环境为 Apple M5 Pro / macOS(Darwin 25.5.0)/ Node v26.3.1。7 个文档均含文本层,不含扫描图像 PDF。样本获取脚本、测量脚本和原始结果数据在本仓库的 scripts/benchmarks/pdf-table-extraction/ 目录下。
| PDF 文档 | 类型 | 文本提取管线表格行数 | 结构推断管线表格行数 | 文本提取管线标题数 | 结构推断管线标题数 |
|---|---|---|---|---|---|
| Attention Is All You Need | 双栏学术论文 | 0 | 50 | 45 | 38 |
| BERT | 双栏学术论文 | 0 | 106 | 27 | 42 |
| NIST Cybersecurity Framework 2.0 | 图表密集的技术文档 | 0 | 45 | 3 | 27 |
| IRS Form 1040(2025) | 填写表单 | 0 | 42 | 24 | 5 |
| 劳动力调查年鉴基本统计 | 多栏统计表 | 0 | 405 | 1360 | 6 |
| 令和 7 年版信息通信白皮书概要 | 图表为主的幻灯片 | 0 | 9 | 38 | 112 |
| 经济与物价形势展望(日本银行) | 多栏央行报告 | 0 | 19 | 211 | 1 |
从数据看,两条管线的出错方式正好相反。文本提取管线在 7 个文档中表格行数全部为 0,即完全没有生成表格。结构推断管线每次都生成了表格,但行数多不代表提取正确。
单看行数无法判断对错。多栏央行报告中,标题和正文句子全部跑进了表格单元格,错乱严重,但表格行占整个输出的比例为 0.43。而真正有表格的填写表单,表格行比例为 0.45。这两个数值无法用阈值区分。也就是说,输出的表格行多,并不能证明表格提取正确。
错乱类型一:表格消失,只剩普通文本
第一种错乱是表格完全没有以表格形式输出。单元格里的文本能提取出来,但行列分隔丢失,数字和项目名称像普通句子一样连续输出。实测中文本提取管线就是这个表现,7 个文档表格行数全为 0。
这种错乱有一个好处:读起来马上就能发现不对。"应该有表格的地方没有表格"这件事很难忽略,方便你回到原文对照处理。
但也有副作用。表格中的每一行可能被误升为 Markdown 标题(#、## 等)。实测中,多栏统计表经文本提取管线转换后生成了 1360 个标题,而原文实际标题目测只有 4 个左右。如果转换后目录突然多出几百条,就应该是这个副作用。
错乱类型二:表格形式保留,但单元格错位
第二种错乱是 Markdown 表格语法本身没有错,但哪个值进哪个单元格搞混了。实测中结构推断管线属于这种情况。多栏统计表生成了 405 行表格,但多组数据混进了同一个单元格。
|15~ 64歳 6625 5878 6678 5893 6732 5912 …|15~ 24歳 595|25~ 34歳 1168|
这种比第一种更危险。管道符和分隔行都完整,Markdown 渲染器会正常显示一个"看起来没问题的表格",直接粘进报告或文档里。但某个数值偏了一列,没对照原文的读者很难察觉。表面看着没坏、实际数据已经错了,这一点比第一种错乱更需要警惕。
图表或多栏正文被误判为表格
结构推断还可能把不是表格的东西识别成表格。实测中确认了两个典型例子。
NIST Cybersecurity Framework 2.0 的环形图(Fig. 1 CSF Core structure)中,沿圆弧排列的文字被识别为表格单元格,而且首字母还丢了:
| Fig. 1. CSF Core structure |||
| --- | --- | --- |
| DENTIFY | ROTECT | ETECT ESPOND |
正确的词是 IDENTIFY、PROTECT、DETECT、RESPOND。沿圆弧排布的文字被切断,首字符被当作独立元素处理,结果变成了没有意义的碎片。
另一个例子是整个文档变成了一个巨大的表格。多栏央行报告中,标题和正文段落全部进了表格单元格:
|||||2025 年5月1日|
| --- | --- | --- | --- | --- |
||【基本的見解】|1|経済・物価情勢の展望(2025 年4月) <概要>|日本銀行|
这个文档中结构推断管线只生成了 1 个标题——文末的"以上"。原因是多栏排版整体被当作一个多列表格来解析了。
换转换方式能修好的错乱和修不好的错乱
值不值得换工具或换方法,取决于错乱的根因。
| 症状 | 可能原因 | 下一步 |
|---|---|---|
| 完全没有表格输出 | 所用管线不支持表格组装 | 值得试带表格结构推断功能的工具 |
| 有表格但单元格错位 | 坐标推断出错 | 换工具大概率也错位,需对照原文手动修正 |
| 图表文字变成了表格 | 图内文字被误判为单元格 | 删掉那个表格,参照原 PDF 中的图 |
| 整篇正文变成了一个表格 | 多栏排版被当作表格解析 | 切换为纯文本提取方式 |
| 一个字符都提取不到 | PDF 无文本层(扫描图像) | 转换无法解决,需要 OCR |
大致规律是:"有没有表格"换方法就能改变;但"出来的表格对不对",如果原 PDF 没有结构标记,任何方法都靠推断,换工具不保证正确。
想确认自己的 PDF 会出哪种错乱,最直接的办法就是实际跑一次。PDF 转 Markdown 在浏览器内完成转换,文件不会上传到任何服务器,可以安全地用自己的文件测试。


修复错乱表格的方法
转换结果必须对照原文
含表格的 PDF 转成 Markdown 后,不要直接用。必须对照原 PDF 逐项核对。错乱类型二无法靠肉眼发现,对照原文是唯一的验证手段。
建议按以下顺序检查:
- 行数和列数是否与原文一致
- 表头行的字段名是否按原文顺序排列
- 每行第一个和最后一个单元格的值与原文比对。错位通常先从两端显现
- 原文中有合并单元格的地方单独检查。Markdown 表格无法表达合并,这些区域一定发生了某种变形
数值表格不如直接重建
金额、测量值、统计数据这类表格,一个单元格错位就会改变数据含义。修复错乱的表格不如重新做。从原 PDF 中复制表格文本,粘贴到电子表格(Excel、WPS 等)中整理对齐,然后导出为 CSV,再用 CSV 转 Markdown 转换。这样单元格的对应关系能完整保留。
关于 Markdown 表格语法 本身(管道符位置、分隔行、对齐冒号、单元格内管道符转义等),表格语法不是 CommonMark 核心规范,而是 GitHub Flavored Markdown(GFM)的扩展(GFM 规范 Tables extension在新标签页中打开),粘贴目标平台是否支持 GFM 表格也值得确认。
哪些 PDF 容易错乱,哪些相对安全
以下清单不是绝对保证,而是降低表格错乱概率的检查项。
转换前检查
- PDF 查看器中能否用鼠标拖拽选中表格内的文字。选不中说明没有文本层,无法转换。
- 表格是否有清晰的边框线。无边框表格缺少单元格边界,推断难度增加。
- 页面是单栏还是多栏。双栏或三栏排版中,栏本身可能被误判为表格。
- 表格是否跨页。跨页的表格大概率按页拆成多个独立表格输出。
- 是否有合并单元格。Markdown 表格没有合并单元格的写法,必然变形。
- 表格中是否混有图表或图标。图中的文字可能被当作表格内容提取。
转换后需要怀疑的情况
- 每行列数不一致。说明单元格边界推断在行间摇摆。
- 空单元格异常多,或分隔行前有
|||||这类只有分隔符没有内容的行。 - 标题(
#)数量异常多。正文行可能被误判为标题。 - 出现无意义的碎片词,如实测中的
DENTIFY,说明字符被切断。 - 表格单元格内出现了明显是正文段落的长句。
扫描 PDF 没有文本信息,无法转换
用扫描仪或手机拍照生成的 PDF,每页是一张图片。人眼能看到字,但文件里没有文本数据。这种情况根本谈不上表格错乱——没有可提取的文字。
这类文档需要的是光学字符识别(OCR),不是格式转换。FormatArc 的 PDF 工具不内置 OCR 引擎,遇到这类文件会显示无法转换的提示,而不是返回猜测性的输出。与其输出可能错误的数据,不如明确告知无法转换,这更安全。
判断自己的 PDF 是不是扫描版,在查看器里试试拖拽文字。选不中就是图片。
常见问题
换个转换工具表格就正常了吗?
取决于错乱原因。如果完全没有表格输出,换到带结构推断的工具至少能生成表格。如果单元格错位,原 PDF 没有结构标记的话,任何工具都靠坐标推断,不保证修好。
Tagged PDF 就不会错乱吗?
结构标记正确的话,可以直接读取 Table、TR、TH、TD 结构,不依赖推断。但标记与否取决于 PDF 制作时的设置,阅读端无法选择。而且即使有标记,标记内容也可能与实际视觉排版不一致。
扫描 PDF 能转换吗?
FormatArc 不能。扫描 PDF 没有文本层,需要 OCR,本工具不支持 OCR,会显示无法转换的提示。
能只提取表格吗?
没有单独提取表格的功能。但从原 PDF 复制表格区域,粘贴到电子表格中保存为 CSV,再转 Markdown,可以保留单元格对应关系。对数值表格来说这条路最可靠。
总结
PDF 表格在 Markdown 转换中错乱,根本原因是 PDF 通常不保存表格的可复用结构,转换工具只能从字符和线条坐标推断结构。7 个文档的实测确认了两种错乱:完全不生成表格(文本提取管线)和表格形式保留但单元格错位(结构推断管线)。后者表面看不出问题,所以转换含表格的 PDF 后一定要对照原文核对。
想测试自己的 PDF 会怎么转换,可以用 PDF 转 Markdown。文件只在浏览器内处理,不会上传到外部。