波仔
💻 第十一章 XML究竟是什么
📄 一句话概括

格式良好只管语法，内容合不合法得另立规矩——DTD 与 XML Schema 规定元素顺序、个数、类型，文档进系统前先过这道质检门。

📝 本节和前面几节的关系

标签能自解释了、也不撞名了，可【该有的字段有没有、值是不是数字】还没人管——本节把规矩写死。

一、格式良好 ≠ 结构合法

格式良好（Well-formed）：语法合格——标签成对、根唯一，这是解析器的门槛； 结构合法（Valid）：内容合规——该有的元素在不在、出现几次、什么类型，解析器不管； <书><书名>A</书名></书> 语法完美，但缺了价格——业务上就是不合格。

二、两种定义方式

DTD（文档类型定义）：XML 1.0 自带的老方案，写法简洁，能规定元素、属性、出现次数； XML Schema（XSD）：本身也用 XML 写，能规定数据类型（整数、日期、格式），表达力强，是现代主流； 两者都由文档在开头引用（DTD 用 DOCTYPE，Schema 用属性指明位置），校验器据此逐条比对。

三、为什么企业级交换离不开它

数据进系统前的第一道质检门：格式对不上就退回，脏数据不污染数据库； Schema 本身就是接口契约：写进文档后，双方各自开发不必来回打电话； 【⚠️ 2026 现状】金融、医疗、政务等行业标准（报文格式）通篇建立在这套校验机制上，迁移到 JSON 时也要另配一套 JSON Schema 补位——可见【结构定义】是刚需而非 XML 专属。

四、动手 Demo：手写一个迷你校验器

用几行规则模拟 Schema 校验：book 下必须恰好 1 个 title 和 1 个整数 price，四种文档逐一验收。

import xml.etree.ElementTree as ET
cases = [
    ("合格", "<book><title>A</title><price>59</price></book>"),
    ("缺 price", "<book><title>A</title></book>"),
    ("price 重复", "<book><title>A</title><price>59</price><price>60</price></book>"),
    ("price 非整数", "<book><title>A</title><price>贵</price></book>"),
]
for name, doc in cases:
    d = ET.fromstring(doc)
    kids = [e.tag for e in d]
    ok = kids.count("title") == 1 and kids.count("price") == 1 \
         and d.find("price").text.isdigit()
    print(name, "->", "合规矩" if ok else "不合规矩")

实跑输出：

--------------------------------------------------------------------
可以严格地定义 XML 的文档结构
--------------------------------------------------------------------

光有标签还不够: <书名> 可以有 0 个还是 1 个? <价格> 必须是数字还是文本?
结构和类型得写成【规矩】, 用 DTD 或 XML Schema 定义, 文档一比对就知道合不合格:

    规矩: book 下必须正好有 1 个 title 和 1 个 price(整数)

  用例             文档                                                                验收
  ----------------------------------------------------------------------------------------------
  合格             <book><title>A</title><price>59</price></book>                      合规矩
  缺 price         <book><title>A</title></book>                                       不合规矩
  price 重复       <book><title>A</title><price>59</price><price>60</price></book>     不合规矩
  price 非整数     <book><title>A</title><price>贵</price></book>                      不合规矩

    第一份合规矩, 后三份各因缺/重/类型错被拦下 ——
    严格的结构定义 = 数据进入系统前的第一道质检门。

四份文档全都【格式良好】，但只有第一份【结构合法】——两把尺子的区别一目了然。 真实校验器（lxml 等库）能直接吃 DTD／Schema 文件，原理与此处的规则比对无异。

30 秒实验

  1. 为【学生】文档写三条结构规矩（姓名 1 个、分数 1 个且为整数、年龄 0 或 1 个）。
  2. 解释：为什么格式良好的文档仍可能被系统退回？

常见误区

  1. 以为解析通过就是合格文档——解析只管语法，业务合规要靠 DTD／Schema 校验。
  2. 以为 Schema 只是文档——它同时是双方开发的接口契约，可读可校验。
自测三问（点开对答案） 1. 格式良好与结构合法的区别？ —— 前者是语法合格（解析器把关），后者是内容合规（校验器把关）。 2. DTD 与 Schema 各有什么特点？ —— DTD 老而简，Schema 用 XML 写且支持数据类型。 3. 结构定义在交换中的作用？ —— 质检门＋接口契约——脏数据进不了系统，双方开发有据可依。

相关笔记