XML 与 JSON 怎么互转？先核对属性、重复节点和混合文本

拿到一份 XML 响应，想临时整理成 JSON 交给程序处理，可以使用宝塔拨测的“XML/JSON互转”。转换前要先看数据长什么样：商品列表这样的规则节点比较容易对照，正文里夹着标签的混合内容则要格外小心。

本文用虚构商品目录演示当前工具的映射方式，再用一个短段落核对往返边界。转换前保留原文，以下规则是本工具当前的实际输出，不应当作所有 XML/JSON 转换器通用的约定。

属性和重复节点，转换后放在哪里

进入“XML/JSON互转”，保持“XML → JSON”，将下面内容粘进“XML 输入”，点击“转换为 JSON”：

<catalog region="demo"><item id="a">Alpha</item><item id="b">Beta</item><count>2</count><enabled>true</enabled></catalog>

输入包含一个根节点 catalog，它有 region 属性。两个同名 item 是重复子节点，每个 item 又带一个 id 属性和一段文字。右侧输出会保留根节点名称，并将这些内容分别放进不同字段。

本次的 catalog.region 被写成 catalog 下的 _attributes.region，两个 item 放进同一个数组。每个数组项里，属性放进 _attributes，文字放进 _text。第一项的结构是：

{
  "_attributes": { "id": "a" },
  "_text": "Alpha"
}

如果后续要写程序取商品名称，应读取每个数组项的 _text；取编号则读取 _attributes.id。不能沿用另一款转换器的字段名，直接假设属性一定以 @id 表示，或节点文字就是一个裸字符串。

另外，输入中的 <count>2</count> 和 <enabled>true</enabled> 转换后，其 _text 分别是字符串 "2" 和 "true"。XML 的文字看起来像数字或布尔值，也不会在这个例子中自动变成 JSON 数值和布尔值。如果接收接口要求真正的数字，需要按接口约定单独处理类型，不能只改扩展名就完成数据适配。

把 JSON 转回来，再对一次字段

先复制刚才输出的完整 JSON，确认包含最外层的大括号，再切换到“JSON → XML”，粘进“JSON 输入”，点击“转换为 XML”。右侧生成 XML 后，可在框内滚动检查末尾，核对根节点的结束标签是否完整。

这份普通节点示例可以重新得到 region="demo"、两个 item 的 id 和对应文字，count 与 enabled 也保留。工具还输出了 XML 声明和缩进，因此文本排版与原来一行的输入不同。

这里验证的是这组字段按本工具的映射成功往返。正式使用前，仍要数一下重复节点有没有少，属性是否回到正确节点，文字是否完整。接收方如果要求特定根节点、命名空间或其他结构，也要逐项确认。本次示例没有覆盖那些情况，不能由一次成功往返推断任意文档都能无损处理。

正文夹标签时，先做小样本测试

很多文章片段并非纯粹的字段列表。例如这段内容把“重点”加粗，前后还各有一段普通文字，并带一条注释：

<p>前文<strong>重点</strong>后文<!--备注--></p>

切回“XML → JSON”，将这段内容转换后，本次结果是：

{
  "p": {
    "strong": { "_text": "重点" },
    "_text": "前文后文"
  }
}

原来“前文—strong 节点—后文”的相对位置，在这个 JSON 结构中已经没有完整保存；注释也没有保留。仅看 strong 和 _text 都有值，容易误以为内容齐全，但它们不足以重建原来的排列。

再把这份 JSON 复制到“JSON → XML”里转换，本次实际只得到：

<?xml version="1.0" encoding="UTF-8"?>
<p>
  <strong>重点</strong>
</p>

这一步不仅改变了排版，“前文”和“后文”也未恢复。遇到这种内容，不要继续把结果当成原文的等价副本。保留原 XML，将要处理的文档交给支持保留节点顺序、文本节点及注释的专用解析流程，并用实际文档做往返对比。

如果只是从规则 XML 中临时提取几个字段，本工具可以帮助看清属性和数组的映射。若任务要求完整还原文档，应先把最有代表性的片段转过去再转回来；一旦出现上面的文字丢失，就停止用这条转换链覆盖原文件。