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 存储有几个缺点：