PDF → HTML 转换器，免费

关于 PDF → HTML 转换

此工具使用 PDF.js 从 PDF 文件中提取文本并将其渲染为语义化 HTML。非常适合将文档转换为 Web 兼容格式、归档内容或为后续处理准备文本。

常见用途

• 文档归档· 将 PDF 转换为 HTML，用于长期数字保存和网页访问。
• 内容迁移· 将 PDF 中的文本提取为结构化 HTML，用于 CMS 或网页发布。
• 文本提取· 从 PDF 获得干净的文本用于分析或复用。
• 网页发布· 将文档转换为 Web 兼容格式，加载快速，可访问性更好。
• 数据处理· 为进一步的转换或集成准备 PDF 内容。

常见问题

支持多大的 PDF？

此工具可处理约 10 MB 以内的 PDF，具体取决于您的浏览器。非常大或复杂的 PDF 处理时间可能更长。

它会保留 PDF 的格式吗？

工具提取文本内容并以段落形式渲染。复杂的版式、图片和样式会被简化为干净的 HTML。

可以下载 HTML 吗？

可以。点击「下载 HTML」将转换后的内容保存为 .html 文件，可在任意浏览器或编辑器中打开。

PDF简史：从PostScript到可移植页面

可移植文档格式（PDF）是约翰·沃诺克（John Warnock）的创意，他是Adobe Systems的联合创始人，此前曾共同发明了PostScript（一种页面描述语言，自1985年与Apple LaserWriter结合，开创了桌面出版的可能）。PostScript功能极为强大，但它是一种编程语言而非文档格式：PostScript文件描述的是如何在解释器中渲染页面，并非真正为了跨机器阅读、编辑或在缺乏正确字体的机器上一致渲染而设计。

1991年，沃诺克在Adobe内部流传了一份备忘录，后来被称为Camelot项目。其前提是：Adobe应该构建一种单一文件格式，能够捕获任何文档（包括字体、排版、矢量图形和图像），并在任何计算机、任何操作系统上完全一致地重现，无论最初由哪个应用程序创建。待方案细化之后，这个项目有了产品名称：Adobe Acrobat。

Acrobat 1.0和PDF 1.0于1992年11月在拉斯维加斯举办的Comdex Fall贸易展上展示，并于1993年6月向用户发货。Adobe于1994年做出了关键商业决策：开始免费提供Acrobat Reader，这一举措与HTML浏览器的做法如出一辙，在数百万设备上播下了安装的种子。该格式经历了多次修订：PDF 1.1（1996年，外部链接和安全性）、1.2（1996年，AcroForms）、1.3（2000年，数字签名）、1.4（2001年，透明度）、1.5（2003年，对象流和JPEG 2000）、1.6（2004年，OpenType和3D）、1.7（2006年）。2008年，PDF 1.7以ISO 32000-1:2008发布；PDF 2.0随后以ISO 32000-2:2017发布，其实质性修订的第二版（ISO 32000-2:2020）纳入了勘误并成为当前权威参考。

在主标准之外还存在几种专业PDF配置文件：PDF/A（ISO 19005-1:2005，以及2011年的-2版和2012年的-3版）是归档配置文件，禁止依赖外部资源或未来软件的功能（不支持JavaScript、音频、加密，字体必须嵌入）；PDF/X是印刷行业使用的印前配置文件；PDF/E是工程图纸的工程配置文件；PDF/UA（ISO 14289-1:2014）是无障碍配置文件，要求具备逻辑结构和标签，以便屏幕阅读器能够按阅读顺序呈现内容；PDF/VT是个性化信函合并中使用的可变事务配置文件。

PDF转HTML在结构上为何如此困难

在最底层，PDF是一组编号对象（字典、数组、字符串、数字、名称和二进制流）的集合，末尾有一个交叉引用表，使读取器无需解析整个文件即可跳转到任意对象。这些对象形成一棵以Catalog对象为根的树，指向Pages树，Pages树包含Page对象。每个Page引用一个内容流：即实际绘制页面的指令。

内容流是一系列紧凑的图形操作符，使用一种与PostScript相关但非图灵完备的小型语言。对于文本，它使用Tf（设置字体和大小）、Td（移动文本位置）、Tm（设置文本矩阵）、Tj（显示字符串）、TJ（显示带有可选字符间距偏移量的字符串数组，用于字距调整）以及ET（结束文本）。关键之处在于一切都是基于位置的。正文段落并不是以段落的形式存储，而是以一系列Tj或TJ命令的形式存储，每条命令在页面特定x和y坐标处绘制一个或一小段字形。这里没有句子、段落、标题、列表或栏的概念，只有每个字符在物理上所处的位置。

HTML与之相反：它是一种语义元素的流式树，布局由渲染器负责，同一份HTML可以自适应手机、桌面或屏幕阅读器。因此，PDF转HTML需要逆向工程出PDF从未被要求记录的结构。转换器必须查看每页上文本的空间分布并推断出：

• 哪些字符属于同一个单词（通过将字形间距与字体的平均步进宽度进行比较）；
• 哪些单词属于同一行（通过在容差范围内对y坐标聚类）；
• 哪些行属于同一段落（通过检测基线差异和缩进模式）；
• 哪些段落属于同一栏（通过查找空白的垂直分隔区）；
• 以及多栏、脚注和旁注之间的阅读顺序。

这些问题都无法通过按顺序读取内容流来解决，因为流中的顺序不一定是阅读顺序。生成PDF的排版引擎可能按照最高效的渲染顺序绘制元素，这可能是自上而下的锯齿形、按字体分组或按颜色分组。单个段落的文本在底层流中可能与相邻段落的文本交错排列。这就是为什么仅按流顺序拼接字符串的PDF提取器，在处理任何比单栏小说更复杂的文档时都会产生乱序输出。

如果PDF已被标记（即作者在视觉内容旁附带了结构树），工作就会容易得多。已标记的PDF包含一层结构元素的层次（P表示段落，H1到H6表示标题，L表示列表，LI表示列表项，Table、TR、TD、Figure、Caption），与HTML的语义词汇相对应。PDF/UA正是为了无障碍访问而强制要求标记，因为未标记的PDF对辅助技术基本上是不透明的。然而在实际中，大多数实际中的PDF要么未标记，要么被创作工具打上了错误的标签，因此即使标签存在，健壮的转换器也必须回退到布局分析。

主要开源PDF渲染库

PDF.js是由Mozilla编写的JavaScript库，于2011年6月以安德烈亚斯·加尔（Andreas Gal）领导的实验性项目形式启动。它完全使用HTML5 canvas和JavaScript在浏览器中解析并渲染PDF，无需任何原生插件。PDF.js从2013年3月的Firefox 19开始作为默认PDF查看器被捆绑到Firefox中，取代了Adobe Reader插件。它提供了一个JavaScript API，可提取带有位置元数据的文本内容（每个文本段落返回其x、y、宽度、高度、字体名称和字体大小）。本工具基于PDF.js构建。

Poppler是一个C++库，派生自xpdf（一款由Glyph and Cog自1990年代末持续维护的老牌PDF查看器）。Poppler为Linux桌面环境的PDF渲染功能（GNOME的Evince、KDE的Okular）、pdftotext和pdftohtml命令行工具以及众多服务端PDF处理流水线提供支持。MuPDF由Artifex Software开发（与Ghostscript维护方为同一公司），是一个面向嵌入式应用的更小、更快的C语言库。PDFium是内置于Google Chrome和Microsoft Edge中用于PDF查看的引擎；它是Foxit专有PDF SDK的一个分支，由Google和Foxit于2015年5月联合开源。qpdf是一个C++库和命令行工具，专注于结构操作而非渲染，可在不改变视觉内容的前提下解压、加密、解密、线性化和重写PDF。

在专门生成HTML输出方面，最重要的专用项目是pdf2htmlEX，最初由卢旺（Lu Wang）于2012年编写，现由社区组织维护。pdf2htmlEX采用了与大多数转换器不同的方式：它不尝试重构语义化HTML，而是通过为每个文本段落输出绝对定位的div元素、将原始字体嵌入为网络字体（WOFF）文件并在必要时使用CSS变换，尽可能忠实地再现PDF的视觉布局。结果是一个在外观上与原始PDF难以区分的网页，但底层HTML却是一堆缺乏语义意义的position: absolute定位span。

布局保真度与语义流：核心权衡

这是PDF转HTML的核心权衡：你可以拥有布局保真度，也可以拥有语义流，但两者兼顾极为困难。以pdf2htmlEX为代表的保真度优先转换器生成的输出在打印和外观上与原文档一致，但对屏幕阅读器不透明，在手机屏幕上也无法灵活自适应。以pdftotext或PDF.js的getTextContent为代表的语义流优先转换器，经简单段落重建后可生成清晰、可读、无障碍的HTML，但会丧失原文档的视觉丰富性，包括颜色、精确字体、图片位置、表格网格以及原始页面的版式感。

Absolutool的本工具坚定地站在语义流优先的一侧。它使用PDF.js提取文本内容并以段落形式输出，将可读性、无障碍性和小文件体积置于像素级精确还原之上。如果您需要视觉还原方案（每个字形保持原始位置、嵌入原始字体、精确保留分页）pdf2htmlEX是值得参考的工具；如果您需要可读段落方案（内容复用、网络发布、可搜索索引的HTML、屏幕阅读器可访问的输出）本工具则完全适合。

嵌入字体、图片与底层矢量内容

PDF可以嵌入任意字体，想要保留原始外观的转换器有三种选择。嵌入并提供：转换器从PDF中提取每种嵌入字体，将其重新打包为浏览器可理解的网络字体格式（WOFF，或自2018年起带有更激进Brotli压缩的WOFF2），并在生成的HTML中链接。这可以保留原始外观，但会增大文件体积，如果字体的嵌入权限不包括网络再发行，还可能产生许可证问题。替代：将每种嵌入字体映射到类似的系统字体（PDF中的衬线字体可能变成Times New Roman或Georgia），以换取更小、更干净的输出，代价是一定程度的视觉偏差。忽略：完全丢弃字体信息，让浏览器应用默认正文字体，这正是大多数语义流优先转换器的做法，因为用户会在浏览器的正常样式中阅读HTML。

图片面临类似的选择。转换器可以将嵌入图片提取为单独文件并在HTML中引用；将整页光栅化为图片并内联嵌入（将PDF变成美化版的图片画廊）；或者完全丢弃图片只输出文本，这正是本工具的选择，适合内容复用而非视觉还原。矢量内容（PDF图形操作符绘制的线条、形状和路径）更加棘手，因为在语义HTML中没有干净的表示方式；想要保留矢量内容的转换器往往回退到内联SVG或PNG光栅化。

当PDF只是图片时：扫描文档的OCR回退

实际中相当大比例的PDF从结构意义上说根本不是文档，而是纸质文档的扫描图像，被封装在PDF外壳中，因为PDF是通过互联网传递类纸张内容的通用格式。扫描PDF没有文本内容流；每页都是一张恰好描绘了文字但并不以机器可读字符形式包含文字的光栅图像。从此类PDF中提取文本需要光学字符识别（OCR），这从根本上不同于文本提取操作。

最主要的开源OCR引擎是Tesseract，最初由惠普实验室于1985年至1995年间开发，2005年开源，2006年起由Google维护，直至2018年前后Google将主要维护权移交给社区组织。Tesseract支持超过一百种语言，可在所有主流平台上运行，为无数桌面和服务端工具的OCR功能提供支持。苹果的Vision框架自2017年起在macOS和iOS上可用，包含操作系统内置截图和照片应用所使用的快速精准文本识别API。Google Cloud Vision、Azure Computer Vision和Amazon Textract是主要的云端OCR服务；专门针对文档，Textract和Azure的文档智能（Document Intelligence）都超越了纯OCR，可识别表格、键值对和表单字段。

完全在客户端运行的基于浏览器的PDF转HTML转换器通常无法执行OCR：OCR模型至少需要数十MB，而在用户笔记本上进行交互式推理速度太慢。如果您的PDF包含无可提取文本的扫描页，本工具将为这些页面生成空输出，正确的下一步是使用专用OCR工具或服务端服务。

为何需要将PDF转为HTML

使用场景可归纳为几类反复出现的模式：

• 拥有历史报告存档的出版商：年度报告、白皮书、研究报告、政府出版物、技术手册，将PDF转为HTML，使内容可直接在浏览器中阅读，无需强制每位访客下载文件。HTML版本更易于导航（可链接到特定章节）、在手机上加载更快，且可被搜索引擎爬取。
• 博主和内容营销人员将自己创作或获得授权的PDF转为HTML，以便将内容作为文章重新发布，无需重新输入即可复用文字。
• 网络档案员将PDF转为HTML作为保存项目的一部分，理由是HTML在数十年时间跨度上比规范长达数千页的复杂二进制格式更具持久性。
• 移动阅读应用和稍后阅读服务将PDF转为HTML，使文章可在其阅读视图中打开，提供用户偏好的字体和字号、深色模式及可调行长。
• 屏幕阅读器用户将PDF转为HTML，因为未标记的PDF对辅助技术基本上不透明，但带有适当段落和标题的HTML渲染可以清晰朗读。
• 知识管理工作流将PDF转为HTML，以便将内容输入搜索索引、全文数据库和大型语言模型的上下文窗口，这些系统都不能原生理解PDF格式，但都能很好地处理纯文本和HTML。
• 研究人员和学者从期刊论文PDF中提取文本，输入文献管理工具、参考数据库或文本挖掘流水线，以便在数千篇论文中查找模式。

这些场景各有略微不同的需求，但有一条共同主线：用户需要的是PDF的内容（文字、结构、含义），而不受原始文档所选择的刚性分页格式的束缚。

更多问题

为什么转换后的HTML看起来与原始PDF不同？

本工具采用语义流优先方式：提取文本并以浏览器默认字体输出整洁的段落，将可读性、无障碍性和可检索性置于视觉保真度之上。如果您需要原始布局的像素级精确还原（嵌入字体、精确定位、原始颜色），请参考保真度优先工具，如pdf2htmlEX（它输出与源PDF视觉上匹配的绝对定位div元素，但其HTML对屏幕阅读器基本上不可读，在手机屏幕上也无法自适应）。

为什么我的多栏PDF输出是乱序的？

PDF不存储阅读顺序，只存储位置。转换器必须从文本的空间分布推断栏的边界。对于简单的两栏布局，启发式算法通常有效；对于复杂布局（包含旁注、与正文文本交错的脚注或跨越栏间隔的文本），可能产生乱序输出。如果您有已标记的PDF（包含结构树的PDF），准确率会大幅提高；对于未标记的PDF，结果取决于栏与栏之间的物理空白是否清晰。

我的PDF是扫描件（只有图片），为什么什么都提取不到？

扫描PDF没有文本内容，每页都是文本的光栅图像，而不是解析器可以读取的文本。提取文本需要OCR（Tesseract、Google Cloud Vision、苹果的Vision框架等），这是与PDF解析根本不同的操作。本工具不捆绑OCR引擎，因为这些模型太大，无法随浏览器工具一起发布。正确的下一步是专用OCR服务或内置OCR的桌面工具。

我可以转换受密码保护的PDF吗？

如果PDF设置了打开密码（只有输入密码才能查看），PDF.js会抛出错误而不进行转换。如果PDF只设置了权限密码（可以自由打开，但打印/复制受限），行为会有所不同：大多数现代PDF.js版本会遵守权限设置，可能拒绝提取文本。无论哪种情况，最简便的方法是先在原始PDF工具中移除保护，再进行转换。在您合法拥有的PDF上移除保护是允许的；在您不拥有的PDF上这样做则可能不合法。

相关工具