字符编码

　　Unicode 的工作方式是，为每个字符提供一个唯一的码位，该码位与平台、程序或语言无关。支持 Unicode 的程序可以处理任何语言的数据。因为其设计宗旨是涵盖世界上所有语言的所有字符，所以不需要让不同的代码页来处理不同的字符集。

　　因为所有 Unicode 系统都统一使用相同的位模式来表示所有字符，所以从一个系统转到另一个系统时，不会出现字符转换不正确的问题。

　　Unicode 码位及它们所代表的字符与用于可视呈现的“字形”是分开的。ISO 标准 (ISO/IEC 9541-1) 将字形定义为“与具体设计无关的可识别抽象图形符号”。因此，一个字符不必总是由相同的字形乃至唯一的字形来表示。所选择的字体决定将使用什么字形来表示 特定码位或一系列码位。

　　有关详细信息，请参阅 Unicode Consortium 网站。

　　编码

　　Unicode 将码位映射到字符，但实际上并不指定数据在内存、数据库或网页中的表示方式。这便是 Unicode 数据编码发挥作用的地方。有许多不同的 Unicode 编码。多半选择一种 Unicode 数据类型即可，不必为这些细节操心;不过，在以下情况下了解编码有重要意义：

　　•应对可能以不同方式对 Unicode 进行编码的应用程序时

　　•向其他平台(非 Microsoft Windows)或 Web 服务器发送数据时

　　•导入其他编码的数据或将数据导出为其他编码时

　　Unicode 标准定义了其单一字符集的多种编码：UTF-7、UTF-8、UTF-16 和 UTF-32。本部分对这些常见的编码进行说明：

　　•UCS-2

　　•UTF-16

　　•UTF-8

　　SQL Server 通常以 UCS-2 编码方案存储 Unicode。不过，许多客户端以另一种编码方案(如 UTF-8)来处理 Unicode。这种情况在基于 Web 的应用程序中经常出现。在 Microsoft Visual Basic 应用程序中，字符串以 UCS-2 编码方案来处理。因此，不需要显式地指定 Visual Basic 应用程序与 SQL Server 实例之间的编码方案转换。

　　SQL Server 2005 使用 Unicode (UTF-16) 来对 XML 数据进行编码。类型为 xml 的列中的数据以内部格式存储为二进制大型对象 (BLOB)，以支持 XML 模型特征，如文档顺序和递归结构。因此，从服务器检索的 XML 数据会以 UTF-16 格式输出;如果想要为检索的数据使用其他编码，则应用程序必须对所检索的 UTF-16 数据执行必要的转换。《SQL Server 2005 联机丛书》中的 XML 最佳实践提供了如何为从 varchar(max) 列中检索的 XML 数据显式地声明编码的示例。

　　使用 UTF-16 编码是因为它可以处理 2 字节或 4 字节字符，并且处理是依照面向字节的协议进行的。这些特性使得 UTF-16 非常适合于遍历使用不同编码和字节排序系统的不同计算机。因为 XML 数据通常在网络上得到广泛共享，所以在数据库中及在将 XML 数据导出到客户端时保持默认的 UTF-16 存储格式是有意义的。

　　UCS-2

　　UCS-2 是 UTF-16 的前身。UCS-2 与 UTF-16 的不同之处是，UCS-2 是一种固定长度编码，它以 16 位值(2 个字节)表示所有字符，因此不支持补充字符。UCS-2 常与 UTF-16 发生混淆，UTF-16 用于在内部表示 Microsoft Windows 操作系统(Windows NT、Windows 2000、Windows XP 和 Windows CE)中的文本，但 UCS-2 受到的限制更多。

　　注意 有关在 Windows 操作系统中使用 Unicode 的最新信息，请参阅 Microsoft Developer Network (MSDN) 库中的 Unicode。建议 Windows 应用程序在内部使用 UTF-16，仅在必须使用其他格式时再通过接口作为“薄层”的一部分进行转换。

　　在 Microsoft SQL Server 2000 和 Microsoft SQL Server 2005 中以 Unicode 存储的信息使用 UCS-2 编码，无论使用的是哪个字符，该编码都将每个字符存储为两个字节。因此，对拉丁语字母“A”的处理方式与对西里尔文字母 Sha ())、希伯来语字母 Lamed (ì)、泰米尔语字母 Rra (?) 或日语平假名字母 E (‚¦) 的处理方式是相同的。每个字母都有一个唯一的码位(对于上述字母，码位分别为 U+0041、U+0248、U+05DC、U+0BB1 和 U+3048，每个四位十六进制数表示 UCS-2 使用的那两个字节)。

　　因为 UCS-2 只考虑了 65,536 个不同码位的编码，其本身无法处理补充字符，只能将补充字符视为未定义的 Unicode 代理项字符，这些字符组对后定义补充字符。不过，SQL Server 可以存储补充字符而不会有字符丢失或损坏的风险。通过创建自定义 CLR 函数，可以扩展 SQL Server 处理代理项对的能力。有关处理代理项对和补充字符的详细信息，请参阅本文后面的“补充字符和代理项对”部分。

　　注意 补充字符定义为“具有补充码位的 Unicode 编码字符”。补充码位的范围在 U+10000 和 U+10FFFF 之间。

　　UTF-8

　　UTF-8 是一种旨在以与计算机上的字节排序无关的方式来处理 Unicode 数据的编码方案。在处理 ASCII 及其他要求使用 8 位编码的面向字节的系统(例如，必须覆盖大量使用不同编码、不同字节顺序和不同语言的计算机的邮件服务器)时，UTF-8 会有帮助。尽管 SQL Server 2005 不以 UTF-8 格式存储数据，但它仍支持使用 UTF-8 来处理可扩展标记语言 (XML) 数据。有关详细信息，请参阅本文的 SQL Server 2005 中的 XML 支持部分。

　　其他数据库系统(例如，Oracle 和 Sybase SQL Server)通过使用 UTF-8 存储来支持 Unicode。视服务器的实现方式而定，从技术上讲实现数据库引擎可能比较容易，因为服务器上的现有文本管理代码在一次处理一个字节的数据时并不要求进 行重大更改。不过，在 Windows 环境中，UTF-8 存储有几个缺点：

　　•组件对象模型 (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 之外，大部分平面中的字符仍未定义，但可以用来表示补充字符。补充字符主要用于历史和古典文学典籍，以协助处理中文、韩语和日语丰富文学遗产的编码。补充字符还包括古代北欧文字以及其他具有历史意义的文字、音乐符号等。

　　在 UTF-16 中，一对码位(称为代理项对)用于表示主字符集 (BMP) 之外的字符。代理项区是 Unicode 中从 U+D800 到 U+DFFF 的一个范围，其中包含 1,024 个低代理项值和 1,024 个高代理项值。高代理项(范围 U+D800 到 U+DBFF)和低代理项(范围 U+DC00 到 U+DFFF)相结合可以表示超过一百万个可能的字符。

　　仅具有代理项对的一半将视为无效;高代理项必须始终跟有低代理项，才算有效。这使得代理项的检查变为范围检查，它比检测 DBCS(双字节字符系统)字符所需的相当复杂的规则要简单。

　　尽管 UCS-2 不能识别代理项，但 SQL Server 2000 和 SQL Server 2005 都可以存储代理项对。SQL Server 将代理项对视为两个未定义的 Unicode 字符而非单一字符。此类应用程序通常称为“代理中性”或“代理安全”，这意味着它们不具备固有的与数据进行交互的能力，但至少可以做到存储的数据不会丢 失。

　　作为对照，“能够识别代理项的”应用程序不仅可以识别代理项对，还可以处理组合字符和需要特殊处理的其他字符。 编写良好的应用程序可以检测到分开的代理项，并且只通过几个子例程就可以将它们重新组合。可以识别代理项的应用程序包括 Microsoft Word 和 Internet Explorer 5 及更高版本。