什么时候更喜欢JSON而不是XML？

Question

我的要求就是在展开时显示从数据库中检索的一组值。我正在使用jquery。

Answer 1

当其中任何一个成立时，支持XML而不是JSON：

• 您需要消息验证
• 您正在使用XSLT
• 您的邮件包含大量标记文字
• 您需要与不支持JSON的环境进行互操作

当所有这些都成立时，将JSON优先于XML：

• 不需要验证消息，也不需要验证其反序列化是否简单
• 你没有转换消息，或者转换他们的反序列化很简单
• 您的邮件主要是数据，而非标记文字
• 消息传递端点具有良好的JSON工具

Answer 2

除非我需要使用XML，否则我使用JSON。它更容易理解，并且（因为它需要更少的配置开销）如果库在您的上下文中可用，则更容易编写读写程序，并且它们现在非常普遍。

当亚马逊首次将其目录作为Web服务公开时，他们提供了JSON和XML。 90％的实施者都选择了JSON。

Answer 3

考虑到你在客户端已经在使用javascript的特定情况，我会因为以下原因选择JSON：

• 由于JSON是javascript原生的 你必须写更少的代码 客户端 - 只需eval()（或者更好，JSON.parse()）JSON 字符串并获得一个对象 使用

• 同时评估JSON 客户端会更多 高效，因此更快。

• JSON序列化产生的时间更短 字符串而不是XML。使用JSON会 减少运行的数据量 穿越电线并改善 在这方面的表现。

以下是一些进一步的阅读：http://www.subbu.org/blog/2006/08/json-vs-xml

Answer 4

我在XML vs JSON中遇到的其他一些事情：

JSON非常适合

• 名称/值对
• 嵌套这些对

这意味着它倾向于喜欢数组或嵌套数组。但是JSON缺少

• 属性
• 命名空间

因此，如果您要组合两个或更多JSON服务，则可能存在潜在的命名空间冲突。据说JSON可用于在我的经验中交换数据时可用于XML的大约90％的相同内容。

Answer 5

通常JSON更紧凑，解析速度更快。

首选XML：

• 您需要在客户端上处理数据，并且可以利用XSL。有可能XML + XSL链比JSON + JavaScript工作得更快，特别是对于大块数据。
  • 一个好例子是将数据转换为HTML代码段。
• 各种遗留案件：
  • 有一个现有的XML服务，由于某些原因，用JSON重写它是一件麻烦事。
  • 您必须使用用户输入进行一些轻量级处理后将此数据作为XML发回。

（几乎）XML的一个重要案例：尝试检测何时发送HTML片段比发送原始数据更有益。 AHAH可以在简单的应用程序中创造奇迹，但却经常被忽视。通常，此样式假定服务器发送的HTML片段将在网页中内联而不进行处理。

通常在AHAH案例中，CSS最大限度地利用CSS来按目标按摩片段并实现简单的条件，例如使用特定于用户或特定于应用程序的设置隐藏/显示片段的相关部分。

Answer 6

JSON解析起来既简单又快捷。 XML解析起来有点困难，解析和传输速度较慢（在大多数情况下）。

由于您正在使用jQuery，我建议使用JSON：jQuery可以检索JSON数据并自动将其转换为Javascript对象。事实上，你可以convert JSON data into a Javascript object using eval。 XML必须由您手动遍历（我不知道它在Javascript中是如何工作的，但是在我使用XML库的大多数语言中都很难/更烦人。）

Answer 7

就客户端浏览器解析数据所需的处理而言，JSON总是更可取的。此外，JSON是轻量级数据交换格式。

XML解析总是消耗大量浏览器资源，除非另有要求，否则应尽可能避免。

Answer 8

我有一篇关于这个主题的博客文章，详细介绍了Web协议的历史（即SOAP，XML，JSON，REST，POX等），提供了每个摘要以及每个的优点和缺点：http://www.servicestack.net/mythz_blog/?p=154 < / p>

我实际上认为通过比较动态（JSON）和静态（XML）语言之间的差异，您可以在XML和JSON之间绘制许多相似之处。

基本上，XML是一种更严格，更严格的序列化格式，可以选择使用附带的架构（可以是XSD或DTD）进行验证。 XSD非常复杂，允许您描述许多不同的类型，例如日期，时间，枚举，用户定义类型甚至类型继承等.SOAP有效地构建在XML功能集之上，提供了通过WSDL描述Web服务（例如类型和操作）的标准化方法。 WSDL规范的详细程度和复杂性意味着开发可能会更繁琐，但同时可以使用更多工具，大多数现代语言提供自动化工具来生成客户端代理，从而承担一些负担尝试与外部服务进行互操作时关闭。 （虽然与此同时我发现在处理频繁变化的Web服务时，生成的代理本身就是一种负担。）

如果您有一个定义明确的“企业服务”，不经常更改或者您的Web服务需要从多种不同语言访问，我仍然建议您使用XML作为您的Web服务。

为了它的所有好处，XML也有缺点。它依赖于命名空间以提供类型化的可扩展格式，并允许您在同一文档中指定属性和元素。 在一个文档中使用不同的命名空间意味着在使用Xml Parser提取数据时很多时候，您还需要提供要检索/遍历的每个元素的命名空间。它还可以推断有效载荷，使其更加冗长。 具有输出属性和元素的选项意味着您的类不能很好地映射到XML文档。仅这些功能使其成为大多数语言的程序设计，使得使用起来更加繁琐和繁琐。 Microsoft已经通过废除XML属性并仅仅将类的属性映射到Xml元素来识别和简化它们的DataContract序列化程序。

另一方面，JSON在很多方面与XML完全相反，因为它的类型非常松散，并且只支持基本类型：Number，Bool，string，Objects和Arrays。其他一切基本上都必须符合字符串。当尝试跨语言边界进行通信时，这并不是很好，因为如果要支持更具体的类型，则需要遵守一些带外非标准规范。从好的方面来看，它的有限功能集非常适合大多数语言 - 并且非常适合JavaScript，因为JSON字符串可以 eval'ed 直接导入JavaScript对象。

尺寸和效果

我有一些northwind database benchmarks available比较了Microsofts XML和JSON实现之间的大小和速度。基本上，XML的大小是JSON的2倍，但同时看起来微软在优化XML DataContractSerializer方面付出了很多努力。 它比他们的JSON快30％。看来你必须在尺寸和性能之间进行权衡。对这个事实不满意，我决定编写自己的快速JsonSerializer，它现在比MS的XML快一倍 - 这两个世界都是最好的:)。

Answer 9

如果我需要验证传入数据的大小，我会选择XML over JSON，因为XML通过XSD本身支持这一点。

Answer 10

from JSON - the last feet

  

当你走下JSON路线时，你   遇到与XML相同的问题   面对10年前：

     

混合来自两个不同来源的数据   一个JSON包可以导致元素   标签相互碰撞。混合   装箱单和发票，以及   突然，From地址可能意味着   一些不同的东西。这就是为什么   XML具有名称空间。

     

在不同的JSON之间转换   结构需要写作   平凡的代码。更具说明性的方式   映射数据可以使工作更轻松。   这就是XML具有 XSLT 的原因。

     

描述JSON数据包   结构 - 其领域，数据类型，   等 - 对于人来说是必要的   挂钩你的服务。它的   拥有元数据语言至关重要   为了这。这就是XML具有架构的原因。

     

同时进行两次   客户端 - 服务器对话需要   关心。如果你问服务器两个   问题并得到一个答案，如何   你知道它回答了什么问题吗？   这就是XML具有 WS-Correlation 的原因。

Answer 11

从http://json.org/xml.html

的第一行开始

  

可扩展标记语言（XML）是从标准通用标记语言（SGML）派生的文本格式。与SGML相比，XML很简单。相比之下，超文本标记语言（HTML）甚至更简单。即便如此，一本关于HTML的好书也只有一英寸厚。这是因为文档的格式化和结构化是一项复杂的业务。   。 。

显然JSON更快，但更难以阅读。 使用JSON提高速度，如果存在人机交互则使用XML，您可以牺牲速度。

Answer 12

JSON是javascript的本机编码。它应该更快更容易使用。

Answer 13

我将JSON用于任何类型的配置，数据交换或消息传递。我只是出于其他原因使用XML或者在语义上标记类似文档的数据。

Answer 14

Microsoft支持XML和JSON。 XML文字是VB 9中新的酷炫功能。在即将推出的ASP.NET 4.0版本中，JSON必须利用客户端模板的强大功能。

从您提出的问题来看，似乎JSON可能是您的选择，因为无论是否使用jQuery，都可以在客户端轻松处理。

Answer 15

使用JSON

• 如果数据将由浏览器中的JavaScript使用。
• 数据模型简单而不复杂（复合对象太多）。

使用XML

• 主要在您正在集成的SOA环境中 异构平台和技术上的几项服务。
• SOAP的优势在于它可以跨不同传输 除了HTTP之外的其他协议。
• 易于在XSLT，XSL-FO等数据模型转换工具中使用。
• 许多数据库支持存储/查询（XQuery）XML数据。
• XML是一种非常成熟的数据格式，因此您可以找到许多工具来支持您能想到的任何用例。

Answer 16

快速规则：

• JSON：程序到程序数据格式
• YAML（JSON超集）：人与程序数据格式
• XML：文档标记格式

<强>解释

JSON的唯一作用是使用大多数编程语言常用的数据类型序列化面向对象的数据：列表，哈希和标量 ，为了这个目的，它真的不能被打败或改进。 “JSON没有版本号[as]，预计不会修改JSON语法”。 - Douglas Crockford（无法将其打败，表明你完美地完成了自己的工作）

XML曾经作为数据交换格式出售，但考虑两个最常见的用例：异步客户端 - 服务器通信（AJAX） - JSON几乎完全取代了XML（The X应该是一个J）和 Web服务：JSON使XML成为一种多余的替代方案。

XML被广泛使用的另一件事是用于程序的人类可写/可读（？）数据文件，但是在YAML（JSON超集）中，你也有一个更简洁，更易于编程，更人性化的格式。

因此，对于数据表示，JSON全面击败XML。那么XML还剩下什么呢？混合内容文档表示，它是was intended for。

Answer 17

我发现this article at digital bazaar非常有趣。

文章的某些部分引用如下。

关于JSON专业人士：

  

如果您要传递的只是原子值或列表或哈希值   原子价值，JSON具有XML的许多优点：它是   通过互联网直接使用，支持各种各样的   应用程序，编写程序来处理JSON很容易，它很少   可选功能，它的设计清晰易读，相当清晰   是正式和简洁的，JSON文档很容易创建，它使用   Unicode格式。 ...

关于XML专业人员：

  

XML非常好地处理非结构化的丰富性   数据。即使它死了，我也不会担心XML的未来   一群网络API设计师高兴地庆祝。

     

我无法抗拒说“我告诉你了！”在我的   台。我期待看到JSON人们做什么   要求开发更丰富的API。当他们想要更好地交换时   结构化的数据，他们会把它变成JSON吗？我偶尔会看到   提到JSON的模式语言，其他语言会遵循吗？   ...

Answer 18

大多数较新的Web技术都使用JSON，因此最终使用JSON是一个很好的理由。一个很大的优点是，在XML中，您可以用多种不同的方式表示相同的信息，这在JSON中更直接。

JSON IMHO也比XML更清晰，这对我来说是一个明显的优势。如果你正在使用.NET，Json.NET是一个明显的赢家，可以帮助你使用JSON。

Answer 19

我在这里看到一些偏见教条。看来，针对xml的答案过于简化了，并且仅来自Web Development的上下文（这对问题是有意义的），因此我认为id提供了一些其他的见解，以防万一有人跨过此问题并需要数据的答案在其他情况下进行序列化。

这是硬性规定和快速规定：

毫无疑问，XML确实更强大。因此，当您的数据模型非常复杂而需要以下功能时，请使用它：

1. 对命名空间的支持
2. 支持面向对象，即继承/多态
3. 支持包含和可扩展性，以实现复杂类型的重用。
4. 需要一个可靠，成熟和完整的架构验证系统的支持。
   • w3c Schema验证系统具有更强大的JSON Schema功能，并且有更多文献可供学习。
5. 支持混合内容文档数据建模，并像数据建模一样记录。

JSON更易于学习，理解和使用。因此，当您没有时间学习XML并且不需要上述任何功能时，请使用它。如果这对您的用例来说很重要，那么它的重量也更轻巧。

TL：DR ，XML可以完成json可以做的所有事情，但是更重。反之则不正确。是的，Json更简单，因此使用了更多，但这并不意味着它可以代替XML。在我要面对2020年这一年的情况下，json并没有减少我们的用例，实际上我们需要XML。如果需要，我可以再谈更多。干杯，祝你好运。