DTD是XML的结构规范，定义标签、嵌套、属性及内容规则；无DTD仅需well-formed，有DTD且通过验证才为valid；声明分内部（紧贴XML声明后）和外部（SYSTEM/PUBLIC引用），位置或路径错误将导致解析失败。
DTD 就是 XML 的“结构合同”
DTD 不是 XML 本身，而是一份独立的规则说明书，告诉解析器：“这个 XML 文档里，哪些标签能用、怎么嵌套、哪些属性必须有、哪些内容只能是文字”。没有 DTD，XML 只需满足基本语法（比如标签闭合、大小写敏感）就是 well-formed；加上 DTD 并通过验证，才叫 valid——也就是真正“合法”的 XML。
怎么声明 DTD：内部 vs 外部，选错就报错
常见错误是把 DTD 声明位置搞错，导致解析器直接忽略或报 Invalid DOCTYPE declaration。关键点：
- 内部 DTD 必须紧贴 XML 声明之后、根元素之前，且包裹在
]]>中，不能有空格或注释干扰 - 外部 DTD 引用必须用
SYSTEM或PUBLIC，路径要相对准确；例如：<!DOCTYPE note SYSTEM "note.dtd">，如果note.dtd不在同目录或路径写错，解析器会静默失败或报Failed to load external entity - 内部 + 外部混合用时，内部部分优先级更高，但容易引发冲突，不建议新手混用
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me</body> </note>
元素和内容模型怎么写：别把 #PCDATA 当万能兜底
#PCDATA 表示纯字符数据，但它不能和子元素共存——这是最常踩的坑。比如写成 <!ELEMENT note (#PCDATA|to|from)*> 看似灵活，实际违反 DTD 规则，因为 #PCDATA 若出现，就必须是该元素的唯一内容类型（且不能加 * 或 + 修饰）。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 只含文字：用
<!ELEMENT title (#PCDATA)> - 只含子元素：用
<!ELEMENT note (to,from,heading,body)>（顺序强制）或<!ELEMENT note ((to|from),heading?)>（可选+或选一） - 文字+子元素混合：DTD 不支持，必须改用 XSD；强行写会触发解析器拒绝
- 空元素：用
<!ELEMENT hr EMPTY>，不是<!ELEMENT hr ()>
为什么现在很少人用 DTD 了
不是它没用，而是限制太硬：不支持命名空间、没有数据类型（比如无法约束 age 必须是整数）、语法非 XML 风格（难读难维护）。现代项目基本用 XSD 替代，但 DTD 仍有不可替代的场景：
- 遗留系统接口文档仍以 DTD 发布，你得能看懂并生成对应 XML
- 嵌入式设备或轻量解析器（如某些 C 库）只支持 DTD 验证
- 快速原型验证，比如手动写个
config.dtd约束配置文件结构，比搭 XSD 工具链快得多
真正麻烦的不是语法，而是当你要表达“这个字段可选但一旦出现就得是邮箱格式”——DTD 做不到，这时候就得承认：它只是个结构草图，不是契约全书。
