XML 和 JSON 是現今網際網路中最常用的兩種資料交換格式。XML 格式由 W3C 於 1996 年提出。JSON 格式由 Douglas Crockford 於 2002 年提出。雖然這兩種格式的設計目標並不相同，但它們常常用於同一個任務，也就是資料交換中。XML 和 JSON 的文件都很完善（RFC 7159、RFC 4825），且都同時具有人類可讀性和機器可讀性。這兩種格式並沒有哪一個比另一個更強，只是各自適用的領域不用。（LCTT 譯註：W3C 是網際網路聯盟，制定了各種 Web 相關的標準，如 HTML、CSS 等。Douglas Crockford 除了制定了 JSON 格式，還致力於改進 JavaScript，開發了 JavaScript 相關工具 JSLint 和 JSMin）
XML 與 JSON 相比有很多優點。二者間最大的不同在於 XML 可以通過在標籤中新增屬性這一簡單的方法來儲存後設資料。而使用 JSON 時需要建立一個物件，把後設資料當作物件的成員來儲存。雖然二者都能達到儲存後設資料的目的，但在這一情況下 XML 往往是更好的選擇，因為 JSON 的表達形式會讓用戶端程式開發人員誤以為要將資料轉換成一個物件。舉個例子，如果你的 C++ 程式需要使用 JSON 格式傳送一個附帶後設資料的整型資料，需要建立一個物件，用物件中的一個名稱/值對來記錄整型資料的值，再為每一個附帶的屬性新增一個名稱/值對。接收到這個 JSON 的程式在讀取後很可能把它當成一個物件，可事實並不是這樣。雖然這是使用 JSON 傳遞後設資料的一種變通方法，但他違背了 JSON 的核心理念：“JSON 的結構與常規的程式語言中的結構相對應，而無需修改。”1
雖然稍後我會說這也是 XML 的一個缺點，但 XML 中對命名衝突、字首的處理機制賦予了它 JSON 所不具備的能力。程式設計師們可以通過字首來把統一名稱給予兩個不同的實體。2 當不同的實體在用戶端中使用的名稱相同時，這一特性會非常有用。
XML 的另一個優勢在於大多數的瀏覽器可以把它以具有高可讀性和強組織性的方式展現給使用者。XML 的樹形結構讓它易於結構化，瀏覽器也讓使用者可以自行展開或折疊樹中的元素，這簡直就是偵錯的福音。
XML 對比 JSON 有一個很重要的優勢就是它可以記錄混合內容。例如在 XML 中處理包含結構化標記的字串時，程式設計師們只要把帶有標記的文字放在一個標籤內就可以了。可因為 JSON 只包含資料，沒有用於指明標籤的簡單方式，雖然可以使用處理後設資料的解決方法，但這總有點濫用之嫌。
JSON 自身也有很多優點。其中最顯而易見的一點就是 JSON 比 XML 簡潔得多。因為 XML 中需要開啟和關閉標籤，而 JSON 使用名稱/值對表示資料，使用簡單的 { 和 } 來標記物件，[ 和 ] 來標記陣列，, 來表示資料的分隔，: 表示名稱和值的分隔。就算是使用 gzip 壓縮，JSON 還是比 XML 要小，而且耗時更少。3 正如 Sumaray 和 Makki 在實驗中指出的那樣，JSON 在很多方面都比 XML 更具優勢，得出同樣結果的還有 Nurseitov、Paulson、Reynolds 和 Izurieta。首先，由於 JSON 檔案天生的簡潔性，與包含相同資訊的 XML 相比，JSON 總是更小，這意味著更快的傳輸和處理速度。第二，在不考慮大小的情況下，兩組研究 4 5 表明使用 JSON 執行序列化和反序列化的速度顯著優於使用 XML。第三，後續的研究指出 JSON 的處理在 CPU 資源的使用上也優於 XML。研究人員發現 JSON 在總體上使用的資源更少，其中更多的 CPU 資源消耗在使用者空間，系統空間消耗的 CPU 資源較少。這一實驗是在 RedHat 的裝置上進行的，RedHat 表示更傾向於在使用者空間使用 CPU 資源。6 不出意外，Sumaray 和 Makki 在研究裡還說明了在移動裝置上 JSON 的效能也優於 XML。7 這是有道理的，因為 JSON 消耗的資源更少，而移動裝置的效能也更弱。
JSON 的另一個優點在於其對物件和陣列的表述和宿主語言中的資料結構相對應，例如物件、記錄、結構體、字典、雜湊表、鍵值列表還有陣列、向量、列表，以及物件組成的陣列等等。8 雖然 XML 裡也能表達這些資料結構，也只需呼叫一個函數就能完成解析，而往往需要更多的程式碼才能正確的完成 XML 的序列化和反序列化處理。而且 XML 對於人類來說不如 JSON 那麼直觀，XML 標準缺乏物件、陣列的標籤的明確定義。當結構化的標記可以替代巢狀的標籤時，JSON 的優勢極為突出。JSON 中的花括號和中括號則明確表示了資料的結構，當然這一優勢也包含前文中的問題，在表示後設資料時 JSON 不如 XML 準確。
雖然 XML 支援名稱空間與字首，但這不代表 JSON 沒有處理命名衝突的能力。比起 XML 的字首，它處理命名衝突的方式更簡潔，在程式中的處理也更自然。在 JSON 裡，每一個物件都在它自己的名稱空間中，因此不同物件內的元素名稱可以隨意重複。在大多數程式語言中，不同的物件中的成員可以包含相同的名字，所以 JSON 根據物件進行名稱區分的規則在處理時更加自然。
也許 JSON 比 XML 更優的部分是因為 JSON 是 JavaScript 的子集，所以在 JavaScript 程式碼中對它的解析或封裝都非常的自然。雖然這看起來對 JavaScript 程式非常有用，而其他程式則不能直接從中獲益，可實際上這一問題已經被很好的解決了。現在 JSON 的網站的列表上展示了 64 種不同語言的 175 個工具，它們都實現了處理 JSON 所需的功能。雖然我不能評價大多數工具的品質，但它們的存在明確了開發者社群擁抱 JSON 這一現象，而且它們切實簡化了在不同平台使用 JSON 的難度。
簡單地說，XML 的目標是標記文件。這和 JSON 的目標想去甚遠，所以只要用得到 XML 的地方就儘管用。它使用樹形的結構和包含語意的文字來表達混合內容以實現這一目標。在 XML 中可以表示資料的結構，但這並不是它的長處。
JSON 的目標是用於資料交換的一種結構化表示。它直接使用物件、陣列、數位、字串、布林值這些元素來達成這一目標。這完全不同於文件標示語言。正如上面說的那樣，JSON 沒有原生支援混合內容的記錄。
這些主流的開放 API 僅提供 XML：亞馬遜產品廣告 API。
這些主流 API 僅提供 JSON：臉書圖 API、谷歌地圖 API、推特 API、AccuWeather API、Pinterest API、Reddit API、Foursquare API。
這些主流 API 同時提供 XML 和 JSON：谷歌雲端儲存、領英 API、Flickr API。
根據可程式化網路 9 的資料，最流行的 10 個 API 中只有一個是僅提供 XML 且不支援 JSON 的。其他的要麼同時支援 XML 和 JSON，要麼只支援 JSON。這表明了大多數應用開發者都更傾向於使用支援 JSON 的 API，原因大概是 JSON 更快的處理速度與良好口碑，加之與 XML 相比更加輕量。此外，大多數 API 只是傳遞資料而非文件，所以 JSON 更加合適。例如 Facebook 的重點在於使用者的交流與貼文，谷歌地圖則主要處理坐標和地圖資訊，AccuWeather 就只傳遞天氣資料。總之，雖然不能說天氣 API 在使用時究竟是 JSON 用的多還是 XML 用的多，但是趨勢明確偏向了 JSON。10 11
這些主流的桌面軟體仍然只是用 XML：Microsoft Word、Apache OpenOffice、LibraOffice。
因為這些軟體需要考慮參照、格式、儲存等等，所以比起 JSON，XML 優勢更大。另外，這三款程式都支援混合內容，而 JSON 在這一點上做得並不如 XML 好。舉例說明，當使用者使用 Microsoft Word 編輯一篇論文時，使用者需要使用不同的文字字形、文字大小、文字顏色、頁邊距、段落格式等，而 XML 結構化的組織形式與標籤屬性生來就是為了表達這些資訊的。
這些主流的資料庫支援 XML：IBM DB2、Microsoft SQL Server、Oracle Database、PostgresSQL、BaseX、eXistDB、MarkLogic、MySQL。
這些是支援 JSON 的主流資料庫：MongoDB、CouchDB、eXistDB、Elastisearch、BaseX、MarkLogic、OrientDB、Oracle Database、PostgreSQL、Riak。
在很長一段時間裡，SQL 和關係型資料庫統治著整個資料庫市場。像甲骨文和微軟這樣的軟體巨頭都提供這類資料庫，然而近幾年 NoSQL 資料庫正逐步受到開發者的青睞。也許是正巧碰上了 JSON 的普及，大多數 NoSQL 資料庫都支援 JSON，像 MongoDB、CouchDB 和 Riak 這樣的資料庫甚至使用 JSON 來儲存資料。這些資料庫有兩個重要的特性是它們適用於現代網站：一是它們與關係型資料庫相比更容易擴充套件；二是它們設計的目標就是 web 執行所需的核心元件。12 由於 JSON 更加輕量，又是 JavaScript 的子集，所以很適合 NoSQL 資料庫，並且讓這兩個品質更容易實現。此外，許多舊的關係型資料庫增加了 JSON 支援，例如 Oracle Database 和 PostgreSQL。由於 XML 與 JSON 間的轉換比較麻煩，所以大多數開發者會直接在他們的應用裡使用 JSON，因此開發資料庫的公司才有支援 JSON 的理由。（LCTT 譯註：NoSQL 是對不同於傳統的關聯式資料庫的資料庫管理系統的統稱。參考來源） 13
對網際網路的種種變革中，最讓人期待的便是物聯網（IoT）。這會給網際網路帶來大量計算機之外的裝置，例如手錶、溫度計、電視、冰箱等等。這一勢頭的發展良好，預期在不久的將來迎來爆發式的增長。據估計，到 2020 年時會有 260 億 到 2000 億的物聯網裝置被接入網際網路。14 15 幾乎所有的物聯網裝置都是小型裝置，因此效能比筆電或台式電腦要弱很多，而且大多數都是嵌入式系統。因此，當它們需要與網際網路上的系統交換資料時，更輕量、更快速的 JSON 自然比 XML 更受青睞。16 受益於 JSON 在 web 上的快速普及，與 XML 相比，這些新的物聯網裝置更有可能從使用 JSON 中受益。這是一個典型的梅特卡夫定律的例子，無論是 XML 還是 JSON，抑或是什麼其他全新的格式，現存的裝置和新的裝置都會從支援最廣泛使用的格式中受益。
Node.js 是一款伺服器端的 JavaScript 框架，隨著她的誕生與快速成長，與 MongoDB 等 NoSQL 資料庫一起，讓全棧使用 JavaScript 開發成為可能。這些都預示著 JSON 光明的未來，這些軟體的出現讓 JSON 運用在全棧開發的每一個環節成為可能，這將使應用更加輕量，響應更快。這也是任何應用的追求之一，所以，全棧使用 JavaScript 的趨勢在不久的未來都不會消退。17
此外，另一個應用開發的趨勢是從 SOAP 轉向 REST。18 19 20 XML 和 JSON 都可以用於 REST，可 SOAP 只能使用 XML。
從這些趨勢中可以推斷，JSON 的發展將統一 Web 的資訊交換格式，XML 的使用率將繼續降低。雖然不應該把 JSON 吹過頭了，因為 XML 在 Web 中的使用依舊很廣，而且它還是 SOAP 的唯一選擇，可考慮到 SOAP 到 REST 的遷移，NoSQL 資料庫和全棧 JavaScript 的興起，JSON 卓越的效能，我相信 JSON 很快就會在 Web 開發中超過 XML。至於其他領域，XML 比 JSON 更好的情況並不多。
Comparison of JSON and XML Data Interchange Formats: A Case Study ?
A comparison of data serialization formats for optimal efficiency on a mobile platform ?
Comparison of JSON and XML Data Interchange Formats: A Case Study ?
A comparison of data serialization formats for optimal efficiency on a mobile platform ?
How JSON sparked NoSQL – and will return to the RDBMS fold ?