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

Question

似乎SQL Server 对字段使用Unicode UCS-2,一个2字节的固定长度字符编码nchar/nvarchar.同时,C#对其字符串使用Unicode UTF-16编码(注意:有些人不认为UCS-2是Unicode,但它在Unicode子集0-0xFFFF中编码与UTF-16相同的所有代码点,并且就SQL Server而言,就字符串而言,它本身支持的"Unicode"最接近它.)

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

如果我将C#字符串写入SQL Server nvarchar(UCS-2)字段并将其读回,这是否会返回相同的结果？

看来尽管UTF-16是UCS-2的意义上的超集UTF-16编码更多的代码点(例如上述0xFFFF)时,它实际上是UCS-2的2字节级的子集,因为它是限制性更强.

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

Answer 1

这真的有点胡说八道。

首先是相似之处

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

现在的差异

• .NET 允许您通过StringInfo类访问 CLR 字符串中的实际 Unicode 代码点。
• .NET 对以各种编码方式对文本数据进行编码和解码提供了大量支持。将任意字节流转换为 时String，它始终将字符串编码为 UTF-16（具有完整的多语言平面支持）。

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