JSON的兴起与崛起

詹森已经接管了世界。今天，当任何两个应用程序通过Internet相互通信时，它们很可能使用JSON。它已经被所有的大玩家采用：在十个最流行的网络API中，只有一个API以XML而不是JSON的形式公开数据，这个列表主要由谷歌、Facebook和Twitter等大公司提供。1以该列表中的一个说明性示例为例，Twitter在2013年之前一直支持XML，当时它发布了一个新版本的API，去掉了XML，转而支持JSON独占使用。JSON也被编程人员广泛采用：根据程序员问答网站Stack Overflow的说法，现在关于JSON的问题比关于任何其他数据交换格式的问题都多。2个。

XML仍然存在于许多地方。它在网络上用于SVG，用于RSS和Atom提要。当Android开发者想要声明他们的应用获得了用户的许可时，他们会在他们的应用程序清单中这样做，清单是用XML编写的。XML也不是JSON的唯一替代方案-有些人现在使用像YAML或Google的Protocol Buffers这样的技术。但它们远没有JSON那么受欢迎。目前，JSON似乎是通过互联网与其他程序通信的首选格式。

考虑到就在2005年，Web世界还垂涎于“异步JavaScript和XML”的潜力，而不是“异步JavaScript和JSON”，JSON的主导地位是令人惊讶的。当然，这可能与这两种格式在当时的相对流行程度无关，而只是反映出“Ajax”一定比“Ajaj”看起来更吸引人。但是，即使有些人在2005年就已经在使用JSON而不是XML了(事实上，现在还没有多少人这样做)，人们仍然想知道XML的命运怎么会如此急剧地衰落，以至于短短十年左右之后，“异步JavaScript和XML”就成了一个具有讽刺意味的用词不当。那十年里发生了什么？JSON是如何在这么多应用程序中取代XML的？现在全世界的工程师和系统都依赖于谁创造了这种数据格式呢？

第一条JSON消息是在2001年4月发送的。由于这是计算机历史上的一个重要时刻，这条信息是从阿拜区车库的一台计算机上发出的。道格拉斯·克罗克福德(Douglas Crockford)和奇普·晨星(Chip Morningstar)是一家名为State Software的技术咨询公司的联合创始人，他们聚集在晨星的车库里测试一个想法。

早在“Ajax”这个术语出现之前，Crockford和Morningstar就试图构建Ajax应用程序。浏览器对他们正在尝试的内容的支持不是很好。他们希望在初始页面加载后将数据传递给他们的应用程序，但他们还没有找到一种可以在所有目标浏览器上运行的方法。

虽然今天很难相信，但Internet Explorer在2001年代表了网络浏览的尖端。早在1999年，Internet Explorer5就支持原始形式的XMLHttpRequest，程序员可以使用称为ActiveX的框架进行访问。克罗克福德和晨星本来可以使用这项技术为他们的应用程序获取数据，但他们不能在Netscape 4中使用相同的解决方案，Netscape 4是他们试图支持的另一种浏览器。因此，克罗克福德和晨星必须使用在这两种浏览器中都能工作的不同系统。

<；html&>；<；head<；script>；document ent.domain='；fudco'；；parent.session.recover({to："；session"；，do："；test&34；，text："；Hello world"；})<；/script>；<；/head<；<；/html>。

正如我们今天所知，消息中只有一小部分类似于JSON。消息本身实际上是一个包含一些JavaScript的HTML文档。与JSON类似的部分只是一个JavaScript对象文字，它被传递给一个名为Receive()的函数。

克罗克福德和晨星已经决定，他们可以滥用HTML框架给自己发送数据。他们可以将框架指向URL，该URL将返回类似上面的HTML文档。当接收到HTML时，JavaScriptware将运行，并将对象文字传递回应用程序。只要小心避开阻止子窗口访问其父窗口的浏览器保护，这种方法就有效；您可以看到Crockford和Mornginstar通过显式设置文档域做到了这一点。(这种基于框架的技术，有时称为隐藏框架技术，在XMLHttpRequest广泛实现之前的90年代末就被广泛使用。3)。

第一个JSON消息的惊人之处在于，它显然不是第一次使用一种新的数据格式。这只是JavaScript！事实上，以这种方式使用JavaScript的想法是如此直截了当，以至于Crockford自己也说过，他并不是第一个这样做的人-他声称早在1996年，Netscape就有人使用JavaScript数组文字来交流信息。4因为消息只是JavaScript，所以不需要任何特殊的解析。JavaScript解释器可以完成所有工作。

第一条JSON消息实际上与JavaScript解释器发生了冲突。JavaScript保留了大量的单词-ECMAScript 6中有64个保留单词-而Crockford和Morningstar在他们的消息中无意中使用了一个。他们曾使用DO作为键，但DO是保留的。由于JavaScripthas有如此多的保留字，Crockford决定，与其避免使用所有这些保留字，不如强制引用所有JSON键。JavaScript解释器会将引用键视为字符串，这意味着可以安全地使用保留字。这就是JSON密钥被引用到今天的原因。

克罗克福德和晨星意识到他们有一些东西可以用在各种应用中。他们想把他们的格式命名为“JSML”，即JavaScriptMarkup Language，但是发现这个缩写已经被用于一种叫做Java Speech Markup Language的东西。因此，他们决定使用“JavaScript Object Notation”，即JSON。他们开始向客户推销它，但很快发现客户不愿在缺乏官方规格的未知技术上冒险。所以克罗克福德决定写一本。

在2002年，Crockford购买了域JSON.org，并提供了JSON语法和一个解析器的示例实现。该网站仍在运行，尽管它现在包含了2013年批准的JSON ECMA标准的显著链接。在建立了这个网站之后，Crockford几乎没有做更多的事情来推广JSON，但是很快发现很多人都在用各种不同的编程语言提交JSON解析器实现。JSON的行清楚地将其与JavaScript捆绑在一起，但很明显，JSON非常适合在任意语言对之间进行数据交换。

JSON在2005年得到了很大的提振。那一年，一位名叫杰西·詹姆斯·加勒特(Jesse James Garrett)的网页设计师和开发人员在一篇博客文章中创造了“AJAX”一词。他小心翼翼地强调，Ajax不是任何一项新技术，而是“几种技术，每种技术都以自己的方式蓬勃发展，以强大的新方式结合在一起。”5 Garrett给一种新的应用程序开发方法起了这个名字，他注意到这种方法越来越受欢迎。他的博客文章接着描述了开发人员如何利用JavaScript和XMLHttpRequest来构建比典型网页更具响应性和更有状态的新型应用程序。他指出，Gmail和Flickr是已经依赖AJAX技术的网站的例子。

当然，“Ajax”中的“X”代表XML。但在随后的问答帖子中，加勒特指出JSON是一种完全可以接受的XML替代方案。他写道，“XML是将数据传入和传出AJAX客户端的最成熟的方法，但是您没有理由不能使用JavaScript对象表示法之类的技术或任何类似的数据结构化方法来实现同样的效果。”

开发人员确实发现他们可以很容易地使用JSON来构建AJAX应用程序，许多人开始更喜欢JSON而不是XML。因此，具有讽刺意味的是，对Ajax的兴趣导致JSON的受欢迎程度激增。正是在这个时候，JSON吸引了博客圈的注意。

Dave Winer是一位多产的博客作者，也是许多基于XML的技术(如RSS和XML-RPC)背后的工程师。他在2006年抱怨说，JSON正在无缘无故地重新发明XML。尽管有人可能认为数据交换格式之间的竞争不太可能产生死亡威胁，但Winer写道：

毫无疑问，我可以编写一个例程来解析[JSON]，但看看他们重新发明的程度有多深，由于某些原因，XML本身对他们来说还不够好(我很想听听原因)。是谁做了这件滑稽的事？让我们找一棵树，把它们串起来。现在。7个。

很容易理解温纳的挫折感。XML从来没有受到广泛的喜爱，甚至Winer也说过他不喜欢XML。8但是XML被设计成一个几乎任何人都可以想到的系统。为此，XML实际上是一种元语言，它允许您为各个应用程序定义特定于领域的语言-例如RSS、Web提要技术和SOAP(简单对象访问协议)。Winer认为努力达成共识是很重要的，因为通用的交换格式可以带来所有的好处。他认为XML的灵活性应该能够满足每个人的需求。然而，这里有了JSON，一种格式没有提供任何XML的好处，除了那些通过抛出使XML如此灵活的缺点而启用的格式。

克罗克福德看到了维纳的博客文章，并对此发表了评论。对于JSON正在重新发明XML的说法，Crockford写道，“发明轮子的好处是可以得到一个轮子。”

到2014年，JSON已经由ECMA标准和一个RFC正式指定。它有自己的哑剧类型。杰森已经进入了大联盟。

在JSON.org上，Crockford总结了JSON相对于XML的一些优势。他写道，JSON对于人类和机器来说都更容易理解，因为它的语法是最小的，并且它的结构是可预测的。10其他博客作者关注的是XML的冗长和“角度括号税”。11 XML中的每个开始标记都必须与一个结束标记相匹配，这意味着XML文档包含大量冗余信息。这会使XML文档在未压缩时比等效的JSON文档大得多，但也许更重要的是，它也使XML文档更难阅读。

Crockford还声称JSON的另一个巨大优势是JSON被设计为一种数据交换格式。12它的目的是从一开始就在程序之间传送结构化信息。尽管XML也曾用于同样的目的，但它最初是作为一种文档标记语言设计的。它是从SGML(标准通用标记语言)演变而来的，而SGML又是从一种名为Scribe的标记语言演变而来的，Scribe旨在用作类似于LaTeX的字处理系统。在XML中，标记可以包含所谓的“混合内容”，也可以包含在单词或短语周围带有内联标记的文本。这让人想起编辑用红色或蓝色钢笔标记手稿的形象，这可以说是标记语言的中心隐喻。另一方面，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可能不会像今天这样无处不在。但我认为XHTML的失败是XML阵营的一种道德失败。如果XML不是HTML的最佳工具，那么也许还有更好的工具可用于其他应用程序。在这个世界里，在我们这个世界里，很容易看到像JSON这样简单和狭隘定制的格式是如何获得巨大成功的。

如果你喜欢这个帖子，那就更像是每四周出一次！在Twitter上关注@TwoBitHistory或订阅RSS feed，确保你知道什么时候有新帖子发布。