PDF 转 HTML 怎么做（干净的网页）

把 PDF 变成干净的 HTML 页面：提取文字和图片自己重建、用 pdftohtml 或 Calibre，或者干脆嵌入。坦白讲清转换后什么能活下来。

把 PDF 文件转成干净的 HTML 网页 — PDF → HTML：这趟旅程什么能活下来

如果你想把 PDF 文件转成 HTML，先把实话摆上来：没有任何工具能把任意 PDF 自动变成干净、响应式的 HTML。PDF 是印刷格式——它存的是「把这个字形放在 x=142、y=380」，而不是「这是一个标题」。HTML 恰好相反。每一次转换都是两种哲学之间的翻译，总有东西会丢。

这不代表事情难办。它意味着你该按真实需求选方法：要干净的标记、要快速的一次性输出、还是只求把文档放上网页。三种方法都在下面，外加不转换的理由。

为什么要把 PDF 变成网页？

三个理由反复出现：

SEO。搜索引擎会索引 PDF，但真 HTML 页面的排名好得多：HTML 有结构（标题、链接、alt 文本）、加载更快、在手机上正常工作。埋在 PDF 里的内容，是大多数搜索者永远找不到的内容。
无障碍。屏幕阅读器处理语义化 HTML 的能力远胜过一般的无标签 PDF。如果文档对所有人都重要，HTML 才是无障碍的格式。
用户体验。手机上点开 PDF 链接意味着：下载 → 换应用打开 → 对着固定 A4 版式捏合缩放。HTML 页面则是直接阅读。

方法一——提取并重建（标记最干净）

对于你真正在乎的内容——要上你网站的报告、指南、文档——这条路胜过一切自动转换器。你把原材料从 PDF 里取出来，自己写简单的 HTML 包住它。

取出文字

把 PDF 拖进 提取文字。得到全部文字内容，20 MB、50 页以内免费，免注册。

取出图片

再把同一份 PDF 跑一遍 提取图片——每张内嵌图片按原始分辨率单独输出，直接就能进 img 标签。

标记结构

把文字粘进编辑器，补上 PDF 从来没有的语义：章节标题用 h2、段落用 p、列表用 ul、需要的地方用 table。这是手工的部分——一份 10 页文档通常要 15-30 分钟。

把图片放回去

在插图该在的位置加上带真实 alt 文本的 img 标签。顺手把图片压缩到适合网页的大小。

发布

结果是手工品质的 HTML：响应式、无障碍、可索引——自动转换器给不了其中任何一样。

没错，这是手工活。但产出的是你真正愿意维护的 HTML，对任何要给真实读者看的内容，这笔交换划得来。

方法二——pdftohtml 和 Calibre（命令行党的选择）

想要自动化、又能忍受较乱的输出：

pdftohtml（Poppler 工具集的一部分，Linux/Mac 上已预装或一条命令即装）：

pdftohtml -s -noframes document.pdf output.html

-s 参数输出一份连续的 HTML 文档，而不是每页一个文件。-c 参数开启「复杂模式」，用绝对定位的 div 复现版式——视觉上更接近 PDF，但那些标记除了展示以外毫无用处，在手机上会彻底崩坏。

Calibre（免费、跨平台）把 PDF 当电子书处理：打开 Calibre → 添加 PDF → 转换 → 选 HTMLZ 输出。它在单栏、以文字为主的 PDF 上表现最好，对多栏版式很吃力，经常把阅读顺序读反。

付费转换器（Adobe Acrobat Pro 的导出 HTML、各种 $6-20/月的在线服务）在表格上做得更好、保留的格式更多，但输出仍是机器生成的标记——几百个内联样式和层层嵌套的 span。只求今天把内容放上网，可以；将来要编辑，遭罪。

方法三——不转换：嵌入或链接 PDF

有时候「怎么把这个 PDF 放上我的网站」的正确答案，就是把 PDF 放上你的网站：

<embed src="/files/report.pdf" type="application/pdf" width="100%" height="800px" />

或者干脆一个带大小提示的普通链接： <a href="/files/report.pdf">年度报告（PDF，2.4 MB）</a>。

缺点：嵌入的 PDF 对 SEO 依然乏力，在手机上也别扭。常见的折中是两者兼备——页面上放一段核心内容的 HTML 摘要，下面附完整 PDF 的链接。

哪种方法适合你的情况？

场景	最佳方法	原因
要长期放在网站上的内容	提取 + 重建	干净、响应式、可编辑、可索引
一次性、内部用、没人编辑	pdftohtml / Calibre	又快又免费；乱一点无所谓
200 份 PDF 批量上网	pdftohtml 脚本化	这个规模下唯一可自动化的选项
固定版式就是重点（表单、证书）	嵌入或链接 PDF	转换只会让它们变得更糟
扫描版 PDF（页面是图片）	先 OCR，再重建	OCR 跑完之前根本没有文字层可提取
目标是 SEO	提取 + 重建	搜索引擎排名靠结构化 HTML，不靠定位的 div

坦白预期：什么活下来、什么活不了

无论选哪种方法，先校准预期：

纯文本：在哪儿都能活。这是轻松的 90%。
字体：通常被替换成 web 安全字体或系统字体，除非你手工加 webfont。
多栏版式：经典翻车点。转换器要么把多栏压成一条混乱的流，要么用绝对定位把它们冻住。
表格：看运气。简单网格常能转出来；合并单元格和嵌套表格基本没戏。
页眉、页脚、页码：会作为垃圾文字每「页」重复一次跟过来——你得手工删。
交互式表单字段：任何转换器都保不住。用 HTML 表单重建。

~90%

任何转换方法下纯文本的存活率

15-30 分钟

手工把一份 10 页 PDF 重建成干净 HTML

用 pdfty + 你的编辑器走提取重建路线的成本

1 小时

pdfty 从服务器删除你文件前的时间

常见问题

有真正免费的在线 PDF 转 HTML 转换器吗？

免费的自动转换器是有的，但输出是机器生成的标记——定位的 div 和内联样式。通向干净 HTML 的真正免费路线，是用 pdfty 提取文字和图片（20 MB 以内免费，每天 10 次操作，免注册），标记自己写。

我的 PDF 是扫描件——提取出来是空的，为什么？

扫描版 PDF 是页面的图片，里面没有文字层。先对它做 OCR；之后文字提取就正常了。没有 OCR，世上没有转换器能找到根本不存在的文字。

PDF 里的超链接能在转换中保住吗？

pdftohtml 会把大多数链接注释保留为 a 标签。走提取重建流程的话，纯文本提取会丢掉它们——标记时把重要的 URL 从 PDF 里手工复制过来。

怎么以完整质量取出图片？

用 提取图片——它取出的是内嵌的原始文件，而不是给页面截图，所以你拿到的是 PDF 里实际存储的分辨率。发布前再为网页压缩它们。

Google 到底索引不索引 PDF？

索引——Google 会索引并给 PDF 排名。但同样内容的 HTML 页面始终表现更好：更好的移动体验、更快的加载、真实的标题结构和内部链接都在给排名加分。内容对搜索重要，就发布成 HTML。

Word 能做 PDF 转 HTML 吗？

算是能。Word 能打开许多 PDF（文件 → 打开），把它们重排成可编辑文档，再另存为网页。它吐出的 HTML 臃肿是出了名的——当起点可以，当生产标记不行。

PDF 转 Markdown 而不是 HTML 呢？

往往更聪明。提取文字，加上 Markdown 的标题和列表语法（比敲标签快），让你的站点生成器去产出 HTML。和方法一同一套流程，打字更少。

嵌入 PDF 对无障碍不友好吗？

通常是的。浏览器 PDF 查看器内部的屏幕阅读器支持参差不齐，无标签的 PDF 在哪儿都读得艰难。无障碍重要的话，把内容做成真 HTML——哪怕是嵌入件旁边的一个简化版。