无法在 NVARCHAR 字段中存储特定的 Unicode 代码点/字符
Cannot store particular Unicode code points / characters in NVARCHAR fields
我正在使用 SQL Server 2017 进行一些测试。
我正在尝试将任意 Unicode 代码点存储在 NVARCHAR 列中。
我尝试过不同的归类。
我对Unicode的BMP平面的普通字符没问题
对于更奇特的符号，例如，如果我尝试存储“”字符 (U+1D33)，则会发生以下情况：
- 如果我在 Management Studio 中执行此操作，我只会看到臭名昭著的方形符号。但是 Management Studio 有正确的字体，因为我可以将它粘贴到查询编辑器中。
- 如果我从 Visual Studio 发送文本，我在 Management Studio 中看到的值是“??”，这也是我在执行查询后从 Visual Studio 检索到的值。
我的理解是，对于非补充字符排序规则，不应正确解释 UCS-2 子集之外的字符，因为 NCHAR 字段限制为 2 个字节。
但是，我在数据库级别和列级别尝试了 Latin1_General_100_CS_AS_KS_WS_SC，但它似乎也不起作用。
有什么想法吗？
谢谢
我无法重现任何数据丢失或编码问题。我可以复制一个正方形，在复制时变成 </code>。这可能是由用于在 SSMS 网格中显示结果的 <em> 字体 </em> 或 Visual Studio 调试器 windows.</p> 引起的
<p>SQL 服务器和 Windows 使用 UTF16 已经有一段时间了，而不是 UCS-2。不过很少有字体支持完整的 UTF16 范围。 </p>
<p>当我在 SSMS 中尝试此操作时：</p>
<pre><code>create table #tc(name nvarchar(20));
insert into #tc values (N'');
select name,len(name),DATALENGTH(name) from #tc;
我在格子里看到了一个正方形，2和4。这意味着该字符已正确存储并占用了 4 个字节。当我试图将这些结果复制到 SO 时，虽然我看到了：
name (No column name) (No column name)
2 4
当我使用 Result to Text 时，我得到了实际字符：
name
-------------------- ----------- -----------
2 4
正确的字符在那里，但 SSMS 网格的字体无法显示
更新
正如 Dan Guzman 所指出的，可以从工具-->选项-->环境-->字体和颜色-->显示设置：-->网格结果中更改字体。默认字体是 Microsoft Sans Serif，Windows 上用作默认字体的小字体 (855KB)。它包含 "only" 3000 个字形。不包括中文字符，这就是显示方块的原因。
中国电脑默认使用SimShun，文件大小为17.1MB。 他们显示汉字不会有任何问题。
I'm trying to store arbitrary unicode points in an nvarchar column. I've tried different collations. I have no problem with common characters in the PBS plane of Unicode.
排序规则与您可以在 NVARCHAR / NCHAR / NTEXT（已弃用）列、变量或文字中存储的代码点无关。这些数据类型可以存储所有 1,114,112 个 Unicode 代码点（即使大多数尚未映射到字符）。
if I try to store character(U+1D33), ... within Management Studio, i only see the infamous square symbol. But management studio has the proper font since i can paste it in the query editor.
正如其他人已经解释过的：这只是一个字体问题。字体最多可包含 65k 个字符，因此您可能需要多种字体来覆盖您尝试使用的所有字符。我更喜欢 Code2003，您可以在 FontSpace.com.
上找到它
If i send the text from Visual Studio, the value i see in management studio is '??'
这应该是因为忘记在字符串文字前加上大写 "N" ;-)。
SELECT '' AS [Oops], N'' AS [No Oops];
-- ??
My understanding is, for non supplementary character collations, characters outside the UCS-2 subset shouldn't be interpreted correctly because nchar fields are limited to 2 bytes.
增补字符识别 (SCA) 排序规则——名称中以 _SC 或 _140_ 结尾的排序规则——确实支持增补字符。但是，"support" 仅表示内置函数将代理项对作为单个补充代码点处理，而不是一对代理项代码点。但是，对增补字符的排序和比较的支持实际上是在 SQL Server 2005 引入 90 版归类后开始的。
UCS-2 和 UTF-16 中的所有代码单元都是 16 位/2 字节。补充字符只是那些 2 字节代码单元中的两个。因此，当引入 NVARCHAR 时，能够存储补充字符应该在 SQL Server 7.0 中可用。即使增补字符直到几年后才被定义（在 SQL Server 2000 发布之后），NVARCHAR 类型仍然能够存储和检索它们。我没有要测试的 SQL Server 7.0，但我已经在 SQL Server 2000 上确认了这一点。
更多信息请看：
我正在使用 SQL Server 2017 进行一些测试。
我正在尝试将任意 Unicode 代码点存储在 NVARCHAR 列中。
我尝试过不同的归类。
我对Unicode的BMP平面的普通字符没问题
对于更奇特的符号，例如，如果我尝试存储“”字符 (U+1D33)，则会发生以下情况：
- 如果我在 Management Studio 中执行此操作，我只会看到臭名昭著的方形符号。但是 Management Studio 有正确的字体，因为我可以将它粘贴到查询编辑器中。
- 如果我从 Visual Studio 发送文本，我在 Management Studio 中看到的值是“??”，这也是我在执行查询后从 Visual Studio 检索到的值。
我的理解是，对于非补充字符排序规则，不应正确解释 UCS-2 子集之外的字符，因为 NCHAR 字段限制为 2 个字节。
但是，我在数据库级别和列级别尝试了 Latin1_General_100_CS_AS_KS_WS_SC，但它似乎也不起作用。
有什么想法吗？ 谢谢
我无法重现任何数据丢失或编码问题。我可以复制一个正方形，在复制时变成 </code>。这可能是由用于在 SSMS 网格中显示结果的 <em> 字体 </em> 或 Visual Studio 调试器 windows.</p> 引起的
<p>SQL 服务器和 Windows 使用 UTF16 已经有一段时间了，而不是 UCS-2。不过很少有字体支持完整的 UTF16 范围。 </p>
<p>当我在 SSMS 中尝试此操作时：</p>
<pre><code>create table #tc(name nvarchar(20));
insert into #tc values (N'');
select name,len(name),DATALENGTH(name) from #tc;
我在格子里看到了一个正方形，2和4。这意味着该字符已正确存储并占用了 4 个字节。当我试图将这些结果复制到 SO 时，虽然我看到了：
name (No column name) (No column name)
2 4
当我使用 Result to Text 时，我得到了实际字符：
name
-------------------- ----------- -----------
2 4
正确的字符在那里，但 SSMS 网格的字体无法显示
更新
正如 Dan Guzman 所指出的，可以从工具-->选项-->环境-->字体和颜色-->显示设置：-->网格结果中更改字体。默认字体是 Microsoft Sans Serif，Windows 上用作默认字体的小字体 (855KB)。它包含 "only" 3000 个字形。不包括中文字符，这就是显示方块的原因。
中国电脑默认使用SimShun，文件大小为17.1MB。 他们显示汉字不会有任何问题。
I'm trying to store arbitrary unicode points in an nvarchar column. I've tried different collations. I have no problem with common characters in the PBS plane of Unicode.
排序规则与您可以在 NVARCHAR / NCHAR / NTEXT（已弃用）列、变量或文字中存储的代码点无关。这些数据类型可以存储所有 1,114,112 个 Unicode 代码点（即使大多数尚未映射到字符）。
if I try to store character(U+1D33), ... within Management Studio, i only see the infamous square symbol. But management studio has the proper font since i can paste it in the query editor.
正如其他人已经解释过的：这只是一个字体问题。字体最多可包含 65k 个字符，因此您可能需要多种字体来覆盖您尝试使用的所有字符。我更喜欢 Code2003，您可以在 FontSpace.com.
上找到它If i send the text from Visual Studio, the value i see in management studio is '??'
这应该是因为忘记在字符串文字前加上大写 "N" ;-)。
SELECT '' AS [Oops], N'' AS [No Oops];
-- ??
My understanding is, for non supplementary character collations, characters outside the UCS-2 subset shouldn't be interpreted correctly because nchar fields are limited to 2 bytes.
增补字符识别 (SCA) 排序规则——名称中以 _SC 或 _140_ 结尾的排序规则——确实支持增补字符。但是，"support" 仅表示内置函数将代理项对作为单个补充代码点处理，而不是一对代理项代码点。但是，对增补字符的排序和比较的支持实际上是在 SQL Server 2005 引入 90 版归类后开始的。
UCS-2 和 UTF-16 中的所有代码单元都是 16 位/2 字节。补充字符只是那些 2 字节代码单元中的两个。因此，当引入 NVARCHAR 时，能够存储补充字符应该在 SQL Server 7.0 中可用。即使增补字符直到几年后才被定义（在 SQL Server 2000 发布之后），NVARCHAR 类型仍然能够存储和检索它们。我没有要测试的 SQL Server 7.0，但我已经在 SQL Server 2000 上确认了这一点。
更多信息请看：