据此，SQL Server 2K5 在内部使用 UCS-2 。它可以在 UCS-2 中存储 UTF-16 数据（具有适当的数据类型，nchar 等），但是如果有补充字符，则将其存储为 2 个 UCS-2 字符。
这给字符串函数带来了明显的问题，即 SQL Server 将一个字符视为 2。
令我有些惊讶的是，SQL Server 基本上只能处理 UCS-2，甚至更多，以至于这在 SQL 2K8 中没有得到修复。我很欣赏其中一些角色可能并不那么常见。
除了文章中建议的函数之外，还有关于在 SQL Server 2K5 中处理（损坏的）字符串函数和 UTF-16 数据的最佳方法的任何建议。
SQL Server 2012 现在支持 UTF-16，包括代理对。请参阅http://msdn.microsoft.com/en-us/library/ms143726(v=sql.110).aspx，尤其是“补充字符”部分。
因此，解决原始问题的一种方法是采用 SQL Server 2012。
字符串函数适用于 unicode 字符串；关心字符数的人将两个字节的字符视为单个字符，而不是两个字符。唯一需要注意的是 len() 和 datalength()，它们在使用 unicode 时返回不同的值。它们当然返回正确的值 - len() 返回字符长度，datalength() 返回字节长度。由于两个字节的字符，它们恰好不同。
因此，只要您在代码中使用正确的函数，一切都应该透明地工作。
编辑：只是仔细检查了联机丛书，自 SQL Server 2000 以来，unicode 数据与字符串函数无缝协作。
编辑 2：正如评论中所指出的，SQL Server 的字符串函数不支持完整的 Unicode 字符集，因为不支持解析平面 0 之外的代理项（或者，换句话说，SQL Server 的字符串函数最多只能识别 2每个字符的字节数。）SQL Server 将正确存储和返回数据，但是任何依赖于字符计数的字符串函数都不会返回预期值。绕过此问题的最常见方法似乎是在 SQL Server 外部处理字符串，或者使用 CLR 集成添加可识别 Unicode 的字符串处理函数。
要补充的东西，我刚刚学会了艰难的方式：
如果您在 oracle 中使用“n”字段（我正在运行 9i），并通过 .net oracleclient 访问它，似乎只有参数化的 sql 可以工作......如果 N'string' unicode 前缀似乎不起作用你有一些内联sql。
我所说的“工作”是指：它将丢失基本字符集不支持的任何字符。所以在我的例子中，英文字符工作正常，西里尔字母变成问号/垃圾。
这是关于这个主题的更全面的讨论： http: //forums.oracle.com/forums/thread.jspa?threadID=376847
想知道 ORA_NCHAR_LITERAL_REPLACE 变量是否可以在连接字符串或其他东西中设置。