为什么 PDF 转 Word 比看起来难得多
Word 转 PDF 是一个渲染问题:拿着一份描述好的版式,把它画出来。PDF 转 Word 是反过来的,而这个反向并不对称。倒着走是一个重建问题,重建远比绘制难。
PDF 存的是字形,不是句子
PDF 文件不记录段落和标题。它记录的是「在特定坐标画出某个字符」的指令,所以把 PDF 转成 Word,意味着要从位置数据里反向推导出结构。
Word 文件会说「这是一个一级标题,内容是季度报告」。PDF 会说「用 22 磅的 F2 字体,移动到 x=72 y=782,画出字形 季-度-报-告」。文件里没有任何地方标记它是标题。只能从「它比周围所有文字都大」这个事实推断出来。
为什么段落必须靠反向推导
文字是以坐标上的碎片形式到来的,经常在词中间被切断,字与字之间的空格也常常完全缺失。要还原可读的文字,就得按垂直位置把碎片聚成行,在水平间距暗示有空格的地方补上空格,再判断哪些换行是折行、哪些是段落边界。
这里的每一步都是启发式规则。我们的规则有文档、有测试,但它们终究是猜测——所以这个页面会标出输出中哪些部分是猜的,而不是把全部内容都当成事实呈现。
扫描文档的问题
扫描 PDF 里装的是文字的图片,不是文字。没有 OCR,再怎么解析也还原不出文字。
这是所有 PDF 转 Word 转换器最常见的失望来源,也是很多人断定「这些工具根本不管用」的原因。你把同事扫描的合同拖进去,拿回来一份什么都没有的 Word 文件——而且通常连一句解释都没有。
OCR 是什么,为什么这个工具没有它
光学字符识别(OCR)看的是图片,判断哪些形状是哪些字母。它和读取文字层是完全不同的技术,速度也慢得多,而浏览器端的实现意味着要给每位访客下发一整个识别模型。
所以我们做了退而求其次但更诚实的事:检测出这种情况并明白告诉你,而且是在你拖入文件后看到的第一条信息里。检测逻辑考虑到了扫描页很少完全为空——扫描仪会打上页码,不完整的 OCR 也会留下残迹——所以只有寥寥几个字符的页面会被判定为扫描件,而不是文字页。
这个 PDF 转 Word 工具实际做什么
这是一个文字提取器,不是版式转换器。它把 PDF 里的文字还原成一份可编辑的 Word 文件,但不会重现原始的页面设计。
文字提取与版式还原
人们说「PDF 转 Word」时,其实指两件很不一样的事。版式还原试图重建整份文档:表格还是表格、分栏还是分栏、图片在原位。这需要商业引擎或大量服务端设施,而做得好的实现全都在服务端。
文字提取拿到的是文字本身、阅读顺序,以及能有把握推断出来的基础结构。对很多真实任务来说——引用一条条款、复用一个段落、从报告里取几个数字——这就已经是全部所需。
适合谁用,不适合谁用
适合你,如果你想把 PDF 里的文字拿出来编辑、引用或改写,而且不希望自己的文档被上传到陌生人的服务器。
不适合你,如果你需要 Word 文件看起来和 PDF 一样、文档里表格很多,或者它是一份扫描件。这些情况下面会逐一说明,并告诉你该改用什么。
三步从 PDF 提取文字
拖入 PDF
把 PDF 拖到上面的框里,或点击选择。文件从磁盘直接读进浏览器——没有上传环节,所以大文档会立刻开始处理,而不必等网络。
查看提取预览
文件一读完,你就能看到实际提取到了什么、有多少标题和列表项是推断出来的,以及有没有页面看起来是扫描件或分栏排版。预览有意放在下载之前,好让你在一份注定不行的文件上及时收手,不浪费时间。
下载 DOCX
导出一份标准 Word 文件,可以在 Word、Google Docs、LibreOffice 或 Pages 里打开。如果推断出的标题看起来不对,打开纯文本模式再导出一次——只要一秒钟,并且跳过所有推断。
PDF 转 Word 提取能拿到什么,拿不到什么
每个 PDF 转 Word 工具都会在某处画下这条界线。只是多数工具从不告诉你线画在哪。
可靠提取
正文文字。单栏文档的阅读顺序。粗体和斜体——从内嵌字体的名称推断得出。超链接的可见文字。
对一份普通的报告、信函或文章来说,这实际上已经是全部内容。
靠推断——有时会错
标题层级、段落边界、项目符号和编号列表。这些是从几何信息推导出来的,不是从文件里读出来的——预览把它们标注为「推断」,原因正在于此。
标题层级是怎么按字号猜出来的
我们把文档中最常见的字形高度当作正文字号,然后把明显更大的内容升为标题:1.6 倍及以上是一级标题,1.35 倍是二级标题,1.15 倍是三级标题。
用最常见字号而不是平均值,是有意为之——平均值会被一个很大的标题拉高,反而让那个标题再也无法被识别成标题。基准也是在整份文档范围内计算的,所以一张通篇大字的扉页不会带偏后面的每一页。
不支持
表格会以零散文字的形式输出,而不是表格。图片不会被带过去。页眉、页脚和页码会被当作普通文字提取,出现在它们原本所在的位置。精确的版式、位置、字体和字号完全不会被还原。
表格、图片与扫描页
分栏页面会被检测出来并标记,而不是被悄悄交错混排——因为跨栏的阅读顺序确实存在歧义:一篇双栏的学术论文既可以逐栏读,也可以横排读,而文件本身并没有说是哪种。
扫描页不会产出任何内容,并且会在你导出之前就报告出来。
提取能力一览
| 项目 | 状态 | 说明 |
|---|---|---|
| 正文文字 | 可靠 | 从文字层还原 |
| 阅读顺序(单栏) | 可靠 | 按行位置聚合 |
| 粗体与斜体 | 可靠 | 从内嵌字体名称推断 |
| 超链接文字 | 可靠 | 可见文字,不含链接目标 |
| 标题层级 | 推断 | 按相对字号判断,可能出错 |
| 段落边界 | 推断 | 按行间垂直间距判断 |
| 项目符号与编号列表 | 推断 | 按行首标记和缩进判断 |
| 分栏阅读顺序 | 推断 | 检测并标记,不做重排 |
| 表格 | 不支持 | 输出为零散文字 |
| 图片 | 不支持 | 不会带进 Word 文件 |
| 页眉与页脚 | 不支持 | 以普通文字形式出现 |
| 页面版式与字体 | 不支持 | 不会还原 |
| 扫描页 | 不支持 | 需要 OCR;会检测并报告 |
PDF 转 Word 提取可以用来做什么
PDF 转 Word 提取的现实用途都有一个共同点:你要的是文字,不是设计。
从合同和报告里引用条款
靠手打把 PDF 里的一条条款逐字誊出来,恰恰是在最容不得错的那类文档里制造誊写错误。提取能把措辞原封不动地交给你——而对一份合同来说,「它从未离开过你的机器」绝不是可有可无的细节。
复用学术论文的文字
学术 PDF 是这个工具的经典场景,也是它局限的经典场景:文字能干净地提出来,但双栏论文会被标记出来,因为阅读顺序确实存在歧义。先提取,再手动调整顺序。
从发票里取数据
发票的明细行在表格里,出来的是零散文字而不是网格。即便如此,还是比手打快,而且数字和打印出来的完全一致。
翻新旧文档
把一份旧的 PDF 宣传册或手册重新变成可编辑的文案,要的通常就是文字而不是设计——设计本来就是要换掉的。
为什么这里的隐私格外重要
人们最想提取文字的文档——合同、医疗信函、财务报表——恰恰是最不该上传的文档。本地处理不是回答了这个问题,而是让这个问题根本不存在。
什么情况下该改用服务端转换器
| 如果你需要… | 用什么 | 原因 |
|---|---|---|
| 表格保留为表格 | Adobe、Smallpdf 或 Word 本身 | 需要版式重建 |
| Word 文件看起来和 PDF 一样 | 商业转换器 | 我们不还原版式 |
| 提取扫描文档里的文字 | OCR 工具 | 文件里不存在可读的文字层 |
| 图片一并带过去 | 商业转换器 | 本工具不提取图片 |
| 只要文字,并且要私密 | 本工具 | 不会上传任何内容 |
| 编辑和引用文字 | 本工具 | 文字加基础结构已经足够 |
PDF 转 Word 之后:编辑、转回去、分享
PDF 转 Word 很少是最后一步。文字到了 Word 里、编辑完之后,把它转回 PDF 是顺理成章的下一步——我们的 Word 转 PDF 转换器同样完全在浏览器里运行,所以这一来一回都不会经过任何服务器。
如果你的素材分散在多份 PDF 里,先合并它们再提取一次,比提取好几次再到 Word 里拼接省事得多。