可扩展标记语言(XML)1.0(第二版)(六)

翻译|其它|编辑:郝浩|2005-04-01 13:52:00.000|阅读 1616 次

概述:

# 界面/图表报表/文档/IDE等千款热门软控件火热销售中 >>

E. 确定型内容模型(非正式)

如 3.2.1 元素型内容中所述,元素类型声明中的内容模型要求是确定型的。这个要求是出于和 SGML 的兼容性考虑(SGML 称为"无歧义的");用 SGML 系统生成的 XML 处理器可能会把非确定型内容模型标为错误。

例如,内容模型((b, c) | (b, d))是非确定型的,因为给定一个初始 b,XML 处理器没有在向前看以知道 b 后是什么元素之前,无法知道匹配模型中的哪个 b。在这种情况下,两个对 b 的引用可以简化成单个的引用,使得模型成为(b,(c | d))。此时初始的 b 只和内容模型中的一个名字明确匹配。处理器不需要向前看其后的内容。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 实体交给处理器时没有或有任何的附带(外部)信息,可以区分出两种情况。我们先考虑第一种情况。

F.1 无外部编码信息时的检测

因为每一个没有外部编码信息且非 UTF-8 或 UTF-16 编码的 XML 实体必须以 XML 编码声明开头,其开始的几个字符必须为 '<?xml',任何合乎规范的处理器可以在两到四个八位组的输入后,检测出适用于下列何种情况。在读这张表时,知道这些是有帮助的:在 UCS-4 中,'<' 是 "#x0000003C",'?' 是 "#x0000003F",UTF-16 数据流的字节次序标记要求为 "#xFEFF"。记法 ## 用于表示任意的字节值,但两个连续的 ## 不能同时为 00。

有字节次序标记:

00 00 FE FF UCS-4,big-endian 编码的计算机(1234次序)
FF FE 00 00 UCS-4,little-endian 编码的计算机(4321次序)
00 00 FF FE UCS-4,异常的八位组次序(2143)
FE FF 00 00 UCS-4,异常的八位组次序(3412)
FE FF ## ## UTF-16, big-endian
FF FE ## ## UTF-16, little-endian
EF BB BF UTF-8

无字节次序标记:
 

00 00 00 3C UCS-4 或其他 32 位码元的编码,同时 ASCII 字符的码值就是 ASCII 值,次序分别为 big-endian(1234),little-endian(4321)和两种异常的字节次序(2143 和 3412)。必须读取编码声明以确定使用的是 或其他被支持的 32 位编码。
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F UTF-16BE,big-endian 的 ISO-10646-UCS-2 或其他 16 位码元的 big-endian 的编码,其中 ASCII 字符的码值就是 ASCII (必须读取编码声明以确定使用的是哪一种)
3C 00 3F 00 UTF-16LE,little-endian 的 ISO-10646-UCS-2 或其他 16 位码元的 little-endian 的编码,其中 ASCII 字符的码值就是 ASCII (必须读取编码声明以确定使用的是哪一种)
3C 3F 78 6D UTF-8,ISO 646,ASCII,ISO 8859 的某些部分,Shift-JIS,EUC,或任何其他 7 位,8 位或混合宽度的编码,这些编码必须保证 ASCII 字符有它们正常的位置,宽度和取值;具体其中哪一个适用需读取实际的编码声明来检测确定,但是因为所有这些编码中的 ASCII 字符使用了相同的位模式,所以能够可靠地读取编码声明本身
4C 6F A7 94 EBCDIC (其中的某些情况;必须读取完整的编码声明以确定使用的是哪一个代码页)
其他 没有编码声明则为 UTF-8,否则不是数据流被标错了(没有所需的编码声明),被损坏了,是不完整的,就是被包含在某种外层数据中

注:

在上述不需要读取编码声明来确定所用编码的情况下,4.3.3 节仍然要求读取可能出现的编码声明,并检查其中的编码名称是否与实体实际的编码相一致。同时,现在不要求有编码声明的情况有可能会因为新的字符编码方案的发明而变得必须使用编码声明用于确定所用的编码。

这种层次的自动检测足以用于读取 XML 编码声明和分析字符编码标识符。字符编码标识符仍然是必须的,它用于区分编码方案集中的单个成员(例如从 8859 中区分出 UTF-8,8859 各个部分间的相互区分,以及区分所用的特定 EBCDIC 代码页,等等)。

因为编码声明的内容限于 ASCII 字符集中的字符(不管怎样编码),一旦处理器检测到使用的是哪一个编码方案集,它能够可靠地读取整个编码声明。因为在实际中,所有广泛使用的字符编码都可以归于上述种类中,XML 编码声明保证了可靠的内嵌(in-band)字符编码标注,即使是在操作系统或传输协议级的外部信息源并不可靠的情况下。象 UTF-7 那样重用了 ASCII 编码值的字符编码方案有可能无法可靠地被检测。

一旦处理器检测到所用的字符编码,它就可以作出合适的动作,或是针对每种情况调用单独的输入例程,或是对每个输入的字符调用版本合适的转换函数。

和任何自标注(self-labeling)的系统一样,一旦任何软件改变了实体的字符集或其编码而没有相应修改编码声明的话,XML的编码声明将无法工作。字符编码方案的实现者必须小心仔细,以保证用于标注实体的内部和外部信息的正确性。

F.2 外部编码信息的优先级

第二种可能的情况是 XML 实体有附带的信息,如在一些文件系统和网络协议中。当具有多个信息源时,它们间的相对优先级和首选冲突处理方法必须在传输 XML 的高层协议中给出。具体请参考 [IETF RFC 2376] 或其后续标准,其中定义了 text/xml 和 application/xml MIME 类型并且提供了一些有用的指导。然而出于互操作性考虑,建议使用下列规则。

如果 XML 实体是在一个文件中,用字节次序标记和编码声明 PI(如果有的话)来确定字符编码。
 

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, SoftQuad, Grif SA, Muzmo and Veo Systems
     
  • MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
     
  • Joel Nava, Adobe
     
  • Conleth O'Connell, Vignette
     
  • Peter Sharpe, SoftQuad
     
  • John Tigue, DataChannel

     

H W3C XML 核心工作组(非正式)
 

本规范的第二版由 W3C XML 核心工作组完成。在此版本发表时此工作组的成员包括:

  • Paula Angerstein, Vignette
     
  • Daniel Austin, Ask Jeeves
     
  • Tim Boland
     
  • Allen Brown, Microsoft
     
  • Dan Connolly, W3C (Staff Contact)
     
  • John Cowan, Reuters Limited
     
  • John Evdemon, XMLSolutions Corporation
     
  • Paul Grosso, Arbortext (Co-Chair)
     
  • Arnaud Le Hors, IBM (Co-Chair)
     
  • Eve Maler, Sun Microsystems (Second Edition Editor)
     
  • Jonathan Marsh, Microsoft
     
  • MURATA Makoto (FAMILY Given), IBM
     
  • Mark Needleman, Data Research Associates
     
  • David Orchard, Jamcracker
     
  • Lew Shannon, NCR
     
  • Richard Tobin, University of Edinburgh
     
  • Daniel Veillard, W3C
     
  • Dan Vint, Lexica
     
  • Norman Walsh, Sun Microsystems
     
  • Fran鏾is Yergeau, Alis Technologies (Errata List Editor)
     
  • Kongyi Zhou, Oracle
     

I 文档制作说明(非正式)

第二版用 XMLspec DTD 书写(见其文档)。其 HTML 版本用 xmlspec.xsldiffspec.xsl,和 REC-xml-2e.xsl XSLT 样式表制成。其 PDF 版本使用 html2ps 和一个 distiller 程序制成。


标签:

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@evget.com


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP