非解析实体通过属性引用外部资源，解析器不解析其内容，仅将uri和类型传递给应用程序；2. 使用非解析实体的核心在于通过notation实现类型化引用，提供比直接使用url更丰富的语义信息；3. 与解析实体不同，非解析实体不参与xml内容解析，仅作为外部资源的强类型化指针，适用于多媒体集成、非xml文档引用及高可靠性数据交换场景。
XML的非解析实体（unparsed entity）引用，说白了，你不是直接在XML文档内容里“解析”它，而是通过一个元素的属性来“指向”它。XML解析器不会去处理这个实体的内容，它只是把这个实体的URI和它的类型信息（notation）传递给应用程序，让应用程序自己去搞定。这就像是给你的程序一个线索，告诉它“这里有个外部文件，长这样，你看着办吧。”
解决方案
要引用一个非解析实体，你需要在XML的文档类型定义（DTD）中完成两步：先声明一个“记号”（notation），再声明这个非解析实体本身。最后，在你的XML文档中，通过一个特定类型的属性来引用它。
第一步：声明一个记号（Notation）
记号是用来描述外部非XML数据格式的。它告诉应用程序这个实体是什么类型的数据（比如JPEG图片、PDF文档、或者某个特定应用的数据格式）。
这里，jpeg和pdf是记号的名字，SYSTEM "..."后面通常是MIME类型或一个外部标识符，用于帮助应用程序识别数据类型。
第二步：声明非解析实体
现在，你可以声明你的非解析实体了。声明时，你需要指定它的名字、它指向的外部资源（URI），以及它所关联的记号。
myCoverImage和annualReport是实体的名字。SYSTEM "..."指向实际的文件路径。NDATA jpeg和NDATA pdf就是将这些实体分别与前面声明的jpeg和pdf记号关联起来。
第三步：在XML文档中引用
非解析实体不能像解析实体那样用&entityName;的方式直接插入到XML内容中。它们必须作为某个元素的属性值来引用。但这个属性本身也得在DTD中声明为ENTITY类型。
这里，我们声明了一个book元素，它有两个属性coverImage和reportLink，它们的类型都是ENTITY。这意味着这些属性的值必须是已声明的非解析实体的名字。
最后，在你的XML文档中这样使用：
XML探险记 张三 ...
当XML解析器处理到coverImage是一个ENTITY类型的属性，并且其值myCoverImage是一个非解析实体。解析器不会去读取images/cover.jpg的内容，它只会将myCoverImage这个实体的URI（images/cover.jpg）和它关联的记号（jpeg）传递给处理这个XML文档的应用程序。应用程序拿到这些信息后，就知道要去加载images/cover.jpg这个JPEG图片文件并进行相应的处理。
为什么我们需要使用XML的非解析实体（Unparsed Entity）？
这其实是个挺有意思的设计。你可能会想，我直接在XML属性里写个URL不就行了吗？比如
在我看来，它的核心价值在于“类型化”和“语义丰富性”。当你只给一个URL时，应用程序并不知道这个URL指向的是图片、PDF、还是一个视频。它需要额外的逻辑去猜测或者依赖文件扩展名。而通过非解析实体，结合NDATA和NOTATION，我们是在DTD层面就给这个外部资源打上了一个明确的“类型标签”。这个标签（notation）可以非常具体，比如“这是一个JPEG图片”，或者“这是一个特定版本的CAD图纸文件”。
这使得XML文档不仅仅是数据的容器，更是外部资源管理的一个协调者。XML解析器虽然不碰外部数据本身，但它能确保你的XML文档中引用的外部资源是“合法”的，并且能向应用程序传递足够的信息，让应用程序知道如何正确地处理这些外部数据。这在那些需要严格验证和多媒体集成的场景下，比如早期的文档发布系统或者复杂的行业数据交换标准中，显得尤为重要。它提供了一种基于DTD的、强类型化的外部资源引用机制，确保了数据的一致性和可预测性。
非解析实体（Unparsed Entity）与解析实体（Parsed Entity）的核心差异在哪里？
这个问题触及了XML实体机制的本质区别。说白了，它们俩虽然都叫“实体”，但骨子里干的活儿完全不一样。
解析实体 (Parsed Entity)，顾名思义，是XML解析器会“解析”其内容的实体。当XML解析器遇到一个解析实体引用（比如©rightInfo;），它会做一件事：把这个引用替换成实体声明中定义的内容，然后继续解析替换后的内容。这就像一个文本宏，解析器会把它展开。
- 内容类型： 必须是XML解析器能够处理的文本内容，可以是内部定义的字符串，也可以是外部的XML或纯文本文件（但XML解析器会尝试将其作为XML片段来处理）。
-
引用方式： 通常使用
&entityName;的形式，出现在XML文档的内容区域或属性值中。 - 解析行为： XML解析器会读取实体内容，并将其整合到主文档的解析流中。如果内容是XML，它会被解析；如果是非XML文本，它会被视为字符数据。
非解析实体 (Unparsed Entity)，则完全是另一回事。它指向的是XML解析器“不解析”的内容，通常是外部的、非XML格式的二进制数据或者其他应用程序特有的数据。
- 内容类型： 任何外部数据，包括图片（JPEG, PNG）、音频、视频、PDF文档，或者任何不符合XML语法的文本文件。XML解析器根本不关心其内部结构。
-
引用方式： 只能通过一个属性来引用，而且这个属性必须在DTD中声明为
ENTITY类型。你不能在XML内容里直接写&myImageEntity;来引用它。 - 解析行为： XML解析器不会读取或解析非解析实体的内容。它只会识别出实体名称，获取其关联的URI和记号（notation），然后将这些信息传递给处理XML文档的应用程序。应用程序收到这些信息后，才负责根据URI去加载外部数据，并根据记号来决定如何处理这些数据（比如用图片查看器打开，或者用PDF阅读器打开）。
所以，最核心的差异在于：解析实体是XML文档的“内容扩展”，它们的内容是XML解析过程的一部分；而非解析实体则是XML文档的“外部资源引用”，它们的内容是应用程序的责任，XML解析器只是一个信息传递者。
在实际应用中，如何有效地利用XML的非解析实体？
虽然在现代XML应用中，特别是那些基于XML Schema（XSD）而非DTD的项目里，非解析实体可能不像过去那么常见，但它在特定场景下依然有着不可替代的价值。我个人觉得，理解它的设计哲学，对我们理解XML的“元数据”能力很有帮助。
1. 多媒体和二进制资源的集成： 这是非解析实体最经典、也最直观的应用场景。想象一下，你正在构建一个XML文档来描述一本电子书。这本书里有封面图片、章节插图、甚至一些嵌入的音频或视频片段。你当然可以在XML里直接写image.jpg是JPEG格式还是PNG格式，或者需要特定的处理方式，非解析实体就能派上用场。
XML实战
在这里，coverImage="cover"不仅仅指向一个文件，它还通过DTD告诉应用程序：“嘿，这个cover实体，它是一个JPEG图片！”应用程序就能据此调用正确的图像处理模块。
2. 引用非XML格式的外部文档： 除了多媒体，很多时候我们需要在XML中引用其他格式的文档，比如一份PDF报告、一个Excel电子表格、或者一个CAD设计文件。这些文件本身不是XML，也不应该被XML解析器处理。非解析实体提供了一个干净的引用机制。
第三季度预算报告已完成。
这使得你的XML文档可以作为不同类型信息的“总目录”或“清单”，而无需将所有数据都塞进XML格式。
3. 强类型化外部资源： 这点其实是前面两点的基础。非解析实体通过NDATA和NOTATION机制，为外部资源提供了一种强类型化的声明。这对于需要严格验证和互操作性的系统非常重要。例如，在航空航天或医疗领域的数据交换中，一个XML文档可能需要引用特定格式的传感器数据文件或医学影像。通过非解析实体，你可以确保引用的文件类型是符合预期的，从而提高数据的可靠性和系统的健壮性。
然而，值得一提的是，非解析实体是DTD特有的功能。在基于XML Schema（XSD）的现代XML应用中，由于XSD没有直接等同于NDATA和NOTATION的机制来声明外部非XML数据的类型，通常会采用xs:anyURI类型结合自定义属性（例如type="image/jpeg"）来达到类似的目的。但这需要应用程序自己去解析这些自定义属性，而不是像DTD那样在解析器层面就提供类型提示。所以，如果你还在使用DTD，或者处理一些老旧但依然重要的XML标准，非解析实体依然是一个非常具体且有效的解决方案。
