RLE 算法有缺陷吗？

Question

我正在查看最近的Code Golf 删除字符串中的重复字符。我仔细考虑了一下，认为 RLE 算法会解决它，事实上，我确实相信这会解决删除重复问题，我在这里用 C 编写了一个实现，看看我能走多远

char *rle(const char *src){ 字符 *p=(字符 *)src; 字符 *q=(字符 *)src+1; char *rle_enc=NULL, *tmp_rle, buf[10]; 诠释运行=1； 而 (*p){ 而(*q){ 如果 (*p==*q++) 运行++,p++; } sprintf(buf,"%d%c",运行,*(p-1)); p++; 如果（！rle_enc）{ 如果 ((rle_enc=malloc(strlen(buf)+1))!=NULL){ strcpy(rle_enc,buf); } }别的{ 如果 ((tmp_rle=realloc(rle_enc,(strlen(rle_enc)+strlen(buf)+1)))!=NULL){ rle_enc=tmp_rle; strcat(rle_enc,buf); } } q=(p+1); 运行=1； } 返回 rle_enc; }

果然，这里是主要的：

int main(int argc, char **argv){ char *test1 = "HHHHHHeeeeeellllloooooooo"; 字符 *test2 = "nbHHkRvrXbvkn"; 字符 *p = rle(test1); printf("s = %s\n", test1); printf("p = %s\n", p); 如果（p）免费（p）； 返回0； }

根据 meta 上的Code Golf，它应该是可重用的并解决了一系列问题，但在最短的字符集中，我认为我只需将变量更改为 1 个字母并压缩代码即可它很小..但有些地方不太对劲，因为这让我想到了 RLE 算法本身，这是Wikipedia 上的一个页面，关于它要说的内容和 Java 中的实现。

代码似乎在做它应该做的事情，所以我想，现在，只需检查来自rle 的编码字符串结果，寻找那些后面有一个字母的 1..

不过我确实注意到了 RLE 算法的局限性，它只适用于那些具有一组相邻的重复字符的算法。但是它没有通过 Code Golf 的测试用例，看起来很简单，这让我想到了这个问题：

RLE 算法有缺陷吗？现在会用在什么地方？我认为由于 RLE 周围流动的大量数据和信息不再适合目的，因此收集灰尘......

编辑：感谢 Moonshadow、John 和 Steve 发布他们的答案。

有一个基本的教训我仍然没有学到 - 永远不要去 OTT 并在涉及到这种事情时想得复杂，这对我来说是一个谬误，并显示出大的想法会阻碍你而且我会被它吸得太深，不看正确的角度就被冲昏了头脑！！！！！！！再次感谢！ :)

Answer 1

RLE 通常用于 8 位位图，因为它们通常具有相同字符的长时间运行。 Windows 仍然支持以类似方式使用的 RLE 视频编解码器。如今，LZW + Huffman 编码已取代 RLE，成为“简单”的压缩算法。

RLE 已经使用多年，因此我们很难说它“有缺陷”，但它肯定效率不高。

大多数 RLE 格式都会有一个“转义字符”，因此不会对输出造成混淆。

例如，如果我们使用“e”作为转义字符...

这将产生一个字面意思的“e”：

ee

这将是字母“a”重复两次：

ea2

Answer 2

RLE 不会为您解决代码高尔夫问题。

代码高尔夫问题要求您删除在输入中多次出现的所有字符，无论出现在哪里。然而，RLE，“运行长度编码”，编码“运行”——相同字符的重复序列；同一个字符可以多次运行在一个字符串中，而 RLE 会根据设计对它们分别进行编码。

RLE 旨在更紧凑地对重复数据元素的序列进行编码，方法是将序列替换为仅一个元素，后跟其重复次数。为此目的，它是完全足够的。任何“缺陷”都不在于算法，而在于将其用于不适合的目的的决定。

Answer 3

为什么你认为它有缺陷？ RLE 用于压缩重复字符。它不打算做任何其他事情，并且不会帮助压缩没有运行长度 > 1 的数据。

在这个问题的背景下，我会说 RLE 不是正确的答案，它没有缺陷，只是在这种情况下没有帮助。