为什么每个人都选择 JSON 而不是 XML 作为 jQuery？

与 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 与 JavaScript 编程没有阻抗不匹配。JSON 可以包含整数、字符串、列表和数组。XML 只是需要解析为整数等等的元素和节点，然后才能使用它。

老实说，JSON 和 XML 之间没有太大的不同，因为它们可以表示所有类型的数据。然而，XML 在语法上比 JSON 大，这使得它比 JSON 重。

基本上，因为 JSON 是由 JavaScript 本地识别的，所以它非常轻量级、简约和高度可移植，因为它只依赖于两个基本结构:

• 名称/值对的集合。在不同的语言中，这是通过对象、记录、结构、字典、哈希表、键控列表或关联数组来实现的。
• 值的有序列表。在大多数语言中，这是以数组、向量、列表或序列的形式实现的。

既然大多数语言都有 JSON 编码器和解码器，那么就没有理由不将 JSON 用于有意义的用途(这可能是 XML 用例的90%)。

我甚至听说过在大型 SQL 数据库中使用 JSON 字符串来简化模式更改。

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

当您拥有大量数据时，通常需要报告该数据。XML 并不是一个很好的报告来源。总的来说，事务性数据库似乎比 XML 更容易报告/搜索。

这说得通吗？正如我上面所说，我不是专家，但从我的经验来看，似乎是这样。另外，我相信微软整合了 JSON 支持是因为开发者们转向了客户端或者脚本操作来增强 UI (阿贾克斯)的视觉效果，而且微软的 Ajax 没有像 jQuery 和 MooTools(雅虎的 YUI也在其中)这样被广泛使用，因为它们使用 JSON 对可序列化的对象进行了完美的整合。

我发现自己正在编写代码，在 VB 代码中实现 JSON 序列化器。这太容易了，从升级/修改的角度来看，你无法击败它。我猜这是微软让我们沉迷于 VS 的方式。我最近将一个企业应用程序转换为使用 Ajax (通过 jQuery)和 JSON 格式。大约花了两个星期的时间。实际上，我感谢微软对它的集成，因为如果没有它，我将不得不编写相当多的额外代码。

两者都很棒，而且非常便携。然而，JSON 已经变得越来越流行，因为它在大多数情况下序列化成更少的字符(这意味着更快的传递时间) ，而且因为它匹配 JavaScript 对象语法，它可以直接转换成内存对象，这使得 阿贾克斯更容易实现。

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

 <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 通常是100% 由元素组成的，而且很难看。

它很容易被 JavaScript 解析，而且是轻量级的(JSON 的文档比包含相同数据的 XML 文档要小)

只有当您开始混合使用不同的名称空间模式时，XML 才会真正开始发光。然后您会看到 JSON 开始下降，但是如果您只是需要数据的序列化格式，那么 JSON 更小、更轻量级、更易于阅读，而且通常比 XML 更快。

由于 JSON 的大小和易用性，特别是由于 JavaScript的内置支持，它最适合在 Web 应用程序中使用来自 Web 服务的数据。想象一下，与 JSON 中的即时查找相比，解析 xml 片段的计算开销会有多大。

一个很好的例子是 JSON-P。您可以从封装在回调函数调用中的 webservice 获取数据，比如动态生成的 <script>标记中的 my_callback({"color": "blue", "shape":"square"});，这样数据就可以直接在函数 my_callback()中使用。使用 XML 是无法达到这种方便的。

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

我发现 JSON 比 XML 有一个很大的好处，那就是我不必决定如何格式化数据。正如一些人所展示的，有许多方法可以用 XML 实现即使是简单的数据结构——作为元素、作为属性值等等。然后，您必须对它进行文档记录，编写 XML Schema 或者 RelationNG 或者其他一些废话... ... 这是一团糟。

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 字典(或其他简单的数据结构) ，然后说“ go make yourself into my XML”。如果不编写自定义解析器，或者不需要额外的 XML Schema/RelaxNG 开销和其他诸如此类的麻烦，我就无法接收到 XML 文档并立即说“ go make yourself into object and data strucs”。

简而言之，将数据编码和解码为 JSON 要简单得多，也要直接得多，特别是对于快速交换来说。这可能更适用于来自动态语言背景的人，因为内置在 JavaScript/JSON 中的基本数据类型(列表、字典等)直接映射到 Python、 Perl、 Ruby 等中相同或类似的数据类型。

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

这只是我个人经历中的一则轶事:

我编写了一个小的 Javascript 目录，首先使用 XML 格式的数据，然后将其改编为使用 JSON，这样我就可以并行运行它们，并与 Firebug 进行速度比较。JSON 最终大约快了3倍(显示所有数据的速度分别为350-400毫秒和1200-1300毫秒)。另外，正如其他人所指出的，JSON 对眼睛来说更加容易，由于标记更加精简，文件大小也减少了25% 。

JSON 有效地序列化了 JavaScript，因为您可以将(aJsonString)直接进入 JavaScript 对象。在浏览器内部，这是一个简单易懂的 JSON 非常适合 JavaScript。同时，JavaScript 是一种类型非常松散的动态语言，本身无法利用 XML/Xsd 文档中包含的所有特定类型信息。这种额外的元数据(对于互操作性来说非常好)是 JavaScript 中的一个障碍，使得处理它变得更加乏味和繁琐。

尺寸与性能

如果您使用的是浏览器，那么 JSON 序列化/反序列化更快，因为它更简单、更紧凑，而且更重要的是它本身支持。我有一些 可用的 northwind 数据库基准测试比较大小和速度之间的不同序列化可用。在基类库中，微软的 XML 数据合同序列化器比 JSON 序列化器的速度快于 百分之三十序列化器。尽管这与微软投入到他们的 XML 序列化器中的努力有更多的关系，因为我能够开发一个比他们的 XML 序列化器更快的 JsonSerializer。至于基于基准测试的有效载荷，看起来 XML 大约比 JSON 大小的 2倍还要大。但是，如果您的 XML 有效负载在同一文档中使用许多不同的名称空间，这种情况可能会很快消失。

这里没有人提到 XML-s 的主要优势: 验证规则(DTD，XSD):

• JSON 非常适合 ajax，特别是如果您自己开发服务器端和客户端。基本上就是在服务器脚本中创建 js 对象！
• 当您必须在大型官僚机构之间设置数据交换标准时，XML 在公司环境中大放异彩。通常，一方比另一方提前几个月开发自己的部分，因此根据约定的 XSD 验证自己的请求确实会受益匪浅。此外，在大公司中，数据传输通常在不同的系统之间进行转换。考虑到 XSLT，这也是 XML 的优势所在。示例: 无代码转换为 JSON: p

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

我是两者的粉丝，他们只是有不同的强项。

除了这里提到的优势之外，还有一个主要的优势。 对于相同的数据，有多种方法可以将其表示为 XML 文件，但使用 JSON 只有一种方法，可以消除歧义:)