Javascript JSON是否像xml一样过于冗余？

摘要：

在json格式中，我们有键值对。对于每个对象，重复相同的关键点。这不是裁员吗？可以将其更改为数据库表格式，其中第一行具有所有键，下一行表示具有值的对象

详细信息：

据说xml由于其结尾标记而更加冗长和冗余。因此，另一种选择是json。但我发现json太多余了。我发现的冗余是：

在每个对象实例中重复关键帧

每个键和值的名称都有不必要的双引号 对于2，我发现一个解释是，由于javascript不允许保留关键字，如

函数

，

if

，

else

作为键，而且Crockford先生希望json保持简单，所以他选择使用引号

问题1:为什么不让json解析器在数据到达客户端时添加引号，而不是在json数据中使用引号？例如，服务器应以以下方式发送数据：

[
    {
        product: car,
        price: 100
    }, 

    {
        product: bus,
        price: 1000
    }
]

json解析器应该在客户端将其转换为：

[
    {
        "product": "car",
        "price": "100"
    }, 

    {
        "product": "bus",
        "price": "1000"
    }
]

现在让我们谈谈第一点。假设我们在json中有以下数据：

[
    {
        "product": "car",
        "price": "100"
    }, 

    {
        "product": "bus",
        "price": "1000"
    },
    {
        "product": "Train",
        "price": "100000"
    }
]

这里，键

产品

重复了三次，键

价格

也重复了三次。在表数据库格式中，该数据如下所示：

+=========+===================+
| product |       price       |
+=========+===================+
|   car   |        100        |
+---------+-------------------+
|   bus   |        1000       |
+---------+-------------------+
|  train  |        100000     |
+---------+-------------------+

在表格格式中，

产品

和

价格

无重复。因此，这种格式必须是最佳格式。为了在json中实现这一点，我想出了以下方法：

表式数组：

+=-----------------------------------//用于将以下代码格式化

[
    ["product", "price"],
    ["car", "100"],
    ["bus", "1000"],
    ["train", "100000"]

]

我们有很多阵列。还有另一个改进：

所有键的单个数组和所有值的另一个单独数组：

+-=-------------//用于将以下代码格式化

[
    ["product", "price"],
    ["car", "bus", "train"],
    ["100", "1000", "100000"]
]

现在只有三个阵列。这是最理想的方法，可以稍加改进，使其更有意义：

{
    "product": ["car", "bus", "train"],
    "price": ["100", "1000", "100000"]
}

现在我们看到json中的冗余可以被删除

问题2:json确实是格式副本，格式可以进一步改进吗

我的想法是，在某些情况下，数据不会对每个对象具有相同的键，因此我的方法不适合它们。因此，开发人员需要根据实际需要重新格式化json。另一种想法是，当Gzip文件大小与原始json Gzip文件大小相同时，这可能是我的格式

---

问题3:如果一个json数据的所有对象都有相同的键，那么Gzip时的我的格式是否比原始json Gzip文件大小小

是的，有很多冗余

例如，“产品”可以替换为“1”，而“价格”可以替换为“2”。或者说，为什么要使用16位呢？如果只有两把钥匙，他们只需要一点

但你信息的全部基调是冗余是不好的。这不是一个公认的事实。冗余有很多好处，这就是为什么自然语言有这么多冗余

问题1:为什么不让json解析器在数据到达客户端时添加引号，而不是在json数据中使用引号

带引号的值用于（a）将值标识为字符串，以及（b）允许在字符串值中使用任何字符（包括逗号和转义引号）。特别是，结束引号限定了文本的结尾-如果它不存在，解析器将无法区分以下内容（其中每行表示一个键/值对）：

……或者

key1: hello,
world: hello, world,
key2: hello,
universe: hello, universe

如您所述，文本中的逗号可能需要转义才能绕过此问题：

key1: hello\, world: hello\, world,
key2: hello\, universe: hello\, universe

但正如您所提到的，逗号在文本中比引用标记更普遍，因此这可能具有增加大小的整体效果（例如，考虑JSON值是莎士比亚的完整作品），也会违背现有语言中使用的现有约定。

其他可能的冗余？

一个理论上的小冗余是JSON字符串值的起始引号：如果没有它，解析器仍然拥有解释键和值所需的所有信息。但移除它们看起来很奇怪：

"key1": a string value",
"key2": \"I really don't like this!\""

问题2:json确实是格式副本，格式可以进一步改进吗

这个问题的答案取决于“改进”的含义。JSON并不是为了使用尽可能少的字符数来表示数据而设计的：在简洁性和人类可读性之间取得了平衡，后者非常重要

问题3:如果一个json数据的所有对象都有相同的键，那么Gzip时的我的格式是否比原始json Gzip文件大小小

---

如果您决定继续使用建议的格式，您可以自己轻松地进行测试。

如果您确信您的对象始终是

{
    "product": "car",
    "price": "100"
}

您可以通过将它们存储为阵列来减少“冗余”，就像您在这里所做的那样：

[
    ["car", "100"],
    ["bus", "1000"],
    ["train", "100000"]
]

但大多数情况下，您无法确定数据是否“正确”存储，因为数据是以某种方式生成的。因此，用对象表示法存储数据是一个很大的优势（顺便说一句，JSON就是这个意思的缩写）。您只需就可以检查存储的对象在代码中是否具有某些属性

因此，不要因为JSON提供了冗余而责怪它，因为如果愿意，您可以绕过它。

---

这取决于您如何使用JSON。

特别需要引号，否则您将开始遇到空白控制问题。例如：一个描述，如果您的产品价格示例有一个描述，它将是多个单词，没有引号，您的解析器可能会遇到问题和歧义。@ChrisWatts如果所有描述值都用逗号分隔，怎么会有歧义？逗号

[
    ["car", "100"],
    ["bus", "1000"],
    ["train", "100000"]
]