您在哪些特定情况下使用JSON而不是XML？

Question

我还没有真正在现实项目中使用过JSON - 我几乎总是依赖XML。

Answer 1

每当我有选择时，我更喜欢JSON。它比XML更自我记录（假设没有模式），因为它区分：

• 记录（对象，命名子项，顺序不重要）和
• 列表（数组，编号子项，顺序很重要）。

在仅仅格式良好的XML中，这两件事通常都由元素表示。天真地，我们可能会考虑将XML子元素用于列表项，并将XML属性用于命名属性。但是，命名属性值只能是字符串，而不是任意嵌套结构。列表中子元素的元素名称通常是多余的。

XML简直不适合其最常见的应用程序（表示对象层次结构），而JSON更适合。

这并不令人惊讶，因为XML基于SGML，最初用于在纯文本流中应用标记 - 这是一个非常不同的应用程序。

Answer 2

任何时候你需要通过XHR调用移动大量数据。

我们已经开始将所有XHR调用转移到JSON，因为它比旧的XML格式小至少4倍。

现在有了像Firefox 3.5这样的浏览器，它具有原生JSON支持，使用起来更容易。

Answer 3

简而言之，JSON是一个不错的互操作选项，特别是对于javascript。如果它足够了，那么XML有什么意义呢？

对于更复杂的数据，json在我看来并不那么有利。 XML可能不那么“高效”，但我很少遇到任何问题 - 但是xml中元素的强制命名意味着它通常很容易调试 - 对于跨越多个组织的项目尤其如此 - B2B互相说，互相说。 XML具有更好的工具，包括XSLT，XSD，集成到多种语言（VB.NET的原生XML，比如LINQ to XML），而且更自然地“开放” - 使用新元素扩展XML更容易，而不会中断旧模式，而json中的列表包含未命名的项，使更多可能发生功能冲突。当然，你可以在JSON中解决所有这些问题，但这需要远见和规划工作。最后，虽然大多数语言都有不错的XML支持，但javascript特别没有，除非你使用一些帮助函数，否则构建XML会很痛苦（DOM在这里没有赢得任何设计奖品）。

总之;我使用XML进行所有数据交换，并且可能是长期复杂的API，而json专门用于轻量级客户端服务器，不需要严格的API，因此xml与OO的不完美匹配和稍重的重量传输是一种阻力。没有任何好处。如果您要快速进行AJAX更新，JSON可以正常工作，并且可以避免OO / XML阻抗不匹配（并且较小的序列化是锦上添花）。

我从来没有在一个足够大的应用程序上工作，其中JSON的带宽节省产生了影响，但如果你是谷歌或微软，我相信这也是一个重要的好处（你可能需要无论如何，无论如何花费大量的计划和远见，因为无论如何，你发布的任何API都会迅速成为一种依赖。）

Answer 4

• 很容易
• 通过调用eval（）将字符串转换为javascript对象很简单，但要小心。有关eval（）的详细信息，请查看this question。
• 您不必解析XML（在某些情况下可能意味着性能提升）。

但是，你放弃了XML提供的一些很好的兼容性。

Answer 5

对我来说，JSON更容易使用，更低的开销，更容易操作，对我而言，我选择的dojo + PHP工具更容易从服务器获取数据并将其集成到UI中。 / p>

Answer 6

始终。对于我目前参与的所有项目，我使用JSON。

http://www.techyouruniverse.com/software/json-vs-xml-vs-serialize-for-data是一个非常可靠的资源，为什么（不是我的网站）。

这是一个很好，简单，快速的方法来集成php和JavaScript。它也是在网站中存储网站用户偏好的绝佳方式。

Answer 7

JSON是一种更简单的数据格式。即使在如许多SOAP Web服务中使用的具有Schema的XML这样的良好指定的XML中，数据类型的互操作性也很困难。即使是普通整数和布尔值也会导致互操作问题，而更复杂的结构（如带有可选值的嵌套数组）很难在不同类型的系统中工作。 JSON是一个非常简单明确指定的类型系统，它似乎更容易互操作。

XML的另一个重要缺点是解析复杂性会导致安全问题。简单的XML很简单。但是大多数XML库都会解析完整的XML，包括PI和DTD以及实体扩展。很容易错误地使用这些XML库，导致XXE vulnerabilities等。如果只是将JSON数据eval（）作为代码，也可以不安全地使用JSON。但是有很多易于使用的JSON解析库可以将JSON数据安全地视为数据，而不是代码。

Answer 8

1. 小得多的开销
2. 更易于阅读
3. 使用标题“application / json”
在Firebug中自动格式化