PDF转成word?做不到
今天我接了个活:把 PDF 转成 HTML。
刚听到的时候,我就觉得这事不对劲,但一开始又说不清到底哪里不对。因为直觉上看,PDF 明明能显示,浏览器也明明能把它重新画出来,那为什么不能顺手转成干净的 HTML?
我当时还专门拿 GPT5.5 过了一轮,列计划、写代码、试工具、换方案。连 5.5xh 都用上了,就是怕自己一开始走歪。结果他妈的正经折腾了一天,到下班才明白,问题根本不在这里。更离谱的是,它不是完全没提到这个问题,而是一直像在说,但始终没说到点上,最后还是一路带着我在歪路上狂奔,让我一直以为再补几个规则、再换一个库、再改一个方案,就能越来越接近“完美还原”。
后来到下班我才明白:这事麻烦,不是因为库还不够强,而是因为目标本身就有问题。
1. 你哪怕重画一个一模一样的 PDF,你也没法把它变成结构化文本

图:你能重画页面,但重画不等于知道它原来是什么结构
普通 PDF 里有的,其实就是:
• 坐标
• 字体、字号、颜色
• 字符或者图像笔画
所以 PDF 当然可以被重新渲染。你用 Canvas、SVG,或者一堆绝对定位的元素,都可以把它在网页上重新画得很像。
但问题是,重新画出来,不等于知道它原来是什么结构。
页面顶部一行大字,人会看成标题。
PDF 往往只知道:这里有一段 24 号加粗文字。
一堆横线竖线加几块文字,人会看成表格。
PDF 往往只知道:这里有几条线,几个坐标上有几个字。
也就是说,PDF 根本就没法知道:
• 这里是标题,还是正文
• 这里是列表,还是普通段落
• 这几行其实是不是同一个段落
• 这里到底是不是一个表格
• 这一页到底该先读左边,还是先读右边
除非你手里拿到的是标签本身就很完整、很老实的 Tagged PDF。但现实里,你根本不能拿这个当前提。
如果源文件导出成 PDF 的时候,结构信息已经被压扁成了“字符 + 坐标 + 绘制指令”,那你后面再怎么解析,你他妈都不可能准确知道它原始结构到底是什么样的。
你能还原视觉。
但你不能凭空还原已经丢掉的信息。
2. 现在这些开源项目,本质上就是在猜

图:通用 PDF 解析工具做的不是读取结构,而是根据视觉特征推断结构
所以 MinerU、Docling、MarkItDown 这一类工具,真正干的都不是“读出 PDF 里的标题和正文”,因为大多数 PDF 里,本来就没有这些东西给你读。
它们干的其实是另一件事:
• 看字号是不是更大
• 看字体是不是更粗
• 看几行字的左边缘和行距是不是接近
• 看页面上有没有重复页眉页脚
• 看线条和文字是不是像一个网格
然后据此去猜:
• 这里可能是标题
• 这里可能是一个段落
• 这里可能是表格
• 这里可能要按这个顺序读
注意,这不是“读取”,这是“推断”。
推断就意味着,它永远没办法对所有 PDF 百分之百正确。它只能在大量样本、规则、模型和兼容经验上,不断把命中率往上抬。
这也就是为什么阿里、百度这些厂商,能把 PDF 转 Word、PDF 转 HTML 长期当成一个功能往外卖。
它卖的根本不是“格式另存为”。
它卖的是:
对各种脏 PDF、怪排版、烂表格、多栏、公式、页眉页脚、跨页段落做结构猜测和异常兼容的工程经验。
所以这事从理论上就不是一个“完美还原”的问题,而是一个“在信息已经丢失的前提下,谁猜得更准,谁兜的异常更多”的工程问题。
小结一下

图:固定模板才能谈结构化还原;模板不固定,就只能尽量还原格式
要记住的其实就两点。
1. 如果你真的要一一还原,并且是还原成一个真正的结构化文本,那么你只能接受模板是固定的。
2. 如果你做不到模板固定,那么你只能说是尽量还原格式。
所以以后你再遇到“把 PDF 转成别的结构化文件”这种活,完全可以理直气壮地和老板说:做不到完全准确。
如果一定要做,那也只有两条路:
• 去买现成 API
• 或者上开源模块自己调
但不管走哪条路,本质上都只是尽量还原,不是保证还原。
预期别定太高,这才是这件事最现实的打开方式。
夜雨聆风