JSON 與 YAML：您應該使用哪種設定格式？
快速解答
將 JSON 用於 APIs、資料交換以及嚴格解析和驗證很重要的情況。將 YAML 用於設定檔、DevOps 清單以及人類可讀性和註解很重要的情況。 YAML 是 JSON 超集 — 每個有效的 JSON 文件都是有效的 YAML。
介紹
JSON 和 YAML 都是人類可讀的資料序列化格式。 JSON 在網路 APIs 中是嚴格的、最小的且普遍的。 YAML 是 JSON 的超集，它添加了註解、多行字串、錨點和基於縮排的結構，使其在設定檔（Docker Compose、Kubernetes、CI/CD 管道）中很受歡迎。
步步
-
比較文法和可讀性
JSON 使用大括號和引號：{"key": "value"}。 YAML 使用縮排和冒號：鍵：值。 YAML 的設定更加簡潔－字串不需要引號，專案之間不需要逗號，也不需要大括號。 JSON 對於資料交換來說更加明確且不易出錯。
-
比較功能
YAML 支援：註解 (#)、多行字串 (|、>)、錨點 (&) 和別名 (*)、一個檔案中的多個文件 (---) 以及複雜型別。 JSON 不支援這些－沒有註釋，沒有多行字串，沒有引用。 JSON 的簡單性是有意為之的：它是一種資料交換格式，而不是一種設定語言。
-
比較安全性和解析
JSON 解析快速且安全 — JSON.parse 內建於每個 JavaScript 引擎中。 YAML 解析速度更慢、更複雜 — YAML 規範有 80 多頁，而 JSON 只有 2 頁。 YAML 有安全風險（透過錨點進行數十億笑聲攻擊），而 JSON 則沒有。始終使用禁用錨點的安全 YAML 解析器。
-
比較生態系使用情況
JSON：REST APIs、package.json、tsconfig.json、NoSQL 資料庫、Web 應用程式。 YAML：Docker Compose、Kubernetes 清單、GitHub Actions、Ansible playbook、CI/CD 設定、OpenAPI 規格。 JSON 控制運行時資料； YAML 主導配置。
-
根據您的用例決定
APIs，資料交換，NoSQL，Web 應用程式狀態：JSON。設定檔、DevOps、CI/CD、基礎架構即程式碼：YAML。如果是人類手寫的話：YAML。如果機器產生並消耗它：JSON。
範例
JSON 和 YAML 中的配置相同
輸入: JSON: {"server": {"port": 8080, "host": "localhost"}}
YAML: server:\n port: 8080\n host: localhost
輸出: YAML 縮短了 30%，並且支援註解。 JSON 較嚴格且普遍可解析。
常見問題
- YAML 縮排錯誤：YAML 使用縮排進行結構，並且單一錯誤的空格會中斷解析 - 使用具有 YAML linting 的編輯器並始終使用空格，而不是製表符。
- YAML 十億笑攻擊：YAML 錨點和別名可以創建指數擴展，導致 DoS - 使用禁用錨點的安全 YAML 解析器（例如 Python 中的 yaml.safe_load）。
- JSON 沒有註釋：JSON 規範禁止註釋，使設定檔更難註釋－使用 YAML 進行人工編輯的配置，使用 JSON 處理機器產生的資料。
- YAML 隱式類型令人驚訝：YAML 會自動將 yes/no 轉換為布林值，將 1.0 自動轉換為浮點數，這可能會破壞字串欄位 - 明確引用字串以避免意外的類型強制。
提示
- 使用 YAML 進行手動編寫的設定（Docker Compose、Kubernetes、CI/CD），使用 JSON 進行機器產生的資料交換（APIs、NoSQL、應用程式狀態）。
- 請務必使用停用錨點和別名的安全 YAML 解析器 - 切勿在不受信任的輸入上使用通用 YAML 載入器。
- 將 YAML 轉換為 JSON 時，預期會遺失註解、多行字串和錨點 — JSON 是 YAML 的子集，而不是功能的相反方式。
- 一律使用 2 個空格縮排 YAML — 混合製表符和空格或使用不一致的縮排是最常見的 YAML 解析錯誤。