SQL Server 2005 中的 Unicode 支持(3)

组件对象模型 (COM) 仅在其 API 和接口中支持 UTF-16/UCS-2。因此，如果数据以 UTF-8 格式存储，必须始终进行转换。仅在使用 COM 时会出现此问题;SQL Server 数据库引擎通常不会调用 COM 接口。

Windows XP 和 Windows Server 2003 的内核均采用 Unicode。UTF-16 是 Windows 2000、Windows XP 和 Windows Server 2003 的标准编码。不过，Windows 2000、Windows XP 和 Windows Server 2003 都可以识别 UTF-8。因此，在数据库中使用 UTF-8 存储格式需要进行许多额外的转换。通常，转换所需的额外资源不会影响 SQL Server 数据库引擎，但可能会影响许多客户端操作。

执行许多字符串操作时，UTF-8 的速度可能都会较慢。排序、比较及几乎任何字符串操作的速度可能都会下降，因为字符的宽度不固定。

UTF-8 往往需要 2 个以上的字节，并且增加的大小会占用更多的磁盘和内存空间。

尽管有这些缺点，但考虑到 XML 已成为一项重要的 Internet 通信标准这一事实，您可能希望考虑将默认编码设置为 UTF-8。 注意 早期版本的 Oracle 和 Java 也使用 UCS-2，它们无法识别代理项。Oracle Corporation 在 Oracle 7 中开始支持将 Unicode 作为数据库字符集。Oracle 目前支持两种 Unicode 数据存储方法：(1) UTF-8 作为 CHAR 和 VARCHAR2 字符数据类型以及所有 SQL 名称和文字的编码;(2) UTF-16 用于 NCHAR、NVARCHAR 和 NCLOB Unicode 数据类型的存储。Oracle 允许同时使用这两种方法。

UTF-16

UTF-16 是 Microsoft 的编码标准，在 Windows 操作系统中 UTF-16 是一个扩展，其设计用途是处理附加的 1,048,576 个字符。对代理项范围的需要甚至在 Unicode 2.0 发布之前就已意识到了，因为事实清楚地表明，仅使用 65,536 个字符无法实现 Unicode 的用单一码位表示每种语言的每个字符的目标。例如，某些语言(例如，中文)至少需要那样多的字符才能对历史和文学表意文字等字符进行编码，这些字符尽管很少使用，但对出版和学术有着重要意义。下一部分提供了有关代理项范围的详细信息。 UTF-16 与 UCS-2 类似，也使用 little endian 字节顺序，在 Windows 上执行的任何操作都遵循该顺序。Little endian(与 big endian 相对)意味着低位字节存储在内存中的最低地址处。在操作系统级别字节的排序有重要意义。SQL Server 以及运行在 Windows 平台上的其他应用程序都使用 little endian 字节顺序。因此，0x1234 这样的十六进制词语以 0x34 0x12 形式存储在内存中。在某些情况下，可能需要显式地反转字节顺序以正确地读取字符的编码。SQL Server Integration Services 提供了用于转换 Unicode 文本字节顺序的函数。有关详细信息，请参阅本文的 SQL Server 2005 Integration Services 部分。

补充字符和代理项对

Microsoft Windows 通常使用 UTF-16 来表示字符数据。使用 16 位允许表示 65,536 个唯一字符。不过，即使是这么多的字符也不足以涵盖人类语言中使用的所有符号。在 UTF-16 中，某些码位紧接着前两个字节使用另一个码位，以将该字符定义为代理项范围的一部分。

在 Unicode 标准中，有 16 个字符“平面”，具有定义多达 1,114,112 个字符的潜力。平面 0(或称基本多语言块 (BMP))可以表示世界上的大部分书面文字、出版中使用的字符、数学和技术符号、几何图形、所有 100 级 Zapf Dingbat 以及标点符号。 在 BMP 之外，大部分平面中的字符仍未定义，但可以用来表示补充字符。补充字符主要用于历史和古典文学典籍，以协助处理中文、韩语和日语丰富文学遗产的编码。补充字符还包括古代北欧文字以及其他具有历史意义的文字、音乐符号等。