什么时候比XML更喜欢JSON?

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

18 Solutions collect form web for “什么时候比XML更喜欢JSON?”

在以下任何一种情况下,通过JSON支持XML:

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

当所有这些都是真实的时候,赞成XML上的JSON:

  • 消息不需要validation,或validation它们的反序列化是简单的
  • 你不是在转换消息,或者转换他们的反序列化很简单
  • 你的信息主要是数据,而不是标记的文本
  • 消息传递端点具有良好的JSON工具

我使用JSON,除非我需要使用XML。 理解起来更简单,而且(因为它需要更less的configuration开销),如果库在您的上下文中可用,则更容易进行读写编程,而且现在它们非常普遍。

当亚马逊第一次将他们的目录作为Web服务公开时,他们提供了JSON和XML。 有90%的实施者select了JSON。

考虑到你已经在客户端做JavaScript的具体情况,我会去与JSON出于以下原因:

  • 由于JSON是原生的JavaScript,你不得不在客户端编写更less的代码 – 只要eval() (或者,更好的是, JSON.parse() )JSONstring并获得一个可以使用的对象。

  • 同时,在客户端评估JSON会更有效率,因此速度更快。

  • JSON序列化产生比XML更短的string。 使用JSON将减less跨networking运行的数据量,并提高这方面的性能。

这里有一些更深入的阅读: http : //www.subbu.org/blog/2006/08/json-vs-xml

我在XML vs JSON中遇到的其他一些问题:

JSON非常适合

  • 名称/值对
  • 嵌套这些对

这意味着它倾向于喜欢一个数组或嵌套数组。 但是,JSON缺失

  • 属性
  • 命名空间

因此,如果要合并两个或更多的JSON服务,则可能存在潜在的名称空间冲突。 这就是说,在我的经验交stream数据时,可以使用约90%的XML可用于XML。

通常JSON更紧凑,parsing速度更快。

如果符合以下要求

  • 您需要在客户端上处理数据,并且可以利用XSL。 XML + XSL链可能会比JSON + JavaScript更快,特别是对于大块数据。
    • 一个好的例子是将数据转换成HTML代码片段。
  • 各种遗留情况:
    • 有一个现有的XML服务,由于某些原因使用JSON重写它是一件麻烦事。
    • 您必须在使用用户的input进行一些简单处理之后,将这些数据作为XML发回。

(几乎)XML的一个重要情况:尝试检测发送HTML片段比发送原始数据更有用。 AHAH可以在简单的应用程序中创造奇迹,但经常被忽视。 通常,这种风格假定服务器发送HTML片段,这些片段将被内联在网页中而不进行处理。

通常情况下,在AHAH案例中,CSS被利用到最大程度上可视化地按摩片段,并实现简单的条件,例如使用用户特定或应用特定的设置来隐藏/显示片段的相关部分。

JSONparsing起来简单快捷。 XMLparsing起来有点困难,parsing和传输(大多数情况下)速度较慢。

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

客户端浏览器在分析数据时必须处理JSON。 而且,JSON是轻量级的数据交换格式。

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

如果我需要validation传入数据的块,我会selectXML over JSON,因为XML本身通过XSD支持。

我有一个关于这个主题的博客文章,详细介绍了Web协议(即SOAP,XML,JSON,REST,POX等)的历史,提供了一个总结以及每一个的优缺点: http : //www.servicestack.net / mythz_blog / p = 154

实际上,我认为通过比较dynamic(JSON)和静态(XML)语言之间的差异,可以在XML和JSON之间绘制出许多相似之处。

基本上XML是一个更严格,更严格的序列化格式,可以select使用随附的模式(即XSD或DTD)进行validation。 XSD是非常复杂的,允许你描述许多不同的types,例如date,时间,枚举,用户定义types,甚至是typesinheritance等。SOAP有效地build立在XML特性集之上,提供标准化的方式来描述你的Web服务例如types和操作)通过WSDL。 WSDL规范的冗长性和复杂性意味着开发起来可能更乏味,但同时还有更多的工具可供您使用,大多数现代语言都提供自动化工具来生成您的客户端代理,从而承担一些负担尝试与外部服务进行互操作时closures。 (尽pipe在处理频繁变化的Web服务时,我同时发现生成代理的负担本身)。

如果您有一个定义良好的“企业服务”,不需要频繁更改,或者您的Web服务需要使用多种不同的语言访问,那么我仍然build议使用XML来处理您的Web服务。

所有的好处XML也有缺点。 它依赖于命名空间来提供一个types化的可扩展格式,使您能够在同一个文档中指定属性和元素。 在一个文档中使用不同的名称空间意味着使用Xmlparsing器提取数据的时间很长,您还需要提供要检索/遍历的每个元素的名称空间。 它还推断有效载荷使其比需要的更冗长。 具有输出属性和元素的选项意味着您的类不能很好地映射到XML文档。 这些function本身就使得它对于大多数语言来说是一个糟糕的程序devise,使得它更加繁琐和繁琐。 微软已经在DataContract序列化程序中通过废除XML属性并仅仅将属性映射到Xml元素来认识和简化了这一点。

另一方面,JSON在很多方面与XML完全相反,因为它非常松散,只支持基本types:数字,布尔,string,对象和数组。 其他的东西基本上都要放在一个string中。 如果您想要支持更多特定的types,您将需要遵守一些带外的非标准规范,这在跨语言边界进行通信时并不是很好。 另一方面,有限的function集可以很好地适用于大多数语言,而且非常适合JavaScript,因为JSONstring可以直接评估为JavaScript对象。

大小和性能

我有一些Northwind数据库的基准testing可用来比较微软XML和JSON实现的大小和速度。 基本上XML是JSON的两倍多,但同时它看起来好像微软在优化他们的XML DataContractSerializer方面付出了很多的努力,因为它比JSON快了30%以上。 看来你必须在规模和性能之间进行权衡。 不满意这个事实,我决定编写我自己的快速JsonSerializer ,现在是MS的XML版本的2.6倍 – 这是两全其美的:)。

来自JSON – 最后一脚

当你走下JSON路线时,遇到了10年前XML面临的相同问题:

将来自两个不同源的数据混合成一个JSON数据包可能会导致元素标签相互碰撞。 把一个装箱单和一张发票混在一起,突然间,From地址可能意味着完全不同的东西。 这就是XML具有名称空间的原因。

在不同的JSON结构之间转换需要编写普通的代码。 映射数据的更具说明性的方式将使工作更容易。 这就是为什么XML有XSLT

描述一个JSON数据包的结构 – 它的字段,数据types等是必要的,以便人们能够接入到你的服务中。 为此需要有一个元数据语言。 这就是XML具有Schema的原因。

同时进行两个客户端 – 服务器对话需要注意。 如果你向服务器询问两个问题并得到一个回答,你怎么知道它回答什么问题? 这就是XML具有WS关联的原因。

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

可扩展标记语言(XML)是从标准通用标记语言(SGML)派生的文本格式。 与SGML相比,XML很简单。 超文本标记语言(HTML),相比之下,更简单。 即使如此,HTML上的一本很好的参考书是一英寸厚的。 这是因为文档的格式和结构是复杂的业务。 。 。 。

显然,JSON速度更快,但更难以阅读。 使用JSON的速度,使用XML,如果有人际交互,你可以牺牲速度。

JSON是javascript的本地编码。 这应该是更快,更容易合作。

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

Microsoft和Microsoft都支持XML和JSON。 XML文字是VB 9中新的酷炫function。在即将推出的ASP.NET 4.0版本中,JSON是必须利用客户端模板的强大function。

从你问的问题,似乎JSON可能是你的select,因为它是很容易处理客户端有或没有jQuery。

使用JSON

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

使用XML

  • 大多数情况下,在SOAtypes的环境中,您将在异构平台和技术上集成多项服务。
  • SOAP具有可以通过HTTP之外的其他协议传输的优点。
  • 易于在XSLT,XSL-FO等数据模型转换工具中使用
  • 很多数据库支持存储/查询(XQuery)XML数据。
  • XML是一种非常成熟的数据格式,因此您可以find大量工具来支持您可以想到的任何用例。

快速规则:

  • JSON:程序到程序的数据格式
  • YAML(JSON超集):人类到程序的数据格式
  • XML:文档标记格式

说明:

JSON的唯一作用是使用大多数编程语言通用的数据types( 列表哈希标量 )来序列化面向对象的数据,为此目的它真的不能被打败或改进。 为了“JSON没有版本号[因为]没有预期的JSON语法修订”。 – 道格拉斯·克罗克福德 ( Douglas Crockford ,作为一个标志,你完美地完成了你的工作)

XML曾经作为数据交换格式出售,但考虑两个最常见的用例: asynchronous客户端 – 服务器通信(AJAX) – JSON几乎完全取代了XML(X应该是J),而Web服务 :JSON已经使XML成为一种多余的select。

XML被广泛用于程序的人类可写/可读(?)数据文件,但在这里,您也可以在YAML(JSON超集)中使用更简洁,更易于编程,更加人性化的格式。

所以对于数据表示来说,JSON在整个板子上击败XML。 那么XML还剩下什么? 混合内容文档表示,这是它的目的 。

我在数字集市上发现这篇文章真的很有趣。

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

关于JSON优点:

如果你想要传递的是primefaces值或者primefaces值列表或哈希,JSON具有许多XML的优点:它可以直接在Internet上使用,支持各种应用程序,编写程序来处理JSON,它具有可选的特点,人性化,合理清晰,deviseforms简洁,JSON文档易于创build,使用Unicode。 …

关于XML优点:

XML非结构化数据的丰富性非常好。 我并不担心XML的未来,即使它的死亡是由一群Web APIdevise师高兴地庆祝的。

我无法抗拒“我已经告诉过你了!” 令牌在我的桌子。 我期待看到当JSON人们被要求开发更丰富的API时,他们会做些什么。 当他们想交换不太好的结构化数据时,他们会把它变成JSON吗? 我偶尔会看到JSON的模式语言,其他语言会跟着吗? …

大多数较新的Web技术使用JSON,所以使用JSON是一个很好的理由。 一个很大的好处是,在XML中,可以用多种不同的方式表示相同的信息,这在JSON中是更直接的。

另外JSON恕我直言是比XML更清晰,这使我有一个明显的优势。 如果你使用.NET,Json.NET是一个明显的赢家,可以帮助你使用JSON。

  • 用长行编辑xml文件在vim中确实很慢。 我能做些什么来解决这个问题?
  • Android百分比布局高度
  • XML架构:根元素
  • JAXB:如何在解组XML文档时忽略名称空间?
  • XPath如何处理XML名称空间?
  • .NET的XML序列化陷阱?
  • 使用java创buildXML文件
  • 未findJava类java.util.ArrayList ...和MIME媒体typestext / xml的消息正文编写器
  • XML是否区分大小写?
  • 使用JAXB从XMLstring创build对象
  • Android:在XML中调整imageview的大小