压缩字典答案

【问题标题】：Compress a dictionary压缩字典
【发布时间】：2012-11-19 19:19:06
【问题描述】：

我正在使用 Pusher 将 JSON 文件发送到我的 web 应用程序。我的问题是 pusher 可以推送的大小限制为 10Kb，而我的 JSON 大约为 14-20Kb（精确到 1816 字节）。所以它返回一个错误 413。

我可以在我的应用程序中压缩这个 dict / JSON 并在 javascript 中解压缩它吗？我怎样才能做到这一点？我环顾四周，但找不到任何我能理解（我是初学者）或使用的东西。

我用 pusher 发送的字典示例。 http://pastebin.com/x2jkhqmr

谢谢！

【问题讨论】：

您的数据不是valid JSON，也不是JSON.parse()。例如，布尔文字是 true 和 false，而不是 True 和 False，并且 JSON 不支持 Python Unicode 字符串文字 u'…'。你需要先解决这个问题。
stackoverflow.com/questions/7887915/…
如果它是一个有效的 json，我可以压缩它以使其更小吗？
我用 Javascript 写了一个 gzip 压缩器，它非常慢。除非绝对必要，否则我不建议尝试在客户端上解压缩类似的东西。下载 gzip 库的开销很可能比压缩数据所获得的任何收益都要大。

标签： javascript pusher

【解决方案1】：

我不会尝试压缩您的数据，而是将其拆分并分成多个部分发送，每个部分小于 10K。
压缩有一个限制，而您可以根据需要发送尽可能多的数据块。

【讨论】：

AFAICS，将嵌套数据分成最大大小的块并不是一个简单的计算问题。
@PointedEars：...对于非常笼统的任意数据，不...在他的情况下，很容易。他正在尝试传输 13 个密钥，每个密钥的 json 表示形式约为 1410 个字节（给或取 10 个字节）。
恐怕你弄错了。我已经通过eval("(" + … + ")") 运行了数据的更正版本，这表明它是一个相当深的嵌套结构。例如，结果对象obj 中有一个路径obj["37828"].lineUp.Ba.captain。你能保证它总是可以按照你的建议拆分吗？
我没有弄错每个键的值的 json 表示有多大......并且嵌套级别无关紧要（我没有提到它）。我确实说过有 13 个键，每个键的 json 表示非常、非常接近彼此……就是这样。
最后我决定走那条路。我也修复了我的 JSON :)

【解决方案2】：

假设您的数据是 valid JSON（它不是），您可以使用以下代码的等效项从中删除不必要的空格：

data = data.replace(/('(?:[^\\']|\\.)*'|"(?:[^\\"]|\\.)*")|\s+/g, "$1");

这会将这 17'264 个字符减少到 15'141 个字符 (-12.3%)。

此外，您可以为您的 Web 应用程序定义一个约定，通过该约定您将布尔文字作为数字传输，例如 0 用于 false 和 1 用于 true：

data = data.replace(
  /('(?:[^\\']|\\.)*'|"(?:[^\\"]|\\.)*")|true|false/g,
  function (m, p1) {
    if (p1) return p1;
    return (m === "true") ? "1" : "0";
  });

这将使有效负载再减少 2'657 个字符 (-17.5%)。

删除不支持的（并且在 JSON 中是不必要的）u'…' 表示法已经从该数据中减少了 151 个字符：

data = data.replace(/u?('(?:[^\\']|\\.)*'|"(?:[^\\"]|\\.)*")/g, "$1");

（Python 有escape sequences for Unicode characters，例如\x12\x23…。如果出于某种原因你会使用它，如果你先解码，你可以将每个转义字符减少至少 3 个字符。ECMAScript 实现已经内置Unicode 支持已有十多年了。）

最后，您可以将小于 2⁵⁴−1 的整数字符串值作为数字 without loss of precision 传输，每个此类字符串删除两个字符（' 和 " 对）价值。

【讨论】：

试图更紧密地打包这些数据，希望它能够压缩到 10K 以下，这将导致未来失败。没有运行你的计算，但假设它今天设法挤进 10K 以下，只要他在未来添加另外几个键，它就会中断。
@Gerrat 我同意。需要重新考虑应用程序的通信模型，或者交换库，因为您对有效负载进行切片的方法也不能很好地扩展。这个答案显示了包装的可能性以及如何包装，因此相比之下它确实回答了这个问题。
“您的有效载荷切片方法也不能很好地扩展”？每个密钥约 1400 字节...每次传输打包 6 个密钥...这怎么不扩展？？？考虑到 1414 字节的平均大小和 7 字节的标准偏差，发送 6 个密钥/传输给每个数据无法工作的机会远低于百万分之一...尝试以您的方式更紧密地打包数据如果 OP 仅添加 5 个键，将在 100% 的情况下中断！
@Gerrat 显然你还没有考虑到这一点。 “记录”的大小现在很小。