为什么在所有这些讨论中，没有提到UTF-8?能够存储完整的unicode字符跨度并不意味着必须总是为每个字符分配两个字节(或使用unicode术语的“码位”)。所有的ASCII都是UTF-8。SQL Server检查VARCHAR()字段，文本是严格的ASCII(即顶部字节位零)?我希望不是。

如果您希望存储unicode并希望与旧的仅使用ascii的应用程序兼容，我认为使用VARCHAR()和UTF-8将是神奇的子弹:它只在需要时使用更多的空间。

对于那些不熟悉UTF-8的人，我可以推荐一个入门。

总是使用nvarchar。

对于大多数应用程序，您可能永远都不需要双字节字符。但是，如果您需要支持双字节语言，而您的数据库模式中只有单字节支持，那么返回并在整个应用程序中进行修改是非常昂贵的。

将一个应用程序从varchar迁移到nvarchar的成本将远远超过在大多数应用程序中使用的一点点额外磁盘空间。

为什么在所有这些讨论中，没有提到UTF-8?能够存储完整的unicode字符跨度并不意味着必须总是为每个字符分配两个字节(或使用unicode术语的“码位”)。所有的ASCII都是UTF-8。SQL Server检查VARCHAR()字段，文本是严格的ASCII(即顶部字节位零)?我希望不是。

如果您希望存储unicode并希望与旧的仅使用ascii的应用程序兼容，我认为使用VARCHAR()和UTF-8将是神奇的子弹:它只在需要时使用更多的空间。

对于那些不熟悉UTF-8的人，我可以推荐一个入门。

在某些特殊情况下，您会有意限制数据类型，以确保它不包含某个特定集合中的字符。例如，我有一个场景，我需要在数据库中存储域名。域名的国际化在当时是不可靠的，所以最好限制在基础水平上的输入，并有助于避免任何潜在的问题。

For your application, nvarchar is fine because the database size is small. Saying "always use nvarchar" is a vast oversimplification. If you're not required to store things like Kanji or other crazy characters, use VARCHAR, it'll use a lot less space. My predecessor at my current job designed something using NVARCHAR when it wasn't needed. We recently switched it to VARCHAR and saved 15 GB on just that table (it was highly written to). Furthermore, if you then have an index on that table and you want to include that column or make a composite index, you've just made your index file size larger.

做决定时要考虑周全;在SQL开发和数据定义中，似乎很少有“默认答案”(当然，除了不惜一切代价避免游标)。

由于您的应用程序很小，使用nvarchar与使用varchar相比，基本上没有明显的成本增加，而且如果您需要存储unicode数据，您也省去了潜在的麻烦。