JSON 压缩后的文件尺寸较大

JSON 压缩后文件尺寸增大的问题引发了对于压缩算法在处理小数据时的有效性的讨论。使用 gzip 压缩工具时，添加的标头和对数据的修改可能会导致压缩后的数据比原始数据更大。因此，对于不断处理小数据的情况，使用压缩库可能不是最佳选择。

我会尽力解决我的问题。

myjson 是一个简单的 json 字符串。 len(myjson) = 78

e 是 json.marshal(myjson)

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

然后我像这样压缩e：

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

并且 buf.len() = 96

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

编辑：当有人试图理解为什么会发生某些事情时，巨魔会否决一个问题，这很搞笑。我想我应该盲目地接受而不是询问。

解决方案

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

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

Go gzip 包参考：

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

RFC1952

gzip 格式和标头：

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

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

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

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

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

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JSON 压缩后的文件尺寸较大》文章吧，也可关注golang学习网公众号了解相关技术文章。