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

我的需求仅仅是显示一组从数据库中检索到的值，我使用的是 jquery。

39378 次浏览
小开

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

小开

JSON 易于解析且速度更快。XML 比较难解析，而且解析和传输(在大多数情况下)比较慢。

因为您使用的是 jQuery，所以我建议使用 JSON: jQuery 可以检索 JSON 数据并将其自动转换为 Javascript 对象。事实上，你可以 使用 eval 将 JSON 数据转换为 Javascript 对象。XML 必须由您手动进行转换(我不知道在 Javascript 中这是如何工作的，但是在我使用 XML 库的大多数语言中，这是很困难的/更烦人的)。

小开

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

当 Amazon 第一次将他们的目录作为 Web 服务公开时，他们同时提供了 JSON 和 XML。大约90% 的实现者选择了 JSON。

小开

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

小开

考虑到您在客户端已经使用了 javascript 的特殊情况，我选择 JSON 的原因如下:

  • 因为 JSON 是 javascript 的本机 您必须在 客户端-只需要 eval()(或者更好的是 JSON.parse()) JSON 字符串，并得到一个对象，你可以 使用

  • 同时在 客户端会更多 效率高，因此速度更快

  • JSON 序列化产生的时间更短 使用 JSON 将 减少运行的数据量 并且提高 在这方面的表现

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

小开

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

如果:

  • 您需要在客户机上处理数据，并且可以利用 XSL 来实现这一点。XML + XSL 链可能比 JSON + JavaScript 工作得更快，特别是对于大块数据。
    • 一个很好的例子是将数据转换成 HTML 片段。
  • 各类遗留个案:
    • 有一个现有的 XML 服务，由于某些原因，用 JSON 重写它很麻烦。
    • 在使用用户输入进行一些简单的处理之后，您必须将这些数据作为 XML 发回。

(几乎) XML 的一个重要情况是: 尝试检测何时发送 HTML 代码片段比发送原始数据更有益。啊哈可以在简单的应用程序中创造奇迹，但经常被忽视。通常，这种风格假设服务器发送 HTML 片段，这些片段将内联在网页中而无需处理。

通常在 AHAH 情况下，CSS 被最大限度地用于可视化地按摩代码片段，并实现简单的条件，比如使用特定于用户或特定于应用程序的设置隐藏/显示代码片段的相关部分。

小开

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

小开
最佳答案

如果以下任何一条是正确的，请选择 XML 而不是 JSON:

  • 您需要消息验证
  • 您正在使用 XSLT
  • 你的短信里有很多标记过的文字
  • 您需要与不支持 JSON 的环境进行互操作

当所有这些都成立时，优先选择 JSON 而不是 XML:

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

我在 XML 与 JSON 领域遇到的其他一些问题:

JSON 非常适合

  • 名称/值对
  • 在这些对中筑巢

这意味着它倾向于喜欢一个数组或嵌套数组

  • 属性
  • 命名空间

因此，如果要组合两个或多个 JSON 服务，可能存在潜在的名称空间冲突。也就是说，根据我的经验，JSON 可以用于大约90% 的 XML 用于交换数据的事情。

小开

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

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

小开

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

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

小开

从 JSON-最后的脚

当您沿着 JSON 路线前进时，您 遇到与 XML 相同的问题 10年前面临的问题:

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

在不同的 JSON 之间转换 结构需要书写 世俗的代码，一种更具声明性的方式 地图数据会使工作更容易。 这就是为什么 XML 有 XSLT。

描述 JSON 数据包的 结构ーー其字段、数据类型、, 对人们来说是必要的 你的服务。这是 拥有元数据语言的必要条件 这就是为什么 XML 有 模式。

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

小开

我有一篇关于 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 服务时，生成的代理本身也是一种负担)。

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

尽管 XML 有诸多好处，但也有不足之处。它依赖于命名空间来提供类型化的可扩展格式，并允许您在同一文档中指定属性和元素。 在一个文档中使用不同的名称空间意味着在使用 Xml 解析器提取数据时，需要提供想要检索/遍历的每个元素的名称空间。它还可以外推有效载荷，使其比实际需要的更加冗长。 具有输出属性和元素的选项意味着您的类不能很好地映射到 XML 文档。仅仅这些特性就使它不适合大多数语言的编程，从而使其工作起来更加乏味和麻烦。微软已经在他们的数据合同序列化器中认识到并简化了这一点，方法是去掉 XML 属性，只将类的属性映射到 XML 元素。

另一方面，JSON 在许多方面与 XML 完全相反，因为它的类型非常松散，只支持基本类型: Number、 Bool、 string、 Objects 和 Array。其他所有东西基本上都要放在一个字符串中。当试图跨语言边界进行通信时，这不是很好，因为如果您想要支持更具体的类型，就需要遵守一些带外的非标准规范。从好的方面来看，它有限的特性集非常适合大多数语言，而且非常适合 JavaScript，因为 JSON 字符串可以直接将 评估过了转换为 JavaScript 对象。

尺寸和性能

我有一些 可用的 northwind 数据库基准测试来比较微软 XML 和 JSON 实现之间的大小和速度。基本上 XML 的大小是 JSON 的2倍以上，但是同时看起来微软在优化他们的 XML DataContractSerializer 方面投入了很多精力 它比他们的 JSON 快30% 以上。似乎你必须在规模和性能之间做出权衡。不满意这个事实，我决定编写我自己的快速 JsonSerializer，它现在比 MS 的 XML 快2.6倍——所以这两个世界都是最好的:)。

小开

使用 JSON

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

使用 XML

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

我觉得 这篇数码集市上的文章很有趣。

下面引用了文章的一些部分。

关于 JSON 专家:

如果要传递的全部内容是原子值、列表或 原子值，JSON 具有 XML 的许多优点: 它是 可直接通过互联网使用，支持各种各样的 应用程序，它很容易编写程序来处理 JSON，它有很少 可选的功能，它的人类-清晰，相当清楚，它的设计 JSON 文档是正式和简洁的，易于创建，并且它使用 Unicode...

关于 XML 优点:

XML 非常好地处理了非结构化的丰富内容 data. I’m not worried about the future of XML at all even if its death 被一群 Web API 设计者欢欣鼓舞地庆祝着。

我忍不住把一句“我早就告诉过你”塞进我的 我期待着看到当 JSON 的家伙们在做什么的时候 要求开发更丰富的 API 结构化数据，他们会把它硬塞进 JSON 吗 提到 JSON 的模式语言，其他语言会跟随吗？ ...

小开

快速规则:

  • JSON: program-to-program 数据格式
  • YAML (JSON 超集) : 人对程序数据格式
  • XML: 文档标记格式

说明:

JSON 的唯一作用是使用大多数编程语言通用的数据类型(清单、 大麻和 标量)来序列化面向对象的数据，在这方面，它确实不能被打败或改进。也就是说“ JSON 没有版本号[因为]预计不会对 JSON 语法进行修订”。- 道格拉斯·克罗克福特(无法否认这是你完美完成工作的标志)

XML 曾经作为数据交换格式出售，但是考虑两个最常见的用例: 异步客户机-服务器通信(AJAX)-JSON 几乎完全取代了 XML (X 应该是 J) ，而且 网上服务: JSON 使 XML 成为一个多余的替代品。

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

因此，对于数据表示，JSON 在所有方面都胜过 XML。那么 XML 还剩下什么呢？混合内容的文档表示，也就是它的 是为了。

小开

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

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

显然 JSON 更快，但更明显的是它很难阅读。 使用 JSON 来提高速度，如果需要人机交互，可以使用 XML，而且可以牺牲速度。

小开

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

而且 JSON IMHO 比 XML 更清晰，这使得它对我来说是一个明显的优势。如果你和。NET，JSON.NET 是一个明显的赢家，可以帮助您使用 JSON。

小开

我在这里看到了一点偏见教条。对于 xml 来说，这个问题的答案似乎过于简单，而且只来自 Web 开发的上下文(这对这个问题来说是有意义的) ，所以我认为 id 提供了一些额外的见解，以防有人越过这个问题，需要在其他上下文中解决数据序列化问题。

以下是严格的规则:

毫无疑问，XML 更加强大。因此，当您的数据模型足够复杂以至于需要以下特性时，可以使用它:

  1. 对命名空间的支持
  2. 支持面向对象即继承/多态
  3. 支持复杂类型重用的包含性和可扩展性。
  4. 可靠、成熟和完整的模式验证系统所需的支持。
    • W3c 模式验证系统对 JSON 模式的能力要强得多，并且有更多的文献可以学习。
  5. 支持混合内容文档数据建模和记录类似的数据建模。

JSON 更容易学习、理解和使用。因此，当您没有时间学习 XML 并且不需要以上任何特性时，可以使用它。它在线上也更轻量级，如果这对您的用例很重要的话。

TL: DR， XML 可以做 json 能做的所有事情，但是它更重一些。反过来就不对了。是的，Json 更简单，因此使用更多，但这并不意味着它可以取代 XML。在我今年要面对的情况下，2020年，json 没有达到我们的用例要求，我们确实需要 XML。如果需要的话，我可以多说一些。干杯，祝你好运。


提交答案