我认为 XML 具有高度可移植性，可以用作小型数据库。我见过到处都在使用 XML。我什至看到大公司切换到JSON。甚至微软也集成了对 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 解析器，无论是用于原生 iPhone 应用程序的 Javascript 或 Objective-C 还是 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 字典（或其他简单的数据结构）说“把你自己变成我的 XML”。如果不编写自定义解析器，或者不需要 XML Schema/Relax NG 的额外开销和其他类似的痛苦，我无法收到 XML 文档并立即说“让自己进入对象和数据结构”。
简而言之，将数据编码和解码为 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 服务中获取数据，例如动态生成的 <script> 标记内的 my_callback({"color": "blue", "shape":"square"});，以便可以在函数 my_callback() 中直接使用数据。使用 XML 无法实现这种便利。
XML 将是大型文档的首选格式，其中您有一个使用 XSLT 以多种格式呈现数据页面的框架。 XML 也可以与应用程序配置文件一起使用，以便在许多其他用途中保持可读性。
【讨论】：
这里没有人提到 XML-s 的主要优势：验证规则（DTD、XSD）。我的结论，两者都使用过：
当然，正在开发 json-schema，但您不会在任何地方找到对它的内置支持。
我是两者的粉丝，他们只是有不同的优势。
【讨论】：
现在大多数语言都有 JSON 编码器和解码器，没有理由不将 JSON 用于有意义的用途（这可能是 XML 用例的 90%）。
我什至听说过在大型 SQL 数据库中使用 JSON 字符串来简化架构更改。
【讨论】：
老实说，JSON 和 XML 之间并没有太大区别，因为它们可以表示所有类型的数据。但是，XML 在语法上比 JSON 大，这使得它比 JSON 更重。
【讨论】：
JSON 与 JavaScript 编程没有阻抗不匹配。 JSON 可以包含整数、字符串、列表、数组。 XML 只是元素和节点，需要解析为整数等才能被使用。
【讨论】：
两者都很棒而且非常便携。然而 JSON 越来越受欢迎，因为它在大多数情况下序列化为更少的字符（这意味着更快的交付时间），并且由于它与 JavaScript 对象语法匹配，它可以直接转换为内存中的对象，这使得 Ajax 很多更容易实现。
XML 仍然很棒。与 XML 相比，JSON 只是“最新最好的”。
【讨论】：
很容易被 JavaScript 解析并且它是轻量级的（JSON 中的文档比包含相同数据的 XML 文档小。）
【讨论】：
JSON 是有效的序列化 JavaScript，因为您可以将 eval(aJsonString) 直接转换为 JavaScript 对象。在浏览器内部，它是一个不费吹灰之力的 JSON 非常适合 JavaScript。同时，JavaScript 是一种类型非常松散的动态语言，不能在本地利用 Xml/Xsd 文档中包含的所有特定类型信息。这种额外的元数据（对互操作性很有帮助）是 JavaScript 中的一个障碍，使其使用起来更加乏味和繁琐。
尺寸与性能
如果您使用的是浏览器，JSON 的序列化/反序列化速度更快，因为它更简单、更紧凑且更重要的是本机支持。我有一些northwind database benchmarks available 比较可用的不同序列化程序之间的大小和速度。在基类库中，Microsoft 的 XML DataContract 序列化程序比他们的 JSON 序列化程序快 30%。尽管这与微软在他们的 XML 序列化程序中投入的努力有关，因为我能够开发出一个比他们的 XML 快 2.6x 的JsonSerializer。至于基于基准的有效负载，看起来 XML 的大小大约是 JSON 的 2x 多。但是，如果您的 XML 有效负载在同一文档中使用许多不同的命名空间，这可能会很快爆发。
【讨论】：
在大多数情况下，XML 是臃肿的蛇油。 JSON 为您提供了大部分好处，而且不会臃肿。
【讨论】：
除了这里提到的之外，还有一个主要优势。 对于相同的数据，有多种方法可以将其表示为 XML 文件，但只有一种使用 JSON 的方法可以消除歧义:)
【讨论】：
{"colors":["red","green","blue"],"systems":["windows","mac"]} 与 {"entries":[{"type":"color","value":"red"},{"type":"system","value":"mac"}]}
到目前为止，我还不是专家，但在我工作过的各种公司中，我们通常在小型数据环境或配置值中使用 XML（web.config 就是一个很好的例子）。
当您拥有大量数据时，通常您会希望报告这些数据。而且 XML 并不是一个很好的报告来源。从宏观上看，事务数据库似乎比 XML 更容易报告/搜索。
这有意义吗？正如我上面所说，我不是专家，但根据我的经验，情况似乎如此。此外，我相信由于开发人员转向客户端或脚本操作以增强 UI 的视觉效果 (Ajax) 的浪潮，微软集成了 JSON 支持，并且微软的 Ajax 没有像 jQuery 和MooTools（Yahoo 的 YUI 也在其中），因为它们使用 JSON 将可序列化对象完美集成。
我发现自己正在编写代码，现在在我的 VB 代码中实现 JSON 序列化程序。这太容易了，从升级/修改的角度来看，你无法击败它。我猜这是微软让我们沉迷于 VS 的方式。我最近将一个企业应用程序转换为使用 Ajax（通过 jQuery）和 JSON 格式。这样做花了大约 2 周时间。我实际上感谢 Microsoft 集成它，因为没有它，我将不得不编写相当多的额外代码。
【讨论】：