将 C# 字符串 (UTF-16) 存储在 SQL Server nvarchar (UCS-2) 列中会产生什么后果？

SQL Server 似乎使用 UnicodeUCS-2，一个2字节的定长字符编码，对于nchar/nvarchar字段。同时，C# 使用 UnicodeUTF-16其字符串的编码（注意：有些人不认为 UCS-2 是 Unicode，但它在 Unicode 子集 0-0xFFFF 中对所有与 UTF-16 相同的代码点进行编码，就 SQL Server 而言，这是就字符串而言，它本身支持的最接近“Unicode”的东西。）

虽然 UCS-2 在基本多语言平面 (BMP) 中编码与 UTF-16 相同的基本代码点，但它没有保留 UTF-16 允许代理项对的某些位模式。

如果我将 C# 字符串写入 SQL Servernvarchar(UCS-2) 字段并读回，这总是返回相同的结果吗？

看起来，虽然 UTF-16 是 UCS-2 的超集，因为 UTF-16 编码了更多代码点（例如高于 0xFFFF），但它实际上是 UCS-2 在 2 字节级别的子集，因为它是更具限制性。

为了回答我自己的问题，我怀疑如果我的 C# 字符串包含高于 0xFFFF 的代码点（由字符对表示），这些代码点将在数据库中很好地存储和检索，但如果我尝试在数据库中操作它们（例如也许调用 TOUPPER 或尝试清空所有其他字符），那么我可能会在稍后显示字符串时遇到一些问题...除非 SQL Server 具有确认代理项对并有效处理的函数nchar/nvarchar字符串为 UTF-16。

这真的有点胡说八道。

首先是相似之处

• SQL服务器nchar/nvarchar/ntext数据类型将文本存储为 2 字节字符的字符串。它并不真正关心您在其中放入什么，直到您进行搜索和排序（然后它使用适当的 Unicode 排序规则序列）。
• The CLR String数据类型还将文本存储为 2 字节的字符串Chars。它也并不真正关心你在其中放入什么，直到你进行搜索和排序（然后它使用适当的特定于文化的方法）。

现在的差异

• .NET 允许您通过以下方式访问 CLR 字符串中的实际 Unicode 代码点字符串信息 http://msdn.microsoft.com/en-us/library/system.globalization.stringinfo.aspx class.
• .NET 对以各种编码方式对文本数据进行编码和解码提供了大量支持。当将任意字节流转换为String，它总是将字符串编码为 UTF-16（具有完整的多语言平面支持）。

简而言之，只要将 CLR 和 SQL Server 字符串变量视为整个文本块，那么您可以自由地从一个分配到另一个，而不会丢失信息。尽管顶层的抽象略有不同，但底层存储格式完全相同。