我們堅持使用 web 系統可以理解或不需要太多努力就能理解的特殊格式，而且對人類(lèi)可讀性特別有用的格式。每個(gè)都有各自的優(yōu)缺點(diǎn)和適當的用例場(chǎng)景。
-- Tim Anderson
我是一名開(kāi)發(fā)者，我讀代碼，我寫(xiě)代碼，我寫(xiě)會(huì )寫(xiě)代碼的代碼，我寫(xiě)會(huì )寫(xiě)出供其它代碼讀的代碼的代碼。這些都非?；鹦钦Z(yǔ)，但是有其美妙之處。然而，最后一點(diǎn)，寫(xiě)會(huì )寫(xiě)出供其它代碼讀的代碼的代碼，可以很快變得比這段文字更費解。有很多方法可以做到這一點(diǎn)。一種不那么復雜而且開(kāi)發(fā)者社區最?lèi)?ài)的方式是數據序列化。對于那些不了解我剛剛拋給你的時(shí)髦詞的人，數據序列化是從一個(gè)系統獲取一些信息，將其轉換為其它系統可以讀取的格式，然后將其傳遞給其它系統的過(guò)程。
雖然 數據序列化格式 多到可以埋葬哈利法塔，但它們大多分為兩類(lèi)：
很難兩全其美，因為人類(lèi)喜歡讓我們更具表現力的松散類(lèi)型和靈活格式標準，而機器傾向于被確切告知一切事情而沒(méi)有二義性和細節缺失，并且認為“嚴格規范”才是它們最?lèi)?ài)的口味。
由于我是一名 web 開(kāi)發(fā)者，而且我們是一個(gè)創(chuàng )建網(wǎng)站的機構，我們將堅持使用 web 系統可以理解或不需要太多努力就能理解的特殊格式，而且對人類(lèi)可讀性特別有用的格式：XML、JSON、TOML、CSON 以及 YAML。每個(gè)都有各自的優(yōu)缺點(diǎn)和適當的用例場(chǎng)景。
回到互聯(lián)網(wǎng)的早期， 一些非常聰明的家伙 決定整合一種讓每個(gè)系統都能理解的標準語(yǔ)言，并創(chuàng )造性地將其命名為 標準通用標記語(yǔ)言(Standard Generalized Markup Language)（簡(jiǎn)稱(chēng) SGML）。SGML 非常靈活，發(fā)布者也很好地定義了它。它成為了 XML、SVG 和 HTML 等語(yǔ)言之父。所有這三個(gè)都符合 SGML 規范，可是它們都是規則更嚴格、靈活性更少的子集。
最終，人們開(kāi)始看到非常小、簡(jiǎn)潔、易讀且易于生成的數據的好處，這些數據可以在系統之間以編程的方式共享，而開(kāi)銷(xiāo)很小。大約在那個(gè)時(shí)候，JSON 誕生了并且能夠滿(mǎn)足所有的需求。而另一方面，其它語(yǔ)言也開(kāi)始出現以處理更多的專(zhuān)業(yè)用例，如 CSON，TOML 和 YAML。
原本，XML 語(yǔ)言非常靈活且易于編寫(xiě)，但它的缺點(diǎn)是冗長(cháng)，人類(lèi)難以閱讀、計算機非常難以讀取，并且有很多語(yǔ)法對于傳達信息并不是完全必要的。
今天，它在 web 上的數據序列化的用途已經(jīng)消失了。除非你在編寫(xiě) HTML 或者 SVG，否則你不太能在許多其它地方看到 XML。一些過(guò)時(shí)的系統今天仍在使用它，但是用它傳遞數據往往太重了。
我已經(jīng)可以聽(tīng)到 XML 老爺爺開(kāi)始在它們的石碑上亂寫(xiě)為什么 XML 是了不起的，所以我將提供一個(gè)小小的補充：XML 可以很容易地由系統和人讀寫(xiě)。然而，真的，我的意思是荒謬的，很難創(chuàng )建一個(gè)可以規范的讀取它的系統。這是一個(gè)簡(jiǎn)單美觀(guān)的 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>
太棒了。易于閱讀、理解、寫(xiě)入，也容易編碼一個(gè)可以讀寫(xiě)它的系統。但請考慮這個(gè)例子：
<!DOCTYPE r [ <!ENTITY y 'a]>b'> ]>
<r>
<a b='&y;>' />
<![CDATA[[a>b <a>b <a]]>
<?x <a> <!-- <b> ?> c --> d
</r>
這上面是 100% 有效的 XML。幾乎不可能閱讀、理解或推理。編寫(xiě)可以使用和理解這個(gè)的代碼將花費至少 36 根頭發(fā)和 248 磅咖啡渣。我們沒(méi)有那么多時(shí)間或咖啡，而且我們大多數老程序員們現在都是禿頭。所以，讓它活在我們的記憶里，就像 css hacks 、 IE 6 瀏覽器 和 真空管 一樣好了。
好吧，我們都同意，XML = 差勁。那么，好的替代品是什么？ JavaScript 對象表示法(JavaScript Object Notation)，簡(jiǎn)稱(chēng) JSON。JSON（讀起來(lái)像 Jason 這個(gè)名字） 是 Brendan Eich 發(fā)明的，并且得到了偉大而強力的 JavaScript 意見(jiàn)領(lǐng)袖 Douglas Crockford 的推廣。它現在幾乎用在任何地方。這種格式很容易由人和機器編寫(xiě)，按規范中的嚴格規則 解析 也相當容易，并且靈活 —— 允許深層嵌套數據，支持所有的原始數據類(lèi)型，及將集合解釋為數組或對象。JSON 成為了將數據從一個(gè)系統傳輸到另一個(gè)系統的事實(shí)標準。幾乎所有語(yǔ)言都有內置讀寫(xiě)它的功能。
JSON語(yǔ)法很簡(jiǎn)單。方括號表示數組，花括號表示記錄，由冒號分隔的兩個(gè)值分別表示屬性或“鍵”（在左邊）、值（在右邊）。所有鍵必須用雙引號括起來(lái)：
{
'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'
}
]
}
這對你來(lái)說(shuō)應該是完全有意義的。它簡(jiǎn)潔明了，并且從 XML 中刪除了大量額外廢話(huà)，并傳達相同數量的信息。JSON 現在是王道，本文剩下的部分會(huì )介紹其它語(yǔ)言格式，這些格式只不過(guò)是 JSON 的簡(jiǎn)化版，嘗試讓其更簡(jiǎn)潔或對人類(lèi)更易讀，可結構還是非常相似的。
TOML（ Tom 的顯而易見(jiàn)的最小化語(yǔ)言(Tom’s Obvious, Minimal Language)）允許以相當快捷、簡(jiǎn)潔的方式定義深層嵌套的數據結構。名字中的 Tom 是指發(fā)明者 Tom Preston Werner ，他是一位活躍于我們行業(yè)的創(chuàng )造者和軟件開(kāi)發(fā)人員。與 JSON 相比，語(yǔ)法有點(diǎn)尷尬，更類(lèi)似 ini 文件 。這不是一個(gè)糟糕的語(yǔ)法，但是需要一些時(shí)間適應。
[[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 中集成了一些很棒的功能，例如多行字符串、保留字符的自動(dòng)轉義、日期、時(shí)間、整數、浮點(diǎn)數、科學(xué)記數法和“表擴展”等數據類(lèi)型。最后一點(diǎn)是特別的，是 TOML 如此簡(jiǎn)潔的原因：
[a.b.c]
d = 'Hello'
e = 'World'
以上擴展到以下內容：
{
'a': {
'b': {
'c': {
'd': 'Hello'
'e': 'World'
}
}
}
}
使用 TOML，你可以肯定在時(shí)間和文件長(cháng)度上會(huì )節省不少。很少有系統使用它或非常類(lèi)似的東西作為配置，這是它最大的缺點(diǎn)。根本沒(méi)有很多語(yǔ)言或庫可以用來(lái)解釋 TOML。
首先，有兩個(gè) CSON 規范。 一個(gè)代表 CoffeeScript Object Notation，另一個(gè)代表 Cursive Script Object Notation。后者不經(jīng)常使用，所以我們不會(huì )關(guān)注它。我們只關(guān)注 CoffeeScript。
CSON 需要一點(diǎn)介紹。首先，我們來(lái)談?wù)?CoffeeScript。 CoffeeScript 是一種通過(guò)運行編譯器生成 JavaScript 的語(yǔ)言。它允許你以更加簡(jiǎn)潔的語(yǔ)法編寫(xiě) JavaScript 并 轉譯 成實(shí)際的 JavaScript，然后你可以在你的 web 應用程序中使用它。CoffeeScript 通過(guò)刪除 JavaScript 中必需的許多額外語(yǔ)法，使編寫(xiě) JavaScript 變得更容易。CoffeeScript 擺脫的一個(gè)大問(wèn)題是花括號 —— 不需要它們。同樣，CSON 是沒(méi)有大括號的 JSON。它依賴(lài)于縮進(jìn)來(lái)確定數據的層次結構。CSON 非常易于讀寫(xiě)，并且通常比 JSON 需要更少的代碼行，因為沒(méi)有括號。
CSON 還提供一些 JSON 不提供的額外細節。多行字符串非常容易編寫(xiě)，你可以通過(guò)使用 # 符號開(kāi)始一行來(lái)輸入 注釋 ，并且不需要用逗號分隔鍵值對。
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 的大問(wèn)題。它是 CoffeScript 對象表示法(CoffeeScript Object Notation)。也就是說(shuō)你要用 CoffeeScript 解析/標記化/lex/轉譯或其它方式來(lái)使用 CSON。CoffeeScript 是讀取數據的系統。如果數據序列化的目的是允許數據從一個(gè)系統傳遞到另一個(gè)系統，這里我們有一個(gè)只能由單個(gè)系統讀取的數據序列化格式，這使得它與防火火柴、防水海綿或者叉匙惱人的脆弱叉子部分一樣有用。
如果這種格式被其它系統也采用，那它在開(kāi)發(fā)者世界中可能非常有用。但到目前為止這基本上沒(méi)有發(fā)生，所以在 PHP 或 JAVA 等替代語(yǔ)言中使用它是不行的。
開(kāi)發(fā)人員感到高興，因為 YAML 來(lái)自 一個(gè) Python 的貢獻者 。YAML 具有與 CSON 相同的功能集和類(lèi)似的語(yǔ)法，有一系列新功能，以及幾乎所有 web 編程語(yǔ)言都可用的解析器。它還有一些額外的功能，如循環(huán)引用、軟包裝、多行鍵、類(lèi)型轉換標簽、二進(jìn)制數據、對象合并和 集合映射 。它具有非常好的可讀性和可寫(xiě)性，并且是 JSON 的超集，因此你可以在 YAML 中使用完全合格的 JSON 語(yǔ)法并且一切正常工作。你幾乎不需要引號，它可以解釋大多數基本數據類(lèi)型（字符串、整數、浮點(diǎn)數、布爾值等）。
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
業(yè)界的年輕人正在迅速采用 YAML 作為他們首選的數據序列化和系統配置格式。他們這樣做很機智。YAML 具有像 CSON 一樣簡(jiǎn)潔的所有好處，以及與 JSON 一樣的數據類(lèi)型解釋的所有功能。YAML 像加拿大人容易相處一樣容易閱讀。
YAML 有兩個(gè)問(wèn)題，對我而言，第一個(gè)是大問(wèn)題。在撰寫(xiě)本文時(shí)，YAML 解析器尚未內置于多種語(yǔ)言，因此你需要使用第三方庫或擴展來(lái)為你選擇的語(yǔ)言解析 .yaml 文件。這不是什么大問(wèn)題，可似乎大多數為 YAML 創(chuàng )建解析器的開(kāi)發(fā)人員都選擇隨機將“附加功能”放入解析器中。有些允許 標記化 ，有些允許 鏈引用 ，有些甚至允許內聯(lián)計算。這一切都很好（某種意義上），只是這些功能都不是規范的一部分，因此很難在其他語(yǔ)言的其他解析器中找到。這導致系統限定，你最終遇到了與 CSON 相同的問(wèn)題。如果你使用僅在一個(gè)解析器中找到的功能，則其他解析器將無(wú)法解釋輸入。大多數這些功能都是無(wú)意義的，不屬于數據集，而是屬于你的應用程序邏輯，因此最好簡(jiǎn)單地忽略它們和編寫(xiě)符合規范的 YAML。
第二個(gè)問(wèn)題是很少有解析器完全實(shí)現規范。所有的基本要素都有，但是很難找到一些更復雜和更新的東西，比如軟包裝、文檔標記和首選語(yǔ)言的循環(huán)引用。我還沒(méi)有看到對這些東西的剛需，所以希望它們不讓你很失望?？紤]到上述情況，我傾向于保持 1.1 規范 中呈現的更成熟的功能集，而避免在 1.2 規范 中找到的新東西。然而，編程是一個(gè)不斷發(fā)展的怪獸，所以當你讀完這篇文章時(shí)，你或許就可以使用 1.2 規范了。
這是最后一段話(huà)。每個(gè)序列化語(yǔ)言都應該以個(gè)案標準的方式評價(jià)。當涉及機器的可讀性時(shí)，有些 無(wú)出其右(the bee’s knees)。對于人類(lèi)可讀性，有些 名至實(shí)歸(the cat’s meow)，有些只是 金玉其外(gilded turds)。以下是最終細分：如果你要編寫(xiě)供其他代碼閱讀的代碼，請使用 YAML。如果你正在編寫(xiě)能寫(xiě)出供其他代碼讀取的代碼的代碼，請使用 JSON。最后，如果你正在編寫(xiě)將代碼轉譯為供其他代碼讀取的代碼的代碼，請重新考慮你的人生選擇。
via: https://www.zionandzion.com/json-vs-xml-vs-toml-vs-cson-vs-yaml/
聯(lián)系客服
