PDF 转 DOCX 或 HTML：双引擎串联的往返是怎么工作的
PDF 是文档的终点。它把版式、字体、分页冻结成在任何地方打印都一致的东西——这正是它的价值，也正是当你需要重新编辑内容、发布到网页、或拉进其他工作流时它成为死胡同的原因。
从 PDF 里走出来，需要两个各司其职的引擎串成一条往返管线：一个读文本层、重建结构，一个写出真正的 DOCX 或 HTML 文件。这篇文章讲清楚这条链在本站怎么工作、什么能在旅程中存活，以及如何在两个目标格式之间选择。
PDF 是目的地，不是出发地
PDF 格式的设计目标是让页面在每个屏幕和每台打印机上看起来一样。为此它存储的是带精确坐标的字形：这个字符、这个字体、页面上的这个位置。它不存储文本的含义——没有段落对象、没有标题样式、没有列表结构，只有位置上的一堆痕迹。
这个设计正是从 PDF 复制文本常常得到错乱换行和丢失格式的原因。阅读软件只能靠空白和几何位置猜段落从哪开始、到哪结束。把 PDF 转回可编辑格式，就是同一个猜测游戏——只是玩得更仔细、规模更大。
为什么单个引擎走不完这趟旅程
读文本层和写 Word 文档是两门不同的手艺。前者是几何学：把带坐标的字形排序成行、把行合并成段落、按字号识别标题、把正文与页眉页脚和页码分开。后者是序列化问题：产出带正确样式的合法 OOXML，或元素层级正确的干净 HTML。
把两个各自做好一件事的引擎串联起来，胜过要求一个引擎两件事都做。本站的第一个引擎是专门的 PDF 文本层提取器，第二个是作为 WebAssembly 在浏览器里运行的 Pandoc——文档转换的参考实现。两者之间坐着一个双方都懂的中间格式：Markdown。
这条链：提取、结构化、写出
第一阶段：提取器走遍每一页的文本层，把字形排成阅读顺序，重建逻辑结构——按字重和字号认出标题、按间距认出段落、按标记认出列表。产出是 Markdown：原始文档忠实的结构骨架。
第二阶段：Pandoc 接过这份 Markdown，写出目标格式。要 DOCX，得到的是真正的 .docx——样式、标题、列表、表格都是 Word 原生构件，能在 Word、LibreOffice 或 Google Docs 里打开。要 HTML，得到的是可以直接贴进 CMS 的干净独立页面。两个阶段都在本地运行，文件从不离开你的机器。
什么能在往返中存活
结构存活得很好。标题层级、段落、无序和有序列表、加粗和斜体、超链接，都能干净地从文本层经 Markdown 映射进 DOCX 或 HTML。对以文本为中心的文档——报告、合同、手册、信函——产出是真正可编辑的，而不是你得重新打字的摹本。
外观按设计不存活。精确的字体、精确的间距、多栏版式、浮动文本框，都是 PDF 的渲染决策而不是内容，这条链刻意把它们丢弃。表格介于两者之间：简单的网格能作为表格通过，复杂的合并单元格版式会退化成需要手工修复的碎片。正确的预期是一份结构良好的草稿，而不是像素级完美的重建。
DOCX 还是 HTML：选择目标
当结果要由人来编辑时，选 DOCX。需要修订的合同、等待批注的报告、被改作他用的模板——下一步发生在 Word 或兼容编辑器里的任何场景。原生样式意味着修订跟踪、评论和重新排版都如常工作。
当内容要回到网页时，选 HTML。把旧的 PDF 文档迁移进帮助中心、把宣传册重新发布成着陆页、把内容喂给静态站点生成器——HTML 完全绕过文字处理软件，产出可以直接检查的标记。两个目标共享同一个提取阶段，所以拿不准时两个都出；不额外花你任何成本。
扫描版 PDF 需要先过 OCR
整条链依赖文本层。扫描版 PDF——包在 PDF 壳里的页面照片——没有文本层，任何提取器都读不出不存在的东西。两秒钟的测试：在 PDF 阅读器里试着选中一句话。如果高亮不了文字，你手里就是扫描件。
解法是在前面加一级识别：先让文件过一遍 OCR——本站的图片转 Markdown 工具就在本地完成——再把识别出的文本喂进转换链。识别错误成了新的薄弱环节，所以对输出里的姓名和数字要格外仔细地校对。
信任，但要抽查
每一次 PDF 转可编辑格式的转换都是一次重建，而重建值得复核。先查标题层级——一个漏掉的字号线索能把章节标题降格成正文。然后查表格，再查要紧的数字，最后查每一节的首尾行——页眉页脚最喜欢从那里混进来。
这五分钟不是工作流的缺陷，它就是工作流本身。这条链把一份碰不得的 PDF 变成一份真正能用的草稿，而一份经过核验的草稿，远比一份根本编辑不了的“原件”值钱。