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

各系统语言平台数据库都不同，却都读得懂 XML——把数据装进 XML 这个【中间信封】，跨系统交换就有了与平台无关的普通话。

📝 本节和前面几节的关系

含义能写清楚了，本节看它的第一号用途：让互不相识的系统交换数据。

一、交换的难点：两边不一样

A 系统用关系表、B 系统用对象，语言不同、平台不同、字段名也不同； 直接对接就得写 N×N 套转换程序——系统一多就爆炸； 解法是统一中间格式：各方只写【自家 ↔ 中间格式】这一对转换，两边一劳永逸。

二、XML 为什么能当中立格式

与平台无关：纯文本，任何系统、任何语言都能读写； 自描述：标签带着含义（11.4），对方不用查文档也能猜个大概； 可校验：配结构定义（11.7）先验一遍，垃圾数据进不了系统； 有工具：各语言标准库都自带解析器（11.8），不必自己造轮子。

三、典型场景

企业内部系统之间、企业与银行／海关之间（报税、报关）大量用 XML 传单据； 老一代 Web 服务（SOAP）把请求响应都包成 XML 信封来回传； 【⚠️ 2026 现状】新式 Web 接口多数改用 JSON（更短更省解析），但企业级数据交换仍以 XML 为主力——校验严格、行业标准积累深是它的护城河。

四、动手 Demo：表 → XML → 表：一次完整交换

把一张二维表打包成 XML 信封，再从信封解析回原始数据，验证一次往返不丢信息。

import xml.etree.ElementTree as ET
rows = [("张三", 92), ("李四", 85)]
body = "".join("<学生><姓名>%s</姓名><分数>%d</分数></学生>" % r for r in rows)
xml = "<班级>%s</班级>" % body
back = [(e.find("姓名").text, int(e.find("分数").text))
        for e in ET.fromstring(xml)]
print("一致?", back == rows)

实跑输出：

--------------------------------------------------------------------
XML 是通用的数据交换格式
--------------------------------------------------------------------

A 系统存的是表, B 系统要的是对象——怎么传? 用 XML 当【中间信封】:

    原始数据(二维表):
        张三  92
        李四  85

    转成 XML 信封(此处分行显示, 实际是一行长串):
        <班级>
            <学生><姓名>张三</姓名><分数>92</分数></学生>
            <学生><姓名>李四</姓名><分数>85</分数></学生>
        </班级>

    对面解析回来: [('张三', 92), ('李四', 85)]
    和原始数据一致? True

    各系统语言、平台、数据库都不一样, 但都读得懂 XML ——
    与平台无关的【普通话】, 这是数据交换格式的核心价值。

来回一趟数据严格相等（True）——只要两边都按同一份标签约定读写，交换就是无损的。 实际系统还会附上 XML Schema 做校验，防止对端漏字段或写错类型。

30 秒实验

  1. 把一段 JSON 数据改写成等价的 XML，比较两者写法的长短。
  2. 想一想：为什么银行、海关这类系统更偏爱 XML 而不是 JSON？

常见误区

  1. 以为 XML 是唯一的数据交换格式——JSON、YAML、Protobuf 各有地盘，XML 只是其中资历最深的一个。
  2. 以为随便定义标签就能对接——交换双方必须共享同一份标签约定（最好配结构定义）。
自测三问（点开对答案） 1. 数据交换为什么需要中间格式？ —— 避免 N×N 套两两转换，各方只需对接统一格式。 2. XML 当中立格式的四个优势？ —— 平台无关、自描述、可校验、工具齐备。 3. 2026 现状下 XML 的稳固地盘？ —— 企业数据交换、文档格式、配置文件——Web 公开接口多已转向 JSON。

相关笔记