我正在尝试真正理解unicode标准，并且正在阅读xml spec所在的位置：
Char :: =＃x9 | #xA | #xD | [＃x20-＃xD7FF] | [＃xE000-＃xFFFD] | [＃x10000-＃x10FFFF] / *任何Unicode字符，不包括代理块，FFFE和FFFF。 * /
现在我有几个问题：
感谢您的澄清！
答案 0 :(得分：2)
代理区块是什么？
U+D800到U+DFFF范围内的Unicode代码点，包含在内，专门用作UTF-16代理，在任何其他情况下都是非法的。
它们是指示4字节代码点的UTF-16代码吗？
是
#xXXXX在这里是指代码点还是UTF-16编码值？
实际的Unicode代码点。考虑到Char的定义包括值＆gt; #xFFFF，其中个别编码的UTF-16值不能超过。 UTF是代码点值的字节编码方案。 XML规范是根据代码点而不是编码来编写的。 XML文档可以编码在＆＃34;编码＆＃34;中指定的任何字符集中。出于存储和传输的目的，XML prolog的属性，但实际的XML内容是根据未编码的代码点处理的。
如果它引用了代码点并且我对代理块的理解是正确的：为什么这里提到了代理块？
代理代码点是保留的，不允许在任何文本内容中显示为未编码。 Char定义只是强制执行该规则。
为什么非字符如＆＃34; U + FFFE＆＃34;定义为unicode标准的一部分？至于我的理解，字节顺序检测（以及处理灵活大小的代码字）取决于编码。
因为编码并不总是提前知道，并且可能必须动态检测。 U+FFFE用作BOM标记，以帮助实现这一目标。早期版本的Unicode允许U+FFFE用作或 BOM或文本内容中的实际非破坏空格字符。这有时会导致模棱两可。因此，较新版本的Unicode仅将U+FFFE严格保留为BOM，而不间断的间距由U+2060 WORD JOINER处理，以避免任何歧义。
话虽如此，在XML的上下文中，在任何文本内容中使用U+FFFE都没有意义。整个文档在特定的字符集中编码，所使用的任何BOM都必须出现在XML序言之前。 XML规范定义了XML文档本身之外的BOM处理和字符集检测。这就是为什么Char定义排除了U+FFFE。
U+FFFF是保留的，并不打算在实际中用于实际内容。这就是Char定义排除它的原因。
所以基本上Char定义允许所有Unicode代码点减去受限制的代码点。