2026 年 PDF 转 Markdown 工具对比：按文档类型选方案
选 PDF 转 Markdown 工具，先看你的文档里有什么，再看转换结果能不能进入后续流程。文字是否完整、阅读顺序是否正确、表头能不能对应到数值、扫描页有没有漏、公式有没有变，这些比工具的技术标签更重要。
可选中文字的单栏 PDF，可以先用本地提取器做基线。扫描件需要启用 OCR。复杂表格和多栏排版，则要比较具体的结构恢复效果，不能预设文本提取一定不行，也不能预设视觉模型一定更好。
我们是 Markovo 的开发者。本文会介绍 Markovo 这个托管选项，但不把它包装成独立评测的冠军。官方能力说明在 2026 年 10 月 19 日修订时核对；下文实测数据来自 10 月 6 日的历史合成 PDF 实验，不是对所有工具最新版本的一次新横评。
先判断文档类型
| 你的文档 | 可以先试的路线 | 是否可用，主要看什么 |
|---|---|---|
| 可选中文字的单栏正文 | 本地文本提取或轻量 Markdown 转换 | 句子是否完整、段落是否按顺序排列、需要的标题结构是否保留 |
| 带简单表格的电子 PDF | Markdown 转换器或可配置的表格提取器 | 表头、单位、行列对应关系，以及输出的表格格式 |
| 多栏报告、论文 | 支持版面分析的提取路线，可结合模型 | 跨栏顺序、图注、侧栏、跨页衔接 |
| 扫描件或电子页与扫描页混合的 PDF | 明确启用 OCR，必要时增加版面处理 | 每个需要的页面是否恢复文字，嵌入图片里的文字是否遗漏 |
| 公式较多的资料 | 数学识别，或可靠的原生文本提取 | 符号、上下标，以及公式渲染后的含义 |
| 敏感或限制外传的文件 | 已获批准的本地或私有部署 | 数据去向、依赖、模型下载和远程调用 |
一份 PDF 可能同时落在几行里。第一页文字正常，不代表附录里的扫描页也处理了；表格看起来整齐，也不代表金额对应到了正确的项目。
比较技术路线，不给工具划“代际”
一个转换器可以同时使用几种技术：
- 文本与几何信息提取。 读取 PDF 已有文字和位置信息，减少对可靠文本重新识别带来的错误，但仍需要处理阅读顺序和结构。pdfminer.six 本身就有版面分析机制，不能把所有文本提取器都说成“按文件顺序倒出文字”。
- OCR。 从像素中识别文字。需要的文字不在可用文本层里，就要走这条路。OCRmyPDF 可以为扫描 PDF 增加可搜索的文本层，但它的输出本身不等于一份完成结构整理的 Markdown。
- 版面和表格恢复。 判断正文块顺序、单元格关系，以及标题、图和图注之间的关系，可以使用几何规则、模型，或两者结合。
- 视觉语言模型处理。 从渲染后的页面生成结构化内容。仍然要检查漏字、数字变化和数学符号错误。
这些路线可以组合使用，不是从低到高的成熟度排名。混合处理并不天然比端到端视觉模型差。核心是结果是否满足需求，以及修复结果需要花多少成本。
主流工具分别适合评估什么
下面区分“官方文档支持什么”和“本文实际测过什么”。没有出现在后面历史结果中的工具，不代表我们在这次实验里跑过它的 PDF 转换。
| 工具 | 官方描述的主要用途 | 部署和选型时要核对的边界 |
|---|---|---|
| pdfminer.six / pypdf | 本地 PDF 文本提取，版面相关选项因工具而异 | Markdown 结构需要另外生成或检查；pypdf 本身不是 OCR 引擎 |
| pdfplumber | 字符与几何信息检查、文本提取、可配置的表格提取和可视化调试 | 表格区域和策略需要匹配文档；只跑 extract_text，不等于测试过它调优后的表格能力 |
| PyMuPDF4LLM | 面向 Markdown 的提取，提供表格、图片、分页、版面和 OCR 控制 | 当前项目仓库 说明相关代码已迁入 PyMuPDF 2.x。本文的 1.28.2 历史测试不能当成当前安装方案 |
| MarkItDown | 用统一接口转换多种格式 | 本地 PDF 提取、可选 OCR 插件和 Azure 后端是不同配置，不能混为一谈 |
| OCRmyPDF | 为扫描 PDF 增加可搜索文本层 | 后续仍要安排 Markdown 和版面转换；识别出文字不等于恢复了表格结构 |
| Docling | 结构化文档转换，支持版面、表格、OCR 和多种导出 | 需要选择管线和导出选项；公式、图片增强 是可配置功能，不能用某个默认结果概括全部能力 |
| Marker | 结合版面、OCR 的文档处理，输出 Markdown 或 JSON | 核对模式、推理后端、模型要求和许可；当前文档同时包含 CPU、Apple Silicon 和 GPU 路线 |
| MinerU | 提供多种本地处理配置的模型解析方案 | 硬件和依赖随档位、后端变化，不能笼统写成所有配置都必须用 NVIDIA GPU |
| olmOCR | 基于视觉语言模型的文档处理工具链 | 核对模型服务要求、输入覆盖、输出格式和部署成本 |
| Mathpix | 识别文字、公式、表格等 STEM 内容，输出 Mathpix Markdown | 核对 Markdown 扩展语法兼容性、价格、数据保留和部署方式；官方也提供 Private Cloud OCR 说明，不能写成“只有托管” |
| Markovo | 网页和已认证开发者接口中的托管转换 | 检查实际 Markdown 和 bundle 内容、账号要求、Credits 估算及源文档保真度；服务质量字段不等于独立正确率 |
采用前，要看你实际使用的代码、模型和服务各自的条款。“开源”不代表算力免费、模型许可都相同，或部署没有其他要求。本文不替你的具体应用作法律判断。
历史 PDF 实验说明了什么
2026 年 10 月 6 日的实验包含八份合成 PDF，每份都有对应的预期内容。环境为 Python 3.11.14，运行的是：
- MarkItDown 0.1.8，本地转换，关闭插件。
- PyMuPDF4LLM 1.28.2，记录中的默认调用。
- pdfplumber 0.11.10，只做原始文本提取。
- Markovo，使用记录中的 10 月 6 日服务批次输出，评分时读取缓存。
可以查看完整分数和指标定义、本地运行记录和 Markovo 缓存批次记录。这组实验不能证明 Marker、MinerU、Docling 的 PDF 路线、olmOCR、Mathpix、MarkItDown OCR 插件或 Azure 后端在这些样本上的表现。
| 指定样本上的检查 | MarkItDown | PyMuPDF4LLM | pdfplumber 文本基线 | Markovo 缓存输出 |
|---|---|---|---|---|
| 单栏正文召回 / 顺序 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 |
| 简单表格行内容 / 叶子表头 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 |
| 双栏正文召回 / 顺序 | 0.1111 / 0.8 | 1.0 / 1.0 | 0.1111 / 0.8 | 1.0 / 1.0 |
| 纯扫描页句子召回 | 0.0 | 0.0 | 0.0 | 1.0 |
| 混合文档页面锚点覆盖 | 0.6667 | 0.6667 | 0.6667 | 1.0 |
| 线性公式归一化字符串召回 | 1.0 | 0.75 | 1.0 | 0.5 |
这些是特定检查的结果，不是通用文档准确率。行内容和表头指标检查的是预期字符串是否出现在同一输出行，不验证合并单元格的语义。公式指标检查归一化后的表达式字符串，不证明数学等价。
Markovo 批次全部记录了 from_cache=true 和 elapsed_s=0.0，不能拿这个零做速度对比。费率版本也不是转换器实现版本。前面工具表中的当前能力，不等于 10 月 6 日测试时启用的配置。
阅读顺序：检查完整段落，别只搜关键词
在双栏样本里，MarkItDown 和原始 pdfplumber 文本出现了跨栏句子交错，PyMuPDF4LLM 和 Markovo 保留了被测句子顺序。因此，不能笼统说基于文本的 Markdown 工具一定处理不好双栏。
换成你的文件，至少检查一段跨栏正文、一处图注和一块侧栏。关键词都在，但片段顺序错了，文章仍然读不通。反过来，一页规则的双栏论文通过，也不能推导所有期刊排版都能通过。
表格：既看对应关系，也看输出格式
简单发票样本中，四条路线都保留了预期行内容和叶子表头。MarkItDown 和 PyMuPDF4LLM 输出管道表格；原始 pdfplumber 文本没有管道表格；Markovo 输出 HTML 表格。
合并表头和旋转表头样本中，MarkItDown、PyMuPDF4LLM 的行内容检查通过，但叶子表头检查没有通过。Markovo 两项字符串检查都通过了，但这仍然不能证明父表头跨列关系和所有数值归属都正确，需要对照 PDF。
比“有没有表格”更有用的问题是：后续读者能不能不靠猜测，找出正确的项目、数量、单价和总额？
扫描和公式：分开验证
被测本地配置没有恢复扫描句子，Markovo 缓存结果恢复了。这不代表这些本地项目没有其他 OCR 路线。比如 MarkItDown 有可选 OCR 插件和 Azure 集成，PyMuPDF4LLM 的官方文档也描述了 OCR 配置。
同一实验里的线性公式样本，按保存的匹配规则，本地文本路线得分高于 Markovo。这些是文本形式的表达式，不是空间排版的分式或矩阵。扫描文字识别得好，不能直接推出公式保真；LaTeX 看起来合理，也不代表减号或下标一定正确。
一份合成 PDF 的实际输出
下面是 table-simple.pdf 对应的完整 Markovo 历史输出，可以在 PowerPoint 文章的独立 PDF 探针文件中核对。这里展示的是 PDF 结果，不是 Excel 仪表盘转换：
## Quarterly invoice summary
<table><tr><td>Item</td><td>Qty</td><td>Unit Price</td><td>Total</td></tr><tr><td>Consulting hours</td><td>12</td><td>85.00</td><td>1020.00</td></tr><tr><td>Data export fee</td><td>3</td><td>40.00</td><td>120.00</td></tr><tr><td>Template license</td><td>1</td><td>190.00</td><td>190.00</td></tr><tr><td>Support retainer</td><td>6</td><td>55.00</td><td>330.00</td></tr><tr></tr></table>
这份结果保留了有用的表格内容，但包含原始 HTML，最后还有一个空行。要放进实际渲染器和解析器里检查。如果下游支持管道表格，却会过滤 HTML，就需要换一种表示方式，或经过验证后再转换表格格式。
服务文档列出了 Markdown、资源文件、源映射、质量报告等交付内容，但仍要检查这次任务实际返回了哪些文件。它们方便复核，不代表每张图、每个公式、每一页都已经正确。
用自己的文档怎么比较
- 挑一小组有代表性的文件。 普通页面和难页面都要有，覆盖工作里实际出现的多栏、合并表头、旋转标签、扫描件、低清图片和公式。
- 先写验收条件。 明确要求完整段落、正确的表头与数值对应、必要页面和公式；需要链接、图片资源，也一并检查。
- 记录配置。 保存工具和模型版本、OCR 与增强开关、硬件、页码范围、输出格式。
- 保留未修改的原始输出。 把转换效果和后处理分开，不要把人工修复变成未披露的优势。
- 测试真正的使用环境。 渲染 Markdown，运行实际解析或检索流程。表格在转换时保住了，也可能在 HTML 清洗或切块时丢失。
- 算总成本。 包括运行时间、模型部署、托管费用、人工复核、失败任务和重试。冷启动与稳定运行、缓存与新转换要分开统计。
公开数据集可以补充你的样本。OpenDataLoader-Bench 评估阅读顺序、表格和标题；DP-Bench 是另一套文档解析评测资源。引用之前，检查数据集版本、引擎配置和具体输出。自己跑出的结果，不能在官方榜单没有收录时写成“官方排名”。
什么情况下值得试 Markovo
如果你更想用托管流程，而不是维护本地提取器和模型依赖，可以从 PDF 转 Markdown 开始。先看费用估算和账号要求，再把下载结果与原文件对照。开发集成以当前 API 和 CLI 文档为准。
输入本来就是图片，可以走图片转 Markdown。如果你还有原始 Word、Excel 或 PowerPoint，则应该另外评估原生格式转换。XLSX 表格转得好，不代表 PDF 表格也转得好；只有幻灯片画面的 PDF，也不能提供源文件里没有包含的演讲者备注。
常见问题
2026 年有没有一款通用最好的工具？
本文的证据不能支持这个结论。先按文档类型、部署限制和输出要求缩小范围。即使在八份小型合成 PDF 里，不同路线也各有差异，而且这组实验没有覆盖所有工具和当前版本。
做 RAG 就一定需要视觉模型吗？
不一定。可靠的原生文本可能已经包含检索需要的内容。源文件需要 OCR 或版面处理时，再引入相应步骤，同时检查切块后是否保留标题、表格上下文、单位和来源。提取时漏掉的页面，检索阶段补不回来。
转成 Markdown 后，能保留 PDF 的设计吗？
应把它当作内容和结构提取，而不是原始版面的替代品。视觉关系重要时，保留源图片或页面引用，并检查下游是否支持输出的表格和数学语法。
文档写着“支持 OCR”，就够了吗？
不够。要核对版本、引擎、语言数据、模型或服务配置，以及需要的内容是否真的经过识别。最后仍然要与源文档比较。
要进一步排查本地方案，可以看 MarkItDown 的 PDF 提取与 OCR 路线和 Python 中的 PDF 转 Markdown。先选能通过验收的简单路线，再把难页面留在可复核的流程里。