【发布时间】：2010-10-09 18:10:31
【问题描述】：
json 与 xml 对 ajax 请求的优缺点是什么？ 性能上有区别吗？即浏览器是否能够比另一种更快地处理一种格式？
【问题讨论】：
标签： xml ajax json xmlhttprequest
【发布时间】：2010-10-09 18:10:31
【问题描述】：
总之，JSON（可以被认为是 JavaScript 的一个子集）比 XML 更精简。这有几个积极的副作用
- JSON 小于对应的 XML
- JSON 更快，即更简单的语法
->更容易解析（更快的解析）
在我对这个问题的最初回答中，我对 JSON 的看法是对 JavaScript 的看法，我认为它是近亲。但是 JSON 是独立的，JSON.org 在描述 JSON 方面做得很好。它还提供了一个 JavaScript 兼容性库，当浏览器不支持时，它增加了对 JSON.parse 和 JSON.stringify 的支持。
虽然 eval 在当时（2009 年年中）用于评估 JavaScript，但它也可以评估 JSON，即解析 JSON，但它被认为是不安全的，因为它允许任意 JavaScript 代替它执行。
由于它与 JavaScript 的密切关系，JSON 恰好非常适合浏览器，并且是一种发展平台的自然方式。
虽然 XML 可能被认为具有更好的严谨性，因为您可以键入它，但也正是这些东西使它变得慢了很多（我认为它也有点冗长）。但如果这是你真正想要的东西，你应该使用它，XML 同样无处不在。
我不会就动态或静态类型展开辩论，但我会这么说。在无架构数据之上添加内容真的很容易，并且有很多方法可以进行验证，无论架构或无架构。
【讨论】：
-
JSON 如何比 XML 更适合表示动态内容？
-
@John：您将解析与执行混为一谈。他们是两种不同的野兽。
-
@Guillaume and dirkgently - JSON 与浏览器脚本一起使用要简单得多。更适合将数据推送到客户端。我喜欢将 JSON 视为专门的 JavaScript，因为它可以让我从与 XML 不一样的服务器端代码发出行为。
-
@MagnusHoff 没有错，只是
JSON.toJSON和JSON.stringify最初并非所有主流浏览器都支持点。你绝对应该像 jQuery 和许多其他框架一样使用这些。但这不是 jQuery 最初的工作方式，因为当时的浏览器问题，jQuery 在当时是许多人的一大灵感，现在仍然如此。 -
我还冒昧地重写了我对这些 cmets 的回答，以反映对这个问题的更现代的看法。这些年来我也学到了一两件事......
到目前为止，我在讨论中还没有看到 XML 的一个优点是 XML 可以具有模式。这对于描述 XML 的结构非常有价值。对于简单的数据结构，JSON 和一些描述你在做什么的文本就可以了。在处理更复杂的数据结构时，或者当数据的创建者和消费者不是同一个团队时，拥有 Schema 可以大大帮助沟通。
此外，拥有架构意味着您可以验证数据，这在尝试调试复杂错误时可以挽救生命...
【讨论】：
-
模式并不总是严格要求的，尤其是为 NoSQL 工作！
您在这篇文章“The AJAX response: XML, HTML, or JSON?”中有关于该主题的完整辩论：
XML
-
优势
XML 最重要的优势在于它是其他人最容易阅读的格式。
第二个优势是 XML 已经存在了很长一段时间，并且许多开发人员已经习惯了它。 -
缺点
将数据插入 HTML 页面所需的 JavaScript 非常冗长。
JSON
-
优势
如果您将 JSON 文件作为新的<script>标签导入，那么最重要的优势是 JSON 绕过了 JavaScript 的同源策略。有关血腥细节，请参阅Simon Willison's example。
JavaScript 不允许您访问来自其他服务器的文档（无论是 XML 还是 HTML）。但是，如果您将 JSON 文件作为脚本标签导入，则可以规避此问题，并且可以将任何 JSON 数据导入任何网站。这是好事还是坏事取决于您的业务目标，但目前它是唯一允许无限制访问的数据格式。
第二个优势是 JSON 数据的脚本比 XML 数据的脚本更简单，更符合 JavaScript 语言的其余部分。 -
缺点
JSON 最重要的缺点是该格式很难被人类阅读，当然，每个逗号、引号和括号都应该在正确的位置。虽然 XML 也是如此，但 JSON 的大量看起来很复杂的语法，例如数据 sn-p 末尾的 }}]}，可能会吓到新手并导致复杂的调试。
从 cmets 来看，JSON 被认为比 XML 处理得更快。
【讨论】：
-
如果服务器端的设计考虑到了这种行为，那么将 XML 填充到 DOM 中就没有什么难的了。在服务器端做一点设计工作可以大大减少浏览器端的工作量。
-
这么荒谬的观点； JSON对于人类来说很难阅读吗？你真的还在用这个作为答案吗？ JSON 比 XML 更容易为人类阅读；普遍的事实。我无法相信这种说法是多么愚蠢！
尚未提到的 XML 的一个优点是，可以使用 XSLT 通过任意复杂的 XPath 表达式从 XML 文档中提取数据。我看不到在 JSON 中执行此操作的方法。无论对象在结构中出现的位置如何，如何在 JSON 文档中找到包含“货币”字段作为直接后代的所有对象？在带有 XSLT/XPath 的 XML 中，这非常容易。
但是，在浏览器中执行此操作是有代价的。您会遇到特定于浏览器的怪癖，而且它可能会更慢且更占用内存。
【讨论】：
-
“如何在 JSON 文档中找到包含“货币”字段作为直接后代的所有对象，而不管这些对象在结构中出现的位置如何？”与 XSLT 转换器一样，通过遍历结构并找到它们。仅仅因为没有众所周知的 JSON 转换器并不意味着不存在，或者它不如 XML 版本有用。
虽然我喜欢 Json 并且会推荐它，但我认为最佳处理速度之间没有根本区别。库和平台之间的差异更为显着：好的 xml 解析器比坏的 json 解析器更快，反之亦然。所以通常格式本身的性能并不是一个大因素。 两者都可以快速发光（Java 有一些很好的解析器，例如，其他语言可能也有）。
至于紧凑性，这取决于数据类型，Json 通常更紧凑，但并非完全如此。除非您有很多数组/列表，其中 json 表示法“{ ... }”比 xml 标记更紧凑（除非您尽可能使用空格，例如“1 2 3 4”）。
【讨论】：
链接提供了一个很好的差异概要（滚动到底部）。重点是：
JSON：更小，可以表示所有 unicode 字符（xml 不能在 UTF8 中，至少，根据它自己的规范）。在 AJAX 应用程序中使用它也很简单（因为 javascript 的 eval() 函数），尤其是更高级的功能，如 jsonp（响应调用回调）。
XML：有很多工具可以轻松查询其结构。由于它更老、更成熟，它通常也有更多的工具支持。
一般来说，他们可以完成同样的事情（你可以通过xml做jsonp，只需要手动解析回调）。
【讨论】：
-
我不同意您关于 XML 不能代表所有 Unicode 字符的说法。您只需将编码设置为 Unicode（“UTF-16”）。看看如何：w3schools.com/xml/xml_encoding.asp
-
哇，这是不久前的 :)。 XML中没有明确禁止的字符吗？我似乎肯定记得那些和 utf8 之间有一些重叠，不确定 utf16。我已经更新了我的答案，以反映它至少在 utf8 中。
您可能想阅读JSON: The Fat-Free Alternative to XML。使用 JSON，您可以在请求的源和目标之间来回进行回调，并在您现有的 Javascript 代码中实际使用它。
【讨论】：
-
链接坏了（至少对我来说...）
我认为 Json 的另一个优点是它不使用 括号，您可以将 html 代码放入其中而不会造成很多混乱。
【讨论】：
JSON 轻量级、AJAX 友好（被视为 Javascript 的子集）并且易于序列化。 XML 做这一切，但在喝了一些牛奶之后。
【讨论】：