格式化 JSON

JSON—JavaScript Object Notation—是用于結構化數據交換的無處不在的基於文本的格式。它由IETF作為RFC 8259和Ecma International作為ECMA-404共同標準化，它們共同定義了為現代API、日誌、配置和數據庫提供支持的緊湊、與語言無關的語法。

語法和編碼：保持系統通信的精確位

JSON值是對象、數組、字符串、數字或字面量true、false或null之一；對象將字符串映射到值，數組則包含有序的值——結構字符周圍允許有无关紧要的空白（RFC 8259,ECMA-404）。儘管JSON源於JavaScript，但它與語言無關，幾乎在任何地方都受支持（MDN: JSON）。在線路上，事實上的和推薦的編碼是 UTF-8（RFC 8259 §8.1）。為了額外的互操作性安全，I-JSON配置文件（RFC 7493）收緊了關於編碼和數值範圍的規則。

在JavaScript中，全局JSON對象公開了兩個主力：JSON.parse（帶有一個可選的reviver）和JSON.stringify（帶有用於美化打印的replacer/spacing），如MDN上所記錄（parse,stringify）。

數字：看似簡單，實則尖銳

JSON的數字語法是十進制的，但規範並未規定精度或整數/浮點數的區別。實現方式自行選擇如何表示它們（RFC 8259 §6）。在JavaScript和Node.js中，Number是IEEE-754雙精度，這意味著只有在[−(2^53−1), 2^53−1]範圍內的整數才是完全安全的——參見Number.MAX_SAFE_INTEGER和BigInt類型。這就是為什麼公共API通常將ID作為字符串傳輸並明確驗證“安全整數”的原因。

超越普通JSON：指針、補丁和合併補丁

隨著使用的成熟，出現了用於尋址和就地修改JSON的標準。JSON指針（RFC 6901）是一種微小的、斜杠分隔的語法，用於定位值（例如，/a/b/0），並為~和/提供了轉義規則。JSON補丁（RFC 6902）將部分更新建模為有序操作（add、remove、replace、move、copy、test），並以application/json-patch+json的形式傳輸。對於更簡單的差異，JSON合併補丁（RFC 7386）使用文檔形狀的合併：存在的字段被添加/替換；將字段設置為null會刪除它。許多框架都原生支持這兩種形式中的一種或兩種。

模式與類型：驗證與生成

JSON本身是無模式的，但生態系統依賴於模式進行驗證、文檔編制和代碼生成。JSON模式2020-12系列規定了諸如type、properties、items和組合關鍵字等约束，并与OpenAPI 3.1保持一致。對於以代碼生成為中心的工作流，JSON類型定義（RFC 8927）提供了一種故意降低表達能力的語言，可以可預測地映射到主流類型系統。

流式處理與大數據：JSON Lines和序列

傳統的JSON期望每個有效負載有一個完整的文本，這使得流式處理日誌和長壽命響應變得複雜。有兩種模式可以提供幫助：

• JSON文本序列（RFC 7464）：一個UTF-8 JSON文本流，每個文本前綴為記錄分隔符（U+001E），並以LF結尾；註冊為application/json-seq。
• NDJSON / JSON Lines：每一行都是一個獨立的JSON值——易於跟蹤、gzip壓縮和進行map-reduce（ndjson.org,jsonlines.org）。它在批量API中很受歡迎，例如Elasticsearch的批量API。

二進制近親：當文本不夠緊湊時

當帶寬或速度占主導地位時，“二進制JSON”格式在保留JSON數據模型的同時，用效率換取了人類可讀性：

• BSON（MongoDB的原生格式）添加了二進制、日期時間和類型化整數等類型（bsonspec.org）。
• MessagePack緊湊且無模式，在各種語言中廣泛實現（msgpack.org）。
• CBOR標準化了一種可擴展的緊湊格式（帶有JSON轉碼指南），在物聯網/受限環境中很常見（RFC 8949,cbor.io）。
• Smile（來自Jackson生態系統）使用可選的後向引用對重複的名稱/值進行JSON編碼（jackson-dataformat-smile）。

安全說明：舊技巧與現代修復

因為JSON只是文本，所以大多數風險來自於您如何傳輸和處理它：

• JSONP（通過帶有回調的<script>請求數據）是CORS之前的跨域請求變通方法，但很危險——它會執行任意腳本。請優先使用帶有真實application/json響應的CORS（OWASP: JSONP Abuse）。
• JSON劫持：返回敏感數組的簡單GET端點可能會在舊版瀏覽器中通過跨域腳本標籤被竊取；緩解措施包括使用CSRF保護的POST或使用非JSON哨兵作為前綴（OWASP: JSON Hijacking）。
• JSON注入：將JSON視為數據，而不是代碼；勤於轉義並驗證輸入（OWASP: JSON Injection）。

媒體類型與傳承

JSON在RFC 4627 (2006)下首次亮相；註冊的媒體類型是application/json，其規範現在指向RFC 8259。由於UTF-8是公共互聯網上的默認設置，因此JSON響應上的“charset”參數通常是不必要的。

在生產中實現健壯JSON的實用技巧

• 在任何地方都默認使用UTF-8；在輸入和輸出時都假定為UTF-8（RFC 8259 §8.1）。
• 對大整數要明確：如果ID可能超過2^53−1，請將其作為字符串傳輸並記錄下來（MDN: MAX_SAFE_INTEGER）。
• 使用JSON模式2020-12（或對於代碼生成密集的堆棧，使用JTD）驗證有效負載。在API文檔旁邊發布模式（OpenAPI 3.1）。
• 明智地打補丁：對於操作級別的差異，使用JSON補丁，對於簡單的文檔形狀更新，使用合併補丁。
• 大規模流式處理：為日誌和長壽命響應選擇JSON文本序列或NDJSON；明確媒體類型。
• 當文本成為瓶頸時，求助於二進制（BSON,MessagePack,CBOR,Smile）——但要確保兩端都同意類型。

關於“更友好的JSON”的一點說明

開發人員通常希望在配置文件中使用註釋、尾隨逗號或單引號字符串。這超出了標準JSON的範圍，但JSON5為人工編輯的文件提供了一個文檔齊全的超集。除非您控制兩端，否則避免通過公共API發送JSON5。

JSON的成功來自於其小巧的表面積、廣泛的語言支持以及一系列相鄰標準——指針、補丁、模式、序列——這些標準涵蓋了分佈式系統的混亂現實。理解基礎知識（語法、編碼、數字），依靠正確的相鄰標準，它將繼續在各種堆棧和服務中帶來紅利（RFC 8259,ECMA-404,RFC 6901,RFC 6902,RFC 7386,JSON Schema,JTD,RFC 7464,NDJSON）。