编码解码哈希加密格式化时间转换开发生成文本处理网络工具其他工具
首页 / 格式化 / JSON转XML

JSON转XML

粘贴JSON,一键转成带缩进的XML

输入 JSON
XML 结果

这个工具能做什么

这个工具把一段 JSON 数据转换成对应的 XML 结构,解决的是数据格式对接时的手工翻译麻烦。很多老系统、企业中间件或第三方接口只吃 XML,而现在的服务大多返回 JSON,两边格式不一致就得有人对着结构一个标签一个标签地敲。json转xml 把这件事自动化:粘贴 JSON,立刻得到带缩进、层级清晰的 XML,省去手写标签、手动转义和对齐缩进的重复劳动,也方便你把接口返回或配置数据换个格式看个明白。

它的工作方式是先用标准的 JSON 解析把文本读成内存里的数据树,再递归遍历这棵树来拼 XML。整个 json转换xml 的映射规则很直接:最外层套一个固定的 root 根节点;对象的每个键当作标签名,也就是所谓的对象转xml,键对应的值继续往下递归;数组因为本身没有名字,统一把每个元素用 item 标签重复输出;字符串、数字、布尔这类基本值直接写成标签的文本内容。写文本时会对 < > & 这些在 XML 里有特殊含义的字符做实体转义(分别转成 &lt; &gt; &amp;),避免破坏文档结构,最后按嵌套深度加上缩进。这些计算全部在浏览器本地用 JavaScript 完成,数据不上传服务器。

典型场景一是对接只认 XML 的老接口。比如你手上有一段接口返回的 JSON 订单数据,下游的支付网关或 ERP 却要求 XML 报文,用这个工具 json to xml 一转,就能拿到 root 包裹、字段变标签、订单列表变成一串 item 的 XML 直接提交或做进一步加工。场景二是写接口文档或做数据核对,你把一份 JSON 样例 json生成xml 之后,和团队里习惯看 XML 的同事对齐同一份数据的结构,或者在调试时把两种格式并排比对,确认字段有没有漏、层级对不对。

有几个边界要留意。XML 的标签名有命名规则,不能以数字开头、不能含空格或部分符号,而 JSON 的键几乎什么字符都能用,所以像 "123" 或 "user name" 这类键转出来虽然结构对,却可能不是严格合法的 XML,套进有校验的解析器前最好先检查一下。另外这个工具只做单向的 JSON 到 XML,不生成属性(attribute)、命名空间或 XML 声明头,所有信息都以子元素和文本的形式表达;数组一律映射成 item、根节点固定为 root,也不提供改名。如果你需要带属性、自定义标签或反向的 XML 转 JSON,那要另找对应工具。

JSON转XML是一个免费的在线工具,打开网页就能用,不用下载也不用注册。平时大家搜的“json转xml”、“json转换xml”、“json to xml”,说的都是这个。

常见使用场景

使用方法

  1. 把内容粘贴到输入框(生成类工具直接设置选项)。
  2. 按需要选择选项,点操作按钮。
  3. 结果出现在下方,点「复制结果」即可带走。

常见问题

数组是怎么转成 XML 的,为什么元素都叫 item?
JSON 数组本身没有字段名,无法直接映射成标签,所以工具把数组里的每个元素都用统一的 item 标签重复输出。比如 [1,2,3] 会转成三个并列的 <item> 节点,包在它所属的那个键标签里面。
能生成带属性(attribute)的 XML 吗?根节点能改名吗?
不能。工具采用固定规则:根节点始终是 root,对象的键一律转成子元素标签,值作为标签的文本内容,不产生属性、命名空间,也不支持自定义根节点或数组标签名。
文本里的 < > & 这些特殊字符会不会破坏 XML?
不会。工具会对文本内容做 XML 转义,把 & 转成 &amp;、< 转成 &lt;、> 转成 &gt;,这样特殊字符只作为普通文字出现,不会被误当成标签的一部分而破坏文档结构。
转出来的 XML 一定是合法的吗?
结构上是配对的,但不保证在严格校验下合法。因为 XML 标签命名有规则(不能数字开头、不能含空格等),而 JSON 的键没这些限制,如果键名是 "123" 或带空格,生成的标签就可能不符合 XML 规范,使用前建议先校验。
转换会把我的数据上传到服务器吗?
不会。JSON 解析、递归遍历、转义和缩进全部在你的浏览器本地用 JavaScript 完成,数据不经过任何服务器,粘贴接口返回或内部配置数据也不用担心外泄。

相关工具

查看全部「格式化」工具 →