RLE压缩算法实战：从原理到代码实现

1. 初识RLE：一个“数数”的压缩算法

大家好，我是老张，在数据存储和传输这块摸爬滚打了十几年。今天想和大家聊聊一个特别“古老”但又极其经典的压缩算法——RLE。你可能没听过它的全名“游程编码”，但你肯定在不知不觉中用过它。想象一下，你小时候画画，画了一长串一模一样的小红花，老师让你描述这幅画，你会怎么说？你肯定不会说“一朵红花、一朵红花、一朵红花……”说上十遍，你大概率会说：“这里有十朵一样的小红花”。看，你已经掌握了RLE算法的精髓：用“数量+数据”来代替一连串重复的数据。

RLE的全称是Run-Length Encoding，翻译过来就是“游程编码”或“行程长度编码”。这个名字听起来有点学术，但它的思想简单到令人发指。它的核心任务就是“数数”。当它扫描数据时，比如一串字符“AAAAABBBCCCCCC”，它不会老老实实地把这13个字母都存下来，而是会记录成“5A3B6C”。这里的“5”、“3”、“6”就是计数器，代表后面这个字符连续出现了多少次。这样一来，原本需要13个字节存储的信息，现在可能只需要6个字节（假设计数和字符各占1字节），压缩效果立竿见影。

我第一次接触RLE是在处理早期的黑白传真图像时。那时候的传真机，一张纸上的内容大部分不是黑就是白，而且经常是大片大片的连续黑色或白色。用RLE来压缩这种图像数据简直是天作之合。比如一行像素是“黑黑黑黑白白白白黑”，用RLE编码可能就是“4黑4白1黑”。这种算法无损的，意味着你压缩后再解压，数据会和原来一模一样，一个像素都不会差。而且它的压缩和解压速度极快，因为算法逻辑就是简单的计数和复制，几乎没有复杂的计算。这对于实时性要求高、或者硬件资源有限的场景（比如早期的游戏机、简单的嵌入式设备）来说，是巨大的优势。

当然，RLE也不是万能的。它的命门就在于数据的“重复性”。如果给你一段毫无规律、完全不重复的文本，比如“ABCDEFG”，RLE会怎么处理？它会老老实实地编码成“1A1B1C1D1E1F1G”。好家伙，原来7个字节，现在变成了14个字节，体积直接翻倍！这就是RLE最尴尬的地方：对于重复性差的数据，它不但不能压缩，反而会导致数据膨胀。所以，在使用RLE之前，你得先掂量一下你的数据是不是那种“扎堆出现”的类型。

2. 庖丁解牛：RLE的工作原理与两种编码模式

理解了RLE“数数”的基本思想后，我们得深入它的内部，看看它具体是怎么工作的。这就像学做菜，知道了要“炒”，还得明白是猛火快炒还是文火慢炖。RLE在具体实现时，主要有两种编码思路，我习惯把它们叫做“计数模式”和“转义模式”。这两种模式没有绝对的好坏，主要看你的数据更适合哪一种。

第一种，也是最直观的，就是计数模式。我们上面举的例子“AAAAABBBCC” -> “5A3B2C”就是典型的计数模式。它用一个字节（假设是1字节）来存储重复次数，紧接着下一个字节存储重复的数据本身。这种模式实现起来超级简单，解析也快。但它有个隐含的限制：计数器的范围。如果你用1个字节（8位）存储计数，那它最大只能表示255。也就是说，一段数据如果连续重复了300次，你得把它拆成“255次 + 45次”两段来编码。不过在很多实际场景里，比如256色位图，连续相同颜色像素超过255个的情况并不常见，所以1字节的计数器是够用的。

第二种，是转义模式。这种模式更适合处理那种“偶尔重复，大部分不重复”的混合型数据。它的规则稍微复杂一点：它会设定一个特殊的“转义字符”。当遇到连续重复的数据时，它先写入转义字符，然后写入重复次数，再写入重复的数据。当遇到不重复的单个数据时，就直接原样写入。但如果这个不重复的数据恰好等于转义字符本身怎么办？那就写入两个转义字符来表示“这是一个真正的转义字符数据，不是转义标记”。这种模式的优点是灵活性更高，能更好地处理非重复数据，避免数据膨胀。但缺点是多了一个转义字符的判断逻辑，编解码稍复杂一点。

为了让你更直观地感受这两种模式的区别，我们来看一个表格对比：