PDF 转 Word

PDF 里真正装着什么，文字为什么按这个顺序出来

PDF 的一页是一段程序，而不是一个段落：用这种字体、在这些坐标上画出这个字符，然后画那张图片，再画一条线。人眼看到的阅读顺序并没有存在任何地方——它是从位置推断出来的。这里用的是一套 PDF 文字读取器，它沿着内容流走一遍，按页面绘制的顺序报告每一段文字，并在每行最后一段上带一个标记。

这个顺序在这个工具写出来之前就被量过，用的是一份六页、双栏的样本：12,833 个字符在 96 毫秒里输出，两栏是一栏接一栏到来的，而不是交错（60 次检查里只有一次跨栏切换），85 段文字带着行尾标记，重建出 65 行。所以这个工具跟随内容流，并用行尾标记来断行。按坐标对文字做聚类——另一种常见做法——会把任何故意放在基线之外的东西重排，比如图注或页边印章，而测量表明这里并不需要那样做。

你在别处会看到的另一种做法——把每一页栅格化再跑 OCR——对一份本来就有文字的文档来说更糟：它去猜本来可以精确读到的字符，分不清小写 l 和数字 1，还把一份可搜索的文件变成它的一张图片。

Word 文件是怎么写出来的

.docx 是一个装着 XML 的 ZIP 包。这个工具直接把它写出来——三个部分：内容类型表、包关系表、文档正文——配上一份 CRC-32 校验和浏览器自带的压缩。没有从模板里嵌任何东西，没有向任何地方取任何东西，过程中也没有任何页面之外的东西碰过你的文字。

文档正文故意做得很朴素，因为文字层能支持的只有这些：一行一个段落，PDF 有分页的地方放一个分页符，US Letter 页面配一英寸页边距。文字会按 XML 转义，XML 禁止的字符——来自损坏字体编码的 NUL 或换页符——会被丢掉而不是传下去，因为 Word 会为一个非法字符拒绝整份文档。Unicode 原样通过，包括带重音的字母、中日韩文字、货币符号和 emoji。

这个包在发出去之前会先被验证：我们会像阅读器一样把它读回来（从文件末尾开始，穿过中央目录，把每个偏移、大小和 CRC 核对一遍），完成的文件也会在浏览器里打开检查。同一份文件还用另一套独立的办公软件工具打开核对过，在 Word 里打开时不会弹修复提示。

什么会被拒绝，什么不会跟过来

扫描件会被拒绝，而不是导出一份空的。这也是量过的：一份只有图片的样本，六页给出了 56 个字符的“文字”——而那些是画在上面的页眉，不是页面内容。真正的扫描件给出零。所以这个工具会数它找到的文字，如果一个都没有，就告诉你这些页面没有文字层、建议先做 OCR，然后在这里停下，而不是塞给你一个看起来像失败的 Word 文件。

需要密码的 PDF 同样会被拒绝，因为在一个从不上传任何东西的页面里，没有办法向你要密码；那条提示会指向解锁工具，它在同一个标签页里运行，可以移除你知道的那个密码。

其余的限制它都老实说明。标题、列表、分栏、表格和颜色都不会被识别，因为文字层区分不了它们：表格的一行到来时就是一行文字，间距是 PDF 当时存下的样子。没有可读文字的页面会在结果里逐个列出，所以一份一半是扫描件的文档是显而易见的，而不是悄悄不完整。你得到的是一份干净的、可编辑的文字草稿，而这正是多数人实际需要的——而且它花一秒，而不是一分钟。

分页模式，以及怎么看结果

分页这个选项决定文字在 Word 里怎么落位。每个 PDF 页对应一个 Word 页，能让两边的页数对齐——Word 文件的第 4 页就是 PDF 的第 4 页——当编号必须和一份印刷文档对得上时，这一点很重要。不加分页符则让文字流成一段连续正文，当你的目的是搜索、引用或改写、而页码在文件被接受的那一刻起就不再重要时，这正是你想要的。

表单下方的计划是按你输入的页数（最多 2000）画出来的，那时文件还不存在；等真正的文档进来之后再按它重建。不产出文字的页面会在结果里单独报告，而不是消失；转换接收一份最多 25 MB 的 PDF，读和写全部在这个标签页里完成。