2017年9月撰写的文章
JSON已经占领了世界。 如果今天有两个应用程序通过Internet相互通信，那么很可能它们使用JSON进行通信。 该标准为所有主要参与者所接受：在十个最受欢迎的Web API中（主要由Google，Facebook和Twitter等大公司开发），
只有一个API可以 XML格式传输数据，而不能以JSON格式传输数据。 例如，Twitter在2013年之前一直支持XML，直到2013年才以JSON形式发布API的新版本。 在其他开发人员中，JSON也很流行：根据Stack Overflow的说法，
关于JSON的问题要多于其他任何数据交换格式 。
XML仍然存在并且使用很多。 例如，以Web格式SVG，RSS和Atom。 如果Android应用程序的作者想要声明他需要用户的许可，则可以在以XML编写的应用程序清单中执行此操作。 而且XML并不是唯一的JSON替代方案：一些开发人员选择Google的YAML或协议缓冲区。 但是这些格式远没有像JSON那样流行，JSON几乎已经成为在Internet上的程序之间交换数据的事实上的标准。
JSON的优势令人惊讶，因为早在2005年，每个人都在讨论“异步JavaScript和XML”而不是“异步JavaScript和JSON”的潜力。 当然，这可能并没有说明这两种格式的相对流行程度，只是AJAX似乎比AJAJ更具吸引力。 但是，尽管在2005年有人已经使用JSON代替XML（实际上很少使用），但您仍然想知道XML会如何急剧下降以至十年后，“异步JavaScript和XML”这一短语引起了讽刺。 在这十年中发生了什么？ JSON如何在许多应用程序中替代XML？ 谁发明了这种数据格式，现在全世界的工程师和系统都依赖这种格式？
JSON的诞生
第一条JSON消息是2001年4月从位于旧金山附近的车库中的计算机发送的。 历史保留了参与该活动的人员的名字：Douglas Crockford和技术咨询公司State Software的联合创始人Chip Morningstar。
在术语AJAX出现之前，这两个公司就一直在开发AJAX应用程序。 但是浏览器中的应用程序支持不是很好。 他们希望在页面初始加载后将数据传输到他们的应用程序，但是没有找到一种在所有浏览器中都可以使用的方法。
今天很难相信，但是Internet Explorer是2001年最先进的浏览器。 自1999年以来，Internet Explorer 5通过ActiveX支持早期形式的XMLHttpRequest。 Crockford和Morningstar可以使用此技术来检索应用程序中的数据，但在Netscape 4中不起作用。因此，我必须寻找在两种浏览器中都可以使用的不同格式。
第一条JSON消息如下所示：
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html>
正如我们今天所知道的，消息中只有一小部分类似于JSON。 消息本身实际上是带有几行JavaScript的HTML文档。 类似JSON的部分只是用于
receive()函数的JavaScript文字。
Crockford和Morningstar决定滥用HTML框架来发送数据。 对于框架，您可以指定一个URL，该URL返回与上面类似的HTML文档。 收到HTML时，将启动JavaScript，并将文字传递回应用程序。 这样做的前提是要仔细规避浏览器保护，以防止孩子访问父窗口：如您所见，Crockford和Morningstar明确设置了文档域。 这种技术有时被称为隐藏框架；它
通常在90年代后期使用在常规XMLHttpRequest之前 。
关于JSON的第一篇文章令人惊讶的是，这并不是第一次使用一种新的数据格式。 这只是JavaScript！ 实际上，以这种方式使用JavaScript的想法是如此简单，以至于Crockford本人认为自己并不是第一个这样做的人-他声称Netscape中有人
在1996年使用JavaScript数组文字来传输信息。 使用纯JavaScript进行发布不需要任何特殊的解析。 一切都由JavaScript解释器完成。
实际上，历史记录中的第一条JSON消息在解释器方面存在问题。 JavaScript保留了大量单词-ECMAScript 6中保留了64个单词-Crockford和Morningstar在其消息中无意中使用了它们：即，保留单词
do作为关键字。 由于JavaScript有很多保留字，因此Crockford决定不回避它们，而只是引用所有JSON键。 JavaScript解释器将带引号的键视为字符串，因此您可以安全地使用保留字。 这就是为什么仍引用JSON键的原因。
Crockford和Morningstar意识到新方法可用于各种应用。 他们想调用JSML（JavaScript标记语言）格式，但事实证明，该缩写已经在忙于Java语音标记语言。 因此，我们选择了Javascript对象表示法，即JSON。 他们开始向客户提供该格式，但是很快变得很清楚，他们没有冒险使用没有官方规范的未知技术。 所以克罗克福德决定写它。
在2002年，Crockford购买了
JSON.org域，发布了JSON语法以及解析器的示例实现。 该网站仍在运行，尽管现在显示了2013年采用的JSON ECMA标准的链接。 除了启动该网站之外，Crockford几乎没有做任何推广JSON的工作，但是很快便有了以各种编程语言实现的JSON解析器。 最初，JSON显然与JavaScript相关联，但是后来很明显，它非常适合在任意语言对之间交换数据。
AJAX错误
JSON在2005年大获成功。 然后，名为Jesse James Garrett的设计师兼开发人员在他的
文章中创造了AJAX这个词。 他试图强调AJAX不仅是一项新技术，而且是“以良好的方式将强大的新方法结合在一起的好技术。” Garrett称AJAX是Web应用程序开发的一种新方法。 在一篇博客文章中，他描述了开发人员如何使用JavaScript和XMLHttpRequest创建更多的交互式应用程序。 他将依赖AJAX方法的网站称为Gmail和Flickr的示例。
当然，AJAX中的“ X”表示XML。 但是在随后的问题和答案中，Garrett称JSON为完全可接受的替代方法。 他写道：“ XML是AJAX客户端功能最强大的数据交换工具，但是使用Javascript Object Notation或任何类似的数据结构格式可以实现相同的效果。”
开发人员确实发现他们可以轻松地使用JSON创建AJAX应用程序，许多人选择了它来代替XML。 具有讽刺意味的是，对AJAX的兴趣导致JSON的普及爆炸式增长。 大约在这个时候，JSON引起了Blogosphere的注意。
2006年，多产的博客作者和许多XML技术（例如RSS和XML-RPC）的创建者Dave Weiner
抱怨 JSON出于没有充分的理由重塑XML：
“当然，我可以编写一个解析[JSON]的过程，但是看看它们在重塑该技术方面走了多远：出于某种原因，XML对他们来说还不够好（我想知道为什么）。 谁创造了这个模仿？ 让我们找到一棵树，然后挂一个人。 现在。”
很容易理解韦纳的失望。 XML从未被特别喜欢过。 甚至魏纳本人也
说他不喜欢XML 。 但是XML被设计为可以想象的任何应用程序的通用系统。 XML实际上是一种元语言，它使您可以为单个应用程序定义域语言，例如RSS和SOAP。 Weiner认为，对于通用交换格式所带来的所有好处，达成共识很重要。 他认为，XML的灵活性能够满足任何需求。 但是，JSON是一种除XML之外没有任何优势的格式，除了垃圾清除（使垃圾邮件变得如此灵活）之外。
克罗克福德（Crockford）看到了韦纳（Weiner）的博客并发表了评论。 为了回应有关JSON重塑XML的指责，Crockford写道：
“重塑
轮子是件好事，因为您可以绕过它 。
”JSON与XML
到2014年，JSON被正式认可为ECMA和RFC标准。 他得到了MIME类型。 JSON已进入大联盟。
为什么JSON比XML流行得多？
在
JSON.org上， Crockford列出了
JSON优于XML的一些
优点 。 他写道，JSON更容易被人和机器理解，因为它的语法最小并且结构是可预测的。 其他博客作者
提到 XML的冗长性和“标签税”。 XML中的每个开始标记必须具有结束标记，这意味着很多冗余信息。 这使得XML比等效的JSON文档大得多，但是更重要的是，由于这个原因，XML文档更难以阅读。
Crockford
称 JSON的另一个巨大优势为：JSON最初被设计为一种在程序之间交换结构化信息的格式。 尽管XML用于相同的目的，但它最初是作为文档标记语言开发的。 它起源于SGML（标准通用标记语言），而SGML又是从Scribe标记语言演变而来的，该语言用于标记文本，例如LaTeX。 在XML中，标签内可能有所谓的“混合内容”，即带有嵌入标签的文本周围的单词或短语。 它类似于一个用红色或蓝色标记标记稿件的编辑器，这是一种标记语言的隐喻。 另一方面，JSON不支持混合内容的精确模拟，这意味着简化了结构。 最好用树的形式表示文档，但是放弃了文档的想法，Crockford能够将JSON限制为所有程序员用来创建程序的字典和熟悉元素的数组。
最后，我自己的猜测是人们不喜欢XML的复杂性，这的确是因为XML的多样性。 乍一看，很难区分XML本身及其子语言，例如RSS，ATOM，SOAP或SVG。 典型XML文档的第一行建立XML版本，然后建立XML文档必须匹配的特定子语言。 与JSON相比，这些选项很多，因为JSON非常简单，因此不会编写新版本的JSON规范。 XML开发人员试图为所有内容创建单一的数据交换格式，但却成为经典程序员陷阱的受害者：过度的技术复杂性。 XML太笼统了，很难用于简单的事情。
在2000年，一项运动开始使HTML与XML标准保持一致。 发布了符合XML的HTML规范，以后称为XHTML。 一些浏览器制造商立即开始支持新标准，但是很快就很明显，使用HTML的普通公众不想改变他们的习惯。 新标准要求XHTML的验证比HTML惯用的更为严格，但是太多的站点依赖于免费的HTML规则。 到2009年，活动家已经停止尝试编写XHTML的第二版，因为很明显，未来就在于HTML5标准，该标准不需要XML合规性。
如果XHTML的努力成功了，那么XML可能会像其开发人员所希望的那样成为一种通用的数据格式。 想象一下一个HTML文档和API响应具有完全相同的结构的世界。 在这样的世界中，JSON可能不像今天这样流行。 但是我认为XHTML的失败是XML阵营的道德失败。 如果XML不能帮助HTML，那么可能会有用于其他应用程序的更好的工具。 在现实世界中，很容易理解为什么简单且高度专业化的JSON格式如此成功。