XML 格式化:把压成一行的配置、SOAP、RSS 看清楚

接口返回的 XML 经常是一整行。日志里、工单里、对接方的响应里,几 KB 的内容全挤在没有换行的字符串中,想找一个字段得在尖括号的海洋里数标签。XML 格式化做的就是把这团东西重新排成有缩进的层级结构,让人眼能跟着结构走。

XML 美化到底改了什么

格式化器不改你的数据,只动空白。它先把原始文本交给解析器读成一棵 DOM 树,再按树的层级重新输出:每深一层加一级缩进,每个元素单独占行。缩进可以选 2 空格、4 空格或 Tab,看你团队的约定。

关键是它保留所有非元素节点:CDATA 段照样包成 <![CDATA[…]]>,注释照样是 ,处理指令照样是 <?…?>,顶部的 XML 声明原样不动,属性也按你写的源顺序排列,不会被重排。这一点对 Maven 的 pom.xml 很重要,每个依赖上方的注释留在原地,提交评审时 diff 才不会被无关的属性顺序变动撑大。

一个真实的压缩到美化例子

下面是一段挤成一行的响应,典型的接口原样返回:

<order id="A123"><customer>李雷</customer><items><item sku="X9">2</item><item sku="Y4">1</item></items><total currency="CNY">358.00</total></order>

格式化后是这样:

<order id="A123">
  <customer>李雷</customer>
  <items>
    <item sku="X9">2</item>
    <item sku="Y4">1</item>
  </items>
  <total currency="CNY">358.00</total>
</order>

同样的字节,排开之后 items 下有几个 item、total 的币种是什么,一眼就清楚了。反过来,要贴进 Jira 工单或聊天框时,点压缩,它又塌回紧凑的一行,不占半屏。我自己排查对接 bug 时基本就是这两个动作来回切。

看懂 SOAP、RSS 和配置文件

XML 至今活跃在三类场景里。SOAP 响应是一个嵌套的信封,soap:Body 里裹着业务数据,出错时 soap:Fault 块里的 faultcode 和 faultstring 告诉你哪里崩了。这些块在一行里根本没法读,排开后层级对齐,fault 一目了然。

RSS 和 Atom feed 是另一类。播客或博客的订阅源就是 XML,<channel> 下挂着一串 <item>。当某个阅读器死活加载不了某个 feed,十有八九是某条标题里有个没转义的 & 破坏了结构。把 feed 粘进来校验,解析器会直接标出是哪一行哪一列出的问题。

第三类是配置:Spring 的 bean 定义、Maven 的 pom.xml、各种框架的 web.xml。这些文件人要反复读和改,缩进乱了维护成本立刻上来。

转义字符:那个总在坑人的 & 号

XML 里有五个字符不能裸写,因为它们对解析器有特殊含义:< 写成 <、> 写成 >、& 写成 &、" 写成 "、' 写成 '。其中最常翻车的是 &。一个 URL 里的查询参数 ?a=1&b=2 直接塞进 XML 文本节点,那个 &b 就会被当成实体的开头,解析直接失败。

还有一个坑:HTML 里很顺手的   在原始 XML 里是没有定义的,XML 只内置那五个实体。要写不间断空格得用数字引用  ,或者在 DTD 里先声明。这也是为什么有些从网页复制来的片段在 XML 解析器里报错。

和 JSON 比,什么时候用哪个

经常有人问既然有 JSON 了为什么还碰 XML。两者定位不同。JSON 轻、字段直接映射成对象,前后端传数据用它最省事。XML 更重,但它有属性、命名空间、CDATA、注释、处理指令这些 JSON 没有的东西,适合需要严格 schema 校验、混合文档结构,或者历史上就用它的协议,比如 SOAP 和大量企业级配置。如果你拿到的是 JSON,可以用 JSON 格式化工具做同样的美化和校验;两类格式之间需要互转时,XML 转 JSON 能直接把这段结构搬过去。

数据为什么不出你的标签页

这里得说清楚一点:XML 格式化工具全部处理走浏览器原生的 DOMParser,在你的标签页里跑完,没有任何网络请求,内容也不写进 URL。这意味着含 token 的 SOAP 响应、签名过的 XML、带密钥的配置文件,粘进来都只留在本地。不放心可以打开 DevTools 的网络面板,从头到尾不会有一条请求携带你的数据。对要处理敏感配置的人来说,这比把内容贴到来路不明的在线工具上踏实得多。

Made by Toolora · Updated 2026-06-13