写代码的时候，格式转换是个绕不开的问题。配置文件、数据导出、接口调试，这些场景里经常要在不同格式之间来回折腾。

以前我的解决方案是：写一个临时脚本，处理完了扔掉。后来发现这个需求出现得太频繁了，每次都从头写效率太低。

开发者最常遇到的格式转换场景

JSON ↔ YAML：这是最高频的需求。Kubernetes 配置文件是 YAML，但很多接口返回 JSON；Ansible playbook 是 YAML，但调试数据通常是 JSON。两者之间的互转每周都要遇到。

JSON ↔ CSV：从 API 拿到的 JSON 数组，需要导入 Excel 或给非技术同事看，要转成 CSV。反过来，Excel 导出的 CSV 要处理成 JSON 接口数据也是常见需求。

XML ↔ JSON：老系统、Java 后端、SOAP 接口经常输出 XML，前端或 Python 处理的时候需要 JSON。

TOML 格式：Rust 项目（Cargo.toml）、Hugo 静态站（config.toml）用得多，但生态工具里有时候要求 YAML，需要互转。

文件编码转换：接手老项目时经常遇到 GBK 编码的文件，现代工具期望 UTF-8，或者反过来。

ConvertET 的数据格式转换功能

ConvertET 的数据格式转换模块支持：

  • JSON → YAML / YAML → JSON
  • JSON → CSV / CSV → JSON（支持设置分隔符：逗号、分号、Tab）
  • XML ↔ JSON
  • TOML 格式转换
  • 文件编码转换（UTF-8、GBK、GB2312、Latin-1、UTF-16 等）

操作是图形界面的，不需要记命令行参数。对于不常写脚本的产品经理、测试人员来说也很友好。

JSON 转 YAML 会有什么问题吗

大部分情况下转换是精准的，数据结构完整保留。但有几个细节值得注意：

数字类型：JSON 里的 1.0 和 1 都是合法的数字，但 YAML 对这两者的处理可能不同。如果你的数据里有浮点数，转换后最好检查一下。

特殊字符：YAML 里冒号（:）、井号（#）有特殊含义，如果 JSON 的 key 里包含这些字符，转换出来的 YAML 会自动加引号，这是正常的。

多行字符串：JSON 里用 \n 转义换行，YAML 转换后可能会展开成真正的多行，这在 YAML 里是更规范的表达方式。

CSV 和 JSON 互转的注意事项

JSON 转 CSV 有个天然的限制：CSV 是二维表格结构，而 JSON 可以嵌套多层。

ConvertET 的 JSON 转 CSV 处理的是 JSON 数组（数组里每个元素是对象），把顶层字段作为 CSV 的列。如果 JSON 里有嵌套对象，嵌套部分会被序列化成字符串放在一个格子里。

所以这个功能最适合的场景是：API 返回的数组型 JSON 数据，需要导出给非技术人员查看或导入 Excel。

编码转换的实用场景

这个功能对接手旧项目或处理第三方数据的开发者来说会很有用：

  • 数据库导出的 CSV 是 GBK，Python 脚本处理时需要 UTF-8
  • 爬取的网页内容是 Latin-1，需要转成 UTF-8 存储
  • 发给日本团队的文件需要转成 Shift-JIS

ConvertET 支持主流编码的双向转换，操作时会先自动检测原始文件的编码，再按你的选择输出。

常见问题

Q：数据格式转换需要联网吗？

不需要。JSON/YAML/CSV/XML/TOML 转换以及文件编码转换完全离线运行，不依赖任何外部服务。对于包含配置文件、API 密钥的敏感数据，本地处理是最安全的方式。

Q：JSON 转 CSV 对数据结构有什么要求？

JSON 数据需要是顶层数组结构，数组里每个元素是对象，顶层字段作为 CSV 的列。不满足这个结构的 JSON（比如嵌套很深的对象）转 CSV 效果会打折扣。

Q：编码转换支持哪些编码？

支持 UTF-8（带/不带 BOM）、GBK、GB2312、GB18030、Latin-1、UTF-16、Shift-JIS、Big5 等主流编码。

Q：这些数据格式功能免费版能用吗？

是的，数据格式转换（JSON/YAML/CSV/XML/TOML/编码）全部属于基础功能，免费版可用，每次处理 1 个文件。需要批量处理，专业版从 ¥28/月起。

这几类格式转换功能在 ConvertET 里都是免费的基础功能，下载地址：https://www.zpyztech.com/product/convertet/

如果你是开发者，顺便看一眼它的视频/音频转换功能也不错，同一个工具能处理更多场景。