Question

在通过线路发送数据包之前，压缩数据包的最佳压缩算法是什么？数据包使用JSON编码。 LZW会是一个好的还是有更好的东西？

Answer 1

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

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的容器的问题相当简单，我认为可以留作“读者练习”，正如他们所说的那样。。）

Answer 2

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

Answer 3

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

Answer 4

让网络服务器压缩，浏览器本地解压缩; gzip或deflate。

Answer 5

这是一个关于JSON数据可压缩性的简短测试原文：crime-data_geojson.json 72844By （您可以在此处获取文件：https://github.com/lsauer/Data-Hub。该文件是随机选取的，但无法代表平均JSON数据）

除了zip之外，所有归档参数都设置为超

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

Answer 6

Gzip（deflate算法）非常擅长压缩，虽然像所有好的压缩算法一样，使用了大量的cpu（在我的测试中，json读取/写入的开销是3-5倍）。

Answer 7

我发现压缩算法比选择替代格式更有效。如果这是“实时”压缩，我建议您研究一个较低级别的Brotli或Zstandard压缩器（较高级别的压缩器会占用大量CPU，但确实会提供很好的压缩率）。

如果您想了解所有替代方案以及我如何得出该结论，请参见on the Lucidchart techblog。

JSON编码包的压缩算法？

7 个答案: