手上堆着一批 PDF，想用 MATLAB 直接读进来做分析，这事我干过不止一次。最早是帮一个做工艺参数统计的小团队，把几百份检测报告里的数值抽出来做趋势图；后来又把自己攒的一堆技术说明书拆成结构化字段做检索。每一次都会撞上同一堵墙：一行extractFileText跑下来，正文变成一堆顺序错乱的字符串，表格整段压成一行，扫描件干脆返回一个空字符串，你还以为是自己路径写错了。所以这篇不打算写成函数手册，而是把MATLAB 读取 PDF这条链路上的三段活——文本提取、表格识别、OCR 处理——按照我实际跑通的顺序摊开讲，包括每一步为什么这么选、参数怎么定、哪里会翻车。

适合谁看：手上已经有 MATLAB 基础语法、能写循环能调函数，但被 PDF 折磨过的人；也适合做数据治理、报告自动化、档案数字化的同学，把 MATLAB 当成调度台和下游分析引擎来用。全文的代码都是可复制的骨架，你替换路径和字段名就能跑。一个前提先说清楚：MATLAB 本身不是 PDF 解析器，它的定位是“总调度 + 后处理”，认清这一点，后面的技术选型就顺了。

1. 先搞清楚 PDF 的体质，再谈技术路线

1.1 PDF 的三种体质决定了三条完全不同的路

很多人一上来就问“MATLAB 怎么读 PDF 表格”，这问题问早了。得先知道手上这份 PDF 是哪一类，因为三类文件的处理成本差着一个数量级。

第一类是文本型 PDF，也叫原生电子版，从 Word、LaTeX、排版软件直接导出。这类文件内部有文字层，你用鼠标能选中、能复制，它就是给你读的。这类文件用extractFileText一行就能拿到全部文字，成本最低。

第二类是扫描型 PDF，本质是一堆图片被包进了 PDF 容器。你在阅读器里怎么拖都选不中文字，复制出来是空白。这类必须走 OCR，也就是把页面渲染成位图再识别，成本最高，且识别结果一定有错字。

第三类是混合型，也是最坑的。正文是文本层，但夹着几页扫描的附件；或者整份文件是别人 OCR 完之后又存成 PDF 的，表面上有文字层，可文字顺序是按识别框的坐标乱序写进去的，extractFileText读出来像被洗过牌。我遇到过一份两百页的规范文档，正文完全正常，唯独目录和附录的页码全是乱的，原因就是那几页来自扫描件。

判断方法很土但很有效：抽三到五页，跑一次提取，看返回字符串的非空白字符长度。长度接近零，基本是扫描型；长度正常但你读着语句断裂、数字和单位分家，大概率是混合型里的“伪文字层”。

probe = extractFileText(pdfFile,"Pages",1:min(5,nPage)); density = strlength(erase(probe,[" ","\r","\n"])) / max(1,strlength(probe)); if density < 0.05 mode = "ocr"; % 扫描型，直接走 OCR 路线 elseif density > 0.6 mode = "text"; % 文本型，走提取 + 清洗 else mode = "mixed"; % 混合型，逐页判定 end

这段判定逻辑不追求精确，追求的是“别把扫描件丢进文本提取里白跑一晚”。密度阈值 0.05 和 0.6 是我在自己那批文档上调出来的经验值，你手上如果是公式密集的理工科文档，空白比例天然偏高，阈值得往下压，别照抄。

1.2 MATLAB 在这条链路里该站什么位置

说句实话，MATLAB 在 PDF 解析这块的官方能力是偏薄的。它能做的是提取纯文本，而且只给你字符串，不给你版面坐标。这意味着两件关键的事它做不了：一是还原表格的行列结构，因为你不知道每个词画在页面的哪个位置；二是判断哪段文字属于页眉页脚，同样因为没有坐标，只能靠文本重复率去猜。

但它的强项也很明确：批量调度、数值计算、矩阵化清洗、和 Excel 及数据库对接、出图。所以我的整体架构一直是这个分工——解析交给最合适的工具，MATLAB 负责编排、清洗、校验和落地。具体来说，文本提取优先用 MATLAB 自带的函数，够用且不用装环境；表格识别交给 Python 侧的库通过pyenv桥接，或者直接命令行调用转换工具；OCR 用 Computer Vision Toolbox 里的ocr函数，因为它返回的是带坐标和置信度的对象，比只给一段文本的引擎好用得多。

这个分工带来的好处是可维护。你不需要在一个脚本里塞三种语言的黑魔法，而是每层职责清晰：谁解析、谁清洗、谁输出，出了问题一眼能定位到层。坏处是多了一层进程间调用，得处理路径、编码、返回值类型转换这些琐碎事，后面我会把这些坑逐个填上。

1.3 一张表把方案选型定下来

选型表是我每次开工前必写的，写不出来说明你还没想清楚需求。

这张表里我最想强调的是最后一行的思路：宁可多一次落盘，也不要一次调用做完所有事。中间格式（纯文本、CSV、PNG）的存在，让你的流程可以断点续跑，也让排错变得可能——出问题时你能肉眼看看中间产物到底长什么样，而不是对着一行报错猜。

2. 文本提取：从一行调用到逐页可控

2.1 最小的可用调用与环境确认

先确认工具箱，别写完一屏代码才发现函数不存在。

if ~license('test','Text_Analytics_Toolbox') error('缺少 Text Analytics Toolbox，文本提取路线不可用'); end txt = extractFileText("E:\docs\sample.pdf");

extractFileText返回的是 string 标量，整份文档的正文全在里面，换行符保留，但段落之间的空行、缩进、分栏顺序都不保证。这里有个常识要提醒：PDF 内部保存文字是按“绘制指令”的顺序，而不是按“人眼阅读”的顺序。所以一份双栏排版的论文，提取出来经常是左栏第一段、右栏第一段、左栏第二段这样交错。这不是 bug，是 PDF 格式本身的特性，任何工具都只能缓解不能根治。

如果只想要某几页，新版本支持用Pages指定页码范围：

part = extractFileText("E:\docs\sample.pdf","Pages",3:8);

注意版本差异。老版本没有这个参数，你只能整份读进来再自己切，或者退回命令行工具分页转换。我曾经在一台老机器上调试了半天，最后发现是版本不支持，白白怀疑了半小时路径问题——遇到“参数不认识”的报错，第一反应查版本，别急着查代码。

2.2 逐页提取：为什么我几乎不整份读

除非文档只有几页，否则我基本都改成逐页提取。原因有三个，都很实际。

第一是可回溯。做数据治理最怕的是结果错了却不知道错在哪一页。逐页提取时，你把页码和文本一起存进结构体或者表格里，后面任何一条异常记录都能反查到原文第几页第几行，人工核对成本极低。

第二是防爆内存。一份三百页的彩印目录，整份字符串可能有几十兆，再叠上正则匹配的中间变量，内存会悄悄吃掉一大块。逐页处理时，每页处理完就可以释放。

第三是可容错。整份读取只要有一页结构异常，整个调用可能直接抛错，前面九十九页全白干。逐页加上try/catch，坏页跳过并记录，剩下的照常跑完。

nPage = 42; % 页数，用第三方工具或阅读器确认 pdfFile = "E:\docs\sample.pdf"; pages = strings(nPage,1); badPage = []; for k = 1:nPage try pages(k) = extractFileText(pdfFile,"Pages",k); catch ME warning("第 %d 页提取失败：%s", k, ME.message); pages(k) = ""; badPage(end+1) = k; %#ok<AGROW> end end fprintf("完成 %d 页，失败 %d 页\n", nPage-numel(badPage), numel(badPage));

页数怎么来？MATLAB 里没有直接的“取页数”函数，我通常用阅读器看一眼，或者让外部命令行工具输出一份分页文本，数一数分隔符。这一步偷懒的话，后面循环次数不对，你会怀疑人生。

对失败页还有一层兜底：调用命令行转换工具单独转这一页。这类工具对畸形文件结构的容忍度往往比库函数高。

pdftotext -f 7 -l 7 -enc UTF-8 -layout "sample.pdf" "page7.txt"

然后在 MATLAB 里fileread("page7.txt")读回来。注意-layout这个参数，它会让输出尽量保留原始版面的空白，代价是行内会出现大量连续空格，后面清洗时得专门处理。不用-layout的话文字更紧凑，但表格和缩进信息全丢。要版面就用它，要纯文本就别用，别两个都要。

2.3 中文文档的清洗：全角、断行、页眉三件事

拿到原始字符串只是开始，真正花时间的是清洗。中文 PDF 有三个高频毛病，我按处理顺序说。

第一件，全角字符与不可见空白。PDF 里排版的空格经常是全角空格（U+3000）或者不换行空格（U+00A0），用普通的isspace判断不出来，正则里写\s也未必匹配得到。统一替换掉：

s = replace(s, [char(12288), char(160)], " "); % 全角空格、不换行空格 s = regexprep(s, "[ \t]+", " ");

数字和单位之间那种排版用的窄空格，如果后面要做数值解析，也得一并清掉，否则str2double会返回NaN，而你会盯着一个看起来完全正常的“12.5 mm”发呆。

第二件，硬换行把句子切断。这是最烦的。PDF 按行绘制文字，提取出来每一行末尾都有换行符，但语义上的段落并没有结束。如果你直接按行切分做字段匹配，一句“检测结果符合 GB/T”和下一行的“1234 的要求”就分家了。我的合并规则是：如果上一行结尾不是句号、问号、分号、冒号这类终止标点，且下一行开头不是编号、不是短横线、不是大写字母开头的条目，就把两行接起来。

lines = splitlines(s); lines = strtrim(lines); merged = strings(0,1); for i = 1:numel(lines) cur = lines(i); if isempty(merged) || cur == "" merged(end+1,1) = cur; %#ok<AGROW> continue; end prev = merged(end); endChar = extractAfter(prev, strlength(prev)-1); isBreak = any(endChar == ["。","？","；","：",".","!","?"]); isItem = ~isempty(regexp(cur, "^\s*(\d+[\.、]|[（(]\d+[）)]|[-—•])", "once")); if ~isBreak && ~isItem merged(end) = prev + cur; else merged(end+1,1) = cur; %#ok<AGROW> end end

这段代码不完美，尤其是遇到英文单词跨行断字（informa-换行tion）时会把连字符留着。中文文档里这种少，英文技术手册里遍地都是，得再加一条规则：行尾是连字符且前一个字符是字母，就去掉连字符直接拼接。

第三件，页眉页脚。它们每页重复出现，混进正文会污染关键词统计和字段提取。识别办法是统计每页首行和末行的重复率：

headLine = strings(nPage,1); for k = 1:nPage L = splitlines(pages(k)); L = strtrim(L); L(L=="") = []; if ~isempty(L), headLine(k) = L(1); end end [u,~,ic] = unique(headLine); cnt = accumarray(ic,1); isHeader = u(cnt/nPage > 0.6); % 六成以上页面重复出现，判为页眉 pages = replace(pages, isHeader, "");

阈值 0.6 是个折中。定太高会漏（文档有多个章节，页眉分几种），定太低会误杀（正文里反复出现的固定短语）。我的做法是先跑一遍看输出，把isHeader打印出来人工扫一眼，确认无误再固化。清洗规则一定要先肉眼验证再批量跑，否则错误会被放大几百倍并且悄无声息。

2.4 正则提取字段：把脏文本变成表

清洗完的文本，下一步是抽字段。这里我推荐用 MATLAB 的pattern体系而不是传统正则字符串，可读性好很多，尤其是带前后文的场景。

pID = lookBehindBoundary("编号：") + digitsPattern(6); pDate = lookBehindBoundary("检测日期：") + digitsPattern(4) + "-" + ... digitsPattern(2) + "-" + digitsPattern(2); pVal = digitsPattern(1,4) + optionalPattern("." + digitsPattern(1,3)); id = extract(txt, pID); date = extract(txt, pDate); val = double(extract(txt, pVal));

几个实操要点。lookBehindBoundary需要较新的版本，老版本用regexp(...,'tokens')加捕获组替代。extract返回的是所有匹配，顺序就是文本中出现的顺序，它不会告诉你匹配来自哪一页，所以要么逐页提取逐页解析、把页码作为一列带上，要么接受“只能拿到值拿不到出处”的妥协。我选前者，因为后期核对时出处比结果更值钱。

还有一个容易忽略的点：数值提取一定要做单位校验。digitsPattern会把“第 3 章”里的 3 也抓出来。稳妥做法是把单位和数字绑在一起匹配，匹配不到单位的直接丢弃，宁可漏也不要错——漏掉的数据你能通过补规则找回来，错的数字会污染整张表并且很难事后发现。

3. 表格识别：PDF 里最难啃的一块

3.1 表格为什么会塌成一行

先说清楚原理，不然你没法定策略。PDF 里没有“表格”这个对象，只有“在某个坐标画了一条线”和“在某个坐标写了一段文字”。表格是渲染出来的视觉效果，不是数据结构。所以当你用文本提取时，工具只能按绘制顺序把文字串起来，一行表格可能变成“项目 数值 单位 温度 25 摄氏度”这样一条线，也可能变成“项目 温度”和“数值 25”交错排列，取决于当初排版软件怎么写的。

按存在形态分三种：有框线的规则表格、靠空白对齐的无框线表格、扫描件里的表格。第一种理论上可以靠检测线条位置反推单元格，第二种只能靠文字坐标聚类，第三种必须先 OCR 拿到带坐标的词框。三种的解法完全不同，别指望一个函数通吃。

3.2 走 Python 桥接拿坐标，这是最省力的路

MATLAB 官方没有表格识别 API，最实用的办法是通过pyenv调用 Python 侧的 PDF 库。配好环境后，MATLAB 里能直接py.xxx调用。

pyenv('Version', 'C:\Python311\python.exe'); % 换成你自己的解释器路径 plumber = py.importlib.import_module('pdfplumber'); pdf = plumber.open(pdfFile); pg = pdf.pages{1}; % Python 的 0 基索引 rawTbls = pg.extract_tables(); % 返回 Python list

pyenv有几个硬性限制：MATLAB 启动后只能设置一次，改了必须重启；解释器版本必须和 MATLAB 支持的版本范围匹配；路径里有中文或者空格容易出问题。这几点踩过一次就记住了。

拿到的是嵌套的 Python 结构，得转成 MATLAB 的 cell 或 table，否则后面没法用：

function T = pyTable2matlab(pyTbl) rows = cell(pyTbl); % 外层是行 nR = numel(rows); nC = numel(cell(rows{1})); C = strings(nR, nC); for i = 1:nR r = cell(rows{i}); for j = 1:nC v = r{j}; if isa(v,'py.NoneType') || isempty(v) C(i,j) = ""; else C(i,j) = string(v); end end end T = cell2table(cellstr(C)); end

isa(v,'py.NoneType')这个判断必须加。Python 里的空单元格是None，直接string(None)会给你一个诡异的"None"字符串，然后你的表里全是 None，做数值转换时一片NaN。我第一版代码就漏了这个判断，排查了快一小时才发现问题出在类型转换。

3.3 无框线表格：用文字坐标聚类

extract_tables对无框线的表格经常抽不出来，这时候得自己动手。思路是拿每个词的坐标，先按纵向聚成行，再按横向切成列。

words = pg.extract_words(); % 每个元素含 text / x0 / x1 / top / bottom w = cell(words); n = numel(w); txt = strings(n,1); top = zeros(n,1); x0 = zeros(n,1); x1 = zeros(n,1); for i = 1:n d = w{i}; txt(i) = string(d{'text'}); top(i) = double(d{'top'}); x0(i) = double(d{'x0'}); x1(i) = double(d{'x1'}); end % 按 top 排序后聚行 [top, idx] = sort(top); txt = txt(idx); x0 = x0(idx); x1 = x1(idx); tol = 0.6 * median(x1 - x0) / 4; % 经验容差，跟字号挂钩 rowId = cumsum([true; diff(top) > tol]);

行聚好之后聚列：把每个词的横向中心点排序，相邻中心点间距超过一个阈值就切一刀。阈值取“中位字宽”的三到五倍比较稳，太小会把一列切成两列，太大会把相邻两列并成一列。这个参数必须拿两三页样本试出来，用固定值跨文档复用一定会翻车，因为不同文档的字号和栏宽差异很大。

聚完的行列其实是一个稀疏矩阵，每个格子里可能没有词、有一个词、有多个词。多个词的要按 x 顺序拼起来，中间补空格；没有词的填空。拼的时候有个小技巧：如果两个词的间隙超过一个半字宽，中间补两个空格，这样后面再分列时还能恢复。

3.4 校验比识别更重要

表格识别做完，我最花时间的不是抽，是验。三个校验点，缺一不可。

第一，维度校验。抽出来的表格行列数，和你肉眼看到的对不对得上。这个方法土，但能一次性抓出“整列丢失”这种致命错误。

第二，数值校验。数值列的转换失败率超过 5%，说明列错位了。原因通常是某一行的某个单元格是空的，导致后面的值整体左移一格。

col = T.Var3; num = str2double(erase(string(col), ["，",","," "])); badRate = mean(isnan(num) & strlength(string(col)) > 0); if badRate > 0.05 warning("第 3 列可能有列错位，失败率 %.1f%%", badRate*100); end

第三，合计校验。如果表里有“合计”行，把分项加一遍和合计对比。差值是零说明结构化完全正确，差值非零说明有单元格串行了或者被漏掉了。这是我最信任的一种校验，因为它不看格式只看数。

落到 Excel 的时候，我习惯一个 PDF 一页一个 sheet，sheet 名带上页码：

writetable(T, outXlsx, 'Sheet', "P" + k, 'WriteVariableNames', false);

关掉变量名是因为原表本来就有表头行，让它当普通数据写进去，格式和视觉一致，后面人工核对时不用来回对照。

4. OCR 处理：扫描件的兜底方案

4.1 环境与语言包

OCR 这层用的是ocr函数，属于 Computer Vision Toolbox。中文识别需要额外装语言数据，装完才能指定语言。

img = imread("page1.png"); res = ocr(img, 'Language', 'chinese', 'LayoutAnalysis', 'block'); fprintf("识别 %d 个词，平均置信度 %.1f\n", numel(res.Words), mean(res.Confidences));

res是个对象，除了.Text还有.Words（词列表）、.WordBoundingBoxes（每个词的框）、.Confidences（置信度）。后面做表格和定位全靠这几个属性，只取.Text是浪费。

LayoutAnalysis这个参数值得单独说。默认的自动模式在版面规整的文档上表现不错，但遇到多栏、带侧边注的页面会乱序。设成'block'让它按块分析，顺序会稳一些，代价是速度慢一点。我的习惯是先自动跑一页看看，读着顺就不动，读着跳来跳去再改块模式。

4.2 页面渲染：DPI 决定上限

MATLAB 本身没有 PDF 转图片的原生函数，还是走外部命令行工具。核心参数就一个：分辨率。

pdftoppm -r 300 -png -f 12 -l 12 "sample.pdf" "page12"

为什么是 300 DPI？这是印刷行业的老经验值，对应人眼在正常阅读距离下的分辨极限。实测下来，200 DPI 以下，六号字和上标下标开始大面积出错；300 DPI 是性价比拐点；400 DPI 以上识别率的提升非常有限，但单页耗时差不多翻倍，磁盘占用也翻倍。一页 A4 彩色 300 DPI 的 PNG 大概三到八兆，如果你一年要处理几万页，磁盘规划得提前做。

还有一个细节：如果原文档是纯文字的黑白扫描，用-gray或者直接输出单色位图能显著减小文件体积，OCR 效果基本无损。彩色封面、带底纹的页面则必须保留灰度，二值化留给后面自己做，让工具过早扔掉信息是不可逆的。

4.3 预处理：克制比激进更有效

网上一搜 OCR 预处理，全是“灰度化、二值化、去噪、锐化、形态学”一整套流程。我实测的结论和这个直觉相反：对现代 OCR 引擎来说，过度预处理往往是负收益。

原因在于引擎内部已经有一套自适应的二值化和版面分析，你把图先处理成黑白硬边，等于替它做了决定，而且做错的概率不低。底纹、水印、纸张泛黄这些情况它自己处理得比手写阈值好。

我的实际做法分两档。干净文档：直接喂原图或者灰度图，不做任何处理，只在必要时加一层轻微的中值滤波去掉椒盐噪点。

g = rgb2gray(img); g = medfilt2(g, [3 3]);

脏文档（有底纹、有水印、扫描歪斜）：先做倾斜校正，再做自适应二值化。倾斜校正用霍夫变换找文本行主方向：

bw = ~imbinarize(g, 'adaptive'); [H,T,R] = hough(bw); P = houghpeaks(H, 5, 'Threshold', ceil(0.3*max(H(:)))); lines = houghlines(bw, T, R, P, 'FillGap', 20, 'MinLength', 80); ang = median([lines.theta]); g2 = imrotate(g, -ang, 'bilinear', 'crop');

这里的符号方向别死记，跑一次看看图是更歪了还是更正了，歪了就取反。我第一版就是符号反了，越校正越歪，还以为是霍夫变换参数不对。倾斜超过两三度的扫描件，校正带来的识别率提升非常明显，尤其是表格和数字列。

二值化只在背景脏的时候上，而且用自适应而不是全局阈值：

bw = imbinarize(g2, 'adaptive', 'ForegroundPolarity', 'dark', 'Sensitivity', 0.5);

Sensitivity在 0.4 到 0.6 之间调，太低会丢细笔画，太高会把噪点当文字。这个参数我一般拿一页跑三个值，肉眼比一比哪个干净，别猜。

4.4 结果回填与置信度过滤

OCR 出来的词带置信度，这是它比纯文本引擎强的地方。中文识别的置信度普遍偏低，我的经验阈值是 60：低于 60 的词标记出来，不直接丢，因为很多是单位符号和标点，丢了反而破坏语义连续性。

lowIdx = find(res.Confidences < 60); suspect = res.Words(lowIdx);

这些可疑词我一般不自动纠正，而是导出成一张待核对清单，和原文页码一起交给人工过一遍。全自动纠正风险太大，尤其是数字——8和B、0和O、1和l这些混淆，改错的代价比不改高得多。

如果 OCR 是为了抽表格，那还得用词框坐标走一遍第 3 节的聚类逻辑，只不过数据源从extract_words换成了res.WordBoundingBoxes。框的格式是[x y w h]，转成左上右下的坐标后就一样处理了。

4.5 批量跑与性能

几百页以上必须并行。parfor按页分发，每页独立渲染独立识别，天然适合并行。

parfor k = 1:nPage try pngFile = renderPage(pdfFile, k, tmpDir); % 外部工具渲染 res = ocr(imread(pngFile), 'Language','chinese'); save(fullfile(cacheDir, sprintf("ocr_%04d.mat",k)), "res"); catch ME warning("第 %d 页 OCR 失败：%s", k, ME.message); end end

两个要点。一是每页结果立刻落盘，别攒在内存里最后统一写。OCR 是长任务，跑到第 400 页崩了，前面全丢是最让人崩溃的事。有了缓存文件，重跑时先isfile判断一下就跳过。

二是先判定再 OCR。文本型页面完全不需要 OCR，白烧算力。逐页跑一次文本提取，密度正常就跳过 OCR，这一步能省掉混合型文档里六成以上的无效计算。我第一次没做这个判定，一份两百页的文档跑了四十多分钟，后来加上前置判断，同样的文档八分钟跑完。

5. 把三段活串成一条流水线

5.1 主流程骨架

三段能力单独跑通之后，要合成一个可重复调用的入口。我的骨架长这样：先探测、再分流、后落盘，每页独立决策。

function runPipeline(pdfFile, outDir) info = probePDF(pdfFile); % 页数、体质、是否需要 OCR cache = fullfile(outDir, "cache"); if ~isfolder(cache), mkdir(cache); end for k = 1:info.nPage matFile = fullfile(cache, sprintf("p%04d.mat", k)); if isfile(matFile), continue; end % 断点续跑 switch info.pageMode(k) case "text" rec = extractPageText(pdfFile, k); case "ocr" rec = extractPageOCR(pdfFile, k, info.dpi); otherwise rec = extractPageHybrid(pdfFile, k, info.dpi); end rec.page = k; save(matFile, "rec"); end assemble(outDir); % 汇总成 table / Excel end

这个骨架的价值在于每页都是一个独立事务。渲染失败、识别失败、提取失败，都只影响一页，其余照跑。做工程化最怕的就是“一荣俱荣一损俱损”的大事务，尤其是处理不可控的外部文件。

5.2 日志与人工复核清单

流水线跑完，我一定会输出两份东西：一份是结构化数据，一份是问题清单。问题清单里至少包含三类记录——提取失败的页码、OCR 置信度低于阈值的词及其位置、表格数值转换失败率超标的页。

这三类记录是后续迭代的燃料。比如你发现某几页总是提取失败，去看看那几页长什么样，大概率是插了一整页图片；某几页 OCR 错字特别多，八成是扫描分辨率不够或者盖了公章。没有复核清单的自动化流水线，跑完你也不敢用结果。

5.3 一致性校验

最后一道关是交叉校验。对混合型文档，同一页用两条路各跑一次，比对关键字段是否一致。文本层提取出来的编号，和 OCR 出来的编号如果对不上，说明这页的文字层不可信，应该以 OCR 结果为准。

这个思路听着笨，但在我处理过的那批“别人 OCR 完又存成 PDF”的文件里救过好几次。那些文件的文字层看着完整，实际上错字率惊人，纯靠文本提取会把错误一路带进最终报表，而且因为格式规整，你根本不会怀疑它。

6. 常见问题与排查速查表

6.1 报错与乱码类

编码这一条单独展开一句。中文 Windows 环境下，命令行工具默认输出编码经常不是 UTF-8，fileread读回来就是一串乱码。显式指定编码比事后猜要省事得多：

fid = fopen("page7.txt", "r", "n", "UTF-8"); s = fread(fid, "*char")'; fclose(fid);

6.2 结果质量类

文字顺序错乱。双栏、多栏排版的原生问题。缓解办法是按坐标重排：拿到词框后先聚类成列，再按列内纵向排序。纯文本提取做不到，必须走坐标路线。

表格列错位。最常见的原因是有合并单元格。合并单元格在 PDF 里就是“某个文字框跨了两列宽”，用固定列边界去切必然错。处理办法是先识别出跨越列边界的宽框，把它单独拆出来当一列，或者干脆把这一行标记为“需人工确认”。

OCR 数字识别错误。小数点被识别成逗号、0被识别成O。我的处理是识别完之后做一次数值域的白名单校正：只在数字列里，把O→0、l→1、,→.，其他列绝不动。范围一定要卡死，全表替换会把正文里的字母也毁掉。

页眉漏删。文档中途换章节，页眉变了，单一阈值抓不全。改进办法是分段统计，或者用“该行不含任何标点且长度小于 20 字符且在页面首尾”的组合条件，比纯重复率稳。

6.3 几条踩出来的经验

第一条，先小样本跑通再批量。十页样本能暴露九成的问题，而且改起来快。我见过太多人直接上五百页，跑到一半发现字段全错，重跑一次又是半小时。

第二条，中间产物一律落盘。文本、图片、OCR 结果各存一份，别嫌占地方。排查问题时你能直接打开看，比在代码里加断点打印高效十倍。批处理任务尤其如此，可复现比省磁盘重要得多。

第三条，参数不要跨文档复用。行聚类的容差、列切分的阈值、二值化的敏感度，这些全都和字号、栏宽、扫描质量强相关。我现在的做法是把这些参数写成一个配置文件，每个文档批次单独调一次，调完的参数和批次号一起记下来，下次遇到同类文档直接复用，省事又不至于瞎猜。

第四条，接受不完美。PDF 这个格式从设计之初就不是为了让人反向解析的，它更像一份“打印说明书”。指望百分之百还原结构是不现实的，工程上能做到百分之九十五，剩下的百分之五靠人工复核清单兜住，就是很健康的方案了。我早期总想把错字率压到零，花了大量时间调预处理，最后发现把那份时间拿去做好复核界面，整体效率高得多。

第五条，纯属个人偏好：整条链路我尽量让 MATLAB 只干两件事——调度和清洗。凡是涉及“理解版面”的活，全部推给专门的工具去做。这个边界一旦守住，代码会变得很短，出问题也容易定位。反过来，如果你硬要在 MATLAB 里手写 PDF 解析器，那条路能走，但维护成本会让你后悔。