免费XML转JSON转换器
即时将XML转换为JSON。支持属性、嵌套元素和文本节点。完全在您的浏览器中运行。
什么是XML？
XML（可扩展标记语言）是一种用于存储和传输数据的格式。它使用自定义标签来描述数据结构，使其人类可读且广泛受支持。与JSON不同，XML可以在元素上包含属性。
为什么要将XML转换为JSON？
- 文件体积更小 · JSON比XML更紧凑。
- Web API · 大多数现代Web服务使用JSON而不是XML。
- 更容易解析 · JSON直接映射到JavaScript对象。
- 遗留系统集成 · 将旧XML数据转换为现代JSON格式。
常见问题
XML属性是如何处理的？
XML属性被转换为带有@前缀的JSON属性（例如@id、@href）。这在JSON结构中保留了属性信息。
命名空间怎么处理？
命名空间会在输出中保留。前缀会包含在元素名称中（例如“ns:element”）。
可以将JSON反转为XML吗？
此工具将XML转换为JSON。反向转换请使用我们的JSON转XML转换器。
两种格式，三十年的间隔
XML 1.0于1998年2月10日成为W3C推荐标准。最初的编辑者是Tim Bray（Textuality / Netscape）、Jean Paoli（微软）和C. M. Sperberg-McQueen（伊利诺伊大学芝加哥分校）；工作组由Sun微系统公司的Jon Bosak主持。XML的血统可追溯至SGML（ISO 8879:1986），这一文档标记标准本身源自IBM于1970年代的GML。SGML功能强大但令人望而生畏；XML的设计目标是「设计一个SGML的精简版」，删减可选特性，使其可以用几千行代码实现，同时保留Unicode、命名空间和富属性文档。
JSON（JavaScript对象表示法）是被发现的，而非设计出来的。Douglas Crockford和Chip Morningstar于2001年4月在State Software发送了第一条JSON消息，该格式源自JavaScript的对象字面量语法。Crockford于2002年注册了json.org并发布了一页规范。该格式于2006年7月首次被正式化为RFC 4627，2014年重新发布为RFC 7159，2017年12月稳定为RFC 8259 / STD 90，同年ECMA国际发布了ECMA-404。JSON的设计意图（根据Crockford的回顾）：极简、语言无关、易于生成和解析、没有版本号（「没有版本号」），以及故意不支持注释（「我删除了注释，因为我发现人们在用它们存储解析指令」）。
JSON在2000年代末随着REST取代SOAP、XMLHttpRequest让位于fetch over JSON而占据Web API主导地位。到2015年，JSON已成为几乎所有公共API的默认响应格式；XML在长尾企业SOA、文档格式（Office Open XML、OpenDocument）以及受标准约束的细分领域中幸存下来。
XML与JSON的区别
| XML | JSON | |
|---|---|---|
| 属性 | 原生支持（<item id="5"/>） | 无属性，所有内容均为键/值对 |
| 命名空间 | 原生支持（xmlns:prefix="uri"） | 扁平名称；前缀冲突由应用程序处理 |
| 注释 | <!-- … --> | 规范中无此概念 |
| 混合内容 | 原生支持（<p>text <b>and</b> markup</p>） | 处理笨拙，需要数组或字符串化 |
| 模式 | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema（社区规范，草案 2020-12） |
| 顺序 | 元素顺序在规范中有意义 | 对象键顺序无保证（大多数解析器在实践中保留插入顺序）；数组是有序的 |
| 数字 | 在模式类型化之前均为字符串 | IEEE 754 双精度浮点；规范层面不区分整数/浮点数 |
| 冗余程度 | 高（每个值都用标签包裹 | 低）仅使用标点符号 |
为何XML→JSON本质上是有损的
不存在W3C认可的XML到JSON规范映射。每个转换器都必须对XML能表达但JSON没有原生词汇的问题自行作答。反复出现的决策点：
- 属性与子元素：XML允许两种方式表达相同数据。JSON只有一种概念（对象的键），因此转换器必须创造一个标记。常见约定：BadgerFish用
@表示属性，用$表示文本；Parker完全丢弃属性（有损但简单）；JsonML将元素表示为带类型标签的数组（保留顺序和结构）；GData / Newtonsoft / xml2js使用@attributes子对象加上在需要时使用#text键。本转换器遵循GData风格约定：@attributes下存放属性，#text下存放混合内容文本，重复子元素成为数组。 - 重复子元素：如果转换器盲目地为每个子元素创建一个键，第二个子元素会覆盖第一个。标准解决方案：检测重复并生成数组。但这意味着JSON结构依赖于数据，一个
<book>生成字符串，两个生成字符串数组。某些消费方即使只有一个元素也想要数组形式；一些转换器为特定元素名提供「始终数组」切换选项。 - 混合内容：
<p>Hello <b>world</b>!</p>将文本和元素交错，顺序有意义。JSON无法在不使用混合类型数组或哨兵#text键的情况下原生表达这种交错。许多转换器会丢弃元素之间的散文；较保守的转换器将其拆分为多个文本节点条目。 - 命名空间：
<soap:Envelope xmlns:soap="…">同时具有前缀和绑定URI。大多数转换器将前缀作为JSON键的一部分保留（soap:Envelope）并丢弃绑定，只要消费方不需要解析命名空间这就没问题。 - 注释和处理指令：通常被静默丢弃，因为JSON没有注释语法。
- CDATA节：被展平为纯字符串；
<![CDATA[…]]>包装器丢失。 - 空白符：XML有
xml:space="preserve"用于有意义的空白符；JSON没有等效项。大多数转换器会修剪元素之间的纯空白文本节点。
适合使用此工具的场景
- 从现代JS前端消费遗留SOAP服务。SOAP响应是XML；在边界处一次性转换可让应用的其余部分以JSON运行。
- RSS / Atom订阅源处理：两者都是XML格式；现代新闻阅读器和聚合器通常需要JSON。
- XML站点地图（
sitemap.xml），转换为JSON使其更易于以编程方式检查和处理。 - OpenStreetMap OSM数据：以XML发布，客户端地图制作经常需要JSON格式。
- Google Earth KML / GPX文件：XML格式的地理数据格式。
- Office Open XML内部结构：
.docx、.xlsx和.pptx是压缩的XML文件；如果您提取了其中一个并希望以JSON形式检查其结构，这就是转换步骤。 - SVG操作：SVG是XML。转换为JSON使得在重新序列化之前用JavaScript遍历和修改树变得更容易。
- Maven POM、Ant构建文件、Spring配置、Android资源、Apple plist、XBRL财务数据、HL7医疗记录、MusicXML、NMX法律文件：长尾XML格式，下游工具通常需要JSON。
现代替代方案
- 原生JSON API。如果上游服务提供JSON变体，直接使用。SOAP服务通常不提供，但大多数现代等效服务提供。
- GraphQL。一种查询语言，允许客户端从类型化模式中精确请求所需的JSON结构。
- Protocol Buffers（Protobuf）、MessagePack、CBOR、Avro。带模式的二进制序列化格式，线路大小比XML或JSON小得多。在微服务网格内部很常见；在浏览器边界很少使用，因为它们需要显式解码库。
- 坚持使用XML。如果数据本质上是面向文档的（混合内容、深度类型结构、重要的模式验证），XML是更好的选择。JSON的优势在于API形状的数据；文档保真度不是它的专长。
更多问题
为何相同的XML在不同工具中产生不同的JSON结构？
因为不存在规范的XML→JSON映射。每个转换器选择一种约定（BadgerFish、Parker、JsonML、GData风格），生成的JSON结构在属性标记方式、混合内容保留方式和重复子元素数组化方式上各不相同。通过不同转换器对XML进行往返转换会产生不同的JSON；通过不同转换器将JSON往返转换回XML可能改变属性位置甚至元素顺序。为了互操作性，请记录您使用的约定并坚持使用。
CDATA节、注释和处理指令怎么处理？
CDATA节（<![CDATA[…]]>）被展平为纯字符串内容，包装器消失，但其中的文本被原样保留。XML注释（<!-- … -->）和处理指令（<?xml-stylesheet …?>）被丢弃，因为JSON对两者都没有语法。如果您需要保留注释的往返保真度，纯XML往返才是正确方式。
我的XML模式（XSD）在转换后还能保留吗？
不能。XSD描述XML结构和类型；JSON Schema是JSON的类似（独立）标准。某些高级工具可以将XSD转换为JSON Schema，但这是有损操作，XSD具有JSON Schema没有对应等效项的特性（混合内容、替换组、派生类型）。对于重要的文档验证，请对原始XML运行XSD，而不是对JSON转换运行。
为何JSON在Web API中胜出？
几个原因。JSON直接映射到JavaScript对象，因此浏览器端解析只需一次JSON.parse()调用。格式更小，没有闭合标签，没有命名空间声明，没有模式包袱。REST在2000年代末取代了大多数公共API的SOAP，而JSON是REST的天然载荷。XML的优势（严格模式、命名空间、混合内容）对文档和遗留企业系统很重要，但对于「给我用户对象」这类请求很少有用。Web针对更简单的情况进行了优化。
有任何内容会发送到服务器吗？
不会。XML由浏览器原生的DOMParser解析，然后在JavaScript中递归遍历以构建JSON输出。粘贴的XML从不离开页面。该工具在加载后可离线工作，这在源XML包含内部API端点、客户数据或您不愿上传到任何地方的专有模式时尤为重要。