压缩的JSON大于未压缩的版本

Question

我会尽力解决我的问题。

myJSON是一个简单的JSON字符串。 len(myJSON)= 78

e是 json.Marshal(myJSON)

据我了解，e现在是 []byte

然后我像这样压缩：

var buf bytes.Buffer
gz := gzip.NewWriter(&buf)
gz.Write(e)
gz.Close()

和buf.Len()= 96

那么...为什么我的压缩缓冲区比原始的非压缩字符串大？

编辑：当某人试图了解为什么正在发生某事时，投下一个问题的巨魔很搞笑。猜猜我应该盲目接受它，而不要问。

Answer 1

设计一个无损压缩算法以减小每个输入文档的大小在物理上是不可能的。

作为一个思想实验，想象一下存在这样一种压缩器，并且可以将任何文档压缩至少一位。

现在让我们说，我生成的每个文档最长为N位。即长度为1的1个文档，长度为1的2个文档，长度为2的4个文档，依此类推。此序列计算出的2^(N+1)-1文档总数。

如果我们通过压缩程序运行所有文档，则压缩版本的长度最多为N-1位。这意味着最多只能有2^N-1压缩的文档，这比我们开始时要少。要么压缩系统有损（在这种情况下，解压缩不一定会为我们提供原始文档），要么某些文件在压缩时必须增大大小。

古老的说法是：如果您可以创建一种无损算法，可以将每个输入至少减少1位，并重复足够的次数（在前一次运行的输出上），则可以将整个Internet压缩到一个位... (3认同)

Answer 2

gzip将添加一个标题并对原始数据进行一些更改。对于这种情况，原始数据确实很小，它不能保证压缩后的数据会小于原始数据。

所以如果你的程序会不断地处理这样的小数据。压缩数据使用压缩库可能不是一个好主意。有时我们将数据序列化为二进制流，以应对数据一直很小的情况。

去 gzip 包参考：

包 gzip 实现了 gzip 格式压缩文件的读取和写入，如 RFC 1952 中所指定。

gzip 格式和标题：

http://www.onicos.com/staff/iz/formats/gzip.html