在不同格式之間轉換資料而不失去理智

你一定遇過這種情況。資料庫匯出給你 CSV。新的 API 要 JSON。部署設定需要 YAML。老舊系統只會說 XML。然後不知怎的，讓它們全部互通的人就是你。

資料格式轉換聽起來很簡單，直到你真的去做。以下是如何建構一個不會崩潰的真正管道。

場景：一次真實的遷移

假設你正在將使用者資料從舊系統遷移到新系統。你手上有這些東西：

• 來源：舊資料庫的 CSV 匯出（10,000 行，15 欄）
• API 層：新系統透過 REST API 接受 JSON
• 設定檔：YAML 格式的部署設定
• 舊系統整合：合作夥伴的系統仍然需要 XML 資料

四種格式。一份資料集。開始吧。

步驟 1：CSV 轉 JSON — 從匯出到 API 可用

你的 CSV 看起來像這樣：

id,name,email,plan,created
1,Alice,alice@example.com,pro,2024-03-15
2,Bob,bob@example.com,free,2024-06-22

轉換為 JSON 後，你會得到結構化、巢狀的資料，讓你的 API 可以直接使用：

[
  {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com",
    "plan": "pro",
    "created": "2024-03-15"
  }
]

注意事項：含有逗號的引號欄位、應該是 null 而非空字串的空值，以及各行之間不一致的日期格式。這些 bug 會在你以為一切正常的第 4,738 行突然冒出來。

步驟 2：JSON 轉 YAML — 用於設定檔

你的部署需要 YAML 設定。資料結構不變——只是需要不同的語法：

users:
  - id: 1
    name: Alice
    email: alice@example.com
    plan: pro
    created: "2024-03-15"

YAML 對設定檔來說可讀性更好，這就是為什麼 Kubernetes、Docker Compose 和 CI/CD 管道都使用它。但它對空白很敏感，少一個縮排，你的部署就會在凌晨兩點崩潰。

步驟 3：JSON 轉 XML — 用於舊系統

2015 年的合作夥伴系統需要 XML。不，他們不會升級 API。是的，你還是得支援它。

<users>
  <user>
    <id>1</id>
    <name>Alice</name>
    <email>alice@example.com</email>
    <plan>pro</plan>
    <created>2024-03-15</created>
  </user>
</users>

轉換本身很直接，但 XML 有些特性要注意——屬性 vs 元素、命名空間需求、Schema 驗證。XML 轉換器處理結構轉換，商業邏輯則由你來處理。

步驟 4：用 JSON 格式化器驗證所有內容

在每個階段，都要格式化和驗證你的 JSON。一個放錯位置的括號、一個多餘的逗號、一個未轉義的引號——你的匯入就會靜默丟棄記錄或直接崩潰。

在將任何轉換後的資料發送到 API 之前，先格式化它並目視檢查結構。五秒鐘的格式化可以省下五小時的「為什麼少了 200 筆記錄」除錯時間。

資料遷移的常見陷阱

編碼問題：Windows 上 Excel 匯出的 CSV 可能是 Windows-1252 而非 UTF-8。你的日本客戶名字會變成問號。永遠先檢查編碼。

型別轉換：CSV 把所有東西都當字串。CSV 中的數字 001 在 JSON 中會變成 1。郵遞區號、電話號碼和有前導零的 ID 欄位是常見的受害者。

巢狀資料：CSV 是平面的，JSON 是巢狀的。你需要決定 CSV 中的 address_street、address_city、address_zip 如何對應到 JSON 中的 address 物件。

Null vs 空值：空的 CSV 儲存格是 null、""，還是應該完全省略這個鍵？在開始之前就定義好，而不是發現 bug 的時候。

管道模式

對於任何資料遷移，工作流程如下：

1. 匯出來源系統的資料（通常是 CSV 或 SQL 傾印）
2. 轉換為你的工作格式（CSV 轉 JSON）
3. 變換結構（重新命名欄位、巢狀化物件、修正型別）
4. 驗證輸出（格式化並檢查）
5. 轉換為目標格式（YAML 或 XML）
6. 匯入到目標系統

工具處理步驟 2、4 和 5。步驟 1、3 和 6 是你的程式碼。將「轉換」與「變換」分離，讓事情保持可控。

---

資料遷移從來不像規劃文件中看起來那麼簡單。但在每個步驟都有可靠的轉換工具，意味著你可以把時間花在真正的問題上——商業邏輯、邊緣案例和資料品質——而不是跟格式語法搏鬥。