简介：面向C#开发者的OCR通用识别Demo，基于PaddleOCR模型封装，解决在.NET环境下快速接入图像文字识别能力的问题，可应用于截图取词、合同票据识别、PDF文档文字提取等场景。项目整合图形处理库Clipper、Emgu.CV完成图像预处理，借助Microsoft.ML.OnnxRuntime高性能推理引擎加载模型，支持照片识别、屏幕截图识别及PDF文件识别三种典型输入方式，适合有WinForm或WPF基础、希望离线集成OCR功能的开发者。压缩包约41.06MB，为一个RAR压缩包，其中主要包含可直接运行的C#工程源码、依赖的本地库文件以及使用说明文档，方便在Visual Studio中打开并对照学习。目前已有305人浏览学习，资源附带详细的博文项目解析，可帮助读者理解PaddleOCR模型在C#中的调用流程、图像解码与推理参数设置等关键环节，并避开常见踩坑点。 做上位机开发的朋友，大概率遇到过这种需求：客户拿来一堆图片，说“帮我把上面的单号、名称、金额提出来，存到表格里”；或者设备产线上有个屏幕读数，不方便人工盯，想让它自动识别文字进系统。这种“从图像里提取文字”的需求，就是OCR（Optical Character Recognition，光学字符识别）。
我之前在C#桌面项目里做过一个OCR通用识别Demo，目标是做一个能直接在WinForms里用的最小可用版本：拖一张图进去，点一下识别，把文字和置信度列出来。文章不堆概念，只讲实操，把引擎选型、图片预处理、调用方式、问题排查全部过一遍。适合正在做C#上位机、桌面工具，或者想在业务流程里塞一个“看图识字”功能的开发者参考。
1. 项目整体思路与选型权衡
1.1 这个Demo到底要解决什么问题
市面上OCR引擎很多，但C#开发者真正上手时，常卡在三件事上：
- 引擎怎么选：网上资料杂，有开源的、有收费的、有系统自带的，不知道该用哪个。
- 调起来麻不麻烦：有些引擎是Python生态的，C#要套一层RPC、HTTP或进程管道，图省事的话一个Demo还要配一堆依赖。
- 识别质量谁来保证：同一个引擎，给不同图片效果差很多，图片不清晰、背景复杂、文字歪斜，识别率直接崩。
所以这个Demo不追求“把所有图片都识得完美”，而是解决“用最少代价，跑通一条可用链路”的问题。目标场景包括：截图里的文字提取、扫描件单号识别、设备铭牌拍照识别。这些都是C#桌面开发里最常见的OCR需求。
我最终选型的方案组合是：WinForms + .NET 6/8 + 本地OCR引擎，整个Demo不依赖外部网络服务，离线可用，代码结构上把“界面”和“识别服务”拆开，方便后续替换引擎或集成到上位机里。
1.2 四种主流OCR引擎怎么选
C#项目里可选的OCR方案，我梳理了一下，大致四类：
| 方案 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| Windows.Media.Ocr（系统自带） | 无需额外文件，Win10/11自带，中英文可用 | 识别精度一般，语言模型不可控，样式自由度低 | 快速原型、内部工具 |
| Tesseract 5（开源） | 免费、离线、支持多语言，社区活跃 | 原生C++生态，需要C#封装库；对复杂背景图片敏感 | 大多数桌面工具，推荐 |
| PaddleOCR（百度飞桨） | 中文识别精度高，支持版面分析，模型丰富 | 模型文件大，C#需通过PaddleOCRSharp等封装调用，部署麻烦 | 中文文档、表格、复杂版面 |
| 商业云OCR（百度/腾讯/讯飞等） | 精度最高，支持各种场景 | 收费、依赖网络、有数据安全顾虑 | 生产环境、非敏感数据 |
我的建议是：如果你只是做一个“通用识别Demo”，先选Tesseract 5，理由很实际——免费、离线、模型文件可控、改造成本低。如果你后续明确要识别中文表格、发票、手写体这类复杂内容，再升级PaddleOCR。
1.3 Demo项目的分层设计
一个好的Demo不是代码堆在一起能跑就行，而是要留出“以后好改”的余地。我按三层来组织：
- 界面层（WinForms）：负责选择图片、展示结果、显示耗时和置信度。
- 服务层（OcrService）：封装具体识别引擎，对外只暴露
Image -> List<OcrResult>的方法。 - 图像处理层（ImageProcessor）：负责缩放、灰度化、二值化、降噪等预处理。
这样做的好处是：界面层完全不关心底层是Tesseract还是Windows.Media.Ocr，哪天要换引擎，只要改服务层里的实现类，界面不用动。对做上位机的朋友来说，这种结构也让OCR模块可以独立复用，不至于每次都得从界面上抠代码。
2. 核心功能实现
2.1 WinForms界面布局
界面不需要花哨，一个可拖拽图片的Panel、两个按钮（选图、识别）、一个显示结果的DataGridView、一个显示图片的PictureBox就够了。
布局上有一个关键细节：PictureBox的SizeMode要设为Zoom，否则大图会把界面撑爆，而且用户看不出图片被缩放过。界面底部加一个Label，用来显示单次识别耗时和识别出的文字条数，这对调优非常有用。
代码上，界面逻辑很直白：点击“选择图片”时调用OpenFileDialog，支持png/jpg/bmp格式；选完后显示图片，并调用OcrService进行识别，结果绑定到DataGridView，显示识别文本和置信度。
2.2 把识别逻辑封装成独立服务
不管用哪种引擎，服务层对外最好只暴露一个方法。比如：
public class OcrResult { public string Text { get; set; } public float Confidence { get; set; } public Rectangle BoundingBox { get; set; } } public interface IOcrService { Task<List<OcrResult>> RecognizeAsync(byte[] imageData, CancellationToken ct = default); }接口接收byte[]而不是Bitmap，主要是为了解耦——客户端可能从文件读、从摄像头截帧、从网络下载，统一转成字节数组最省事。返回的OcrResult里带上Confidence（置信度）和BoundingBox（文字区域），方便后续做区域筛选或人工校验。
2.3 调用Windows.Media.Ocr实现第一版
如果你只是想在项目里快速看到效果，Windows自带的OCR是个不错的起点，不需要安装任何东西：
using Windows.Media.Ocr; using Windows.Graphics.Imaging; using Windows.Storage.Streams; public async Task<string> RecognizeWithSystemOcr(byte[] imageData) { var stream = new InMemoryRandomAccessStream(); await stream.WriteAsync(imageData.AsBuffer()); stream.Seek(0); var decoder = await BitmapDecoder.CreateAsync(stream); var softwareBitmap = await decoder.GetSoftwareBitmapAsync(); var language = new Windows.Globalization.Language("zh-CN"); var ocrEngine = OcrEngine.TryCreateFromLanguage(language); if (ocrEngine == null) return "不支持当前语言"; var result = await ocrEngine.RecognizeAsync(softwareBitmap); return result.Text; }注意两个坑：第一，OcrEngine对象的并发能力有限，建议每次识别都重新创建或者用锁保护；第二，Win10/11系统自带的OCR语言包是和系统语言绑定的，有些精简版系统可能识别不了中文，需要先确认。这版精度也就是“能看”，复杂图片基本别指望。
2.4 切换到Tesseract 5 + 中文语言包
真正拿来当Demo核心，我推荐换Tesseract。NuGet包里有两个常用封装：Tesseract（经典包，基于Tesseract 4.x）和TesseractOCR（新版，基于Tesseract 5.x）。我建议用TesseractOCR，API更现代，而且兼容.NET Standard 2.0，WinForms和ASP.NET Core都能用。
安装NuGet包：
Install-Package TesseractOCR使用起来也很简单：
using TesseractOCR; using TesseractOCR.Enums; public class TesseractOcrService : IOcrService { private readonly Engine _engine; public TesseractOcrService() { var path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "tessdata"); _engine = new Engine(path, Language.ChineseSimplified, EngineMode.LstmOnly); } public Task<List<OcrResult>> RecognizeAsync(byte[] imageData, CancellationToken ct = default) { var results = new List<OcrResult>(); using var img = Pix.LoadFromMemory(imageData); using var page = _engine.Process(img, PageSegMode.Auto); using var iterator = page.GetIterator(); iterator.Begin(); do { if (iterator.TryGetBoundingBox(out var box) && iterator.TryGetConfidence(out var conf)) { var text = iterator.GetText(); if (!string.IsNullOrWhiteSpace(text)) { results.Add(new OcrResult { Text = text.Trim(), Confidence = conf, BoundingBox = new Rectangle(box.X1, box.Y1, box.X2 - box.X1, box.Y2 - box.Y1) }); } } } while (iterator.Next(PageIteratorLevel.TextLine)); return Task.FromResult(results); } }这里必须提一个最容易被新手忽略的点：tessdata语言包的位置。Language.ChineseSimplified对应的chi_sim.traineddata文件必须放在运行目录下的tessdata文件夹里，否则引擎初始化直接抛异常。下载地址在Tesseract官方GitHub的tessdata_fast仓库，大概2MB左右，放进去就能用。这个文件在项目里要设置成“复制到输出目录”，否则发布后换个机器就找不到了。
3. 图像预处理与识别率优化
3.1 图像缩放：为什么必须先缩再识别
识别率和图片清晰度不是简单的“越大越清楚”正相关。Tesseract内部会把输入图缩放到一个合适的尺度处理，图片过大反而会导致识别慢、内存占用高，甚至把文字的边缘毛刺也当成特征。我在实际测试中发现，一张4000x3000的合同扫描件直接识别，耗能接近3秒，而且把缩放为2000px再识别，速度提升一半以上，识别率没有明显下降。
所以预处理第一步是等比缩放：宽或高超过2000px时，统一把最长边缩到2000px左右。这个值不是拍脑袋定的，是我在多个图测下来相对平衡的临界点，文字太小的截图反而需要把局部放大后再识别。
public static Bitmap ScaleToMaxEdge(Bitmap source, int maxEdge = 2000) { if (source.Width <= maxEdge && source.Height <= maxEdge) return (Bitmap)source.Clone(); var ratio = (double)maxEdge / Math.Max(source.Width, source.Height); var newWidth = (int)(source.Width * ratio); var newHeight = (int)(source.Height * ratio); var target = new Bitmap(newWidth, newHeight); using var g = Graphics.FromImage(target); g.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic; g.DrawImage(source, 0, 0, newWidth, newHeight); return target; }3.2 灰度化、二值化与降噪
Tesseract对彩色图也能识别，但对灰度图和二值图最友好。彩色图像里的颜色信息对文字识别几乎没有帮助，反而会让背景中的杂色干扰边缘提取。灰度化之后，再用二值化把“文字”和“背景”彻底分开，识别率能明显提升。
我在Demo里写了几个预处理步骤，按顺序执行：
- 灰度化：将RGB三通道转为单通道灰度值。
- 二值化：用Otsu算法自动计算阈值，大于阈值的记为白（背景），小于阈值的记为黑（文字）。
- 去除噪点：用中值滤波去掉细小杂点，但要注意滤波核不能太大，否则会破坏笔画细节。
这里给出一段灰度化+Otsu二值化的核心代码，Otsu计算的逻辑是寻找一个灰度级，使得前景与背景两类之间的方差最大：
public static Bitmap ToBinary(Bitmap source) { int width = source.Width; int height = source.Height; var gray = new Bitmap(width, height, System.Drawing.Imaging.PixelFormat.Format8bppIndexed); var palette = gray.Palette; for (int i = 0; i < 256; i++) palette.Entries[i] = Color.FromArgb(i, i, i); gray.Palette = palette; var rect = new Rectangle(0, 0, width, height); var bmpData = gray.LockBits(rect, System.Drawing.Imaging.ImageLockMode.WriteOnly, System.Drawing.Imaging.PixelFormat.Format8bppIndexed); var sourceData = source.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadOnly, System.Drawing.Imaging.PixelFormat.Format24bppRgb); unsafe { byte* src = (byte*)sourceData.Scan0; byte* dst = (byte*)bmpData.Scan0; int[] histogram = new int[256]; for (int y = 0; y < height; y++) { byte* srcRow = src + y * sourceData.Stride; byte* dstRow = dst + y * bmpData.Stride; for (int x = 0; x < width; x++) { byte grayVal = (byte)((srcRow[x * 3] + srcRow[x * 3 + 1] + srcRow[x * 3 + 2]) / 3); dstRow[x] = grayVal; histogram[grayVal]++; } } int total = width * height; float sum = 0; for (int i = 0; i < 256; i++) sum += i * histogram[i]; float sumB = 0; int weightB = 0; float maxVariance = 0; int threshold = 127; for (int i = 0; i < 256; i++) { weightB += histogram[i]; if (weightB == 0) continue; int weightF = total - weightB; if (weightF == 0) break; sumB += i * histogram[i]; float meanB = sumB / weightB; float meanF = (sum - sumB) / weightF; float between = (float)weightB * weightF * (meanB - meanF) * (meanB - meanF); if (between > maxVariance) { maxVariance = between; threshold = i; } } for (int y = 0; y < height; y++) { byte* dstRow = dst + y * bmpData.Stride; for (int x = 0; x < width; x++) { dstRow[x] = dstRow[x] < threshold ? (byte)0 : (byte)255; } } } source.UnlockBits(sourceData); gray.UnlockBits(bmpData); return gray; }注意，二值化不是对所有图片都有正面效果。如果图片本身是清晰的黑底白字截图，二值化效果很好；但如果图片有渐变背景、反光、阴影，强制二值化反而会损失信息。我的处理方式是：默认做灰度化，二值化加一个开关，在界面上显示预览，用户可以自行切换。这个“在界面上暴露预处理开关”的设计，在实际排查识别率问题时非常有帮助。
3.3 PageSegMode的合理选择
Tesseract的PageSegMode参数很关键，直接影响识别效果。默认Auto会在整页里自动找段落和文字块，但如果你的图片是单行数字或一行标题，用Auto反而会误切分。
常用的几个模式：
| 模式 | 值 | 适用场景 |
|---|---|---|
| Auto | PSM_AUTO_OSD（默认） | 混合排版的文档、杂志、扫描件 |
| SingleBlock | PSM_SINGLE_BLOCK | 单块文字，如一段菜单、一段说明 |
| SingleLine | PSM_SINGLE_LINE | 单行文字，如设备编号、车牌 |
| SingleWord | PSM_SINGLE_WORD | 单个词、单个验证码 |
| SparseText | PSM_SPARSE_TEXT | 文字分布零散，没有固定版式 |
我的经验是：宁可先判断图片内容，再指定模式，也不要一直用Auto。比如识别截图里的单行订单号时，用SingleLine模式比Auto的准确率高出一大截，因为引擎不会再花精力去猜版面结构。我的Demo里把模式做成了下拉框，用户可以根据图片类型切换，同时记住上次选择，下次启动自动带出来。
4. 性能优化与多线程
4.1 异步识别，别让界面卡死
OCR识别是CPU密集型操作，识别一张大图可能要几百毫秒到几秒。如果在UI线程里直接调用，界面会假死，用户体验极差。WinForms里的正规做法是用async/await，把耗时操作放到线程池里。
我在Demo里做了两个保障：
IOcrService.RecognizeAsync的方法签名天然支持异步调用，界面层只要await结果即可。- Tesseract的
Engine实例不是线程安全的，多线程并发识别同一实例会崩溃。所以我在服务层加了一个SemaphoreSlim，限制同一时间只有一个识别任务在执行。
private readonly SemaphoreSlim _gate = new SemaphoreSlim(1, 1); public async Task<List<OcrResult>> RecognizeAsync(byte[] imageData, CancellationToken ct = default) { await _gate.WaitAsync(ct); try { return await Task.Run(() => RecognizeInternal(imageData), ct); } finally { _gate.Release(); } }这里有个细节：Engine虽然不能并发，但可以重复使用多次，所以建议把Engine实例缓存成单例，不要每次识别都new一个，否则每次都要加载语言模型，耗时极高。我实测过，Tesseract初始化引擎加载模型大概需要200~500ms，多次调用时这个开销累积起来很可观。
4.2 批量识别时的资源控制
如果你把Demo扩展成“批量识别一个文件夹里的所有图片”，那就要注意资源释放问题。Pix.LoadFromMemory、Engine.Process、Bitmap这些对象都实现了IDisposable，必须在using块里释放，否则内存会一路上涨，最终OOM。
此外，批量识别不建议无限并行。就算你的机器是8核16线程，OCR也不是纯并行友好的任务，因为每个进程内部有资源锁。我测试过，并发数设为CPU核心数时吞吐量接近最大，继续加并发数反而会因为线程切换和内存带宽瓶颈导致性能下降。控制并发数可以直接让Task.WhenAll配合SemaphoreSlim，每个批次最多跑N个任务。
5. 常见问题与排查
5.1 识别结果全空，是什么原因
这类问题九成出在图像预处理或语言包上。先看预处理：如果二值化阈值选得太偏，白色文字被滤掉，结果全空。再看语言包：用了英文语言包去识别中文，结果自然为空。建议第一次跑的时候，把预处理后的图像保存到本地看看，确认文字区域是否还清晰可见。
我在Demo里加了一个“保存预处理图”的功能按钮，排查问题时特别好用——你一眼就能看到Tesseract到底拿到的是什么图像，是清楚还是糊了，是黑底白字还是白底黑字。如果预处理图都看不清文字，那识别空是正常的，问题在图像采集，不在OCR引擎。
5.2 中文乱码或识别出方块字
中文乱码通常是语言包不匹配，或者语言包版本太旧。tessdata_fast仓库里的chi_sim.traineddata是Tesseract 4.0+专用格式，不要从一些老旧网站下载乱七八糟的“中文包”。另外，如果安装了多个tessdata目录，程序可能会加载到错误路径。最简单的验证方式：初始化引擎后打印Engine.Version，并确认tessdata目录下确实存在chi_sim.traineddata。
还有一种情况是字体本身的问题。艺术字、手写体、带有连笔的草书，Tesseract确实识别不了，这属于引擎能力边界，不是代码逻辑问题。这时候要么换PaddleOCR，要么对图片做针对性处理。
5.3 内存和耗时异常
大图直接进Tesseract是最常见的耗时元凶。我见过有同事拿6000x8000的扫描件直接识别，跑了十几秒，内存涨到1GB以上。你如果在生产环境遇到类似情况，先检查图像有没有经过缩放。另外，Tesseract的LSTM引擎对每个文字块都会做一次推理，如果页面布局很碎，识别开销会显著上升，合并相近的文字块、减少噪点，都能明显改善耗时。
5.4 发布和安装包注意点
WinForms项目发布时，最容易漏掉的就是语言包和原生DLL。TesseractOCR封装包会带一个原生tesseract的依赖文件，确保它被复制到了输出目录。tessdata目录层级不能错，必须是运行目录/tessdata/chi_sim.traineddata。我用Inno Setup打包安装包时，会把tessdata整个目录、运行目录下所有dll和exe一起打进去，安装后测试直接从Program Files目录跑一遍识别，确认没有路径问题。
5.5 从图片区域定向识别
最后分享一个实用扩展：很多时候我们不需要识别整张图，只要识别某个固定区域。比如上位机里摄像头拍到的仪表盘，表盘读数区域是固定的。这时可以加一个“识别区域”参数，先裁剪出指定矩形区域，再做预处理和识别。这样既提升了识别速度，又避免了周围杂讯干扰。在我的Demo里，这个功能是通过在PictureBox上拖拽画框实现的，后边接一个CropImage(bitmap, rect)就完事了。
根据个人经验，OCR的识别率大概七分靠预处理，二分靠引擎选型，一分靠参数调优。拿到一张图片，先看看它适不适合直接丢给引擎，多花几秒钟做缩放、灰度、二值化，比换什么高级引擎都管用。这次的Demo代码结构比较保守，没有引入复杂的DI框架，就是为了让C#桌面开发者能直接看懂、改得动。后续如果你想进一步集成到上位机里，还可以把IOcrService替换成PaddleOCR的调用端，或者接一个云OCR接口，界面层完全不用动。
本文还有配套的精品资源，点击获取
