荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: playboy (沉睡太平洋底), 信区: Program
标 题: 可扩展标记语言(XML) 1.0(5)
发信站: BBS 荔园晨风站 (Wed May 31 22:02:01 2000), 转信
4.2 实体声明(Entity Declaration)
实体以如下方式声明：
实体声明
[70] EntityDecl ::= GEDecl | PEDecl
[71] GEDecl ::= '<!ENTITY' S Name S EntityDef S? '>'
[72] PEDecl ::= '<!ENTITY' S '%' S Name S PEDef S? '>'
[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)
[74] PEDef ::= EntityValue | ExternalID
实体引用中的Name标识了该实体;对于未析实体，ENTITY或ENTITIES属
性的值标识了该实体。如果同一实体被声明了不止一次，绑定第一个
声明。由用户选择，如果实体被多次声明，XML处理器可以给出警告。
4.2.1 内部实体(Internal Entities)
如果实体定义是一个EntityValue，被定义的实体被称为内部实体。
内部实体没有单独的物理存储对象，实体的内容在声明中给出。注意
字面实体值中一些实体和字符引用的处理可能要求产生正确的置换文
本：参见"4.5 内部置换文本的构造"。
内部实体是已析实体。
内部实体声明的例子：
<!ENTITY Pub-Status "This is a pre-release of the
specification.">
4.2.2 外部实体(External Entities)
如果实体不是内部的，那么它是一个外部实体，声明如下：
外部实体声明
[75] ExternalID ::= 'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76] NDataDecl ::= S 'NDATA' S Name [ VC: 声明符号 ]
如果有NDataDecl，那么这是一个通用未析实体;否则它是一个已析实体。
有效性约束: 声明符号
Name必须与符号的名字相匹配。
SystemLiteral被称为该实体的系统标识符。这是一个URI，可以用于
查找此实体。注意井号(#)和URI中常用的片断标识符形式上而言不是
URI的一部分；如果一个片断标识符作为系统标识符的部分给出，XML
处理器可以给出一个错误。除非在本规范范围之外另外给出(如，一
个特殊DTD定义的专用XML元素类型，或一个特殊应用规范中定义的处
理指令)，相对URI指相对于实体声明所在资源的位置。因此，一个URI
可能是相对于文档实体，或相对于包含外部DTD子集的实体，或相对于
其他一些外部参数实体。
XML处理器处理URI中的非ASCII字符时，将UTF-8中的字符用一个或多个
字节表示，然后将这些字符用URI转义机制转义(即，将每个字节转换成
%HH，其中HH是字节值的十六进制符号)。
除了系统标识符之外，外部标识符还可以包含公共标识符。试图查找实
体内容的XML处理器可以用公共标识符试着产生一个可选URI。如果处理
器无法做到这一点，它必须使用系统常量中定义的URI。在试着匹配之
前，公共标识符中所有空白字符串必须被规范为tch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif >
4.3 已析实体(Parsed Entities)
4.3.1 文本声明(Text Declaration)
每个外部已析实体可以以文本声明作为开始。
文本声明
[77] TextDecl ::= '<?xml' VersionInfo? EncodingDecl S? '?>'
文本声明必须以字面形式给出，而不能使用已析实体的引用。文本声明只
能在外部已析实体的开头出现，不允许在其他任何地方出现。
4.3.2 格式良好的已析实体(Well-Formed Parsed Entities)
如果文档实体匹配document产生式，那么它是格式良好的。如果外部通用
已析实体匹配extParsedEnt产生式，那么它是格式良好的。如果外部参数
实体匹配extPE产生式，那么它是格式良好的。
格式良好的外部已析实体
[78] extParsedEnt ::= TextDecl? content
[79] extPE ::= TextDecl? extSubsetDecl
如果内部普通已析实体的置换文本匹配content产生式，那么它是格式良
好的。根据定义，所有内部的参数实体都是格式良好的。
实体符合格式要求的一个结果是XML文档的逻辑和物理结构是严格嵌套的
;起始标记，结束标记，空元素标记，元素，注释，处理指令，字符引用，
或实体引用都不能在一个实体中开始而在另一个实体中结束。
4.3.3 实体中的字符编码(Character Encoding in Entities)
XML文档中的每个外部已析实体都可以对其字符采用一种不同的编码方案。
所有XML处理器必须能读编码为UTF-8或UTF-16的实体。
以UTF-16编码的实体必须以ISO/IEC 10646增补E和Unicode附录B(零宽度不
间断空格字符，#xFEFF)中所描述的字节次序标记(Byte Order Mark)开头。
这是一个编码签名，即不是XML文档中标记的一部分，也不是XML文档字符
数据的一部分。XML处理器必须能用此字符区分UTF-8编码和UTF-16编码的文档。
虽然XML处理器只被要求能读取UTF-8和UTF-16编码的实体，普遍认为国际
上还有其他编码方案。有时可能想让XML处理器读取以那些编码方案编码的
实体。以不同与UTF-8和UTF-16的编码方案存储的实体必须以包含编码声
明的文本声明开头：
编码声明
[80] EncodingDecl ::= S 'encoding' Eq ('"' EncName '"' | "'"
EncName "'" )
[81] EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* /* 编码方案
的名字只包含拉丁字母 */
在文档实体中，编码声明是XML声明的一部分。EncName是所用编码方案的
名字。
在一个编码声明中，值"UTF-8"，"UTF-16"，"ISO-10646-UCS-2"和
"ISO-10646-UCS-4"应该用于表示Unicode或ISO/IEC 10646中的各种不
同编码和变换方案，值"ISO-8859-1"，"ISO-8859-2"，... "ISO-8859-9"
应该用于表示ISO 8859的各个部分，而值"ISO-2022-JP"，"Shift_JIS"和
"EUC-JP"应该用于表示JIS X-0208-1997的各种编码。XML处理器可以识别
其他编码方案;建议对于在Internet Assigned Numbers Authority [IANA]
注册的字符编码方案(以字符集(charset)的方式)，除了以上所列的之外，
引用时应使用其注册名。注意这些注册名定义为大小写敏感，因此欲与之匹
配的处理器要以大小写敏感的方式进行匹配。
在缺少外部传输协议(如HTTP或MIME)所提供的信息时，以下情况均是错误：
XML处理器接收到的实体的编码方案与实体所含编码声明中指出的编码方案
不同，编码声明不在外部实体的开头，既不以字节次序标记开头也不以编码
声明开头的实体使用了不同于UTF-8的编码。注意因为ASCII是UTF-8的一个
子集，以普通ASCII编码的实体不严格需要编码声明。
当XML处理遇到的实体使用了它不能处理的编码时，是一个严重错误。
编码声明的例子：
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>
4.4 XML处理器对实体和引用的处理
下表汇总了字符引用，实体引用，和对未析实体的调用可以出现的上下文，
以及每种情况下XML处理器要求的动作。最左边一列的标签记指明了识别时的上下文：
内容中的引用
可以在元素的起始标记之后，结束标记之前的任何地方以引用形式出现，
对应于非终结符content。
属性值中的引用
可以在起始标记内的属性值中，或属性声明内的缺省值中以引用形式出现
;对应于非终结符AttValue。
作为属性值
可以以Name而不是以引用的形式出现，作为声明为ENTITY类型的属性的值，
或可以作为声明为ENTITIES类型的属性值中的以空白分隔的记号之一。
实体值中的引用
可以在参数中或内部实体的实体声明内的字面实体值中以引用形式出现;
对应于非终结符EntityValue。
DTD中的引用
可以在DTD的内部或外部子集中以引用形式出现，但须在EntityValue和
AttValue之外。
实体类型 字符
参数 内部通用 外部已析通用 未析
内容中的引用 不被识别 被包含 进行验证时被包含 被禁止 被包含
属性值中的引用 不被识别 作为常量被包含 被禁止 被禁止 被包含
作为属性值 不被识别 被禁止 被禁止 通知 不被识别
实体值中的引用 作为常量被包含 不处理 不处理 被禁止 被包含
DTD中的引用 作为PE被包含 被禁止 被禁止 被禁止 被禁止
4.4.1 不被识别(Not Recognized)
在DTD之外，百分号字符%没有特殊含义;因此在DTD中的参数实体引用在
content中不被当成标记识别。类似地，除非未析实体的名字出现在已适
当声明的属性的值中，否则它们不被识别。
4.4.2 被包含(Included)
当一个实体的置换文本代替引用,被当成引用文档的一部分一样被查找和
处理时，称此实体被包含。其置换文本可以包含字符数据和标记(不包括
参数实体)，其中标记必须以通常的方式识别，淀器识别出一个对已析实体的引用，为了验
证该文档，处理器必
须包含此实体的置换文本。如果实体是外部的，而处理器不试图验证该
XML文档，那么处理器可以，但不是必须，包含此实体的置换文本。如果
一个不验证的解析器不包含此置换文本，它必须通知应用它识别出但没
有读取此实体。
这条规范基于这样一个共识：由SGML和XML的实体机制提供的起初设计
用于支持模块化创作的自动包含不一定适合于其他应用，尤其是文档
浏览。例如，当浏览器遇到一个外部已析实体引用时，可能选择用可
视方式表示其存在但只在被请求时才查找它进行显示。
4.4.4 被禁止(Forbidden)
以下情况被禁止，并构成一个严重错误：
n 出现对未析实体的引用。
n 在DTD中出现任何字符或通用实体引用，除非它们出现在
EntityValue或AttValue中。
n 属性值中出现对外部实体的引用。
4.4.5 被包含在常量中(Included in Literal)
当实体引用出现在属性值中或参数实体引用出现在字面实体值中时，
它们的置换文本代替引用被当成引用文档的一部分一样被查找和处
理，但是置换文本中的单双引号总是被当成正常的数据字符而不会
结束此常量。例如，下面的例子是格式良好的：
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said &YN;" >
而这个例子不是：
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>
4.4.6 通知(Notify)
当未析实体名字作为记号在声明为ENTITY或ENTITIES类型的属性的值
中出现时，进行验证的处理器必须将此实体和它的相关符号的系统和
公共(如果有的话)标识符通知给应用。
4.4.7 不处理(Bypassed)
当实体声明内一个通用兵实体引用出现在EntityValue中时，它不被
处理，保持不变。
4.4.8 作为PE被包含(Included as PE)
和外部已析实体一样，参数实体只需在进行验证时被包含。当参数实
体引用在DTD中被识别并被包含时，它的置换文本被前后各加上一个
空格字符;其目的在于强制参数实体的置换文本在DTD中包含完整的的
语法记号。
4.5 内部实体置换文本的构建(Construction of Internal Entity)
在讨论内部实体的处理时，区分两种形式的实体值是有帮助的。字面
实体值(literal entity value)是实际出现在实体声明中用引号括起
的字符串。对应于非终结符EntityValue。置换文本(replacement text)
是置换了字符引用和参数实体引用后的实体内容。
在内部实体声明(EntityValue)中给出的字面实体值可以包括字符引用
，参数实体引用和通用实体引用。这些引用必须被整个包含于字面实体
值中。如前述方式被包含的实际置换文本必须包含所有被引用的参数实
体的置换文本，同时在字面实体值中必须包含所有代替字符引用的字符
。但通用实体的引用必须保持不变，不被展开。例如，如果有以下的声明：
<!ENTITY % pub "Éditions Gallimard" >
<!ENTITY rights "All rights reserved" >
<!ENTITY book "La Peste: Albert Camus, © 1947 %pub;. &rights;" >
那么实体"book"的置换文本为：
La Peste: Albert Camus, ?nbsp;1947 ditions Gallimard. &rights;
一旦引用"&book;"出现在文档的内容或属性值中时，通用实体引用"&rights;"
应该被展开。
这些简单的规则将可能会有复杂的相互作用;参见"D. 实体和字符引用的展开
"中对一个难的例子的详细讨论。
4.6 预定义实体(Predefined Entities)
实体和字符引用都可以用于转义左尖括号，"and"号(&)和其他定界符。
通用实体集合(amp，lt，gt，apos，quot)专门用于此目的。也可以使用
数值字符引用; 一旦被识别，它们立即被展开，同时它们必须被当成字
符数据，因此数值字符引用"<"和"&"可以用于转义出现在字符
数据中的<和&。
不管这些实体是否被声明，所有的XML处理器必须能识别它们。出于互操
作性考虑，如其他实体一样，有效的XML文档应该在使用这些实体前先声
明它们。如果声明的话，这些实体必须被声明为内部实体，其置换文本
是被转义的单个字符或指向这个字符的字符引用。如下所示。
<!ENTITY lt "&#60;">
<!ENTITY gt ">">
<!ENTITY amp "&#38;">
<!ENTITY apos "'">
<!ENTITY quot """>
注意在"lt"和"amp"的声明中，<和&被两次转义，这是为了满足实体置
换的格式要求。
4.7 符号声明(Notation Declarations)
符号用名字标识了未析实体的格式，具有符号属性的元素的格式以及处
理指令所针对的应用的格式。
符号声明赋予符号一个名字用于实体,属性表声明和属性说明中，同时也
给出了一个符号的外部标识符使得XML处理器或它的客户应用可以定位能
以给定符号处理数据的助理应用。
符号声明
[82] NotationDecl ::= '<!NOTATION' S Name S (ExternalID |理器必须向应用提供任
何在属性值中，属性定义中或实体声明
中定义或引用的符号的名字和外部标识符。它们还可以将外部标识符
解析成系统标识符，文档名，或是应用调用相应处理器处理给定符号
格式的数据的所需的其他信息。(但如果XML处理器或应用所运行的系
统中没有处理XML文档声明和引用的符号的相应应用的情况，不是一个
错误。)
4.8 文档实体(Document Entity)
文档实体(document entity)是实体树的根和XML处理器的处理起点。
本规范没有规定XML如何定位文档实体;与其他实体不同，文档实体没
有名字，而且可以完全不带任何标识地出现在处理器的输入流中。
5. 一致性(Conformance)
5.1 进行验证和不进行验证的处理器(Validating and Non-Validating Processors)
合乎规范的XML处理器可以分为两类：进行验证的和不进行验证的。
进行验证和不进行验证的处理器都必须报告在文档实体的内容中和
任何其他它们读到的已析实体中对格式约束的违反。
进行验证的处理器必须报告违反DTD声明中所述约束的情况以及不满
足本规范中给出的有效性约束的情况。要完成这一点，进行验证的
XML处理器必须读取和处理整个DTD和所有在文档中引用的外部已析实体。
不进行验证的处理器只被要求检查文档实体和整个内部DTD子集的格
式。虽然它们不被要求检查文档的有效性，但它们必须处理它们读取
的所有内部DTD子集和参数实体中的声明，直到遇到第一个没有读取
的参数实体的引用;也就是说，它们必须根据这些声明中的信息规范
化属性值，包含内部实体的置换文本，并提供缺省属性值。它们在遇
到第一个没有读取的参数实体的引用后，不应处理其后的实体声明或
属性表声明，因为此实体中包含的声明可能覆盖前面的声明。
5.2 使用XML处理器
进行验证的处理器的行为是高度可预测的;它必须读取文档的所有部
分，报告所有对格式和有效性的违反。对一个不进行验证的处理器
的要求要低一点;它不需要读取文档实体以外的任何文档部分。这对
XML的处理器的用户而言可能会有两个重要的影响：
n 某些格式错误，尤其是那些要求读取外部实体的，可能不会
被不进行验证的处理器检测到。例如称为声明实体，已析实体和无递
归的约束，以及"4.4 XML处理器对实体和引用的处理"中描述为被禁
止的一些情况。
n 取决于处理器是否读取参数和外部实体，从处理器传给应用
的信息可能会有所不同。例如，不进行验证的处理器可能不规范化属
性值，不包含内部实体的置换文本，或不提供缺省属性值，这些动作
要求先读取外部或参数实体中的声明。
为了使不同XML处理器间的互操作有最大的可靠性，使用不进行验证的
处理器的应用不应依赖于不要求这些处理器具备的动作。那些要求使用
如缺省值或在外部实体中声明内部实体等功能的应用应该使用进行验证
的XML处理器。
6. 符号(Notation)
本规范中XML的正式句法用一种简单的扩展巴科斯范式
(Extended Backus-Naur Form，EBNF)给出。句法中的每一条规则定义
了一个记号，形式如下：
symbol ::= expression
如果记号用正则表达式定义，则它以大写字母开头，否则以小写字母开头
。字符串(literal strings)用引号括起。
在规则右边的表达式中，以下表达式用于匹配一个或多个字符的字符串：
#xN
N是一个十六进制的整数，当ISO/IEC 10646中某个字符的规范(UCS-4)代
码值作为无符号二进制数与N相等时，此表达式匹配这个字符。#xN中的前
导0没有意义，在相应的代码值中的前导0的个数则由所用字符编码方案决
定，对XML没有意义。
[a-zA-Z]， [#xN-#xN]
与其值在指定范围内的任何字符相匹配(含界，inclusive)。
[^a-z]， [^#xN-#xN]
与其值在指定范围之外的任何字符相匹配。
[^abc]， [^#xN#xN#xN]
与任何不在给定字符集内的字符相匹配。
"string"
与双引号中字符串相匹配。
'string'
与单引号中字符串相匹配。
这些符号可以按下列方式组合，以匹配更复杂的模式，其中A和B表示简
单表达式：
(expression)
expression被当成一个单元，可以如本表描述进行组合。
A?
与零个或一个A相匹配，即A可选。
A B
与A后跟B的模式相匹配。
A | B
与AB之一相匹配，但不同时匹配。
A - B
与任何匹配A但不匹配B的字符串相匹配。
A+
与一个或多个A相匹配。
A*
与零个或多个A相匹配。
其他在产生式中使用的符号有：
/* ... */
注释
[ wfc: ... ]
格式约束;用名字标识一个对与某个产生式相关联的格式良好的文档的约束。
[ vc: ... ]
有效性约束;用名字标识一个对与某个产生式相关联的有效文档的约束。
附录
A. 参考文献
A.1 标准参考文献
IANA
(Internet Assigned Numbers Authority) Official Names for Character
Sets， ed. Keld Simonsen et al. See ftp://ftp.isi.edu/in-notes/iana/
assignments/character-sets.
IETF RFC 1766
IETF (Internet Engineering Task Force). RFC 1766: Tags
for the Identification of Languages， ed. H. Alvestrand. 1995.
ISO 639
(International Organization for Standardization). ISO
639:1988 (E). Code for the representation of names of
languages. [Geneva]: International Organization for Standardization， 1988.
ISO 3166
(International Organization for Standardization). ISO
3166-1:1997 (E). Codes for the representation of names
of countries and their subdivisions -- Part 1: Country
codes [Geneva]: International Organization for Standardization， 1997.
ISO/IEC 10646
ISO (International Organization for Standardization).
ISO/IEC 10646-1993 (E). Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane.
[Geneva]: International Organization for Standardization，
1993 (plus amendments AM 1 through AM 7).
Unicode
The Unicode Consortium. The Unicode Standard，
Version 2.0. Reading， Mass.: Addison-Wesley Developers
Press， 1996.
A.2 其他参考文献
Aho/Ullman
Aho， Alfred V., Ravi Sethi， and Jeffrey D. Ullman.
Compilers: Principles, Techniques, and Tools. Reading:
Addison-Wesley, 1986, rpt. corr. 1988.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform
Resource Identifiers (URI): Generic Syntax and Semantics.
1997. (Work in progress; see updates to RFC1738.)
Br黦gemann-Klein
Br黦gemann-Klein, Anne. Regular Expressions into Finite
Automata. Extended abstract in I. Simon, Hrsg., LATIN
1992, S. 97-98. Springer-Verlag, Berlin 1992. Full Version
in Theoretical Computer Science 120: 197-213, 1993.
Br黦gemann-Klein and Wood
Br黦gemann-Klein, Anne, and Derick Wood. Deterministic
Regular Languages. Universit Freiburg, Institut
Informatik, Bericht 38, Oktober 1991.
Clark
James Clark. Comparison of SGML and XML.
See http://www.w3.org/TR/NOTE-sgml-xml-971215.
IETF RFC1738
IETF (Internet Engineering Task Force). RFC 1738:
Uniform Resource Locators (URL), ed. T. Berners-Lee,
L. Masinter, M. McCahill. 1994.
IETF RFC1808
IETF (Internet Engineering Task Force). RFC 1808:
Relative Uniform Resource Locators, ed. R. Fielding. 1995.
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats.
1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E).
Information processing -- Text and Office Systems -- Standard Generalized
Markup Language (SGML). First edition -- 1986-10-15. [Geneva]: International
Organization for
Standardization, 1986.
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E).
Information technology -- Hypermedia/Time-based Structuring Language (HyTime).
[Geneva]: International Organization for Standardization, 1992. Extended
Facilities Annexe.
[Geneva]: International Organization for Standardization, 1996.
B. 字符的分类(Character Classes)
根据Unicode标准中定义的特征，字符被分为基类字符(其中包括没有变音符的拉丁字母)，
表意字符和组合字符(其中包括大多数的变音符);这些类合起来组成了字母类。数字和扩展
符(extender)也各自被分成类。
字符
[84] Letter ::= BaseChar | Ideographic
[85] BaseChar ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] |
[#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] |
[#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] |
[#x01F4-#x01F5] | [#x01FA-#x0217]
| [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C |
[#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE
| #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C]
| [#x045E-#x0481]
| [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] |
[#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586]
| [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] |
[#x0671-#x06B7] |
[#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6]
| [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990]
| [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] |
[#x09DC-#x09DD] |
[#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] |
[#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0 | #x0A8D | [#x0A8F-#x0A91] |
[#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD
| #x0AE0 | [#x0B05-#x0B0C] |
[#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] |
[#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A]
| [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F]
| [#x0BA3-#x0BA4] |
[#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] |
[#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] |
[#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] |
[#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] |
#x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28]
| [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33]
| [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A |
#x0E8D |
[#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 |
[#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD |
[#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] |
[#x10D0-#x10F6] | #x1100 |
[#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112]
| #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] |
#x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E]
| [#x1172-#x1173] |
#x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA
| [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9]
| [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] |
[#x1F50-#x1F57] |
#x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC]
| #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB]
| [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 |
[#x212A-#x212B] | #x212E |
[#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] |
[#xAC00-#xD7A3]
[86] Ideographic ::= [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87] CombiningChar ::= [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] |
[#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2]
| #x05C4 | [#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] |
[#x06E0-#x06E4] |
[#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C]
| #x094D | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC |
#x09BE | #x09BF | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7
| [#x09E2-#x09E3] |
#x0A02 | #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] |
[#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5]
| [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43]
| [#x0B47-#x0B48] |
[#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] |
[#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44]
| [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] |
[#x0CBE-#x0CC4] |
[#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] |
[#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 |
[#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC]
| [#x0EC8-#x0ECD] |
[#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84]
| [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7]
| #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
[88] Digit ::= [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] |
[#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] |
[#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] |
[#x0D66-#x0D6F] | [#x0E50-#x0E59] |
[#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89] Extender ::= #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 |
#x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]
在此定义的字符类可以从Unicode字符库中如下导出：
n 名字的起始字符必须属于Ll, Lu, Lo, Lt, Nl中的一类。
n 除了起始字符之外的命名字符必须属于Mc，Me，Mn，Lm或Nd中
的一类。
n 兼容区(即代码大于#xF900，小于#xFFFE的字符)中的字符不允
许在XML名字中出现。
n 不允许出现具有字体或兼容性分解的字符(即数据库中第5项有
以"<"开始的"compatibility formatting tag"的字符 )。
n 下列字符被当成名字起始字符而非名字字符，因为特性文件中
将它们归于字母类： [#x02BB-#x02C1]，#x0559，#x06E5，#x06E6。
n 不允许出现字符#x20DD-#x20E0(与Unicode的5.14节保持一致)。
n 字符#x00B7被分为扩展符，因为特性文件中对它是这么标识的。
n 字符#x0387被当成一个命名字符，因为#x00B7是它的等价规范形式。
n 字符':'和'_'可以作为名字起始字符。
n 字符'-'和'.'可以作为命名字符。
C. XML和SGML(非标准)
XML被设计为SGML的一个子集，表现在每一个有效的XML文档应该也是一
个合乎规范的SGML文档。对XML在SGML之外对文档所加的限制的详细讨论
参见[Clark]。
D. 实体和字符引用的展开(非标准)
本附录中举例说明了在 "4.4 XML处理器对实体和引用的处理"一节中规定
的实体和字符引用的识别和展开的次序。
如果声明包含在DTD中
<!ENTITY example "<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;).</p>" >
那么XML处理器将在对实体声明进行解析时识别出字符引用，并
在将下面的字符串存为实体"example"的值前解析这些字符引用:
<p>An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).</p>
文档中对"&example;"的引用会导致对文本的重新分析，此时元素
"p"的起始和结束标记被识别，三个引用被识别和展开，其结果是
一个包含下面内容(所有数据，无定界符或标记)的"p"元素：
An ampersand (&) may be escaped
numerically (&) or with a general entity
(&).
一个更复杂的例子可以完整地说明这些规则和它们的作用。在下
面的例子中，行号仅仅是为了方便说明。
1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '%zz;'>
5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>
这个例子会导致下列动作：
n 在第4行，对字符37的引用会被立即展开，参数实体
"xx"以值"%zz;"存于记号表中。因为置换文本不被再次扫描，
对参数实体"zz"的引用不会被识别。(而且如果它被识别的话
则是一个错误，因为"zz"还没有被声明。)
n 在第5行，字符引用"<"被立即展开，而参数实体
"zz"以置换文本"<!ENTITY tricky "error-prone" >"被存储，
此置换文本是一个格式良好的实体声明。
n 在第6行，对"xx"的引用被识别，"xx"的置换文本(即
"%zz;")被解析。对"zz"的引用随后被识别，它的置换文本
("<!ENTITY tricky "error-prone" >")被解析。此时通用实
体"tricky"被声明，它的置换文本是"error-prone"。
n 在第8行，对通用实体"tricky"的引用被识别，并被
展开，因此"test"元素的全部内容为一个自我描述的(不合语法
)字符串。此例表明了一种有错误倾向的方法。
E. 确定型内容模型(非标准)
出于兼容性考虑，要求元素类型声明中的内容模型是确定型的。
SGML要求内容模型是确定型的(它称为"无歧义的"); 用SGML系统
生成的XML处理器可能会把非确定型内容模型标为错误。
例如，内容模型((b, c) | (b, d))是非确定型的，因为给定一个
初始雒置魅菲ヅ洹＝馕銎鞑恍枰蚯翱雌浜蟮哪谌?
。c或d都能被接受。
更正式的说法：使用Aho，Sethi和Ullman所著[Aho/Ullman]3.9节
中的标准算法3.5，可以从内容模型构造出一个有限状态自动机。
在很多这样的算法中，对应正则表达式中的每一个位置(即正则表
达式的语法树中的每个叶子节点)，都构造一个随集(follow set)；
如果任一位置的随集中不止一个后继位置被标为同一元素类型时，
那么此内容模型出错，并且可以被报为错误。
存在将许多但不是所有非确定型内容模型自动规约为等价的确定型
模型的算法；参见Br黦gemann-Klein 1991 [Br黦gemann-Klein].
F. 字符编码的自动检测(非标准)
XML编码声明在实体中以内部标签的方式工作，用于指出使用了何种
字符编码。然而，在XML处理器能读取这个内部标签前，显然它必须
知道当前使用的是何种字符编码－而这正是此内部标签要试图指出
的。通常情况下，这是一种无法解决的情况。但在XML中并非如此，
因为XML在两个方面对这种情形作出了限制：假定每一种实现只支持
一个有限的字符编码集，并且，为了使得正常情况下自动检测每个实
体中所用字符编码成为可能，限制了XML编码声明的位置和内容。同
时，很多情况下除了XML数据流本身之外，另外还有可用的信息源。
根据XML实体交给处理器时没有或有任何的附带(外部)信息，可以区
分出两种情况。我们先考虑第一种情况。
因为每一个非UTF-8或UTF-16格式的XML实体必须以XML编码声明开头
，其开始的几个字符必须为'<?xml'，任何合乎规范的处理器可以在两
到四个八位组的输入后，检测出适用于下列何种情况。在读这张表时
，知道这些是有帮助的：在UCS-4中，'<'是"#x0000003C"，'?'是
"#x0000003F"，UTF-16数据流的字节次序标记要求为"#xFEFF"。
n 00 00 00 3C: UCS-4，big-endian编码的计算机(1234次序)
n 3C 00 00 00: UCS-4，little-endian编码的计算机(4321次序)
n 00 00 3C 00: UCS-4，异常的八位组次序(2143)
n 00 3C 00 00: UCS-4，异常的八位组次序(3412)
n FE FF: UTF-16，big-endian
n FF FE: UTF-16，little-endian
n 00 3C 00 3F: UTF-16，big-endian，无字节次序标记(因此
严格说来出错)
n 3C 00 3F 00: UTF-16，little-endian，无字节次序标记(因
此严格说来出错)
n 3C 3F 78 6D: UTF-8，ISO 646，ASCII，ISO 8859的一些部分
，Shift-JIS，EUC，及其他任何7位，8位或混合宽度的能保证ASCII字
符有它们正常的位置，宽度，取值的编码;具体其中哪一个适用需读取实
际的编码声明来检测确定，但因为所有这些编码中ASCII字符的位模式
相同，所以能够可靠地读取编码声明本身。
n 4C 6F A7 94: EBCDIC(在某些变种中，完整的编码声明必须能
用于确定使用了哪一代码页)
n 其他：无编码声明的UTF-8，或是数据流已损坏，不完整或被
包含在某种外层数据中。
这种层次的自动检测足以用于读取XML编码声明和解析字符编码标识符
。字符编码标识符仍然是必须的，它用于区分编码方案集中的单个成
员(例如从8859中区分出UTF-8，8859各个部分间的相互区分，以及
区分所用的特定EBCDIC代码页，等等)。
因为编码声明的内容限于ASCII字符，一旦处理器检测到使用的是哪
一个编码方案集，它能够可靠地读取整个编码声明。因为在实际中，
所有广泛使用的字符编码都可以归于上述种类中，XML编码声明保证了
可靠的内嵌(in-band)字符编码标注，即使是在操作系统或传输协议
级的外部信息源并不可靠的情况下。
一旦处理器检测到所用的字符编码，它就可以作出合适的动作，或是
针对每种情况调用单独的输入例程，或是对每个输入的字符调用版本
合适的转换函数。
和任何自标注(self-labeling)的系统一样，一旦任何软件改变了实体
的字符集或其编码而没有相应修改编码声明的话，XML的编码声明将无
法工作。字符编码方案的实现者必须小心，以保证用于标注实体的内部
和外部信息的正确性。
第二种可能的情况是XML实体有附带的信息，如在一些文档系统和网络
协议中。当具有多个信息源时，它们间的相对优先级和首选冲突处理方
法必须在传输XML的高层协议中给出。例如，内部标签和外部文档头中的
MIME类型标签的相对优先级应该是定义text/xml和application/xml MIME
类型的RFC文档的一部分。然而出于互操作性考虑，建议使用下列规则。
如果XML实体是在一个文档中，用字节次序标记和编码声明PI(如果有的
话)来确定字符编码。所有其他信息源和推断都仅仅用于错误恢复。
如果XML实体传递时标为text/xml MIME类型，那么MIME类型的charset
参数决定了字符编码方法;所有其他信息源和推断都仅仅用于错误恢复。
如果XML实体传递时标为application/xml MIME类型，那么用字节次序
标记和编码声明PI(如果有的话)来确定字符编码。所有其他信息源和推
断都仅仅用于错误恢复。
这些规则只适用于缺少协议级文档时的情况；特别是，当相关RFC中定
义了这些text/xml和application/xml MIME类型时，RFC中的建议取代
这些规则。
G. W3C XML工作组(非正式)
本规范由W3C XML工作组(WG)完成并批准发表。工作组批准了本规范并
不一定表示工作组的所有成员一致同意本规范。现有和以前的XML工作组成员包括：
Jon Bosak, Sun (Chair); James Clark (Technical Lead);
Tim Bray, Textuality and Netscape (XML Co-editor); Jean Paoli,
Microsoft (XML Co-editor); C. M. Sperberg-McQueen, U. of Ill.
(XML Co-editor); Dan Connolly, W3C (W3C Liaison); Paula Angerstein,
Texcel; Steve DeRose, INSO; Dave Hollander, HP; Eliot Kimber,
ISOGEN; Eve Maler, ArborText; Tom Magliery, NCSA; Murray Maloney,
Muzmo and Grif; Makoto Murata, Fuji Xerox Information Systems;
Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe,
SoftQuad; John Tigue, DataChannel
--
※ 来源:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.90]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店