第一次把 XML 转成 JSON 的人，几乎都会问同一句话：「这个 @ 和 #text 是哪来的」。它们不是脏数据，而是两种语言在结构上不等价的地方被显式标注出来了。

四条映射规则

XML 转换 的 XML 转 JSON 规则是固定的四条：

一、属性加 @ 前缀。 <item id="7"> 变成 {"@id":"7"}。原因是 JSON 对象里键不能重复，而 XML 里元素既可以有属性、又可以有同名子元素 —— 不加前缀就会撞键。

二、元素文本用 #text。 <name>张三</name> 在需要与属性共存时，文本被放进 #text 键。这样才能同时保留「它说了什么」和「它带什么属性」。

三、同名兄弟节点自动转为数组。 三个 <phone> 会变成一个包含三项的数组。但只有一个时它仍是对象 —— 这是消费方最常见的崩溃点：代码按数组写，遇到单条记录就报错。

四、CDATA 按文本处理。 元素里 <note> 包着的 CDATA 段，内容直接当字符串值，不会保留 CDATA 这个包装。

还有一条容易被忽略的：命名空间前缀按字面名输出，不解析其含义。<a:item> 与 <b:item> 就是两个不同的键名，不会去做 URI 归并，这是能力边界不是省略。

想只看属性：用属性提取

「列出所有属性」这种需求，转 JSON 是绕远路。 这一页的属性提取功能直接给出「元素路径 → 属性名 = 值」的清单，并可导出为 CSV 或 JSON。

典型用法：检查一批报文里 encoding 声明是否统一、找出所有带 xsi:type 的节点、看哪些元素带了意外属性。

CDATA 里的内容同理：CDATA 提取按出现顺序导出所有段的文本，不用自己在格式化结果里翻。

反向检查完整性的两个办法

第一是比数量。 转换后数一数数组长度，与 XML 里同名节点的手动计数对上。「少了一项」通常意味着原文有嵌套同名节点被并到了同一层。

第二是把 JSON 再转成 CSV 看。 用 JSON 格式化 的 JSON 转 CSV：嵌套键变成 a.b.c 列名、所有对象的键取并集、缺失值留空。表格视图下，哪一列大片留空，就说明原 XML 的结构不均匀。规则细节见 JSON 数组转 CSV 导入 Excel：嵌套键、缺失值和列顺序怎么处理。

该选 XML 还是 JSON

报文有属性、命名空间、混合内容的，保留 XML 更稳。 只需要「一堆记录、每条若干字段」的，转成 JSON 或直接导出 CSV 更省事，程序处理成本明显低。

要长期给程序用的数据，别在中间反复转格式 —— 每转一次都在丢失一部分语义（属性前缀、顺序、命名空间）。源头是什么格式，就用那个格式对接。

全程在浏览器本地完成，文件不上传、不占每日转换次数。分隔符、编码那类问题属于 CSV 一侧，见 CSV 分隔符是逗号还是分号？自动识别的规则与必须手动的两种情况。