文章
在 CSV、XML、JSON 和 YAML 之間轉換：實用指南
CSV、JSON、XML 和 YAML 是開發者在資料管道、設定檔和 APIs 中最常遇到的四種格式。當資料模型相符時，互相轉換很直接；而當它們不相符時，資料損失往往出人意料。本指南說明每種格式能夠且不能夠表示什麼、轉換過程中資訊消失的原因，以及可能導致靜默損壞的編碼陷阱。本站的 data-converter 工具在瀏覽器中處理這四種格式中的三種（CSV、JSON 和 YAML）；本文中關於 XML 的部分則是背景知識，供你手動搬移資料或使用其他工具時參考。
四種格式與其資料模型
CSV 將資料組織為行列的平面網格。第一行通常為欄位命名；後續每行是一筆記錄。沒有巢狀結構、沒有類型資訊，除了儲存格中的純文字之外也沒有任何標準。每個值都是字串，除非使用該資料的應用程式強制套用某種類型。 JSON 將資料建模為物件（鍵值對映射）和陣列的樹狀結構。值可以是字串、數字、布林值、null、巢狀物件或任意深度的陣列。這讓單一 JSON 文件得以表示包含嵌入式地址物件、訂單項目陣列和類型化數字合計的客戶記錄。 XML 將資料建模為元素樹。每個元素可以攜帶具名屬性，並包含子元素或文字內容。沒有內建的數字或布林類型；一切都是文字。XSD 等結構描述可在驗證時強制執行類型，但傳輸格式始終是字元資料。 YAML 使用縮排來表達與 JSON 相同的物件和陣列模型，但語法更為簡潔易讀。YAML 是 JSON 的超集：任何有效的 JSON 文件也是有效的 YAML。它新增了多行字串、注釋以及用於重複區塊的錨點別名引用。YAML 常見於設定檔；JSON 常見於 API 回應。
有損轉換：扁平化與 XML 的歧義性
最常見的有損轉換是將巢狀 JSON 或 XML 扁平化為 CSV。一個帶有巢狀地址欄位的 JSON 物件無法乾淨地對應到 CSV 的一行。典型的解決方案是使用點標記法的欄位名稱：customer.address.city 成為獨立的欄位。這對一層巢狀有效，但一旦出現陣列就完全失效。一位有三個電話號碼的客戶，需要三個獨立的欄位（寫死最大數量）、拆分為第二個 CSV 檔案，或者將陣列編碼為單一儲存格中的分隔字串。如果沒有額外的元資料，這些選項都無法還原回原始 JSON。 XML 帶來了另一個歧義：屬性與子元素的選擇。"Paris" 這個值可以儲存為屬性（<city name="Paris">）或子元素（<city><name>Paris</name></city>）。當轉換器讀取 XML 並產生 JSON 時，必須決定如何對應屬性。常見的慣例包括在屬性鍵前加上 @ 前綴，或將它們放在 "_attributes" 鍵下。這個選擇並未標準化，這意味著兩個轉換器讀取相同的 XML 可能產生結構上不同的 JSON。如果您計畫在 XML 和 JSON 之間來回轉換資料，請在開始前確定一個慣例。
CSV 的陷阱：分隔符、引號與編碼
CSV 沒有單一的正式標準，只有 RFC 4180 作為廣泛引用的參考。最常見的分隔符是逗號，但在實踐中也會出現分號（在以逗號作為小數分隔符的歐洲地區常見）、定位字元（TSV）和管道符號。一個名為 .csv 的檔案可以使用其中任何一種，而不會標示所用的是哪種。 當欄位值本身包含分隔符時，RFC 4180 要求將欄位用雙引號括起來："San Francisco, CA"。在引號括起的欄位中，雙引號本身必須透過加倍來轉義："He said ""hello"""。包含換行符的欄位也必須加引號。略過此步驟的解析器會產生難以追蹤的行數錯誤。 編碼是另一個陷阱。Windows 工具產生的 CSV 檔案通常帶有 UTF-8 BOM（位元組順序標記：檔案開頭的三個位元組 EF BB BF）。BOM 幫助 Excel 識別編碼，但許多程式語言的解析器會將 BOM 視為第一個欄位名稱的一部分，產生名為 "id" 而非 "id" 的欄位。這會破壞任何按名稱查詢欄位的下游程式碼。以程式方式讀取 CSV 檔案時，請在解析前去除 BOM，或使用明確處理 BOM 的程式庫。
選擇格式：設定檔、資料交換與試算表
格式的選擇通常由情境決定，而非個人偏好。 JSON 是 REST APIs 和瀏覽器與伺服器之間資料交換的預設選擇。它緊湊、在每種程式語言中都能原生解析，並為數字和布林值攜帶類型資訊。它的弱點是缺少注釋功能，這使它不適合開發者手動讀取和編輯的檔案。 YAML 較受設定檔（Kubernetes 清單、CI 管道定義、Ansible playbooks）的青睞，因為它支援行內注釋，並且比具有多層縮排的 JSON 更易閱讀。其主要風險是縮排錯誤是靜默的：縮排錯誤的鍵會移至不同的作用域，而不會出現任何解析錯誤。 XML 在舊有企業系統、SOAP 網路服務、文件格式（DOCX、SVG、RSS）以及需要結構描述驗證或命名空間消歧的情境中仍是標準。它很冗長，但 XPath 和 XSLT 工具鏈已相當成熟。 CSV 是當資料確實是平面的，且使用者是試算表應用程式或資料分析師時的正確選擇。由於沒有類型系統和巢狀結構，它不適合設定檔或 API 資料交換。
使用 data-converter 在本地完成轉換
本網站的 data-converter 工具完全在瀏覽器內部解析並轉換 CSV、JSON 和 YAML；它不會讀取或寫入 XML。在任何時候，資料都不會傳送到伺服器。轉換在您的本地 JavaScript 執行環境中執行，輸出結果可供下載或複製，無需任何資料離開您的裝置。 這對於不屬於您可以分享的資料尤為重要：包含個人資訊的 API 回應、帶有內部主機名稱的設定檔，或來自內部資料庫的 CSV 匯出。將這些資料貼入在伺服器上執行的網頁轉換器，意味著內容透過網路傳送並在您無法控制的硬體上處理。使用 data-converter 時，瀏覽器分頁就是處理環境。 該工具在讀寫 CSV 時套用 RFC 4180 引號規則，並期望從 JSON 或 YAML 轉為 CSV 時輸入的是一個扁平的物件陣列：某個鍵底下若是巢狀物件或陣列值，並不會自動以點標記法扁平化，如果你需要把它們變成獨立欄位，請自行先扁平化這些欄位。如果你需要搬移資料到 XML 或從 XML 搬出，請先用專門的 XML 工具把它轉換成 JSON 或 YAML，再拿到這裡處理。
本文涉及的工具
常見問題
我可以將 JSON 轉換為 CSV 再還原回原始格式嗎？
只有當 JSON 是平面物件陣列、沒有巢狀欄位且沒有陣列值時才可以。一旦有巢狀物件或陣列值，CSV 的表示方式就需要做出結構上的決定（點標記法欄位、多行或編碼字串），而這種決定無法自動逆轉。如果您的資料有巢狀結構，JSON、XML 或 YAML 可以完整還原；CSV 則不行。
為什麼從歐洲應用程式匯出後，我的 CSV 在 Excel 中看起來不正確？
歐洲地區通常使用分號作為 CSV 分隔符，因為逗號用作小數符號。歐洲地區的 Excel 預期使用分號。如果檔案使用逗號，Excel 會將整行視為單一欄位。解決方法是在匯出設定中更改分隔符，或使用 Excel 的「資料匯入精靈」，讓您手動指定分隔符。UTF-8 BOM 問題是另一回事：若沒有 BOM，Excel 也可能將帶有重音符號的字元顯示為亂碼。
YAML 和 JSON 在實踐中有何不同？
兩者表示相同的底層資料模型：物件、陣列、字串、數字、布林值和 null。YAML 新增了注釋（以 # 開頭的行）、多行字串字面值以及用於重複區塊的錨點引用。JSON 嚴格來說是有效 YAML 的子集，但 JSON 解析器無法讀取 YAML。實用規則：API 有效載荷和資料儲存使用 JSON；對人類需要編輯且受益於行內注釋的設定檔使用 YAML。