是否有比JSON/BSON更精简的Javascript对象表示法格式？

对于占用空间比JSON小得多的简单Javascript对象树，有什么好的序列化/反序列化格式吗？BSON不是很令人印象深刻

---

JSON中的冗余开销对于许多对象共享同一组属性的树尤其重要。理论上，应该可以在对象数组中检测模式，这样属性名就不会重复

您可以将JSON转换成更多的“数据库”格式，然后将其转换回常规对象。结果有时是值得的

// Typed on the fly
var dict = [
  ["FirstName", "LastName"],
  ["Ken",       "Starr"],
  ["Kermit",    "Frog"]
];

然后您可以循环字典，如下所示：

// Again, typed on the fly
var headers = dict[0];
var result = []
var o;
for (var i = 0 + 1; i < dict.length; i++) {
  o = {}
  for (j = 0; j < headers.length; j++) {
    o[headers[j]] = dict[i][j];
  }
  result.push(o);
}

[{"value-a":0,"value-b":0,"value-c":0},{"value-a":1,"value-b":1,"value-c":1} /* etc. */]

{"index":{"value-a":0,"value-b":1,"value-c":2},"rows":[[0,0,0],[1,1,1] /* etc. */ ]}

//又一次，快速输入
var headers=dict[0]；
var结果=[]
var o；
对于（变量i=0+1；i

有非常快速的压缩库。因此，压缩格式并不一定比不太紧凑的格式加上压缩要好

我手头没有链接，但我认为一位前protobuf设计师推荐了这种方法

退房。它是一种相当紧凑的二进制格式，其语义与JSON或BSON非常相似

短数组（最多16个元素）、映射（最多16对）和字符串（最多32个字节）具有单字节开销。小整数（-32到128）只占一个字节的总数

Gzip很快。非常快。我非常有信心，这是精益运输的最佳解决方案（从实用性和效率两方面来说）

为了说明这一点，我在我的一个临时站点上构建了一个快速示例

生成5k行简单数据，并输出原始的、未着色的JSON

$data = array();
for ($i = 0; $i < 5000; $i++) {
    $data[] = array(
        'value-a' => $i,
        'value-b' => pow($i,2),
        'value-c' => pow($i,3)
    );
}

print json_encode($data);

另一种格式是生成相同的5k行简单数据，但将数据重组为更高效的索引JSON序列化

$data = array();
for ($i = 0; $i < 5000; $i++) {
    $data[] = array(
        'value-a' => $i,
        'value-b' => pow($i,2),
        'value-c' => pow($i,3)
    );
}

$out_index = array();
$out = array();

foreach ($data as $row) {
    $new_row = array();
    foreach ($row as $k => $v) {
        if (!isset($out_index[$k])) {
            $out_index[$k] = sizeof($out_index);
        }
        $new_row[$out_index[$k]] = $v;
    }
    $out[] = $new_row;
}

print json_encode(array(
    'index' => $out_index,
    'rows' => $out
));

因此，在我们相当简单的示例中，原始的、重构的数据比原始数据小50%以上。但是，当gzipped时，它只比gzipped小9%。在这种情况下，成本是总请求时间增加44%

如果您编写一个二进制库来重组数据，我希望您可以显著减少44%。但是，这仍然不太可能值得。您需要它来序列化数据，而不需要比“正常”编码结构花费超过9%的时间才能看到任何增益

避免重构或“替代序列化”的唯一方法是从头到尾以笨拙的索引方式在服务器端处理所有对象。而且，除非你真的迫不及待地想从你的硬件中获得微不足道的性能，否则这真是一个糟糕的想法

在这两种情况下，gzip节省的空间远远超过了我们使用另一种JavaScript comptable格式所能实现的

（我们甚至没有考虑到客户端大小的解析——这对于任何非“正常”JSON或XML的东西都非常重要。）

总之

---

只需使用内置的序列化库和gzip。

您尝试过gzip JSON吗？@alex-它会消耗大量服务器CPU，因为数据不可缓存。我宁愿首先生成一个紧凑的表示。@PatriciaBrothers一般来说，压缩编译库的序列化要比在脚本中构建替代序列化快得多。尝试使用protobuf，它看起来有点难看，但一旦你学会了如何使用它，你就会看到它的好处，它在最常见的语言服务器端2中工作。您的

b

s指的是位还是字节？通常，当您引用字节时，应该使用大写。@CodesInChaos大小取自Chrome网络监视器。所以，我相信它们是以字节为单位的。@codesin混乱。。。谢谢你指出这个模棱两可的地方。我已经编辑了答案。你的数字很低，但如果不调查原因，就很难得出任何好的结论。@CodesInChaos我不会把结果当作福音。但是，它们确实说明了一个微不足道的记忆优势；即使不考虑时间成本（通过从头到尾使用更复杂的格式可以避免），这也可能使“聪明”解决方案的努力成为一项糟糕的投资。（我正在说明的一个被广泛接受的观点是，它很难与成熟的二进制库竞争。）MessagePack很有趣。但是，在缓存、日志记录等过程中，它的价值似乎更多地体现在服务器端节省空间上。。使用它的知名大公司（例如Pintrest）似乎仍然在使用标准JSON+gzip进行传输。（根据你的第一点，如果我理解正确的话。）如果这个答案包含一些数据，表明MessagePack是否比Gzip JSON产生更高的有效吞吐量，我可以给这个答案投赞成票。