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

时间:2019-07-12 14:07:18

标签: json go gzip

我会尽力解决我的问题。

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

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

编辑:当某人试图了解为什么正在发生某些事情时,将这些问题投下一个问题是很有趣的。猜猜我应该盲目接受它,而不要问。

2 个答案:

答案 0 :(得分:7)

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

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

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

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

答案 1 :(得分:2)

gzip 将添加标头,并对原始数据进行一些更改。在这种情况下,原始数据确实很小,无法保证压缩数据会小于原始数据。

因此,如果您的程序将不断处理此类小数据。使用压缩库压缩数据可能不是一个好主意。有时,如果数据一直很小,我们会将数据序列化为二进制流

转到gzip软件包参考:

  

软件包gzip实现对压缩的gzip格式的读写   文件,如RFC 1952中所述。

RFC1952

gzip格式和标题:

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