做C#开发的人多多少少会遇到一个尴尬场景用户丢过来一堆扫描PDF或者照片让你把里面的文字提取出来做检索、做归档、做自动录入。如果这些文件是Word文档那还好说可偏偏是图片或者扫描件直接用PdfPig、iText7去读读出来全是一堆空字符串连个标点都没有。问题不在代码而在文件本身扫描PDF本质上就是一页页的照片照片里只有像素没有可复制的文本层。所以要想从图片和扫描PDF中拿到文字唯一靠谱的路线就是OCR光学字符识别。这篇文章我就把C#环境下读取图片文字、扫描PDF文字这条完整链路拆开讲透包括底层原理、引擎选型、代码实现、参数调优以及我实际踩过的一些坑希望能帮你少走弯路。1. 内容整体设计与思路拆解1.1 扫描PDF与普通PDF的本质区别先说个基础知识很多人一上来就搞混。普通PDF比如Word另存为的PDF、代码生成的PDF里面是有文本对象的每个字符都是一个独立元素记录着字体、大小、坐标所以你用任何PDF解析库都能直接提取出字符串。扫描PDF完全不是一回事。它是把纸质文件用扫描仪或者手机拍下来然后以图片的形式嵌入到PDF页面里。整个页面其实就是一张大图上面没有文字对象、没有字符编码、没有文本层只有RGB像素。这也是为什么你会遇到“用iText7读取扫描PDF返回空字符串”的情况——不是代码写错了而是文件本身就没有文本可读。所以思路就很清晰了要处理扫描PDF先得把PDF的每一页渲染成图片再把图片丢给OCR引擎去识别。整个过程可以理解成“先拍照再认字”。图片识别是基础PDF识别是图片识别的延伸核心都在OCR。1.2 主流的OCR引擎选型对比C#本身不内置OCR能力必须借助现成的OCR引擎或者SDK。我把目前C#生态里最常用的几条路都试过大概可以分成三派第一派是Tesseract。这是一个开源OCR引擎最初是惠普实验室搞的后来Google接手维护目前已经发展到4.x版本采用了LSTM神经网络识别模式识别率比老版本有了质的飞跃。C#这边有Tesseract封装库NuGet直接装就能用支持离线识别语言包丰富中文简体、繁体、英文、数字混排都能处理。这是我个人最常用、也是这篇文章重点讲的方案。第二派是Windows.Media.Ocr这是Windows系统自带的一个UWP接口不需要额外装第三方库。它的优点是调用简单、识别速度快而且对中文支持不错。但缺点也很明显只能在Windows 10及以上系统用只支持WinRT环境部署到Windows Service或者Linux服务器上就玩不转了而且对扫描件这种低质量图像的处理能力一般。第三派是云端OCR服务比如百度、阿里、腾讯、Azure的OCR接口。这类服务识别率确实高尤其是复杂版式、手写体、表格这类场景而且不需要自己调模型。但代价是要联网、要付费、数据要出本地很多企业内部项目过不了安全合规这一关。如果你做的是机密文档处理这路基本可以直接排除。除了上面三派现在还有PaddleOCR这种表现很猛的开源方案也有C#封装可以通过ONNX Runtime加载模型推理。如果你对识别率要求极高、项目时间充裕也可以往这个方向走。但整体复杂度高不少配置起来比Tesseract繁琐对新手不太友好。1.3 为什么推荐优先从Tesseract入手选Tesseract做主力主要是这几点考虑第一完美契合C#桌面端和服务器端场景。不管是WinForm、WPF还是ASP.NET Core WebAPITesseract都能无缝集成NuGet包拉下来就能跑不挑系统环境。第二完全离线运行。对于处理企业内部文档、客户资料这类敏感信息的场景数据不出本机是一个硬要求Tesseract天然满足。第三语言包机制非常灵活。英文、简中、繁中、日文、韩文等等都有独立的数据包还可以通过训练工具训练自己的专用字库比如专门识别发票、车牌、产品型号。我后面会讲到怎么配置多语言识别。第四社区资料多遇到问题基本都能搜到解决方案。作为一个2006年就开源的老牌引擎它的问题已经被无数人问过、踩过、填过坑了不像一些新库出了问题只能自己去翻源码。当然Tesseract不是万能的。它对印刷体文字的识别率很高对复杂手写体的识别就比较吃力对清晰截图识别很准对那种歪歪扭扭、光照不均的手机拍照件就需要做预处理。但“能做、可用、好集成、不花钱”这几点已经覆盖了绝大多数C#开发者的OCR需求。2. 环境准备与核心依赖配置2.1 NuGet包选择既然选定Tesseract路线接下来就把环境搭起来。这里我直接给出经过实测的包组合Tesseract官方C#封装版本建议用5.x或最新稳定版。注意4.x和5.x的API基本一致旧项目升级也不费劲。Tesseract.Data.Eng英文语言包包含eng.traineddata。Tesseract.Data.Chinese简体中文语言包包含chi_sim.traineddata。如果你的文档里还有繁体再装一个Tesseract.Data.Chinese.Traditional。为什么特别强调语言包要单独装因为Tesseract核心引擎本身不含任何语言数据它就像一个没有词典的翻译。你光装了引擎就去识别中文它只会给你吐一堆乱码。语言包决定了它能认出什么语言的字符这是新手最容易漏掉的一步。装包的方式很简单在Visual Studio的NuGet包管理器里搜索这几个名字直接安装即可。或者用Package Manager ConsoleInstall-Package Tesseract Install-Package Tesseract.Data.Eng Install-Package Tesseract.Data.Chinese装完之后你会在输出目录下看到一个tessdata文件夹里面就是各种.traineddata语言包文件。2.2 确认tessdata路径Tesseract初始化的时候会去加载tessdata目录下的语言包所以这个路径绝对不能搞错。如果运行时直接抛异常“Failed to load language chi_sim”或者“TesseractInit failed”90%是tessdata路径没指对。我建议你一开始就显式指定路径而不是依赖默认行为。最稳的做法是把tessdata目录复制到程序运行目录然后用相对路径加载。如果程序部署环境复杂比如放在服务上跑也可以用Application.StartupPath或者AppContext.BaseDirectory拼出完整路径并用Directory.Exists先检查一下目录存在避免因为工作目录变化导致的诡异问题。注意有些版本的Tesseract包会把语言包放在子目录里安装后需要确认一下NUnit输出目录里确实有tessdata文件夹。如果没生成就把语言包文件拷贝过去手动建一个tessdata目录。2.3 第一个能跑的OCR代码环境配置好之后先跑通一个最简单的例子验证整条链路是通的。新建一个控制台项目把下面这段代码粘进去using Tesseract; string tessDataPath Path.Combine(AppContext.BaseDirectory, tessdata); string imagePath D:\test.png; using var engine new TesseractEngine(tessDataPath, chi_sim, EngineMode.Default); using var img Pix.LoadFromFile(imagePath); using var page engine.Process(img); string text page.GetText(); Console.WriteLine(text);这段代码做了四件事初始化OCR引擎、加载图片、执行识别、输出结果。其中引擎实例实现了IDisposable接口必须用using包起来因为每次初始化都会加载几十MB的语言包到内存不释放的话跑几次就会内存吃紧。Pix是Tesseract内部使用的一种图像格式Pix.LoadFromFile可以直接从文件加载图片。这里可能有人会问为什么不直接用System.Drawing.Bitmap因为Tesseract原生API是基于Leptonica库的Pix格式才是它的“母语”直接用Bitmap反而需要额外转换还容易丢灰度信息。2.4 引擎的三种模式怎么选我在代码里用了EngineMode.Default这是新手最稳妥的选择。除此之外还有另外两个模式可以设置EngineMode.TesseractOnly表示只用传统Tesseract算法速度快但识别率比较低适合那种要求性能优先、图像又很清晰的场景。EngineMode.LstmOnly表示只用LSTM神经网络识别率高但速度稍慢。EngineMode.Default让引擎自动选择通常默认就是最佳实践。如果你处理的是普通截图、清晰的扫描件Default完全够用。如果你图片质量很差、文字模糊重影可以试试LstmOnly某些场景下会比Default表现好。反过来如果图片质量好、但量特别大、对速度敏感TesseractOnly也是一种取舍方案。3. 图片文字识别实操与踩坑记录3.1 图片识别的主流程设计大部分业务场景中图片来源不是那种规规矩矩的扫描件而是手机随手拍的、微信传输的、各种设备导出的。这些图片普遍存在几个毛病有旋转角度、有阴影干扰、颜色偏暗、分辨率忽高忽低。如果直接丢给Tesseract识别率会很不稳定。所以一个完整的图片识别流程应该分成四步读取图片、图像预处理、OCR识别、后处理纠错。读取图片这一步用Pix.LoadFromFile或者Bitmap转换都行重点是预处理和OCR的配合。我这里用一个更完整的示例展示涉及图像加载、灰度化、二值化、OCR识别几个环节using Tesseract; using ImageMagick; // 用于图像预处理 string tessDataPath Path.Combine(AppContext.BaseDirectory, tessdata); string imagePath D:\scan.png; using var image new MagickImage(imagePath); // 转为灰度图降低颜色干扰 image.Grayscale(); // 提高对比度让文字更清晰 image.Contrast(); // 如果文字偏浅可以做一下二值化 image.Threshold(new Percentage(70)); // 保存预处理后的图片 string preprocessedPath D:\scan_processed.png; image.Write(preprocessedPath); // 交给Tesseract识别 using var engine new TesseractEngine(tessDataPath, chi_sim, EngineMode.Default); engine.SetVariable(tessedit_char_whitelist, 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz); using var img Pix.LoadFromFile(preprocessedPath); using var page engine.Process(img); Console.WriteLine(page.GetText());这里我用了ImageMagick做预处理库你也可以用OpenCVSharp或者直接System.Drawing效果差别不大关键是预处理这一步不能省。3.2 为什么要先灰度化、再二值化很多彩色图片背景很花有底纹、有水印、有颜色渐变这些都会干扰OCR引擎对文字边缘的判断。灰度化就是把彩色图像变成黑白灰的亮度图等于把颜色信息去掉只保留明暗信息。这一步对Tesseract来说太重要了因为它内部的LSTM网络本身就是基于灰度图像训练的。二值化则是进一步把灰度图变成只有黑白两种像素的图像。文字变成黑色背景变成白色。这样OCR引擎就不用去分辨“浅灰色背景上的深灰色文字”而只需要识别“白底黑字”识别率和稳定性都会提升。但二值化有个坑阈值选不好会直接把文字给抹掉。阈值太高浅色文字变成白色丢了阈值太低深色背景变成黑色噪音大。实际操作中我会先用Contrast提高对比度再做Threshold这样能减少阈值敏感性。如果你的文档背景很干净不做二值化直接灰度化也能取得不错效果。3.3 Tesseract的PageSegMode到底怎么设置PageSegMode是Tesseract一个非常重要的参数它告诉引擎“你面对的是什么样的版面”。默认的Auto模式会根据图像内容自动猜测但对一些特殊图片会猜错。比如你识别一个单行文字条幅用Auto模式会识别得很吃力因为它会默认这是整页文章花费大量时间去分析段落结构。这时候手动指定PageSegMode.SingleLine识别速度和准确率都会大幅提升。using Tesseract; var engine new TesseractEngine(tessDataPath, eng, EngineMode.Default); engine.DefaultPageSegMode PageSegMode.SingleLine;我自己实际测试过一张包含单行文字的截图用Auto模式耗时200ms识别结果还有几个字符错误改成SingleLine之后耗时降到80ms结果完全正确。所以如果你清楚自己的图片版式一定要手动指定分段模式。常见的选择有PageSegMode.SingleBlock适合一行或多行文字的图片块PageSegMode.SingleLine适合单行文本PageSegMode.SingleWord适合单个单词PageSegMode.SparseText适合不规则排版的文字3.4 白名单和黑名单的作用识别一些特定场景时白名单能极大提升准确率。比如识别身份证上的号码、发票右上角的发票代码这些场景内容主要是数字和少量字母中文和标点反而会成为噪音源。通过engine.SetVariable(tessedit_char_whitelist, 0123456789)把识别范围限定在数字引擎就不会把“1”误识别成“l”把“0”误识别成“O”因为这些容易混淆的字符根本不在候选范围内。黑名单同理通过tessedit_char_blacklist排除掉某些字符。这里要提醒一下白名单只对传统OCR模式生效LSTM模式下可能不起作用。这是引擎本身的限制如果你发现设置了白名单但识别结果还是有其他字符可以把引擎模式改成TesseractOnly试试。4. 扫描PDF识别的完整链路实现4.1 PDF转图片的三个硬性指标处理扫描PDF的核心思路和图片识别一样只不过多了一步“把PDF页面渲染成图片”。这一步做到位了后面OCR就是图片识别的重复劳动。渲染PDF页面时有三个指标直接影响OCR结果分辨率DPI、色彩模式、旋转角度。DPI是最关键的一个。如果你用PDF库默认的72 DPI渲染页面出来的图片会非常模糊OCR肯定识别不好。根据我自己的测试经验扫描文档以300 DPI渲染是性价比最高的选择既能保证文字边缘清晰又不会让图片文件过大。如果原始扫描件本身质量差可以拉到400甚至600 DPI但耗时和内存开销会显著上升。色彩模式上除非PDF页面里存在彩色图表或者需要用颜色区分的版式否则一律用灰度渲染。灰度图比彩色图数据量少三分之二OCR处理速度更快而且少了颜色干扰识别率反而更高。旋转角度是很多人忽略的点。手机扫描件经常带一点倾斜Tesseract默认只能识别小角度的倾斜大概15度以内。如果倾斜超过这个范围文字会变成歪的识别结果会非常差。这种情况下要么先用图像处理算法做旋转校正要么在渲染PDF时就根据页面属性做旋转。PdfiumViewer的Render方法带了Rotate参数可以传入页面预设的旋转角度。4.2 用PdfiumViewer渲染PDF页面C#生态里把PDF渲染成图片我推荐用PdfiumViewer。这个库基于Google的PDFium引擎渲染速度快内存控制也不错而且API设计得很C#化用起来顺手。using PdfiumViewer; using System.Drawing; using System.Drawing.Imaging; string pdfPath D:\scan.pdf; string outputDir D:\pdf_pages; Directory.CreateDirectory(outputDir); using var document PdfDocument.Load(pdfPath); for (int i 0; i document.PageCount; i) { // 300 DPI 渲染当前页 using var image document.Render(i, 300, 300, PdfRenderFlags.CorrectFromDpi); string outputPath Path.Combine(outputDir, $page_{i 1}.png); image.Save(outputPath, ImageFormat.Png); Console.WriteLine($第 {i 1} 页已渲染: {outputPath}); }这里重点解释一下PdfRenderFlags.CorrectFromDpi。如果不加这个标志Pdfium渲染出来的图片尺寸可能不符合预期的DPI会导致图片的分辨率和实际物理尺寸不匹配。加上这个标志后库会按照传入的DPI参数计算实际的像素宽度和高度保证输出图片清晰度达到要求。渲染出来的PNG图片可能比较多为了节省磁盘空间我一般不会保存到磁盘而是直接放在内存里接着OCR。但如果你需要调试或人工复核识别结果保存下来会更方便。4.3 扫描PDF识别逐页渲染加识别的完整代码下面这段代码就是一个完整的“扫描PDF → 提取文字”的解决方案。逻辑很简单加载PDF文档遍历每一页渲染为图片再交给Tesseract识别。using PdfiumViewer; using System.Drawing; using Tesseract; string pdfPath D:\scan_document.pdf; string tessDataPath Path.Combine(AppContext.BaseDirectory, tessdata); using var engine new TesseractEngine(tessDataPath, chi_simeng, EngineMode.Default); engine.SetVariable(preserve_interword_spaces, 1); using var document PdfDocument.Load(pdfPath); for (int i 0; i document.PageCount; i) { using var pageImage document.Render(i, 300, 300, PdfRenderFlags.CorrectFromDpi); using var pix PixConverter.ToPix(pageImage); using var page engine.Process(pix); string pageText page.GetText(); Console.WriteLine($ 第 {i 1} 页 ); Console.WriteLine(pageText); Console.WriteLine(); }这里有个新东西PixConverter.ToPix。PdfiumViewer渲染出来的是System.Drawing.Bitmap而Tesseract需要的是Pix格式。我原本以为还要先把Bitmap保存为图片文件再重新加载后来发现Tesseract封装库自带了PixConverter类可以直接在内存中把Bitmap转成Pix省去了IO开销。这个转换方式不仅代码更简洁性能也更好尤其是处理大量PDF页面时减少磁盘操作的好处非常明显。另外注意到语言包参数我写的是chi_simeng。Tesseract支持同时加载多个语言包进行混排识别中文和英文用加号连接。如果你的文档是纯中文只写chi_sim速度会更快但如果是技术文档、产品说明这类中英混排的就必须用chi_simeng。4.4 内存管理避免大PDF把程序拖垮扫描PDF动辄上百页每页渲染成300 DPI图片后再识别内存会像坐火箭一样往上蹿。我遇到过一次处理一本200多页的扫描书任务跑到一半直接把服务内存吃满最后整个程序崩溃。经验总结下来有几点第一每一页处理完之后图片、Pix、Page这些对象一定要尽快释放。C#的using语句能帮我们自动做这件事但要注意作用域。像上面那段代码我把using放在for循环内部确保每次循环结束本页相关的资源都被回收。第二如果PDF非常大可以考虑使用PdfiumViewer的分页加载特性不要一次性把整个文档读入内存。PdfDocument.Load只加载文档结构页面数据是按需读取的所以渲染的时候内存开销主要集中在当前页这是好现象。第三不要保存所有页面的文本结果到同一个字符串变量里要不然几百页的文字堆在一起内存照样吃紧。正确做法是每识别完一页就把结果写入文件或数据库然后释放变量。4.5 识别结果的坐标信息处理表格与版面分析如果你只是要纯文本上面那些代码已经够了。但很多业务场景需要的是“哪个位置有什么内容”比如自动录入发票信息、提取身份证字段。这时候你就需要用到Tesseract提供的数据接口。using var page engine.Process(pix); using var iterator page.GetIterator(); iterator.Begin(); do { string text iterator.GetText(PageIteratorLevel.Word); if (string.IsNullOrEmpty(text)) continue; // 获取这个词的边界框坐标 if (iterator.TryGetBoundingBox(PageIteratorLevel.Word, out var box)) { Console.WriteLine($文字: {text}, 坐标: ({box.X1}, {box.Y1}) - ({box.X2}, {box.Y2})); } } while (iterator.Next(PageIteratorLevel.Word));这个能力在做信息结构化提取时非常有用。比如你扫描一份表单知道“发票号码”这个标签在页面的左上角那你就可以只关注这个区域的识别结果其他区域直接忽略既提高准确率又减小处理耗时。5. 常见问题与排查技巧实录5.1 识别结果乱码的排查思路乱码是OCR新手遇到最多的问题。我整理了一张速查表基本覆盖了排查路径现象可能原因解决方案输出一堆拉丁字符乱码未安装中文语言包安装Tesseract.Data.Chinese初始化时指定chi_sim中文能识别但夹杂很多无意义字符图片质量差或背景复杂先做灰度化、二值化、提高对比度识别出的英文全是乱的语言包设置错误v用了chi_sim识别英文初始化引擎时使用chi_simeng混排同一张图每次识别结果不一致图片边缘有大量噪点裁剪边缘、去除脏点、统一图片方向大段文字顺序错乱版面分析失败尝试PageSegMode.SparseText或SingleBlock5.2 图片太模糊时的预处理补救方案如果图片本身质量差文字边缘已经模糊成一片任何参数调优都是白费。这时候可以试试放大图片再加锐化。Tesseract对文字的识别高度依赖笔画边缘的清晰度把图片放大2到4倍再做一次锐化有时候效果会好得出奇。我常用的一个方案是用ImageMagick的AdaptiveSharpen算法比普通Sharpen更智能会重点增强边缘区域的对比度。代码很简单using ImageMagick; using var image new MagickImage(D:\blurry.png); image.Resize(new Percentage(200)); // 放大2倍 image.AdaptiveSharpen(); image.Write(D:\blurry_enhanced.png);实测下来对于手机夜间拍摄的文档照片这个方案能把识别率从不到50%提高到80%以上。当然如果是那种压缩到惨不忍睹的微信传图神仙也救不回来建议直接让用户原图重传。5.3 引擎初始化慢、识别速度慢的优化Tesseract引擎初始化时需要加载语言包和模型这个操作比较耗时实测中文语言包初始化大约需要1到2秒。如果你每识别一张图片都new一个TesseractEngine那时间全浪费在初始化上了。正确做法是一个进程全局只创建一个Engine实例用单例模式管理然后并发或者串行处理多张图片。Engine实例是线程安全的复用不会出问题。我自己在超市小票批量识别项目中就是这么干的100张小票复用单例引擎比每次new新引擎快了将近3倍。5.4 中文文本中的空格问题Tesseract识别中文时默认是不输出字间空格的因为中文本来就不需要空格分词。但识别中英混排文档时没有空格会导致英文单词连在一起影响后期处理。解决方式很简单我在前面的代码里已经用到了engine.SetVariable(preserve_interword_spaces, 1);加了这行之后输出结果中英文单词之间会保留空格。这个参数在默认情况下是关闭的但实际项目中我几乎总是开启它因为后处理的时候要按空格分词的情况太多了。5.5 特殊字符和后处理策略OCR的输出很少是完美的总会混入一些全角半角混乱、标点错位、相似字符误识别的问题。所以在OCR之后我一般还会做一层文本后处理把全角逗号、句号统一转半角或者反过来去除多余的空白行过滤掉纯符号的行最后再交给下游。这层后处理看似简单实际对最终交付结果的观感影响巨大。一个只做“识别”的OCR工具和一个人感舒适的“提取方案”差距往往就体现在这里。C#中做这些处理很方便一行正则或者简单的字符串替换就能搞定。6. 多语言的进阶配置与场景扩展6.1 多语言混排场景的配置方式前面提到过用chi_simeng实现中英混排识别。这里再补充两个细节第一语言包的加载顺序会影响识别结果。一般来说把主体语言放在前面辅助语言放在后面比如chi_simeng表示以中文为主、英文为辅。如果你的文档是英文为主、夹杂少量中文就写engchi_sim。第二可以自定义语言包组合。Tesseract允许用多个traineddata文件组合成新的语言通过tesseract命令行工具的combine_tessdata来实现。我经常把“数字大写金额”单独训练成一个语言包专门用于财务单据识别效果比通用中文包好很多。6.2 批量处理长文档的工程化建议如果你要做一个批量扫描文档识别的系统有几个工程化建议值得留意第一任务拆分与进度恢复。处理几百页的PDF时最好把“当前处理到第几页”记录下来程序崩溃后可以从中断处继续而不是从头再来。实现很简单用数据库存一个任务表每页处理完就更新状态。第二异常隔离。某一页图片损坏或者实在太模糊不应该导致整个任务失败。把每页放在try-catch里识别失败就把该页记录下来最后统一生成一个失败清单让人工处理。第三并发控制。Tesseract引擎支持并发处理图像但要注意同时处理的图像数量不要太多否则内存和CPU都会爆掉。我一般用固定线程数方式控制在4到6个并发任务这个值可以根据服务器核数调整。6.3 边缘场景表格、发票、表单的结构化提取OCR的最终目的通常不只是拿一段文字而是为了提取结构化字段。比如识别发票我们真正想要的是发票号码、开票日期、金额、税额这些字段。要做到这一点除了前面讲的坐标信息获取还可以用正则表达式匹配。比如发票号码一般位于页面特定位置配合坐标判断再配合正则校验格式准确率可以做到很高。// 假设text是某一页的OCR结果 string pattern 发票号码[:]\s*([0-9]{8,20}); var match Regex.Match(text, pattern); if (match.Success) { string invoiceNo match.Groups[1].Value; Console.WriteLine($找到发票号码: {invoiceNo}); }这种方法对版式固定的单据效果非常好。如果版式不固定那就需要上目标检测模型来找文本框了复杂度会高一个量级但已经超出本文范畴这里先不展开。我个人在实际项目里的体会是Tesseract这套组合拳能够在80%的常见场景下做到“开箱即用”真正决定一个OCR项目能否落地的往往不是引擎本身而是你对图像预处理、参数调优和后处理这层“外围功夫”的打磨。遇到识别率不高时先别急着换引擎把图片放大、转灰度、调对比度、设置合理的分段模式往往比换一个重型模型更有效。最后再分享一个小技巧处理一批来自同一扫描设备的文档时先拿几张样张调试出一套固定的预处理参数后面整批套用既稳又快。