XML 與 JSON 優劣對比，TOML、CSON、YAML

簡介

XML 和 JSON 是現今互聯網中最常用的兩種數據交換格式。XML 格式由 W3C 於 1996 年提出。JSON 格式由 Douglas Crockford 於 2002 年提出。雖然這兩種格式的設計目標並不相同，但它們常常用於同一個任務，也就是數據交換中。XML 和 JSON 的文檔都很完善（RFC 7159、RFC 4825），且都同時具有 人類可讀性(human-readable)和 機器可讀性(machine-readable)。這兩種格式並沒有哪一個比另一個更強，只是各自適用的領域不用。（LCTT 譯註：W3C 是互聯網聯盟，制定了各種 Web 相關的標準，如 HTML、CSS 等。Douglas Crockford 除了制定了 JSON 格式，還致力於改進 JavaScript，開發了 JavaScript 相關工具 JSLint 和 JSMin）

XML 的優點

XML 與 JSON 相比有很多優點。二者間最大的不同在於 XML 可以通過在標籤中添加屬性這一簡單的方法來存儲 元數據(metadata)。而使用 JSON 時需要創建一個對象，把元數據當作對象的成員來存儲。雖然二者都能達到存儲元數據的目的，但在這一情況下 XML 往往是更好的選擇，因爲 JSON 的表達形式會讓客戶端程序開發人員誤以爲要將數據轉換成一個對象。舉個例子，如果你的 C++ 程序需要使用 JSON 格式發送一個附帶元數據的整型數據，需要創建一個對象，用對象中的一個 名稱/值對(name/value pair)來記錄整型數據的值，再爲每一個附帶的屬性添加一個名稱/值對。接收到這個 JSON 的程序在讀取後很可能把它當成一個對象，可事實並不是這樣。雖然這是使用 JSON 傳遞元數據的一種變通方法，但他違背了 JSON 的核心理念：“ JSON 的結構與常規的程序語言中的結構相對應，而無需修改。(JSON’s structures look like conventional programming language structures. No restructuring is necessary.)”1

雖然稍後我會說這也是 XML 的一個缺點，但 XML 中對命名衝突、 前綴(prefix)的處理機制賦予了它 JSON 所不具備的能力。程序員們可以通過前綴來把統一名稱給予兩個不同的實體。2 當不同的實體在客戶端中使用的名稱相同時，這一特性會非常有用。

XML 的另一個優勢在於大多數的瀏覽器可以把它以 具有高可讀性和強組織性的方式(highly readable and organized way)展現給用戶。XML 的樹形結構讓它易於結構化，瀏覽器也讓用戶可以自行展開或摺疊樹中的元素，這簡直就是調試的福音。

XML 對比 JSON 有一個很重要的優勢就是它可以記錄 混合內容(mixed content)。例如在 XML 中處理包含結構化標記的字符串時，程序員們只要把帶有標記的文本放在一個標籤內就可以了。可因爲 JSON 只包含數據，沒有用於指明標籤的簡單方式，雖然可以使用處理元數據的解決方法，但這總有點濫用之嫌。

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 的另一個優點在於其對對象和數組的表述和 宿主語言(host language)中的數據結構相對應，例如 對象(object)、 記錄(record)、 結構體(struct)、 字典(dictionary)、 哈希表(hash table)、 鍵值列表(keyed list)還有 數組(array)、 向量(vector)、 列表(list)，以及對象組成的數組等等。8 雖然 XML 裏也能表達這些數據結構，也只需調用一個函數就能完成解析，而往往需要更多的代碼才能正確的完成 XML 的序列化和反序列化處理。而且 XML 對於人類來說不如 JSON 那麼直觀，XML 標準缺乏對象、數組的標籤的明確定義。當結構化的標記可以替代嵌套的標籤時，JSON 的優勢極爲突出。JSON 中的花括號和中括號則明確表示了數據的結構，當然這一優勢也包含前文中的問題，在表示元數據時 JSON 不如 XML 準確。

雖然 XML 支持 命名空間(namespace)與 前綴(prefix)，但這不代表 JSON 沒有處理命名衝突的能力。比起 XML 的前綴，它處理命名衝突的方式更簡潔，在程序中的處理也更自然。在 JSON 裏，每一個對象都在它自己的命名空間中，因此不同對象內的元素名稱可以隨意重複。在大多數編程語言中，不同的對象中的成員可以包含相同的名字，所以 JSON 根據對象進行名稱區分的規則在處理時更加自然。

也許 JSON 比 XML 更優的部分是因爲 JSON 是 JavaScript 的子集，所以在 JavaScript 代碼中對它的解析或封裝都非常的自然。雖然這看起來對 JavaScript 程序非常有用，而其他程序則不能直接從中獲益，可實際上這一問題已經被很好的解決了。現在 JSON 的網站的列表上展示了 64 種不同語言的 175 個工具，它們都實現了處理 JSON 所需的功能。雖然我不能評價大多數工具的質量，但它們的存在明確了開發者社區擁抱 JSON 這一現象，而且它們切實簡化了在不同平臺使用 JSON 的難度。

二者的動機

簡單地說，XML 的目標是標記文檔。這和 JSON 的目標想去甚遠，所以只要用得到 XML 的地方就儘管用。它使用樹形的結構和包含語義的文本來表達混合內容以實現這一目標。在 XML 中可以表示數據的結構，但這並不是它的長處。

JSON 的目標是用於數據交換的一種結構化表示。它直接使用對象、數組、數字、字符串、布爾值這些元素來達成這一目標。這完全不同於文檔標記語言。正如上面說的那樣，JSON 沒有原生支持 混合內容(mixed content)的記錄。

軟件

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

這些主流 API 僅提供 JSON： 臉書圖 API(Facebook Graph API)、 谷歌地圖 API(Google Maps API)、 推特 API(Twitter API)、AccuWeather API、Pinterest API、Reddit API、Foursquare API。

這些主流 API 同時提供 XML 和 JSON： 谷歌雲存儲(Google Cloud Storage)、 領英 API(Linkedin API)、Flickr API。

根據 可編程網絡(Programmable Web) 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 和關係型數據庫統治着整個數據庫市場。像 甲骨文(Oracle)和 微軟(Microsoft)這樣的軟件巨頭都提供這類數據庫，然而近幾年 NoSQL 數據庫正逐步受到開發者的青睞。也許是正巧碰上了 JSON 的普及，大多數 NoSQL 數據庫都支持 JSON，像 MongoDB、CouchDB 和 Riak 這樣的數據庫甚至使用 JSON 來存儲數據。這些數據庫有兩個重要的特性是它們適用於現代網站：一是它們與關係型數據庫相比 更容易擴展(more scalable)；二是它們設計的目標就是 web 運行所需的核心組件。12 由於 JSON 更加輕量，又是 JavaScript 的子集，所以很適合 NoSQL 數據庫，並且讓這兩個品質更容易實現。此外，許多舊的關係型數據庫增加了 JSON 支持，例如 Oracle Database 和 PostgreSQL。由於 XML 與 JSON 間的轉換比較麻煩，所以大多數開發者會直接在他們的應用裏使用 JSON，因此開發數據庫的公司纔有支持 JSON 的理由。（LCTT 譯註：NoSQL 是對不同於傳統的關係數據庫的數據庫管理系統的統稱。參考來源） 13

未來

對互聯網的種種變革中，最讓人期待的便是 物聯網(Internet of Things)（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 更好的情況並不多。

角注

1. Introducing JSON↩
2. XML Tutorial↩
3. JSON vs. XML: Some hard numbers about verbosity↩
4. Comparison of JSON and XML Data Interchange Formats: A Case Study↩
5. A comparison of data serialization formats for optimal efficiency on a mobile platform↩
6. Comparison of JSON and XML Data Interchange Formats: A Case Study↩
7. A comparison of data serialization formats for optimal efficiency on a mobile platform↩
8. Introducing JSON↩
9. Most Popular APIs: At Least One Will Surprise You↩
10. Why JSON will continue to push XML out of the picture↩
11. Thousands of APIs Paint a Bright Future for the Web↩
12. Why JSON will continue to push XML out of the picture↩
13. How JSON sparked NoSQL – and will return to the RDBMS fold↩
14. A Simple Explanation Of ‘The Internet Of Things’↩
15. Proofpoint Uncovers Internet of Things (IoT) Cyberattack↩
16. Why JSON will continue to push XML out of the picture↩
17. Why JSON will continue to push XML out of the picture↩
18. Thousands of APIs Paint a Bright Future for the Web↩
19. 3,000 Web APIs: Trends From A Quickly Growing Directory↩
20. How REST replaced SOAP on the Web: What it means to you↩

 

JSON不總是更小,如: <a b="c"/> 和 "a":{"b":"c"} 對比一下長度

都9102年了，對比不應該加上yaml和protobuf麼？

JSON、XML、TOML、CSON、YAML 大比拼

一段超級嚴肅的關於樣本序列化的集合、子集和超集的文字

我是一名開發者，我讀代碼，我寫代碼，我寫會寫代碼的代碼，我寫會寫出供其它代碼讀的代碼的代碼。這些都非常火星語，但是有其美妙之處。然而，最後一點，寫會寫出供其它代碼讀的代碼的代碼，可以很快變得比這段文字更費解。有很多方法可以做到這一點。一種不那麼複雜而且開發者社區最愛的方式是數據序列化。對於那些不瞭解我剛剛拋給你的時髦詞的人，數據序列化是從一個系統獲取一些信息，將其轉換爲其它系統可以讀取的格式，然後將其傳遞給其它系統的過程。

雖然數據序列化格式多到可以埋葬哈利法塔，但它們大多分爲兩類：

• 易於人類讀寫，
• 易於機器讀寫。

很難兩全其美，因爲人類喜歡讓我們更具表現力的鬆散類型和靈活格式標準，而機器傾向於被確切告知一切事情而沒有二義性和細節缺失，並且認爲“嚴格規範”纔是它們最愛的口味。

由於我是一名 web 開發者，而且我們是一個創建網站的機構，我們將堅持使用 web 系統可以理解或不需要太多努力就能理解的特殊格式，而且對人類可讀性特別有用的格式：XML、JSON、TOML、CSON 以及 YAML。每個都有各自的優缺點和適當的用例場景。

事實最先

回到互聯網的早期，一些非常聰明的傢伙決定整合一種讓每個系統都能理解的標準語言，並創造性地將其命名爲 標準通用標記語言(Standard Generalized Markup Language)（簡稱 SGML）。SGML 非常靈活，發佈者也很好地定義了它。它成爲了 XML、SVG 和 HTML 等語言之父。所有這三個都符合 SGML 規範，可是它們都是規則更嚴格、靈活性更少的子集。

最終，人們開始看到非常小、簡潔、易讀且易於生成的數據的好處，這些數據可以在系統之間以編程的方式共享，而開銷很小。大約在那個時候，JSON 誕生了並且能夠滿足所有的需求。而另一方面，其它語言也開始出現以處理更多的專業用例，如 CSON，TOML 和 YAML。

XML：不行了

原本，XML 語言非常靈活且易於編寫，但它的缺點是冗長，人類難以閱讀、計算機非常難以讀取，並且有很多語法對於傳達信息並不是完全必要的。

今天，它在 web 上的數據序列化的用途已經消失了。除非你在編寫 HTML 或者 SVG，否則你不太能在許多其它地方看到 XML。一些過時的系統今天仍在使用它，但是用它傳遞數據往往太重了。

我已經可以聽到 XML 老爺爺開始在它們的石碑上亂寫爲什麼 XML 是了不起的，所以我將提供一個小小的補充：XML 可以很容易地由系統和人讀寫。然而，真的，我的意思是荒謬的，很難創建一個可以規範的讀取它的系統。這是一個簡單美觀的 XML 示例：

<book id="bk101">
<author>Gambardella, Matthew</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications
with XML.</description>
</book>

太棒了。易於閱讀、理解、寫入，也容易編碼一個可以讀寫它的系統。但請考慮這個例子：

<!DOCTYPE r [ <!ENTITY y "a]>b"> ]>
<r>
<a b="&y;>" />
<![CDATA[[a>b <a>b <a]]>
<?x <a> <!-- <b> ?> c --> d
</r>

這上面是 100% 有效的 XML。幾乎不可能閱讀、理解或推理。編寫可以使用和理解這個的代碼將花費至少 36 根頭髮和 248 磅咖啡渣。我們沒有那麼多時間或咖啡，而且我們大多數老程序員們現在都是禿頭。所以，讓它活在我們的記憶裏，就像 css hacks、IE 6 瀏覽器 和真空管一樣好了。

JSON：並列聚會

好吧，我們都同意，XML = 差勁。那麼，好的替代品是什麼？ JavaScript 對象表示法(JavaScript Object Notation)，簡稱 JSON。JSON（讀起來像 Jason 這個名字） 是 Brendan Eich 發明的，並且得到了偉大而強力的 JavaScript 意見領袖 Douglas Crockford 的推廣。它現在幾乎用在任何地方。這種格式很容易由人和機器編寫，按規範中的嚴格規則解析也相當容易，並且靈活 —— 允許深層嵌套數據，支持所有的原始數據類型，及將集合解釋爲數組或對象。JSON 成爲了將數據從一個系統傳輸到另一個系統的事實標準。幾乎所有語言都有內置讀寫它的功能。

JSON語法很簡單。方括號表示數組，花括號表示記錄，由冒號分隔的兩個值分別表示屬性或“鍵”（在左邊）、值（在右邊）。所有鍵必須用雙引號括起來：

{
    "books": [
      {
        "id": "bk102",
        "author": "Crockford, Douglas",
        "title": "JavaScript: The Good Parts",
        "genre": "Computer",
        "price": 29.99,
        "publish_date": "2008-05-01",
        "description": "Unearthing the Excellence in JavaScript"
      }
    ]
  }

這對你來說應該是完全有意義的。它簡潔明瞭，並且從 XML 中刪除了大量額外廢話，並傳達相同數量的信息。JSON 現在是王道，本文剩下的部分會介紹其它語言格式，這些格式只不過是 JSON 的簡化版，嘗試讓其更簡潔或對人類更易讀，可結構還是非常相似的。

TOML: 縮短到徹底的利他主義

TOML（ Tom 的顯而易見的最小化語言(Tom’s Obvious, Minimal Language)）允許以相當快捷、簡潔的方式定義深層嵌套的數據結構。名字中的 Tom 是指發明者 Tom Preston Werner，他是一位活躍於我們行業的創造者和軟件開發人員。與 JSON 相比，語法有點尷尬，更類似 ini 文件。這不是一個糟糕的語法，但是需要一些時間適應。

[[books]]
id = 'bk101'
author = 'Crockford, Douglas'
title = 'JavaScript: The Good Parts'
genre = 'Computer'
price = 29.99
publish_date = 2008-05-01T00:00:00+00:00
description = 'Unearthing the Excellence in JavaScript'

TOML 中集成了一些很棒的功能，例如多行字符串、保留字符的自動轉義、日期、時間、整數、浮點數、科學記數法和“表擴展”等數據類型。最後一點是特別的，是 TOML 如此簡潔的原因：

[a.b.c]
d = 'Hello'
e = 'World'

以上擴展到以下內容：

{
  "a": { 
    "b": {
      "c": { 
        "d": "Hello"
        "e": "World"
      }
    }
  }
}

使用 TOML，你可以肯定在時間和文件長度上會節省不少。很少有系統使用它或非常類似的東西作爲配置，這是它最大的缺點。根本沒有很多語言或庫可以用來解釋 TOML。

CSON: 特定系統所包含的簡單樣本

首先，有兩個 CSON 規範。 一個代表 CoffeeScript Object Notation，另一個代表 Cursive Script Object Notation。後者不經常使用，所以我們不會關注它。我們只關注 CoffeeScript。

CSON 需要一點介紹。首先，我們來談談 CoffeeScript。CoffeeScript 是一種通過運行編譯器生成 JavaScript 的語言。它允許你以更加簡潔的語法編寫 JavaScript 並轉譯成實際的 JavaScript，然後你可以在你的 web 應用程序中使用它。CoffeeScript 通過刪除 JavaScript 中必需的許多額外語法，使編寫 JavaScript 變得更容易。CoffeeScript 擺脫的一個大問題是花括號 —— 不需要它們。同樣，CSON 是沒有大括號的 JSON。它依賴於縮進來確定數據的層次結構。CSON 非常易於讀寫，並且通常比 JSON 需要更少的代碼行，因爲沒有括號。

CSON 還提供一些 JSON 不提供的額外細節。多行字符串非常容易編寫，你可以通過使用 # 符號開始一行來輸入註釋，並且不需要用逗號分隔鍵值對。

books: [
  id: 'bk102'
  author: 'Crockford, Douglas'
  title: 'JavaScript: The Good Parts'
  genre: 'Computer'
  price: 29.99
  publish_date: '2008-05-01'
  description: 'Unearthing the Excellence in JavaScript'
]

這是 CSON 的大問題。它是 CoffeScript 對象表示法(CoffeeScript Object Notation)。也就是說你要用 CoffeeScript 解析/標記化/lex/轉譯或其它方式來使用 CSON。CoffeeScript 是讀取數據的系統。如果數據序列化的目的是允許數據從一個系統傳遞到另一個系統，這裏我們有一個只能由單個系統讀取的數據序列化格式，這使得它與防火火柴、防水海綿或者叉匙惱人的脆弱叉子部分一樣有用。

如果這種格式被其它系統也採用，那它在開發者世界中可能非常有用。但到目前爲止這基本上沒有發生，所以在 PHP 或 JAVA 等替代語言中使用它是不行的。

YAML：年輕人的呼喊

開發人員感到高興，因爲 YAML 來自一個 Python 的貢獻者。YAML 具有與 CSON 相同的功能集和類似的語法，有一系列新功能，以及幾乎所有 web 編程語言都可用的解析器。它還有一些額外的功能，如循環引用、軟包裝、多行鍵、類型轉換標籤、二進制數據、對象合併和集合映射。它具有非常好的可讀性和可寫性，並且是 JSON 的超集，因此你可以在 YAML 中使用完全合格的 JSON 語法並且一切正常工作。你幾乎不需要引號，它可以解釋大多數基本數據類型（字符串、整數、浮點數、布爾值等）。

books:
  - id: bk102
  author: Crockford, Douglas
  title: 'JavaScript: The Good Parts'
  genre: Computer
  price: 29.99
  publish_date: !!str 2008-05-01
  description: Unearthing the Excellence in JavaScript

業界的年輕人正在迅速採用 YAML 作爲他們首選的數據序列化和系統配置格式。他們這樣做很機智。YAML 具有像 CSON 一樣簡潔的所有好處，以及與 JSON 一樣的數據類型解釋的所有功能。YAML 像加拿大人容易相處一樣容易閱讀。

YAML 有兩個問題，對我而言，第一個是大問題。在撰寫本文時，YAML 解析器尚未內置於多種語言，因此你需要使用第三方庫或擴展來爲你選擇的語言解析 .yaml 文件。這不是什麼大問題，可似乎大多數爲 YAML 創建解析器的開發人員都選擇隨機將“附加功能”放入解析器中。有些允許標記化，有些允許鏈引用，有些甚至允許內聯計算。這一切都很好（某種意義上），只是這些功能都不是規範的一部分，因此很難在其他語言的其他解析器中找到。這導致系統限定，你最終遇到了與 CSON 相同的問題。如果你使用僅在一個解析器中找到的功能，則其他解析器將無法解釋輸入。大多數這些功能都是無意義的，不屬於數據集，而是屬於你的應用程序邏輯，因此最好簡單地忽略它們和編寫符合規範的 YAML。

第二個問題是很少有解析器完全實現規範。所有的基本要素都有，但是很難找到一些更復雜和更新的東西，比如軟包裝、文檔標記和首選語言的循環引用。我還沒有看到對這些東西的剛需，所以希望它們不讓你很失望。考慮到上述情況，我傾向於保持 1.1 規範 中呈現的更成熟的功能集，而避免在 1.2 規範 中找到的新東西。然而，編程是一個不斷髮展的怪獸，所以當你讀完這篇文章時，你或許就可以使用 1.2 規範了。

最終哲學

這是最後一段話。每個序列化語言都應該以個案標準的方式評價。當涉及機器的可讀性時，有些 無出其右(the bee’s knees)。對於人類可讀性，有些 名至實歸(the cat’s meow)，有些只是 金玉其外(gilded turds)。以下是最終細分：如果你要編寫供其他代碼閱讀的代碼，請使用 YAML。如果你正在編寫能寫出供其他代碼讀取的代碼的代碼，請使用 JSON。最後，如果你正在編寫將代碼轉譯爲供其他代碼讀取的代碼的代碼，請重新考慮你的人生選擇。

---

---