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

Question

SQL Server 似乎使用 Unicode UCS-2(一种 2 字节固定长度字符编码)来表示 nchar/nvarchar字段。同时，C#对其字符串使用 Unicode UTF-16 编码(注意:有些人不认为 UCS-2 是 Unicode，但它在 Unicode 中对所有与 UTF-16 相同的代码点进行编码)子集 0-0xFFFF，就 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

这确实有点胡扯。

首先是相似之处

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

现在有区别

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

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