JSON和XML比较

我想知道哪个更快:XML和JSON?

375116 次浏览
小开

快不是JSON或XML的属性，也不是两者之间比较产生的结果。如果有，则是解析器的属性或传输数据的带宽。

以下是JSON和XML优缺点的列表(开头部分):

JSON

正方观点:

  • 简单的语法，与XML相比，这将导致更少的“标记”开销。
  • 易于与JavaScript一起使用，因为标记是JS对象文字表示法的一个子集，并且具有与JavaScript相同的基本数据类型。
  • JSON模式用于描述和数据类型和结构验证
  • 用于从深度嵌套结构中提取信息的JsonPath

反对:

  • 语法简单，只支持少数几种不同的数据类型。

  • 不支持评论。

XML

正方观点:

  • 通用标记;为任何目的创建“方言”都是可能的
  • XML模式用于数据类型、结构验证。也可以创建新的数据类型
  • XSLT用于转换成不同的输出格式
  • XPath/XQuery用于提取深度嵌套结构中的信息
  • 内置了对名称空间的支持

反对:

  • 与JSON相比相对冗长(导致相同数量的信息有更多数据)。

所以最后你必须决定你需要。显然，这两种格式都有其合法的用例。如果你主要使用JavaScript，那么你应该使用JSON。

请随意添加优点和缺点。我不是XML专家;)

小开
最佳答案

在回答什么时候用哪个之前，先了解一下背景:

edit:我应该提到的是，这种比较实际上是从在JavaScript浏览器中使用它们的角度进行的。这不是任何数据格式有的使用方式，有很多好的解析器会改变细节，使我所说的不太有效。

JSON既更紧凑，(在我看来)可读性更强——在传输方面，它可以“更快”，因为传输的数据更少。

在解析中，它取决于您的解析器。解析器将代码(无论是JSON还是XML)转换为数据结构(如地图)可能受益于XML的严格性质(XML模式很好地消除了数据结构的歧义)-然而在JSON中，可以从语法上推断项目的类型(字符串/数字/嵌套JSON对象)，例如:

myJSON = {"age" : 12,
"name" : "Danielle"}

解析器不需要足够智能就能意识到12表示一个数字(而Danielle和其他字符串一样是一个字符串)。所以在javascript中我们可以做到:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

在XML中，我们必须做如下的事情:

<person>
<age>12</age>
<name>Danielle</name>
</person>

(顺便说一句，这说明XML更加冗长;对数据传输的关注)。为了使用这些数据，我们将通过解析器运行它，然后我们必须调用如下命令:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

实际上，一个好的解析器可能会为你输入age(另一方面，你可能不希望它这样做)。当我们访问这个数据时，我们不是像上面的JSON示例那样做属性查找，而是在键name上做映射查找。这样的XML格式可能更直观:

<person name="Danielle" age="12" />

但我们仍然需要进行地图查找来访问我们的数据:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

编辑:原:

在大多数编程语言中(不是所有语言)，这样的映射查找比属性查找(就像我们上面解析JSON时得到的那样)代价更大。

这是误导:记住，在JavaScript(和其他动态语言)中，在映射查找和字段查找之间有没有区别。事实上，字段查找是只是一个映射查找。

如果您想要一个真正有价值的比较，最好是对其进行基准测试——在您计划使用数据的上下文中进行基准测试。

就在我打字的时候，Felix Kling已经给出了一个相当简洁的答案，就何时使用它们进行了比较，所以我就不再继续了。

小开

XML(可扩展标记语言)通常使用XHR，因为这是一种标准的广播语言，任何编程语言都可以使用它，并且同时支持服务器端和客户端，因此这是最灵活的解决方案。XML可以被分离成更多的部分，这样指定的小组就可以开发程序的一部分，而不影响其他部分。XML格式也可以由XML DTD或XML模式(XSL)确定，并且可以进行测试。

JSON是一种越来越受欢迎的数据交换格式，是JavaScript应用程序可能采用的格式。基本上这是一个对象符号数组。JSON具有非常简单的语法，因此很容易学习。JavaScript也支持使用eval函数解析JSON。另一方面，eval函数有负号。例如，程序解析JSON可能会非常慢，而且出于安全性考虑，eval可能非常危险。这并不意味着JSON不好，只是我们需要更加小心。

我的建议是，您应该将JSON用于具有少量数据交换的应用程序，如游戏。因为您不必真正关心数据处理，所以这非常简单和快速。

XML最适合大型网站，比如购物网站之类的。XML可以更安全、更清晰。您可以创建基本的数据结构和模式，以轻松地测试更正并轻松地将其分离为部分。

我建议您使用XML，因为它的速度和安全性，但JSON是轻量级的东西。

小开

关于JSON的重要事情是出于安全原因保持数据传输的加密。毫无疑问，JSON比XML快得多。我曾见过XML需要100毫秒，而JSON只需要60毫秒。JSON数据很容易操作。

小开

处理速度可能不是唯一相关的问题，然而，这就是问题所在，这里是基准测试中的一些数字:JSON vs. XML:一些关于冗长的硬性数字。为了提高速度，在这个简单的基准测试中，XML的开销比JSON高21%。

关于冗长有一个重要的注意事项，正如文章所说，这是最常见的抱怨:这在实践中并没有太大的相关性(XML和JSON数据通常都不是由人类处理的，而是由机器处理的)，即使出于速度的考虑，它也需要一些合理的更多时间来压缩。

此外，在这个基准测试中，处理了大量的数据，而典型的web应用程序不会传输这种大小的数据块，大到90MB，压缩可能没有好处(对于足够小的数据块，压缩后的块将比未压缩的块大)，因此不适用。

不过，如果不涉及压缩，显然更简洁的JSON在传输通道中的权重会更小，特别是通过WebSocket连接传输时，在这种情况下，没有经典的HTTP开销可能会使JSON的优势更加显著。

在传输之后，数据将被消耗，这将在整个处理时间中计算。如果要传输足够大或复杂的数据，由于缺乏由验证XML解析器自动检查的模式，可能需要对JSON数据进行更多检查;这些检查必须在JavaScript中执行，而JavaScript的速度并不是特别快，因此在这种情况下，它可能会在XML上产生额外的开销。

不管怎样，只有测试才能为您的特定用例提供答案(如果速度真的是唯一的问题，而不是标准、安全或完整性……)。

更新1:值得一提的是，EXI是二进制XML格式，它提供的压缩成本比使用Gzip低，并且节省了解压压缩XML所需的处理。EXI之于XML，就像BSON之于JSON。这里有一个快速的概述，包括一些空间和时间效率的参考:EXI:最后的二进制标准?。

更新2:也有一个二进制XML性能报告，由W3C进行，作为效率和低内存和CPU占用，也是XML领域的一个问题:高效的XML交换评估。

更新2015-03-01

在这个上下文中值得注意的是，HTTP开销作为一个问题被提出:IANA已经注册了EXI编码(上面提到的高效二进制XML)，作为HTTP协议的内容编码(与压缩， 缩小和gzip一起)。这意味着EXI是一个可以被其他HTTP客户端的浏览器理解的选项。看到超文本传输协议参数(iana.org)。

小开

我发现本文在数字集市真的很有趣。引用Norm的名言:

关于JSON的优点:

如果你想传递的只是原子值或列表或散列 原子值，JSON具有XML的许多优点:它是 可直接在互联网上使用，支持多种 应用程序，很容易编写程序来处理JSON，它有很少 可选功能，它是人类易读和合理清晰的设计 是正式和简洁的，JSON文档易于创建，并且它使用 Unicode…< / p >

关于XML的优点:

XML非常好地处理了非结构化的全部丰富性 数据。我一点也不担心XML的未来，即使它死了 是web API设计师们欢欣鼓舞的标志。

我忍不住把"我早告诉过你"的信物藏在我的 桌子上。我很期待看到JSON的人会做什么 要求开发更丰富的api。当他们想要交换的时候就不那么好了 结构化数据，他们会硬塞进JSON吗?我偶尔看到 提到JSON的模式语言，其他语言会跟进吗? …< / p >

我个人同意Norm的观点。我认为大多数针对XML的攻击都来自典型应用程序的Web开发人员，而不是真正的集成开发人员。但这只是我的观点!；）


提交答案