JSON vs YAML vs XML：到底該用哪種資料格式？

每隔幾個月，團隊裡就有人挑起關於資料格式的爭論。「這裡為什麼用 JSON？YAML 明明更簡潔。」或者，「XML 有 schema，我們應該用那個。」

事實是，沒有一種格式在所有場景下都是最好的。每種格式的存在都是因為它能很好地解決特定的問題。讓我來分析一下各種格式什麼時候真正合適。

快速決策矩陣

| 特性 | JSON | YAML | XML | |------|------|------|-----| | 可讀性 | 良好 | 優秀 | 較差 | | 解析速度 | 快 | 中等 | 慢 | | 註解支援 | 無 | 有 | 有 | | Schema 驗證 | JSON Schema | 有限 | XSD（強大） | | 資料類型 | 基礎 | 豐富 | 基於字串 | | 空白敏感 | 否 | 是（小心！） | 否 | | 檔案大小 | 小 | 最小 | 大 | | 瀏覽器原生支援 | 是 | 否 | 部分 | | 最適合 | API、設定 | 設定、DevOps | 文件、企業級 |

JSON：Web 的通用語言

JSON 贏得了 Web。每個 API 都在用它，每個瀏覽器都原生解析它，每種語言都有內建支援。如果你在建構 REST API，選擇已經定了。

JSON 的優勢：

• API 請求和回應
• 套件清單（package.json、composer.json）
• 服務間資料交換
• 任何需要快速解析的地方

不足之處：不支援註解。你沒辦法在 JSON 設定檔裡說明某個值為什麼這樣設定。有人用 "_comment" 鍵來繞過，但那是個取巧的辦法。

YAML：人類友善的選擇

YAML 的設計初衷就是讓人先讀懂。沒有大括號，大多數字串不需要引號，隨處可以加註解。DevOps 團隊很喜歡它——Kubernetes、Docker Compose、GitHub Actions、Ansible——都選擇了 YAML。

但 YAML 有個陷阱：空白很重要。縮排錯一個，整個設定就廢了。錯誤訊息呢？通常沒什麼幫助。200 行設定裡出現 "Mapping values are not allowed here" 真的說明不了什麼。

而且 YAML 的類型轉換可能讓你吃驚。yes 變成 true。3.10 變成 3.1。挪威的國家代碼 NO 變成 false。這不是 bug——是在你最意想不到的時候咬你一口的特性。

XML：企業級的主力

XML 現在被罵得很多，有些確實該罵。它太囉唆了。JSON 裡一行的簡單鍵值對，XML 裡要三行。

但 XML 能做其他格式做不到的事。XSD schema 提供強大的驗證——可以強制執行資料類型、模式、必填欄位，甚至值範圍。XSLT 可以轉換文件。命名空間可以防止合併不同來源文件時的命名衝突。

如果你在醫療（HL7）、金融（FIXML）或出版（DocBook）領域，XML 不會消失。這些產業選擇 XML 就是因為它的嚴格，而這種嚴格正是他們需要的。

什麼時候用什麼

選擇 JSON：

• 建構 Web API
• 儲存簡單設定
• 前後端資料交換
• 需要快速解析和廣泛語言支援

選擇 YAML：

• 撰寫 CI/CD 管線
• Kubernetes 或 Docker 設定
• 需要註解的人工編輯設定檔
• 需要無跳脫字元的多行字串

選擇 XML：

• 與要求 XML 的企業系統協作
• 需要強大的 schema 驗證
• 混合內容文件（文字中嵌入資料）
• 需要命名空間來組合文件類型

格式間轉換

實際工作中，你經常需要在格式之間轉換。也許你在把舊的 XML 設定遷移到 YAML，或者需要把 YAML 轉成 JSON 給 API 用。

三種格式之間的結構對應相當乾淨。物件變成映射變成元素。陣列變成序列變成重複元素。棘手的部分是 XML 的屬性（JSON 和 YAML 中沒有直接對應）和註解（轉換為 JSON 時會遺失）。

你還可以在 XML 和 JSON 之間轉換，或者處理表格資料時在 CSV 和 JSON 之間轉換。

真正的答案

用你的生態系統期望的那個。寫 Kubernetes 設定就用 YAML。建構 Web API 就用 JSON。在企業醫療領域就用 XML。

不要與工具和團隊的慣例對著幹。最好的資料格式是專案裡每個人都已經理解的那個。

---

資料格式的爭論很有趣，但很少像我們想的那麼重要。選一個適合你用例的，保持一致，然後去解決真正的問題。你的使用者不在乎設定檔是用大括號還是縮排。