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

EN

直到您开始将不同的名称空间模式混合在一起，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或Objective-C的原生iPhone应用程序，还是C#或Python客户端。浮点数将被解释为浮点数，字符串将被解释为字符串，布尔值将被解释为布尔值。使用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 could into my XML“。如果不编写自定义解析器，或者不需要额外的XML Schema/Relax NG和其他类似的麻烦，我就无法接收XML文档并立即说"go make could go and data structures“。

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

在大多数用例中，JSON的性能与XML没有太大区别，JSON并不适合深度嵌套的结构，可读性也不好……您将遇到]}]，这将使调试变得困难