数据转换器

在 CSV、JSON、YAML 和 XML 之间搬运数据

数据很少安安静静地待在一种格式里。一份报表以电子表格的形式落到你手上，某个 API 想要 JSON，部署流水线期望 YAML，而在地下室某处，一个老旧的服务仍然只会说 XML。处理数据时日常的大部分摩擦并不来自数据本身，而是把它从你手头的形态变成别的东西所要求的形态。这就是数据转换器的全部工作：接收一种记法的结构化文本，再用另一种记法重新输出，过程中不丢失原意。

Speedor 的转换器完全在你的浏览器里运行。你粘贴、你点击、你复制结果。没有任何上传，没有任何记录，没有任何东西离开你的机器。对于任何曾在把客户导出数据丢进一个随便找来的网站之前犹豫过的人，这种"仅本地"的设计正是关键所在。

每种格式究竟擅长什么

在你开始来回倒腾之前，先弄清这些格式为何存在会很有帮助，因为每一种都是为不同的任务而生的。

CSV 是电子表格钟爱的那种扁平、以逗号分隔的网格。它天生是表格式的：行与列，没有嵌套。用 Excel、Google Sheets 或 Numbers 打开它，它就能直接工作。问题在于 CSV 没有类型的概念。值 007 可能是字符串、数字，也可能是邮政编码，而 CSV 不会告诉你它到底是哪个。

JSON 是现代 Web 的通用语。你将来要调用的几乎每一个 API 都说它。JSON 能处理嵌套、数组，以及少数几种真正的类型（字符串、数字、布尔值、null），这让它比一张扁平的表格表达力强得多。它紧凑、对机器友好，且到处都受支持。

YAML 是 JSON 那位更易读的表亲。它用缩进代替括号，支持注释，往往是配置文件、Docker Compose、Kubernetes 清单和 CI 流水线的首选格式。当需要由人手工编辑某样东西时，YAML 通常对眼睛更友好。

XML 是元老级人物。冗长、标签繁多，至今仍深植于企业系统、SOAP 服务、金融报文，以及像 RSS 这样的文档标准之中。在全新项目里你遇到它的机会少了，但一旦真要用到它，那就是非它不可。

转换究竟在哪些场景发生

一旦你开始留意，这些场景就相当具体了。比如说市场部递给你一张 4,000 个联系人的电子表格，而注册 API 只接受 JSON 数组。你把表格导出为 CSV，用 CSV 转 JSON 跑一遍，就得到一个可以直接 POST 的载荷。不用写胶水脚本，不用 pandas，也不用等工程师。

又或者你从同一个 API 拉回一段 JSON，想把它放进一个你的服务在启动时读取的配置文件里。用 JSON 转 YAML 转一下，你就得到一份干净、可加注释、能直接放进代码仓库的东西。反方向也一样管用——当某个工具只接受 JSON，而你的配置却写成了 YAML 时。

然后是那个谁都不爱碰的对接活儿：一个只能摄入 XML 的合作方系统。你用 JSON 构建载荷，因为你的应用就是这么思考的，然后在边界处转成 XML。形态保持不变，变的只是语法。

值得了解的那些坑

格式转换并不总是无损的，假装它无损只会引来 bug。有几件事要记在心里：

CSV 会遗忘类型。 因为每个单元格都只是文本，所以数字、布尔值和日期出来时全是字符串，除非转换器替你猜测。如果 true 需要成为布尔值而不是"true"这个词，发布前请检查输出。

YAML 在意空白。 在 YAML 里缩进不是装饰，而是结构性的。一个多余的空格就能改变某个值归属于哪个键，而制表符则被彻底禁止。任何一次 JSON 转 YAML 的往返之后，都值得快速扫一眼，或者把结果再丢回一个 JSON 格式化工具 里，确认结构没有走样。

XML 与 JSON 无法干净地相互映射。 JSON 有数组；XML 有重复元素。JSON 处处没有属性；XML 处处都是属性。多数转换器会选定一套合理的约定，但如果你的 XML 大量使用属性，它生成的 JSON 看起来就会和手写的 JSON 略有不同。这是预期之中的，并非缺陷。

嵌套深度有讲究。 CSV 是扁平的，所以深度嵌套的 JSON 并不总能在不展平键名（想想 address.city）的情况下塌缩成列。反过来走，一张扁平的 CSV 会变成一个扁平的数组，永远不会是一棵树。

为什么"仅本地"在这里很重要

你想转换的很多数据并不归你随意分享。用户记录、内部配置、藏在响应里的 API 密钥、财务数据行。许多在线转换器悄悄地把你粘贴的内容发到服务器去处理。Speedor 不会。转换逻辑就在你的浏览器标签页里运行，数据从不跨越网络，关掉标签页就是全部的清理工作。它也更快，因为没有上传往返，而且页面一旦加载完，离线也能用。免费、无需注册、没有配额。

常见问题