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

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

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

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

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

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

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

--然后，您可能会通过创建一个文本字符串的硬编码字典来获得最佳压缩，该字典会一直显示在您的数据中，并用适当的字典索引替换其中一个文本字符串的每次出现。（实际上，如果您的数据是这常规的，您可能希望通过线路发送只是值，并在需要JSON对象的情况下，将函数写入客户机以从值构造JSON对象。）

如果无法预测将使用哪个标题，则可能需要使用LZW或LZ77，或另一种方法查看已通过的数据，以找到可以以特别紧凑的形式表示的数据。然而

2） 数据包是否需要单独压缩？如果是这样，那么LZW肯定是而不是您想要的方法；它将没有时间将其字典构建到在单个数据包结束时提供大量压缩结果的大小。在这种情况下，IMHO获得真正实质性压缩的唯一机会是使用硬编码字典

---

（以上所有内容的补充：正如Michael Kohne所指出的，发送JSON意味着你可能正在发送所有文本，这意味着你没有充分利用带宽，而带宽可以发送比你使用的范围更广的字符。然而，如何将0-127范围内的字符打包到你需要的容器中的问题是d值0-255相当简单，我认为可以作为“读者的练习”，正如他们所说。）

Gzip（deflate算法）非常擅长压缩，尽管像所有好的压缩算法一样，使用大量cpu（相当于我测试时json读写开销的3-5倍）.

还有两种JSON压缩算法：

---

HPack做得非常好，与gzip压缩相当。

这里是一个关于JSON数据可压缩性的简短测试 原件：crime-data_geojson.json 72844By （您可以在此处获取文件：。该文件是随机选取的，但不能代表平均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）

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

---

如果您想了解所有备选方案以及我是如何得出该结论的，可以找到完整的详细信息。

它不是一个web服务器。客户端是一个Flash程序。例如，在上面的示例中，以SOA而不是AOS格式存储会大大减少数据。我发现，在很多情况下，这是一种很好的“压缩”方法，但它取决于sp如果SOA是合适的，请指定应用程序。2中的建议令人困惑-即使每个数据包都很大，LZW仍然不是正确的方法吗？如果数据包不需要单独压缩怎么办？关于将0-255打包成0-127的任何详细信息或链接都会有帮助。它将0-127打包成0-255，而不是相反。ASCII使用8位byt是，但标准文本的字符仅使用较低的7位；其他128个字符（将最高位设置为1）是控制字符。要打包字符，您需要每8个字符，并将其7个数据位分成前7个字符中未使用的“高位”。“那么你可能应该选择一个不全是文本的有线协议”例如（+1，如果你说出两个或更多；-）@tobsen，但是，整个web使用HTTP由来已久，从来没有出现过问题（正在工作）。此外，关于文本与二进制…将Windows注册表与所有文本的Linux方法进行比较，并告诉我哪种方法更快…文本并不意味着慢。@CamiloMartin我认为“在线协议”和“在线格式”在这里混在一起。我在搜索有线格式的替代方案，如ASN1、XDR、ProtocolBuffers（其他？）而不是wire protocols“.JSON不是协议。@tobsen啊，是的。但是SOAP可以被称为协议，对吗？所以JSON版本可以。我想这也是回答者所说的“协议”的意思。我不是唯一一个知道NanoZip的人！+1:D（但我永远不会在wire上使用它lol）我不知道算法，但可能这个项目与你类似