上周某同事丢过来一份九十多页的PDF年报头也不回地说了一句“帮我把里面的表格弄出来放到Excel里”。我看着那个背影心里只有三个字又来了。PDF表格提取是我近几年做过的最容易“看起来简单、做起来翻车”的活儿。把PDF里的表格数据读出来再写入Excel、CSV或者数据库导入格式几乎是每个和数据打交道的人都会碰到的需求。市面上工具一大堆但真正用起来你会发现同一个PDF在不同工具里提取出来的结果能差出十万八千里有的行数对不上有的列全乱了有的干脆一个表格都识别不出来。这篇文章想把我在这个方向上踩过的坑、试过的方案、最后沉淀下来的一套可复用流程整套写清楚。适合谁看两类人一类是偶尔要处理几个PDF表格的办公族想用最快速度拿到能用数据另一类是需要在系统里批量处理PDF的开发者想找一份能直接抄的工程化方案。先说结论别指望一个工具通吃所有PDF组合拳才是常态。下面从原理讲到实操再讲翻车现场最后给你一套可以直接跑的生产级脚本。1. PDF里根本没有“表格”只有坐标和画线指令1.1 先把PDF的底层逻辑说清楚很多人提取PDF表格失败问题不在工具而在对PDF形式的误解。PDF不是Word也不是HTML它本身不存储“行、列、单元格、合并区域”这种逻辑结构。PDF页面上的所有内容本质上是一堆绘图指令的执行结果一个字符保存在内容流里记录的是“在x坐标、y坐标处用某种字体、某个字号绘制这样一段文本”一条表格线则是“从坐标A到坐标B画一条直线”。整个页面看起来是张表是因为那些文本和线条恰好排列成了网格形状。这意味着PDF表格提取本质上是“识别”而不是“读取”。工具要做的事情是先找到页面上的横线和竖线判断哪些线条围成了矩形区域再把落在矩形里的文字归到对应单元格里。凡是这个过程里不能确定的全都靠猜。这就是为什么同一个文件在两个工具里结果不一样的根本原因。我打个比方PDF像一幅画在坐标纸上的工程图上面标着文字、画着线段。你要做的是从这幅图里反推出“这原来是个Excel表格”。不同工具的反推算法不一样有的更擅长看线条有的更擅长看文字间距自然结果就有差异。1.2 不同来源的PDF脾气完全不一样同样叫“PDF表格”来源不同提取难度差别极大。这几类我基本都碰过用Excel直接打印/导出成的PDF通常带完整网格线线条规整、文字对齐严格这是最好提取的一类大多数工具都能处理。用Word排版后导出的PDF很多表格为了美观根本没有画边框线只是用底纹或空白来区分区域。线条检测直接失效只能靠文字间距去猜列边界难度高不少。用报表系统生成的PDF这种最友好很多系统生成的PDF甚至带有隐藏的真实表格结构提取准确率极高。设计师用排版软件做的PDF版式自由表格之间可能还有嵌入图形、浮动文本框表格线和文字常常不在预期位置提取结果很容易错位。扫描件页面是图片连文本层都没有。普通表格提取工具面对这种文件基本束手无策必须先做OCR。搞清楚文件是哪一类再决定用什么工具这是我处理PDF表格的第一个习惯。否则拿着专门吃线条的库去提一个Word导出的无边框表格注定白忙一场。2. 工具选型免费库和商业套件我的实测结论2.1 Python生态的三板斧我自己长期用Python先说免费方案里最主流的三个库。工具提取原理环境依赖适合场景主要缺点pdfplumber基于字符坐标线框检测提供详细页面对象纯Python依赖pdfminer等常规有线条的PDF灵活自定义无线框的版式容易提歪camelot提供lattice线条和stream空白分割两种模式需要Ghostscript和OpenCV复杂有线表格精度较高可导出Excel/HTML依赖安装麻烦对无线框表格同样吃力tabula-py从Java版tabula移植内置PDF表格识别算法需要Java运行时环境线条完整的大批量表格Java环境有些团队不让装有版本兼容问题pdfplumber是我最常用的主力工具。它的优点是很“透明”每个页面上的字符、线条、矩形你都可以单独取出来检查和调试。遇到提取结果不对你能清楚地看到是哪里断线了、哪个文字没进单元格排查效率很高。camelot我在一个线条极度复杂的三线表场景里用过lattice模式表现确实比pdfplumber稳但安装Ghostscript那一步就劝退了很多新手。tabula-py胜在简单几行代码就能出结果可是Java环境在有些办公电脑上不被允许安装我后来基本没用它做主力。2.2 商业套件的定位别搞错免费库搞不定扫描件和极端复杂版式这种情况下我还是会掏钱用商业方案。市面上的商业PDF识别套件核心优势在于混合识别它会同时分析线条、文字间距、字体变化、图像纹理甚至能调用OCR识别扫描件识别率很高。我遇到最典型的例子是某些采购合同扫描件页面上还有印章、手写体干扰免费库提取结果惨不忍睹换商业套件之后准确率一下子到了九成以上。但商业工具也有它的问题首先是价格不少是按年订阅的其次是批量运行时界面操作式的工具很难嵌入到自动化流程里最后还是要回到命令行或API方式调用第三是识别结果经常“过度处理”它会自动帮你判断哪些内容是表格反而把一些本来不是表格的版式也归并成了表格后续清洗更费劲。所以我的结论很明确能用免费库搞定的先用免费库扫描件或复杂版式准备一份商业套件兜底两边都不行的时候才考虑人工介入。2.3 我最终沉淀下来的选型组合我的日常处理流程是固定的三板斧先跑pdfplumber把所有PDF页面的表格框位置打印出来人工或脚本判断这批文件属于哪种类型。能直接用pdfplumber处理的就走Python链路自动提取、清洗、落盘。扫描件先补一层OCR让页面带上文本层之后再走第2步OCR之后仍然提取失败的部分单独导出成图片放一边交给商业套件或人工处理。这套组合几十份文件跑下来稳定性和效率都比较理想。3. 落地实操从PDF表格到Excel/CSV的完整链路3.1 环境准备实操之前先把环境装好。我建议你新建一个干净的虚拟环境不要直接装到全项目共用的环境里因为pdfplumber依赖的某些底层库升级时很可能动到别的模块。python -m venv pdfenv source pdfenv/bin/activate # Windows 下是 pdfenv\Scripts\activate pip install pdfplumber pandas openpyxlpandas是用来清洗数据再写文件的openpyxl是Excel写入引擎没有它pandas写xlsx会报错。Python版本我用的3.103.8以上基本都兼容。3.2 第一次提取代码写出来就跑通下面这段是我最常用的最小可用代码读取一个PDF文件里所有页面的表格并全部写入Excelimport pdfplumber import pandas as pd pdf_path sample.pdf output_path output.xlsx all_tables [] with pdfplumber.open(pdf_path) as pdf: for page_no, page in enumerate(pdf.pages, start1): tables page.extract_tables( table_settings{ vertical_strategy: lines, horizontal_strategy: lines, } ) for table in tables: # 每张表记录来源页码方便溯源 all_tables.append({ page: page_no, data: table, }) if not all_tables: print(没有提取到任何表格请检查PDF是否有文本层或表格线) exit() with pd.ExcelWriter(output_path, engineopenpyxl) as writer: for idx, item in enumerate(all_tables, start1): df pd.DataFrame(item[data]) sheet_name fpage{item[page]}_table{idx}[:31] # Excel sheet名最长31字符 df.to_excel(writer, sheet_namesheet_name, indexFalse)第一次跑通这个脚本之后我一般会顺手把每个表的行数和列数打印出来看一眼确认哪些页面的表被完整读到了。这里有个很常见的误区一张跨页的表格pdfplumber会把它当成两页上的两个独立表格来处理后续拼表时要注意后面专门讲。3.3 进阶清洗空行、空列和跨行单元格直接提取出来的表格大概率带着各种脏数据。最常见的三种情况合并单元格pdfplumber提取时被合并的区域只会在第一个单元格有值其他位置是空字符串。上下跨行的标题单元格表格中间隔几行会出现空白因为那个位置被“内容竖直居中”的单元格占住了。页面边缘的装饰性线条可能被误识别成表格整个表格只有一行字符或全是空内容。我的清洗套路是先转成pandas的DataFrame再统一处理import math def clean_table(raw_table): # 删除全空行和全空列 df pd.DataFrame(raw_table) df df.dropna(axis0, howall).dropna(axis1, howall) df df.fillna() # 处理跨行合并把空字符串填充为上一行同列的值 df df.replace(, pd.NA) df df.ffill() df df.fillna() # 去掉纯装饰性的空表格 if len(df) 1 or len(df.columns) 1: return None return dfffill是向前填充能处理大多数“列标题跨多行”导致的空槽位。但这里有个坑如果某一行本来就是整行空数据比如页面底部留白ffill会把它填出上一行的内容产生假数据。所以完整做法是先删除全空行再对列内的个别空值做填充顺序不能反。3.4 写入其他格式CSV、Excel、数据库除了Excel大家在工作中最常要的还有CSV和数据库导入。写入CSV要注意编码问题特别是内容含中文时我通常用UTF-8 with BOM编码不然双击打开CSV时中文会乱码df.to_csv(output.csv, indexFalse, encodingutf-8-sig)写入数据库也很常用。比如把提取结果导入SQLite做后续查询import sqlite3 conn sqlite3.connect(data.db) for idx, item in enumerate(all_tables, start1): df clean_table(item[data]) if df is None: continue df.to_sql(ftable_{item[page]}_{idx}, conn, if_existsreplace, indexFalse) conn.close()更贴合真实需求的做法是把每张表都带上一列source_page记录来源页码我实际项目里还会记录文件名、提取时间、原始表格坐标范围方便追溯“这行数据从PDF哪一页来的”。4. 扫描件、合并单元格、跨页表格三个常见的翻车场景4.1 扫描件先补文本层再提取扫描件是整个PDF表格提取分类里最让人头疼的一类。它本质上是照片没有文本层pdfplumber之类的库拿它毫无办法因为页面内容流里根本没有字符对象只有一张图片。正确的流程不是直接识别表格而是先做OCR。OCR的思路是先识别出图片里的所有文字和大概位置再把这些文字“写回”到一个新的PDF里让这个新PDF拥有文本层。这个环节我用的是开源的OCR方案选过几款国产框架效果都不错。处理完之后得到的“带文本层PDF”再交给pdfplumber正常提取准确率和直接扫描件相比是两码事。实际操作中有一个更简单的办法很多OCR工具支持直接输出“可搜索PDF”。拿到这个可搜索PDF之后走正常的提取流程就好。整个链路我写成伪代码是这样的扫描件PDF - 翻页转图片 - OCR识别文字与位置 - 生成带文本层的可搜索PDF - pdfplumber提取表格 - 清洗落盘这里有几个经验要点OCR之前最好把图片分辨率统一处理低于200dpi的扫描件识别效果会很差建议至少提到300dpi。扫描件经常有倾斜OCR前先做倾斜校正否则文字位置偏移会让表格线归组错位。如果图片上印章恰好压在表格线交叉点上表格线检测会在这里断裂提取时大概率出现整列错位。遇到这种情况我的兜底方案是把这个区域单独切出来手工录入或单独走商业套件不浪费时间去调整全局参数。4.2 跨页断表拆开再拼跨页表格是最容易被忽视的坑。一个PDF表格在第一页底部被截断然后在第二页顶部继续pdfplumber会把这两部分当成两个完全独立的表格对象。如果表头行在第二页顶部又重复了一遍那拼接时就得多一步“去掉重复表头”。我的处理思路是这样的判断两张相邻页的表格是否“长得像”列数相同、前几列名称文本一致就可以认为是同一张表被分页了。去掉第二页表格的重复表头行。按列顺序把两张表的行拼起来。简化代码如下def page_has_same_header(table1, table2): if not table1 or not table2: return False # 表头取每张表第一行 header1 table1[0] header2 table2[0] # 比较列数和表头文本 if len(header1) ! len(header2): return False similar sum(1 for a, b in zip(header1, header2) if a and b and str(a).strip() str(b).strip()) return similar max(2, len(header1) // 2)拼接时的另一个麻烦是分页位置可能刚好把一个单元格的内容切断比如“应收账款”四个字第一页页尾显示“应收”第二页页首显示“账款”这属于OCR和文本抽取都很难自动处理的边界问题。遇到这种我建议在输出文件里保留一个标志列注明“此行来自分页拼接”交给业务人员复核别硬让程序猜着拼接。4.3 一次完整的排错过程列全乱了的根因是什么有一次处理一批某公司年度审计报告的附件表格pdfplumber提取后看着很正常但写出的Excel里本来应该在“日期”列的日期跑到了“金额”列而且每两列之间错位一整行整个数据完全没法用。排查链路是这样的第一步我先把原始表格对象原样打印出来对比PDF原稿标号。发现每个提取结果的列数比原稿少了一列。第二步我把这个PDF页面的所有线条用pdfplumber的line对象导出到一张调试图上发现原表格里“日期”和“描述”之间有一条很淡的浅灰色分隔线。这条线颜色太淡灰度检测默认阈值把它过滤掉了于是两列被当成一列。第三步我把table_settings里的vertical_strategy改了不做线条检测而是改用text策略让算法根据文字的垂直分布推测列边界table_settings { vertical_strategy: text, horizontal_strategy: lines, }改完之后列数总算对了。但随后又暴露出新问题有些原本能对齐的文字因为列宽太窄被断开一个数字被拆成两行。这次我加了explicit策略手动指定列边界坐标用页面可视区域里的垂直刻度线位置来定义每一列的左右边界最终把问题彻底解决。这个排错过程给我最大的启发是遇到提取结果异常一定要先回到页面对象层面看线条和字符的客观情况而不是盲目调库的参数。“为什么这里会分成两列”永远比“怎么让代码跑通”更重要。4.4 加密PDF与超大文件的处理带打开密码的PDF如果你的使用权限允许读取pdfplumber在打开时直接传口令就行with pdfplumber.open(pdf_path, password这里填已知口令) as pdf: ...强调一下这里只讨论你有合法访问权限的文件。没有授权的情况下不要去试图绕过任何文档保护机制。超大PDF则要小心内存。我之前处理过一个三百多页、每页都有多个表格的PDF一次性用pdf.pages遍历并保存所有表格内存直接飙到好几个GB后来改成按页处理每页处理完立刻释放然后把结果写到磁盘上的临时SQLite库里内存占用立刻降下来了。批量处理时永远不要让所有页面同时驻留在内存里。5. 把脚本变成工具批量处理与质量校验的心得5.1 批量处理一个文件夹里所有PDF单一文件跑通不算完真实场景往往是一整个文件夹几十个PDF要批量出结果。我写过一个巡检脚本功能包括遍历文件夹里所有PDF、逐页提取表格、把提取结果和“原始页面文本备份”都写出去、为每个PDF生成一份处理日志。import glob import json import logging import traceback import pdfplumber logging.basicConfig( filenamepdf_extract.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) pdf_files glob.glob(data/*.pdf) for pdf_path in pdf_files: try: with pdfplumber.open(pdf_path) as pdf: summary {file: pdf_path, pages: len(pdf.pages), tables: 0} for page_no, page in enumerate(pdf.pages, start1): tables page.extract_tables() summary[tables] len(tables) logging.info(json.dumps(summary, ensure_asciiFalse)) except Exception: logging.error(f处理失败: {pdf_path}\n{traceback.format_exc()})日志里我会记录每个文件的页数和表格数。生产环境里跑完之后先看日志凡是表格数为0的文件都能直接定位到再决定是走OCR补救还是走人工。5.2 校验输出质量的三板斧表格提取完千万别直接发出去说“搞定了”。我吃过好几次亏之后固定下来一套输出质量检查流程第一板斧数量核对确认提取出的表格总数和原PDF页面上肉眼可见的表格数一致或接近。差异太大的直接标记异常。第二板斧关键字段校验如果源表格是年鉴或财务数据我会挑几列求和或计算均值和已知数据对比。比如提取十页利润表第6页的合计金额应该等于前面明细之和或者等于PDF里另一处明确写着的数字。对不上的基本可以断定某个表提取歪了。第三板斧抽样打开随机抽两三个sheet用Excel打开肉眼检查表头是否对齐、数字是否被切到多个单元格。这一步看似原始但其实是效率最高的兜底检查很多结构化校验发现不了的语义错误肉眼一秒钟就能看出来。5.3 关于提不干净的兜底策略无论工具怎么调总有一部分PDF是自动流程搞不定的。我的原则是“宁缺勿错”。提取结果如果明显不可靠与其硬着头皮生成一份错误数据污染下游不如把这个区域标记出来单独输出一个“待人工处理”清单交给业务方复核。具体到代码上我会在遇到可疑表格时把原页面的原始字符坐标快照、表格框坐标、提取结果都存成JSON配上一条提示日志。后续人工只需要看着提示快速定位而不是从头翻PDF效率提升非常明显。实践中我还发现一个值得做的增强对所有文本型单元格提取时顺便记录它的字体大小和是否加粗。很多表格的合计行、小计行在视觉上是加粗的利用这个信息可以在清洗时自动识别“小计”“合计”行甚至能辅助判断哪些行该进明细表、哪些该进汇总表。这是我最近在继续优化的方向。回头说两句个人体会。PDF表格提取这件事我从一开始天真地以为“写个库调用就完事”到后来被各种版式按在地上摩擦现在固定下来的想法是不要把希望寄托在任何一个单独的识别引擎上。组合拳、质量校验、人工兜底这三件事做好绝大多数PDF表格都能被收拾得服服帖帖。如果你刚接手类似任务我建议先拿几份特征差异明显的PDF跑一遍打印出每个页面被识别出的表格框位置看到它们具体长什么样比读十篇教程都有用。希望这篇踩坑复盘能帮你少走点弯路。 
长河君 · 2026/10/15 5:32:12 · 阅读 1.2k PDF表格提取实战：从工具选型到批量落盘Excel的完整攻略
上周某同事丢过来一份九十多页的PDF年报头也不回地说了一句“帮我把里面的表格弄出来放到Excel里”。我看着那个背影心里只有三个字又来了。PDF表格提取是我近几年做过的最容易“看起来简单、做起来翻车”的活儿。把PDF里的表格数据读出来再写入Excel、CSV或者数据库导入格式几乎是每个和数据打交道的人都会碰到的需求。市面上工具一大堆但真正用起来你会发现同一个PDF在不同工具里提取出来的结果能差出十万八千里有的行数对不上有的列全乱了有的干脆一个表格都识别不出来。这篇文章想把我在这个方向上踩过的坑、试过的方案、最后沉淀下来的一套可复用流程整套写清楚。适合谁看两类人一类是偶尔要处理几个PDF表格的办公族想用最快速度拿到能用数据另一类是需要在系统里批量处理PDF的开发者想找一份能直接抄的工程化方案。先说结论别指望一个工具通吃所有PDF组合拳才是常态。下面从原理讲到实操再讲翻车现场最后给你一套可以直接跑的生产级脚本。1. PDF里根本没有“表格”只有坐标和画线指令1.1 先把PDF的底层逻辑说清楚很多人提取PDF表格失败问题不在工具而在对PDF形式的误解。PDF不是Word也不是HTML它本身不存储“行、列、单元格、合并区域”这种逻辑结构。PDF页面上的所有内容本质上是一堆绘图指令的执行结果一个字符保存在内容流里记录的是“在x坐标、y坐标处用某种字体、某个字号绘制这样一段文本”一条表格线则是“从坐标A到坐标B画一条直线”。整个页面看起来是张表是因为那些文本和线条恰好排列成了网格形状。这意味着PDF表格提取本质上是“识别”而不是“读取”。工具要做的事情是先找到页面上的横线和竖线判断哪些线条围成了矩形区域再把落在矩形里的文字归到对应单元格里。凡是这个过程里不能确定的全都靠猜。这就是为什么同一个文件在两个工具里结果不一样的根本原因。我打个比方PDF像一幅画在坐标纸上的工程图上面标着文字、画着线段。你要做的是从这幅图里反推出“这原来是个Excel表格”。不同工具的反推算法不一样有的更擅长看线条有的更擅长看文字间距自然结果就有差异。1.2 不同来源的PDF脾气完全不一样同样叫“PDF表格”来源不同提取难度差别极大。这几类我基本都碰过用Excel直接打印/导出成的PDF通常带完整网格线线条规整、文字对齐严格这是最好提取的一类大多数工具都能处理。用Word排版后导出的PDF很多表格为了美观根本没有画边框线只是用底纹或空白来区分区域。线条检测直接失效只能靠文字间距去猜列边界难度高不少。用报表系统生成的PDF这种最友好很多系统生成的PDF甚至带有隐藏的真实表格结构提取准确率极高。设计师用排版软件做的PDF版式自由表格之间可能还有嵌入图形、浮动文本框表格线和文字常常不在预期位置提取结果很容易错位。扫描件页面是图片连文本层都没有。普通表格提取工具面对这种文件基本束手无策必须先做OCR。搞清楚文件是哪一类再决定用什么工具这是我处理PDF表格的第一个习惯。否则拿着专门吃线条的库去提一个Word导出的无边框表格注定白忙一场。2. 工具选型免费库和商业套件我的实测结论2.1 Python生态的三板斧我自己长期用Python先说免费方案里最主流的三个库。工具提取原理环境依赖适合场景主要缺点pdfplumber基于字符坐标线框检测提供详细页面对象纯Python依赖pdfminer等常规有线条的PDF灵活自定义无线框的版式容易提歪camelot提供lattice线条和stream空白分割两种模式需要Ghostscript和OpenCV复杂有线表格精度较高可导出Excel/HTML依赖安装麻烦对无线框表格同样吃力tabula-py从Java版tabula移植内置PDF表格识别算法需要Java运行时环境线条完整的大批量表格Java环境有些团队不让装有版本兼容问题pdfplumber是我最常用的主力工具。它的优点是很“透明”每个页面上的字符、线条、矩形你都可以单独取出来检查和调试。遇到提取结果不对你能清楚地看到是哪里断线了、哪个文字没进单元格排查效率很高。camelot我在一个线条极度复杂的三线表场景里用过lattice模式表现确实比pdfplumber稳但安装Ghostscript那一步就劝退了很多新手。tabula-py胜在简单几行代码就能出结果可是Java环境在有些办公电脑上不被允许安装我后来基本没用它做主力。2.2 商业套件的定位别搞错免费库搞不定扫描件和极端复杂版式这种情况下我还是会掏钱用商业方案。市面上的商业PDF识别套件核心优势在于混合识别它会同时分析线条、文字间距、字体变化、图像纹理甚至能调用OCR识别扫描件识别率很高。我遇到最典型的例子是某些采购合同扫描件页面上还有印章、手写体干扰免费库提取结果惨不忍睹换商业套件之后准确率一下子到了九成以上。但商业工具也有它的问题首先是价格不少是按年订阅的其次是批量运行时界面操作式的工具很难嵌入到自动化流程里最后还是要回到命令行或API方式调用第三是识别结果经常“过度处理”它会自动帮你判断哪些内容是表格反而把一些本来不是表格的版式也归并成了表格后续清洗更费劲。所以我的结论很明确能用免费库搞定的先用免费库扫描件或复杂版式准备一份商业套件兜底两边都不行的时候才考虑人工介入。2.3 我最终沉淀下来的选型组合我的日常处理流程是固定的三板斧先跑pdfplumber把所有PDF页面的表格框位置打印出来人工或脚本判断这批文件属于哪种类型。能直接用pdfplumber处理的就走Python链路自动提取、清洗、落盘。扫描件先补一层OCR让页面带上文本层之后再走第2步OCR之后仍然提取失败的部分单独导出成图片放一边交给商业套件或人工处理。这套组合几十份文件跑下来稳定性和效率都比较理想。3. 落地实操从PDF表格到Excel/CSV的完整链路3.1 环境准备实操之前先把环境装好。我建议你新建一个干净的虚拟环境不要直接装到全项目共用的环境里因为pdfplumber依赖的某些底层库升级时很可能动到别的模块。python -m venv pdfenv source pdfenv/bin/activate # Windows 下是 pdfenv\Scripts\activate pip install pdfplumber pandas openpyxlpandas是用来清洗数据再写文件的openpyxl是Excel写入引擎没有它pandas写xlsx会报错。Python版本我用的3.103.8以上基本都兼容。3.2 第一次提取代码写出来就跑通下面这段是我最常用的最小可用代码读取一个PDF文件里所有页面的表格并全部写入Excelimport pdfplumber import pandas as pd pdf_path sample.pdf output_path output.xlsx all_tables [] with pdfplumber.open(pdf_path) as pdf: for page_no, page in enumerate(pdf.pages, start1): tables page.extract_tables( table_settings{ vertical_strategy: lines, horizontal_strategy: lines, } ) for table in tables: # 每张表记录来源页码方便溯源 all_tables.append({ page: page_no, data: table, }) if not all_tables: print(没有提取到任何表格请检查PDF是否有文本层或表格线) exit() with pd.ExcelWriter(output_path, engineopenpyxl) as writer: for idx, item in enumerate(all_tables, start1): df pd.DataFrame(item[data]) sheet_name fpage{item[page]}_table{idx}[:31] # Excel sheet名最长31字符 df.to_excel(writer, sheet_namesheet_name, indexFalse)第一次跑通这个脚本之后我一般会顺手把每个表的行数和列数打印出来看一眼确认哪些页面的表被完整读到了。这里有个很常见的误区一张跨页的表格pdfplumber会把它当成两页上的两个独立表格来处理后续拼表时要注意后面专门讲。3.3 进阶清洗空行、空列和跨行单元格直接提取出来的表格大概率带着各种脏数据。最常见的三种情况合并单元格pdfplumber提取时被合并的区域只会在第一个单元格有值其他位置是空字符串。上下跨行的标题单元格表格中间隔几行会出现空白因为那个位置被“内容竖直居中”的单元格占住了。页面边缘的装饰性线条可能被误识别成表格整个表格只有一行字符或全是空内容。我的清洗套路是先转成pandas的DataFrame再统一处理import math def clean_table(raw_table): # 删除全空行和全空列 df pd.DataFrame(raw_table) df df.dropna(axis0, howall).dropna(axis1, howall) df df.fillna() # 处理跨行合并把空字符串填充为上一行同列的值 df df.replace(, pd.NA) df df.ffill() df df.fillna() # 去掉纯装饰性的空表格 if len(df) 1 or len(df.columns) 1: return None return dfffill是向前填充能处理大多数“列标题跨多行”导致的空槽位。但这里有个坑如果某一行本来就是整行空数据比如页面底部留白ffill会把它填出上一行的内容产生假数据。所以完整做法是先删除全空行再对列内的个别空值做填充顺序不能反。3.4 写入其他格式CSV、Excel、数据库除了Excel大家在工作中最常要的还有CSV和数据库导入。写入CSV要注意编码问题特别是内容含中文时我通常用UTF-8 with BOM编码不然双击打开CSV时中文会乱码df.to_csv(output.csv, indexFalse, encodingutf-8-sig)写入数据库也很常用。比如把提取结果导入SQLite做后续查询import sqlite3 conn sqlite3.connect(data.db) for idx, item in enumerate(all_tables, start1): df clean_table(item[data]) if df is None: continue df.to_sql(ftable_{item[page]}_{idx}, conn, if_existsreplace, indexFalse) conn.close()更贴合真实需求的做法是把每张表都带上一列source_page记录来源页码我实际项目里还会记录文件名、提取时间、原始表格坐标范围方便追溯“这行数据从PDF哪一页来的”。4. 扫描件、合并单元格、跨页表格三个常见的翻车场景4.1 扫描件先补文本层再提取扫描件是整个PDF表格提取分类里最让人头疼的一类。它本质上是照片没有文本层pdfplumber之类的库拿它毫无办法因为页面内容流里根本没有字符对象只有一张图片。正确的流程不是直接识别表格而是先做OCR。OCR的思路是先识别出图片里的所有文字和大概位置再把这些文字“写回”到一个新的PDF里让这个新PDF拥有文本层。这个环节我用的是开源的OCR方案选过几款国产框架效果都不错。处理完之后得到的“带文本层PDF”再交给pdfplumber正常提取准确率和直接扫描件相比是两码事。实际操作中有一个更简单的办法很多OCR工具支持直接输出“可搜索PDF”。拿到这个可搜索PDF之后走正常的提取流程就好。整个链路我写成伪代码是这样的扫描件PDF - 翻页转图片 - OCR识别文字与位置 - 生成带文本层的可搜索PDF - pdfplumber提取表格 - 清洗落盘这里有几个经验要点OCR之前最好把图片分辨率统一处理低于200dpi的扫描件识别效果会很差建议至少提到300dpi。扫描件经常有倾斜OCR前先做倾斜校正否则文字位置偏移会让表格线归组错位。如果图片上印章恰好压在表格线交叉点上表格线检测会在这里断裂提取时大概率出现整列错位。遇到这种情况我的兜底方案是把这个区域单独切出来手工录入或单独走商业套件不浪费时间去调整全局参数。4.2 跨页断表拆开再拼跨页表格是最容易被忽视的坑。一个PDF表格在第一页底部被截断然后在第二页顶部继续pdfplumber会把这两部分当成两个完全独立的表格对象。如果表头行在第二页顶部又重复了一遍那拼接时就得多一步“去掉重复表头”。我的处理思路是这样的判断两张相邻页的表格是否“长得像”列数相同、前几列名称文本一致就可以认为是同一张表被分页了。去掉第二页表格的重复表头行。按列顺序把两张表的行拼起来。简化代码如下def page_has_same_header(table1, table2): if not table1 or not table2: return False # 表头取每张表第一行 header1 table1[0] header2 table2[0] # 比较列数和表头文本 if len(header1) ! len(header2): return False similar sum(1 for a, b in zip(header1, header2) if a and b and str(a).strip() str(b).strip()) return similar max(2, len(header1) // 2)拼接时的另一个麻烦是分页位置可能刚好把一个单元格的内容切断比如“应收账款”四个字第一页页尾显示“应收”第二页页首显示“账款”这属于OCR和文本抽取都很难自动处理的边界问题。遇到这种我建议在输出文件里保留一个标志列注明“此行来自分页拼接”交给业务人员复核别硬让程序猜着拼接。4.3 一次完整的排错过程列全乱了的根因是什么有一次处理一批某公司年度审计报告的附件表格pdfplumber提取后看着很正常但写出的Excel里本来应该在“日期”列的日期跑到了“金额”列而且每两列之间错位一整行整个数据完全没法用。排查链路是这样的第一步我先把原始表格对象原样打印出来对比PDF原稿标号。发现每个提取结果的列数比原稿少了一列。第二步我把这个PDF页面的所有线条用pdfplumber的line对象导出到一张调试图上发现原表格里“日期”和“描述”之间有一条很淡的浅灰色分隔线。这条线颜色太淡灰度检测默认阈值把它过滤掉了于是两列被当成一列。第三步我把table_settings里的vertical_strategy改了不做线条检测而是改用text策略让算法根据文字的垂直分布推测列边界table_settings { vertical_strategy: text, horizontal_strategy: lines, }改完之后列数总算对了。但随后又暴露出新问题有些原本能对齐的文字因为列宽太窄被断开一个数字被拆成两行。这次我加了explicit策略手动指定列边界坐标用页面可视区域里的垂直刻度线位置来定义每一列的左右边界最终把问题彻底解决。这个排错过程给我最大的启发是遇到提取结果异常一定要先回到页面对象层面看线条和字符的客观情况而不是盲目调库的参数。“为什么这里会分成两列”永远比“怎么让代码跑通”更重要。4.4 加密PDF与超大文件的处理带打开密码的PDF如果你的使用权限允许读取pdfplumber在打开时直接传口令就行with pdfplumber.open(pdf_path, password这里填已知口令) as pdf: ...强调一下这里只讨论你有合法访问权限的文件。没有授权的情况下不要去试图绕过任何文档保护机制。超大PDF则要小心内存。我之前处理过一个三百多页、每页都有多个表格的PDF一次性用pdf.pages遍历并保存所有表格内存直接飙到好几个GB后来改成按页处理每页处理完立刻释放然后把结果写到磁盘上的临时SQLite库里内存占用立刻降下来了。批量处理时永远不要让所有页面同时驻留在内存里。5. 把脚本变成工具批量处理与质量校验的心得5.1 批量处理一个文件夹里所有PDF单一文件跑通不算完真实场景往往是一整个文件夹几十个PDF要批量出结果。我写过一个巡检脚本功能包括遍历文件夹里所有PDF、逐页提取表格、把提取结果和“原始页面文本备份”都写出去、为每个PDF生成一份处理日志。import glob import json import logging import traceback import pdfplumber logging.basicConfig( filenamepdf_extract.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) pdf_files glob.glob(data/*.pdf) for pdf_path in pdf_files: try: with pdfplumber.open(pdf_path) as pdf: summary {file: pdf_path, pages: len(pdf.pages), tables: 0} for page_no, page in enumerate(pdf.pages, start1): tables page.extract_tables() summary[tables] len(tables) logging.info(json.dumps(summary, ensure_asciiFalse)) except Exception: logging.error(f处理失败: {pdf_path}\n{traceback.format_exc()})日志里我会记录每个文件的页数和表格数。生产环境里跑完之后先看日志凡是表格数为0的文件都能直接定位到再决定是走OCR补救还是走人工。5.2 校验输出质量的三板斧表格提取完千万别直接发出去说“搞定了”。我吃过好几次亏之后固定下来一套输出质量检查流程第一板斧数量核对确认提取出的表格总数和原PDF页面上肉眼可见的表格数一致或接近。差异太大的直接标记异常。第二板斧关键字段校验如果源表格是年鉴或财务数据我会挑几列求和或计算均值和已知数据对比。比如提取十页利润表第6页的合计金额应该等于前面明细之和或者等于PDF里另一处明确写着的数字。对不上的基本可以断定某个表提取歪了。第三板斧抽样打开随机抽两三个sheet用Excel打开肉眼检查表头是否对齐、数字是否被切到多个单元格。这一步看似原始但其实是效率最高的兜底检查很多结构化校验发现不了的语义错误肉眼一秒钟就能看出来。5.3 关于提不干净的兜底策略无论工具怎么调总有一部分PDF是自动流程搞不定的。我的原则是“宁缺勿错”。提取结果如果明显不可靠与其硬着头皮生成一份错误数据污染下游不如把这个区域标记出来单独输出一个“待人工处理”清单交给业务方复核。具体到代码上我会在遇到可疑表格时把原页面的原始字符坐标快照、表格框坐标、提取结果都存成JSON配上一条提示日志。后续人工只需要看着提示快速定位而不是从头翻PDF效率提升非常明显。实践中我还发现一个值得做的增强对所有文本型单元格提取时顺便记录它的字体大小和是否加粗。很多表格的合计行、小计行在视觉上是加粗的利用这个信息可以在清洗时自动识别“小计”“合计”行甚至能辅助判断哪些行该进明细表、哪些该进汇总表。这是我最近在继续优化的方向。回头说两句个人体会。PDF表格提取这件事我从一开始天真地以为“写个库调用就完事”到后来被各种版式按在地上摩擦现在固定下来的想法是不要把希望寄托在任何一个单独的识别引擎上。组合拳、质量校验、人工兜底这三件事做好绝大多数PDF表格都能被收拾得服服帖帖。如果你刚接手类似任务我建议先拿几份特征差异明显的PDF跑一遍打印出每个页面被识别出的表格框位置看到它们具体长什么样比读十篇教程都有用。希望这篇踩坑复盘能帮你少走点弯路。