从逻辑上理解压缩算法答案

【问题标题】：logically Understanding a compression algorithm从逻辑上理解压缩算法
【发布时间】：2015-11-26 00:49:16
【问题描述】：

这个想法已经在我脑海中流动了 3 年，但我在应用它时遇到了问题我想创建一个压缩算法，将文件大小减半

例如8 mb 到 4 mb

凭借一些搜索和编程经验，我理解了以下内容。
让我们获取一个带有字母 (a,b,c,d) 的 .txt 文件

使用IO.File.ReadAllBytes 函数，它给出以下字节数组：(97 | 98 | 99 | 100)，据此：https://en.wikipedia.org/wiki/ASCII#ASCII_control_code_chart 是字母的十进制值。

我想到的是：如何通过将每个 2 个成员组合成一个成员，在数学上将这个 4 成员数组切割成只有 2 个成员的数组，但你不能简单地在数学上组合两个数字并简单地将它们反转回来因为你有很多可能性，例如
80 | 90 : 90+80=170 但没有办法知道 170 是 80+90 的结果，而不是 100+70 或 110+60。
即使你能克服这个问题，你也会受到数组单个成员中字节最大值（255 个字节）的限制。

我知道大多数压缩算法都使用二进制压缩并且它们是成功的，但是想象一下将文件大小减少一半，我想听听您对此的想法。

最好的问候。

【问题讨论】：

看看Huffman Coding。压缩的基本要点是您将80 | 90 组合替换为某种占位符。解码时，在表格中查找占位符并获取原始字节。
我知道霍夫曼，但它无法达到我的目标（半尺寸压缩）我需要一种更简单的方法来组合 0~255 范围内的数字
你能告诉我们你的数据集中有多少个A | B字节组合吗？
实际上没有数据集，这只是一个示例，我只有一个 97 的数组 | 98 | 99 | 100 原来是 abcd
“将文件大小减半”是什么意思？什么样的文件（如果你允许任何文件，你可以一次又一次地压缩结果，最终得到一个 0 字节的文件——这是不现实的）。如果文件中包含的信息小于文件占用的磁盘空间（在霍夫曼编码中表示为“熵”），则只能压缩文件。因此，如果文件确实占用了所需空间的两倍，则只能将文件压缩到其原始大小的 50%。

标签： arrays algorithm io

【解决方案1】：

不可能制定一种压缩算法来缩短每个文件。证明称为“计数论证”，很简单：

长度为 L 的文件有 256^L 个。

假设有 N(L) 个长度为

如果你算一下，你会发现 256^L = 255*N(L)+1

所以。您显然不能压缩每个长度为 L 的文件，因为没有足够短的文件来唯一地保存它们。如果您制作的压缩器总是缩短长度为 L 的文件，那么许多文件将不得不压缩为相同的较短文件，当然您只能在解压缩时恢复其中的一个。

事实上，长度为 L 的文件数量是较短文件的 255 倍以上，因此您甚至无法压缩 大多数 长度为 L 的文件。只有一小部分比例实际上可以变短。

comp.compression FAQ 中（再次）很好地解释了这一点： http://www.faqs.org/faqs/compression-faq/part1/section-8.html

编辑：所以也许你现在想知道这个压缩的东西是关于什么的......

嗯，绝大多数“所有可能的长度为 L 的文件”都是随机垃圾。无损数据压缩通过将较短的表示（输出文件）分配给我们实际使用的文件来工作。

例如，霍夫曼编码逐个字符地工作，并且使用更少的位来编写最常见的字符。例如，“e”比“q”更频繁地出现在文本中，因此它可能只花费 3 位来写“e”，但 7 位来写“q”。几乎从未出现过的字节，例如字符 131 可能用 9 位或 10 位写入 - 比它们来自的 8 位字节长。平均而言，您可以通过这种方式将简单的英文文本压缩近一半。

LZ 和类似的压缩器（如 PKZIP 等）会记住文件中出现的所有字符串，并将较短的编码分配给已经出现的字符串，并将较长的编码分配给尚未看到的字符串。这会更好，因为它考虑了有关每个编码字符的上下文的更多信息。平均而言，写“boy”比写“boe”需要更少的位数，因为“boy”出现的频率更高，尽管“e”比“y”更常见。

因为这完全是关于预测您实际使用的文件的特征，所以这有点像魔法，而且不同类型的压缩器在不同类型的数据上工作得更好或更差——这就是为什么有这么多不同的算法。

【讨论】：