主页 / dba / 问题 / 294387
Accepted
Eng.Fouad
Asked: 2021-06-17 07:35:55 +0800 CST

Arabic_100_CS_AS_KS_WS_SC_UTF8 和 Latin1_General_100_CS_AS_KS_WS_SC_UTF8 有什么区别？

  • 772

从 SQL Server 2019 开始，它支持 UTF-8 作为排序规则。但是，根据以下查询：

SELECT COLLATIONPROPERTY('Arabic_100_CS_AS_KS_WS_SC_UTF8', 'CodePage')
SELECT COLLATIONPROPERTY('Latin1_General_100_CS_AS_KS_WS_SC_UTF8', 'CodePage');

65001两者都返回Windows 中的 Unicode代码页。此外，所有新的_UTF8排序规则都使用代码页65001：

SELECT * FROM sys.fn_helpcollations() WHERE name LIKE '%_UTF8';

Arabic_100_CS_AS_KS_WS_SC_UTF8using和Latin1_General_100_CS_AS_KS_WS_SC_UTF8as collat​​ion之间有什么区别吗？

sql-server collation

1 个回答

  1. Best Answer

    是的，所有_UTF8排序规则都使用代码页 65001，因为这是UTF-8 的代码页。您甚至可以通过以下方式在 DOS / 命令窗口中使用 65001：

    chcp 65001

    尽管并非所有程序和字体都可以与它无缝协作。

    对于_UTF8排序规则，代码页不受文化（即Latin1_Generalvs Arabic）的控制，_UTF8因为代码页指示用于VARCHAR数据的特定 8 位编码（即 8 位字符数据）。对于非 Unicode 8 位编码，文化通常与作为字符集的代码页相关联（例如，Latin1 是代码页 Windows-1252，它在 128-255 范围内的字符与作为代码的 Windows-1255 不同希伯来语页面）。但是对于 UTF-8，它是8 位编码，用于单数、无所不包的字符集，即 Unicode。

    至于Arabic_100_CS_AS_KS_WS_SC_UTF8和Latin1_General_100_CS_AS_KS_WS_SC_UTF8去之间的差异，它实际上只是对各种字符进行排序和比较的特定文化规则。当然，这两种语言并没有真正共享任何字符，但是在某些代码点的处理方式上仍然存在差异。

    查看“Windows Server 2008 排序权重表”文件（据我所知，这是版本_100_排序规则的主要依据），我找不到这两个排序规则之间的任何排序/比较差异。因此，就行为而言，它们可能是相同的。但是，它们是不同的，因为它们仍然具有不同的 LCID（区域设置/文化标识符），因此将它们的值转换为非 UTF8VARCHAR可能会导致数据丢失/损坏，以及查看排序规则的任何进程/功能确定某些其他行为可能表现不同。

    话虽如此，我确实找到了一个使用乌尔都语排序规则时阿拉伯字符行为差异的示例，因为这些排序规则确实对默认排序权重进行了一些修改（9 在“Windows Server 2008 排序权重表”文件中注册） .

    查看“Teh Marbuta”字符（U+0629），它在默认表（即用于美国英语/Latin1 的表）中的权重为 29，其排序权重低于“Peheh”字符（U +06A6)，默认权重为 137。41 表示字符在哪个“脚本”中，这两个都是阿拉伯字符。但是，乌尔都语排序规则将“Teh Marbuta”（U+0629）的排序权重修改为 183，然后其排序权重高于“Peheh”（U+06A6），仍然为 137。

    -- Default
0x0629  41  29  2   2   ;Arabic Teh Marbuta -- ة
0x06a6  41  137 2   2   ;Arabic Peheh       -- ڦ

-- Urdu modifications
0x0629  41  183 2   2   ;Teh Marbuta        -- ة

    如果我们使用Latin1_General_100_CS_AS_KS_WS_SC_UTF8or对这两个字符进行排序Arabic_100_CS_AS_KS_WS_SC_UTF8，我们应该得到默认行为。而且，即使我们使用Yakut排序规则，它使用西里尔字母并且对默认排序权重有自己的修改，它不会修改这些阿拉伯字符中的任何一个，因此它们的行为应该与使用Latin1_General或Arabic排序规则时相同：

    SELECT *
FROM   (VALUES (1, NCHAR(0x0629)), (2, NCHAR(0x06a6))) tmp(ID, TheChar)
ORDER BY tmp.[TheChar] COLLATE Latin1_General_100_CS_AS_KS_WS_SC_UTF8 ASC

SELECT *
FROM   (VALUES (1, NCHAR(0x0629)), (2, NCHAR(0x06a6))) tmp(ID, TheChar)
ORDER BY tmp.[TheChar] COLLATE Arabic_100_CS_AS_KS_WS_SC_UTF8 ASC


SELECT *
FROM   (VALUES (1, NCHAR(0x0629)), (2, NCHAR(0x06a6))) tmp(ID, TheChar)
ORDER BY tmp.[TheChar] COLLATE Yakut_100_CS_AS_KS_WS_SC_UTF8 ASC

    上面显示的所有三个查询都返回以下结果：

    ID    TheChar
1     ة
2     ڦ

    但是，当我们切换到Urdu排序规则时，这两个字符的顺序确实发生了变化：

    SELECT *
FROM   (VALUES (1, NCHAR(0x0629)), (2, NCHAR(0x06a6))) tmp(ID, TheChar)
ORDER BY tmp.[TheChar] COLLATE Urdu_100_CS_AS_SC_UTF8 ASC

    返回：

    ID    TheChar
2     ڦ
1     ة

    最后，请记住，虽然很少遇到这种情况，但排序规则也会影响大写/小写映射。我相信这仅限于Azeri_*和Turkish排序规则，并且仅限于字母“i”和“I”（这些文化有一个带点的大写“I”和一个不带点的小写“i”），但仍然最好注意潜在的：

    SELECT UPPER(N'i' COLLATE Arabic_100_CS_AS_KS_WS_SC_UTF8) AS [Arabic],
   UPPER(N'i' COLLATE Turkish_100_CS_AS_KS_WS_SC_UTF8) AS [Turkish],
   UPPER(N'i' COLLATE Azeri_Cyrillic_100_CS_AS_KS_WS_SC_UTF8) AS [Azeri_Cyrillic],
   UPPER(N'i' COLLATE Azeri_Latin_100_CS_AS_KS_WS_SC_UTF8) AS [Azeri_Latin];

    返回：

    Arabic   Turkish   Azeri_Cyrillic   Azeri_Latin
I        İ         İ                İ
    • 11

相关问题