在格式之间转换数据而不崩溃

你一定经历过。数据库导出给你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管道都用它。但它对空白敏感，一个缩进错了，你的部署就会在凌晨2点崩掉。

第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元素、命名空间要求、模式验证。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步是你的代码。把"格式转换"和"数据变换"分开，事情就好管理了。

---

数据迁移从来不像计划文档里写的那么简单。但在每一步都有可靠的转换工具，意味着你可以把时间花在真正的问题上——业务逻辑、边缘情况和数据质量——而不是和格式语法较劲。