代码之家 › 专栏 › 技术社区 › ryeguy

JSON编码包的压缩算法?

packet compression json

ryeguy · 技术社区 · 16 年前

在通过网络发送数据包之前,使用哪种压缩算法来压缩数据包?这些包是使用JSON编码的。LZW是一个很好的选择还是有更好的选择?

6 回复 | 直到 14 年前

afeldspar 16 年前

我认为有两个问题会影响你的答案:

1)在不知道在程序的任何特定运行中会发生什么情况的情况下,您如何预测数据的组成?例如,如果您的数据包如下所示:

{
    "vector": {
        "latitude": 16,
        "longitude": 18,
        "altitude": 20
    },
    "vector": {
        "latitude": -8,
        "longitude": 13,
        "altitude": -5
    },
    [... et cetera ...]
}

--然后,您可能会通过创建一个文本字符串的硬编码字典来获得最好的压缩效果,该字典会一直显示在您的数据中,并用适当的字典索引替换其中一个文本字符串的每次出现。(实际上,如果你的数据是这普通的,你可能想寄只是如果需要JSON对象,只需将值通过连线写入客户机,即可从这些值构造JSON对象。)

如果你不能预测 哪一个 将使用头文件,您可能需要使用lzw或lz77,或另一种方法,该方法查看已经通过的数据,以找到可以以特别紧凑的形式表示的数据。然而。。。

2)是否需要将数据包彼此分开压缩?如果是这样,那么LZW肯定是不您需要的方法;它将没有时间构建其字典,其大小将在单个数据包结束时给出实质性的压缩结果。在这种情况下,获得真正实质性压缩的唯一机会是使用硬编码字典。

(以上所有内容的附录:正如Michael Kohne指出的,发送JSON意味着你可能发送所有文本,这意味着你正在使用的带宽比你使用的字符范围要宽得多。但是,如何将0-127范围内的字符打包到保存值0-255的容器中的问题相当简单,我认为可以像他们所说的那样保留为“读者的练习”。

Alex Objelean 14 年前

还有两种JSON压缩算法: CJson & HPack 与gzip压缩相比,hpack做得非常好。

Michael Kohne 16 年前

嗯……如果我错了,请纠正我,但是如果您正在实现线压缩,那么您可以控制连接的两端,对吗?在这种情况下,如果JSON是一个过于胖的协议,为什么不选择一个不那么胖的不同的有线协议呢?我的意思是,我理解使用像JSON这样的标准的吸引力,但是如果您关心带宽,那么您可能应该选择一个不全是文本的有线协议。

Mat 16 年前

让Web服务器压缩,浏览器本机解压缩;gzip或deflate。

Lorenz Lo Sauer 14 年前

下面是一个关于JSON数据压缩性的简短测试原件:crime-data_geojson.json 72844by (您可以在此处获取文件: https://github.com/lsauer/Data-Hub . 该文件是随机选取的,但不能代表平均JSON数据)

除了zip之外,所有archiver参数都设置为ultra

* cm/ nanozip: 
  > 4076/72844
  [1] 0.05595519
* gzip:
  > 6611/72844
  [1] 0.09075559
* LZMA / 7zip
  > 5864/72844
  [1] 0.0805008
* Huffman / zip:
  > 7382/72844
  [1] 0.1013398
* ?/Arc:
  > 4739/72844
  [1] 0.06505683

这意味着压缩非常高而且有益。JSON数据通常具有较高的熵。根据维基百科

英语文本的熵率在1.0到1.5位之间。字母[1]或每个字母0.6到1.3位,根据香农基于人类实验的估计

JSON数据的熵通常远高于此。(在10个大小大致相等的任意JSON文件的实验中,我计算了2.36)

StaxMan 16 年前

gzip(deflate算法)非常擅长压缩,尽管和所有优秀的压缩算法一样,它使用大量的CPU(相当于测试中JSON读/写开销的3-5倍)。