转载

JSON和XML：不可同日而语

【编者按】本文作者 Yegor Bugayenko 是 Teamed.io 公司的联合创始人，在软件质量和工程管理方法领域有深入的研究。本文中，作者通过对比 JSON ，向大家更详细地阐述了 XML 的四大特性，帮助大家在搭建项目时选择适合的数据格式类型。

很多人都在心里纠结，如果 JSON 和 XML 相比，谁更好谁更快？在接下来的新项目中到底选择哪一个？别傻了！完全没有可比性。就像自行车和 AMG S65 ，你能说哪个更好吗？虽然两者都是交通工具，但有些情况下，自行车反而更便捷。所以 JSON 和 XML 也一样，它们都各有所长，完全没有必要进行比较。

下面举一个简单的 JSON 数据（140个字符）：

{   "id": 123,   "title": "Object Thinking",   "author": "David West",   "published": {     "by": "Microsoft Press",     "year": 2004   } }

同样的数据在 XML 中会表示如下（167个字符）:

<?xml version="1.0"?>   <book id="123">     <title>Object Thinking</title>   <author>David West</author>   <published>     <by>Microsoft Press</by>     <year>2004</year>   </published> </book>

很容易看出其中的区别，前者更简洁更容易理解，而且能在JavaScript 中能完美解析。所以，我们便可以简单粗暴地放弃 XML 选择 JSON 了吗？谁还会需要已历时15年的重量级语言呢？

但恰恰相反，本人就非常喜爱 XML ，且听下文分解。

但千万别误会，本文并不是在反对 JSON 。 JSON 的确是很好的数据格式，但它仅仅只是一种数据格式，经常被临时用于将数据从 A 点传到 B 点。它比 XML 更简短易读，但仅此而已。

XML 是一种非常强大的语言，而非只是单纯的数据格式。相对于 JSON 和其他简单的数据格式来说，如 YAML ，XML 至少有以下四个重要特性。

XPath

为了从文档中得到上文类似的出版年份，只需要发送一个简单的 XPath 请求：/book/published/year/text() 。但是，必须得有一个 XPath 处理器来解析请求并返回2004。好就好在 XPath2.0是集 functions、predicates、axes 等为一体的强大检索引擎，在不用 Java 代码编写任何遍历的逻辑的情况下，就可以在 XPath 请求中以自然语言形式加入任何逻辑，例如，你可以直接发出请求 “How many books were published by David West in 2004?” ，便能通过 XPath 得到答案。而这是 JSON 所不能做到的。

Attributes and Namespaces

可以将 metadata 加到 XML 数据中，正如上面的 id 属性一样。数据保存在元素中，例如图书作者的姓名，而 metadata（数据的数据）应该保存为属性，这会大大有利于组织和结构化信息。最重要的是，元素和属性都可以标记为属于某个 namespaces ，当多个应用使用同一 XML 文档时，这种技术的优势会非常明显。

XML Schema

试想这样的情况，当你在一台机器上创建了 XML 文档，在其他电脑上做了数次修改，然后又传到别的电脑上使用，所以必须确保文档结构没有被中间操作所破坏。比如可能有人用保存出版日期，但别人又可能使用 ISO-8601 格式的。为了避免这样的结构混乱，我们可以创建一个说明文档 XML Schema ，和主文档一起进行保存。在每次操作主文档之前，都需要通过 schema 文件检查其正确性，这是生产过程中的一种集成测试。 RelaxNG 也是类似的机制，但会简单很多，如果觉得 XML Schema 太过复杂不妨尝试用 RelaxNG。

XSL

事实上，可以不用任何 Java/Ruby 等代码就能完成 XML 文档的修改。简单的说，你只需要创建一个 XSL transformation 文档并将其应用于原始 XML ，然后得到一个新的 XML 。 XSL 语言（纯功能性语言）是专为分层数据操作设计的，它比 Java 或任何其他面向对象/过程的语言都更适合这一任务。借助 XSL 可以将 XML 转换为任何形式，包括纯文本和 HTML 。很多人抱怨 XSL 太复杂，但其实没那么难， XSL 的核心功能其实很简单，大家不妨一试。

以上所述并不是 XML 的全部特征，但这四大特性的确用途非凡。它们不仅可以让文档的“自给自足”，还能进行自我验证（XML Schema），进而知道如何修改（XSL），最后还能方便地获得其中的文档内容（Xpath）。

同时，市面上还有很多以 XML 为基础发展的语言、标准和应用，包括 Xforms、 SVG、 MathML、 RDF、 OWL、 WSDL 等。但一般的主流项目中都不会用到，因为它们的针对性都太强。

设计 JSON 的用途并非是满足以上特性，尽管 JSON 领域现在努力尝试，包括用于查询的 JSONPath 、一些转换工具和用于验证的 json-schema ，但和强大的 XML 相比这只是微不足道的模仿，笔者并不认为会有长远发展，而且迟早会消失殆尽。

综上所述， JSON 是一种没有过多附加功能的简单数据格式，其最佳的使用情况是在 AJAX 下，除此之外，本人都强烈推荐大家使用 XML。

（编译自： https://dzone.com/articles/stop-comparing-json-and-xml ）

OneAPM 为您提供端到端的 Java 应用性能解决方案，我们支持所有常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本原因。分钟级部署，即刻体验，Java 监控从来没有如此简单。想阅读更多技术文章，请访问OneAPM 官方技术博客。

原文 http://news.oneapm.com/json-xml/

正文到此结束