JSON 转 TOML：转换差异、边界与常见坑
在线 JSON 转 TOML：把对象数组写成 [[section]] 段落，值允许时输出原生日期时间；转换前先确认 TOML 无法表达的 null 该丢弃还是改写，避免配置语义变化。
TOML 的定位是配置文件而非数据交换，因此它有自己的规则：顶层必须是表、对象数组要写成重复段、原生支持日期类型。JSON 走一遍 TOML 再回来，通常会发现日期与注释的语义已经变了。
两种格式的差异对照
| 维度 | JSON | TOML |
|---|---|---|
| 定位 | 数据交换格式 | 配置文件格式（由配置文件需求驱动设计） |
| 注释 | 不支持 | 支持 # 注释 |
| 日期类型 | 无原生类型，靠字符串约定 | 原生支持 RFC 3339 日期时间 |
| 嵌套表达 | 括号直接嵌套 | 点分表头与 [table] 段，深层嵌套啰嗦 |
| 数组 | 原生数组，可嵌套任意类型 | 同质数组表达好，对象数组需 [[key]] 重复段 |
| 顶层结构 | 可以是数组或标量 | 必须是表（键值集合） |
| 可读性 | 结构显式，适合程序 | 扁平配置极友好，深层数据可读性差 |
| 标准版本 | RFC 8259 / ECMA-404 | TOML v1.0.0（1.0 起稳定） |
边界条件
- JSON 顶层是数组时无法直接转 TOML（TOML 顶层必须是表），需要包一层键名，或改用其它格式。
- 键名含点号会被解析成嵌套表，如果本意是"键就叫 a.b"则必须加引号包裹整个键。
- 空对象 {} 在 TOML 里没有直接对应的写法，通常被转成空表段或直接丢弃，需要确认消费端行为。
- 同质数组（全是字符串或数字）可用内联数组表达，混合类型数组在 TOML 里不被允许。
常见坑
- 把 JSON 顶层数组直接丢进来转换，因 TOML 要求顶层为表而失败，误以为工具不支持数组。
- 含点号的键被拆成嵌套表，配置读取路径全部对不上。
- 日期字符串被转成原生日期，再转回 JSON 时格式可能规范化（时区/精度变化）。
- 深层嵌套的数据硬转 TOML，产出大量 [a.b.c.d] 段，可读性比 JSON 更差。
相关工具
- JSON 转 TOML把 JSON 转为强类型 TOML 配置，保留嵌套表、数组与日期类型，适合把接口配置改写为 pyproject.toml 与 Cargo.toml，类型语义不丢失。数组表与嵌套表会按规范重排，日期类型保留为原生日期。布尔与数字不会被转成字符串，避免类型语义丢失。数组元素类型会按样本推断。
- TOML 转 JSON把 TOML 文档解析为 JSON，完整还原表、数组、内联表与多行字符串，适合把 Cargo.toml 与 pyproject.toml 喂给需 JSON 输入的脚本。日期与时间会按要求输出为字符串，内联表与多行字符串一并还原。数组表会转成对象数组，便于脚本直接读取。表与内联表都会展开。
- 数据格式转换器在 JSON、YAML、TOML、XML、CSV 之间一处粘贴自由互转并实时预览。在 JSON、YAML、TOML、XML 与 CSV 之间任意互转，粘贴一次即可看多种输出。转换时会提示解析失败的位置，避免带着语法错误继续处理。适合在不同工具链之间迁移配置文件。支持粘贴即转。多种格式的输出可逐一取用。
常见问题
怎么把 TOML 再转回 JSON？
使用同工具的交换方向功能，或本站对应的「TOML 转 JSON」页面，两者都本地运行、数据不上传，可完成往返转换与校验。
JSON 和 TOML 哪个更适合人类阅读？
这取决于场景：TOML 通常更偏向程序解析与接口传输式的可读形态，而 JSON 更利于程序解析与接口传输式的程序消费；需要人工编辑时优先选可读性更高的那一侧。
嵌套的对象数组转成 TOML 后变成很多 [[xxx]] 段，正常吗？
正常。TOML 把"对象数组"表达为由 [[段名]] 标记的重复段，与 JSON 的嵌套写法等价但不直观。段会按数组顺序依次出现，解析回去仍得到同一个数组。若嵌套过深导致可读性崩溃，说明这个数据更适合留在 JSON。
日期会被当成字符串吗？
反了：TOML 有原生日期类型（1979-05-27T07:32:00Z），而 JSON 没有。所以 JSON → TOML 时，符合 RFC 3339 的字符串会被推断成原生日期，再转回 JSON 时又输出为字符串——往返之后类型语义变了，但文本值一致。