繁體 ▾
Free, Fast & Secure Online Tools
JSON 是 JavaScript Object Notation 的縮寫，而這是一個會誤導人的名字——它現在和 JavaScript 關係很小，而且什麼東西都在用它。它是一種用純文字寫結構化資料的方式，當你跟一個服務要求匯出你的帳號資料、當一個 App 儲存它的設定、當一個程式把資料送給另一個程式，拿到的就是它。
一個小例子幾乎包含了這個格式能做的全部：
{
"name": "Widget",
"price": 4.50,
"inStock": true,
"tags": ["small", "blue"],
"discount": null
}
大括號裝著一個物件——一組有名字的值。方括號裝著一個陣列——一個有順序的清單。而整個型別系統就是這些：物件、陣列、字串、數字、true／false，以及 null。六樣東西。
物件和陣列可以互相包含到任意深度，JSON 就是這樣用這麼小的詞彙量描述複雜結構的。
JSON 嚴格得會讓任何寫過真正程式語言的人意外，因為它長得像好幾種語言，卻禁止那些語言允許的事。
'name' 是無效的。每一個字串和每一個鍵都要雙引號。name: "Widget" 無效；"name": "Widget" 才對。// 不行，/* */ 也不行。這是這個格式歷史上被抱怨最多的缺席，而它是刻意的：註解會誘使人把意義放在剖析器會忽略的地方。註解禁令有一個通用的變通做法：加一個普通的鍵，比如 "_comment"，把你的備註當成它的值。那不是註解——程式會把它當成資料讀——但那就是大家在設定檔裡放說明的位置。
這件事值得理解，因為它會讓錯誤訊息沒那麼令人挫折。
JSON 沒有任何從語法錯誤中恢復的辦法。它不像 CSV 有「行」這種紀錄邊界，所以一個碰到意外內容的剖析器沒辦法跳過壞掉的部分繼續——整個檔案就是失敗。
更糟的是，報出來的行號是剖析器察覺的地方，不是你犯錯的地方。在靠前的位置漏掉一個右大括號，錯誤會出現在檔案的最尾端，因為那才是結構第一次變得不可能的點。漏掉一個逗號，訊息常常指向你要修的那一行的下一行。
所以當一個 JSON 錯誤指出某一行，去看它上面的結構，而不是那一行本身。一個驗證器、或者一個會標示成對括號的編輯器，找這些東西比用讀的快得多。
兩者都是純文字，兩者都在描述結構。JSON 在資料交換上贏在兩點。
第一是重量。XML 裡一個值要被一個開標籤和一個閉標籤包起來；JSON 裡它是一個名字、一個冒號和那個值。在一個大檔案上，那在體積和可讀性上都是相當大的差別。
第二點更要緊：JSON 的六種型別直接對應到每一種程式語言本來就有的資料結構。物件變成字典、陣列變成清單、數字就是數字。XML 需要解讀——在某個東西決定它是什麼意思之前，一切都是文字。
JSON 換來這些所放棄的，是所有和文件有關的能力：沒有註解、沒有屬性、沒有命名空間，也沒有辦法表示「文字裡面夾著標記」。這就是為什麼資料以 JSON 流通，而文件留在 XML。
這是常見的實際任務，而它行不行得通，完全取決於你資料的形狀。
一個扁平的物件陣列轉得很乾淨。一串欄位都相同的紀錄就是一張表：一個物件一列，一個鍵一欄。任何轉換工具都處理得了。
巢狀資料不行。如果每一筆紀錄裡面含有另一組物件的陣列——一張有好幾個品項的訂單、一個有多個地址的使用者——沒有誠實的方法把那個放進一個格子裡。轉換要嘛把它攤平成 items.0.name、items.1.name 這樣的欄位，要嘛把巢狀結構整個丟掉。
這不是轉換器的限制。試算表是一個長方形而 JSON 是一棵樹，樹塞不進長方形。當資料真的是巢狀的，有用的做法通常是把你實際需要的那一部分抽出來成為一個扁平清單，而不是試圖轉換整個結構。
一個大型匯出檔往往不是一份 JSON 文件，而是一個每行一個完整 JSON 物件的檔案，叫做 JSONL 或 NDJSON。
理由很實際：一個巨大的單一 JSON 陣列必須整個讀進記憶體才能做任何事，而且不重寫整個檔案就沒辦法往後追加。一行一個物件可以一行一行處理，而且可以永遠追加下去。
如果一個檔案是 .jsonl 或 .ndjson，或者打開是很多行、每行都以 { 開頭，那就是這種東西——而把它丟給一般的 JSON 剖析器會失敗，因為整個檔案作為一個整體並不是合法的 JSON。
關於這一點，Markdown 成立的每一件事在這裡也成立。JSON 在任何文字編輯器裡都打得開、任何軟體消失它都活得下來、用一般工具就搜得到，而且兩個版本之間可以逐行比較。
唯一的實務步驟是在閱讀前把它排版美化。匯出的 JSON 常常是單一一條巨大的行。任何格式化工具或堪用的編輯器都會把它重新縮排成人看得懂的樣子，而不改動資料。
"_comment" 鍵