何时更喜欢 JSON 而不是 XML？

Posted 2023-05-08

【中文标题】何时更喜欢 JSON 而不是 XML？

【英文标题】：When to prefer JSON over XML?

【发布时间】：2010-09-24 09:59:01

【问题描述】：

我的要求只是显示一组从数据库中检索到的值。我正在使用 jquery。

【参考方案1】：

当其中任何一个为真时，优先使用 XML 而非 JSON：

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

当所有这些都为真时，优先使用 JSON 而不是 XML：

消息不需要验证，或者验证它们的反序列化很简单 您不是在转换消息，也不是转换它们的反序列化很简单 您的消息主要是数据，而不是标记文本 消息传递端点具有良好的 JSON 工具

【讨论】：

JSON 在处理标记文本方面没有提供任何优于 XML 的优势。但我明白你的意思；这可能被夸大了。

当所有条件都相同时，支持 JSON 有两个原因：JSON 比 XML 更容易解析（CPU 友好），并且需要传输的数据少得多（网络友好）。

什么时候使用 XSLT 而不是 XML？如果您已经在使用 XSLT，那么 XML 是给定的。这不应该支持使用 XML 的论点。如果您使用 JSON.parse()，这就像说使用 JSON。另外，我认为转换 JSON 对象比编写 XSLT 转换更容易，但这可能是我个人的偏见。

我不完全同意 JSON 中的验证部分。 JSON 也是可验证的。检查这个 IETF 草案：link 这是一个草案，但仍然......

@sotn 你没有用于 JSON 的 PL/SQL 和 XML（例如 XQuery）。它是一些 NoSQL DB（eXist、MarkLogic Server、EMC Documentum xDB、BaseX、Zorba）的基础

【参考方案2】：

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

当亚马逊首次将他们的目录公开为一种网络服务时，他们同时提供了 JSON 和 XML。大约 90% 的实施者选择了 JSON。

【讨论】：

"除非需要使用 XML，否则我会使用 JSON。" ~ 没错。

所以更深层次的问题是“您需要使用 XML 的原因是什么？”这些理由是愚蠢的吗？还是它们只是从与您不同的角度反映了不同的担忧？

几个可能的原因，包括我不想重写的现有软件。但最重要的是使用 XML 作为数据交换格式，我不控制两端，或者有一个正式的标准适用并需要 XML。只有当我是唯一的开发者时，我才能任意选择。

【参考方案3】：

考虑到您已经在客户端执行 javascript 的特定情况，出于以下原因，我会使用 JSON：

因为 JSON 是 JavaScript 原生的 你必须在上面写更少的代码 客户端 - 只是 eval()（或者，更好的是，JSON.parse()）JSON 字符串并得到一个你可以的对象 使用。

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

JSON 序列化产生更短的 字符串比 XML。使用 JSON 将 减少运行的数据量 跨越电线并改善 在这方面的表现。

这里有一些进一步的阅读：http://www.subbu.org/blog/2006/08/json-vs-xml

【讨论】：

eval()ing JSON 不是一个大禁忌吗？

@Shy，JSON 自己的网站说你可以在 JSON 上使用 eval（用括号括起来）：json.org/js.html

取自 json.org：eval 函数非常快。但是，它可以编译和执行任何 JavaScript 程序，因此可能存在安全问题。当来源受信任且有能力时，指示使用 eval 。使用 JSON 解析器更安全

首选 JSON.parse() 而不是 eval()。

【参考方案4】：

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

JSON 非常适合

名称/值对 嵌套这些对

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

属性 命名空间

因此，如果您要组合两个或多个 JSON 服务，则可能存在潜在的命名空间冲突。话虽如此，根据我的经验，在交换数据时，JSON 可以用于大约 90% 的相同事情。

【讨论】：

Json 的另一个问题是你不能轻易合并两个 json 消息来创建一个新的 json 消息。它通常不会格式良好..

您需要哪些属性？如果您的元素包含其他值，请将其设为对象 - 成员是您的“属性”。坦率地说，我认为 XML 的分叉属性/容器结构完全有害。

我认为没有属性的 JSON 是一个特性。

【参考方案5】：

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

如果满足以下条件，则首选 XML：

您需要在客户端处理数据，您可以利用 XSL 来实现。 XML + XSL 链的运行速度可能比 JSON + JavaScript 更快，尤其是对于大块数据。 一个很好的例子是将数据转换为 HTML sn-p。 各种遗留案例： 已有一个 XML 服务，由于某些原因，用 JSON 重写它很麻烦。 您必须在使用用户输入进行一些轻量级处理后将此数据以 XML 格式发回。

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

通常在 AHAH 情况下，CSS 被最大限度地利用来直观地按摩 sn-ps 并实现简单的条件，例如使用特定于用户或特定于应用程序的设置隐藏/显示 sn-p 的相关部分。

【参考方案6】：

在客户端浏览器解析数据时必须执行的处理方面，JSON 总是更可取的。此外，JSON 是一种轻量级的数据交换格式。

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

【参考方案7】：

JSON 解析起来既简单又快捷。 XML 更难解析，解析和传输也更慢（在大多数情况下）。

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

【讨论】：

JSON 根据定义是一个 JavaScript 对象，jQuery 并没有真正做任何特殊的“转换”。只是觉得应该澄清一下。

JSON 不是 javascript 对象，除非它在 ​​javascript 中实例化。它恰好遵循用于序列化 javascript 对象的格式，但可以从大多数语言访问（使用适当的附加组件和内置），至少与 XML 一样容易。

@Gianforcaro，我意识到这一点。我将编辑我的帖子以更清楚地说明这一点。 @doofledorfer，我说“并将其转换为 Javascript 对象。”我没有说 JSON 数据是 Javascript 对象。

啊，抱歉，没听清楚。

【参考方案8】：

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

我实际上认为，通过比较动态 (JSON) 和静态 (XML) 语言之间的差异，您可以得出 XML 和 JSON 之间的许多相似之处。

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

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

尽管 XML 有其所有优点，但也有缺点。它依赖命名空间来提供类型化的可扩展格式，并使您能够在同一文档中指定属性和元素。 在一个文档中拥有不同的命名空间意味着在很多时候使用 Xml 解析器来提取数据时，您还需要提供要检索/遍历的每个元素的命名空间。它还推断有效负载，使其比需要的更详细。 可以选择输出属性和元素意味着您的类不能很好地映射到 XML 文档。仅这些功能就使其不适用于大多数语言的编程，使其使用起来更加乏味和麻烦。 Microsoft 已经在他们的 DataContract 序列化程序中认识到并简化了这一点，取消了 XML 属性，只将类的属性映射到 Xml 元素。

另一方面，JSON 在许多方面与 XML 完全相反，因为它的类型非常松散，并且仅对基本类型有简单的支持：数字、布尔值、字符串、对象和数组。其他一切本质上都必须放在一个字符串中。这在尝试跨语言边界进行通信时并不是很好，因为如果您想支持更具体的类型，您将需要遵守一些带外非标准规范。从好的方面来说，它有限的功能集可以很好地适应大多数语言 - 并且非常适合 JavaScript，因为 JSON 字符串可以直接eval'ed 到 JavaScript 对象中。

尺寸和性能

我有一些northwind database benchmarks available 比较 Microsoft 的 XML 和 JSON 实现之间的大小和速度。基本上 XML 的大小是 JSON 的 2 倍以上，但与此同时，微软似乎在优化他们的 XML DataContractSerializer 方面付出了很多努力 它比他们的 JSON 快 30% 以上。看来您必须在尺寸和性能之间进行权衡。对此事实不满意，我决定编写自己的快速JsonSerializer，它现在比 MS 的 XML 快 2.6 倍 - 两全其美:)。

【参考方案9】：

如果我需要验证传入的数据块，我会选择 XML 而不是 JSON，因为 XML 通过 XSD 原生支持这一点。

【参考方案10】：

from JSON - the last feet

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

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

不同JSON之间的转换 结构需要写作 平凡的代码。更具声明性的方式 映射数据将使工作更容易。 这就是 XML 具有 XSLT 的原因。

描述一个 JSON 数据包的 结构——它的字段、数据类型、 等等——对于人们来说是必要的 连接到您的服务。它的 拥有元数据语言必不可少 为了这。这就是 XML 具有 Schemas 的原因。

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

【讨论】：

命名空间只是另一种解决方法；如果你愿意，你可以在 JSON 中做同样的事情。 WS-Correlation 也是作为事后添加到 XML 中的，并不是“内置的”。您也可以将其添加到 JSON 中。结构描述（Schemas）不是 XML 特有的；自 eBNF 发明以来，您可以通过多种方式对任何形式语言进行此操作。不过，XSLT 是一个有效的卖点。

【参考方案11】：

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

【参考方案12】：

从http://json.org/xml.html的第一行开始

可扩展标记语言 (XML) 是一种源自标准通用标记语言 (SGML) 的文本格式。与 SGML 相比，XML 简单。相比之下，超文本标记语言 (HTML) 更加简单。即便如此，一本好的 HTML 参考书也只有一英寸厚。这是因为文档的格式化和结构化是一项复杂的业务。 . . .

显然 JSON 更快，但更清楚的是它难以阅读。 使用 JSON 以提高速度，如果需要人工交互，则使用 XML，您可以牺牲速度。

【讨论】：

你的回答并没有带来任何新的信息......但我想它仍然是真的

【参考方案13】：

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

【参考方案14】：

Microsoft 支持 XML 和 JSON。 XML 文字是 VB 9 中新的很酷的特性。在即将发布的 ASP.NET 4.0 版本中，必须使用 JSON 来利用客户端模板的强大功能。

从您提出的问题看来，JSON 可能是您的选择，因为它很容易在客户端使用或不使用 jQuery 进行处理。

【参考方案15】：

使用 JSON

如果数据要被浏览器中的 JavaScript 消费。 数据模型简单而不复杂（复合对象太多）。

使用 XML

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

【参考方案16】：

我发现this article at digital bazaar 真的很有趣。

下面引用了文章的部分内容。

关于 JSON 专家：

如果你想要传递的只是原子值或列表或散列 原子值，JSON 具有 XML 的许多优点： 可直接在 Internet 上使用，支持多种 应用程序，很容易编写程序来处理 JSON，它很少 可选功能，易于阅读且相当清晰，其设计 形式简洁，JSON 文档易于创建，并且它使用 统一码。 ...

关于 XML 专家：

XML 非常好地处理了丰富的非结构化 数据。即使 XML 死了，我也不担心 XML 的未来 受到一群 Web API 设计师的欢欣鼓舞。

而且我忍不住吐了一句“我告诉过你！”令牌在我的 桌子。我期待看到 JSON 人员在他们的时候会做什么 要求开发更丰富的 API。当他们想换得不好的时候 结构化数据，他们会将其硬塞到 JSON 中吗？我偶尔看到 提到 JSON 的模式语言，其他语言会跟随吗？ ...

【讨论】：

这个答案和提供的摘录完全歪曲了被引文章的主旨，它强烈支持 JSON。引用来自文章作者不同意的第三方。引用的文章是一本很好的读物 - 因此尽管存在虚假陈述，但不要对这个答案投反对票。

【参考方案17】：

快速规则：

JSON：

程序到程序的数据格式

YAML（JSON 超集）：

人机交互数据格式

XML：

文档标记格式

说明：

JSON 的唯一作用是使用大多数编程语言常见的数据类型来序列化面向对象的数据：lists、hashes 和 scalars ，为此目的，它确实无法被击败或改进。也就是说，“JSON 没有版本号 [as] 预计不会对 JSON 语法进行修订”。 - Douglas Crockford（不能把它作为你完美工作的标志）

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

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

因此，在数据表示方面，JSON 全面胜过 XML。那么，XML 还剩下什么？混合内容文档表示，这就是它was intended for。

【参考方案18】：

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

JSON 恕我直言也比 XML 更清晰，这对我来说是一个明显的优势。如果您正在使用 .NET，那么 Json.NET 无疑是帮助您使用 JSON 的赢家。

【参考方案19】：

我在这里看到了一些偏见教条。似乎对于 xml 和仅来自 Web 开发的上下文（这对问题有意义）而言，对此的答案过于简化，所以我认为 id 提供了一些额外的见解，以防万一有人越过这个问题并需要数据的答案其他上下文中的序列化。

以下是硬性规定：

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

支持命名空间 支持面向对象，即继承/多态 支持复杂类型重用的包含性和可扩展性。 可靠、成熟和完整的架构验证系统需要支持。 w3c Schema Validation 系统对 JSON Schema 的能力要强得多，并且有更多的文献可供学习。 支持混合内容文档数据建模和记录类数据建模。

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

TL:DR, XML 可以做 json 可以做的所有事情，但更重。反过来是不正确的。是的，Json 更简单，因此使用得更多，但这并不意味着它可以取代 XML。就我今年 2020 年的情况而言，json 没有为我们的用例做好准备，我们确实需要 XML。如果需要，我可以多谈。干杯，祝你好运。