開發者工具 · JSON 格式化程式和驗證程序
JSON 的標準歷史：RFC 4627 到 RFC 8259 和 ECMA-404
· 背景
json 標準 驗證
JSON 已被兩個標準機構指定至少四次。這篇文章追蹤了從 Douglas Crockford 的 json.org 到 RFC 8259 和 ECMA-404 的路徑，並解釋了開發人員在此過程中實際發生的變化。
我的解析器遵循哪個規範？
解析器遵循哪個規範？答案通常在邊緣可見，而不是在普通物件和陣列中。測試頂級字串，例如 `"ready"`、前導位元組順序標記、重複的成員名稱和異常大的數字。不同的檔案在不同層級討論語法和互通性，而實作則添加自己的資料類型和錯誤行為。只有當觀察到的解析器契約與每個 JSON 實現的假設分開時，命名標準才有用。
ToolAcre 的儲存庫證據比一般標準歷史更具體且更狹窄。格式化程式使用 `JSON.parse` 產生值並使用 `JSON.stringify` 發出它們；解析失敗後，本機掃描器會提供穩定的診斷位置和原因。
json.org 和 JSON 的早期描述
json.org 將 JSON 作為源自 JavaScript 物件文字語法的緊湊表示法，並用一個小語法記錄了其核心結構。早期的描述幫助開發人員為物件、陣列、字串、數字、布林值和空值提供了共享名稱和引用。將頁面描述為早期的公開解釋比在沒有引用歷史證據的情況下聲稱頁面或個人單槍匹馬地發現了一種格式或確立了其採用更為安全。
目前儲存庫來源不包括 json.org、瀏覽器使用或委員會討論的存檔歷史記錄。他們展示了該應用程式如何解析和診斷 JSON 今天。因此，本文中的歷史陳述與過時的標準檔案保持接近，並避免歸因那些本地檔案無法證明的動機或市場影響。
RFC 4627 in 2006 — 第一個 IETF 描述、應用程式 /json 媒體類型以及文字必須是物件或陣列的規則
RFC 4627，在 2006 中發布，描述了用於 Internet 交換的 JSON 並註冊了 `application/json` 媒體類型。它對 JSON 文字的定義需要頂層的物件或數組，即使字串、數字和文字作為值存在於這些容器內。此限制是一個有用的歷史差異，因為僅包含 `"ready"` 的檔案可能是後續公式中的有效值，但不符合 RFC 4627 的 JSON 文字定義。
該檔案也討論了當時可用的實作的編碼和安全性問題。不應將其視為此儲存庫的變更日誌：ToolAcre 不包含 RFC 4627 相容模式，且其解析器路徑將值建構委託給主機 JavaScript 引擎。
ECMA-404 in 2013 — Ecma 的最小純語法標準，以及為什麼兩個組織最終描述一種格式
ECMA-404 首次在 2013 中發布，以故意緊湊的形式指定 JSON 語法。它的重點是有效 JSON 文字的語法，而不是每個網路使用的完整交換設定檔。這個範圍有助於解釋為什麼 ECMA-404 和 IETF 檔案可以描述相同的基本符號，但它們強調的周圍互通性指南有所不同。兩個標準機構的存在並不意味著在日常使用中存在兩種不相容的格式。
關於組織為何選擇特定發布路徑的宣告需要超出此程式碼庫的文獻資料，因此本文不會從標準日期推斷委員會的動機。相關的實際問題是 RFC 8259 和 ECMA-404 旨在在語法上保持一致，而 RFC 8259 提供了對可互操作交換至關重要的建議。
RFC 7159 和 RFC 8259
RFC 7159 取代了 2014 中的 RFC 4627 並將 JSON 文字的定義擴展到任何序列化值，刪除了僅物件或陣列的頂級規則。 RFC 8259 取代了 2017 中的 RFC 7159，並保留通常為 JSON 引用的 IETF 參考。它需要在封閉生態系之外的系統之間交換 JSON 的 UTF-8 ，並記錄有關數字、重複名稱、Unicode 和字節順序標記的互通性警告，而不是假裝僅使用語法來保證各處的相同結果。
頂級 `true` 是一種觀察 ToolAcre 中現代根值規則的緊湊方法，因為 `JSON.parse` 接受它。此結果顯示了該實現的行為；當每個瀏覽器、伺服器或 API 都採用更廣泛的定義時，它不會重構。
對於工作開發人員來說發生了什麼變化
對於工作開發人員來說，最明顯的規範變化是現代接受任何 JSON 根值以及對可互操作編碼的更強有力的指導。不太明顯的教訓是，有效的語法仍然留下實現選擇。重複的物件名稱可能會被折疊，成員排序不是語義契約，非常大的數字可能會失去精確度，並不尋常的 Unicode 序列可能會以不同的方式在庫中傳輸。因此，符合標準的檔案應該受到應用程式模式的額外約束。
在此格式化程式中，重複的名稱和數字標記首先通過 `JSON.parse`，因此稍後的格式化會反映產生的 JavaScript 值而不是原始詞彙檔案。掃描器在故障後提供診斷；它不保留重複的成員或任意精確度的數字。這些是存儲庫支援的觀察結果。
這不包括什麼
這不包括 JSON 之上的規格。 JSON 模式描述了對檔案形狀和值的限制； JSON 指標定址檔案內的位置； JSON 補丁代表變更。它們解決了與基本語法不同的問題，不應被視為 JSON 本身的更高版本。 JSONC、JSON5 和類似的創作格式也擴展或改變了可接受的語法，並需要它們自己的解析器，而不是默默地折疊到嚴格的驗證中。
本文也避免了 JSON 採用、瀏覽器支援或與 XML 競爭的全面社會歷史，因為列出的儲存庫來源無法證實該敘述。尚未發明外部引文來填補這一空白。
重點：RFC 8259 是引用的參考文獻
RFC 8259 是引用目前 JSON 語法和互通性指南的實用 IETF 參考，ECMA-404 提供對齊的 Ecma 語法標準。 RFC 4627 和 RFC 7159 對於理解已發佈的定義如何變更（尤其是在頂層）仍然有用。引用支援確切宣告的文件，而不是使用「JSON 規範」作為對權威的模糊訴求，並將規範規則與特定解析器中觀察到的實現行為區分開來。
對於 ToolAcre，合理的說法是儲存庫使用 JavaScript 的 JSON 解析器和序列化器，並添加嚴格的本地掃描器以在失敗後進行診斷。對頂級值、格式錯誤的標點符號和數字處理的測試描述了該路線；它們不是歷史來源。