粘贴 XML 内容,一键检查语法是否正确,并可以顺手整理排版。
XML 全称 eXtensible Markup Language,直译是"可扩展标记语言",顾名思义,它的标签不是固定的一套,而是可以由使用者自己按需要定义,这和标签集合早已固定的 HTML 完全不同。它不依赖任何特定平台,文档本身既能被人读懂,也能被程序解析。现实中很常见的应用包括 SOAP 这类老牌 Web 服务协议、Maven 和 Android 的项目配置文件、RSS 订阅源与网站地图(Sitemap)、以及 Office Open XML 这类办公文档格式。正因为语法规则足够严格,XML 长期被当作系统之间交换数据的"通用语言",数据完整性有保障,这也是它历经多年仍未被完全取代的原因。
任何一份 XML 文档都要以声明行开头,注明版本和编码方式。所有标签必须成对出现、正确闭合,标签名区分大小写,这一点和 HTML 的宽松处理很不一样。属性的值必须用引号包起来,元素之间的嵌套关系要严格对应,不能出现交叉闭合。一份文档只能有一个根元素,这是最容易被忽略却最常引发报错的一条。遇到 &、<、> 这类特殊字符,必须转成对应的实体写法,比如 &、<、>,直接写进去会破坏文档结构。注释用 <!-- --> 包裹,如果确实需要在内容里保留大段未转义的特殊字符,可以放进 CDATA 区块处理。
一份 XML 只要标签都闭合、嵌套关系正确、属性写法没问题,就可以称之为"格式良好"(well-formed),这是解析器能顺利读取的最低门槛。但"合法"(valid)要求更高一层——文档还得符合某个 DTD(文档类型定义)或者 XML Schema 里规定的具体结构。DTD 负责描述元素和属性该长什么样,XML Schema 则更进一步,能定义精确的数据类型和各种约束条件。换句话说,格式良好只保证"能被读",合法则保证"符合业务逻辑该有的样子"。大多数对外接口只要求格式良好就够了,但企业内部的核心系统往往会强制要求文档必须通过 Schema 校验,才允许进入下一步处理流程。
标签名对不上是最高频的错误——开始标签和结束标签的名字必须一字不差,包括大小写。属性值忘记加引号也很常见,写代码时容易图省事漏掉。特殊字符没做转义直接写进文本里,比如把 < 原样留在内容中,会被解析器误判为新标签的开始。嵌套顺序写反,或者一份文档里出现了不止一个根元素,也都是常见的翻车点。手动一行行找错误很费时间,借助校验工具能立刻定位到具体是第几行、第几列出的问题,连带给出出错原因,排查效率会高很多。
XML 和 JSON 是目前数据交换里最常见的两套格式。XML 规则更严格、结构也更复杂,配合 Schema 能做很强的校验;它可以用属性和元素两种方式承载元数据,还支持注释和命名空间,表达能力更丰富。JSON 则更简洁轻量,天然贴合 JavaScript 的数据结构,解析速度快、可读性也好,只是想做严格校验的话需要单独引入 JSON Schema。实际项目中,REST 接口大多首选 JSON,而老一代的 SOAP 服务基本都是 XML 的天下。偏文档型、层级复杂的数据用 XML 更顺手,偏结构化、追求轻量传输的场景 JSON 往往更合适,最终还是要看项目本身的技术栈和生态。
XML 命名空间的作用是防止元素名字"撞车"——通过 xmlns 属性声明,再用前缀区分来自不同词汇表的同名元素,当一份文档里要混用多套 XML 规范时(比如同时出现 XHTML、SVG、MathML),命名空间几乎是必需品。XML Schema(常简称 XSD)是一门专门用来定义文档结构的强大语言,能约束数据类型(字符串、整数、日期等)、设置约束条件(最小长度、匹配模式等),还支持复合类型和继承关系。相比更早期的 DTD,XSD 表达能力更强,而且本身就是用 XML 语法写的,校验起来也更方便,是大型系统里保障数据质量和互通性的核心工具之一。