PDF 转 Word

PDF 页面根本没有 Word 文档那种"段落"或"标题"的概念——它内部其实是一组被定位好的文字片段，每一个本质上都是在说"在这个精确的 x、y 坐标上，用这种字体，画出这些字符。"这里没有大纲，没有文档结构，甚至连一行在哪里结束、下一行从哪里开始都没有可靠的概念；PDF 阅读器是通过在每个文字片段声明的位置上把它画出来，来重现页面的视觉外观，而阅读结果的人之所以能感知到行和段落，只是因为这些位置恰好排列成了那样。把 PDF 转换成可编辑文档，意味着要反向推导这个过程：把垂直位置相近的文字片段归并成行，再留意某一行和下一行之间的垂直间距什么时候异常地大——这是一个段落刚刚结束的信号——并把它当作一次分段处理。这从根本上说是一次基于位置数据的重建，而不是对文件里某种隐藏文档结构的读取，这也正是原始格式无法被恢复的原因：文件里本来就没有可供恢复的结构化格式信息，有的只是墨迹被放在了哪里。

人们很容易以为"读取一份 PDF"和"读取一张扫描页面"是同一个任务、用同一个工具就能解决，但它们其实是两个截然不同的问题。这个工具所做的文字提取，读取的是 PDF 已经作为文字存储的内容——字符编码和位置，正是 PDF 阅读器用来让你选中和复制一句话的那份数据。OCR（光学字符识别）解决的是一个难得多的问题：看着一个只是一张图片、文件里任何地方都没有文字数据的页面，用图像识别去猜测这张图片描绘的到底是什么字母和单词。这是一项根本上更繁重的工作——涉及图像处理、字符识别模型，以及对"正确答案"本身固有的不确定性，而当文字已经作为文字存在时，这些都用不上。把一整套 OCR 引擎塞进一个卖点就是能在浏览器里瞬间运行的工具，会牺牲掉让这个工具真正好用的速度和简洁性，而这样做只是为了照顾少数恰好是扫描件的 PDF。扫描的、只有图像的 PDF 是一种真实且常见的情况，这个工具会在结果里直接说明，而不是悄悄生成一份空文档——但要真正解决这个问题，需要找一个专门的 OCR 工具，而不是把这个工具拉扯到它诚实能力范围之外。

一个更有野心的转换工具可能会尝试重现原始页面的版式——把文字放进大致对应坐标的方框里，猜测分栏，试图复现字体。实际效果往往是一份表面上看起来和原文相似、却几乎无法真正编辑的文档：文字停留在互不相连的浮动方框里，而不是流动的段落，一旦增删任何内容就会重排得一团糟，处处和使用者对着干。相反，把提取出的文字重排成普通段落——这个工具采用的方法——刻意放弃了视觉上的相似性，换来一份真正表现得像 Word 文档该有的样子：在段落末尾打字会正常换行，删掉一句话，页面其余部分会像文字处理软件一直以来那样重新排列。对于把 PDF 的文字变成可编辑文档这个常见目标——引用、修改、再利用或翻译——这笔交易是正确的，这也是为什么这个工具不会试图打扮成一个版式保留工具、却披着文本编辑器的外衣。