[[256892]]

簡(jiǎn)介

XML 和 JSON 是現(xiàn)今互聯(lián)網(wǎng)中最常用的兩種數(shù)據(jù)交換格式。XML 格式由 W3C 于 1996 年提出。JSON 格式由 Douglas Crockford 于 2002 年提出。雖然這兩種格式的設(shè)計(jì)目標(biāo)并不相同，但它們常常用于同一個(gè)任務(wù)，也就是數(shù)據(jù)交換中。XML 和 JSON 的文檔都很完善(RFC 7159[1]、RFC 4825[2])，且都同時(shí)具有人類可讀性human-readable和機(jī)器可讀性machine-readable。這兩種格式并沒有哪一個(gè)比另一個(gè)更強(qiáng)，只是各自適用的領(lǐng)域不用。(LCTT 譯注：W3C 是互聯(lián)網(wǎng)聯(lián)盟[3]，制定了各種 Web 相關(guān)的標(biāo)準(zhǔn)，如 HTML、CSS 等。Douglas Crockford 除了制定了 JSON 格式，還致力于改進(jìn) JavaScript，開發(fā)了 JavaScript 相關(guān)工具 JSLint[4] 和 JSMin[5])

XML 的優(yōu)點(diǎn)

XML 與 JSON 相比有很多優(yōu)點(diǎn)。二者間最大的不同在于 XML 可以通過在標(biāo)簽中添加屬性這一簡(jiǎn)單的方法來存儲(chǔ)元數(shù)據(jù)metadata。而使用 JSON 時(shí)需要?jiǎng)?chuàng)建一個(gè)對(duì)象，把元數(shù)據(jù)當(dāng)作對(duì)象的成員來存儲(chǔ)。雖然二者都能達(dá)到存儲(chǔ)元數(shù)據(jù)的目的，但在這一情況下 XML 往往是更好的選擇，因?yàn)?JSON 的表達(dá)形式會(huì)讓客戶端程序開發(fā)人員誤以為要將數(shù)據(jù)轉(zhuǎn)換成一個(gè)對(duì)象。舉個(gè)例子，如果你的 C++ 程序需要使用 JSON 格式發(fā)送一個(gè)附帶元數(shù)據(jù)的整型數(shù)據(jù)，需要?jiǎng)?chuàng)建一個(gè)對(duì)象，用對(duì)象中的一個(gè)名稱/值對(duì)name/value pair來記錄整型數(shù)據(jù)的值，再為每一個(gè)附帶的屬性添加一個(gè)名稱/值對(duì)。接收到這個(gè) JSON 的程序在讀取后很可能把它當(dāng)成一個(gè)對(duì)象，可事實(shí)并不是這樣。雖然這是使用 JSON 傳遞元數(shù)據(jù)的一種變通方法，但他違背了 JSON 的核心理念：“JSON 的結(jié)構(gòu)與常規(guī)的程序語言中的結(jié)構(gòu)相對(duì)應(yīng)，而無需修改。JSON’s structures look like conventional programming language structures. No restructuring is necessary.”1

雖然稍后我會(huì)說這也是 XML 的一個(gè)缺點(diǎn)，但 XML 中對(duì)命名沖突、前綴prefix的處理機(jī)制賦予了它 JSON 所不具備的能力。程序員們可以通過前綴來把統(tǒng)一名稱給予兩個(gè)不同的實(shí)體。2 當(dāng)不同的實(shí)體在客戶端中使用的名稱相同時(shí)，這一特性會(huì)非常有用。

XML 的另一個(gè)優(yōu)勢(shì)在于大多數(shù)的瀏覽器可以把它以具有高可讀性和強(qiáng)組織性的方式highly readable and organized way展現(xiàn)給用戶。XML 的樹形結(jié)構(gòu)讓它易于結(jié)構(gòu)化，瀏覽器也讓用戶可以自行展開或折疊樹中的元素，這簡(jiǎn)直就是調(diào)試的福音。

XML 對(duì)比 JSON 有一個(gè)很重要的優(yōu)勢(shì)就是它可以記錄混合內(nèi)容mixed content。例如在 XML 中處理包含結(jié)構(gòu)化標(biāo)記的字符串時(shí)，程序員們只要把帶有標(biāo)記的文本放在一個(gè)標(biāo)簽內(nèi)就可以了。可因?yàn)?JSON 只包含數(shù)據(jù)，沒有用于指明標(biāo)簽的簡(jiǎn)單方式，雖然可以使用處理元數(shù)據(jù)的解決方法，但這總有點(diǎn)濫用之嫌。

JSON 的優(yōu)點(diǎn)

JSON 自身也有很多優(yōu)點(diǎn)。其中最顯而易見的一點(diǎn)就是 JSON 比 XML 簡(jiǎn)潔得多。因?yàn)?XML 中需要打開和關(guān)閉標(biāo)簽，而 JSON 使用名稱/值對(duì)表示數(shù)據(jù)，使用簡(jiǎn)單的 { 和 } 來標(biāo)記對(duì)象，[和 ] 來標(biāo)記數(shù)組，, 來表示數(shù)據(jù)的分隔，: 表示名稱和值的分隔。就算是使用 gzip 壓縮，JSON 還是比 XML 要小，而且耗時(shí)更少。3 正如 Sumaray 和 Makki 在實(shí)驗(yàn)中指出的那樣，JSON 在很多方面都比 XML 更具優(yōu)勢(shì)，得出同樣結(jié)果的還有 Nurseitov、Paulson、Reynolds 和 Izurieta。首先，由于 JSON 文件天生的簡(jiǎn)潔性，與包含相同信息的 XML 相比，JSON 總是更小，這意味著更快的傳輸和處理速度。第二，在不考慮大小的情況下，兩組研究 4 5 表明使用 JSON 執(zhí)行序列化和反序列化的速度顯著優(yōu)于使用 XML。第三，后續(xù)的研究指出 JSON 的處理在 CPU 資源的使用上也優(yōu)于 XML。研究人員發(fā)現(xiàn) JSON 在總體上使用的資源更少，其中更多的 CPU 資源消耗在用戶空間，系統(tǒng)空間消耗的 CPU 資源較少。這一實(shí)驗(yàn)是在 RedHat 的設(shè)備上進(jìn)行的，RedHat 表示更傾向于在用戶空間使用 CPU 資源。6 不出意外，Sumaray 和 Makki 在研究里還說明了在移動(dòng)設(shè)備上 JSON 的性能也優(yōu)于 XML。7 這是有道理的，因?yàn)?JSON 消耗的資源更少，而移動(dòng)設(shè)備的性能也更弱。

JSON 的另一個(gè)優(yōu)點(diǎn)在于其對(duì)對(duì)象和數(shù)組的表述和宿主語言host language中的數(shù)據(jù)結(jié)構(gòu)相對(duì)應(yīng)，例如對(duì)象object、記錄record、結(jié)構(gòu)體struct、字典dictionary、哈希表hash table、鍵值列表keyed list還有數(shù)組array、向量vector、列表list，以及對(duì)象組成的數(shù)組等等。8 雖然 XML 里也能表達(dá)這些數(shù)據(jù)結(jié)構(gòu)，也只需調(diào)用一個(gè)函數(shù)就能完成解析，而往往需要更多的代碼才能正確的完成 XML 的序列化和反序列化處理。而且 XML 對(duì)于人類來說不如 JSON 那么直觀，XML 標(biāo)準(zhǔn)缺乏對(duì)象、數(shù)組的標(biāo)簽的明確定義。當(dāng)結(jié)構(gòu)化的標(biāo)記可以替代嵌套的標(biāo)簽時(shí)，JSON 的優(yōu)勢(shì)極為突出。JSON 中的花括號(hào)和中括號(hào)則明確表示了數(shù)據(jù)的結(jié)構(gòu)，當(dāng)然這一優(yōu)勢(shì)也包含前文中的問題，在表示元數(shù)據(jù)時(shí) JSON 不如 XML 準(zhǔn)確。

雖然 XML 支持命名空間namespace與前綴prefix，但這不代表 JSON 沒有處理命名沖突的能力。比起 XML 的前綴，它處理命名沖突的方式更簡(jiǎn)潔，在程序中的處理也更自然。在 JSON 里，每一個(gè)對(duì)象都在它自己的命名空間中，因此不同對(duì)象內(nèi)的元素名稱可以隨意重復(fù)。在大多數(shù)編程語言中，不同的對(duì)象中的成員可以包含相同的名字，所以 JSON 根據(jù)對(duì)象進(jìn)行名稱區(qū)分的規(guī)則在處理時(shí)更加自然。

也許 JSON 比 XML 更優(yōu)的部分是因?yàn)?JSON 是 JavaScript 的子集，所以在 JavaScript 代碼中對(duì)它的解析或封裝都非常的自然。雖然這看起來對(duì) JavaScript 程序非常有用，而其他程序則不能直接從中獲益，可實(shí)際上這一問題已經(jīng)被很好的解決了。現(xiàn)在 JSON 的網(wǎng)站的列表上展示了 64 種不同語言的 175 個(gè)工具，它們都實(shí)現(xiàn)了處理 JSON 所需的功能。雖然我不能評(píng)價(jià)大多數(shù)工具的質(zhì)量，但它們的存在明確了開發(fā)者社區(qū)擁抱 JSON 這一現(xiàn)象，而且它們切實(shí)簡(jiǎn)化了在不同平臺(tái)使用 JSON 的難度。

二者的動(dòng)機(jī)

簡(jiǎn)單地說，XML 的目標(biāo)是標(biāo)記文檔。這和 JSON 的目標(biāo)想去甚遠(yuǎn)，所以只要用得到 XML 的地方就盡管用。它使用樹形的結(jié)構(gòu)和包含語義的文本來表達(dá)混合內(nèi)容以實(shí)現(xiàn)這一目標(biāo)。在 XML 中可以表示數(shù)據(jù)的結(jié)構(gòu)，但這并不是它的長(zhǎng)處。

JSON 的目標(biāo)是用于數(shù)據(jù)交換的一種結(jié)構(gòu)化表示。它直接使用對(duì)象、數(shù)組、數(shù)字、字符串、布爾值這些元素來達(dá)成這一目標(biāo)。這完全不同于文檔標(biāo)記語言。正如上面說的那樣，JSON 沒有原生支持混合內(nèi)容mixed content的記錄。

軟件

這些主流的開放 API 僅提供 XML：亞馬遜產(chǎn)品廣告 APIAmazon Product Advertising API。

這些主流 API 僅提供 JSON：臉書圖 APIFacebook Graph API、谷歌地圖 APIGoogle Maps API、推特 APITwitter API、AccuWeather API、Pinterest API、Reddit API、Foursquare API。

這些主流 API 同時(shí)提供 XML 和 JSON：谷歌云存儲(chǔ)Google Cloud Storage、領(lǐng)英 APILinkedin API、Flickr API。

根據(jù)可編程網(wǎng)絡(luò)Programmable Web 9 的數(shù)據(jù)，最流行的 10 個(gè) API 中只有一個(gè)是僅提供 XML 且不支持 JSON 的。其他的要么同時(shí)支持 XML 和 JSON，要么只支持 JSON。這表明了大多數(shù)應(yīng)用開發(fā)者都更傾向于使用支持 JSON 的 API，原因大概是 JSON 更快的處理速度與良好口碑，加之與 XML 相比更加輕量。此外，大多數(shù) API 只是傳遞數(shù)據(jù)而非文檔，所以 JSON 更加合適。例如 Facebook 的重點(diǎn)在于用戶的交流與帖子，谷歌地圖則主要處理坐標(biāo)和地圖信息，AccuWeather 就只傳遞天氣數(shù)據(jù)。總之，雖然不能說天氣 API 在使用時(shí)究竟是 JSON 用的多還是 XML 用的多，但是趨勢(shì)明確偏向了 JSON。10 11

這些主流的桌面軟件仍然只是用 XML：Microsoft Word、Apache OpenOffice、LibraOffice。

因?yàn)檫@些軟件需要考慮引用、格式、存儲(chǔ)等等，所以比起 JSON，XML 優(yōu)勢(shì)更大。另外，這三款程序都支持混合內(nèi)容，而 JSON 在這一點(diǎn)上做得并不如 XML 好。舉例說明，當(dāng)用戶使用 Microsoft Word 編輯一篇論文時(shí)，用戶需要使用不同的文字字形、文字大小、文字顏色、頁(yè)邊距、段落格式等，而 XML 結(jié)構(gòu)化的組織形式與標(biāo)簽屬性生來就是為了表達(dá)這些信息的。

這些主流的數(shù)據(jù)庫(kù)支持 XML：IBM DB2、Microsoft SQL Server、Oracle Database、PostgresSQL、BaseX、eXistDB、MarkLogic、MySQL。

這些是支持 JSON 的主流數(shù)據(jù)庫(kù)：MongoDB、CouchDB、eXistDB、Elastisearch、BaseX、MarkLogic、OrientDB、Oracle Database、PostgreSQL、Riak。

在很長(zhǎng)一段時(shí)間里，SQL 和關(guān)系型數(shù)據(jù)庫(kù)統(tǒng)治著整個(gè)數(shù)據(jù)庫(kù)市場(chǎng)。像甲骨文Oracle和微軟Microsoft這樣的軟件巨頭都提供這類數(shù)據(jù)庫(kù)，然而近幾年 NoSQL 數(shù)據(jù)庫(kù)正逐步受到開發(fā)者的青睞。也許是正巧碰上了 JSON 的普及，大多數(shù) NoSQL 數(shù)據(jù)庫(kù)都支持 JSON，像 MongoDB、CouchDB 和 Riak 這樣的數(shù)據(jù)庫(kù)甚至使用 JSON 來存儲(chǔ)數(shù)據(jù)。這些數(shù)據(jù)庫(kù)有兩個(gè)重要的特性是它們適用于現(xiàn)代網(wǎng)站：一是它們與關(guān)系型數(shù)據(jù)庫(kù)相比更容易擴(kuò)展more scalable;二是它們?cè)O(shè)計(jì)的目標(biāo)就是 web 運(yùn)行所需的核心組件。12 由于 JSON 更加輕量，又是 JavaScript 的子集，所以很適合 NoSQL 數(shù)據(jù)庫(kù)，并且讓這兩個(gè)品質(zhì)更容易實(shí)現(xiàn)。此外，許多舊的關(guān)系型數(shù)據(jù)庫(kù)增加了 JSON 支持，例如 Oracle Database 和 PostgreSQL。由于 XML 與 JSON 間的轉(zhuǎn)換比較麻煩，所以大多數(shù)開發(fā)者會(huì)直接在他們的應(yīng)用里使用 JSON，因此開發(fā)數(shù)據(jù)庫(kù)的公司才有支持 JSON 的理由。(LCTT 譯注：NoSQL 是對(duì)不同于傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)的數(shù)據(jù)庫(kù)管理系統(tǒng)的統(tǒng)稱。參考來源[6]) 13

未來

對(duì)互聯(lián)網(wǎng)的種種變革中，最讓人期待的便是物聯(lián)網(wǎng)Internet of Things(IoT)。這會(huì)給互聯(lián)網(wǎng)帶來大量計(jì)算機(jī)之外的設(shè)備，例如手表、溫度計(jì)、電視、冰箱等等。這一勢(shì)頭的發(fā)展良好，預(yù)期在不久的將來迎來爆發(fā)式的增長(zhǎng)。據(jù)估計(jì)，到 2020 年時(shí)會(huì)有 260 億 到 2000 億的物聯(lián)網(wǎng)設(shè)備被接入互聯(lián)網(wǎng)。14 15 幾乎所有的物聯(lián)網(wǎng)設(shè)備都是小型設(shè)備，因此性能比筆記本或臺(tái)式電腦要弱很多，而且大多數(shù)都是嵌入式系統(tǒng)。因此，當(dāng)它們需要與互聯(lián)網(wǎng)上的系統(tǒng)交換數(shù)據(jù)時(shí)，更輕量、更快速的 JSON 自然比 XML 更受青睞。16 受益于 JSON 在 web 上的快速普及，與 XML 相比，這些新的物聯(lián)網(wǎng)設(shè)備更有可能從使用 JSON 中受益。這是一個(gè)典型的梅特卡夫定律的例子，無論是 XML 還是 JSON，抑或是什么其他全新的格式，現(xiàn)存的設(shè)備和新的設(shè)備都會(huì)從支持最廣泛使用的格式中受益。

Node.js 是一款服務(wù)器端的 JavaScript 框架，隨著她的誕生與快速成長(zhǎng)，與 MongoDB 等 NoSQL 數(shù)據(jù)庫(kù)一起，讓全棧使用 JavaScript 開發(fā)成為可能。這些都預(yù)示著 JSON 光明的未來，這些軟件的出現(xiàn)讓 JSON 運(yùn)用在全棧開發(fā)的每一個(gè)環(huán)節(jié)成為可能，這將使應(yīng)用更加輕量，響應(yīng)更快。這也是任何應(yīng)用的追求之一，所以，全棧使用 JavaScript 的趨勢(shì)在不久的未來都不會(huì)消退。17

此外，另一個(gè)應(yīng)用開發(fā)的趨勢(shì)是從 SOAP 轉(zhuǎn)向 REST。18 19 20 XML 和 JSON 都可以用于 REST，可 SOAP 只能使用 XML。

從這些趨勢(shì)中可以推斷，JSON 的發(fā)展將統(tǒng)一 Web 的信息交換格式，XML 的使用率將繼續(xù)降低。雖然不應(yīng)該把 JSON 吹過頭了，因?yàn)?XML 在 Web 中的使用依舊很廣，而且它還是 SOAP 的唯一選擇，可考慮到 SOAP 到 REST 的遷移，NoSQL 數(shù)據(jù)庫(kù)和全棧 JavaScript 的興起，JSON 卓越的性能，我相信 JSON 很快就會(huì)在 Web 開發(fā)中超過 XML。至于其他領(lǐng)域，XML 比 JSON 更好的情況并不多。

角注

1. Introducing JSON[7]

2. XML Tutorial[8]

3. JSON vs. XML: Some hard numbers about verbosity[9]

4. Comparison of JSON and XML Data Interchange Formats: A Case Study[10]

5. A comparison of data serialization formats for optimal efficiency on a mobile platform[11]

6. Comparison of JSON and XML Data Interchange Formats: A Case Study[10]

7. A comparison of data serialization formats for optimal efficiency on a mobile platform[11]

8. Introducing JSON[7]

9. Most Popular APIs: At Least One Will Surprise You[12]

10. Why JSON will continue to push XML out of the picture[13]

11. Thousands of APIs Paint a Bright Future for the Web[14]

12. Why JSON will continue to push XML out of the picture[13]

13. How JSON sparked NoSQL – and will return to the RDBMS fold[15]

14. A Simple Explanation Of ‘The Internet Of Things’[16]

15. Proofpoint Uncovers Internet of Things (IoT) Cyberattack[17]

16. Why JSON will continue to push XML out of the picture[13]

17. Why JSON will continue to push XML out of the picture[13]

18. Thousands of APIs Paint a Bright Future for the Web[14]

19. 3,000 Web APIs: Trends From A Quickly Growing Directory[18]

20. How REST replaced SOAP on the Web: What it means to you[19]