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。最後，若是你正在編寫將代碼轉譯爲供其餘代碼讀取的代碼的代碼，請從新考慮你的人生選擇。

---

via: www.zionandzion.com/json-vs-xml…

做者：Tim Anderson 選題：lujun9972 譯者：GraveAccent 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出