sql-server - 是否应该使用 NVARCHAR 将 'accented characters' 保存到 Sql Server 中？

Question

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

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

基本上，我认为:

• VARCHAR = ASCII
• NVARCHAR = Unicode

这就是façade等的情况are actually 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 使用特定的 collation 存储单字节 字符。 。 ASCII 仅使用 7 位，即一个字节中可能值的一半。排序规则引用特定的代码页(以及排序和等同规则)以使用每个字节中的另一半可能值。这些代码页通常包含对有限特定重音字符集的支持。如果您的数据使用的代码页支持重音字符，您就可以这样做；如果没有，您会看到奇怪的结果(无法打印的“框”或 ? 字符)。您甚至可以输出存储在一种排序规则中的数据，就好像它存储在另一种排序规则中一样，并以这种方式得到非常奇怪的东西(但不要这样做)。

NVARCHAR 是 unicode，但仍然对排序规则有一定的依赖。在大多数情况下，您最终会得到 UTF-16 ，它确实允许使用全部 unicode 字符。某些排序规则将导致 UCS-2，但其限制稍多。请参阅nchar/nvarchar documentation了解更多信息。

作为一个额外的怪癖，即将推出的 Sql Server 2019 will include support for UTF-8使用正确的排序规则时，在 char 和 varchar 类型中。

<小时/>

现在回答问题。

在极少数情况下，您确定您的数据只需要支持源自单一特定(通常是本地)文化的重音字符，并且仅那些特定的重音字符，您可以使用 varchar 类型来获取。

但是做出这个决定时要非常小心。在日益全局化和多元化的世界中，即使是小企业也希望利用互联网来扩大影响力，即使是在自己的社区内，使用不充分的编码很容易导致错误甚至安全漏洞。大多数情况下，看起来 varchar 编码可能足够好，但实际上不再安全了。

就我个人而言，我现在唯一使用 varchar 的地方是从未向最终用户显示或提供的助记符代码字符串；可能是过程代码中的enum值的东西。即使如此，这往往是遗留代码，并且考虑到我将使用整数值的选项，以实现更快的连接和更有效的内存使用。然而，即将推出的 UTF-8 支持可能会改变这一点。