PyMuPDF vs pdfplumber vs pypdf：PDF 文本提取实测对比（翻译预处理视角）

前言

做 PDF 翻译预处理时，第一步永远是"把文本从 PDF 里干净地拿出来"。这一步的选型直接决定后面整条流水线的质量：提取出来的文本顺序乱了，翻译对齐就废；坐标信息丢了，版面重建就没戏。网上三库对比的文章不少，但大多停留在"都能提取文本"的层面。本文以翻译预处理为视角，在真实的 30 页报告 PDF 上跑了一轮量化实测，把文本速度、表格提取、坐标信息三个硬指标摆出来，结论直接可用。

测试环境：Windows 11，Python 3.13，pymupdf 1.28.2 / pdfplumber 0.11.10 / pypdf 6.18.0。

评测对象

• PyMuPDF（import pymupdf）：基于 MuPDF C 库，主打速度和渲染能力，1.28 起官方推荐 import pymupdf。
• pdfplumber：基于 pdfminer.six 的封装，API 友好，表格提取是招牌功能。
• pypdf：纯 Python 实现，零编译依赖，pypdfium/pikepdf 生态之外的轻量选择。

测试文档构造

用 fpdf2 生成一份 30 页的英文报告 PDF（36 KB），每页含 6 个小节标题+段落，页尾一张 4 行 3 列的表格。全文 41090+ 字符，纯文本型 PDF（非扫描件）。生成脚本：

from fpdf import FPDF

pdf = FPDF()
pdf.add_page()
pdf.set_font("helvetica", "B", 16)
pdf.cell(0, 10, "Quarterly Report - Section 1")
# ... 正文段落 + 页尾表格（Region/Revenue/Growth）
pdf.output("test_report_30p.pdf")

评测代码

import time, pymupdf, pdfplumber
from pypdf import PdfReader

PDF = "test_report_30p.pdf"

# --- PyMuPDF ---
t0 = time.perf_counter()
doc = pymupdf.open(PDF)
mu_text = "\n".join(p.get_text() for p in doc)
mu_time = time.perf_counter() - t0

t0 = time.perf_counter()
mu_tables = [t for p in doc for t in (p.find_tables().tables)]
mu_table_time = time.perf_counter() - t0

# --- pdfplumber ---
t0 = time.perf_counter()
with pdfplumber.open(PDF) as pdf:
    pl_text = "\n".join(p.extract_text() or "" for p in pdf.pages)
pl_time = time.perf_counter() - t0

t0 = time.perf_counter()
with pdfplumber.open(PDF) as pdf:
    pl_tables = [t for p in pdf.pages for t in (p.extract_tables() or [])]
pl_table_time = time.perf_counter() - t0

# --- pypdf ---
t0 = time.perf_counter()
pp_text = "\n".join((pg.extract_text() or "") for pg in PdfReader(PDF).pages)
pp_time = time.perf_counter() - t0

print(len(mu_text), mu_time, len(pl_text), pl_time, len(pp_text), pp_time)

评测结果

文本提取速度与完整性

库	提取字符数	耗时（30页）	相对速度
PyMuPDF	41120	0.042 s	1x
pypdf	41090	0.075 s	1.8x
pdfplumber	41090	0.780 s	18.6x

三个库提取的文本内容抽样比对完全一致（段落顺序、换行位置都相同），字符数的 30 字差异来自 PyMuPDF 对空白字符的处理略有不同。翻译预处理场景下三库的文本质量都在及格线以上，差异主要在速度和附加能力上。

这个"三库结果一致"其实值得多说一句：文本型 PDF 的字符映射（ToUnicode CMap）是规范操作，谁来读都是同一份字典，所以只要不是字体子集损坏的疑难文档，三库在文本正确性上拉不开差距。真正拉开差距的是下面这些"文本之外"的能力——毕竟翻译预处理的痛点从来不是"拿不到文字"，而是"拿不到结构"。

速度上 PyMuPDF 断层领先：30 页 0.042 秒，比 pdfplumber 快 18.6 倍。这意味着批量处理 500 份文档时，PyMuPDF 约 21 秒，pdfplumber 要 6.5 分钟。当然 pdfplumber 慢的代价换来了更细粒度的版面对象解析，见下文。

表格提取

库	API	检出表格数（30页）	耗时	输出质量
PyMuPDF	page.find_tables()	30	0.797 s	4行x3列，含表头
pdfplumber	page.extract_tables()	30	0.782 s	[['Region','Revenue','Growth'], ['EMEA','1.2M','8%'], ...]
pypdf	无内置支持	—	—	—

两者表格检出率相同（30/30），PyMuPDF 的 find_tables() 输出可直接调 .extract() 拿到二维列表；pdfplumber 的输出结构更"开箱即用"，直接就是嵌套列表。有意思的是两者表格提取耗时接近（都是对全部 30 页做表格检测），说明瓶颈在几何分析而非各自引擎。

pypdf 没有表格提取能力，这一局直接出局。

大文件扩展性测试（114 页）

把 30 页报告拼接成 114 页（约 146 KB / 16.4 万字符），模拟批量翻译的真实体量：

库	30 页耗时	114 页耗时	折算 500 页估计
PyMuPDF	0.042 s	0.079 s	~0.4 s
pypdf	0.075 s	0.303 s	~1.5 s
pdfplumber	0.780 s	5.540 s	~27 s

114 页下 pdfplumber 比 PyMuPDF 慢约 70 倍，差距随页数进一步拉大（小文件上还只是 18 倍）。批量处理几百份文档的场景，这个差距是分钟级和秒级的区别。pypdf 的纯 Python 提取速度意外地不错，处在两者之间。

依赖与工程成本

库	安装体积	依赖链	版本迭代活跃度
PyMuPDF	~20 MB（含 MuPDF C 扩展）	无额外依赖	高，且注意 1.24+ 推荐 import pymupdf
pdfplumber	轻	依赖 pdfminer.six	稳定
pypdf	极轻	纯 Python 零编译	稳定

工程上唯一要注意的坑是 PyMuPDF 的 API 变更：老代码里到处都是 import fitz，新版本会提示 deprecation，新项目统一用 import pymupdf，避免将来升级时全量替换。

词级坐标获取方式对比

翻译后重建版面（或做双语对照排版）必须有词级坐标，三库的获取代码：

# PyMuPDF：词级 8 元组 (x0, y0, x1, y1, word, block_no, line_no, word_no)
words = doc[0].get_text("words")
# 实测输出: (31.18, 30.20, 102.32, 52.23, 'Quarterly', 0, 0, 0)

# pdfplumber：词级字典，含 x0/x1/top/bottom
words = pdf.pages[0].extract_words()
# 额外还能拿到 chars / lines / rects / curves 等全部底层版面对象

# pypdf：无结构化坐标输出

• PyMuPDF：8 元组含完整 bbox，够用；
• pdfplumber：字典形式 + 全量底层对象（字符级坐标、线条、矩形），版面分析深度是独门优势；
• pypdf：只有 extract_text()，拿不到结构化坐标。

结论与选型建议

场景	推荐	理由
大批量文档翻译预处理	PyMuPDF	速度碾压，词级坐标齐全，表格也能提
需要精细版面分析（栏检测、字符级定位）	pdfplumber	chars/lines/rects 全量对象，解析最深
轻量脚本、零编译依赖环境	pypdf	纯 Python，装了就能跑，文本质量够用

再补充三个实测过程中确认的细节，选型时可能用得上：

其一，pdfplumber 的慢不是白慢的。 它底层用 pdfminer.six 把每个字符都解析成独立对象，所以能拿到字符级 bbox、线条、矩形这些"原材料"。做双栏检测、复杂嵌套表格这类深度版面分析时，只有它能给到足够细的原始数据。PyMuPDF 的解析是面向渲染优化的，粒度到词和块，一般场景够用，但字符级需求就到顶了。

其二，表格检测的算法路线不同但结果趋同。 PyMuPDF 的 find_tables() 和 pdfplumber 的 extract_tables() 在这份规整文档上检出率都是 30/30。但如果换成无线框表格（只有对齐空格没有边框线），两者都会退化，需要调参数（pdfplumber 的 text_strategy、PyMuPDF 的策略参数），这时候先拿小样本试参数再批量跑，别直接全量。

其三，pypdf 并非没有价值。 在受限环境（无法编译 C 扩展的服务器、AWS Lambda 这类）里，纯 Python 的 pypdf 是唯一选择，而且它的文本提取速度在 114 页测试中只比 PyMuPDF 慢 4 倍，作为"能跑就行"的兜底方案完全合格。

我的实际工作流是：批量环节用 PyMuPDF 做初筛和文本提取，遇到复杂版面（多栏、嵌套表格）再切 pdfplumber 精处理。两者互补而非替代。如果只能装一个库，翻译预处理场景选 PyMuPDF。

最后补一句务实的判断：这套对比的价值不在于"哪个库最强"，而在于把翻译预处理的验收标准定下来——文本完整、顺序正确、词级坐标可取、表格结构不散。三库横评只是手段。选型时先明确你的流水线在"版面重建"上走多深，再回头选库，比看任何 benchmark 都靠谱。

参考资料

• PyMuPDF 文档：https://pymupdf.readthedocs.io/
• pdfplumber 文档：https://github.com/jsvine/pdfplumber
• pypdf 文档：https://pypdf.readthedocs.io/

标签：PDF翻译、PyMuPDF、pdfplumber、pypdf、Python