JSON、YAML、CSV、Markdown 資料格式比較速查表

JSON、YAML、CSV、Markdown 都是以文字為基礎、帶有結構的資料格式，但各自設計的目標與擅長的領域差異很大。設定檔用 CSV 會發現結構只能是扁平的，API 回應用 YAML 會失去嚴格的語法保證，表格資料用 JSON 交換則每列都要重複鍵名。Markdown 作為人類閱讀的文件格式非常優秀，但當成機器可讀的資料儲存格式時，之後會遇到解析上的麻煩。

這篇文章是一份「到底該用哪個格式」的速查表。從快速決策矩陣開始，接著功能對比表、註解支援、解析器生態系、用途別決策矩陣、常見錯誤選擇、LLM 情境下的選擇，以及規格參考資料，全部整理在一頁內。

快速決策矩陣 — 該選哪個格式

猶豫不決時，先看這張表。

簡短結論：機器之間的資料交換用 JSON，人手動編輯的設定用 YAML，二維表格資料用 CSV，人讀的文件用 Markdown。剩下的細部需求再根據下方的功能對比來調整。

先在瀏覽器中試轉 — 四種格式互轉

與其看說明，不如把同一份資料用四種格式寫出來，用眼睛直接比較差異。FormatArc 的轉換工具全部在瀏覽器本機執行，不需要上傳到外部伺服器，機密資料或 API 回應都可以直接貼上測試。

• JSON Formatter — JSON 格式化與語法驗證
• CSV to Markdown — 試算表表格轉為 Markdown 表格
• YAML to JSON / JSON to YAML — YAML 與 JSON 互轉
• CSV to JSON / JSON to CSV — 表格資料與結構化 JSON 互轉
• Markdown to HTML / HTML to Markdown — 文件格式互轉

如果你對把機密資料貼到線上轉換工具感到猶豫，可以先評估該工具是否真的會把資料傳到伺服器。FormatArc 的所有轉換都在瀏覽器中完成，資料不會離開你的分頁。

本文涵蓋的四種格式與未涵蓋的格式

本文聚焦於 JSON、YAML、CSV、Markdown 四種文字格式。這四者在現代 Web 開發、設定檔管理、資料交換與技術文件撰寫中出現頻率最高，也是 FormatArc 在瀏覽器中提供互轉工具的範圍。

以下格式不在本文範圍內：

• XML — 擁有強大的 schema 驗證機制，但語法冗長，新專案採用率持續下降。主要在 SOAP、RSS、SVG、Office Open XML 等既有系統的整合場景出現
• TOML — Rust 的 Cargo 或 Python 的 pyproject.toml 使用的設定格式。與 YAML、JSON5 用途重疊，在 Web 前端場景中出現頻率較低
• Parquet — 針對大型資料分析優化的列式（columnar）二進位格式。屬於二進位格式，不在本文文字格式比較的範圍內
• XLSX / ODS — 試算表的二進位格式。本文僅透過 CSV 匯出與匯入的路徑提及

同一份資料用四種格式寫出來

以兩筆使用者資料（姓名、年齡、技能清單）為例，分別用四種格式表達：

JSON 版本

{
  "users": [
    { "name": "Alice", "age": 30, "skills": ["Python", "Go"] },
    { "name": "Bob",   "age": 25, "skills": ["JavaScript"] }
  ]
}

YAML 版本

users:
  - name: Alice
    age: 30
    skills:
      - Python
      - Go
  - name: Bob
    age: 25
    skills:
      - JavaScript

CSV 版本

CSV 無法直接表達巢狀結構，因此 skills 陣列必須在某處被「拍平」。常見做法有三種：用分隔字元（如 ;）串接、展開成多欄、或拆成獨立的表格。最簡單的分隔字元方式：

name,age,skills
Alice,30,Python;Go
Bob,25,JavaScript

Markdown 版本

Markdown 是文件格式而非資料格式，結構化的表格依賴 GFM（GitHub Flavored Markdown）的表格語法：

| name  | age | skills      |
|-------|-----|-------------|
| Alice | 30  | Python, Go  |
| Bob   | 25  | JavaScript  |

同樣的資料填入四種格式後，各自特性一目了然。JSON 嚴謹、機器解析友善；YAML 人類閱讀友善；CSV 擅長二維表格但無法巢狀；Markdown 渲染後美觀但作為資料來源有侷限。

四種格式的功能對比矩陣

JSON 與 YAML 共享相同的資料模型（物件、陣列、原始型別），所以互轉非常直覺。FormatArc 提供 YAML to JSON 與 JSON to YAML 雙向轉換工具。

註解支援對比

選擇設定檔格式時，能不能寫註解是最關鍵的考量之一。標準規格與衍生方言在此處行為不同：

標準 JSON 不支援註解，所以在設定檔中想留說明時，可以考慮 YAML、JSONC、JSON5，或使用 _comment 這類虛擬鍵名作為變通。

各語言的解析器生態系

JSON 與 CSV 在几乎所有主流語言中都有標準函式庫。YAML 與 Markdown 則依賴第三方函式庫，但各語言都有事實上的穩定選擇。FormatArc 將 yaml、papaparse、marked、turndown、remark 等函式庫打包進瀏覽器，實現了完全離線的轉換環境。

用途別推薦格式矩陣

Markdown 表格手動編輯很麻煩，建議以 CSV 或 JSON 作為原始資料來源，再用工具轉成 Markdown 表格，維護成本會低很多。

常見的錯誤選擇

用 CSV 處理巢狀資料

像 { "user": { "address": { "city": "Taipei" } } } 這種層級結構，硬塞進 CSV 就要額外定義拍平規則，讀取時還要復原。需要巢狀結構的資料，一開始就選 JSON 或 YAML，或者拆成多張 CSV 用關聯模型處理。

YAML 的隱式型別轉換陷阱（挪威問題）

YAML 1.1 規格中，no、yes、on、off 等字串會被自動轉換為布林值。著名的「挪威問題」就是國家代碼 NO 被轉成了 false。YAML 1.2 修正了部分規則，但仍有很多解析器預設使用 1.1 相容模式。可能被誤判為布林值的字串，一律加引號包起來最安全。

country: "NO"   # 安全 — 明確的字串
country:  NO    # 危險 — YAML 1.1 相容解析器可能轉為 false

在標準 JSON 中寫註解

VS Code 的 settings.json 可以寫註解，所以很多人誤以為 JSON 也能寫。但這是 JSONC，一個非標準的方言。標準 JSON（RFC 8259）不允許註解，JSON.parse 遇到註解會拋出錯誤。需要註解時，改用 JSON5、JSONC 或 YAML，或在預處理階段移除。

低估 CSV 的方言差異

RFC 4180 是參考規格，但實務上的 CSV 文件五花八門。分隔字元（逗號、Tab、分號）、換行碼（LF vs CRLF）、引號處理、BOM、文字編碼（UTF-8 vs Big5）、是否包含標頭列、儲存格內換行的逸出方式 — 這些在每個寫入端與讀取端的行為都可能不同。「以為只是個簡單 CSV」造成的除錯時間，可能比 YAML 的問題還多。正式投入前，務必用樣本資料驗證兩端行為。

把 Markdown 當機器可讀的資料格式

Markdown 本質上是文件格式，不是為機器穩定解析而設計的資料格式。Markdown 表格在 GFM 以外的渲染器中可能完全無法顯示，儲存格中包含管道符號或換行時更容易出錯。如果目的是機器之間的資料傳遞，應該用 JSON 或 CSV。

以為 Markdown 表格是 CommonMark 標準

它不是。表格語法屬於 GFM、MultiMarkdown 或 Pandoc 的擴展。使用 CommonMark 嚴格模式的渲染器會把表格當成普通段落顯示。GitHub、hackmd、GitLab 等平台支援 GFM，但自架的 wiki 引擎或部落格系統可能不支援。

LLM 情境下的格式選擇

餵給 ChatGPT、Claude、Gemini 等 LLM 的上下文資料，Markdown 是首選。與 HTML 相比，Markdown 去除了大量不必要的標籤與屬性，token 消耗大幅降低，同時表格、清單、代碼區塊等結構能被 LLM 準確識別。

但 LLM 的結構化輸出（Function Calling、JSON Mode）必須用 JSON。因此實務上形成了「輸入用 Markdown、輸出用 JSON」的非對稱結構。

YAML 作為 LLM 輸入有風險：縮排對 tokenizer 不夠穩定，隱式型別轉換也可能把字串變成布林值。

規格與標準歷史

JSON 與 CSV 有穩定的 RFC 規格。YAML 與 Markdown 則有方言族系（YAML 1.1 vs 1.2；CommonMark vs GFM vs MultiMarkdown vs Pandoc），跨系統整合時需要確認對端的方言。

用 FormatArc 做格式轉換

串起來就是一整條工作流：「API 回應 JSON 轉 YAML 設定檔」「Excel 表格匯出 CSV 再轉 Markdown 表格貼進 README」「網頁 HTML 轉 Markdown 餵給 ChatGPT」— 全部在瀏覽器中完成，資料不離開你的電腦。

常見問題

設定檔該用 JSON、YAML 還是 TOML？

需要註解且可讀性重要時，YAML 最常用（Kubernetes、Docker、GitHub Actions 都用它）。不想處理縮排但又需要註解的話，TOML 或 JSON5 是好的替代。標準 JSON 不支援註解，不適合需要頻繁手動修改的設定檔。

REST API 能用 YAML 或 CSV 替代 JSON 嗎？

技術上可行但不建議。JSON 語法嚴格、型別明確、所有主流語言都有標準解析器，是 Web API 的事實標準。YAML 解析速度較慢且有隱式型別轉換問題，CSV 無法表達巢狀結構。

Excel 資料怎麼快速轉成 Markdown 表格或 JSON？

從 Excel 或 Google Sheets 把範圍複製成 CSV，再用 CSV to Markdown 工具即可得到對齊的 Markdown 表格。需要結構化資料餵給 API 時，用 CSV to JSON 轉換。

餵給 LLM 的資料用什麼格式最好？

文件或表格資料輸入時，Markdown 最有利 — 沒有多餘標籤、結構辨識度高。需要 LLM 回傳可程式化處理的結果時，指定 JSON 輸出。

用 FormatArc 轉換資料安全嗎？

所有轉換都在你的瀏覽器中用 JavaScript（含 WebAssembly 與本機函式庫）執行。輸入的文字或檔案不會傳送到任何外部伺服器，機密資料與個資都可以安全處理。

總結

猶豫時的終極檢查清單：

• 機器間資料交換：JSON
• 人手編輯的設定檔：YAML
• 二維表格資料：CSV
• 人讀的文件：Markdown
• LLM 輸入：Markdown / LLM 輸出：JSON

資料格式沒有絕對的對錯，只有「優化什麼」的選擇。可讀性、嚴謹度、解析器覆蓋範圍、註解支援、LLM token 效率 — 四種格式各有所長。把上面的矩陣當作決策參考，專案起步時快速定格式。

規格參考：

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format在新分頁中開啟
• YAML 1.2.2 Specification在新分頁中開啟
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files在新分頁中開啟
• CommonMark Specification在新分頁中開啟
• GitHub Flavored Markdown Spec在新分頁中開啟