屏幕上那行状态文字死活找不到换了三个版本的字库还是不行——这种经历我给客户做界面自动化录入工具的时候没少碰到。后来把大漠插件的找字函数从基础用法到参数原理彻底吃了一遍再回头看当时的报错和误识别几乎都是对参数的理解出了问题而不是插件本身不行。这次就把我一直在用的FindStrE系列的经验完整梳理出来从环境准备到参数拆解再到实际项目里的排错力求让看完的人能直接上手少走几个月弯路。FindStrE是易语言环境下调用大漠插件做屏幕文字定位的核心函数组简单说就是在屏幕指定区域内按你训练好的字库去找指定的字符串返回坐标。它比传统找图多了一个维度找图是像素级匹配对缩放、变色、遮挡非常敏感找字是基于字形特征和颜色特征匹配只要字体和颜色在偏色范围内它就能认出来。这个特点决定了它特别适合做三件事软件界面上的状态文字识别、固定报表里的关键字段定位、以及各类自动化测试脚本里的按文字找控件。我默认看这篇文章的人要么是刚接触易语言和大漠插件的新手要么是已经在用但总被参数坑到的进阶用户。下面我不会只贴一段能跑的代码就完事而是把调用链路上每个环节都拆开讲清楚。1. FindStrE是干什么的为什么找字比找图更省心1.1 找字和找图的本质区别很多人刚开始做屏幕自动化脑子里第一个想法就是找图把目标截图存下来然后在大屏上做模板匹配。找图在图标、按钮这类形状固定的元素上很好用可一旦遇到文字就头疼。同样的一个销字不同字号、不同分辨率、不同渲染模式截出来的图差距很大模板匹配很容易失灵。更别提文字旁边还有背景色干扰、阴影效果这类情况找图基本就是撞运气。找字的思路完全不一样。它的机制分两层第一层是图像层面的颜色过滤先把你指定的区域里符合主色-偏色范围的点全部保留下来其它颜色全部屏蔽掉第二层是字形层面的特征比对在过滤后的二值图像里去和字库里保存的字符特征做匹配。所以它不要求背景像素一模一样只要文字本身的颜色和近似度落在范围内就能稳定识别。这个原理决定了找字在动态背景、系统缩放、轻微变色这些场景里比找图可靠得多。1.2 E后缀到底多了什么能力大漠插件里找字函数有一整个家族FindStr、FindStrE、FindStrEx、FindStrExE、FindStrFast、FindStrFastE……新手最容易被后缀搞晕。按我的理解命名规则其实很规律不带后缀的 FindStr只返回第一个匹配到的坐标。带 Ex 的 FindStrEx会返回所有匹配到的坐标格式是一串x1,y1|x2,y2|...。带 Fast 的 FindStrFast走更精简的匹配算法速度更快但对字库制作质量要求更高。带 E 后缀的 FindStrE多了一个字库名font_name参数可以在一次调用里显式指定用哪个字库去识别而不是依赖 SetDict 设置的默认字库。E 后缀的价值在于字库切换的灵活性。真实项目里一台机器上可能要识别多个软件的界面不同软件的字体风格差异很大你不可能把所有字符塞进同一个字库去匹配。有了 E 系列你就可以为每个场景准备独立字库调用时指定互不干扰。后面我演示的 Demo 就是用 FindStrE 来实现的。2. 环境准备把大漠插件稳定地用起来2.1 注册与全局初始化大漠插件是一个 COM 组件常规使用前需要先把它注册进系统。一般步骤是把插件文件放到一个固定目录比如 C:\dm然后以管理员身份打开命令行执行注册命令。注册完以后在易语言里就可以通过创建对象的方式来调用。有个容易忽略的坑64 位系统下注册 32 位 COM 组件路径可能和你预想不一样。如果你用的是 32 位插件版本在 64 位系统上注册时要确认组件位数和易语言编译出来的程序位数一致。最稳妥的做法是让整个项目统一在 32 位模式下开发和运行兼容性最好。注册完成后我建议在程序启动时做一次版本检查避免用户机器上一份旧版插件导致接口对不上。通用初始化代码思路如下.版本 2 .支持库 spec .程序集 窗口程序集_启动窗口 .变量 dm, 对象 .子程序 _启动窗口_创建完毕 dm.创建 (“dm.dmsoft”, ) 输出调试文本 (“插件版本: ” 到文本 (dm.数值方法 (“Ver”, )))这里用到了易语言的对象类型调用 COM 方法。如果调用失败返回值为空或者直接抛异常优先检查插件是否注册成功、是否被杀毒软件拦截、以及程序位数是否匹配。2.2 字库文件找字的弹药库找字的前提是有对应的字库文件。字库是大漠的字库工具生成的 txt 文件里面保存的是你已经标记过的字符特征数据。制作字库的流程通常是打开大漠配套的字库工具截图目标软件的界面。框选一个字设定偏色范围然后在工具里把它标记成对应字符。一个字一个字地积累最后导出成字库文件。这个过程看起来很朴素但它直接决定找字成功率。我见过太多人字库做得很随意框选时把文字旁边的干扰点也圈进去了导出后发现字体稍微一变就识别失败。标准做法是一个字多做几个样本把正常态、鼠标悬停态、选中态的颜色变化都收进字库或者偏色范围里这样才有冗余度。字库文件做好之后要集中放在程序能访问到的目录并且在初始化的设路径SetPath里指向它。路径里尽量别带中文少部分环境对中文路径的兼容性不好你排查半天还以为是代码问题。2.3 在易语言里封装一层直接在窗口代码里到处写“dm.数值方法(…)”代码很快会乱成一团。我的习惯是做一个专门的大漠封装模块把初始化、找字、找色、回收释放都包一层项目里其它代码只调用中文子程序这样就算后期换了一个插件也只需要改封装层。封装层至少要包含这几个子程序初始化大漠注册判断、设置路径、加载字库。找字单次封装 FindStrE把区域、字符串、颜色、偏色、字库名、相似度收成参数。找字全部封装 FindStrExE返回坐标集合方便需要遍历多个结果时使用。释放对象程序退出时调用避免 COM 对象残留。关键点在于把默认参数集中管理。比如相似度、偏色值这类全局配置在封装层定义成常量或者程序集变量不同调用点保持一致排查问题时只需要改一处。3. 参数逐个拆解理解参数才算真正会用3.1 查找区域与待查字符串FindStrE 的前四个参数是查找区域的左上角和右下角坐标。这个区域越小扫描的像素点越少速度越快。很多人图省事直接全屏找结果性能慢、误识别率还高。正确做法是先通过窗口句柄拿到窗口在屏幕上的位置和大小再在这个基础上缩小查找范围。第五个参数是待查找的字符串。这里有几个细节字符串可以是多个字比如已完成函数内部按字库里的字符顺序去匹配。字符串里不要带空格尤其是全角空格。很多文本看起来是空格其实是排版产生的空白加入待查字符串后会造成匹配失败。如果待查文字里包含特殊符号尽量单独验证这个字符是否成功做进了字库不要假设它一定在。3.2 偏色和相似度的配合颜色参数一般写法是主色-偏色比如9F9F9F-202020意思是在 RGB 三个通道上允许 0x20 的浮动范围。理解它的作用非常重要屏幕上几乎没有纯色文字系统字体渲染有抗锯齿边缘像素的颜色是渐变的。如果偏色设得太小边缘像素全被过滤掉剩下的是骷髅字字库匹配必然失败偏色设得太大背景里的近似颜色也会混进来形成一堆噪点。相似度参数范围是 0 到 1表示字形匹配的允差。我建议从 0.9 开始调太高接近 1.0要求过于严格稍微一点抗锯齿差异就识别不到太低又会把形状相近的字符认错。等到调参阶段可以把相似度先降到 0.8 验证字符集是否完整确认没问题后再升回 0.9 以上这个顺序可以快速区分是字库问题还是阈值问题。3.3 字库名与返回坐标FindStrE 比基础版多出来的就是字库名参数。它的作用是告诉插件这一次查找请你用叫default的这个字库来匹配。所以初始化时不仅要 SetPath还要把对应的字库文件用字库加载接口导进来并且给每个字库一个唯一名称调用时名称对不上会直接返回查找失败。返回坐标是两个整数型变量参数采用引用传递。函数返回值是整数型返回 1 表示找到0 表示没找到。找到时 x 和 y 会被写入匹配位置的左上角坐标这个坐标是屏幕绝对坐标不是相对于查找区域的偏移。我在早期项目里犯过错拿返回坐标去和窗口客户区坐标做减法结果算出来的位置偏移整条工具栏的高度后来才发现接口返回的就是屏幕绝对坐标。4. 做一个完整的找字识别Demo4.1 场景与思路我拿一个真实做过的场景举例某内部工单系统界面是网页套壳工单列表里每行有个状态栏取值是待处理处理中已完成。我需要写一个自动化脚本每天定时截取列表区域把每行的状态识别出来回填到另一个统计表里。这个需求用 FindStrE 特别合适因为状态文字颜色是系统固定的字体也是固定的字库只做这几个词就行。思路分三步先获取窗口位置和大小再锁定状态栏所在的列表区域最后在区域内查找对应字符串记录坐标和信息。4.2 代码实现核心代码简化后大概长这样.版本 2 .支持库 spec .程序集 窗口程序集_启动窗口 .变量 dm, 对象 .子程序 初始化环境 dm.创建 (“dm.dmsoft”, ) dm.数值方法 (“SetPath”, , “C:\dm_dict”) dm.数值方法 (“SetDict”, , 0, “status_dict.txt”) dm.数值方法 (“LoadDict”, , 0) .子程序 查找状态文字 .参数 查找区域左, 整数型 .参数 查找区域顶, 整数型 .参数 查找区域右, 整数型 .参数 查找区域底, 整数型 .局部变量 x, 整数型 .局部变量 y, 整数型 .局部变量 结果, 整数型 结果 dm.数值方法 (“FindStrE”, , 查找区域左, 查找区域顶, 查找区域右, 查找区域底, “处理中”, “9F9F9F-202020”, 0.9, 0, x, y) 如果真 (结果 1) 输出调试文本 (“找到处理中坐标: ” 到文本 (x) “,” 到文本 (y)) 否则 输出调试文本 (“未找到”) 如果结束这套代码在封装层之下属于最简版本真实项目里至少还要加一个容错如果返回 0可以把相似度调低 0.05 再试一次大多数时候是抗锯齿导致的边缘差异。如果调低相似度后找到了说明字库样本做得还不够全回头去补字典。4.3 跑通后的验证跑通一次只是起点我建议做一组验证用例把界面上几种状态都截图存好脚本自动切换状态后调用找字断言返回值和坐标是否符合预期。这一步很多人忽略以为当时能识别就万事大吉。实际经验是换个显示器、改个缩放比例、或者系统主题从浅色切到深色之前的参数可能全部失效。验证用例能让你发现原来这个颜色其实是主题控制的而不是纯粹的字库问题。我自己的做法是做一个简单的调试窗口实时显示查找区域、字库加载状态、最近一次找字的返回值。这样调参数的时候不用反复改代码编译直接在调试器里能看到结果效率高非常多。5. 实战中踩过的坑排查链路与解决5.1 字符识别偏移或返回坐标不准最典型的症状是返回值是 1坐标也拿到了但鼠标按过去却点到了别的地方。这通常不是找字函数的问题而是查找区域坐标系和鼠标移动坐标系不一致。窗口缩放、DPI 缩放、窗口在屏幕上的位置变化都会造成这个偏差。排查链路参考先确认返回的坐标是不是屏幕绝对坐标。用一个调试工具在屏幕上显示当前鼠标位置和返回坐标对比。确认窗口有没有发生移动或缩放。如果窗口在屏幕上的位置变了旧坐标自然失效。确认是否开启系统 DPI 缩放。高 DPI 下系统会对程序和屏幕做坐标换算需要在程序里声明 DPI 感知否则易语言拿到的窗口坐标和屏幕真实坐标不一致。最后再怀疑字库本身。字库的锚点位置偏移会导致返回坐标偏了几个像素但不会差出整个控件区域那么多。5.2 后台窗口找字失败前台找字没问题一旦把窗口最小化或者遮挡到后面就找到不到了。原因是正常的找字走的是屏幕绘制结果窗口被遮挡后目标区域的画面已经不是你要的内容。这时候需要走后台绑定模式通过背景接口把目标窗口绑定到插件上让它读取窗口内部图像而不是读屏幕。绑定窗口是有前置条件的目标窗口的渲染方式必须支持后台取图。网页套壳、自绘界面等相对容易有些走硬件加速渲染的窗口后台取图拿到的是黑屏那就没辙。遇到这种情况我会先试普通绑定模式再试开启 gdi 模式确认哪种模式能稳定取图再继续做找字。绑定成功以后记得所有找字操作都要在绑定上下文中执行否则返回的坐标还是屏幕坐标系容易混。必须说一句后台绑定这套能力只应该在你自己有权控制的软件、自动化测试环境、或者明确允许自动化的工具里使用。任何未经授权去操作别人软件的行为都违反用户协议尤其是游戏中后果不是技术问题而是账号和合规问题。5.3 常见报错与对策现象常见原因处理方式调用即返回 0字库没加载成功检查 SetPath 和 SetDict 路径、是否有中文路径返回 0调试时用同类字能识别待查字符串里的字符不在字库用字库工具逐个确认字符是否录入识别到但坐标全部偏右上角相似度和偏色太宽松匹配到边缘点收紧偏色范围提高相似度到 0.92 以上偶尔把相似字认错字库存量字符特征太接近补充正负面样本重新生成字库绑定模式取图黑屏窗口走硬件加速渲染尝试不同绑定模式或放弃后台方式6. 进阶性能优化和函数变体怎么选6.1 区域裁剪是最大的性能杠杆找字速度和扫描面积直接相关。一个 1920×1080 的屏幕全屏扫描要比 300×200 区域慢好几倍。所以优化第一步不是换 Fast 函数而是把查找范围压缩到合理最小。如果窗口位置不固定可以先通过窗口句柄拿到客户区范围再在客户区内指定一个相对偏移区域这比写死坐标健壮得多。另一个技巧是两级预筛选。先用大色块的找色函数探测目标区域是否出现主色如果主色都没出现那就不用调 FindStrE 了直接跳过。等主色出现后再执行找字可以把识别频率降下来CPU 占用明显下降。这种先色后字是我做定时轮询任务的标准姿势。6.2 FindStr、FindStrEx、FindStrFast怎么选函数特点适用场景FindStr只返回第一个匹配坐标开销低界面里只有一个目标文本FindStrE指定字库名多个字库切换方便多界面、多字体项目FindStrEx返回所有匹配坐标适合遍历列表里有多行同状态文字FindStrFast匹配速度快但误识别率略高大区域内高频查询FindStrExEEx 和 E 的组合指定字库且返回全部复杂场景首选我个人常用组合是列表类需求用 FindStrExE界面控件定位用 FindStrE全屏扫描时改用 FindStrFastE 配合作区域预判。Fast 系并不是任何时候都更快它适合在字符特征非常稳定的字库上使用如果字库本身质量一般Fast 反而容易产生大量误报得不偿失。6.3 什么时候可以换OCR大漠找字再强也是基于你手工制作的字库遇到字体多变、字号变化、艺术字渲染等场景字库维护成本会爆炸。这时候就应该考虑系统级 OCR 方案。现代系统自带 OCR 接口对印刷体文字的识别能力远强于像素匹配而且不需要预建字库。我通常的判断标准是目标软件字体固定、颜色固定、区域固定继续用 FindStrE 系列维护成本最低。目标内容来自网页动态渲染、字体库经常变直接上 OCR 接口省去大量做字库的工时。两种结合的方案先用 FindStrE 定位控件框架再用 OCR 识别动态文本内容各取所长。我在实际项目里最后落地的往往是第三种。稳定性要求高的核心路径用字库找字不做 OCR 的灰度识别避免把错误数据写进统计表。最后再分享一个小技巧调试找字的时候不要只盯着返回值。把查找区域、字库名、偏色值、相似度、返回坐标这些信息全部输出到调试窗然后人为改变字体颜色、背景色、窗口位置观察结果变化很快就能找出你的字库和参数哪一环是薄弱点。字库是积累出来的不可能一次做好保持小步迭代实时验证的习惯比任何技巧都管用。
