从这些趋势中可以推断,JSON 的发展将统一 Web 的信息交流格式,XML 的利用率将连续降落。
我相信 JSON 很快就会在 Web 开拓中超过 XML。
至于其他领域,XML 比 JSON 更好的情形并不多。

-- Tom Strassner

简介

XML 和 JSON 是现今互联网中最常用的两种数据交流格式。
XML 格式由 W3C 于 1996 年提出。
JSON 格式由 Douglas Crockford 于 2002 年提出。
虽然这两种格式的设计目标并不相同,但它们常常用于同一个任务,也便是数据交流中。
XML 和 JSON 的文档都很完善( RFC 7159 、 RFC 4825 ),且都同时具有 人类可读性(human-readable)和 机器可读性(machine-readable)。
这两种格式并没有哪一个比另一个更强,只是各自适用的领域不用。
(LCTT 译注:W3C 是 互联网同盟 ,制订了各种 Web 干系的标准,如 HTML、CSS 等。
Douglas Crockford 除了制订了 JSON 格式,还致力于改进 JavaScript,开拓了 JavaScript 干系工具 JSLint 和 JSMin )

xmllist格式PHPXML 与 JSON 好坏比较 AJAX

XML 的优点

XML 与 JSON 比较有很多优点。
二者间最大的不同在于 XML 可以通过在标签中添加属性这一大略的方法来存储 元数据(metadata)。
而利用 JSON 时须要创建一个工具,把元数据当作工具的成员来存储。
虽然二者都能达到存储元数据的目的,但在这一情形下 XML 每每是更好的选择,由于 JSON 的表达形式会让客户端程序开拓职员误以为要将数据转换成一个工具。
举个例子,如果你的 C++ 程序须要利用 JSON 格式发送一个附带元数据的整型数据,须要创建一个工具,用工具中的一个 名称/值对(name/value pair)来记录整型数据的值,再为每一个附带的属性添加一个名称/值对。
吸收到这个 JSON 的程序在读取后很可能把它当成一个工具,可事实并不是这样。
虽然这是利用 JSON 通报元数据的一种变通方法,但他违背了 JSON 的核心理念:“ JSON 的构造与常规的程序措辞中的构造相对应,而无需修正。
(JSON’s structures look like conventional programming language structures. No restructuring is necessary.)” 1

虽然稍后我会说这也是 XML 的一个缺陷,但 XML 中对命名冲突、 前缀(prefix)的处理机制授予了它 JSON 所不具备的能力。
程序员们可以通过前缀来把统一名称给予两个不同的实体。
2 当不同的实体在客户端中利用的名称相同时,这一特性会非常有用。

XML 的另一个上风在于大多数的浏览器可以把它以 具有高可读性和强组织性的办法(highly readable and organized way)展现给用户。
XML 的树形构造让它易于构造化,浏览器也让用户可以自行展开或折叠树中的元素,这切实其实便是调试的福音。

XML 比拟 JSON 有一个很主要的上风便是它可以记录 稠浊内容(mixed content)。
例如在 XML 中处理包含构造化标记的字符串时,程序员们只要把带有标记的文本放在一个标签内就可以了。
可由于 JSON 只包含数据,没有用于指明标签的大略办法,虽然可以利用处理元数据的办理方法,但这总有点滥用之嫌。

JSON 的优点

JSON 自身也有很多优点。
个中最显而易见的一点便是 JSON 比 XML 简洁得多。
由于 XML 中须要打开和关闭标签,而 JSON 利用名称/值对表示数据,利用大略的 { 和 } 来标记工具,[ 和 ] 来标记数组,, 来表示数据的分隔,: 表示名称和值的分隔。
就算是利用 gzip 压缩,JSON 还是比 XML 要小,而且耗时更少。
3 正如 Sumaray 和 Makki 在实验中指出的那样,JSON 在很多方面都比 XML 更具上风,得出同样结果的还有 Nurseitov、Paulson、Reynolds 和 Izurieta。
首先,由于 JSON 文件天生的简洁性,与包含相同信息的 XML 比较,JSON 总是更小,这意味着更快的传输和处理速率。
第二,在不考虑大小的情形下,两组研究 45 表明利用 JSON 实行序列化和反序列化的速率显著优于利用 XML。
第三,后续的研究指出 JSON 的处理在 CPU 资源的利用上也优于 XML。
研究职员创造 JSON 在总体上利用的资源更少,个中更多的 CPU 资源花费在用户空间,系统空间花费的 CPU 资源较少。
这一实验是在 RedHat 的设备上进行的,RedHat 表示更方向于在用户空间利用 CPU 资源。
6 不出意外,Sumaray 和 Makki 在研究里还解释了在移动设备上 JSON 的性能也优于 XML。
7 这是有道理的,由于 JSON 花费的资源更少,而移动设备的性能也更弱。

JSON 的另一个优点在于其对工具和数组的表述和 宿主措辞(host language)中的数据构造相对应,例如 工具(object)、 记录(record)、 构造体(struct)、 字典(dictionary)、 哈希表(hash table)、 键值列表(keyed list)还有 数组(array)、 向量(vector)、 列表(list),以及工具组成的数组等等。
8 虽然 XML 里也能表达这些数据构造,也只需调用一个函数就能完成解析,而每每须要更多的代码才能精确的完成 XML 的序列化和反序列化处理。
而且 XML 对付人类来说不如 JSON 那么直不雅观,XML 标准缺少工具、数组的标签的明确定义。
当构造化的标记可以替代嵌套的标签时,JSON 的上风极为突出。
JSON 中的花括号和中括号则明确表示了数据的构造,当然这一上风也包含前文中的问题,在表示元数据时 JSON 不如 XML 准确。

虽然 XML 支持 命名空间(namespace)与 前缀(prefix),但这不代表 JSON 没有处理命名冲突的能力。
比起 XML 的前缀,它处理命名冲突的办法更简洁,在程序中的处理也更自然。
在 JSON 里,每一个工具都在它自己的命名空间中,因此不同工具内的元素名称可以随意重复。
在大多数编程措辞中,不同的工具中的成员可以包含相同的名字,以是 JSON 根据工具进行名称区分的规则在处理时更加自然。

大概 JSON 比 XML 更优的部分是由于 JSON 是 JavaScript 的子集,以是在 JavaScript 代码中对它的解析或封装都非常的自然。
虽然这看起来对 JavaScript 程序非常有用,而其他程序则不能直接从中获益,可实际上这一问题已经被很好的办理了。
现在 JSON 的网站的列表上展示了 64 种不同措辞的 175 个工具,它们都实现了处理 JSON 所需的功能。
虽然我不能评价大多数工具的质量,但它们的存在明确了开拓者社区拥抱 JSON 这一征象,而且它们切实简化了在不同平台利用 JSON 的难度。

二者的动机

大略地说,XML 的目标是标记文档。
这和 JSON 的目标想去甚远,以是只要用得到 XML 的地方就只管用。
它利用树形的构造和包含语义的文本来表达稠浊内容以实现这一目标。
在 XML 中可以表示数据的构造,但这并不是它的长处。

JSON 的目标是用于数据交流的一种构造化表示。
它直策应用工具、数组、数字、字符串、布尔值这些元向来达成这一目标。
这完备不同于文档标记措辞。
正如上面说的那样,JSON 没有原生支持 稠浊内容(mixed content)的记录。

软件

这些主流的开放 API 仅供应 XML: 亚马逊产品广告 API(Amazon Product Advertising API)。

这些主流 API 仅供应 JSON: 脸书图 API(Facebook Graph API)、 谷歌舆图 API(Google Maps API)、 推特 API(Twitter API)、AccuWeather API、Pinterest API、Reddit API、Foursquare API。

这些主流 API 同时供应 XML 和 JSON: 谷歌云存储(Google Cloud Storage)、 领英 API(Linkedin API)、Flickr API。

根据 可编程网络(Programmable Web) 9 的数据,最盛行的 10 个 API 中只有一个是仅供应 XML 且不支持 JSON 的。
其他的要么同时支持 XML 和 JSON,要么只支持 JSON。
这表明了大多数运用开拓者都更方向于利用支持 JSON 的 API,缘故原由大概是 JSON 更快的处理速率与良好口碑,加之与 XML 比较更加轻量。
此外,大多数 API 只是通报数据而非文档,以是 JSON 更加得当。
例如 Facebook 的重点在于用户的互换与帖子,谷歌舆图则紧张处理坐标和舆图信息,AccuWeather 就只通报景象数据。
总之,虽然不能说景象 API 在利用时究竟是 JSON 用的多还是 XML 用的多,但是趋势明确倾向了 JSON。
10 11

这些主流的桌面软件仍旧只是用 XML:Microsoft Word、Apache OpenOffice、LibraOffice。

由于这些软件须要考虑引用、格式、存储等等,以是比起 JSON,XML 上风更大。
其余,这三款程序都支持稠浊内容,而 JSON 在这一点上做得并不如 XML 好。
举例解释,当用户利用 Microsoft Word 编辑一篇论文时,用户须要利用不同的笔墨字形、笔墨大小、笔墨颜色、页边距、段落格式等,而 XML 构造化的组织形式与标签属性生来便是为了表达这些信息的。

这些主流的数据库支持 XML:IBM DB2、Microsoft SQL Server、Oracle Database、PostgresSQL、BaseX、eXistDB、MarkLogic、MySQL。

这些是支持 JSON 的主流数据库:MongoDB、CouchDB、eXistDB、Elastisearch、BaseX、MarkLogic、OrientDB、Oracle Database、PostgreSQL、Riak。

在很长一段韶光里,SQL 和关系型数据库统治着全体数据库市场。
像 甲骨文(Oracle)和 微软(Microsoft)这样的软件巨子都供应这类数据库,然而近几年 NoSQL 数据库正逐步受到开拓者的青睐。
大概是正巧碰上了 JSON 的遍及,大多数 NoSQL 数据库都支持 JSON,像 MongoDB、CouchDB 和 Riak 这样的数据库乃至利用 JSON 来存储数据。
这些数据库有两个主要的特性是它们适用于当代网站:一是它们与关系型数据库比较 更随意马虎扩展(more scalable);二是它们设计的目标便是 web 运行所需的核心组件。
12 由于 JSON 更加轻量,又是 JavaScript 的子集,以是很适宜 NoSQL 数据库,并且让这两个品质更随意马虎实现。
此外,许多旧的关系型数据库增加了 JSON 支持,例如 Oracle Database 和 PostgreSQL。
由于 XML 与 JSON 间的转换比较麻烦,以是大多数开拓者会直接在他们的运用里利用 JSON,因此开拓数据库的公司才有支持 JSON 的情由。
(LCTT 译注:NoSQL 是对不同于传统的关系数据库的数据库管理系统的统称。
参考来源 ) 13

未来

对互联网的各类变革中,最让人期待的便是 物联网(Internet of Things)(IoT)。
这会给互联网带来大量打算机之外的设备,例如腕表、温度计、电视、冰箱等等。
这一势头的发展良好,预期在不久的将来迎来爆发式的增长。
据估计,到 2020 年时会有 260 亿 到 2000 亿的物联网设备被接入互联网。
14 15 险些所有的物联网设备都是小型设备,因此性能比条记本或台式电脑要弱很多,而且大多数都是嵌入式系统。
因此,当它们须要与互联网上的系统交流数据时,更轻量、更快速的 JSON 自然比 XML 更受青睐。
16 受益于 JSON 在 web 上的快速遍及,与 XML 比较,这些新的物联网设备更有可能从利用 JSON 中受益。
这是一个范例的梅特卡夫定律的例子,无论是 XML 还是 JSON,抑或是什么其他全新的格式,现存的设备和新的设备都会从支持最广泛利用的格式中受益。

Node.js 是一款做事器真个 JavaScript 框架,随着她的出身与快速发展,与 MongoDB 等 NoSQL 数据库一起,让全栈利用 JavaScript 开拓成为可能。
这些都预示着 JSON 光明的未来,这些软件的涌现让 JSON 利用在全栈开拓的每一个环节成为可能,这将使运用更加轻量,相应更快。
这也是任何运用的追求之一,以是,全栈利用 JavaScript 的趋势在不久的未来都不会消退。
17

此外,另一个运用开拓的趋势是从 SOAP 转向 REST。
18 19 20 XML 和 JSON 都可以用于 REST,可 SOAP 只能利用 XML。

从这些趋势中可以推断,JSON 的发展将统一 Web 的信息交流格式,XML 的利用率将连续降落。
虽然不应该把 JSON 吹过分了,由于 XML 在 Web 中的利用依旧很广,而且它还是 SOAP 的唯一选择,可考虑到 SOAP 到 REST 的迁移,NoSQL 数据库和全栈 JavaScript 的兴起,JSON 卓越的性能,我相信 JSON 很快就会在 Web 开拓中超过 XML。
至于其他领域,XML 比 JSON 更好的情形并不多。

角注Introducing JSON ↩XML Tutorial ↩JSON vs. XML: Some hard numbers about verbosity ↩Comparison of JSON and XML Data Interchange Formats: A Case Study ↩A comparison of data serialization formats for optimal efficiency on a mobile platform ↩Comparison of JSON and XML Data Interchange Formats: A Case Study ↩A comparison of data serialization formats for optimal efficiency on a mobile platform ↩Introducing JSON ↩Most Popular APIs: At Least One Will Surprise You ↩Why JSON will continue to push XML out of the picture ↩Thousands of APIs Paint a Bright Future for the Web ↩Why JSON will continue to push XML out of the picture ↩How JSON sparked NoSQL – and will return to the RDBMS fold ↩A Simple Explanation Of ‘The Internet Of Things’ ↩Proofpoint Uncovers Internet of Things (IoT) Cyberattack ↩Why JSON will continue to push XML out of the picture ↩Why JSON will continue to push XML out of the picture ↩Thousands of APIs Paint a Bright Future for the Web ↩3,000 Web APIs: Trends From A Quickly Growing Directory ↩How REST replaced SOAP on the Web: What it means to you ↩

via: https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html

作者: TOM STRASSNER 选题: lujun9972 译者: wwhio 校正: wxy

本文由 LCTT 原创编译, Linux中国 名誉推出

点击“理解更多”可访问文内链接