SQL Server 2005/2008 UTF-8排序规则/字符集

我找不到选项（S）直接设置UTF-8rellated Collations/Charsets在SQL Server 2005/2008，一样可以集另一个SQL引擎，但在SQL Server 2005/2008在那里只有拉丁美洲和SQL排序规则。

是否可以在Win2008 OS的SQL Server引擎2005/2008中（对于两个版本）强制/安装这些排序规则/字符集？

不，没有。SQL Server不支持UTF-8。

如果需要unicode数据，则需要将列定义为nvarchar / nchar。注意，SQL Server在内部将其存储为UCS-2。

请注意，这是从Connect上的MS请求的，并且有较旧的KB文章。还有此博客上的一些信息

您不能将UTF-8安装为字符集，因为它不是字符集，而是一种编码。

如果要存储Unicode文本，请使用nvarchar数据类型。

如果要存储使用UTF-8编码的文本，请将其存储为二进制数据（varbinary）。

从SQL Server 2019开始（当前在beta /“社区技术预览”中），通过一系列新的UTF-8归类对UTF-8进行了本机支持。但是，具有使用UTF-8的能力并不意味着您应该这样做。使用UTF-8有明显的缺点，例如：

1. 仅前128个代码点为1字节（即标准的7位ASCII集）
2. 接下来的近2000个代码点为2个字节，因此与UTF-16 / NVARCHAR
3. BMP中剩余的63k代码点（即U + 0800-U + FFFF范围）都是3个字节，因此是1个字节 比UTF-16 /中的相同字符大NVARCHAR。
4. 只需说明一下：两种编码中的补充字符均为4字节，因此那里没有空格差异
5. 尽管您可以使用UTF-8节省空间，但这样做很有可能会影响性能。

真正的结果是：UTF-8是一种存储格式设计，使8位系统（通常围绕ASCII和ASCII扩展-代码页设计）可以使用Unicode，而不会破坏任何内容或需要对现有的内容进行任何修改文件，以保持运行状态。UTF-8非常适合文件系统和网络，但是SQL Server 内部存储的数据都不是。与存储为UTF-16 /的相同数据相比，恰好大部分（或完全）在标准ASCII范围内的数据需要较少的空间NVARCHAR。当然，这是可以证明有用的副作用，但是该决定需要由既了解数据又了解该决定的后果/缺点的人做出。这是不是一般用途的功能。

另外，UTF-8（在SQL Server中）的主要用例是已经使用UTF-8的应用程序代码，可能已经与支持它的另一个RDBMS一起使用，并且不希望或无法更新应用程序代码/数据库架构使用NVARCHAR数据类型（用于表，变量，参数等），或为字符串文字加上大写的“ N”前缀。目标与存在UTF-8的原因相同：使应用程序代码使用Unicode而不更改整体结构或使存在的数据无效。如果这描述了您的情况，请使用UTF-8，但要注意它仍然存在一些错误/问题。

如果您不需要使用NVARCHAR或不使用大写的“ N”作为前缀的字符串文字，则无需使用Unicode ，那么使用UTF-8的唯一另一种情况是，如果您有大量的大多数标准ASCII数据需要允许Unicode字符，并且您正在使用NVARCHAR(MAX)（这意味着无法进行数据压缩），并且该表会频繁更新（因此，群集列存储索引可能不会真正起到帮助作用）。

有关详细信息，请参阅我的文章：

SQL Server 2019中的本机UTF-8支持：救星还是假先知？

就我而言，我必须显示阿拉伯语字符，而我的开发数据库是在2014年，因此一切正常。在这里，在查询中我可以看到阿拉伯字符，而我的排序规则是SQL_Latin1_General_CP1256_CI_AS

但是我的生产是在SQL Server 2008中进行的，最终它不支持UTF-8字符集。在这里，我可以看到所有??????????? 因为SQL 2008不支持UTF-8。

我所做的就是将所有varchar更改为nvarchar，并且可以正确看到阿拉伯字符。我也将我的2008数据库排序规则更改为SQL_Latin1_General_CP1256_CI_AS