为啥每个人都为 jQuery 选择 JSON 而不是 XML？ [关闭]

Posted 2023-05-08

【中文标题】为啥每个人都为 jQuery 选择 JSON 而不是 XML？ [关闭]

【英文标题】：Why is Everyone Choosing JSON Over XML for jQuery? [closed]为什么每个人都为 jQuery 选择 JSON 而不是 XML？ [关闭]

【发布时间】：2010-12-17 03:27:01

【问题描述】：

我认为 XML 具有高度可移植性，可以用作小型数据库。我见过到处都在使用 XML。我什至看到大公司切换到JSON。甚至微软也集成了对 JSON 的支持。对 JSON 的炒作是什么？

【问题讨论】：

“everyone”和“everywhere”都是如此绝对的术语……

@eliben XML 实际上并不糟糕。它非常强大，但就像用火箭发射器猎兔一样，它可能并不总是最好的选择。

人们目前使用 XML 的大部分内容在 JSON 中会更好

@Dan 如果只有 XML 和用火箭发射器打兔子一样有趣（大概 - 我不能说我自己试过）

因为它的“XML 的无脂肪替代品”-json.org

【参考方案1】：

基本上因为 JSON 被 javascript 原生识别，它真的很轻量级、简约且高度可移植，因为它只依赖于两个基本结构：

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

【讨论】：

+1.. 真的.. 与原始 xml 文本相比，支持这么多不同的数据类型非常重要

+1，尤其是 JSON 解析比 XML 解析效率更高，甚至是分段解析。一旦您关心的数据集超过某个（而且非常小）的阈值，性能差异就会很明显。

有人给我看数据说在现代浏览器中 JSON 解析比 XML 更快。此处关于 SO 的答案另有说明：***.com/questions/4596465/…

【参考方案2】：

在您开始将不同的命名空间模式混合在一起之前，XML 并没有真正开始大放异彩。然后您会看到 JSON 开始下降，但如果您只需要数据的序列化格式，JSON 更小、更轻、更易于阅读，并且通常比 XML 更快。

【讨论】：

+1 用于展示 XML 真正有用的地方。人们经常使用 XML，即使他们可以使用更简单的东西。

是的，我必须同意 jcd 和 Daniel 的观点。关于为什么 XML 在某些方面仍然非常有用的质量响应。

XML 的可读性如何降低，我发现读取 json 几乎是不可能的，我认为 XML 的层次结构更容易理解（当然有点罗嗦）。也许我对 JSON 的工作还不够

命名空间是一种 xml 解决方案，用于解决使用 XML 做事时的某些问题。如果您使用的是 json，请找到一个 json 解决方案，以 json 方式解决相同的问题。对我来说，命名空间参数就像“哦！但是 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 翻译时（使用 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 等中相同或相似的数据类型。

【参考方案4】：

对于大多数用例，JSON 的性能与 XML 没有太大区别，JSON 不太适合，并且 对于深度嵌套结构可读...你会遇到]]]]，这使得调试变得困难

【参考方案5】：

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

【讨论】：

不仅更小，而且更人性化。 XML 看起来像是人类像计算机一样说话的糟糕尝试。

您的 XML 还可以使用属性而不是简单类型（名称/值）的元素来减少 XML

@Matthew：是的，但它看起来不一致且丑陋。而且您仍然需要元素的打开/关闭标签。 JSON（充其量）将您需要使用的标签数量减半。

看看 Marc 的例子。我看不出你的版本比他的更容易阅读。 ***.com/questions/1743532/…

不同之处在于长度对我来说似乎没有那么大

【参考方案6】：

只是我个人经历的一个轶事：

我编写了一个小的 Javascript 目录，首先使用 XML 格式的数据，然后将其调整为使用 JSON，以便我可以并排运行它们并与 Firebug 比较速度。 JSON 最终快了大约 3 倍（350-400 毫秒与 1200-1300 毫秒显示所有数据）。此外，正如其他人所指出的，JSON 在视觉上更容易，并且由于更精简的标记，文件大小小了 25%。

【讨论】：

如果每个人都创建了这些基准，我们就没有什么好争论的了。

【参考方案7】：

 <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% 由元素组成的，而且很丑。

【讨论】：

这仍然是比 JSON 示例更多的非空白字符。在 XML 中解析属性可能更烦人。

可能是因为复杂类型实际上只能在元素中描述，因此大多数工具默认。我同意这个 XML 非常易于使用和阅读。

【参考方案8】：

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

【讨论】：

这是我使用它的重要原因。手动解析 xml 极其复杂。此外，由于我首先使用 Python 创建 JSON，它们以非常相似的方式处理数据和对象，这意味着来回序列化让一切变得愉快！

【参考方案9】：

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

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

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

【参考方案10】：

这里没有人提到 XML-s 的主要优势：验证规则（DTD、XSD）。我的结论，两者都使用过：

JSON 非常适合 ajax，尤其是当您自己开发服务器端和客户端时。您基本上可以直接在服务器脚本中创建 js 对象！ 当您必须在大型官僚组织之间设置数据交换标准时，XML 在企业环境中大放异彩。通常，一方会比另一方早几个月开发它的部分，因此它确实受益于根据商定的 XSD 验证其请求。此外，在大公司中，数据传输通常在不同系统之间进行转换。这也是 XML 的强项，想想 XSLT。示例：无代码转换为 JSON :p

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

我是两者的粉丝，他们只是有不同的优势。

【参考方案11】：

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

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

【参考方案12】：

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

【讨论】：

没有发现你的答案特别鼓舞人心，但它没有错，所以反对票似乎不公平。

+1 表示 XML 可以用作 JSON 的 正确 超集。

【参考方案13】：

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

【讨论】：

需要解析项目并不等同于阻抗不匹配。

阻抗不匹配是指概念不能从一种格式清晰地映射到另一种格式，就像对象关系映射一样。有些东西用对象很容易表达，但用 SQL 很难表达，而另一些用 SQL 很容易表达，但对象层次结构很难清晰地表达出来。对于 XML 和 JSON，一个通常比另一个需要更多的工作来获得含义，但这实际上取决于解析工具。表现力（大部分）是相同的。

【参考方案14】：

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

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

【讨论】：

而且我相信较新的 JavaScript 版本开始包含“安全”（无 eval）内置 JSON 编码器和解码器。

【参考方案15】：

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

【参考方案16】：

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 有效负载在同一文档中使用许多不同的命名空间，这可能会很快爆发。

【参考方案17】：

在大多数情况下，XML 是臃肿的蛇油。 JSON 为您提供了大部分好处，而且不会臃肿。

【参考方案18】：

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

【讨论】：

"colors":["red","green","blue"],"systems":["windows","mac"] 与 "entries":["type":"color","value":"red","type":"system","value":"mac"]

【参考方案19】：

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

当您拥有大量数据时，通常您会希望报告这些数据。而且 XML 并不是一个很好的报告来源。从宏观上看，事务数据库似乎比 XML 更容易报告/搜索。

这有意义吗？正如我上面所说，我不是专家，但根据我的经验，情况似乎如此。此外，我相信由于开发人员转向客户端或脚本操作以增强 UI 的视觉效果 (Ajax) 的浪潮，微软集成了 JSON 支持，并且微软的 Ajax 没有像 jQuery 和MooTools（Yahoo 的 YUI 也在其中），因为它们使用 JSON 将可序列化对象完美集成。

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

【讨论】：

我认为这个问题有些混乱，这个答案包含很多猜测。

@Eric P：VB 绝对没有问题。