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

Posted 2023-03-14

【中文标题】JSON编码数据包的压缩算法？

【英文标题】：Compression algorithm for JSON encoded packets?

【发布时间】：2010-09-28 13:44:43

【问题描述】：

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

【问题讨论】：

我不知道算法，但也许这个项目和你很相似github.com/rgcl/jsonpack

【参考方案1】：

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

【讨论】：

" 那么你可能应该选择一个不全是文本的有线协议“例如？ （如果您说出两个或更多，+1 ;-)

@tobsen TCP, IP, UDP?但是，整个网络自古以来就使用 HTTP 并且从未出现过问题（SPDY 正在开发中）。

另外，关于文本与二进制……比较 Windows 注册表和 Linux 的全文本方法，告诉我哪个更快……文本并不意味着慢。

@CamiloMartin 我认为“在线协议”和“有线格式”在这里混淆了。我正在寻找有线格式替代品，如 ASN1、XDR、ProtocolBuffers（其他？）而不是“有线协议”。 JSON 不是协议。

@tobsen 啊，是的。但是 SOAP 可以称为协议，对吗？所以 JSON 版本会。我想这也是回答者所说的“协议”的意思。

【参考方案2】：

让webserver压缩，浏览器原生解压； gzip 或放气。

【讨论】：

它不是网络服务器。客户端是一个 Flash 程序。

【参考方案3】：

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

1) 在不知道程序的任何特定运行会发生什么的情况下，您能在多大程度上预测数据的组成？例如，如果您的数据包如下所示：

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

-- 那么您可能会通过创建一个硬编码的文本字符串字典来获得最佳压缩，这些文本字符串会不断出现在您的数据中，并用适当的字典索引替换每个文本字符串的出现。 （实际上，如果您的数据是 this 常规数据，您可能希望通过网络发送 just 值，然后只需将函数写入客户端以构造 JSON 对象如果需要 JSON 对象，则从值中获取。）

如果你无法预测哪些 headers会被使用，你可能需要使用LZW，或者LZ77，或者其他查看已经经过的数据的方法来找到它可以表达的数据以特别紧凑的形式。不过……

2) 数据包是否需要彼此分开压缩？如果是这样，那么 LZW 绝对是不是您想要的方法；它将没有时间将其字典构建到在单个数据包结束时会产生大量压缩结果的大小。恕我直言，在这种情况下获得真正大幅压缩的唯一机会是使用硬编码字典。

（以上所有内容的附录：正如 Michael Kohne 指出的那样，发送 JSON 意味着您可能正在发送所有文本，这意味着您未充分利用能够发送比您更广泛的字符范围的带宽' 正在使用。但是，如何将 0-127 范围内的字符打包到包含 0-255 值的容器中的问题相当简单，我认为可以作为“读者练习”，正如他们所说.)

【讨论】：

对于上面的示例，以 SOA 而非 AOS 格式存储会大大减少数据。我发现在很多情况下这是一个很好的“压缩”方法，但它取决于特定的应用程序是否适合 SOA。

2 中的建议令人困惑——即使每个数据包都很大，LZW 仍然不是正确的方法吗？如果数据包不需要单独压缩怎么办？此外，有关将 0-255 打包成 0-127 的任何详细信息或链接都会有所帮助

它将 0-127 打包成 0-255，而不是相反。 ASCII 使用 8 位字节，而标准文本的字符只使用低 7 位；将最高位设置为 1 的其他 128 个字符是控制字符。要打包字符，您需要每隔 8 个字符将其 7 个数据位划分为前 7 个字符中未使用的“高位”。

【参考方案4】：

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

【参考方案5】：

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

【参考方案6】：

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

除了 zip，所有归档器参数都设置为 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 bits per 字母，[1] 或低至每个字母 0.6 到 1.3 位，根据 Shannon 基于人体实验的估计

JSON 数据的熵通常远高于此值。 （在使用 10 个大小大致相等的任意 JSON 文件的实验中，我计算出 2.36）

【讨论】：

我不是唯一知道 NanoZip 的人！ +1：D（但我永远不会在电线上使用它哈哈）

【参考方案7】：

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

如果您想了解所有替代方案以及我是如何得出这个结论的，可以在on the Lucidchart techblog 找到完整的详细信息。