JSON 的崛起

译者：runningwater

JSON 已经占领了世界。今天，当任何两个应用程序通过互联网相互通信时，你可以肯定它们正在使用 JSON。它已被所有大公司采用：在十大最受欢迎的 Web API 接口列表中（主要由 Google、Facebook 和 Twitter 提供），只有一个 API 接口以 XML 格式公开数据。1 此列表中的 Twitter API 是一个生动的注脚：它对 XML 格式的支持已于 2013 年结束，当时发布了新版本的 API，删除了 XML 格式并仅切换到 JSON。JSON 也在编程级别和文件存储中被广泛采用：在 Stack Overflow（LCTT 译注：一个面向程序员的问答网站）上，现在关于 JSON 的问题比任何其他数据交换格式都多。2

XML 仍然存在于许多地方。它在网络上用于 SVG 和 RSS/Atom 信息流。当 Android 开发人员想要获得用户许可时，他们需要在其 APP 的清单文件中声明它——这个文件是 XML 格式的。XML 的替代品不止 JSON。现在很多人在使用 YAML 或 Google 的 Protocol Buffers 等技术，但这些技术远不如 JSON 流行。目前，JSON 是应用程序在网络之间进行通信的首选协议格式。

你可以理解为什么 JSON 的主导地位如此令人惊讶，因为自 2005 年以来，网络编程界一直对“异步 JavaScript 和 XML”而非“异步 JavaScript 和 JSON”的潜力垂涎三尺。当然，这可能与这两种通信格式的流行程度无关，而只是反映了首字母缩略词“AJAX”似乎比“AJAJ”更有吸引力。但即使有些人（实际上不是很多人）在 2005 年就已经用 JSON 替换 XML，我们也很难不去想 XML 的末日为何来得如此之快，以至于在短短十年左右的时间里，“异步 JavaScript 和 XML”这个名字就成了一个具有讽刺意味的误称。那么在这十年里发生了什么？JSON 是如何在如此多的应用程序中取代 XML 的？谁想出了现在全球工程师和系统使用和依赖的数据格式？

JSON 的诞生

2001 年 4 月，第一条 JSON 格式的消息从旧金山湾区车库里的一台计算机发出，这是计算机历史上具有开创性意义的时刻。技术咨询公司 State Software 的联合创始人道格拉斯·克罗克福德 (Douglas Crockford) 和奇普·莫宁斯塔 (Chip Morningstar) 聚集在莫宁斯塔的车库里测试一个想法。

在“AJAX”一词诞生之前，Crockford 和 Morningstar 就试图构建一个可用的 AJAX 应用程序，但浏览器与之不太兼容。他们希望在初始页面加载后将数据传递给应用程序，但针对所有浏览器使这变得不可能。

今天看来这似乎难以置信，但请记住，2001 年 Internet Explorer (IE) 代表了 Web 浏览器技术的前沿。早在 1999 年，Internet Explorer 5 支持 XMLHttpRequest 的原始形式，开发人员可以使用名为 ActiveX 的框架访问它。Crockford 和 Morningstar 能够使用这项技术（在 IE 中）检索数据，但此解决方案在 Netscape 4（他们想要支持的另一款浏览器）中不可用。Crockford 和 Morningstar 必须使用不同的系统来适应不同的浏览器。

第一个 JSON 消息如下所示：

该消息只有一小部分类似于我们今天所熟知的 JSON，它本身就是一个包含一些 JavaScript 的 HTML 文档。类似 JSON 的部分只是传递给名为 accept() 的函数的 JavaScript 对象文字。

Crockford 和 Morningstar 决定滥用 HTML 的 frames() 来发送数据。他们可以有一个指向返回上述 HTML 文档的 URL 的框架。收到 HTML 后，JavaScript 代码段将运行，数据对象文字将按原样传回应用程序。只要小心绕过浏览器保护（即不允许子窗口访问父窗口），此技术就可以正常工作。您可以看到 Crockford 和 Morninginstar 通过明确设置文档域实现了他们的目标。（这种基于框架的技术有时称为隐藏框架技术，在 20 世纪 90 年代后期广泛使用，当时 XMLHttpRequest 技术尚未广泛使用。3）

第一条 JSON 消息引人注目之处在于，它显然不是首次使用新的数据格式。它是 JavaScript！事实上，以这种方式使用 JavaScript 的想法非常简单，以至于 Crockford 本人说他并不是第一个这样做的人。他说，Netscape 的某个人早在 1996 年就使用 JavaScript 数组文字来交换信息。4 因为消息只是 JavaScript，所以不需要任何特殊的解析；JavaScript 解释器会处理一切。

原始的 JSON 消息实际上与 JavaScript 解释器发生了冲突。JavaScript 保留了大量的关键字（ECMAScript 6 有 64 个保留字），而 Crockford 和 Morningstar 在他们的 JSON 中意外使用了一个保留字。他们使用 do 作为键名，但 do 在解释器中是一个保留字。由于 JavaScript 使用了如此多的保留字，Crockford 做出了一个决定：既然这些保留字是不可避免的，那么所有 JSON 键名都应该用引号引起来。被引号括起来的键名将被 JavaScript 解释器识别为字符串，这意味着那些保留字也可以安全地使用。这就是今天 JSON 键名被引号括起来的原因。

Crockford 和 Morningstar 意识到这项技术可以应用于各种应用系统。他们想将其命名为“JSML”，即 JavaScript 标记语言，但发现这个缩写已经被一种叫做 Java Speech 标记语言的东西使用。于是他们决定使用“JavaScript Object Notation”，缩写为 JSON。他们开始向客户销售，但很快发现客户不愿意冒险使用缺乏官方规范的未知技术。于是 Crockford 决定写一份规范。

2002 年，Crockford 购买了 JSON.org 域名，并在上面贴出了 JSON 语法示例和解释器。该网站目前仍在运行，并且现在包含一个指向 2013 年正式批准的 JSON ECMA 标准的显眼链接。网站建立后，Crockford 并没有过多地推广它，但很快发现许多人都在用各种编程语言提交 JSON 解析器实现。JSON 的血统显然与 JavaScript 有关，但很明显，JSON 非常适合不同语言之间的数据交换。

AJAX 造成的误解

JSON 在 2005 年迎来了突破性发展。那一年，一位名叫 Jesse James Garrett 的网页设计师兼开发人员在一篇博客文章中创造了“AJAX”一词。他小心翼翼地强调，AJAX 不是一项新技术，而是“几种新兴技术以强大的新方式结合在一起”。5 AJAX 是 Garrett 为一种开发越来越流行的 Web 应用程序的新方法所起的名字。他的博客文章继续描述了开发人员如何使用 JavaScript 和 XMLHttpRequest 构建比传统网页响应更快、状态更丰富的新型应用程序。他还引用了 Gmail 和 Flickr 作为已使用 AJAX 技术的网站示例。

当然，“AJAX”中的“X”代表 XML。但在随后的问答帖中，Garrett 指出 JSON 是 XML 的完美替代品。他写道：“虽然 XML 是 AJAX 客户端数据输入和输出最成熟的技术，但使用 JavaScript 对象表示法 (JSON) 等技术或任何类似的数据结构化方法也可以实现相同的效果。”6

开发人员确实发现在构建 AJAX 应用程序时使用 JSON 很容易，许多人更喜欢它而不是 XML。具有讽刺意味的是，对 AJAX 的兴趣导致了 JSON 的流行。大约在这个时候，JSON 引起了博客圈的关注。

2006 年，多产博主、RSS 和 XML-RPC 等多项基于 XML 的技术的开发者 Dave Winer 抱怨说，JSON 无疑正在重新发明 XML。尽管有人认为数据交换格式之间的竞争不会导致一项技术的消亡，但他写道：

我当然可以编写一个例程来解析 JSON，但看看当由于某种原因 XML 本身对他们来说不够好时，他们重新发明一些东西需要多大意义（我很想知道为什么）。谁想做这种无稽之谈？查找一棵树并将节点串在一起。现在就试试吧。

我理解 Winer 的沮丧。事实上，没有多少人喜欢 XML。甚至 Winer 也说过他不喜欢 XML。8 但 XML 的设计初衷是任何人都可以使用，几乎可以用于任何可以想象到的东西。毕竟，XML 是一种元语言，允许您为特定应用程序定制特定领域的语言。示例包括 RSS 和 SOAP（简单对象访问协议），它们是 Web 信息流技术。Winer 认为，争取共识很重要，因为通用交换格式有很多好处。XML 的灵活性应该足以满足任何人的需求，然而，JSON 格式除了抛弃了使 XML 更灵活的杂乱内容之外，并没有提供比 XML 多得多的功能。

Crockford 阅读了 Winer 的文章并发表了评论。针对 JSON 重新发明 XML 的指控，Crockford 写道：“重新发明轮子的好处是，你最终会得到一个更好的轮子。”9

JSON 与 XML

到 2014 年，JSON 已获得 ECMA 标准和 RFC 的正式认可。它有自己的 MIME 类型。JSON 已进入大联盟。

为什么 JSON 比 XML 更受欢迎？

在 JSON.org 网站上，Crockford 总结了 JSON 的一些优点。他写道，JSON 的语法简洁、结构可预测，使人类和机器更容易理解。10 其他博主则关注 XML 的冗长和“尖括号负担”。11 XML 中的每个开始标记都必须与结束标记匹配，这意味着 XML 文档包含大量冗余信息。未压缩时，XML 文档比信息量相同的 JSON 文档大得多，但更重要的是，这也使 XML 文档更难阅读。

Crockford 还声称 JSON 的另一大优势在于它被设计为一种数据交换格式。12 从一开始，它的目的就是在应用程序之间传递结构化信息。另一方面，XML 也可以用来传递数据，但它最初被设计为一种文档标记语言。它由 SGML（标准通用标记语言）演变而来，而后者又由一种名为 Scribe 的标记语言演变而来，后者原本打算成为像 LaTeX 这样的文本处理系统。在 XML 中，标记可以包含所谓的“混合内容”，即带有围绕单词和短语嵌入标记的文本。这让人想起用红色和蓝色笔书写的手稿的形象，这是对标记语言核心思想的生动隐喻。另一方面，JSON 不支持明确的混合内容模型，但这也意味着它的结构足够简单。 一个文档最好被建模为一棵树，但是 JSON 放弃了这个文档的思想，Crockford 将 JSON 抽象限制为字典和数组，这是所有程序员在构建程序时使用的最基本和最熟悉的元素。

最后，我认为人们不喜欢 XML 是因为它令人困惑。它之所以令人困惑，是因为有太多不同的风格。乍一看，XML 本身与其子语言（如 RSS、ATOM、SOAP 或 SVG）之间的界限并不清晰。典型的 XML 文档的第一行标识了 XML 的版本，然后 XML 文档应该符合特定的子语言。有一些变化需要考虑，特别是与 JSON 相比，JSON 非常简单，以至于永远不需要编写新版本的 JSON 规范。XML 的设计者试图让 XML 成为统治它们所有的唯一数据交换格式，并陷入了经典的程序员陷阱：过度工程。XML 非常通用和概念化，因此很难简单地使用。

2000 年，发起了一场让 HTML 符合 XML 标准的运动，并发布了符合 XML 标准的 HTML 开发规范，这就是后来著名的 XHTML。尽管一些浏览器制造商立即开始支持新标准，但很明显，大多数基于 HTML 技术的开发人员不愿意改变他们的习惯。新标准要求对 XHTML 文档进行严格验证，而不是基于 HTML 基准。但大多数网站都依赖于 HTML 的宽松规则。到 2009 年，编写第二版 XHTML 标准的尝试已经流产，因为很明显 HTML 的未来将演变为 HTML5（不强制执行 XML 规则的标准）。

如果 XHTML 的努力成功了，XML 可能就会成为其设计者所期望的通用数据格式。想象一下这样一个世界，其中 HTML 文档和 API 响应具有完全相同的结构。在这样的世界里，JSON 可能不像今天这样无处不在。但我认为 HTML 的失败是 XML 阵营的道德失败。如果 XML 不是 HTML 的最佳工具，也许会出现更好的工具用于其他应用程序。在那个世界，也就是我们的世界里，很容易看出像 JSON 这样足够简单和量身定制的东西会表现得更好。

如果您喜欢这个博客，每两周就会有新帖子！在 Twitter 上关注 @TwoBitHistory 或订阅 RSS 源，以确保收到新更新的通知。

#software ↩%2Cxml%2Cprotocol-buffers%2Cyaml%2Ccsv ↩Zakas, Nicholas C., et al. “What Is Ajax?” Professional Ajax, 2nd ed., Wiley, 2007. ↩ ↩ ↩ 同上↩ ↩ ↩#comment-26383 ↩ ↩ ↩ ↩

通过：

作者：Two-Bit History 主题：lujun9972 译者：runningwater 校对：wxy

本文由LCTT原创编译，Linux中国荣誉呈现