为什么Everyone为jQuery选择JSON Over XML？

我认为XML非常便携,可以用作迷你数据库.我见过无处不在的XML.我甚至看到大公司转向JSON.甚至微软也集成了对JSON的支持.什么是对JSON的炒作？

1> CMS..：

---

基本上因为JSON本身是由JavaScript识别的,它实际上是轻量级,简约和高度可移植的,因为它只依赖于两个基本结构:

名称/值对的集合.在各种语言中,这被实现为对象,记录,结构,字典,散列表,键控列表或关联数组.

有序的值列表.在大多数语言中,这被实现为数组,向量,列表或序列.

---

+1,特别是因为与XML解析相比,JSON解析的效率要高得令人难以置信,甚至是分段式的.一旦您关心的数据集超过某个(并且非常小)阈值,性能差异就会显着.

---

+1 ..真的..与原始xml文本相比,这么多不同的数据类型支持很多事情

2> jcdyer..：

---

在您开始将不同的命名空间模式混合在一起之前,XML并没有真正开始发挥作用.然后你看到JSON开始倒下,但是如果你只需要数据的序列化格式,那么JSON比XML更小,更轻,更人性化,并且通常比XML更快.

---

+1用于显示XML真正有用的内容.人们常常使用XML,即使他们可以使用更简单的东西.

---

XML如何不易读取,我发现几乎不可能读取json,我认为XML的层次结构更容易理解(当然有点罗嗦).也许我对JSON的工作还不够

3> 小智..：

---

我发现JSON相对于XML的一大好处是我不必决定如何格式化数据.正如一些人所表明的那样,有许多方法可以在XML中做简单的数据结构 - 作为元素,作为属性值等.然后你必须记录它,编写XML Schema或Relax NG或其他一些废话......它是一团糟.

XML可能有其优点,但对于基本数据交换,JSON更加紧凑和直接.作为Python开发人员,JSON和Python中的简单数据类型之间不存在阻抗不匹配.因此,如果我正在为一个询问特定滑雪胜地的雪况的AJAX查询编写服务器端处理程序,我会建立一个如下字典:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

当通过JSON进行翻译时(使用像'simplejson'这样的Python库),生成的JSON结构看起来几乎相同(除了在JSON中,布尔值更低).

解码该结构只需要一个JSON解析器,无论是针对本机iPhone应用程序的Javascript还是Objective-C,还是C#或Python客户端.浮点数将被解释为浮点数,字符串被解释为字符串,而布尔值则被解释为布尔值.使用Python中的'simplejson'库,一个simplejson.loads(some_json_string)语句会给我一个完整的数据结构,就像我在上面的例子中所做的那样.

如果我写XML,我必须决定是否做元素或属性.以下两个都是有效的:

    5
    8.5
    yes
    deep and steep!



   deep and steep!

因此,我不仅要考虑我可能想要发送给客户端的数据,我还要考虑如何格式化它.XML虽然比简单的SGML更简单,但是通过更严格的规则,仍然提供了太多的方法来思考这些数据.然后我将不得不去生成它.我不能只拿一个Python字典(或其他简单的数据结构)并说"自己动手做我的XML".我无法接收XML文档并立即说"不必编写自定义解析器",或者不需要XML Schema/Relax NG和其他此类痛苦的额外开销.

缺点是,将数据编码和解码为JSON更加容易和直接,特别是对于快速交换.这可能更适用于来自动态语言背景的人,因为内置于JavaScript/JSON的基本数据类型(列表,词典等)直接映射到Python,Perl,Ruby等中相同或相似的数据类型.

4> 小智..：

---

对于大多数用例,JSON的性能与XML没有太大的不同,JSON对于深度嵌套结构来说不太适合和可读......你会遇到]]]}],这会使调试变得困难

5> Ron Gejman..：

---

与XML相比,它是轻量级的.如果您需要扩展,请降低带宽要求!

比较JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

到XML:

 
      
           red
           #f00
      
      
           green
           #0f0
      
      
           blue
           #00f
      
      
           cyan
           #0ff
      
      
           magenta
           #f0f
      
      
           yellow
           #ff0
      
      
           black
           #000
      
 

---

不仅更小,而且更人性化.XML看起来像是人类像计算机一样说话的不良尝试.

---

您的XML还可以减少XML属性而不是简单类型的元素(名称/值)

---

@Matthew:是的,但那看起来不一致和丑陋.而且你仍然需要元素的开/关标签.JSON(充其量)将需要使用的标记数量减半.

---

看看Marc的例子.我不知道你的版本比他的版本更容易阅读.http://stackoverflow.com/questions/1743532/why-is-everyone-choosing-json-over-xml-for-jquery/1743664#1743664

6> Nate B..：

---

只是我个人经历的轶事:

我编写了一个小的Javascript目录,首先使用XML格式的数据,然后对其进行调整以使用JSON,这样我就能并排运行它们并与Firebug进行速度比较.JSON最终快了大约3倍(350-400 ms与1200-1300 ms以显示所有数据).此外,正如其他人所指出的那样,JSON在眼睛上更容易,并且由于更精简的标记,文件大小减小了25%.

---

如果每个人都创造了这些基准,我们就没有什么可争论的了.

7> 小智..：

---

使用属性,XML很不错.但由于某种原因,自制的XML通常100%由元素组成,而且很难看.

---

可能因为复杂类型实际上只能在元素中描述,所以大多数工具都是默认的.我同意这个XML使用和阅读非常简单.

---

与JSON示例相比，非空白字符仍然更多。而且在XML中解析属性可能更令人讨厌。

8> Xinus..：

---

JavaScript轻松消费可能是原因之一..

---

这是我使用它的重要原因.手动解析xml非常复杂.此外,由于我首先使用Python来创建JSON,它们以非常类似的方式处理数据和对象,这意味着来回序列化使一切都快乐!

9> Joy Dutta..：

---

JSON最适合从Web服务中获取Web应用程序中的数据,因为它的大小和易用性,特别是由于JavaScript中的内置支持.想象一下,与JSON中的即时查找相比,解析xml片段的计算开销.

一个很好的例子是JSON-P.您可以从回调函数调用中包含的Web服务中获取数据,例如my_callback({"color": "blue", "shape":"square"});在动态生成的