虽然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字符串变量视为整个文本块,就可以自由地从一个文件分配给另一个,而不会丢失任何信息.底层存储格式完全相同,即使顶层分层的抽象略有不同.
