XML 格式化完全指南：美化、压缩与合式校验
从 SOAP 接口抄回一行挤成一团的报文、Android 的 strings.xml 改乱了层级，或 Maven/Spring 配置「看起来差不多但解析器报错」时，最先该做的往往不是改业务字段，而是把 XML 摊成统一缩进的树形结构，再核对标签是否成对、实体是否写对。本指南讲清美化与压缩、合式与合法、实体与命名空间，并直接对接 WebUtils 本地 XML 工具。
核心一句话
先保证合式（well-formed），再谈业务字段；美化让层级可见，压缩只留给传输与入库。
XML 比 HTML 更「死板」：标签必须正确嵌套与闭合，属性值要有引号，裸 &、< 会直接让解析失败。WebUtils 的 XML 格式化 在浏览器里完成美化与压缩，可选手动 2 空格、4 空格或 Tab，数据不出本机。它帮你看清结构，但不是完整的 XSD/DTD 模式校验器——「合式」与「符合某个 Schema 合法」是两层概念，下文会拆开讲。
1. 美化、压缩与校验各自解决什么
美化（Pretty-print / Beautify）
把标签按嵌套层级换行并缩进，让父子关系一眼可读。典型用途：
- 读日志里整行挤在一起的 SOAP/REST 报文
- Code Review 配置文件时对齐层级
- 排查「少写了结束标签」或「交叉嵌套」
美化原则上不改语义：它调整的是标签之间的空白；文本节点内部有意义的空格是否被碰，取决于具体实现。本站工具先把 >…< 之间的空白收紧，再按缩进规则重写，适合「结构文本」为主的报文与配置；若你依赖混合内容里精确空白（少见），应在专用编辑器里再核对。
压缩（Minify）
去掉标签之间多余空白与换行，缩小体积、方便单行粘贴到请求体或消息队列。压缩同样不应改标签名、属性与文本内容本身。注意：若某段文本节点故意包含首尾空白，激进压缩可能影响展示类内容；配置与 API 报文一般无此问题。
校验：合式 ≠ 合法
| 层级 | 问的是什么 | 谁来判断 | 失败例子 |
|---|---|---|---|
| 合式（well-formed） | 是否满足 XML 基本语法 | 任何 XML 解析器 | 标签未闭合、交叉嵌套、裸 & |
| 合法（valid） | 是否符合 DTD/XSD/RelaxNG 等模式 | 带 Schema 的校验器 | 缺必填元素、类型不符、命名空间错 |
日常联调 80% 的「XML 坏了」其实是合式问题。格式化工具通过缩进把结构摊开，能快速暴露未闭合与交叉嵌套；XSD 业务规则要另用 IDE、xmllint 或服务端校验。本工具在格式化路径上若输入明显异常，可能提示检查语法，但不要把它当成完整 Schema 校验。
XML 与 JSON / HTML 的边界
| 点 | XML | JSON | HTML |
|---|---|---|---|
| 主要用途 | 企业集成、配置、文档型数据 | Web API、前端状态 | 页面结构 |
| 注释 | <!-- --> |
无（标准） | <!-- --> |
| 属性 | 元素可有属性 | 无属性，全靠对象字段 | 有属性 |
| 容错 | 解析器几乎不容错 | 严格 | 浏览器高度容错 |
| 命名空间 | 一等公民 | 无 | 有限 |
拿到「像标签又像页面」的片段时：若目标是数据交换/配置，按 XML 合式规则修；若目标是浏览器渲染，更适合 HTML 格式化。接口若已迁到 JSON，排错走 JSON 格式化。
2. 必须刻进肌肉记忆的 XML 规则
单一根元素
一份合式 XML 只能有一个根。下面非法：
<item>a</item> <item>b</item>
应包在一个根下，例如 <items>…</items>，或使用多文档/外层信封（SOAP 的 Envelope 就是这种角色）。
正确嵌套，禁止交叉
<!-- 合法 --> <a><b>text</b></a> <!-- 非法：交叉嵌套 --> <a><b>text</a></b>
美化后若缩进「对不齐」或层级突然回退异常，优先怀疑交叉闭合。
空元素与自闭合
<tag></tag> 与 <tag/> 在多数场景等价（是否允许还受 DTD/XSD 约束）。团队应统一风格，避免同一文件混用造成 diff 噪音。
属性必须加引号
<!-- 合法 --> <item id="1" name='widget'/> <!-- 非法：无引号 --> <item id=1/>
引号内若再含同种引号，需换另一种引号或写成实体（" / '）。
五大预定义实体（最常翻车）
| 字符 | 实体 | 何时必须 |
|---|---|---|
& |
& |
文本或属性里出现和号 |
< |
< |
文本中表示小于号 |
> |
> |
建议转义，部分位置可裸写 |
" |
" |
双引号属性值内部 |
' |
' |
单引号属性值内部 |
经典事故：URL 查询串 a=1&b=2 原样塞进元素文本，解析器在 &b 处报「实体未定义」。正确写法是 a=1&b=2，或把整段放进 CDATA（见下）。
CDATA：什么时候用、什么时候别用
<scriptDesc><![CDATA[
if (a < b && c > d) { ... }
]]></scriptDesc>
CDATA 内几乎原样保留字符（除了不能出现 ]]> 序列），适合内嵌代码片段或已含大量 < & 的文本。不要用 CDATA 逃避本该结构化的字段；安全敏感内容仍要按业务规则过滤。
声明、编码与 BOM
常见声明：
<?xml version="1.0" encoding="UTF-8"?>
声明若存在，必须在文件最前（前导空白在部分解析器也不欢迎）。编码声明与真实字节编码不一致时，中文会乱码或直接解析失败。Windows 记事本另存为带 BOM 的 UTF-8，偶发导致「首行不是声明」类错误——用十六进制或编辑器「显示不可见字符」排查。
命名空间不是装饰
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:GetPrice xmlns:m="urn:example">
<m:Item>Book</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
前缀必须绑定到 URI；复制粘贴时漏了 xmlns:，或把默认命名空间与子元素前缀搞混，常表现为「本地测试能过、对端报未知元素」。格式化能帮你看清层级，但不会自动补命名空间。
3. 用 WebUtils 逐步操作
工具页：XML 格式化与压缩。界面为左右（或上下）双栏：输入 XML / 输出结果，中间是操作与缩进设置。
3.1 美化一份挤在一起的报文
- 打开工具页，确认主题舒适（右上可切换浅色/深色）。
- 在「输入 XML」粘贴原始文本；也可点 加载示例 先熟悉输出形态（示例为带
note/items的演示树）。 - 在 缩进 下拉里选择：
- 2 空格：偏前端/部分开源项目习惯
- 4 空格（默认）：很多 Java/企业配置与 IDE 默认
- Tab：仅当仓库明确要求 Tab 时再用
- 点击 格式化 (Beautify)。
- 在「输出结果」检查层级；用 复制结果 贴回编辑器、工单或 diff 工具。
若输入为空，工具会提示先输入 XML。处理异常时会提示检查语法——此时回到「规则」与下文错误表，而不是反复点按钮。
3.2 压缩后再发出去
- 确认当前输入已是合式内容（可先美化肉眼过一遍，再粘回输入或直接对已合式文本压缩）。
- 点击 压缩 (Minify)：标签之间的空白被收掉，得到更紧的单行/紧凑串。
- 复制到 HTTP 请求体、消息中间件或需要省流量的场景。
联调建议：人对着美化版看，线上传压缩版；两边文本应用同一业务内容，避免「看的是 A、发的是改过的 B」。
3.3 推荐排查闭环
粘贴原始 XML → 格式化（选好缩进） → 扫一眼根元素 / 命名空间 / 最深一层是否对齐 → 若失败或结构怪异：按错误表改实体、闭合、引号 → 再格式化确认 → 需要传输时再压缩 → 复制前对密钥、Token、身份证号脱敏
3.4 本地处理边界（写进习惯）
- 逻辑在浏览器内完成，不上传服务器；仍不要把未脱敏的生产密钥当测试数据到处粘。
- 本工具侧重缩进美化与空白压缩，不是 XSD 校验、不是 XML 数字签名工具、也不是 SOAP UI。
- 极大文件可能受浏览器内存与文本域性能限制；数兆以上的日志建议先截取相关片段或用桌面工具。
- 格式化算法按标签边界重排空白，对极端畸形输入的报错信息不如专用解析器精细——以「能否稳定美化 + 肉眼层级」为第一目标。
4. 常见错误与处理办法
| 现象 / 报错关键词 | 常见原因 | 处理办法 |
|---|---|---|
| 标签未闭合 / unexpected end | 少写 </tag>，或剪贴时截断 |
美化后从最内层往外对括号；编辑器「匹配标签」 |
| 交叉嵌套 / not properly nested | </a> 与 </b> 顺序反了 |
保证后开先闭，像栈一样 |
| 实体引用未定义 | 文本里裸 &，或写成 &foo; 但未声明 |
改成 &；自定义实体需 DTD |
| 属性无引号 | id=1 或从 HTML 习惯抄来 |
一律 id="1" |
| 多根元素 | 拼接了两段 XML 却无总根 | 外包一层，或按多文档处理 |
| 声明不在最前 | BOM、注释或空白在 <?xml 前 |
去 BOM；声明置顶 |
| 编码乱码 | 声明 UTF-8 实为 GBK 等 | 统一另存为 UTF-8；核对通道解码 |
| 命名空间元素「丢失」 | 漏 xmlns，或前缀绑定错 URI |
对照 WSDL/XSD 补命名空间 |
含 < 的文本直接炸 |
把代码/HTML 塞进元素未转义 | < 或 CDATA |
| 格式化后「空了一截」 | 输入半截、或注释/字符串里有伪标签 | 先截取完整根元素再处理 |
| 压缩后业务异常 | 依赖了文本节点边界空白 | 对该字段改回保留空白的写法 |
Android strings.xml 资源失败 |
未转义 ' &，或占位符破坏标签 |
按平台规则转义；美化后查层级 |
| SOAP Fault 难读 | Fault 串在一行 | 美化 Body；对照 faultcode/faultstring |
Maven pom.xml 解析失败 |
标签拼写、依赖节点交叉 | 美化后核对 dependency 是否成对 |
原则：格式化失败时，先把输入缩成「最小可复现片段」（保留根与出错节点），修合式，再恢复上下文。不要在几万行里盲改。
5. 真实工作场景
场景 A：SOAP / 企业接口联调
对端返回一整行 Envelope，或本地拼装的请求被拒。做法：
- 把请求/响应贴进工具 → 格式化，确认
Header/Body层级。 - 核对命名空间 URI 是否与 WSDL 一致（前缀名可变，URI 不可乱改）。
- 检查 Body 业务节点是否多包/少包一层。
- 修完后若网关要单行，再 压缩 发出；保留一份美化版进工单附件。
场景 B：Android strings.xml / 资源 XML
翻译或合并分支后构建报 XML 解析错误。做法：
- 美化
strings.xml或 layout，看是否有未闭合的<string>/<LinearLayout>。 - 英文缩写、撇号、
&按 Android 资源规则转义（例如文本中的'、&）。 - 统一缩进（建议 4 空格或与 Android Studio 一致），减少无意义 diff。
- 不要对已签名的二进制资源做「压缩」幻想；这里美化的是源码 XML。
场景 C：Maven pom.xml / Spring 与日志配置
pom.xml 依赖没生效、logback.xml 不加载 appender。做法：
- 美化后确认每个
dependency、appender、logger开闭成对。 - 看是否把注释写进了标签名附近导致半截标签。
- 对比「能工作的环境」与「坏环境」两份美化结果（可用文本对比工具），差异通常在漏节点或命名空间。
- 提交前压缩一般没必要——源码库更在乎可读 diff；压缩留给接口报文。
场景 D：RSS/Atom、SVG 片段、导出的 Excel XML
内容团队导出 feed，或设计丢来 SVG。做法：
- 先美化看根是
rss/feed/svg哪一种。 - SVG 常含大量路径与属性，美化便于找错标签，但重新压缩前确认查看器是否对空白敏感（多数路径数据在属性里，较安全）。
- Feed 里 HTML 内容常在 CDATA 或实体中；改描述时勿弄破
]]>。
6. 提交与分享前检查清单
- [ ] 能成功 格式化 一遍，层级视觉正常
- [ ] 有且仅有一个根元素（或明确的多文档策略）
- [ ] 无交叉嵌套；空元素风格统一
- [ ] 文本与属性中的
&<已处理；必要处使用 CDATA - [ ] 声明编码与真实文件编码一致；无烦人 BOM
- [ ] 命名空间 URI 与对端契约一致
- [ ] 脱敏：Token、密码、证件号、内网地址
- [ ] 需要上线传输时再压缩；仓库内配置保持可读
- [ ] 若业务要求合法，另跑 XSD/DTD，不单靠美化
8. 团队协作中的小习惯
- 契约先行：SOAP/XML API 以 XSD/WSDL 为源，而不是以某次抓包美化结果为源。
- 统一缩进：在编辑器与 CI 里固定 2 或 4 空格，避免 Tab/空格混战。
- 评审看美化版：PR 里对配置 XML 先格式化再 diff，减少「整文件一行」无法 review。
- 示例入库：准备一份已脱敏的最小合式样例，新人联调先跑通格式再填字段。
- 日志策略：生产日志可对 XML body 截断；排障时再拿完整片段本地美化。
常见问题
格式化会改变我的业务数据吗？
正常情况下，美化与压缩只调整标签之间的空白和换行，不会改标签名、属性名与属性值文本。例外是：你的应用依赖「文本节点两端的空格」或混合内容里的精确空白——这类需求应在业务层明确 xml:space 或改数据模型，而不是指望通用格式化工具保留每一种空白策略。格式化后应用侧跑一次解析与快照对比，是最稳的确认方式。
为什么我的 XML 在浏览器里能开，工具里却怪怪的？
浏览器打开「像 XML 的页面」时，可能按 HTML 容错解析，自动补标签、忽略部分错误。XML 工具与严格解析器走的是合式规则，对交叉嵌套、裸 & 更敏感。以对端服务或标准 XML 解析器为准，不要用浏览器渲染结果当合式证明。若内容本就是 HTML，请改用 HTML 格式化工具。
需要 XSD 校验怎么办？本工具够不够？
本工具解决的是可读性与合式层面的结构暴露，不替代 XSD/DTD 校验。字段是否必填、枚举是否合法、类型是否是 xs:date，要在 IDE、CI（如 xmllint --schema）或服务端校验链完成。推荐流程：先在本工具美化并修合式 → 再跑 Schema → 最后联调业务。
压缩后对端报错，是压缩坏了吗？
多数时候不是。先把同一份压缩结果在本地再美化还原，看结构是否与原文一致；再检查 Content-Type、字符编码、是否多了 BOM、网关是否不允许某字符。若还原后与原文结构一致而对端仍挂，问题更可能在 HTTP 头、签名、时间戳或业务字段，而不是 minify 本身。若还原后结构变了，再带着最小样例排查文本节点空白。
能不能格式化几兆的巨型 XML？
可以尝试，但浏览器文本域与内存有上限，卡顿或失败都正常。实务上：用 head/grep/日志平台先切出相关 Envelope 或出错偏移附近的片段；或改用桌面编辑器、流式工具。联调排错需要的是最小复现，不是把整库导出美化一遍。
Tab 和空格哪个更好？
XML 语法本身不强制，团队一致更重要。Java/Android/Maven 生态常见 4 空格；部分前端仓库偏 2 空格；Tab 易在不同编辑器宽度下误判层级。本工具三者都支持，选与仓库 .editorconfig 一致的一项即可。不要在同一文件混用。
继续浏览
- 动手：XML 格式化与压缩
- 页面结构相近：HTML 格式化完全指南
- 接口主流数据：JSON 格式化完全指南
- 配置缩进敏感：YAML 格式化完全指南
把「合式 → 美化看清 → 再改业务 → 必要时压缩」当成固定手法后，XML 联调会从玄学变成清单题。