1. 首页
  2. 问答
  3. JSON编码数据包的压缩算法？

JSON编码数据包的压缩算法？

2008-12-27 95 views

回答

9

我想两个问题会影响您的回答：

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的问题相当简单，我认为它可以作为“读者的练习”，因为它们）

来源

2008-12-28 01:29:45 afeldspar

2

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

来源

2008-12-27 22:26:59

+4

“那么你可能应该选择一个不是全部文本” 例如？ （如果您指定两个或两个以上，则为+1 ;-) – tobsen 2010-01-18 10:48:27

+0

@tobsen [TCP]（http://tools.ietf.org/html/rfc793），[IP]（http://tools.ietf.org/html/ rfc791），[UDP]（http://tools.ietf.org/html/rfc768）？但是，整个网络仍然使用HTTP，并且从未出现问题（[SPDY]（http://www.chromium.org/spdy/spdy-whitepaper/）正在进行中）。 – 2012-07-27 03:29:45

+0

此外，关于文本与二进制文件...将Windows注册表与全文的Linux方法进行比较，并告诉我哪个更快......文本并不意味着缓慢。 – 2012-07-27 03:31:28

2

让网页服务器自动压缩并浏览器解压; gzip或deflate。

来源

2008-12-27 22:30:50 Mat

0

Gzip（deflate算法）在压缩方面非常出色，尽管像所有优秀的压缩算法一样，它使用了大量的cpu（3-5倍于在我的测试中读取/写入json的开销）。

来源

2009-05-07 06:21:19 StaxMan

5

还有两种JSON压缩算法：CJson & HPack HPack做得非常好，与gzip压缩相当。

来源

2011-08-30 08:54:12

2

这里是JSON数据的压缩短的测试 原：犯罪data_geojson.json 72844By （你可以在这里的文件：https://github.com/lsauer/Data-Hub。该文件是随机挑选，但不能代表平均JSON数据）

除了压缩所有存档参数设置为超

* 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）

来源

2011-09-24 20:26:35

相关问题

 相关问题