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

似乎sql Server对nchar / nvarchar字段使用Unicode UCS-2,一个2字节的固定长度字符编码.同时,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.

解决方法

这真是一点点软糖.

首先是相似之处

> sql Server nchar / nvarchar / ntext数据类型将文本存储为2字节字符的字符串.在你进行搜索和排序之前,它并不关心你放入它们的内容(然后它使用适当的Unicode整理顺序).
> CLR String数据类型还将文本存储为2字节Chars的字符串.在你进行搜索和排序(然后它使用适当的特定于文化的方法)之前,它也不会真正关心你输入的内容.

现在的差异

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

简而言之,只要将CLR和sql Server字符串变量视为整个文本块,就可以自由地从一个文件分配给另一个,而不会丢失任何信息.底层存储格式完全相同,即使顶层分层的抽象略有不同.