XML 转 JSON 转换器 —— 免费、无需登录

树是同一棵，读者不是同一批

XML 和 JSON 描述的都是数据树——这边是带子元素的元素，那边是带键的对象。差别在于谁读它们。XML 生活在配置文件、站点地图、联合供稿、SOAP 信封、企业集成与文档格式的内里。JSON 则是浏览器、移动应用、无服务器函数和整个现代无代码工具链的原生口粮。把 XML 转成 JSON，就是从一个系统产出的格式，走向下一个工具真正听得懂的格式。

因为两边都是树，这是文件所能经历的最轻的转换之一。没有页面要排版，没有像素要搬运：文件被解析、再输出，典型任务远在几分钟之内完成——平台任意任务的上限仍是约 10 分钟，但数据转换很少靠近它。

日常任务同样具体。旧配置，新的部署管线想要 JSON 形态。老 API 的 XML 响应，JavaScript 服务要消费。锁在 XML 导出里的数据，仪表盘、表格工具或脚本更愿意以 JSON 读取。所有这些场景里，最重要的不是速度而是可预期：自动化链会在转换器让它们吃惊的地方断裂。

映射规则，摆在明面上说

规则先行，因为这场转换的全部价值就在于可预期。属性会变成带连字符前缀的键：写作 `<meta id="7">` 的元素会变成一个 meta 对象，其属性以键 "-id"、值 "7" 到达。前缀是有意为之——它保证属性永远不会与同名子元素相撞。

文本节点有自己的规则。当元素同时带有属性和文本时，文本会进入一个以井号开头的专用键（井号后接表示「文本」的小写英文词）。重复决定形状：同名元素在兄弟之间出现两次或以上，才会成为 JSON 数组；只出现一次则映射为普通字符串、数字或对象。输出的形状跟随文档真实的出现次数——这是设计，不是偶然——所以「为什么这是字符串而不是数组」永远只有一个答案：它只出现了一次。

命名空间值得一段如实的话，因为我们不打算假装别样。命名空间前缀不会被保留：带前缀的元素名输出时只保留冒号后面的本地名，命名空间声明本身则按普通属性对待——与其他键一样，变成带连字符前缀的键。如果你的下游逻辑依赖带前缀的限定名，请在接入前检查输出；这场转换用命名空间保真换来了扁平、可预期的形状，并且明说这一点，而不是自称并不具备的完整。

不带惊讶地阅读转换输出

出现次数规则是唯一需要内化的。一个在这个文档里恰好只出现一次的可选元素，会以标量或对象的形态到达——而不是单元素数组。消费这份 JSON 的代码要么两种形状都处理，要么确保源里真的有重复。这是每一场 XML 到 JSON 的映射都在做的取舍；不同之处在于，这里把它写了出来。

数据层面没有任何丢失。属性不会消失——它们戴着连字符。文本不会消失——元素混杂时它坐在自己的键下。XML 里合法的名字会原封不动地成为 JSON 键。唯一值得重复的保证：因为属性带连字符前缀，属性与子元素在输出里永远不会互相覆盖。

实用建议很短。要把某个 XML 源接进自动化链？先转一个有代表性的样本，看看形状，然后再批量处理其余。根本不是 XML 的文件——被截断的下载、改了名的别的什么——会带着明确原因失败，而不是吐出垃圾 JSON，所以失败的任务永远是可以安全重试的任务。

隐私与文件留存

一个文件进，一份 JSON 出——免费，无需登录，无水印。传输走 HTTPS，处理在转换集群上完成，原始 XML 和产出的 JSON 都会在 24 小时内自动删除。配置文件可能含有端点与密钥，所以要直白地说清楚：不与广告商共享任何东西，流程中没有任何电子邮件输入框，任何环节都不要求登录。留下的是你下载走的那份文件。