简介：这是基于PaddleOCR的C#本地离线OCR解决方案，面向需要在Windows桌面应用中识别图片文字、且不希望依赖云端服务的开发者。程序实现了鼠标点击定位取词，可对图片进行缩放，并能通过输入编号获取指定位置文字，适用于截图翻译、文档数字化、卡片信息提取等本地处理场景。OCR模型权重已完整打包，离线启动后即可识别，无需额外下载模型或配置云端接口，识别过程完全在本地完成，更利于数据隐私保护。压缩包共181个文件、约273.37MB，其间包含61个dll依赖库、9个cs源码、9组pdmodel与pdiparams模型文件、项目工程文件（sln、csproj）、配置与说明文档等，目录结构清晰，模型、运行库和源码分层存放，便于直接打开调试或二次开发。目前已有956人学习下载，适合希望快速掌握PaddleOCR集成方法的C#开发者，拿到手即可在Visual Studio中编译运行，并基于示例扩展自定义OCR功能。 用C#做一套本地离线的OCR识别工具，这个需求最近找我咨询的人特别多。大家普遍受够了在线OCR的隐私泄露风险、按次计费的成本，还有网络波动时服务直接不可用的尴尬。这个项目方案一句话说清楚就是：用PaddleOCR开源模型，配合C#封装，做一套完全本地化的图片文字提取程序，不需要联网，不需要外部API，装完就能跑。
这套方案适合谁？适合要做桌面工具、上位机系统、内部办公系统的C#开发人员，尤其是有中文识别需求，对数据敏感不想把图片传到云端，又希望识别精度能打的场景。模型效果对标百度云OCR的中文识别能力，但没有流量费用和并发限制。
1. 项目整体设计思路
1.1 为什么选PaddleOCR而不是Tesseract
做离线OCR，第一反应基本都是Tesseract。我早年也用Tesseract做过几个项目，但体验并不算好。Tesseract对印刷体中英文的表现尚可，一旦遇到中文、手写、倾斜文本、复杂背景，准确率会明显下降。Tesseract 5的中文模型虽然比4好了不少，但和PaddleOCR的差距依然明显。
PaddleOCR是百度开源的OCR工具库，目前已经到PP-OCRv4版本。它在中文场景的识别能力，尤其是通用场景文本检测、方向分类、文本识别三个模块的配合，几乎接近商用云OCR的水平。而且模型体积可控，推理速度也快，纯CPU跑也能在几百毫秒内完成一张普通图片的识别，这在桌面场景完全够用。
1.2 C#接入PaddleOCR的三条路线
C#开发者要使用PaddleOCR，市面上有三条路线，我列出各自的优劣势：
| 方案 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| PaddleSharp | 通过Native绑定直接调用PaddleOCR的C++推理库 | 纯C#集成、内存共享、性能最好 | 需要正确匹配版本、一些坑需要排查 |
| 子进程调用Python | C#进程启动Python脚本执行OCR | 实现简单、Python代码好改 | 每次启动Python进程开销大、部署要装Python环境 |
| ONNX Runtime | 将Paddle模型导出为ONNX，用C#调用ONNX Runtime推理 | 跨平台、无Python依赖 | 模型转换繁琐、部分算子支持不完整 |
我倾向于PaddleSharp，这是目前生产环境里最成熟的C#绑定方案。核心思路就是通过PaddleSharp库封装PaddleOCR的推理模型，在C#里直接操作图像和结果，部署时只需要带上模型文件和相关DLL，不需要客户端安装Python。后续维护也简单，识别逻辑全部在C#里搞定，跟原有的WinForm、WPF程序无缝集成。
1.3 项目最终要解决的核心问题
这套程序需要做到三件事：加载本地模型、读取本地图片、输出识别文字。数据完全在本地流转，不经过任何网络请求。核心模块可以抽象成四层：界面层负责用户交互、图像处理层负责图片格式转换和预处理、推理层负责调用PaddleOCR模型、结果层负责解析和格式化输出。WinForm项目天然适合这个结构，做上位机的同学一眼就能接得住。
2. 环境准备与NuGet包说明
2.1 最小依赖清单
PaddleSharp在NuGet上以几个包的形式发布：Sdcb.PaddleOCR、Sdcb.PaddleInference和对应的Runtime包。需要注意，运行时包分CPU和GPU两个方向，必须根据目标机器选对应版本。
| NuGet包名 | 用途 | 备注 |
|---|---|---|
| Sdcb.PaddleOCR | PaddleOCR推理的C#封装 | 核心库 |
| Sdcb.PaddleInference | Paddle推理引擎的C#互操作层 | 一般无需直接引用 |
| Sdcb.PaddleInference.runtime.win64.mkldnn | Windows x64 CPU推理运行时 | CPU版选这个 |
| Sdcb.PaddleInference.runtime.win64.gpu | Windows x64 GPU推理运行时 | GPU版选这个，体积大很多 |
安装命令直接通过NuGet包管理器操作。CPU版运行时体积大概一百多MB，GPU版带了CUDA和cuDNN依赖，几个G都正常。如果是给客户部署，建议CPU版优先，省去在客户机器上装显卡驱动的麻烦。
2.2 模型文件下载与目录结构
模型文件需要从PaddleOCR官方仓库下载。最少需要三个模型：文本检测模型、方向分类模型、文本识别模型。中文场景还需要下载中文识别模型。
下载完解压后，目录结构建议这样放：
models/ ├── det/ │ ├── inference.pdiparams │ ├── inference.pdiparams.info │ └── inference.pdmodel ├── cls/ │ ├── inference.pdiparams │ ├── inference.pdiparams.info │ └── inference.pdmodel └── rec/ ├── inference.pdiparams ├── inference.pdiparams.info ├── inference.pdmodel └── dict.txt代码里加载模型时，路径指向这三个文件夹即可。我不建议把模型文件硬编码到系统盘根目录，因为不同的Windows环境权限策略不一样，放程序同级的models目录下最稳妥，还能做到绿色拷贝部署。
2.3 CPU版还是GPU版
PaddleOCR官方宣称GPU模式需要CUDA和cuDNN配合，网上的热词“cudnn 8.5”说的就是GPU推理环境的版本匹配。如果你的开发机器没有NVIDIA显卡，或者客户现场都是普通办公电脑，直接走CPU版。实测下来，常规的A4发票截图、手机拍的书页照片，CPU推理时间大约300-800ms，体感上不慢。
如果有NVIDIA显卡，可以切GPU版，速度能提升几倍。但GPU版在部署时有个硬门槛：目标机器必须安装对应版本的CUDA和cuDNN，不同Paddle版本对CUDA版本要求还不一样，弄不好就是启动时报DLL找不到。所以我认为除非场景对性能要求极高，否则CPU版已经够用，后面我会单独讲GPU配置的坑。
3. 核心代码实现与关键步骤
3.1 搭建OCR引擎
PaddleSharp的核心用法很简洁，所有PaddleOCR能力都通过PaddleOcrAll类来调用。初始化时需要传入检测、分类、识别三个模型各自的路径，以及识别用的字典文件。
using Sdcb.PaddleInference; using Sdcb.PaddleOCR; using Sdcb.PaddleOCR.Models; using Sdcb.PaddleOCR.Models.Local; public class OcrService : IDisposable { private PaddleOcrAll _ocrEngine; public void Init(string modelRootDir) { string detDir = Path.Combine(modelRootDir, "det"); string clsDir = Path.Combine(modelRootDir, "cls"); string recDir = Path.Combine(modelRootDir, "rec"); string dictPath = Path.Combine(recDir, "dict.txt"); var detModel = LocalDetectionModel.FromDirectory(detDir); var clsModel = LocalClassificationModel.FromDirectory(clsDir); var recModel = LocalRecognitionModel.FromDirectory(recDir, dictPath); var config = new PaddleOcrOptions { AllowMemoryOptimizer = true, EnableMKLDNN = true, GpuDeviceId = -1 // -1表示CPU模式，0以上为GPU设备 }; _ocrEngine = new PaddleOcrAll(detModel, clsModel, recModel, config); } public string Recognize(byte[] imageBytes) { using var bitmap = new Bitmap(new MemoryStream(imageBytes)); using var result = _ocrEngine.Run(bitmap); return result.Text; } public void Dispose() { _ocrEngine?.Dispose(); } }这段代码里几个要点：
LocalDetectionModel.FromDirectory方法会读取目录下的inference.pdmodel和inference.pdiparams，命名如果不对就会加载失败。下载模型后我建议先看一眼文件结构，确认为inference.pdmodel而不是model.pdmodel再往下走。GpuDeviceId设置为-1就是纯CPU推理，配合EnableMKLDNN = true，在Intel CPU上能利用MKL-DNN加速，速度有明显提升。PaddleOcrAll对象是线程不安全的，多线程场景下需要加锁，或每个线程创建独立实例。
3.2 图像预处理：灰度化、缩放与二值化
PaddleOCR内部有自己的预处理流程，但我们在调用前如果能做适当的图像增强，对识别率提升帮助很大。尤其是手机拍照、屏幕截图这类场景，清晰度和对比度直接决定识别效果。
我常用的预处理策略是：先转灰度图，再做自适应二值化，接着根据图片宽度等比例缩放，控制在一个合适的尺寸范围内。PaddleSharp的PaddleOcrAll.Run重载支持传入Mat类型，配合OpenCvSharp可以一条龙处理。
using OpenCvSharp; public string RecognizeWithPreprocess(string imagePath) { using var src = new Mat(imagePath, ImreadModes.Color); // 图片过大时等比例缩小，过小的图放大，控制在2000px附近 double maxSide = Math.Max(src.Width, src.Height); if (maxSide > 2000) { double scale = 2000.0 / maxSide; var resized = new Mat(); Cv2.Resize(src, resized, new Size((int)(src.Width * scale), (int)(src.Height * scale))); src.Dispose(); src = resized; } using var gray = new Mat(); Cv2.CvtColor(src, gray, ColorConversionCodes.BGR2GRAY); using var binary = new Mat(); Cv2.AdaptiveThreshold(gray, binary, 255, AdaptiveThresholdTypes.GaussianC, ThresholdTypes.Binary, 15, 10); using var result = _ocrEngine.Run(binary); return result.Text; }调试图像预处理参数时，我习惯把处理后的中间结果保存下来看一眼。如果OCR结果不好，先看二值化图像上文字是否清晰、是否断笔，这是最快定位问题的方式。
3.3 结果解析：识别区域与置信度
PaddleOcrResult不只是返回一段文字，它还包含了每个文本区域的坐标、方向和置信度。这个信息在做票据识别、翻拍件提取结构化字段时极其有用。举个例子，如果只想提取一张发票上的“发票号码”这一栏，可以通过坐标范围过滤结果，而不是把整张图的所有文字都返回。
using var result = _ocrEngine.Run(image); foreach (var region in result.Regions) { float score = region.Score; // 置信度，0~1 string text = region.Text; // 该区域的文字 var points = region.PolygonPoints; // 文本区域的四点坐标 Console.WriteLine($"[{score:P0}] {text}"); // 坐标过滤示例：只取图片右上角区域的文字 if (points[0].X > image.Width / 2 && points[0].Y < image.Height / 2) { // 命中右上角区域，做后续处理 } }result.Text是一个便捷属性，内部其实就是把所有区域的文本按行拼起来。如果只需要文字内容，用它足够；要做结构化解析，就用Regions自己去过滤。
3.4 WinForm界面集成
把它封装成WinForm程序非常简单。界面上三个核心控件：一个显示图片的PictureBox、一个触发识别的按钮、一个显示结果的TextBox。考虑到识别时间可能在几百毫秒到几秒不等，建议用async/await封装调用，避免界面卡死。
private async void btnRecognize_Click(object sender, EventArgs e) { using var openDlg = new OpenFileDialog(); openDlg.Filter = "图片文件|*.png;*.jpg;*.jpeg;*.bmp;*.tiff"; if (openDlg.ShowDialog() != DialogResult.OK) return; btnRecognize.Enabled = false; try { var text = await Task.Run(() => _ocrService.Recognize(openDlg.FileName)); txtResult.Text = text; } catch (Exception ex) { MessageBox.Show($"识别失败: {ex.Message}", "错误", MessageBoxButtons.OK, MessageBoxIcon.Error); } finally { btnRecognize.Enabled = true; } }Task.Run在这里是让OCR推理在后台线程执行，避免阻塞UI线程。严格地说，PaddleSharp的调用内部是C++推理，在任务线程池里跑没问题。但要留意一点，PaddleOcrAll实例创建后建议常驻，不要每次识别都new一个，因为模型加载耗时几秒级，只会拖慢程序。
4. 常见问题与排查技巧实录
4.1 模型加载报错 "Cannot open file inference.pdmodel"
这个错误在我收到的反馈中出现频率最高，结合热词里“源程序经编译后，但尚未链接的文件”这类说法，很多朋友以为是编译问题，实际是模型目录结构不对造成的。
排查思路：
- 检查模型目录下是否同时存在
inference.pdmodel和inference.pdiparams，这两个文件缺一不可 - 检查路径是否传到了正确的父目录。
FromDirectory期望传入的是包含这两个文件的目录，不要把路径多包一层 - 确认文件没有损坏，重新解压一次
4.2 运行时报缺少onnxruntime.dll或paddle_inference.dll
PaddleSharp依赖一些原生DLL，这些DLL由NuGet运行时包提供。如果项目引用不完整，或者部署时没有把runtimes目录一起拷走，就会出现DLL找不到。
解决方案是确保安装的运行时包和你项目的目标平台一致。项目生成属性里，Platform Target必须设置为x64。如果你代码是64位编译，但NuGet包引用了AnyCPU或x86，大概率加载失败。
一个最稳妥的做法：在程序入口处强制设置当前目录到依赖DLL所在位置。
[STAThread] static void Main() { // 将运行目录切换到exe所在目录，避免相对路径找不到模型和DLL Environment.CurrentDirectory = AppDomain.CurrentDomain.BaseDirectory; Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); }4.3 GPU模式下运行报cudnn相关错误
网上搜到“paddleocr 如何用gpu模式 cudnn 8.5”这类话题，一般就是GPU环境没配对。PaddleSharp的GPU版本对CUDA、cuDNN的版本要求比较严格，比如某些版本要求CUDA 11.7 + cuDNN 8.4或8.5，配上之后还要把cudnn64_8.dll挂在PATH里。
我的建议很简单直接：如果公司没有统一的GPU部署环境，别碰GPU版。CPU版配合MKL-DNN在绝大多数办公场景已经够用，省下来的时间不如去优化图像预处理。实在要上GPU，先在NVIDIA官网上确认目标机器的显卡、驱动版本、CUDA版本，三者匹配再动手。
4.4 识别的文字夹杂大量乱码或重复字符
这个问题的根源通常是识别模型和字典文件不匹配。PaddleOCR的中文识别模型对应一份dict.txt，里面按顺序列出了模型认识的所有字符。如果你用的是精简版字典，但模型是全量模型，识别结果就会产生错乱。
解决办法是重新从官方下载与模型配套的字典文件，并确认传入LocalRecognitionModel.FromDirectory的字典路径正确。
4.5 截图或低分辨率图片识别效果差
手机拍的书页、系统截图这类图，像素不透明，文字边缘有锯齿。我在文章前面提到的预处理流程能解决大部分问题。再加一条：如果是白底黑字的文档截图，把图像反色后再交给OCR，有时反而能拿到更好的结果，因为PaddleOCR对深色背景浅色文字的建模方式和白底黑字不同。
using var inverted = new Mat(); Cv2.BitwiseNot(gray, inverted); // 再把inverted传给OCR引擎5. 部署与后续扩展
5.1 制作WinForm安装包
热词里有人搜“c#的winform如何制作安装包”，这里直接给结论：用Visual Studio自带的Microsoft Visual Studio Installer Projects扩展即可。新建Setup项目，把主程序的输出和模型目录加进去，生成msi安装包。装完在客户机器上，只要目标机器是64位Windows 10/11，装了.NET Framework 4.7.2以上，基本就能跑。
一个部署时的细节：模型文件比较大，几百MB级别的模型如果一起塞进msi，安装会很慢。建议安装包只装主程序，首次运行时引导用户选择模型目录，或者复制模型到指定路径。这样做还有个好处是模型可以独立更新，不用整体重装程序。
5.2 识别结果导出
实际项目中很少有人只需要把文字显示在界面上。把结果导出成txt、csv、json是刚需。导出时要考虑编码问题，Windows下写文件建议用UTF-8带BOM，否则Excel直接打开csv会乱码。
private void ExportToCsv(List<RegionResult> regions, string savePath) { var sb = new StringBuilder(); sb.AppendLine("识别文字,置信度,左上角X,左上角Y"); foreach (var region in regions) { var p = region.PolygonPoints[0]; sb.AppendLine($"\"{region.Text}\",{region.Score:F2},{p.X:F0},{p.Y:F0}"); } File.WriteAllText(savePath, sb.ToString(), new UTF8Encoding(true)); // 带BOM }5.3 批量识别文件夹
批量识别是另一个高频率需求。实现思路就是遍历文件夹下所有图片文件，逐个调用OCR引擎识别，把结果聚合输出。这里有个小技巧：识别几张图之后，PaddleOCR内部的一些缓存会逐渐预热，后续单张耗时会更稳定。批量场景下可以在进度条里展示处理进度，避免用户误以为程序卡死。
public async Task BatchRecognizeAsync(string inputDir, string outputDir, IProgress<int> progress) { var files = Directory.GetFiles(inputDir, "*.png") .Concat(Directory.GetFiles(inputDir, "*.jpg")) .Concat(Directory.GetFiles(inputDir, "*.jpeg")) .ToArray(); for (int i = 0; i < files.Length; i++) { string fileName = Path.GetFileNameWithoutExtension(files[i]); var text = await Task.Run(() => Recognize(files[i])); File.WriteAllText(Path.Combine(outputDir, $"{fileName}.txt"), text, Encoding.UTF8); progress.Report((i + 1) * 100 / files.Length); } }前面這些坑，大部分都是我实际部署过程中一条条踩出来的。最有价值的一条经验：PaddleOCR的模型文件虽然不是C#直接编译出来的，但部署时把它们当作程序的一部分来管理，跟随版本一起升级维护，是最靠谱的。模型和程序的版本要保持一致，别只更新程序，模型还在用半年前的旧版本，那样识别效果达不到预期也正常。
另外再补充一个小技巧，程序里OCR识别完成后，可以把置信度低于0.8的文本区域用高亮标出来，或者单独存成一张“低置信度名单”。这样在人工复核时效率会高很多。很多商用OCR系统就是这么设计的，原理并不复杂，就是在Regions遍历时多做一个阈值判断而已。
本文还有配套的精品资源，点击获取
