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

Question

在通过网络发送数据包之前压缩数据包的最佳压缩算法是什么？数据包使用JSON编码。 LZW会是一个不错的选择吗？还是有更好的选择？

Answer 1

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

1）在不知道程序的任何特定运行情况下会如何预测数据的组成情况？例如，如果您的数据包如下所示：

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

-然后，您可能会通过创建一个不断出现在数据中的文本字符串的硬编码字典来获得最佳压缩，并用适当的字典索引替换每个出现的文本字符串之一。 （实际上，如果您的数据是this常规数据，则您可能想通过电线发送just值，并简单地将一个函数写入客户端以根据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或放气。

Answer 5

这里是对JSON数据可压缩性的简短测试原始：Crime-data_geojson.json 72844（您可以在这里获取文件：https://github.com/lsauer/Data-Hub。该文件是随机选择的，但不能代表平均JSON数据）

Answer 6

Gzip（压缩算法）在压缩方面相当出色，尽管像所有好的压缩算法一样，使用了大量的cpu（在我的测试中是json读写开销的3-5倍。]

Answer 7

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