如何处理图片避免文字被OCR识别：原理与对抗实践

一、为什么要讨论“防OCR”

在实际业务与个人内容发布中，常会遇到这类需求：把文字内容渲染成图片对外分享，希望真人读者能顺利阅读，但不希望被自动化工具批量抓取、转写或建立索引。典型场景包括：防止图文内容被爬虫批量搬运、避免截图中的信息被自动化流水线提取、以及对图片中的版权与水印信息做防护。

传统思路是“堵”：加噪点、扭曲变形、局部模糊、彩色干扰线等。这些手段存在一个共同问题——它们对人和对机器的伤害是同步的。防OCR效果越好，人类的阅读体验越差；而如果力度不足，OCR只需稍作预处理（去噪、二值化、透视矫正）就能恢复识别能力。

本文介绍一种相反的思路：“疏”。不阻止OCR工作，而是主动配合它的工作流程，让它在预定位置“顺利完成识别”，从而放弃对真正载荷文字的检测。

二、先弄清楚OCR是怎么工作的

主流OCR引擎普遍采用“检测＋识别”的两阶段流水线：

1. 文本检测阶段：在整图上生成候选区域（连通域、候选框或分割掩码），判断“哪里有字”；
2. 文本识别阶段：对每个候选区域进行裁剪、矫正，逐个识别出字符内容。

这条流水线为了工程效率，普遍存在三个可被利用的特性：

其一，尺度偏好。检测器基于固定或有限的多尺度特征工作，对常见文档字号（几十像素量级）最敏感，对极端字号（数百像素的大字、或十几像素以下的小字）要么置信度骤降，要么直接被合并进邻近的大框。

其二，重叠抑制。检测后处理中的非极大值抑制会合并高度重叠的候选框，大字产生的框天然压制落在其内部的小字框。

其三，一检即止。一旦某区域被判定为“文字”并完成识别，流水线不会再对该区域内部做二次细分扫描——系统默认一个检测框内就是一段普通文本，不会怀疑“这个大字的笔画本身是由更小的字组成的”。

第三点是整个方案的核心突破口。

三、核心思路：让OCR“识别出文字”，而不是“识别不出”

正所谓堵不如疏。想让OCR识别不出目标文字，最稳妥的办法反而是让它识别出别的文字：用一份“看起来完整可信”的诱饵文本占据检测框，使引擎认为该位置已经处理完毕，从而放弃二次检测。

这种对机器的误导，对人类完全无效。人眼看到一个大字，会自然注意到它的笔画由密密麻麻的小字构成，凑近即可逐字分辨；而未经专门训练的模型，不会对一个高置信度的检测框产生“内部还有字”的怀疑。

需要强调本方案的适用边界：它防的是自动化识别，不防人类阅读。设计初衷就是让人类始终是合法读者，机器才是被防御的对象。

四、两种布局：大字藏小字与小字藏大字

按照诱饵与载荷的字号关系，分为两种布局：

1. 大字藏小字：以数百像素的大字作为诱饵，把十几到三十像素的小字（真正的载荷）填充进大字的字形区域内。适用于对全局检测能力较强、能对超大字号给出稳定检测框的OCR引擎。
2. 小字藏大字：思路对称，以密集的小字号诱饵优先占满检测器的候选，使真正的大字号载荷落在引擎不再细分的区域。适用于对小字检测特别精确、反而容易漏掉异常大字的引擎。

选哪种没有万能答案——各家OCR的处理流程虽然固定，彼此差异却很大。正确做法是试错：先用小样张分别测试目标引擎，观察哪一端的识别更“顽固”，就反向布置诱饵，见招拆招。两种布局大概率总有一种能奏效。

五、关键参数怎么调

这套方法最灵活之处在于字号、行距、字距全部可调。几组可参考的参数组合：

• 大字300像素，小字12像素，行间距1像素，字间距1像素；
• 大字400像素，小字30像素，行间距0像素，字间距0像素；
• 大字200像素，小字12像素，行间距1像素，字间距1像素。

调参原则：

• 大字字号越大，越容易获得高置信度检测框，诱饵越稳；
• 小字字号要在“人眼可辨”与“低于检测敏感区间”之间取平衡，且必须把下游平台的图片压缩损耗计算在内（后文详述）；
• 行距、字距压到0～1像素，是为了提高小字填充的密度与均匀度，让大字笔画看起来“浑然一体”。

另一个重要细节是填充顺序。早期实现按全局从上到下、从左到右的光栅顺序填充小字，人眼追踪起来非常吃力；改为“大字逐字填充”——先填满第一个大字，再填第二个——之后，读者只需按大字顺序连读其中的小字即可，识别难度显著下降。这是一个典型的“对机器无差别、对人类体验影响巨大”的优化。

示意伪代码如下：

# 伪代码：大字藏小字的渲染流程
def render(big_text, secret_text,
           big_size=400, small_size=12,
           line_gap=1, char_gap=1):
    # 1) 逐个渲染大字字形，提取笔画/字形区域掩码
    # 2) 按大字顺序逐字处理：
    #    在每个大字的掩码内部，以行高 small_size+line_gap
    #    逐行排布 secret_text 的小字，字间距 char_gap
    # 3) 小字按序循环取用，直至该大字区域填满
    # 4) 输出合成后的图像
    ...

具体实现可借助任意支持文字渲染的常用图像处理库完成，逻辑并不复杂。把需求描述清楚后，让通用大语言模型直接生成一版代码再手工调参，也是可行的路径。

六、为什么不推荐模糊等传统手段

一个常见疑问是：加高斯模糊能不能解决？确实能，模糊可以物理性地抹掉小字，但它有两个致命问题：

第一，模糊必须“有的放矢”。其前提是人类先看出哪里有大字、哪里藏了小字，再对局部做定向模糊，模型自己并不会主动判断哪里该模糊。如果让流水线不分青红皂白地对所有图片统一加模糊，一张正常的文章截图糊完就什么都识别不出来了，这属于自毁式防御。

第二，一旦需要人类参与判断，防御就失去了意义。人既然能看出哪里藏了字，就等于人已经能直接读懂内容，再走OCR流程纯属多余。

对比很清晰：模糊类手段是“人机同伤”，本方案是“精确防御机器、完整保留人类的可读性”。

七、工程落地的注意事项

1. 警惕图片压缩。移动端上传或转发图片时，平台普遍会做有损压缩（重采样叠加质量因子下降），12像素级别的小字可能在压缩中被直接抹平，导致载荷既骗不过机器、也无法还原给人看。对策包括：适当提高小字字号；引导读者获取原图（电脑端通常可下载原图）；控制转发次数，避免多级压缩叠加。实践中建议在目标平台分别用移动端与电脑端各验证一轮。
2. 载体字形选择。笔画繁复、内部空间充足的字更适合做“容器”；笔画稀疏的字填充区域小，承载的小字信息量有限。
3. 密度与可读性的平衡。密度越高对机器越“浑然一体”，但小字过密也会加重人眼阅读疲劳，需按载体字号折中。
4. 建立验证闭环。生成样张→用目标OCR实测→不达标就调整字号、行距或布局→复测。由于各引擎流程固定，一旦调通，同参数即可批量生产。

八、局限性与适用声明

必须客观说明这套方案的天花板：

其一，成立前提是目前尚无针对这类“文字隐写”专门训练的模型。如果未来出现会对检测框内部做二次细扫、或把“超大字号”视为异常信号触发多尺度复核的引擎，该方式即告失效。对抗技术本质上是动态博弈，不存在一劳永逸的方案。

其二，它不设防的对象包括人类。如果威胁模型里包含人工审查或人机结合的审核流程，载荷文字仍会被读出。

其三，合规边界。这类技术用于保护自身内容、防止自动化滥用是正当的；不应被用于规避平台审核、传播违规内容或对抗合法监管流程。

九、小结

防OCR的最佳策略不是让机器“看不见”，而是让机器“看错了还自以为看对了”。利用OCR“检测→识别、一检即止”的流水线特性，以诱饵文字占据检测框，把载荷藏进引擎不再细分的区域；字号、行距、字距全部可调，配合试错可适配不同引擎；相比模糊等自伤式手段，它完整保留了人类的可读性。同时也要清醒：它防不住专门训练的模型，也从来不想防人。理解这类对抗性思维的原理与边界，比记住任何一组具体参数都更重要。