应用程序级数据压缩的优点？

Question

这个问题是受MessagePack启发的，但我正在寻找一个关于应用程序内压缩相对于外部压缩的优势的一般答案。

对于网络I/O，传输协议(至少是可选的)不是提供某种压缩吗？如果是的话，是什么使应用程序内的压缩更好呢？

对于文件存储，是什么使应用程序内的压缩比外部压缩(压缩等)更好？

我的猜测是，应用程序内压缩具有更多关于正在压缩的内容的上下文信息，因此在速度和/或压缩因子方面可能表现得更好。显然我的理解有点模糊。还有比这更重要的吗？

Answer 1

在理想的系统中(阅读:编程精良)，特定比通用更有效，但泛型更广泛适用。使用泛型可以节省开发时间，也可以使用特定的方法节省用户时间。

图像就是一个很好的例子。如果您在没有内置压缩的位图上使用TCP的gzip压缩，那么您将应用一个纯粹的通用解决方案。它将寻找能够在较少的数据中复制的模式。例如，1000像素的纯白色可以从3000 0 0xFF字节更改为几个字节，例如“复制字节”的指令，然后是计数"3000“和值"0xFF”。(gzip比这个要复杂得多，但是您可以得到gist)，但是它不会注意到一个100x1000矩形的白色可以用一个指令代替；它需要100个指令，每次它到达流中的3000块0xFF时。

另一方面，如果您使用一个JPG，它内置了压缩，它知道这是一个图像。它可以识别那些规则的块，它知道它可以在特定的区域进行剪短，而人类的眼睛不会注意到这一点。如果有几个像素稍微偏离颜色，人们就不会注意到，但是机器可以把它安装成一个模式，从而使它更加压缩。

但是如果你试图将这种压缩应用于二进制数据，它会破坏它。

或者，如果您使用无损图像压缩类型，比如PNG，它将拥有所有的图像理论来识别它可以减少图像大小的方法。虽然您可以将此应用于常规数据而不会损坏，但由于它所寻找的模式对数据中的模式都是错误的，所以它的用处将大大降低。

在此基础上，还可以找到模式中的模式，使其更小。

MessagePack在gzip上的主要优势(粗略地看一下)是，它消除了结束元素(即结尾引号、结尾括号、逗号)，将json的语法开销减半，代价是降低了它的可读性和人工可编辑性。Gzip不能这么做。

它似乎没有压缩实际的数据，这是gzip擅长的，所以您应该使用这两种压缩来相互补充。应用程序中的MessagePack之上的TCP中的Gzip。

但是，有可能(我不知道，您需要测试它)，gzip可以比MessagePack生成的模式更好地处理常规json中的模式，因此可以产生更小的大小。不过，我觉得这是值得怀疑的，因为gzip更适合通用二进制，而不是专门针对文本。