XML 转 JSON 工具到底产出什么
XML 转 JSON 工具做的事情很具体：沿着 XML 文档树走一遍，输出一份按相同层级组织的 JSON。每个元素变成对象，每个属性按约定折进对象里（多数实现用 @ 前缀的键），文本内容放进另一个约定键（常见的是 #text），重复的同级元素归并成 JSON 数组。换言之，它不是把 XML 换种写法，而是把 XML 重新塑形成 JSON 仅有的两种容器——对象和数组。
为什么会有这个方向的转换需求
XML 在订阅源、配置文件、SOAP 接口和大量企业级文档交换里仍然广泛存在；JSON 主导了现代 HTTP 接口、JavaScript 运行时和绝大多数调试工具。XML 转 JSON 就是这两个世界之间的桥：当一份本来用 XML 传过来的数据，要被一个只懂 JSON 的程序消费时，与其改造两端，不如在中间转一次。
XML 构件如何映射到 JSON，又有哪些映射不下来
JSON 只有对象、数组、字符串、数字、布尔、null；XML 有元素、属性、混合文本、命名空间、处理指令、CDATA，还有顺序规则。多数 XML 构件能映射到 JSON，但这是一组“约定”而非规范——每个转换工具自己选一套。提前理解本工具采用的约定，能让你审查输出更快，也更能预测下游代码会看到什么。
- 每个元素变成一个以标签名为键的 JSON 对象；子元素以嵌套对象的方式放在该键下面。
- 属性折进同一个对象，但加约定前缀（常见为 @attr），避免和子元素名撞键。
- 文本内容放在约定键下（常见为 #text 或 _），只有当元素同时还带属性或子元素时才会用到这个键。
- 同名的多个同级元素会合并成数组；只有一个同名子元素时仍然是单个对象。下游代码必须同时能处理两种形态。
- 命名空间默认保留在标签名里（前缀:标签），除非显式要求剥离。静默去掉命名空间是“两份看起来一样的文档其实语义不同”的最常见原因。
一句话原则：审查输出前先写下你期望的约定（属性前缀、文本键、数组策略、命名空间处理）。结果是否“对”，永远只是相对于你已经定下的约定而言。
如何使用这个工具
- 先在 XML 转 JSON 中准备一份有代表性的需要变成更适合接口或解析器使用的 XML 文档，不要一开始就处理最大或最敏感的真实内容。
- 执行处理流程并生成反映 XML 层级结构、便于审查的 JSON 文本后，优先检查属性、重复元素、文本节点内容、命名空间，以及源 XML 是否混合了数据和展示结构，再判断结果是否真的可用。
- 只有当结果已经适合用于接口迁移、支持排查、导入准备和 XML 清理，并且不再触发这条风险提醒时，才复制或下载输出：XML 的属性、命名空间和重复节点在转换后可能会被压平，因此结果需要额外人工检查。
XML 转 JSON 示例
这个 XML 转 JSON 示例使用有代表性的需要变成更适合接口或解析器使用的 XML 文档，展示生成后的反映 XML 层级结构、便于审查的 JSON 文本，便于你先确认属性、重复元素、文本节点内容、命名空间，以及源 XML 是否混合了数据和展示结构，再把同样设置用于真实输入。
示例输入
<item><name>ToolKit</name><active>true</active></item>
预期输出
{
"item": {
"name": "ToolKit",
"active": "true"
}
}一份小型 XML 与对应的 JSON
<!-- XML -->
<library>
<book id="1" lang="en">
<title>XML in a Nutshell</title>
<author>Eckstein</author>
</book>
<book id="2" lang="en">
<title>Effective Java</title>
<author>Bloch</author>
</book>
</library>
// JSON
{
"library": {
"book": [
{ "@id": "1", "@lang": "en", "title": "XML in a Nutshell", "author": "Eckstein" },
{ "@id": "2", "@lang": "en", "title": "Effective Java", "author": "Bloch" }
]
}
}注意两个同级 book 元素合并成了数组，而属性（@id、@lang）和子元素键并排放在同一个对象里。如果原本只有一个 book，book 就是对象而不是数组。
什么场景下 XML 转 JSON 是正确选择
这一步转换最划算的位置，是“产 XML 的系统”和“消费 JSON 的系统”之间的边界。数据一旦越过这条边界，下游每件工具的集成成本都会下降。
- 把 RSS/Atom 订阅源导入到一个 JS 写的阅读器或研究脚本里，下游栈里没有 XML 解析器。
- 想快速排查一份复杂的 XML 响应：转成 JSON 后在 DevTools 里展开看，比硬读 XML 快得多。
- 在网关层把老 SOAP 服务桥接到现代 HTTP 接口。
- 把 XML 配置喂给只接受 JSON 的校验器、Lint 工具或 Schema 推断工具。
- 把合作方提供的 XML 样本分享给分析、产品、客服等团队，免去他们装 XML 查看器。
转换之后最值得复核的几类边界
XML 能表达 JSON 表达不了的东西。看似“奇怪”的转换结果，多数不是 bug，而是源 XML 用到了 JSON 约定必须拍平、改名或丢弃的东西。
- 元素顺序：XML 严格保留，JSON 对象键不保留。下游若依赖顺序，应让子元素保留为数组，而不是提升成对象键。
- 混合内容：同时含文本与子元素的元素没有干净的 JSON 形态，常见做法是拍成片段数组，这对“文档型 XML”是有损的。
- 命名空间：剥掉前缀让 JSON 看起来更整齐，但会把 XML 视作不同的元素静默合并。拿不准时保留前缀。
- 看似数字的字符串：XML 里 007 本就是文本。若被工具强转成数字，前导零会丢，下游做字符串比较时就匹配不上。
- CDATA 块：内部内容必须原样保留。工具可以去掉外层 CDATA 标记，但不应对内容做额外转义或裁剪。
使用注意
- 复用反映 XML 层级结构、便于审查的 JSON 文本前，先检查属性、重复元素、文本节点内容、命名空间，以及源 XML 是否混合了数据和展示结构。
- XML 的属性、命名空间和重复节点在转换后可能会被压平，因此结果需要额外人工检查。
- 当结果会影响生产工作或客户可见内容时，应保留原始需要变成更适合接口或解析器使用的 XML 文档以便回退和核对。
XML 转 JSON 参考说明
XML 转 JSON 的参考说明应始终围绕需要变成更适合接口或解析器使用的 XML 文档、生成的反映 XML 层级结构、便于审查的 JSON 文本，以及用于接口迁移、支持排查、导入准备和 XML 清理前必须确认的检查点。
- 输入重点：需要变成更适合接口或解析器使用的 XML 文档。
- 输出重点：反映 XML 层级结构、便于审查的 JSON 文本。
- 复核重点：属性、重复元素、文本节点内容、命名空间，以及源 XML 是否混合了数据和展示结构。
参考资料
常见问题
以下问题围绕 XML 转 JSON 的实际用途整理，重点说明输入要求、输出结果和常见限制。将 XML 标记转换为 JSON 对象。
XML 转 JSON 最适合处理什么样的需要变成更适合接口或解析器使用的 XML 文档？
XML 转 JSON 的核心用途是把 XML 转成更容易检查和继续处理的 JSON。当需要变成更适合接口或解析器使用的 XML 文档需要快速变成反映 XML 层级结构、便于审查的 JSON 文本，并继续用于接口迁移、支持排查、导入准备和 XML 清理时，它最有价值。
复用 XML 转 JSON 生成的反映 XML 层级结构、便于审查的 JSON 文本前，最该检查什么？
应优先检查属性、重复元素、文本节点内容、命名空间，以及源 XML 是否混合了数据和展示结构。这些细节最能直接判断结果是否已经适合继续交给下游流程。
XML 转 JSON 生成的反映 XML 层级结构、便于审查的 JSON 文本通常会被带到哪里继续使用？
最常见的下一步就是用于接口迁移、支持排查、导入准备和 XML 清理。这类输出是按真实交接场景来组织的，不是泛化占位结果。
什么时候不应该直接相信 XML 转 JSON 的结果，而要人工复核？
XML 的属性、命名空间和重复节点在转换后可能会被压平，因此结果需要额外人工检查。