为什么每个人都为jQuery选择XML之上的JSON？[关闭]

我认为XML具有高度的可移植性，可以用作小型数据库。我已经看到XML随处可见。我什至看到大公司转而使用JSON。甚至Microsoft都集成了对JSON的支持。对JSON的所有炒作是什么？

基本上因为JSON被JavaScript本地识别，所以它非常轻巧，简约并且具有高度可移植性，因为它仅依赖于两个基本结构：

• 名称/值对的集合。在各种语言中，这被实现为对象，记录，结构，字典，哈希表，键列表或关联数组。
• 值的有序列表。在大多数语言中，这被实现为数组，向量，列表或序列。

在您开始将不同的命名空间模式混合在一起之前，XML才真正开始发挥作用。然后您会看到JSON开始下降，但是如果您只需要数据的序列化格式，则JSON会更小，更轻量，更易读，并且通常比XML快。

我发现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转换时（对于Python使用类似'simplejson'的库），生成的JSON结构看起来几乎完全相同（除了JSON，布尔值是小写的）。

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

如果我编写XML，则必须决定是执行元素还是属性。以下两项均有效：

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

因此，我不仅要考虑可能要发送给客户端的数据，还必须考虑如何格式化数据。XML尽管通过严格的规则比普通的SGML更简单，但仍然提供了太多考虑数据的方法。然后，我将不得不去生成它。我不能只接受Python字典（或其他简单的数据结构）并说“将自己融入XML”。我没有收到XML文档，而没有写一个自定义的解析器，或者不需要XML Schema / Relax NG的额外开销和其他类似的麻烦，就无法立即说“进入对象和数据结构”。

简而言之，将数据编码和解码为JSON更加容易和直接得多，尤其是对于快速交换而言。这可能更适用于来自动态语言背景的人们，因为内置在JavaScript / JSON中的基本数据类型（列表，字典等）直接映射为Python，Perl，Ruby等中相同或相似的数据类型。

在大多数情况下，JSON的性能与XML并无太大不同，JSON对于深度嵌套的结构不太适合且可读性很强……您会遇到]]]}]]，这使调试变得很困难

与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：

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

只是我个人经历的轶事：

我写了一个小的Javascript目录，首先使用XML格式的数据，然后将其修改为使用JSON，这样我就可以并行运行它们并与Firebug比较速度。JSON的速度提高了大约3倍（350-400毫秒与1200-1300毫秒来显示所有数据）。另外，正如其他人所指出的那样，由于标记更精简，因此JSON在眼睛上更容易使用，并且文件大小小25％。

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

有了属性，XML很不错。但是出于某种原因，自制XML通常100％由元素组成，而且很难看。

JavaScript易于使用可能是原因之一。

JSON是Web服务中Web应用程序中数据消费的最佳选择，因为它的大小和易用性，特别是由于JavaScript的内置支持。想象一下，与JSON中的即时查找相比，解析xml片段的计算开销。

JSON-P是一个很好的例子。您可以从包装在回调函数调用中的Web服务中获取数据，例如my_callback({"color": "blue", "shape":"square"});在动态生成的<script>标签内部，以便可以直接在函数中使用数据my_callback()。使用XML无法实现这种便利。

XML是大型文档的首选格式，在该文档中，您具有使用XSLT呈现多种格式的数据页面的框架。XML还可以与应用程序配置文件一起使用，以提高可读性。

这里没有人提到XML的主要优势：验证规则（DTD，XSD）。我的结论同时使用：

• JSON非常适合ajax，尤其是如果您自己开发服务器端和客户端。您基本上可以在服务器脚本中直接创建js对象！
• 当您必须在大型官僚组织之间设置数据交换标准时，XML在企业环境中大放异彩。通常，一方发展自己的角色要比另一方提前几个月，因此，它确实可以从针对商定的XSD验证其请求中受益。同样，在大公司中，数据传输通常在不同的系统之间转换。XSLT认为，这也是XML的优势。示例：无代码转换为JSON：p

当然，正在开发json模式，但是您在任何地方都找不到对它的内置支持。

我是这两者的忠实拥they，他们的长处不同。

现在，大多数语言都有JSON编码器和解码器，因此没有理由不将JSON用于有意义的用途（这可能是XML用例的90％）。

我什至听说大型SQL数据库中使用JSON字符串来简化架构更改。

老实说，JSON和XML之间的区别不大，因为它们可以表示所有类型的数据。但是，XML在语法上比JSON大，这使其比JSON重。

JSON与JavaScript编程没有阻抗匹配。JSON可以包含整数，字符串，列表，数组。XML只是元素和节点，需要先解析成整数等，然后才能使用它。

两者都很棒而且非常便携。但是，由于JSON在大多数情况下可以序列化为更少的字符（这意味着转换为更快的交付时间），并且由于它与JavaScript对象语法匹配，因此可以直接转换为内存中对象，这使得Ajax更加易于使用，因此JSON受到了欢迎。实行。

XML仍然很棒。与XML相比，JSON只是“最新和最好的”。

很容易被JavaScript解析，并且它是轻量级的（JSON中的文档比包含相同数据的XML文档要小。）

JSON有效地序列化了JavaScript，因为您可以将eval（aJsonString）直接评估为JavaScript对象。在浏览器内部，毫无疑问，JSON非常适合JavaScript。同时，JavaScript是一种非常宽松的动态语言，不能自然地利用Xml / Xsd文档中包含的所有特定类型信息。这些额外的元数据（对于互操作性非常有用）是JavaScript的障碍，使其工作起来更加乏味和繁琐。

尺寸与性能

如果您使用的是浏览器，则JSON序列化/反序列化的速度更快，因为它更简单，更紧凑且更重要地受本机支持。我有一些罗斯文数据库基准测试，可以比较可用的不同序列化程序之间的大小和速度。在基类库中，Microsoft的XML DataContract序列化程序比JSON快30％以上。尽管这更多与Microsoft投入其XML序列化程序的努力有关，因为我能够开发出一种JsonSerializer，该速度比其XML快2.6倍以上。至于基于基准的有效负载，看起来XML远远超过了 2倍JSON的大小。但是，如果您的XML有效负载在同一文档中使用许多不同的名称空间，则此操作可能会很快消失。

XML在大多数情况下都是is肿的蛇油。JSON为您带来了大多数好处，而没有膨胀。

除此处提到的优点以外的一项主要优点。对于相同的数据，有多种方法可以将其表示为XML文件，但是只有一种使用JSON的方法可以消除歧义：)

我到目前为止还不是专家，但是从我工作过的多家公司中，我们通常在小数据环境或配置值中使用XML（web.config是一个很好的例子）。

通常，当您有大量数据时，您将需要报告该数据。而且XML并不是报告的重要来源。在总体方案中，似乎交易数据库比XML更易于报告/搜索。

这有意义吗？如上所述，我不是专家，但根据我的经验，情况似乎确实如此。另外，我相信Microsoft集成了JSON支持，这是由于开发人员纷纷转向客户端或脚本操作来增强UI（Ajax）的视觉效果，并且Microsoft的Ajax并未像jQuery和MooTools（雅虎（Yahoo）的YUI也处于这种混合状态），因为它们使用JSON对可序列化对象进行了精美的集成。

我发现自己正在编写代码，现在在我的VB代码中实现了JSON序列化程序。这太简单了，从升级/修改的角度来看，您无法击败它。我猜这是微软让我们沉迷于VS的方式。我最近将企业应用程序转换为使用Ajax（通过jQuery）和JSON格式。大约花了2个星期。我实际上感谢Microsoft集成它，因为没有它，我将不得不编写很多额外的代码。