给自己的站加一个「上传扫描件转文字」并不难，识别有现成的库可接。真正要拍板的是预处理放在哪一端。放在浏览器里能替服务器省下 CPU，放在服务器上则前端更轻、出了问题日志也都在自己手里。图省事的话，大概会把纠斜、去噪、二值化三步全上，再一股脑塞进后端。我把一组公开扫描页的实测数逐项对了一遍。看完觉得这件事得倒过来想：先看后面接的识别器怕什么、再定哪一步要做，最后才轮到放在哪端。

数据来自两页清晰的出版物扫描：一页是 1986 年发布的《简化字总表》说明，557 个汉字；一页是 1895 年英文小说《The Time Machine》的正文，1,002 个字符。版面都是单栏，字不大不小。页面的倾斜和噪点是程序后加的，并非真扫歪了。所有结果都在一台 Mac 电脑（Apple M4）上单次运行。错字数用字符编辑距离来数，多字、少字、认错一个字都算一处。下面每个数都只对这两页成立。

## 三种识别器怕的东西不一样

先看能直接装在服务器上的开源识别器 Tesseract。英文页不加噪时歪 0°、1°、3°、5° 的准确率是 98.9、99.5、98.1、96.2。歪到 5° 也只掉 2.7 个点，只做纠斜就能拉回 99.0。真正伤它的是噪声。加上 5% 的椒盐噪点后页面正着放也只剩 75.5。歪 3° 再加椒盐时不处理是 72.5，只做一次 3×3 中值就回到 97.6。对 Tesseract 来说去噪比纠斜值钱得多。

macOS 自带的文字识别正好反过来。中文页从 0° 歪到 5° 的错字一直在 4～9 处。纠斜对它几乎没有贡献，Otsu 二值化在它身上一律略差。只有椒盐噪声会让它的错字明显涨到 16～26 处。做完中值去噪又回到 5～8 处。

浏览器端这一档测的是一个网页版的 PDF 文字提取工具，页面说明里写的模型是 PP-OCRv6，首次使用要先下载模型，内部具体怎么跑我不清楚。正着放时它在中文页上只错 2 个，歪 1° 时错 1 个。到 3° 行序就乱了，错 175 处并丢掉 31 个字。到 5° 错 362 处，原文 14 行只剩下约一半。界面照样显示处理完成且没有任何提示。同一页歪 3° 再加噪后先去噪、纠斜、Otsu 再送进去，又回到错 2 个。

| 识别器 | 歪了会怎样 | 噪声会怎样 | 值得做的预处理 |
|---|---|---|---|
| Tesseract | 5° 只掉 2.7 个点 | 椒盐 5% 掉到 75.5 | 先去噪、3° 以上再纠斜 |
| macOS 自带识别 | 0～5° 稳定在 4～9 处 | 只怕椒盐（16～26 处） | 椒盐时做中值、不纠斜不二值化 |
| 浏览器端 PP-OCR | 3° 起乱序丢行 | 单独加噪的条件没测 | 1° 正常，3° 起必须先转正 |

## 估角适合放在前端

估角的产出只是一个数字，很适合交给浏览器去算。这里用的是投影法。先把页面缩到四分之一再在 ±7° 范围里每 0.1° 转一次。每转一次就算一遍各行像素和的方差，取方差最大的那个角度。英文页转 0°、1°、3°、5° 后估出的是 0.3、1.2、3.3、5.3°（多出来的 0.3° 是原页自带的倾斜）。另有一组补测在高斯和椒盐两种噪声下重跑过，投影法估出的角度和无噪时完全一样。换成 minAreaRect 就不稳了：散在画布上的噪点会把外接矩形撑开。二值图不先做中值的话椒盐三档全估成 0.00°。先做中值也出现过把歪 5° 估成 8.92° 的情况。步长放粗到 0.5° 时转 5° 的页估成 5.50°，这点误差对识别有多大影响没测。我的做法是在前端缩图并估角，再把角度和原文件一起交给后端。后端只多收一个数而不用再跑一轮角度搜索。这里有两个假设我最没底。上面的角度是用 OpenCV 算的，换成浏览器里重写的投影法能不能得到同样的数没验证过。141 次小图旋转放在低配手机的浏览器里会不会卡，这个耗时也没测。

## 去噪和转正要在同一端做

前端都把角度算出来了，顺手转正再上传看起来更省事。问题出在顺序上。椒盐噪声下先纠斜再去噪的四个角度只有 91.5～94.4。先去噪再纠斜是 98.6～99.1。只纠斜不去噪更糟，从 48.9 一路掉到 7.3。原因只能算推断。旋转用的三次插值会把孤立的黑白点糊成几个像素大的灰斑。3×3 中值去不掉这些斑，识别器就把它们当成了笔画。另有一组补测换过插值方式：歪 3° 加椒盐并先转正再中值时最近邻错 10 个（99.0%）、双线性错 27 个（97.3%）、三次错 58 个（94.2%）。前端用 canvas 转图默认会开平滑。它具体按哪种插值走、各家浏览器是否一致我没查，只能推断更接近双线性。前端转正再交给后端去噪的拆法，等于悄悄把顺序做反了。

我的拆法是先看识别在哪。识别在后端时前端只估角不转图，去噪、转正、二值化全在后端按顺序走。识别在浏览器时就把这三步连同识别一起在浏览器里走完。二值化放在最后而且可以不做。去噪、纠斜、Otsu 这一串在 Tesseract 上测了 12 个条件的结果都在 98.5～99.5 之间。自适应二值化碰上高斯 σ25 的噪声时四个角度输出全是空的，这一步我不会直接放上线。下面是后端那段按定义简化的示意。它没单独跑过，上面的数来自完整测试。

```python
import cv2
def clean_then_rotate(upload_img, tilt_deg, salt_pepper):
    if salt_pepper:
        upload_img = cv2.medianBlur(upload_img, 3)
    else:
        upload_img = cv2.fastNlMeansDenoising(upload_img, None, 15, 7, 21)
    h, w = upload_img.shape
    m = cv2.getRotationMatrix2D((w / 2, h / 2), -tilt_deg, 1)
    return cv2.warpAffine(upload_img, m, (w, h), flags=cv2.INTER_CUBIC, borderValue=255)
```

## 中值核要跟着分辨率挑

去噪放在后端还有一个理由。后端拿到的是原图并且知道实际有多少像素。宽 1516 的英文页上 3×3 中值把错字从 11 降到 2，换成 9×9 后准确率就被拖到 91.0。中文页交给 macOS 自带识别时 9×9 中值让准确率从 99.1 掉到 68.0，细横、点和偏旁最先消失。同一张英文页缩到宽 758 后 3×3 中值就让错字从 4 涨到 28，用 5×5 更是掉到 85.8。前端估角用的那张小图只拿来算角度，不能拿去去噪。按页面宽度分档挑核大小只是我的假设：手里只有两个尺寸的数，中间该怎么切还没底。

## 噪声类型还没法自动分辨

测试里的噪声是程序加的且类型事先就知道，所以高斯噪声用非局部均值、椒盐噪声用中值，各走各的。用户真传上来一张脏扫描件时是哪种噪点，我还没想到靠谱的判断办法。两种去噪各跑一遍再比，去噪这一步的计算量就多出一倍，这笔账我还没算清。这组数也只来自两页清晰印刷件，双栏、低分辨率和手机拍照的透视变形都没测。前面每一处「放哪端」的判断都押在识别器身上，哪天把 Tesseract 换成别的引擎，这套前后端的拆法就得跟着重排。

样本：中文为国家语言文字工作委员会《简化字总表》1986 年新版说明页，Internet Archive，公有领域标记。英文为 H. G. Wells《The Time Machine》1895 年版第 8 页，维基共享资源，公有领域；倾斜、噪声版本是自制。


给自己的站加一个「上传扫描件转文字」并不难，识别有现成的库可接。真正要拍板的是预处理放在哪一端。放在浏览器里能替服务器省下 CPU，放在服务器上则前端更轻、出了问题日志也都在自己手里。图省事的话，大概会把纠斜、去噪、二值化三步全上，再一股脑塞进后端。我把一组公开扫描页的实测数逐项对了一遍。看完觉得这件事得倒过来想：先看后面接的识别器怕什么、再定哪一步要做，最后才轮到放在哪端。

扫描件OCR预处理放前端还是后端，先看识别器怕什么

用户上传的扫描件该在哪端预处理：Tesseract怕噪不太怕歪、macOS自带识别几乎不怕歪、浏览器端PP-OCR歪3°就乱序；估角可放前端，去噪要在转正前且同一端做。

内容负责人

人工智能

前端

后端

上传扫描件转文字，预处理放在前端还是后端？实测Tesseract、macOS自带识别、PP-OCRv6对噪声和倾斜的不同反应：Tesseract最怕椒盐噪声，去噪比纠斜更关键；macOS识别对倾斜不敏感，只怕噪点；PP-OCR歪3°即乱序。建议前端只估角，后端按「先去噪再纠斜」顺序处理，二值化可不做。

文字识别

代码解释

服务器

MacOS

让每一个 Agent，都跑在云上

imageprocess

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

扫描件OCR预处理放前端还是后端，先看识别器怕什么-腾讯云开发者社区-腾讯云

扫描件OCR预处理放前端还是后端，先看识别器怕什么

扫描件OCR预处理放前端还是后端，先看识别器怕什么

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐