JSON 转 XML：转换差异、边界与常见坑
在线 JSON 转 XML：可指定根元素名称，数组转为重复元素，需要时按 @ 约定映射为属性；适合把 JSON 数据接入依赖 XML 的遗留系统与文档交换场景；重复元素的折叠规则可自由选择。
JSON 转 XML 的难点不是语法而是命名：XML 没有数组类型，只能靠同名元素重复表达，元素名必须由人指定，工具只能用 item 占位；属性更是 JSON 里不存在的概念，通常靠 @ 前缀约定桥接。
两种格式的差异对照
| 维度 | JSON | XML |
|---|---|---|
| 根元素 | 无要求，顶层可以是任意类型 | 必须恰好一个根元素 |
| 数组 | 原生数组类型 | 无数组，靠同名元素重复表达 |
| 属性 | 无此概念 | 元素可带属性与命名空间 |
| 命名空间 | 不支持 | 支持 xmlns，适合多标准混合文档 |
| 注释与处理指令 | 不支持 | 支持注释、CDATA、处理指令、DTD |
| 类型 | number/boolean/null 显式 | 全部是文本，类型靠 Schema 或约定 |
| 体积 | 精简 | 标签重复导致体积显著增大 |
| 典型场景 | API、配置文件、日志 | 文档交换、企业系统集成、SOAP |
边界条件
- JSON 里为 null 的字段转成 XML 时可能输出空元素、自闭合元素或直接省略，三种形态语义不同，需要与消费端约定。
- 键名含空格或以数字开头时不是合法 XML 标签名，必须清洗或改用属性表达。
- 数字与布尔值在 XML 里都是文本，往返后类型信息丢失，需要 Schema 或消费端约定来恢复。
- 空数组转成 XML 后通常消失（没有元素可重复），无法区分"空数组"与"字段不存在"。
常见坑
- 数组元素全叫 <item>，下游按业务名取值时全部取不到。
- 使用 @ 前缀表达属性后，换个解析器读同一份 XML，属性被当成普通子元素。
- null 被输出成空元素，消费端按空字符串处理，与"字段不存在"混淆。
- 中文键名未经清洗直接当标签名，产出非法 XML 导致解析直接报错。
相关工具
- JSON 转 XML把 JSON 文档转为 XML，支持自定义根元素与属性映射，适合对接 SOAP 接口、生成 Sitemap 与 RSS feed，免手写标签。支持自定义根元素名称、是否把键写成属性以及数组的命名方式。特殊字符与中文会自动实体转义，输出可直接用于报文提交。标签名大小写可自定义。可指定根元素名称与缩进。
- XML 转 JSON用浏览器原生 DOMParser 把 XML 解析为 JSON，保留属性与命名空间，适合把 SOAP 响应、RSS 与 SVG 元数据喂给前端组件，免装解析库。属性与文本会分开保留，重复元素合并为数组以免丢失同名字段。命名空间会连同前缀一起注明，便于判断节点归属。转换结果可一键复制。
- 数据格式转换器在 JSON、YAML、TOML、XML、CSV 之间一处粘贴自由互转并实时预览。在 JSON、YAML、TOML、XML 与 CSV 之间任意互转，粘贴一次即可看多种输出。转换时会提示解析失败的位置，避免带着语法错误继续处理。适合在不同工具链之间迁移配置文件。支持粘贴即转。多种格式的输出可逐一取用。
常见问题
怎么把 XML 再转回 JSON？
使用同工具的交换方向功能，或本站对应的「XML 转 JSON」页面，两者都本地运行、数据不上传，可完成往返转换与校验。
JSON 和 XML 哪个更适合人类阅读？
这取决于场景：XML 通常更偏向程序解析与接口传输式的可读形态，而 JSON 更利于程序解析与接口传输式的程序消费；需要人工编辑时优先选可读性更高的那一侧。
JSON 的数组转成 XML 后为什么全是 <item>？
因为 XML 没有数组类型，只能用"同名元素重复出现"表达，元素名必须由人指定；工具无法知道该叫 <book> 还是 <order>，于是用中性的 <item> 占位。需要语义化名字时要手动重命名，或者选择能按上下文命名的转换器。
属性和元素怎么区分？
这是 XML→JSON→XML 往返中最容易出问题的部分：JSON 没有属性概念，工具通常约定 @ 前缀表示属性、#text 表示元素文本。用这套约定往返可以还原，但用别的工具解析时就不认识了——跨工具传输建议只用元素，不用属性。