JSON → XML 转换器，免费

JSON 与 XML，两种格式，两个时代

XML（Extensible Markup Language）于 1998 年 2 月 10 日由 W3C 标准化为 Recommendation，W3C XML 1.0 规范，由 Tim Bray、Jean Paoli 和 C.M. Sperberg-McQueen 编辑。XML 由 SGML（更早的「Standard Generalised Markup Language」，ISO 8879:1986）通过移除最复杂的特性、产出某种 web 实际能用的东西演化而来。在 21 世纪的头一个十年里，XML 是任何结构化数据交换的默认格式，SOAP web 服务、RSS feeds（RSS 2.0，Dave Winer，2002）、Atom（RFC 4287，2005）、Microsoft Office 的 Open XML 格式（.docx/.xlsx/.pptx，ISO/IEC 29500:2008）、Android XML 布局、Java property 文件、几乎所有服务器框架的配置。XML 的强项是命名空间、属性、混合内容（文本和子元素交错）以及一个丰富的 schema 生态系统（DTD、XML Schema 1.1、Relax NG）。它的弱点是冗长，每个值都要带一个开标签和一个闭标签。

JSON（JavaScript Object Notation）由 Douglas Crockford 在 2001 年规范化，json.org 网站和他最初那篇「JSON: The Fat-Free Alternative to XML」的文章。JSON 是 JavaScript 对象字面量语法的一个有意为之的子集：对象、数组、字符串、数字、true/false/null。在 2006 年 7 月被标准化为 RFC 4627，2014 年 3 月精炼为 RFC 7159，又在 2017 年 12 月精炼为 RFC 8259（即当前的 STD 90 标准，同时也由 ECMA 作为 ECMA-404 发布）。JSON 在 web API 上对 XML 的接管大致发生在 2008-2014 年，时间正好与单页应用的兴起以及移动 API 时代相吻合。今天几乎每一个公开的 REST API 都用 JSON 来给自己写文档；XML 主要存活于企业集成、文档格式、配置文件和 feed 格式里。两种格式都仍在活跃使用，因为它们各自擅长编码不同的东西：JSON 适合简单类型、形状可预测的结构化数据；XML 适合带混合内容、属性、命名空间和严格 schema 的文档。

你真正需要把 JSON 转成 XML 的场合

• 从只支持 JSON 的客户端调用 SOAP 网络服务。SOAP 在设计上就是基于 XML 的（SOAP envelope、WSDL 服务描述、XSD schema）。如果你手里有 JSON 形式的数据，又需要构造一份 SOAP 请求体，JSON 转 XML 就是这中间的桥梁。这在企业集成里很常见，当现代微服务需要去和老旧的 SOAP 端点（银行、政府、保险、医疗交换系统）打交道时。
• 从 JSON 数据生成 Office Open XML 文档。.docx、.xlsx 和 .pptx 这些格式本质上是装着 XML 文件的 ZIP 归档。要从 JSON 支持的数据里以编程方式生成或修改 Office 文档，JSON 转 XML 就发生在你应用程序的数据层和文档生成库之间的边界上。
• 从 JSON 内容产出 RSS 或 Atom feed。博客、新闻站点和播客平台会发布 RSS/Atom feed 用于聚合分发。如果你的 CMS 把文章存成 JSON，那么生成 feed 这一步就负责把 JSON 条目转成 feed 阅读器生态期待的那种 XML 格式。
• 为遗留应用生成 XML 配置文件。很多老一些的企业应用（Java 应用服务器、.NET 配置文件、Spring 的 XML application context）都把配置当作 XML 来吃。现代的基础设施即代码工具通常都在 YAML 或 JSON 里工作，所以 JSON 转 XML 就被放进了部署管线里。
• 把数据喂进一次 XSLT 转换。XSLT（XSL Transformations，Michael Kay 主笔的规范，W3C Recommendation）是标准的 XML 转换语言，吃的是 XML 输入。如果你的数据是从 JSON 开始的、而你的报表引擎是基于 XSLT 的，那么转换就发生在输入这一边。
• 生成 Android 资源文件。Android 的 strings.xml、colors.xml、dimens.xml 以及 layout 文件都是 XML。把字符串以 JSON 方式存储以便编辑的本地化管线，会在 build 阶段把它们转换成 XML。

转换映射，哪些信息能保留下来，哪些会丢失

JSON 和 XML 拥有不同的结构原语，所以任何转换都得做一些选择。大多数转换器（包括这一个）所遵循的标准 JSON-to-XML 映射如下：

• JSON 对象变成 XML 元素。每个键变成一个子元素，键名作为标签名。{"name": "Alice"} 会变成 <name>Alice</name>。
• JSON 数组变成重复出现的子元素。{"items": [1, 2, 3]} 会变成 <items> 包装下的三个 <item>1</item><item>2</item><item>3</item> 子元素。（不同转换器对数组元素的命名约定不一样；有的把父元素名取单数形式，有的就固定用 <item>。）
• 字符串、数字、布尔值变成元素的文本内容。类型信息不会保留，XML 把所有文本都当作字符数据处理，所以 XML → 解析 → 重新序列化回 JSON 的一次往返，会把数字以带引号的字符串形式发出来，除非消费方做了类型推断。
• null 变成自闭合的空元素。{"middle_name": null} 会变成 <middle_name/>。也有一些转换器改用 xsi:nil="true" 表达。
• 根元素把整体包起来。JSON 允许顶层是数组或标量；XML 要求恰好有一个根元素。<root> 包装（在这里可配置）就是约定俗成的做法。

在转换中丢失的信息：JSON 在数字和字符串之间的区别、JSON 在 true/false 与「true」/「false」字符串之间的区别、JSON 在数组和对象之间的区别（当一个数组变成重复元素时，光看 XML 你无法知道源数据到底是一个只有单个元素的数组，还是一个单值）。可能获得但简单转换器不会用的信息：XML 属性（一个 JSON 对象其实可以把键映射成属性而不是子元素）、XML 命名空间（JSON 没有任何对应物）、CDATA 段（用来嵌入含 XML 特殊字符的文本）。如果想做一种能保留类型信息、能安全往返的 JSON-to-XML 转换，BadgerFish 约定或 Parker 约定会把 JSON 的类型编码进带命名空间的 XML 属性里，本工具产出的是更简单、更易读的形式，而不是「能安全往返」的那种形式。

JSON 键没有的那些 XML 标签名约束

JSON 对象的键是任意字符串，任何 Unicode 都可以。XML 元素名则受限得多：必须以字母或下划线开头（不能是数字、连字符或点），可以包含字母、数字、连字符、下划线和点（不允许空格，绝大多数标点也不允许），区分大小写，并且不能以保留前缀 xml 开头（在任何大小写组合下都不行）。带空格的 JSON 键（"first name": "Alice"）、以数字开头的键（"3rd_choice"）、含特殊字符的键（"@type"、"$value"）都不能直接当作 XML 元素名来用。大多数转换器（包括这一个）会默默地把不合法的字符改造一下，空格替换成下划线，给以数字开头的键加一个下划线前缀，把大多数标点直接丢掉。在做往返时要意识到这一点：含有不-XML-安全键的 JSON 文档，经过 XML 后是不会原样回到自己的。

2026 年 XML 还在哪些地方称王

在 2026 年，XML 并没有在退场，它只是安顿在了一些具体的领地里。文档格式：Office Open XML（Microsoft Office）、OpenDocument（LibreOffice）、EPUB 电子书、SVG（W3C Recommendation 2001 年 9 月 4 日）、MathML、XHTML。配置：Java 应用服务器、Spring XML context、Maven POM、Android 的 XML 资源、.NET 的 app.config 和 web.config。Feeds：RSS 2.0、Atom 1.0（RFC 4287）、播客 feed（iTunes 的 RSS 扩展）。医疗与政府交换：HL7 v3、FHIR（现在它把 JSON 作为可选项，但 XML 形式仍然在大量使用）、DocBook、NewsML、银行业的 ISO 20022。标准组织：几乎所有 IETF 和 W3C 规范的示例都使用 XML。在这些领域里，XML 的冗长其实是一种特性：它是自描述的，按 schema 进行校验已经很成熟，XML 方言之间的 XSLT 转换也是一套很成熟的工具集。这种格式不会消失；JSON-to-XML 转换正是连接现代数据工具链与这些已经站稳脚跟的、原生使用 XML 的系统之间的桥梁。

隐私：仅在浏览器里完成转换

粘到转换器里的 JSON 经常包含真实的生产数据，带用户标识符的 API 响应、揭示业务分类的内部实体 ID、含端点 URL 与功能开关的配置值、令牌、还没发布出去的草稿内容。服务端转换器会把每一份输入都顺手存进它们自己的日志里。本转换器用浏览器内置的 JSON.parse() 来解析你的 JSON，然后用 JavaScript 走完整个对象树，再以字符串形式输出 XML，一切都在你的浏览器标签页里完成。点 Convert 时打开 DevTools 的 Network 选项卡看一下（不会有任何请求被发出），或者在页面加载完成后让它离线（飞行模式），转换器仍然能继续工作。对生产环境的 API 响应、内部配置、草稿内容，或任何你不希望被复制到陌生人硬盘上的 JSON 来说，都是安全的。

常见问题

JSON 数组如何转换？

数组里的每一项都会变成一个独立的子元素。{"colors": ["red", "blue"]} 会变成 <colors><item>red</item><item>blue</item></colors>。对于没有具名的数组项，约定俗成的元素名就是 <item>。如果你下游的消费方要求另一种约定（比如把父元素名变成单数形式，比如 <color>），那你就得对 XML 做后处理，或者使用另一个支持自定义数组元素命名的转换器。

它能处理大的 JSON 文件吗？

可以，因为整个过程都是在你的浏览器里跑的，实际的天花板就是你设备的可用内存。在现代笔记本上，几万行 JSON 也能在远不到一秒的时间里就转换完成。非常大的输入（几 MB 起步）可能会在解析器走完整棵树期间让标签页短暂卡一下。如果是要批量转换大型数据集，用一段调用服务端转换器（Node 上的 xml2js、Python 上的 dicttoxml）的脚本会更合适。

我的 JSON 会被上传到服务器吗？

不会。整个转换都完全在你的浏览器里完成，粘进来的 JSON 永远不会离开你的设备。点 Convert 时打开 DevTools 的 Network 选项卡看一下（不会有任何请求被发出），或者在页面加载之后让它离线（飞行模式）。对生产环境的 API 响应、内部配置，或任何你不希望被外部分享的数据来说，都是安全的。

我能不能让一些 JSON 键变成 XML 属性，而不是子元素？

本转换器把所有 JSON 键都当作子元素输出，不会作为属性。一些转换器使用的约定（以 @ 开头的键会变成属性（"@id": 5 → 父元素上多一个 id="5"））叫做 BadgerFish 约定。如果你下游的消费方要求某些值必须以属性形式出现，那你需要一个理解这种约定的自定义转换器，或者手动编辑产出的 XML。

那些含有空格或非法 XML 字符的 JSON 键，会被怎么处理？

XML 元素名的规则比 JSON 键要严格得多：必须以字母或下划线开头，不能含空格，绝大多数标点也不允许。含有非法字符的键会被「清洗」一下，空格变成下划线，开头是数字的键会被加上一个下划线前缀，特殊字符直接去掉。这就意味着 JSON → XML → JSON 这一来一回未必能精确还原最初的键名。如果你的数据里有不太寻常的键，请检查一下输出，确认这种重整没有把什么重要的东西搞坏。

相关工具