)
前言
用 Python 从 PDF 里抠表格，是自动化办公里最容易「预期落空」的一项任务。很多人上手前的预期是：装一个库，调用一个「提取表格」的方法，拿到一个干净的二维数组。真实情况是——提取出来的东西常常串行、错列、把两列合成一列，或者干脆一个字都没有。
原因不在库，而在 PDF 这个格式本身。官方文档里有一句说得极好的话：当你在文档里看到一个表格时，你通常并不是在看一个嵌入的 Excel 或某种可识别的对象，它通常只是普通的标准文字，被排版成看起来像表格数据的样子。也就是说，PDF 里没有「表格」这个语义概念，只有散落在页面上的文字、坐标、线段和填充色。
理解了这一点，后面所有现象都能解释：为什么准确率不可能 100%、为什么换个文件同一段代码就失效、为什么扫描件里什么都读不到。本文先把这个前提讲透，再给出三条技术路线的取舍，最后附一个可以照着敲的实战案例。涉及第三方库的部分只讲用途、流程与典型调用骨架，具体参数与返回值以各库官方文档为准。
一、PDF 里究竟有什么
一份由排版软件导出的 PDF，内容大致是这几类对象：
| 对象 | 说明 | 对提取表格的意义 |
|---|
| 文字对象 | 每段文字带字体、字号、位置 | 是数据的真正来源 |
| 矢量线段 | 表格的横线与竖线 | 是判断「哪里有表格」的线索 |
| 矩形与填充 | 单元格底纹、斑马纹 | 辅助判断单元格边界 |
| 图像对象 | 扫描图片、截图 | 里面没有文字层，必须 OCR |
| 注释与表单域 | 表单控件 | 少数情况下可直接读字段 |
关键在于：这些都是「绘制指令」，不是「结构」。PDF 不知道第一行是表头、不知道哪几个字属于同一格。它只知道「在这条指令里，把这个字符串画在坐标 (x, y) 处」。
还有一个更麻烦的特性：PDF 里没有「行」的概念。排版引擎是按视觉行输出的，一段文字可能被拆成多条绘制指令；同一视觉行上的两列内容，可能是两条互不相关的指令。这就是为什么提取出来的文字常常「一行里塞了三列，另一行只有半列」。
二、三条技术路线
面对同一份 PDF，业界的做法大致分三类：
| 路线 | 做法 | 优点 | 局限 |
|---|
| 纯文本流 | 按阅读顺序取出文字，靠空白切列 | 实现简单、不依赖线框 | 依赖排版规整，列宽一变就失灵 |
| 几何分析 | 先找线框/边界框，再按框取字 | 对表格线清晰的 PDF 很准 | 无线框的表格失效 |
| 视觉模型 | 把页面当图，用模型识别表格区 | 能处理复杂版式 | 依赖模型与算力，结果需复核 |
成熟的库通常把前两条路线组合起来。以 PyMuPDF 为例，官方文档说明Page.find_tables()会把「识别表格区域、判断行列边界、按边界取字」这一整套流程包起来，并且强调它的优点是不依赖外部库、也不需要人工智能或机器学习技术。这是一个很有代表性的设计取舍：用几何规则换取可解释性和部署便利。
三、读文字：最基础的一步
无论走哪条路线，起点都是先把页面上的文字取出来。不同的库给出的粒度不同。
有的库直接给整页的纯文本，并且提供一种「尽量保留版面」的模式：
# 适用于 Python 3.9+
# 需要先安装：pip install pypdf
# 具体参数与返回值以 pypdf 官方文档为准
from pypdf import PdfReader
reader = PdfReader("report.pdf")
print(len(reader.pages), "页")
page = reader.pages[0]
# 默认模式：按阅读顺序拼接文本
text = page.extract_text()
# layout 模式：尽量按版面位置保留空白，更接近「看到的样子」
layout_text = page.extract_text(extraction_mode="layout")
print(layout_text[:500])有的库给的是「单词 + 坐标」，这对几何分析至关重要。以 PyMuPDF 为例，Page.get_text("words")返回的每个单词是一个元组，前四个元素是它的边界框坐标，第五个元素才是单词本身：
# 适用于 Python 3.10+
# 需要先安装：pip install pymupdf
# 具体参数与返回值以 PyMuPDF 官方文档为准
import pymupdf
doc = pymupdf.open("report.pdf")
page = doc[0]
# words 模式下，每一项的前四个元素是边界框坐标，第五个元素是文字本身
# 元组的完整构成请以 PyMuPDF 官方文档为准
words = page.get_text("words")
for w in words[:5]:
x0, y0, x1, y1, text = w[0], w[1], w[2], w[3], w[4]
print(f"坐标 x={x0:.1f} y={y0:.1f} 文字={text!r}")
doc.close()有了 (x, y) 坐标，你就能自己实现一套聚类逻辑：把 y 坐标相近的单词归为同一行，把 x 区间重叠的归为同一列。这正是所有几何路线的共同内核。
四、实战案例：一个只靠标准库的行列重构
下面这个例子刻意不依赖任何第三方库。它接收一段「已经取出来的页面文本」，用「连续两个以上空格视为列分隔」这条启发式规则，把文本还原成二维表。之所以这样设计，是因为它把提取问题中最通用的那一层逻辑抽了出来——任何库取来的文本，最后都要经过类似的处理才变成表格。
# 适用于 Python 3.8+
# 仅用标准库，无需安装第三方包
import re
# 模拟从 PDF 按版面模式取到的一段文本
raw_text = """\
产品名称 单价 数量 小计
A 型外壳 12.50 100 1250.00
B 型外壳 8.00 250 2000.00
C 型支架 3.75 80 300.00
"""
# 连续两个及以上的空格视为列分隔；单个空格属于列内文字
SPLIT_RE = re.compile(r"\s{2,}")
def parse_rows(text):
rows = []
for line in text.splitlines():
line = line.rstrip()
if not line.strip():
continue
cells = [c.strip() for c in SPLIT_RE.split(line.strip())]
rows.append(cells)
return rows
def to_number(text):
"""把单元格转成数字，失败就原样返回。"""
try:
return float(text)
except ValueError:
return text
rows = parse_rows(raw_text)
# 第一行当表头，其余当数据
header, data = rows[0], rows[1:]
# 统一列数：短行补空串，长行截断，保证后续处理安全
width = len(header)
data = [(row + [""] * width)[:width] for row in data]
table = []
for row in data:
table.append([to_number(cell) for cell in row])
for row in table:
print(row)
# 顺带算一下「小计」列的总和（最后一列）
total = sum(r[-1] for r in table if isinstance(r[-1], float))
print("合计:", total)这段代码的价值在于它诚实：它明确假设了「列与列之间用两个以上空格隔开」。换成一份用单空格对齐的 PDF，它就会把整行当成一列。这不是 bug，而是这类方法的固有边界。真实的工程做法通常是先做几何分析拿到每列的 x 范围，再按范围切词，而不是靠空白猜。
五、为什么准确率不可能 100%
有四个绕不开的原因：
- 跨页表格。一张表从第 2 页连到第 3 页，表头只出现一次，程序必须自己决定如何拼接，而「第 3 页顶部那几行属于上一张表还是新表」没有客观答案。
- 合并单元格。合并之后，被合并区域的文字只画在左上角，其余位置是空白，按几何切分会得到一堆空列。
- 没有线框的表格。仅靠留白对齐的表格，几何分析法找不到边界，只能退回空白切分，准确率随排版质量波动。
- 扫描件。整页是图像，没有文字层，
extract_text()会返回空字符串。这时必须先做 OCR，而 OCR 自身也会引入误差。
所以对 PDF 表格提取，正确的心理预期是「得到一个需要人工复核的初稿」，而不是「得到一个可直接入库的结果集」。工程上要做的配套动作包括：抽样核对、对行数列数做合理性断言、对异常行打日志而不是静默丢弃。
常见坑点
- 以为扫描件也能直接取文字
❌ 对扫描版 PDF 调extract_text()，得到空字符串或者一堆乱码，然后反复怀疑代码写错了。 ✅ 先判断有没有文字层（取到的文字长度为 0 基本就是扫描件），有图像无文字时走 OCR 路线。
- 把提取出的纯文本直接当表格用
❌ 用整页纯文本按行 split 之后当成表格数据入库，结果列错位、多列粘成一列。 ✅ 明确文本流与表格结构是两回事，中间必须有一层「按列边界重构」的处理，并且要对结果做校验。
- 用同一套列宽切所有 PDF
❌ 把某一份 PDF 里量出来的列 x 坐标硬编码进代码，换一份文件后整张表错位。 ✅ 坐标类规则要按文档动态推算（从线框或表头文字位置推导），避免硬编码。
- 忽略跨页表格的拼接
❌ 逐页独立处理，把跨页表格切成两张表，最后汇总时数据翻倍或断裂。 ✅ 在流程里显式设计「分页拼接」环节，并按表头特征判断新表从哪里开始。
- 不检查行数列数的合理性
❌ 提取完直接写库，某个页面解析出 500 行却没有人发现。 ✅ 对每页得到的行数、列数设阈值，超出预期就告警并保留原始文本便于排查。
- 忘记释放文档对象
❌ 打开文档处理后不关闭，批量跑几百个文件时句柄耗尽。 ✅ 用with管理文档对象的生命周期，或者显式调用关闭方法。
- 对结果过度自信
❌ 拿提取结果直接做财务或对账结论，不抽样核对。 ✅ 明确这类提取天生是启发式的，把人工复核作为流程的一部分固定下来。
总结
| 事实 | 含义 |
|---|
| PDF 里没有表格语义 | 只有文字、坐标与线段 |
| 提取必然靠启发式 | 准确率无法保证 100% |
| 扫描件没有文字层 | 必须 OCR，误差叠加 |
| 跨页与合并单元格 | 需要显式的拼接与兜底策略 |
PDF 表格提取的难点从一开始就不在「用哪个函数」，而在「能不能接受它是概率性的」。把几何分析的思路用对、把人工复核写进流程、把每一条规则都当成假设去验证，得到的结果才是可用的。至于各库的具体方法名、参数与返回结构，请以相应库的官方文档为准。
