JSON（JavaScript Object Notation JavaScript 物件表示法）是由美國程式設計師道格拉斯克羅克福特構想和設計的一種輕量級資料交換格式。其內容由屬性和值所組成，因此也有易於閱讀和處理的優勢。JSON 是獨立於程式語言的資料格式，其不僅是 JavaScript 的子集，也採用了 C 語言家族的習慣用法，目前也有許多程式語言都能夠將其解析和字串化，其廣泛使用的程度也使其成為通用的資料格式。 簡介 JSON 格式是 1999 年《JavaScript Programming Language Standard ECMA262 3rd Edition》的子集合，所以可以在 JavaScript 以 eval 函式（javascript 透過 eval 呼叫解析器）讀入。不過這並不代表 JSON 無法使用於其他語言，事實上幾乎所有與網路開發相關的語言都有 JSON 函式庫。 JSON 的基本資料型別： 數值：十進位制數，不能有前導 0，可以為負數，可以有小數部分。還可以用 e 或者 E 表示指數部分。不能包含非數，如 NaN。不區分整數與浮點數。JavaScript 用雙精度浮點數表示所有數值（後來也支援 BigInt）。 字串：以雙引號 括起來的零個或多個 Unicode 碼位。支援反斜槓開始的跳脫字元序列。 布林值：表示為 true 或者 false。 陣列：有序的零個或者多個值。每個值可以為任意型別。陣列使用方括號 包裹。多個數組元素之間用逗號，分隔，形如：value value。 物件：若干無序的 鍵 值對keyvalue pairs，其中鍵只能是字串。建議但不強制要求物件中的鍵是獨一無二的。物件以花括號 包裹。多個鍵 值對之間使用逗號，分隔。鍵與值之間用冒號：分隔。 空值：值寫為 null token（6 種標點符號、字串、數值、3 種字面量）之間可以存在有限的空白符並被忽略。四個特定字元被認為是空白符：空格符、水平製表符、回車符、換行符。空白符不能出現在 token 內部（但空格符可以出現在字串內部）。JSON 標準不允許有位元組序掩碼，不提供註釋的句法。 一個有效的 JSON 文件的根節點必須是一個物件或一個數組。 JSON 交換時必須編碼為 UTF8。轉義序列可以為：、、、b、f、n、r、t，或 Unicode16 進位制跳脫字元序列（u 後面跟隨 4 位 16 進位制數字）。對於不在基本多文種平面上的碼位，必須用 UTF16 代理對（surrogate pair）表示，例如對於 Emoji 字元 喜極而泣的表情在 JSON 中應表示為： face or face uD83DuDE02 JSON 的格式描述可以參考 RFC 4627。 歷史 JSON 源於對即時伺服器到瀏覽器會話通訊協議的需求，無需使用 Flash 或 Java 小程式等瀏覽器外掛，這是 2000 年代初期使用的主要方法。 Crockford 首先指定並普及了 JSON 格式。這個縮寫詞起源於 State Software，這是一家由 Crockford 和其他人於 2001 年 3 月共同創立的公司。聯合創始人同意構建一個使用標準瀏覽器功能的系統，併為 Web 開發人員提供一個抽象層來建立有狀態的 Web 應用程式，該應用程式具有 透過保持兩個超文字傳輸協議 HTTP 連線開啟並在標準瀏覽器超時之前（如果沒有進一步交換資料）回收這些連線，實現與 Web 伺服器的持久雙工連線。 聯合創始人進行了討論，並投票決定將資料格式命名為 JSML（JavaScript 標記語言）還是 JSON（JavaScript 物件表示法），以及在何種許可型別下提供該格式。 JSONorg 網站於 2001 年推出。 JSON 庫的前身被用於 Cartoon Network 的 Communitiescom 上名為 Cartoon Orbit 的兒童數字資產交易遊戲專案（State 聯合創始人之前都曾在這家公司工作過），該專案 使用具有專有訊息格式的瀏覽器端外掛來操作 DHTML 元素（該系統也屬於 3DO）。 在發現早期的 Ajax 功能後，digiGroups、Noosh 等公司使用框架將資訊傳遞到使用者瀏覽器的視野中，而無需重新整理 Web 應用程式的視覺上下文，僅使用標準 HTTP、HTML 和 JavaScript 功能即可實現即時豐富的 Web 應用程式 Netscape 405 和 IE 5。 Crockford 隨後發現 JavaScript 可以用作此類系統的基於物件的訊息傳遞格式。 該系統被出售給 Sun Microsystems、Amazoncom 和 EDS。 應用領域 Metadata 和架構 JSON 文字的官方媒體型別是雙引號，這一點在大多數現代的安裝中都採用了這種型別。由於傳統原因，許多服務提供商、瀏覽器、伺服器、Web 應用程式、庫、框架和 API 也支援非官方的 MIME 型別 或內容型別。值得注意的例子包括谷歌搜尋 API，雅虎，臉書的 API，Lift，和 Dojo Toolkit。JSON 架構指定一種基於 JSON 的格式，用於定義用於驗證、文件和互動控制的 JSON 資料的結構。它為給定應用程式所需的 JSON 資料以及如何修改該資料提供協定。JSON 架構基於 XML 架構（XSD）中的概念，但基於 JSON。與在 XSD 中一樣，相同的序列化 反序列化工具可用於架構和資料，並且它是自描述的。它在 IETF 的網際網路草案中指定，目前為 202012 年草案，於 2021 年 1 月 28 日釋出。有幾個驗證器可用於不同的程式語言，每個驗證器都有不同程度的一致性。標準副檔名為 json。JSON 標準不支援物件引用，但存在基於 JSON 的物件引用的 IETF 草案標準。 WEB 開發 JSON 最開始被廣泛的應用於 WEB 應用的開發。不過目前 JSON 使用在 JavaScript、Java、Nodejs、C 應用的情況比較多，PHP 等開發的 WEB 應用主要還是使用 XML。 NoSQL 資料庫 相對於傳統的關係型資料庫，一些基於文件儲存的 NoSQL 非關係型資料庫選擇 JSON 作為其資料儲存格式，比較出名的產品有：MongoDB、CouchDB、等。 舉例 firstName John lastName Smith sex male age 25 address streetAddress 21 2nd Street city New York state NY postalCode 10021 phoneNumber type home number 212 5551234 type fax number 646 5554567 這種 JSON 格式也被不少遊戲（如 Minecraft）或應用軟體用來當作的部分資料儲存的格式： text This is the text color dark_red bold true strikethough true clickEvent action open_url value zhwikipediaorg hoverEvent action show_text value text something translate itemdirtname color blue bold false italic true 互操作性 RFC 8259 描述了 JSON 語法的某些方面，儘管這些方面符合規範，但可能會導致互操作性問題。 某些 JSON 實現僅接受表示物件或陣列的 JSON 文字。為了實現互操作性，交換 JSON 的應用程式應傳輸物件或陣列形式的訊息。 該規範允許 JSON 物件包含多個具有相同名稱的成員。處理具有重複名稱的物件的實現的行為是不可預測的。為了實現互操作性，應用程式在傳輸 JSON 物件時應避免重複名稱。 規範特別指出 JSON 物件中成員的順序並不重要。為了實現互操作性，應用程式應該避免為成員排序賦予含義，即使解析軟體使該排序可見。 雖然規範對 JSON 數字文字的大小或精度沒有限制，但廣泛使用的 JavaScript 實現將它們儲存為 IEEE754 binary64 數量。為了實現互操作性，應用程式應避免傳輸無法以這種方式表示的數字，例如 1E400 或 3141592653589793238462643383279。 雖然規範不限制 JSON 文字中 Unicode 字元的字元編碼，但絕大多數實現都採用 UTF8 編碼；為了實現互操作性，應用程式應始終且僅使用 UTF8 對 JSON 訊息進行編碼。 該規範並不禁止傳輸不能正確表示 Unicode 字元的位元組序列。為了實現互操作性，應用程式應傳輸不包含此類位元組序列的訊息。 該規範不限制應用程式如何比較 Unicode 字串。為了實現互操作性，應用程式應始終逐個程式碼單元執行此類比較。 2015 年，IETF 釋出了 RFC7493 ，描述了 IJSON 訊息格式，這是 JSON 的受限配置檔案，它限制了 JSON 的語法和處理，以儘可能避免這些互操作性問題 安全問題 讀取 JSON 由於 JSON 是 JavaScript 的子集，所以一般都會使用 eval 作為讀取資料的方式，如果是針對可靠的資料來源，在不支援原生 JSON 解析的瀏覽器上面這是最快速的方法。然而由於 eval 方法同樣可以執行任意的 JavaScript 程式碼，因此當資料來源不可靠時則可能產生安全問題。如下面的例子，直接用 eval 執行時會跳轉： var json eval messagefunction windowlocationhttpzhwikipediaorgwikiJSONE5AE89E585A8E680A7E5958FE9A18C 其中一種防止不安全程式碼出現的解決辦法，是透過瀏覽器原生支援的 JSONparse str 方法讀取 JSON 資料，目前已經得到大部分主流瀏覽器的支援（IE8，Firefox 35，Chrome4Safari4，Opera10），在不支援原生 JSON 物件的瀏覽器上面可以使用 parseJSON 方法進行讀取，parseJSON 採用解析器驗證讀入的程式碼是否真的是 JSON 程式碼，這樣就更安全。但由於這是用模 擬的方式讀取，速度上會比 eval 慢。 跨站存取問題 另外一個安全上的問題則是跨站請求偽造（Crosssite request forgery，簡稱 CSRF 或 XSRF）。這個問題在 JavaScript 中的狀況是，由於 JavaScript 採用了稱為「沙盒」的機制，這種機制限制 JavaScript 引擎僅能引入同一個站點的程式碼，因而某種程度上提高了安全性。 與其他格式的比較 XML JSON 與 XML 最大的不同在於 XML 是一個完整的標記語言，而 JSON 不是。這使得 XML 在程式判讀上需要比較多的功夫。主要的原因在於 XML 的設計理念與 JSON 不同。XML 利用標記語言的特性提供了絕佳的延展性（如 XPath），在資料儲存，擴充套件及高階檢索方面具備對 JSON 的優勢，而 JSON 則由於比 XML 更加小巧，以及瀏覽器的內建快速解析支援，使得其更適用於網路資料傳輸領域。 YAML 在功能和語法上，JSON 都是 YAML 語言的一個子集。特別是，YAML 12 規範指定 任何 JSON 格式的檔案都是 YAML 格式的有效檔案 。最常見的 YAML 解析器也能夠處理 JSON。版本 12 之前的 YAML 規範沒有完全涵蓋 JSON，主要是由於 YAML 中缺乏本機 UTF32 支援，以及對逗號分隔空格的要求；此外，JSON 規範還包括 樣式的註釋。YAML 最重要的區別是語法擴充套件集，它們在 JSON 中沒有類似物：關係資料支援：在 YAML 文件中，可以引用以前在檔案 流中找到的錨點；透過這種方式，您可以表達遞迴結構。支援除基元之外的可擴充套件資料型別，如字串、數字、布林值等。支援帶縮排的塊語法；它允許您在不使用不必要的符號的情況下描述結構化資料：各種括號、引號等。 MessagePack MessagePack 宣稱比 JSON 更短小，快速。 格式化工具 JSON 格式取代了 XML 給網路傳輸帶來了很大的便利，但是卻沒有了 XML 的一目瞭然，尤其是 JSON 資料很長的時候，會讓人陷入繁瑣複雜的資料節點查詢中。開發者可以 zhcn 透過；zhtw 使用； 線上 JSON 格式化工具，來更方便的對 JSON 資料進行節點查詢和解析。 參考文獻 Apple 捷徑 參閱 JSONP AJAX JavaScript YAML HOCON 外部連結 JSON，關於 JSON 的規格、檔案，以及在其他語言實做的資訊 JSON 中文說明 RFC 4627，JSON 在 RFC 裡的規格 Minecraft 指令JSON 文字格式 JSON 線上格式化、編輯、校驗工具 Category 標記語言 CategoryAJAX Category 資料序列化格式 categoryEcma 標準