【问题标题】:Is JSON too redundant like xml? [closed]JSON 是不是像 xml 一样冗余? [关闭]
【发布时间】:2017-05-22 03:09:44
【问题描述】:

摘要:

     在 json 格式中,我们有键值对。对于每个对象,重复相同的键。这不是冗余吗?是否可以将其更改为数据库表格式,其中第一行具有所有键,下一行表示具有值的对象。

详情:

     据说 xml 因为它的结束标签而更加冗长和冗余。所以替代方案是json。但我发现 json 太多余了。我发现的冗余是:

  1. 每个对象实例中的重复键。
  2. 每个键和值的名称都使用不必要的双引号。

对于 2,我发现一个解释是,由于 javascript 不允许保留关键字,如 functionifelse 作为键,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 键重复了 3 次,price 键也重复了 3 次。在表数据库格式中,此数据将是:

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

在表格格式中,productprice 没有重复。所以这种格式一定是最优格式。为了在 json 中实现这一点,我想出了以下方法:

  1. 类似数组的表格:

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

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

]

我们有很多数组。可能还有其他改进:

  1. 所有键的单独数组和所有值的另一个单独数组:

+-=--------- //用于格式化下面的代码

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

现在将只有三个数组。这是最优化的方法,可以稍微改进以使其更有意义:

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

现在我们看到可以去除 json 中的冗余。

问题2:是不是json是冗余的,格式还可以进一步改进?

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

问题 3: 如果 json 数据的所有对象都具有相同的键,那么我的 gzip 压缩格式是否比原始 json gzip 压缩文件的大小更小?

【问题讨论】:

  • 特别需要引号,否则您将开始遇到空白控制问题。例如:描述,如果您的产品价格示例有描述,它将是多个单词,没有引号,您的解析器可能会遇到问题和歧义。
  • @ChrisWatts 如果所有描述值都用逗号分隔,怎么会有歧义?逗号可以像双引号一样充当分隔符。
  • 考虑非结构化数据。然后 JSON 格式可以防止数据中出现大量不必要的“空白”。任何人:请随意详细说明/改进这个作为答案,我没有时间:-)
  • @user31782 考虑以下几点:"description" : "a meaningful description of the product, created by me", ...description : a meaningful description of the product, created by me, 第二个不会解析,因此开始限制您支持的字符集。 csv格式也是一样,都是用引号来封装数据,防止解析错误。
  • @ChrisWatts commas 可以用斜杠转义,就像双引号是普通的 json 格式一样。我认为这是",。可能有人认为commas 在文本中比quotes 更常见——所以我们应该使用逗号。使用EOF 之类的东西作为分隔符怎么样?

标签: javascript json xml database optimization


【解决方案1】:

是的,有很多冗余。

例如,“产品”可以替换为“1”,“价格”可以替换为“2”。或者实际上,为什么要使用 16 位?如果只有两个键,它们只需要一位。

但你的信息的整体基调是冗余是不好的。这不是一个普遍公认的真理。冗余有很多好处,这就是自然语言有这么多冗余的原因。

【讨论】:

  • 但是如果product1price 替换为2 那么客户怎么知道1 代表产品`和2 代表price?冗余有什么好处?自然语言中有什么样的冗余?请解释。我的知识很少。
  • @MichaelKay:感谢您按下通用按钮 :) 恕我直言,冗余是一把双刃剑。如果它是备用的并与一种检测/纠正错误的方法配对,那就太好了。如果它既浪费又缺乏这样的机制是很糟糕的,因为它的大小只会引发不容易检测到的错误。即 50% 的冗余可能是好的,但 1000% 可能是坏的。选择适量的冗余是一项技能。
【解决方案2】:

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

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

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

...或...

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 压缩文件的大小更小?

如果您决定采用建议的格式,您可以轻松地自行测试。

【讨论】:

    【解决方案3】:

    如果你确定你的对象总是像

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

    您可以像在此处那样将它们存储为数组来减少“冗余”:

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

    但大多数情况下,您无法确定您的数据是否“正确”存储,因为它是通过某种方式生成的。因此,以对象表示法存储数据主要是一个优势(顺便说一句,这是 JSON 的简写)。您只需检查您存储的对象是否在您的代码中具有某些属性

    所以不要责怪 JSON 提供了冗余,因为你可以绕过它,如果你愿意的话。 这取决于您如何使用 JSON。

    【讨论】:

    • 是的,我确信我的对象总是这样。它基本上是一组用 ajax 加载的图像。
    • 那么你可以使用数组表示法。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-06-09
    • 2010-11-10
    相关资源
    最近更新 更多