自动化脚本文字识别实战：自定义字库构建全流程解析

一、为什么自动化脚本需要文字识别

在自动化脚本开发中，找图、找色是最常用的两类定位手段，它们擅长回答“某个图案在不在、坐标在哪里”。但有一类需求它们天然无法覆盖：屏幕上显示的内容到底是什么。

典型的场景包括：

• 自动交易流程中，需要读取订单金额、数量等数字，才能决定后续执行哪个分支；
• 监控类脚本需要周期性扫描行情价格、库存余量等数字变化；
• 业务系统或客户端的状态栏、倒计时、等级等信息往往以位图形式渲染，无法从程序内部直接读取。

这些场景的共同点是：待处理信息以“像素”形式呈现在屏幕上，脚本必须具备“看懂”文字的能力，也就是 OCR（光学字符识别）。本文介绍一种最务实、最易调试的落地方案——自定义字库识别。

二、方案选型：通用 OCR 与自定义字库

屏幕文字识别通常有两条路线：

1. 调用通用 OCR 能力（本地引擎或云端接口）：适合字体多样、排版复杂的开放场景，但会引入外部依赖、网络延迟与调用成本，对“固定样式、小字符集”的场景而言属于高射炮打蚊子。
2. 自定义字库匹配：把屏幕上出现的字符制作成点阵模板，建立“点阵图案 → 字符含义”的映射字典；识别时将截取区域的二值化图像与字库比对，命中即返回对应含义。

自定义字库的核心优势在于：识别对象封闭（如 0–9 十个数字）、显示样式固定（同一字体字号渲染）、响应快、完全本地化、结果可控可调试。

理解它的关键一句话是：字库就是字典。程序先“看见”像素图案，再查字典“理解”含义；没有字典，它只能看到一团点阵，并不知道那是一个数字还是一段乱码。

三、动手前的准备工作

1. 脚本环境：需要支持屏幕截图、图像处理与扩展库加载的自动化脚本框架。多数框架通过插件形式提供 OCR 或字库识别能力，安装与注册方法可参考其官方文档或社区教程，此处不展开。
2. 明确识别目标与字符集：本例以终端中输入的数字（0–9）为识别目标，输入 123 就应识别出 123。字符集封闭是本方案高效的前提，动手前先穷举所有可能出现的字符。
3. 固定显示条件：字体、字号、颜色、缩放比例尽量固定；若运行环境存在变化，需在字库中补充多种渲染样式下的点阵。

四、字库构建全流程

4.1 截取样本图像

使用识别工具的抓图功能（快捷键或工具栏按钮均可），框选包含目标文字的最小区域，确认后预览窗口会显示刚截取的图像。

经验提示：截图范围务必小。范围越大，混入的背景颜色与干扰元素越多，后续二值化越容易产生噪点。宁可多截几次，也不要贪大。

4.2 二值化处理

二值化是把彩色图像变成“非黑即白”的点阵，操作上一般分三步：

1. 在工具的颜色选择区任选一个颜色框；
2. 将鼠标移到预览图上，点击文字本身的颜色（即数字的前景色）；
3. 工具按该颜色及容差筛选像素，其余区域变黑，文字部分保留为可见点阵，二值化区域随即显示提取结果。

若此时杂点很多，几乎都是截图范围过大所致，回到 4.1 重新截取更小的区域即可。

4.3 提取点阵

• 提取单个：将二值化区域内的全部内容作为一个整体图案入库；
• 提取多个：自动判断相邻字符的边界并逐字拆分，适合”123”这类连续字符串。

对数字识别，推荐使用“提取多个”，让工具自动完成字符切分，效率更高。

4.4 标注字符含义（最关键的一步）

到目前为止，程序只知道“存在一个点阵图案”，并不知道它的中文含义。必须在定义文字输入框中手动输入该图案对应的字符（例如 1），输入后务必按回车保存——回车就是提交动作。保存后字库计数加一，界面通常以“图案编码｜含义”的形式展示已录入条目，竖线左侧是编码，右侧即你标注的含义。

这一步的本质是人工建立“图案 → 语义”的映射，程序此后再遇到相同点阵，就能“理解”它是数字 1。

4.5 补全字符集

重复“截图 → 二值化 → 提取 → 标注”，把 0–9 十个数字全部入库。为什么必须做满十个？因为任意长度的数字串都由这十个字符组合而成，缺任何一个，遇到该字符时识别就会失败或输出错乱。

五、字库验证：先验证，后编码

字库完成后，第一件事不是写代码，而是验证：

1. 在终端重新输入一组新数字（刻意避开建库时用过的样本）；
2. 重新截图并二值化；
3. 观察识别区域：字库中已存在的字符会被自动翻译成对应含义显示出来。

若显示结果与输入一致，字库即宣告可用；若出现错认、漏认，回到 4.2 检查二值化颜色与容差设置，或补充缺失的点阵样式。

六、在脚本中调用识别

验证通过后，识别逻辑只需三步：加载字库 → 截取区域 → 匹配输出。以下为示意性伪代码，具体函数名以所用环境为准：

// 1. 加载字库文件
LoadFontLibrary("digit_lib.txt")
// 2. 截取目标区域，按"前景色-偏色"描述进行二值化匹配
text = OcrByLib(320, 180, 460, 210, "FFFFFF-000000")
// 3. 用识别结果驱动业务分支
If IsNumeric(text) Then
    amount = CInt(text)
    TracePrint("识别到的金额：" & amount)
Else
    TracePrint("识别失败，进入重试逻辑")
End If

工程化角度还应补充三点：识别失败时的重试与截图留档机制；识别结果的合法性校验（位数、取值范围）；将字库文件纳入版本管理，便于迭代与回滚。

七、常见问题与优化建议

1. 干扰点多、识别率低：缩小截图范围；调整二值化颜色与容差；必要时先用找色锁定文字所在区域，再做识别。
2. 字体渲染变化（抗锯齿、缩放、DPI 差异）：同一字符在不同渲染条件下点阵不同，需分别入库；条件允许时固定系统 DPI 与字体渲染设置。
3. 背景颜色不固定：改用带偏色描述的匹配方式（如“颜色-偏差”写法），或对底色做预处理。
4. 字符粘连或切分错误：改用“提取单个”逐字手动入库，或调整显示条件增大字符间距。
5. 识别场景扩大（字母、汉字）：字库条目会显著增加，建议按业务场景拆分多个字库文件，按需加载。
6. 复杂场景升级：若文字样式多变、字符集开放，自定义字库的维护成本会超过收益，此时可评估通用 OCR 能力（本地引擎或云服务厂商提供的文字识别类接口），在精度、成本与延迟之间做权衡。

八、总结

自定义字库方案的本质，是“点阵模板 + 人工标注字典”的封闭集识别：把屏幕文字问题转化为图案匹配问题。它的成本集中在前期标注入库，收益是运行期零外部依赖、低延迟、结果完全可控。对于字符集固定、显示样式稳定的自动化场景——金额、价格、倒计时等——这是最务实、最易调试的落地路径。掌握“截图—二值化—提取—标注—验证”这条流水线，再遇到“找图找色搞不定”的需求时，就有一套可靠的解题框架。