技术
游程编码 RLE 原理:压缩流水线里的"找重复"基本功
📅 2026-08-22 · ✍️ 闪压技术团队 · ⏱ 6 分钟阅读
什么是 RLE:把连续重复压缩成一个"符号 + 次数"
如果让你手工把一份文件"压小",你会做的第一件事是什么?大多数人会说:找重复。游程编码(Run-Length Encoding,简称 RLE)就是把这件事做到极致的思路——只盯着"同一符号连续出现"这一种重复模式,用一对数字(值,长度)替代整段重复。
举个例子。一行原始数据是这样:AAAAAABBBBBCCCC,传统存储需要逐字符写出每个字母。但 RLE 的思路是:扫一遍,看到 A 连续出现若干次,就用 (A,次数) 替代整段;对 B、C 同样处理。原来逐字符写出的整段数据,被压缩成三组"符号 + 次数"的简记。
听上去很笨,但 RLE 的价值不在于"多聪明",而在于"足够便宜"。它几乎是所有压缩流水线里最先跑过的一道预处理工序——不是因为它压缩比最高,而是因为它几乎不花算力,还能把后续步骤的输入变得更整齐。
RLE 适合什么样的数据
回答这个问题,关键看"重复是不是连续的"。两类场景特别适合:
第一类:简单的位图和图标。早期 BMP 格式的图像,以及很多黑白二值的扫描件(比如老式传真、老旧的图表),大量像素是连续同色的。这种数据上,RLE 几乎是"白送"的。
第二类:长串同符号的数据。比如大段空白(日志文件里常见的连续空行)、连续零(稀疏矩阵、初始化的内存区域、数据库空字段)、同色色块(简单卡通图标、低分辨率 UI 截图)。这些场景里,RLE 一遍就能把数据量大幅砍下去。
反过来,两类场景几乎从 RLE 里捞不到好处:
第一类:重复不连续。如果同样的字节散落在文档各处,中间隔着别的字符,RLE 完全识别不出来——它只数"连续"。这时候要靠字典编码:扫整段窗口,匹配之前出现过的片段。
第二类:高熵数据。JPEG、PNG 压缩后的图像、MP3、AAC 等已压缩的媒体文件,字节本身已经接近均匀分布,既没有连续重复,也没有可识别的字典模式。RLE 在这种数据上几乎是无效开销,反而会让数据略微变大。
理解这一点很重要:RLE 不是"压缩一切"的银弹,它是一种高度专门化的预处理工具,只在重复是连续的时候才有用武之地。
RLE 在压缩流水线里的位置
很多读者第一次接触 RLE 时,会把它和字典编码、熵编码、BWT 等名字更响亮的算法放在一起比较。但 RLE 的角色其实和它们不在一个层面。它不擅长"挑出散落在文档各处的重复片段",那是字典编码的强项;它也不擅长"按概率给符号重新编码",那是熵编码的活。RLE 只做一件事:对连续重复做出反应。
这种"窄而专"的特点,在压缩流水线里反而是优势——它不会和后续算法抢戏。一段文本先用 RLE 处理掉明显的连续重复(比如长串的空格、连续的零、扫描件的同色块),后面的字典编码才能在更"干净"的输入上发挥;熵编码才能对 RLE 输出的小整数(重复次数)做更精确的概率建模。
RLE 真正发力,是作为流水线的一环。两种典型组合:
RLE + 熵编码。这是早期很多无损压缩工具的做法。RLE 把连续重复的符号变成"小整数 + 值",这些小整数天然是熵编码的好原料——霍夫曼编码、算术编码、ANS,它们对出现概率高的短符号编码效率高,而 RLE 输出的"次数"列里,小整数(比如 1、2、3、4)的出现频率往往远高于大整数。这种组合拳在传真图像、某些 BMP 工具里非常常见。
RLE + BWT + 熵编码。这是更复杂流水线的做法。BWT(Burrows-Wheeler 变换)不会压缩任何东西,只是把数据"洗牌",让原本分散的重复字节聚成更长的连续重复。然后 RLE 接手这些"已经聚拢"的数据,就能砍下相当一部分体积;最后熵编码对 RLE 输出做最终压缩。bzip2 的核心流水线就和这条路径非常接近——BWT 把同类字符聚到一起,再用 MTF(Move-To-Front)把小整数暴露出来,再交给熵编码。
这两条路径里,RLE 都扮演"粗筛 + 整形"的角色:不指望它单挑全场,但它是把数据"喂"给后续更贵算法前的预处理。
RLE 的局限:为什么需要后续算法
RLE 的局限来自它的"只看连续"假设。常见反例:
重复片段不连续。一段代码里同样的函数名在不同行出现多次,中间隔着别的字符;一份文档里某些常用词反复出现,但都隔着其它字。RLE 对这种"分散重复"完全无能为力——它是局部视野,只看相邻字节。要处理这种场景,需要字典编码这种"滑动窗口 + 长距离匹配"的能力。
数据本身已接近最大熵。JPEG、PNG、MP3 这些已经压缩过的数据,字节分布几乎是均匀的,既没有连续重复,也没有可识别的统计模式。RLE 在这种数据上不仅压不动,甚至会产生开销(每个 RLE 单元需要至少一个额外的"长度"字段,数据无重复时反而变大)。这也是为什么 RLE 几乎从不出现在视频/音频压缩流程里——媒体数据在编解码器内部已经达到局部最优。
要解决这两类局限,就得换工具:字典编码处理分散重复,熵编码处理统计冗余,变换算法(BWT、分形压缩)处理结构冗余。RLE 只是压缩工具箱里的一把,不是整个工具箱。
小结:RLE 的位置
RLE 是压缩流水线里最简单、最便宜的一道预处理。它不复杂、不花算力,但只在"重复连续"这一一种场景下发挥作用。在传真、位图、稀疏数据、长串同字节的场景里,RLE 几乎能"白嫖"一遍;在视频、音频、JPEG 这类已压缩数据上,RLE 反而是负优化。
理解 RLE 的价值,不在于知道它能压多少,而在于知道它在压缩工具箱里的位置——它和字典编码、熵编码、BWT 是分工关系,不是替代关系。一份数据通常需要多个步骤接力,才能压到工程上可接受的比例。RLE 是其中最先上场、也最容易理解的那一步。