無論你是在設定網頁應用程式、在服務之間交換資料、分析試算表匯出,還是讀取 API 回應,你都會遇到以結構化文字格式儲存的資料。最常見的四種是 JSON、YAML、CSV 和 XML。
每種格式的設計初衷不同,選擇正確的格式取決於你的使用場景。本文解釋每種格式是什麼、長什麼樣、何時使用,以及它們之間的比較。
JSON——JavaScript 物件表示法
JSON 已成為網路上最主流的資料交換格式。儘管名稱如此,它是語言無關的,無處不在。
語法範例:
{
"name": "Alice Martin",
"age": 34,
"skills": ["Python", "SQL", "Docker"],
"address": {
"city": "Lyon",
"country": "France"
}
}
主要特點:
- 鍵值對,語法清晰易讀
- 支援字串、數字、布林值、陣列、物件和 null
- 標準 JSON 中不允許註解
- 嚴格語法——尾隨逗號和單引號都是錯誤
常見使用場景: REST API、設定檔(package.json、tsconfig.json)、NoSQL 資料庫(MongoDB)、前後端之間的資料交換。
小知識。 JSON 的嚴格語法既是優點也是缺點。它使解析可靠且無歧義,但也意味著一個遺漏的逗號或多餘的尾隨逗號會破壞整個檔案。
YAML——YAML Ain't Markup Language
YAML 的設計目標是成為最易於人類閱讀的資料序列化格式。它使用縮排代替括號,在設定檔中特別受歡迎。
語法範例:
name: Alice Martin
age: 34
skills:
- Python
- SQL
- Docker
address:
city: Lyon
country: France
主要特點:
- 基於縮排的結構(無括號或大括號)
- 支援
#註解 - 支援所有 JSON 資料型別以及更多(日期、多行字串)
- 對空白敏感——不正確的縮排會破壞檔案
常見使用場景: Docker Compose 檔案、Kubernetes 清單、CI/CD 管線(GitHub Actions、GitLab CI)、Ansible playbook、Hugo/Jekyll 設定。
YAML 是 JSON 的超集,意味著任何有效的 JSON 文件也是有效的 YAML。然而,YAML 的彈性可能是雙面刃——其隱含的型別轉換(例如 yes 被解釋為布林值 true,或 3.10 變成 3.1)已造成許多微妙的 Bug。
CSV——逗號分隔值
CSV 是最簡單的結構化資料格式。它將表格資料儲存為純文字,每行是一列記錄,值以逗號(或有時以分號、Tab 或其他分隔符號)分隔。
語法範例:
name,age,city,country
Alice Martin,34,Lyon,France
Bob Dupont,28,Paris,France
Carol Smith,41,London,UK
主要特點:
- 極其簡單——只是帶分隔符號的文字
- 沒有資料型別——一切都是字串
- 沒有表示巢狀資料的標準方式
- 沒有官方的通用標準(RFC 4180 存在但並未被普遍遵循)
- 檔案大小非常小
常見使用場景: 試算表匯出、資料庫匯入/匯出、資料分析(pandas、R)、簡單的資料交換、日誌檔案。
CSV 的簡單性既是其最大的優勢也是最大的限制。它非常適合扁平的表格資料,但無法表示層次結構。邊界情況(值中的逗號、多行欄位、編碼問題)使解析比表面看起來更複雜。
XML——可延伸標記語言
XML 是 JSON 接手之前最主流的資料交換格式。它使用類似 HTML 的標籤式語法,支援結構描述、命名空間和轉換等複雜功能。
語法範例:
<?xml version="1.0" encoding="UTF-8"?>
<person>
<name>Alice Martin</name>
<age>34</age>
<skills>
<skill>Python</skill>
<skill>SQL</skill>
<skill>Docker</skill>
</skills>
<address>
<city>Lyon</city>
<country>France</country>
</address>
</person>
主要特點:
- 基於標籤的結構,有開啟和關閉標籤
- 支援屬性、命名空間、結構描述(XSD)和轉換(XSLT)
- 支援註解
- 與其他格式相比非常冗長
- 極其完善的標準,具有嚴格的驗證
常見使用場景: SOAP 網路服務、企業整合、文件格式(DOCX、SVG、RSS)、Java/.NET 生態系統中的設定檔、政府和金融資料交換。
XML 比 JSON 或 YAML 更冗長,但其結構描述驗證能力使其在資料完整性和系統間正式合約至關重要的場景中不可或缺。
並排比較
| 功能 | JSON | YAML | CSV | XML |
|---|---|---|---|---|
| 人類可讀性 | 好 | 優秀 | 好(表格) | 尚可 |
| 冗長度 | 低 | 低 | 極低 | 高 |
| 註解 | 否 | 是 | 否 | 是 |
| 巢狀資料 | 是 | 是 | 否 | 是 |
| 資料型別 | 基本 | 豐富 | 無(全為字串) | 透過結構描述 |
| 結構描述驗證 | JSON Schema | 無標準 | 否 | XSD |
| 檔案大小 | 小 | 小 | 最小 | 大 |
| 解析速度 | 快 | 中等 | 快 | 中等 |
| 主要領域 | Web API | DevOps 設定 | 資料/試算表 | 企業 |
何時使用哪一種
- 選擇 JSON 當你建構 Web API、為 JavaScript/TypeScript 專案儲存設定,或在服務之間交換資料時。它是大多數現代應用程式的預設選擇。
- 選擇 YAML 當你撰寫人類需要頻繁閱讀和編輯的設定檔時。其可讀性和註解支援使其非常適合 DevOps 和基礎設施即程式碼。
- 選擇 CSV 當你處理表格資料、從試算表或資料庫匯入/匯出,或檔案大小必須最小時。避免用於任何層次結構的資料。
- 選擇 XML 當你處理企業系統、SOAP API,或需要正式結構描述驗證的場景。當你需要文件導向的標記(如 SVG 或 RSS)時,它也是正確的選擇。
格式間的轉換
在這些格式之間轉換是常見的任務。需要注意幾點:
- JSON 到 YAML(反之亦然)通常是無損的,因為 YAML 是 JSON 的超集。
- CSV 到 JSON/YAML 對扁平資料效果很好,但對巢狀輸出需要決定結構。
- XML 到 JSON 可能會遺失資訊(屬性、命名空間、順序),因為 JSON 沒有等效的概念。
- 任何格式到 CSV 只有在資料是扁平的或可以有意義地扁平化時才有效。
提示。 在格式之間轉換時,務必驗證輸出。自動轉換可能會悄悄遺失資料,特別是 XML 屬性、YAML 型別轉換或 CSV 編碼邊界情況。
進階了解
ToolK.io 提供免費工具來轉換 JSON、YAML、CSV 和 XML、格式化和驗證你的資料,以及探索相關教學來處理專案中的結構化資料。
