为什么不将 SQL_Latin1_General_CI_AS 用于全局系统？

Question

在处理英文、德文、日文和中文数据的系统上不使用 SQL_Latin1_General_CI_AS 排序规则的真正好理由是什么？

我很难找到比较排序规则并回答我的上述问题以及以下问题的好来源

1. 在对非日语字符进行排序时，Japanese_CI_AS 与 SQL_Latin1_General_CI_AS 有何不同？
2. UCA 的排序是否与 Japanese_CI_AS 和 SQL_Latin1_General_CI_AS 不同？
3. 全球使用的系统的标准行业惯例是什么？（例如，Facebook、Twitter、Google、Flickr、百度或微软、IBM 和 SAP 使用什么？）
4. SQL_Latin1_General_CI_AS 是否定义了日语字符的排序顺序？如果不是，日文文本如何/为什么在 SQL_Latin1_General_CI_AS 中工作？

基本上我正在尝试学习如何选择合适的排序规则:)

提前致谢！

Answer 1

SQL Server 中的排序规则处理字符串数据的几个方面：

\n\n

\n

1. 区域设置/ LCID（指文化：en-US、fr-FR 等）

   \n\n

   这用于确定对NVARCHAR所有排序规则中的 Unicode / 数据以及VARCHARWindows 的非 Unicode / 数据（即非SQL_）排序规则使用的默认语言排序和比较规则的文化特定覆盖。

\n

2. 代码页

   \n\n

   这是用于非 Unicode/VARCHAR所有排序规则的字符集。需要明确的是，代码页不适用于 Unicode /NVARCHAR数据，因为 Unicode 是单个字符集。需要非常明确的是，Unicode 是一个单一字符集，无论它是如何编码的：UTF-8、UTF-16 或 UTF-32。

\n

3. 灵敏度

   \n\n

   可以在所有排序规则中控制大小写和重音敏感性。仅当使用 Windows 排序规则时才能控制假名和宽度敏感度，并且在使用排序规则时假定为“不敏感” SQL_。

   \n\n

   此外，所有 Windows 排序规则都应该有一个二进制选项（至少是已弃用的_BIN，如果不是的话_BIN2），而只有两个SQL_排序规则具有_BIN/_BIN2选项：SQL_Latin1_General_CP850和SQL_Latin1_General_CP437。

\n

4. 处理补充字符的能力

   \n\n

   SQL Server 2012 中添加了一组名称以 结尾的排序规则。_SC这些排序规则允许正确排序/比较，以及通过 UTF-16 代理项对的内置函数进行处理（这就是 UTF-16 对 U+ 之上的代码点进行编码的方式） FFFF）。此选项不适用于任何SQL_排序规则。

   \n\n

   请注意，无论排序规则如何，都可以存储和检索所有NVARCHARUTF-16 数据，而不会在列NCHAR和变量中丢失任何数据XML，即使排序规则不允许正确解释补充字符。

\n

\n\n

此外，仅在使用排序规则时，非 Unicode/VARCHAR数据才会出现一些行为差异：SQL_

\n\n

\n
1. ASCII 值 0 /CHAR(0)不等于空字符串。
\n
2. 当使用区分大小写的排序规则（例如SQL_Latin1_General_CP1_CS_AS）对数据进行排序时，大写字符将排在小写字符之前。
\n
3. 使用字符串排序，它将所有标点符号排序在所有字母之前，而不是单词排序，忽略单词中的破折号和撇号（例如，在使用字符串排序a-f之前排序，但在使用单词排序时在字符串排序之后排序）。aa
\n
4. 没有进行特定于文化的字符扩展（例如\'\xc3\xa6\' = \'ae\'）
\n

\n\n

NVARCHAR但是，使用任何排序规则的数据与VARCHAR使用 Windows 排序规则的数据之间存在行为一致性。

\n\n

因此，理想情况下，SQL_考虑到上述限制和差异，不应使用排序规则，更不用说它们也已被弃用（截至 SQL Server 2014，只有 77 个排序规则和 3810 个 Windows 排序规则）。如果有的话，请尝试使用特定排序规则的最新版本（例如_100_），如果提供，请使用以 结尾的排序规则_SC。

\n\n

不幸的是，SQL_Latin1_General_CP1_CI_AS这是在美国安装新实例时的默认设置（至少）。但人们不应该自愿选择一种SQL_排序规则来进行新的开发，尤其是在需要处理多种文化时。

\n\n

但要回答另外 4 个问题：

\n\n

\n

1. \n

   在对非日语字符进行排序时， Japanese_CI_AS 与 SQL_Latin1_General_CI_AS 有什么不同？

   \n

   \n\n

   这仅涉及NVARCHAR数据，对吧？LCID 确定将哪些特定于区域性的覆盖应用于默认排序选项。我怀疑美国英语字符在日语和拉丁语排序规则之间的排序相同，但我不确定这是否也适用于使用这些字符的其他语言，或者对于美国英语中未找到的字符，例如带重音符号的字母。一个额外的复杂性是，您的两个字母都已经带有重音符号，然后没有重音符号的字母仅与重音符号相结合（即组合字符），并且这些东西在英语/德语/日语/中文语言环境中可能不等同。

\n

2. \n

   UCA 排序是否与 Japanese_CI_AS 和 SQL_Latin1_General_CI_AS 不同？

   \n

   \n\n

   我不确定这个问题是否有意义。所有字符都有一个默认的排序顺序。然后，每个区域设置都可以覆盖（替换或删除）任何这些默认值或添加新规则。因此 UCA 是字符的基本权重，但每种文化都可能会偏离这些默认值。因此，规则之间会有大量的重叠，但它们之间也会有大量的变化。

\n

3. \n

   全球使用的系统的标准行业惯例是什么？（例如，Facebook、Twitter、Google、Flickr、百度或 Microsoft、IBM 和 SAP 使用什么？）

   \n

   \n\n

   不确定这些公司到底做什么，但我怀疑它们是否预先索引了特定于文化的语言规则。至少不是所有数据。大多数网站确实会询问您的首选语言，并可能使用它来处理某些数据。无论哪种方式，都无法进行单一的、真正独立于文化的排序。

\n

4. \n

   SQL_Latin1_General_CI_AS 是否定义日语字符的排序顺序？如果不是，日语文本如何/为什么在 SQL_Latin1_General_CI_AS 中工作？

   \n

   \n\n

   不确定日语文本“工作”是什么意思，但 Unicode 是适用于所有语言的单一字符集。因此，存储特定语言的字符的能力并不意味着这些字符的排序规则。

   \n\n

   如上所述，UCA 是所有字符的默认排序顺序。Latin1 排序规则可以对所有语言进行基本排序（就 Unicode /NVARCHAR数据而言），但它只有默认规则。Latin1 排序规则不会有任何特定于文化的规则，并且可以有多组这些规则。此外，如上所述，SQL_排序规则无法打开您可能需要的假名或宽度敏感度。

\n

\n