做C#开发的朋友，十有八九会遇到这类需求：从一张JPG里把订单号扣出来，从一个扫描合同PDF里全文检索关键词，或者给内部OA加一个凭证自动录入功能。我去年接过一个项目，对方发来80多个扫描版PDF，全是票据，要求把每页的内容变成可检索的文本。拿到文件我第一反应是直接调PDF解析库，结果翻开一看每页就是一张大图，字符全是"画"上去的。这种文件，常规的PDF解析器根本读不出东西，真正要做的是OCR——把图像里的文字识别成字符串。这篇文章就是围绕这个场景，把C#读取图片文本和扫描PDF文本的完整方案拆开讲清楚：怎么选引擎、怎么写代码、识别率怎么提升、生产环境会踩哪些坑。
1. 需求拆解：图片、扫描PDF和文字PDF的底层差异
1.1 三种输入形态，三种完全不同的处理方式
很多人刚开始做这个需求时，会下意识把所有文件都丢给PDF解析库处理，这是最大的误区。实际上"读文本"这个动作在底层分三条完全不同的技术路线。
第一种是纯图片，JPG、PNG、BMP都算。图片本身没有"文本"概念，只有像素矩阵，唯一能做的事就是OCR。第二种是扫描版PDF，这类文件表面上是PDF，实际上每页可能只有一到两张内嵌大图，是从扫描仪或相机直接生成的，本质上还是图片。第三种是文字版PDF，页面里保存的是真正的字符编码信息，Ctrl+A能选、能复制，这种文件直接用PDF解析库提取就好，不需要走OCR。
判断一个PDF属于哪类，最笨也最有效的方法是提取首页文本，如果返回空或者只有几个空格换行，基本可以断定是扫描版。我接手的那批票据PDF就是这么确认的，80多个文件里只有5个是文字版，剩下全是扫描图。这个比例在真实业务里很常见，尤其是合同、发票、银行回单、纸质档案电子化这类场景。
1.2 OCR的边界：能识别什么，不能识别什么
OCR全称Optical Character Recognition，原理是先把图像转成二值图，然后通过连通域分析切分出字符块，再用训练好的模型进行特征匹配或深度学习推理。听起来复杂，但实际使用中你只需要理解它的能力边界。
它对印刷体、规整的字体识别率很高，中文简体配合好用的引擎能做到95%以上的准确率；但对手写体、艺术字、复杂表格内的跨行文本、带水印和印章遮挡的文字，效果会断崖式下降。公式、特殊符号、表格结构也不能完全依赖OCR恢复成结构化数据——OCR给你的是一段带有坐标信息的字符串流，表格的"行列关系"需要你自己根据坐标重建。
所以项目启动时就要和需求方对齐这个边界。我当时的做法是把OCR产出定位成"可检索文本"，而不是"结构化字段"。票据里的金额、日期、单号这些关键字段，可以在OCR文本基础上用正则或关键词二次提取，但前提是OCR识别结果的准确率足够高、排版足够规整。
1.3 识别整体交付物：文本还是结构化数据
在写代码之前，先想清楚交付物。如果你只需要"能搜索"，把每页文本按顺序拼成TXT就够了；如果你要的是"换一种格式还能再编辑"，那至少要保留每个文本框的坐标、置信度，甚至输出的JSON格式里要有词级别（Word级别）的数据。
Tesseract这类引擎默认只给你整页拼接后的字符串，但如果打开迭代器模式，可以拿到每个单词的包围盒坐标和识别置信度。这些信息在后续做关键词定位、区域裁剪、自动校对时特别有用。不要一开始就贪多，我建议第一版先输出两个东西：整页文本和带坐标的Words集合，分别对应"可检索"和"可定位"两类需求。
2. OCR引擎选型：Tesseract、PaddleOCR和Windows内置OCR怎么选
2.1 Tesseract：C#生态里的老牌默认选择
Tesseract从1985年起步，2005年被Google接手后持续维护到现在，目前已经到5.x版本。C#侧最常用的NuGet包就叫Tesseract，社区也习惯称为Tesseract.NET。它底层封装了C++引擎和Leptonica图像处理库，好处是离线可用、不依赖外部服务、支持100多种语言，并且可以通过tessdata目录随时切换语言包。
它的短板也很明显：纯CPU推理，单张A4扫描图的识别时间通常在0.5到2秒之间；对中文长文本的识别效果不如专门为中文优化的深度学习引擎。但如果你做的是通用工具类应用，或者部署环境不允许联网，Tesseract依然是C#侧性价比最高的选择。
2.2 PaddleOCR：中文场景下的识别效果担当
PaddleOCR是百度开源的OCR工具包，PP-OCRv4系列模型在中文印刷体、复杂背景、倾斜文本上的表现明显优于Tesseract。C#接入的方式有几种：一是通过Sdcb.PaddleOCR这个包装库，它把PaddleOCR的C++推理封装成了.NET可调用的API；二是把PaddleOCR部署成一个本地服务，C#通过HTTP调用；三是直接用C++编译动态库，再通过P/Invoke自行封装——这种方式适合对性能有极端要求的场景。
我当时在中文票据项目里真正用于识别的就是PaddleOCR的模型，但它是以本地服务方式接入的，C#主程序主要负责PDF解析、图片预处理和服务调度。这里要提醒一句：PaddleOCR的模型文件比较大，安装部署没那么轻量，需要额外处理依赖库和模型下载，如果你只是偶尔识别几张图，没必要上这么重的东西。
2.3 Windows.Media.Ocr：系统自带但容易被忽略的选项
Windows 10/11系统自带一个OCR引擎，命名空间是Windows.Media.Ocr，可以通过Windows SDK在WinForms或WPF项目里引用。它对中文、英文识别都还可以，零额外部署成本，不会大地增加安装包体积。
但它有几个硬约束：只能在Windows上跑，需要用SoftwareBitmap这类Windows Runtime类型做输入，项目目标框架需要支持Windows Runtime引用，跨平台部署基本不可能。如果你的产品本身就是Windows桌面工具、又不想引入庞大的OCR依赖，可以考虑它。我在内部小工具里用过，初始化快、识别速度也可接受，但遇到背景复杂或低对比度图片时效果不稳定。
2.4 选型对比与我的建议
| 引擎 | 中文识别质量 | 部署复杂度 | 速度 | 最佳使用场景 |
|---|---|---|---|---|
| Tesseract 5 | 中 | 低，NuGet一步到位 | 中 | 离线批量提取、跨平台桌面工具 |
| PaddleOCR | 高 | 高，依赖模型和运行库 | 中到高，取决CPU/GPU | 中文票据、复杂版面、对准确率要求高 |
| Windows.Media.Ocr | 中上 | 低，仅限Windows | 快 | Windows桌面轻量工具 |
| 云端OCR | 高 | 低，依赖网络 | 快但受网络限制 | 要求准确率最高、能接受公网传输 |
我的选型方法论很简单：先看部署环境能不能联网，再看目标语言和识别难度，最后考虑维护成本。纯离线、多语言的通用扫描件优先Tesseract；中文为主、版面复杂、识别率是核心指标的场景优先PaddleOCR；个人小工具或者演示Demo优先Windows.Media.Ocr；如果客户能接受数据出局，云端OCR是最省事的，准确率也最稳。
3. Tesseract接入C#的完整实践：从NuGet到第一段识别代码
3.1 安装包和tessdata语言包：最常见的卡点
用NuGet安装Tesseract包非常简单，在Visual Studio的包管理控制台执行：
Install-Package Tesseract但这一步之后很多人就卡住了——运行时直接报错说找不到语言包。因为Tesseract自身不带语言包，需要单独去GitHub的tesseract-ocr/tessdata仓库下载，核心的中文文件是chi_sim.traineddata（简体中文）、chi_tra.traineddata（繁体中文），英文是eng.traineddata。
一个容易忽略的坑是版本匹配问题。Tesseract 4.0和5.0的traineddata格式有差异，尽量选择与NuGet包大版本一致的tessdata版本。我习惯在项目目录下建一个tessdata文件夹，把训练数据放进去，并把文件夹属性设为"始终复制"，这样发布后不会找不到文件。目录结构大致如下：
bin/ tessdata/ chi_sim.traineddata eng.traineddata3.2 基础识别代码：五步走
Tesseract.NET的用法非常固定，核心流程是先创建引擎，再加载图像，然后处理，最后取结果。看代码：
using Tesseract; // 1. 创建识别引擎，指定语言，中文和英文同时启用 using var engine = new TesseractEngine(@"./tessdata", "chi_sim+eng", EngineMode.Default); // 2. 加载图像。注意Tesseract使用Pix类型，而不是System.Drawing.Bitmap using var pix = Pix.LoadFromFile(@"C:\data\invoice.png"); // 3. 执行识别，PageSegMode.Auto让引擎自动判断版面 using var page = engine.Process(pix, PageSegMode.Auto); // 4. 取整页文本 string text = page.GetText(); Console.WriteLine(text); // 5. 取平均置信度 float confidence = page.GetMeanConfidence(); Console.WriteLine($"识别置信度：{confidence:P1}");这段代码基本可以照抄。需要注意Pix.LoadFromFile是Leptonica库的图像类型，如果你想从一个MemoryStream或字节数组识别，可以这样：
byte[] imageBytes = GetImageBytes(); // 从数据库或接口拿到图片字节 using var pix = Pix.LoadFromMemory(imageBytes); using var page = engine.Process(pix);我把这一步比喻成"先把图片翻译成引擎认识的语言"，中间不要自作聪明转成Bitmap再转回Pix，绕了一圈反而可能丢失图像质量。
3.3 拿到单词级坐标和置信度：进阶用法
整页文本适用于全文检索，但如果你需要知道某个关键词出现在图片的哪个位置，比如定位发票右上角的代码区域，就要用迭代器：
using var page = engine.Process(pix, PageSegMode.Auto); using var iter = page.GetIterator(); iter.Begin(); do { // 遍历Word级别的文本块 if (iter.TryGetBoundingBox(PageIteratorLevel.Word, out var box)) { string word = iter.GetText(PageIteratorLevel.Word); float wordConfidence = iter.GetConfidence(PageIteratorLevel.Word); Console.WriteLine($"{word} | 置信度:{wordConfidence:F2} | 坐标:X={box.X1},Y={box.Y1},宽={box.Width},高={box.Height}"); } } while (iter.Next(PageIteratorLevel.Word));这里有一个实际经验：整页的平均置信度往往会掩盖局部问题，比如一页里90%的文字都很清楚，但某个关键数字识别错了。所以我在做票据项目时，会同时输出所有置信度低于阈值的单词列表，单独交给人工复核而不是直接入库。阈值通常设在0.6，低于这个值的基本是模糊、倾斜或被盖章遮挡的区域。
3.4 PageSegMode：经常被忽略的关键参数
Tesseract的识别结果好不好，一半看图像，另一半看PageSegMode。这个参数是告诉引擎"这一页大概是什么版面结构"。
我常用的是这些模式：
PageSegMode.Auto：全自动，引擎自己判断，适合混合场景PageSegMode.SingleBlock：整页是单一块文字，适合连续正文PageSegMode.SingleLine：单行文本，适合验证码或标题PageSegMode.SingleWord：单个单词，适合标签纸上的单词识别PageSegMode.SparseText：稀疏文本，适合表格、票据这类文字分布零散的情况
票据识别用SparseText往往比Auto效果好，因为票据上的文字分散在页面各处，Auto模式可能把分割线、印章误判成文字块。反之，扫描合同这种大段正文用Auto或SingleBlock都没问题。这个参数在集成包时往往被忽略，但它是优化识别率的成本最低的手段之一。
4. 别急着换引擎：图像预处理三板斧
4.1 为什么预处理比换引擎更能提升识别率
我做过的项目里有一半"识别率惨不忍睹"的案例，最后发现问题不在OCR引擎，而在图像本身。扫描件常见的问题包括：亮度低、背景发灰、文字和背景对比度不足、页面扫描歪斜、分辨率过低。OCR引擎对这类脏输入非常敏感，尤其是Tesseract这类基于特征匹配的引擎，灰度层次稍微复杂一点，字符分割就出错。
预处理的目的就是用代码把图像"矫正"成适合OCR的理想状态：纯黑背景、纯白字符、字号合适、边缘清晰。花10分钟写预处理，往往比换一个昂贵的商业识别引擎更有效。我实测过一组对比，同一张发票原图Tesseract识别率只有82%，做了灰度化和二值化后直接到94%，再做缩放增强能到96%以上。
4.2 灰度化与二值化：消除背景干扰
彩色图像里的颜色信息对文字识别没有直接帮助，反而可能干扰字符分割。所以第一步通常是把图像转为灰度，再进一步转为黑白二值图。这一步可以明显滤掉浅色背景、水印图案。
using SixLabors.ImageSharp; using SixLabors.ImageSharp.Processing; using var image = Image.Load<Rgba32>(@"C:\data\raw.png"); image.Mutate(x => x .Grayscale() // 灰度化 .BinaryThreshold(0.55f) // 二值化，阈值可调 ); image.SaveAsPng(@"C:\data\processed.png");这里有一个参数要重点讲：BinaryThreshold的阈值决定了"哪些像素算黑，哪些算白"。0.55是经验值，但要根据实际图片微调。如果原图偏暗，阈值可以调低到0.45，避免把淡笔字也滤掉；如果背景发灰，阈值调高到0.65可以更彻底地把背景变白。我建议在工具里把这个参数做成可配置项，而不是硬编码。
4.3 分辨率和缩放：300DPI是黄金标准
OCR对字号敏感，网络上直接下载的图片许多只有72DPI，打印出来的扫描PDF分辨率也参差不齐。经验法则是：让图像中文字的像素高度保持在30到50像素之间，对应300DPI左右扫描件。太小的字切分困难，太大的字反而会在二值化时产生断笔。
我用ImageSharp做缩放的方式是设定一个目标宽度，等比缩放：
using var image = Image.Load<Rgba32>(@"C:\data\processed.png"); image.Mutate(x => x.Resize(new ResizeOptions { // 目标宽度2200像素，大约等于300DPI的A4纸宽度 Size = new Size(2200, 2200), Mode = ResizeMode.Max }));注意ResizeMode.Max表示保持宽高比，只在长边超过设定值时缩小，不会把图片强制拉伸变形。这个目标宽度值不用死记，理解原理就好：你要做的是保证OCR能看清每个字符的笔画结构，而不是追求图片本身的分辨率。
4.4 倾斜校正：让文字回到水平线
扫描仪偶尔会吐出一页歪斜的PDF，倾斜超过10度的图像会让OCR的字符切分完全乱掉。倾斜校正通常有两种做法。
第一种是用图像形态学算子求文本行的倾斜角度，然后反向旋转，这种方案需要接入OpenCVSharp做膨胀腐蚀和霍夫变换，代码量比较大。第二种是直接识别多个文本块的坐标，计算它们的平均倾斜角，再用ImageSharp旋转回来。第二种在Tesseract拿到坐标后就能实现，但需要在识别之后才做校正，属于两轮识别。
我的建议是：如果扫描件来自固定设备，倾斜规律基本一致，可以用第一种方案做一个固定的自动旋转；如果是用户随手拍照上传的图片，倾斜角度随机，那么优先用PaddleOCR这类对倾斜鲁棒性更强的引擎，省去校正的复杂度。
5. 扫描PDF的完整读取管线：从PDF解析到汇总输出
5.1 先判定PDF类型：文字版直接提，扫描版走OCR
处理PDF的第一步不是盲目OCR，而是先判定类型。用iText7提取每页文本，如果文本量足够，直接返回结果，省去大量OCR计算；只有文本为空时才走OCR链路。
using iText.Kernel.Pdf; using iText.Kernel.Pdf.Canvas.Parser; public bool IsScannedPdf(string pdfPath) { using var pdfDoc = new PdfDocument(new PdfReader(pdfPath)); for (int i = 1; i <= pdfDoc.GetNumberOfPages(); i++) { string pageText = PdfTextExtractor.GetTextFromPage(pdfDoc.GetPage(i)); if (!string.IsNullOrWhiteSpace(pageText)) return false; } return true; }这里有一个细节：有些混合型PDF，部分页是文字层，部分页是扫描图。比如一个合同，首页可能是电子签名的文字页，后面附件是扫描页。所以更稳妥的做法是逐页判断，而不是整个PDF一刀切。我在项目里定义了每个页面的处理策略：有文本的页直接提取，没文本的页抽取图像再OCR，最后按页号合并输出。
5.2 用iText7抽取PDF内嵌图像：核心代码
扫描版PDF中的图像以XObject形式嵌入到页面资源对象里，iText7可以把这个对象读出来转成字节数组。注意这里不需要先把PDF整个渲染成位图，扫描PDF的内嵌图像本身就是完整的，直接抽取效率最高。
using iText.Kernel.Pdf; using iText.Kernel.Pdf.Xobject; public List<byte[]> ExtractImagesFromPage(PdfPage page) { var result = new List<byte[]>(); // 获取页面资源字典 var pageDict = page.GetPdfObject(); var resources = pageDict.GetAsDictionary(PdfName.Resources); if (resources == null || !resources.ContainsKey(PdfName.XObject)) return result; var xObjects = resources.GetAsDictionary(PdfName.XObject); if (xObjects == null) return result; foreach (var name in xObjects.KeySet()) { var xObjectStream = xObjects.GetAsStream(name); if (xObjectStream == null) continue; var image = new PdfImageXObject(xObjectStream); byte[] imageBytes = image.GetImageBytes(); result.Add(imageBytes); } return result; }PdfImageXObject是iText7里专门封装图像XObject的类，GetImageBytes()返回解码后的真实图片数据，后续可以直接塞给Tesseract或PaddleOCR。
需要注意，有的扫描PDF每页只有一张大图，有的会切成一堆小图块，比如扫描时的条带分割。如果发现一页抽出来很多碎片（比如每个只有几KB），说明原始PDF的存储方式不规整，这时候简单的图像拼接或直接整页渲染可能是更好的兜底方案。可靠性最高的兜底是用Ghostscript把PDF页面渲染成整张PNG，代码不复杂，但需要额外分发一个外部exe，部署时要考虑。
5.3 完整的批量处理管线：串起来跑通
把所有环节串成一个完整处理函数，大概是这样的逻辑：
public string ExtractTextFromPdfPage(PdfPage page, TesseractEngine engine) { // 先提取文本，有就直接返回 string text = PdfTextExtractor.GetTextFromPage(page); if (!string.IsNullOrWhiteSpace(text)) return text; // 没有文本就抽取图像 var images = ExtractImagesFromPage(page); if (images.Count == 0) return string.Empty; // 用OCR处理第一张最大的图 byte[] mainImage = images.OrderByDescending(img => img.Length).First(); using var pix = Pix.LoadFromMemory(mainImage); using var result = engine.Process(pix, PageSegMode.Auto); return result.GetText(); }这里用OrderByDescending取最大的一张图，是因为很多扫描PDF其实页面里就一张完整扫描图，其他都是掩膜或补丁，直接拿最大的最省事。如果前面预处理那步已经写了缩放和灰度化，在调用Pix.LoadFromMemory之前可以把图像先过一遍ImageSharp，这样识别效果会更好。
5.4 多页和批量的内存管理：别把PDF全读进内存
处理200MB的大PDF时，最忌讳的做法是new PdfDocument(new PdfReader(...))后一口气遍历完所有页面，同时保存所有图像字节。PDF解析库本身会持有页面资源的引用，不释放的话内存占用会持续暴涨。
我的做法是逐页处理、逐页丢弃。每页OCR完之后，立即清空引用并调用GC.Collect()——虽然显示调用GC不优雅，但处理超大文档时确实能稳住峰值内存。还有一个实用技巧：先跑一遍pdfDoc.GetNumberOfPages()，把页数打印到日志，用ConcurrentBag<string>收集每页结果，最后统一写文件时再排序，这样方便中途断点续传。
批量处理时可以考虑用Parallel.For并行识别不同PDF文件，但要注意Tesseract引擎实例不是线程安全的。正确姿势是每个线程独享一个引擎实例：
var threadLocalEngine = new ThreadLocal<TesseractEngine>( () => new TesseractEngine(tessdata, "chi_sim+eng", EngineMode.Default) ); Parallel.ForEach(files, new ParallelOptions { MaxDegreeOfParallelism = 4 }, file => { var engine = threadLocalEngine.Value; // 识别逻辑 });ThreadLocal<T>保证了每个线程拿到的都是独立引擎实例，避免并发冲突。最大并行度建议按CPU物理核数的一半设置，因为OCR本身是CPU密集型，并行过多会导致线程切换开销，识别总时长反而没降多少。
6. 踩坑实录：真实项目里的六个高频问题
6.1 识别结果乱码和问号：语言包和编码同时排查
中文OCR出来一堆????是最让人头疼的问题。我第一次遇到时以为是引擎坏了，排查了很久，最后定位到两个原因：一是语言包只加载了英文，没有加载chi_sim，中文全部无法识别；二是输出文件编码不对，控制台和TXT文件没按UTF-8写入。
区分问题来源有一个简单方法：把识别结果打印到控制台看。如果控制台显示中文正常，写文件后打开是乱码，那就是写文件编码的问题；如果控制台本身就是问号，那大概率是语言包没配好。写文件时明确指定UTF-8：
File.WriteAllText(outputPath, text, new UTF8Encoding(false));顺带说一句，chi_sim+eng这种多语言组合并不是越多越好，语言包越多，引擎的字符候选集越大，识别速度和准确率都会受影响。如果确定是纯中文文档，只加载chi_sim就够了。
6.2 tessdata目录找不到：发布后的隐形炸弹
调试环境下一切正常，一发布到服务器或拷到别的机器就报Failed to init API, possibly an invalid tessdata path——这是所有Tesseract使用者都会遇到的坑。原因不复杂：@"./tessdata"是相对路径，依赖当前工作目录；而Windows服务或计划任务的默认工作目录往往不在程序集所在目录。
解决办法有两种。第一种是把tessdata目录改成绝对定位，用AppDomain.CurrentDomain.BaseDirectory拼出完整路径；第二种是把语言包作为EmbeddedResource嵌入程序集，运行时解压到临时目录。第二种部署更干净，尤其是做成Windows服务时，不会因为工作目录变化而出问题。个人建议走第二条路，因为你就不会再被这个坑烦第二次了。
6.3 每页图片被切碎，抽出来一堆碎片
前面提到过，有些扫描PDF内部的图像存储方式很碎。一种情况是打包时按色板拆分，比如黑白图存为CCITT格式；另一种是按条带切分，一页有十几张长条图。直接用GetImageBytes()拿到的碎片识别效果很差，因为这些条带之间没有上下文，一行文字可能被拦腰切成两段。
我的经验是：如果一页抽出的图像数量超过3张，就不要再逐张识别了，直接切换到整页渲染方案。先用Ghostscript或PdfiumViewer把整页渲染成高分辨率PNG，再对PNG整页OCR。虽然多了一步渲染，但最终识别质量和稳定性都高很多。
6.4 倾斜和旋转页面识别率低下
扫描仪和手机拍摄的照片经常带旋转。手机横拍PDF页面，扫描出来的图像是横着的，OCR直接识别时文字被转置90度，结果自然一塌糊涂。
处理旋转有两个方向。一个是在预处理阶段根据EXIF信息自动转正，另一类是检测页面方向。Tesseract本身没有直接的自动旋转接口，但可以识别两次：第一次用低分辨率图像做方向检测，旋转后再用高分辨率图片正式识别。这个方案在实践中可行，但成本高。
更务实的做法是：如果页面提供方是固定Scanner，就强制要求输出"A4竖版朝上"；如果是用户手机上传，让用户确认页面方向后再提交。我在票据项目里就用了一句话提示加预览图让用户确认方向，就再也没人抱怨识别率低了。
6.5 印章、水印和背景干扰
红头文件、发票、合同上的印章和水印，是OCR最大的天敌。水印在二值化后可能会变成前景文字，印章的红色在灰度化后和黑色文字混在一起，极大干扰字符切分。
预处理不能完全解决所有干扰。我总结了一套常用的处理优先级：先试灰度+二值化，如果印章干扰严重，改用颜色过滤，将红色通道区域直接置白；如果背景是有网格的表格，可以结合形态学闭运算去除细网格线条。在代码里可以用ImageSharp按通道操作：
image.Mutate(x => x .Grayscale() .BinaryThreshold(0.55f) );这一招对大多数白底黑字的扫描件已经够用。如果背景复杂到预处理救不回来，就得依赖PaddleOCR的模型鲁棒性，或者考虑人工介入核对关键字段。
6.6 识别结果没有结构：段落和表格怎么办
OCR输出的文本是所有识别出的字符串按阅读顺序拼接的，表格里的数值会被排成和阅读顺序一致的流水文本，而不是保留行列关系。如果你需要的是表格结构化提取，我的建议是不要试图去控表格线，直接用"关键词定位法"：先通过正则或字符串匹配把字段名找出来，再根据字段名后面的坐标区域去提取对应值。
这个方法在票据上很有效，比如先定位"发票号码"，然后在它的右方200像素内搜索数字。因为Tesseract可以输出每个词的坐标，这种基于坐标的字段提取比硬解析表格结构稳定得多。我在项目里实现的字段提取规则是XML配置化的，每种票据模板配一套提取规则，再配合置信度过滤，整体准确率能达到运营验收标准。
7. 从跑通到上线：性能、日志和监控补充
7.1 性能数据：先摸清自己的基线
在不同环境里，OCR性能差异很大。我提供一个参考基准：单张1000×1400像素扫描图，Tesseract中英文混排识别耗时约0.8秒；PaddleOCR CPU模式约0.5到1秒，GPU模式可以压到0.2秒以内。如果你有1000页文件，Tesseract串行处理大约需要十几个小时，这时必须引入并行和任务队列。
生产环境我建议做成生产者消费者模式：PDF解析线程负责抽取图像，识别线程池负责OCR，结果线程负责写库或写文件。有人可能会问，为什么不直接Parallel.ForEach完事？因为大批量任务需要支持断点续传和失败重试，并行框架虽然快，但遇到中间一个文件损坏，整批重来代价太大。用任务队列配合数据库记录每页处理状态，比裸并行可靠得多。
7.2 日志指标：不只记成功，要记录失败原因
OCR项目上线后，最有价值的不是识别出多少字，而是哪些页面卡住了、哪些页面识别质量差。我为每个处理页面记录三个指标：处理耗时、平均置信度、是否走到了OCR分支（还是直接文本提取）。每日汇总后，可以快速定位是哪台扫描仪、哪个批次、哪类模板的识别率存在问题。
失败重试机制也很关键。我在重试策略上遵循简单原则：同一页最多重试两次，第一次失败就原样保存图片和页面号，不反复消耗计算资源。事后分析时，有原始图片和日志，问题定位效率高得多。
7.3 识别结果的校验方案：不能只靠置信度
置信度是OCR给的，但置信度高不代表内容一定正确。比如字符0和O、1和l，在低清晰度图片上可能被高置信度地识别错。针对固定格式的票据，我额外做了一层规则校验：金额字段必须是数字和小数点，日期字段必须符合日期格式，单号字段必须符合前缀规则。不符合规则的结果直接标记为"待人工复核"。
另外建议对识别结果做词语级校对，比如金额识别成"100,000"就缓存一条记录并弹出警告，因为很多扫描件的千分位逗号和句点极其相似。这种基于业务规则的校验虽然简单，但能让系统的可用性提升一个档次。
7.4 后续扩展方向：从纯文本到文档理解
跑通C#读取图片和扫描PDF文本之后，你的能力边界其实可以继续延伸。OCR只是把图像转成了文本，下一步可以做的是文档分类、关键信息抽取、全文检索引擎接入，甚至用大模型对识别出的票据文本做语义理解。我在现有项目里已经把OCR结果接入了Elasticsearch，实现跨批次搜索；字段提取模块也在逐步迁移到基于规则的配置项上，后续计划引入基于深度学习的命名实体识别。
不过这些扩展都有一个前提：底层的OCR识别质量得稳定。这也是为什么我反复强调图像预处理、引擎选型和数据校验，因为它们共同决定了所有上层应用的效果上限。
8. 最后分享一个省时间的调试技巧
无论选哪个引擎，调试阶段都建议先做"最小验证"：拿一张干净的、大号字体的测试图片跑通全流程，确认语言包、路径、编码都没问题，再切换真实业务图片。这样才能把"代码问题"和"图像问题"分离开。不要一上来就拿难啃的票据图片调试，不然报错时你根本分不清是代码写得不对，还是图片质量太差。
另外，把所有可调参数统一收口到一个配置类里，比如DPI目标值、二值化阈值、PageSegMode、并行度、重试次数，这样在项目验收时能快速做参数调优。我在票据项目里就是因为一开始把这些参数硬编码了，后期为了提高某个模板的识别率，不得不改代码重新编译，浪费了不少时间。
