是否应该使用NVARCHAR将“重音符号”保存到Sql Server中？

Question

我在Sql Server表中具有以下两个字段：

当我在字段中添加带有重音符号的测试数据时，它实际上存储了它们！我以为我必须将列从VARCHAR更改NVARCHAR为接受重音符号等？

基本上，我认为：

• VARCHAR = ASCII
• NVARCHAR = Unicode

那么，是这样的情况，其中façadeetc 实际上是ASCII ..而其他一些字符会出错（如果VARCHAR）？

我可以在扩展的 ASCII图表中看到ç和é字符（上面的链接）..这是否意味着ASCII包括0-> 127或0-> 255？

（想法：我想我很高兴接受0-> 255并删除其他任何内容。）

编辑

• 数据库整理： Latin1_General_CI_AS
• 服务器版本： 12.0.5223.6
• 服务器整理： SQL_Latin1_General_CP1_CI_AS

Answer 1

首先，详细介绍Sql Server正在做什么。

VARCHAR使用特定的归类存储单字节字符。ASCII仅使用7位或一个字节中可能值的一半。归类引用特定的代码页（以及排序和等同规则）以使用每个字节中另一半的可能值。这些代码页通常包括对一组有限且特定的重音字符的支持。如果用于数据的代码页支持重音符，则可以执行；如果不是，您会看到奇怪的结果（不可打印的“框”或？字符）。您甚至可以输出存储在一个排序规则中的数据，就好像它已经存储在另一排序规则中一样，并以这种方式获得真正奇怪的东西（但不要这样做）。

NVARCHAR是unicode，但仍然需要归类。在大多数情况下，您最终会得到UTF-16，这确实允许使用所有范围的unicode字符。相反，某些排序规则将导致UCS-2出现，这会稍微受到限制。有关更多信息，请参见nchar / nvarchar文档。

作为一个额外的怪癖，即将推出的SQL服务器2019将包括UTF-8支持的char和varchar使用正确的归类时类型。

现在回答问题。

在极少数情况下，如果您确定数据仅需要支持源自单个特定（通常是本地）文化的重音字符，并且仅支持那些特定的重音字符，则可以使用该varchar类型。

但是，请务必谨慎确定。在一个日益全球化和多样化的世界中，即使是小型企业也希望利用互联网来扩大其覆盖范围，即使是在自己的社区内，使用不足的编码也很容易导致错误甚至安全漏洞。它多数情况好像一个varchar编码可能是不够好真的不再安全。

就我个人而言，我varchar今天唯一使用的地方是助记符代码字符串，这些字符串永远不会显示给最终用户或由最终用户提供。enum在程序代码中可能是值的东西。即使这样，它也往往是遗留代码，并且在给定选项的情况下，我将改用整数值，以实现更快的联接和更有效的内存使用。但是，即将推出的UTF-8支持可能会改变这一点。