供应商发来一份XML，打开后是一长行。格式化可以帮助看清订单、项目和数量之间的层级，却不能证明这个文件符合接收系统要求。XML“能解析”和“符合某套业务规则”是两个不同判断。
用一个订单片段理解层级
将文件粘贴到XunL XML格式化工具，确认语言是XML。可以用 <order><item sku="A-01"><qty>2</qty></item></order> 作为小例子，先观察根元素、属性和子元素，再选择缩进。
若解析报错，检查起止标签、嵌套、引号与根元素。比如item尚未关闭就结束order，属于结构问题；数量写成不允许的值，则可能需要业务校验才发现。不要把所有失败都解释成“缩进不对”。
复制过程中也要留意转义。正文里的与号等特殊字符需要按XML规则表达，不能把网页渲染出来的文本当作原始源码。若文件声明编码，应核对实际保存编码与声明一致，否则标签结构看似完整，中文仍可能在接收端出现问题。
格式正确，不等于通过XSD
工具检查XML是否格式正确，不能替代某个XSD或DTD的完整约束验证。接收方可能要求固定元素顺序、必填属性或特定代码，即使标签都配对也仍然不合格。拿到接口规范以后，应另用匹配的校验器检查。
命名空间也要保持原意。前缀看起来冗长，不代表可以随意删除；它可能参与识别元素属于哪套词汇。格式化时应关注文本、属性和结构，不为了视觉简洁重命名业务标签。
空白不是在所有文档里都可以丢弃
工具会调整缩进与换行，对只含空白的文本节点可能进行整理。普通数据交换常容易阅读，但混合文本、xml:space保留要求或其他空白敏感场景，应先确认接收方如何解释。
例如一段带行内元素的说明，空白可能影响词语间隔；签名或逐字节校验文件也不应拿排版结果替换原件。查看可以使用整理后的副本，正式传输仍要按协议保留原文与对应验证方式。
导入前，做结构与内容双重对照
保存原XML，再比较格式化副本的元素、属性与文本。检查型号前导零、单位、空值和多项明细是否还符合业务含义。与JSON转换时尤其要先定义映射，XML属性、重复元素和混合内容不一定能无损变成简单对象。
本地处理并不替代资料权限判断。含客户身份或商业记录的文件仍应按组织规则使用，导出时避免把演示和真实数据混在一起。大文件受页面大小与处理方式限制，遇到未完成先核对状态，不重复覆盖源文件。
正式接入还要在测试环境导入，确认系统实际接受与数据数量正确。排版工具不执行接口，也不证明数据已经写入成功；把格式检查、规范验证和业务导入分别记录，定位问题会更快。
为什么XML与JSON看起来字段一样，转换后仍有差异？
两种格式的数据模型不同。属性、重复元素、命名空间和文本混合需要明确规则，不能只按标签名字自动对应后就宣布无损。
文件格式化成功，为什么供应商仍说不合格？
可能违反其XSD或业务规范，或使用了不接受的值和顺序。应获取具体错误与规范版本，继续验证，而不是反复改变缩进。
个人微信：ssevening
