主页 / dba / 问题 / 21445
Accepted
David
Asked: 2012-07-25 20:09:54 +0800 CST

为什么不对全局系统使用 SQL_Latin1_General_CI_AS？

  • 772

在处理英文、德文、日文和中文数据的系统上不使用 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 中工作？

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

提前致谢！

sql-server sql-server-2008-r2

2 个回答

  1. Best Answer

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

    1. 语言环境/ LCID（指文化：en-US、fr-FR 等）

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

    2. 代码页

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

    3. 灵敏度

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

      此外，所有 Windows 排序规则都应该有一个二元选项（至少是 deprecated _BIN，如果不是的话_BIN2），而只有两个SQL_排序规则有_BIN/_BIN2选项：SQL_Latin1_General_CP850和SQL_Latin1_General_CP437.

    4. 处理补充字符的能力

      _SCSQL Server 2012 中添加了一组名称以. FFFF）。此选项不适用于任何SQL_排序规则。

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

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

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

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

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

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

    但要回答 4 个附加问题：

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

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

    2. UCA 的排序方式是否不同于 Japanese_CI_AS 和 SQL_Latin1_General_CI_AS？

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

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

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

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

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

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

    • 3

  2. 以下脚本应该清楚地说明问题 1。

    declare @i int = 0;
declare @temp table( id int, latin varchar(1) collate SQL_Latin1_General_CP1_CI_AS, jap varchar(1) collate Japanese_90_CI_AS )
while (@i < 256)
begin
insert into @temp 
select @i, char(@i)  collate SQL_Latin1_General_CP1_CI_AS ,char(@i)  collate Japanese_90_CI_AS  

set @i = @i+1;
end

select * from @temp
order by latin

select * from @temp
order by jap

    1. Collat​​ion 是关于如何排序的规则，对此有一个阅读。上面的脚本应该向您展示排序更改如何与 UCA 匹配。

    2. 任何答案都是基于意见的，上面的大多数公司都不使用单一类型的数据库（图形、大数据等），除了SQL_Latin1_General_CP1_CI_AS. （我从来不用在欧洲以外的地方工作）

    3. 如果您正在使用nvarchars= 您正在使用unicode并且 unicode 就像 Chuck Norris - 涵盖所有内容（两次）。

    • 0

相关问题