在 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 及更高版本。

在 SQL Server 中处理补充字符时，请记住以下几点：

因为代理项对被视为两个独立的 Unicode 码位，所以 nvarchar(n) 的大小必须是 2，以容纳单一补充字符(换言之，代理项对所需的空间)。

不支持在元数据(例如，数据库对象的名称)中使用补充字符。一般来说，元数据中使用的文本必须符合标识符的规则。有关详细信息，请参阅《SQL Server 2005 联机丛书》中的标识符。

标准字符串操作不能识别补充字符。SUBSTRING(nvarchar(2),1,1) 之类的操作仅返回补充字符代理项对的高代理项。LEN 函数为遇到的每个补充字符返回两个字符的计数：一个计数对应高代理项，一个计数对应低代理项。不过，可以创建能够识别补充字符的自定义函数。《SQL Server 2005 联机丛书》的可识别补充字符的字符串操作中的 StringManipulate 示例演示了如何创建此类函数。

对补充字符的排序和搜索行为可能会随排序规则的不同而发生变化。在新的 90_and BIN2 排序规则中，可以正确地对补充字符进行比较，而在早期排序规则和标准 Windows 排序规则中，所有补充字符的比较都视同所有其他补充字符的比较。例如，默认的日语和朝鲜语排序规则不处理补充字符，而 Japanese_90 和 Korean_90 则会进行处理。

有关 Unicode 码位、设计可识别代理项的应用程序的最佳实践以及处理 Unicode 数据的详细信息，请参阅循序渐进全球化：支持 Unicode。有关 Unicode 标准中支持的字符范围的信息，请参阅 Unicode 技术标准 #18 中关于 Unicode 正则表达式的部分。

组合字符

“组合字符”是与其他字符一起使用以修改其外观或含义的字符。组合的字符会形成单一字形。例如，欧洲语言中使用的音调符号便是组合字符，可以作为字符加音调符号的形式或预构成字符的形式出现。

在 .NET Framework 中，将组合字符的顺序视为文本元素，即显示为单个字符的文本单元。文本元素有别于排序元素。例如，在某些排序规则中，字母“CH”不是组合字符;它们是两个独立的文本元素，但可以将它们视为一个排序元素。

注意 SQL 函数的做法有所不同，它通常将组合字符与补充字符一视同仁：它们将组合字符作为两个独立的 Unicode 码位进行处理。有关如何创建能够更准确地对补充字符进行计数和比较的自定义函数的示例，请参阅 StringManipulate 示例。