アクセントセンシティブソート

19

なぜこれらの2つのSELECTステートメントが異なるソート順になるのですか？

USE tempdb;
CREATE TABLE dbo.OddSort 
(
    id INT IDENTITY(1,1) PRIMARY KEY
    , col1 NVARCHAR(2)
    , col2 NVARCHAR(2)
);
GO
INSERT dbo.OddSort (col1, col2) 
VALUES (N'e', N'eA')
    , (N'é', N'éB')
    , (N'ë', N'ëC')
    , (N'è', N'èD')
    , (N'ê', N'êE')
    , (N'ē', N'ēF');
GO

SELECT * 
FROM dbo.OddSort 
ORDER BY col1 COLLATE Latin1_General_100_CS_AS;

╔====╦======╦======╗
║id║col1║col2║
╠====╬======╬======╣
║1║e║eA║
║2éé║éB║
║4èèèè║-id 3にする必要がありますか？
║5êê║êE║
║3║ë║ëC║
║6║ē║ēF║
╚====╩======╩======╝
SELECT * 
FROM dbo.OddSort 
ORDER BY col2 COLLATE Latin1_General_100_CS_AS;

╔====╦======╦======╗
║id║col1║col2║
╠====╬======╬======╣
║1║e║eA║
║2éé║éB║
║3║ë║ëC║
║4║è║èD║
║5êê║êE║
║6║ē║ēF║
╚====╩======╩======╝
sql-server  collation  unicode 
— アラム
ソース

回答:

13

この質問はデータベースとはあまり関係がありませんが、Unicodeの処理とルールに関するものです。

https://docs.microsoft.com/en-us/sql/t-sql/statements/windows-collat​​ion-name-transact-sqlに 基づくLatin1_General_100_CS_ASは、「照合はLatin1一般辞書の並べ替え規則とマップをコードページに使用します1252インチにCS =大文字と小文字を区別し、AS =アクセントを区別します。

Windowsコードページ1252とUnicode（http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT）の間のマッピングは、扱っているすべての文字に対して同じ値を示します（マクロンを含むeを除く）これはMicrosoftのマッピングには存在しないため、このケースで何が行われるのかわかりません）、現在はUnicodeツールと用語に集中できます。

まず、すべての文字列について、何を扱っているかを正確にお知らせください。

0065  LATIN SMALL LETTER E
0041  LATIN CAPITAL LETTER A
00E9  LATIN SMALL LETTER E WITH ACUTE
0042  LATIN CAPITAL LETTER B
00EB  LATIN SMALL LETTER E WITH DIAERESIS
0043  LATIN CAPITAL LETTER C
00E8  LATIN SMALL LETTER E WITH GRAVE
0044  LATIN CAPITAL LETTER D
00EA  LATIN SMALL LETTER E WITH CIRCUMFLEX
0045  LATIN CAPITAL LETTER E
‎0113  LATIN SMALL LETTER E WITH MACRON
0046  LATIN CAPITAL LETTER F

Unicode照合アルゴリズムについては、https：//www.unicode.org/reports/tr10/で説明しています。

一部のルールはコンテキスト依存であるため、ソートは1つの文字だけに依存することはできないことを説明するセクション1.3「コンテキスト依存」をご覧ください。

1.8の次の点にも注意してください。

照合は文字列のプロパティではありません。一般に、連結またはサブストリング操作では照合順序は保持されません。

デフォルトでは、アルゴリズムは完全にカスタマイズ可能な3つのレベルを使用します。ラテン文字の場合、これらのレベルはおおよそ次のものに対応します。

alphabetic ordering
diacritic ordering
case ordering.

しかし、アルゴリズム自体は少し高密度です。その要点は次のとおりです。簡単に言えば、Unicode照合アルゴリズムは、入力Unicode文字列と、文字のマッピングデータを含む照合要素テーブルを受け取ります。ソートキーを生成します。これは、符号なし16ビット整数の配列です。このように生成された2つ以上のソートキーをバイナリ比較して、生成された文字列間の正しい比較を行うことができます。

特定のラテン語の並べ替え規則 については、http：//developer.mimer.com/collat​​ions/charts/latin.htmをご覧ください。MSSQLの場合、具体的にはhttp://collat​​ion-charts.org/mssql/mssqlをご覧 ください。 0409.1252.Latin1_General_CS_AS.html

以下のためeの文字には示しています。

e EéÉèèêÊëË

これはcol1、コードページ1252にēが存在しないことを除いて、注文時の結果を説明しています。

または、http：//www.unicode.org/Public/UCA/latest/allkeys.txtのDUCETのキー値を使用して、Unicodeアルゴリズムを手動で実行する場合：

ステップ1：正規化フォームD。したがって、各ケースは次のようになります。

e => U+0065
é => U+0065 U+0301
ë => U+0065 U+0308
è => U+0065 U+0300
ê => U+0065 U+0302
ē => U+0065 U+0304

ステップ2、照合配列の作成（ファイル内の検索allkeys.txt）

e => [.1D10.0020.0002]
é => [.1D10.0020.0002] [.0000.0024.0002]
ë => [.1D10.0020.0002] [.0000.002B.0002]
è => [.1D10.0020.0002] [.0000.0025.0002]
ê => [.1D10.0020.0002] [.0000.0027.0002]
ē => [.1D10.0020.0002] [.0000.0032.0002]

ステップ3、ソートキーを形成します（各レベルで、各照合配列内の各値を取得し、区切り文字として0000を入れて、次のレベルで再度開始します）

e => 1D10 0000 0020 0000 0002
é => 1D10 0000 0020 0024 0000 0002 0002
ë => 1D10 0000 0020 002B 0000 0002 0002
è => 1D10 0000 0020 0025 0000 0002 0002
ê => 1D10 0000 0020 0027 0000 0002 0002
ē => 1D10 0000 0020 0032 0000 0002 0002

ステップ4、ソートキーの比較（各値を1つずつ単純なバイナリ比較）：4番目の値ですべてをソートできるため、最終的な順序は次のようになります。

e
é
è
ê
ë
ē

注文と同じ方法でcol2：

ステップ1：NFD

eA => U+0065 U+0041
éB => U+0065 U+0301 U+0042
ëC => U+0065 U+0308 U+0043
èD => U+0065 U+0300 U+0044
êE => U+0065 U+0302 U+0045
ēF => U+0065 U+0304 U+0046

ステップ2：照合配列

eA => [.1D10.0020.0002] [.1CAD.0020.0008]
éB => [.1D10.0020.0002] [.0000.0024.0002] [.1CC6.0020.0008]
ëC => [.1D10.0020.0002] [.0000.002B.0002] [.1CE0.0020.0008]
èD => [.1D10.0020.0002] [.0000.0025.0002] [.1CF5.0020.0008]
êE => [.1D10.0020.0002] [.0000.0027.0002] [.1D10.0020.0008]
ēF => [.1D10.0020.0002] [.0000.0032.0002] [.1D4B.0020.0008]

ステップ3：ソートキーの作成

eA => 1D10 1CAD 0000 0020 0020 0000 0002 0008
éB => 1D10 1CC6 0000 0020 0024 0020 0000 0002 0002 0008
ëC => 1D10 1CE0 0000 0020 002B 0020 0000 0002 0002 0008
èD => 1D10 1CF5 0000 0020 0025 0020 0000 0002 0002 0008
êE => 1D10 1D10 0000 0020 0027 0020 0000 0002 0002 0008
ēF => 1D10 1D4B 0000 0020 0032 0020 0000 0002 0002 0008

ステップ4：ソートキーの比較：2番目の値はすべてをソートするのに十分であり、実際にはすでに昇順であるため、実際の最終順序は次のとおりです。

eA
éB
ëC
èD
êE
ēF

更新：ソロモンラッツキーの3番目のケースを追加します。これは、新しいルールを有効にするスペースがあるために複雑です（「無視できないケース」を選択しました）。

ステップ1、NFD：

è 1 => U+0065 U+0300 U+0020 U+0031
ê 5 => U+0065 U+0302 U+0020 U+0035
e 2 => U+0065 U+0020 U+0032
é 4 => U+0065 U+0301 U+0020 U+0034
ē 3 => U+0065 U+0304 U+0020 U+0033
ë 6 => U+0065 U+0308 U+0020 U+0036

ステップ2、照合配列の作成：

è 1 => [.1D10.0020.0002] [.0000.0025.0002] [*0209.0020.0002] [.1CA4.0020.0002]
ê 5 => [.1D10.0020.0002] [.0000.0027.0002] [*0209.0020.0002] [.1CA8.0020.0002]
e 2 => [.1D10.0020.0002] [*0209.0020.0002] [.1CA5.0020.0002]
é 4 => [.1D10.0020.0002] [.0000.0024.0002] [*0209.0020.0002] [.1CA7.0020.0002]
ē 3 => [.1D10.0020.0002] [.0000.0032.0002] [*0209.0020.0002] [.1CA6.0020.0002]
ë 6 => [.1D10.0020.0002] [.0000.002B.0002] [*0209.0020.0002] [.1CA9.0020.0002]

ステップ3、フォームソートキー：

è 1 => 1D10 0209 1CA4 0000 0020 0025 0020 0020 0000 0002 0002 0002 0002
ê 5 => 1D10 0209 1CA8 0000 0020 0027 0020 0020 0000 0002 0002 0002 0002
e 2 => 1D10 0209 1CA5 0000 0020 0020 0020 0000 0002 0002 0002
é 4 => 1D10 0209 1CA7 0000 0020 0024 0020 0020 0000 0002 0002 0002 0002
ē 3 => 1D10 0209 1CA6 0000 0020 0032 0020 0020 0000 0002 0002 0002 0002
ë 6 => 1D10 0209 1CA9 0000 0020 002B 0020 0020 0000 0002 0002 0002 0002

ステップ4、ソートキーの比較：

基本的に3番目の値は順序を決定し、実際には最後の桁のみに基づいているため、順序は次のようになります。

è 1
e 2
ē 3
é 4
ê 5
ë 6

Unicodeバージョンに関するSolomon Rutzkyのコメントに基づく2番目の更新。

allkeys.txtこの時点で最新のUnicodeバージョン、つまりバージョン10.0に関するデータを使用しました

代わりにUnicode 5.1を考慮する必要がある場合、これは次のようになります。http： //www.unicode.org/Public/UCA/5.1.0/allkeys.txt

上記のすべての文字について、照合配列は次のようになっています。

e => [.119D.0020.0002.0065]
é => [.119D.0020.0002.0065] [.0000.0032.0002.0301]
ë => [.119D.0020.0002.0065] [.0000.0047.0002.0308]
è => [.119D.0020.0002.0065] [.0000.0035.0002.0300]
ê => [.119D.0020.0002.0065] [.0000.003C.0002.0302]
ē => [.119D.0020.0002.0065] [.0000.005B.0002.0304]

そして：

eA => [.119D.0020.0002.0065] [.1141.0020.0008.0041]
éB => [.119D.0020.0002.0065] [.0000.0032.0002.0301] [.1157.0020.0008.0042]
ëC => [.119D.0020.0002.0065] [.0000.0047.0002.0308] [.116F.0020.0008.0043]
èD => [.119D.0020.0002.0065] [.0000.0035.0002.0300] [.1182.0020.0008.0044]
êE => [.119D.0020.0002.0065] [.0000.003C.0002.0302] [.119D.0020.0008.0045]
ēF => [.119D.0020.0002.0065] [.0000.005B.0002.0304] [.11D5.0020.0008.0046]

そして：

è 1 => [.119D.0020.0002.0065] [.0000.0035.0002.0300] [*0209.0020.0002.0020] [.1138.0020.0002.0031]
ê 5 => [.119D.0020.0002.0065] [.0000.003C.0002.0302] [*0209.0020.0002.0020] [.113C.0020.0002.0035]
e 2 => [.119D.0020.0002.0065] [*0209.0020.0002.0020] [.1139.0020.0002.0032]
é 4 => [.119D.0020.0002.0065] [.0000.0032.0002.0301] [*0209.0020.0002.0020] [.113B.0020.0002.0034]
ē 3 => [.119D.0020.0002.0065] [.0000.005B.0002.0304] [*0209.0020.0002.0020] [.113A.0020.0002.0033]
ë 6 => [.119D.0020.0002.0065] [.0000.0047.0002.0308] [*0209.0020.0002.0020] [.113D.0020.0002.0036]

次に、次のソートキーを計算します。

e => 119D 0000 0020 0000 0002 0000 0065
é => 119D 0000 0020 0032 0000 0002 0002 0000 0065 0301
ë => 119D 0000 0020 0047 0000 0002 0002 0000 0065 0308
è => 119D 0000 0020 0035 0000 0002 0002 0000 0065 0300
ê => 119D 0000 0020 003C 0000 0002 0002 0000 0065 0302
ē => 119D 0000 0020 005B 0000 0002 0002 0000 0065 0304

そして：

eA => 119D 1141 0000 0020 0020 0000 0002 0008 0000 0065 0041
éB => 119D 1157 0000 0020 0032 0020 0000 0002 0002 0008 0000 0065 0301 0042
ëC => 119D 116F 0000 0020 0047 0020 0000 0002 0002 0008 0000 0065 0308 0043
èD => 119D 1182 0000 0020 0035 0020 0000 0002 0002 0008 0000 0065 0300 0044
êE => 119D 119D 0000 0020 003C 0020 0000 0002 0002 0008 0000 0065 0302 0045
ēF => 119D 11D5 0000 0020 005B 0020 0000 0002 0002 0008 0000 0065 0304 0046

そして：

è 1 => 119D 0209 1138 0000 0020 0035 0020 0020 0000 0002 0002 0002 0002 0000 0065 0300 0020 0031
ê 5 => 119D 0209 113C 0000 0020 003C 0020 0020 0000 0002 0002 0002 0002 0000 0065 0302 0020 0035
e 2 => 119D 0209 1139 0000 0020 0020 0020 0000 0002 0002 0002 0000 0065 0020 0032
é 4 => 119D 0209 113B 0000 0020 0032 0020 0020 0000 0002 0002 0002 0002 0000 0065 0301 0020 0034
ē 3 => 119D 0209 113A 0000 0020 005B 0020 0020 0000 0002 0002 0002 0002 0000 0065 0304 0020 0033
ë 6 => 119D 0209 113D 0000 0020 0047 0020 0020 0000 0002 0002 0002 0002 0000 0065 0308 0020 0036

この場合も、次の3つの並べ替えられた結果が得られます。

e
é
è
ê
ë
ē

そして

eA
éB
ëC
èD
êE
ēF

そして

è 1
e 2
ē 3
é 4
ê 5
ë 6
— パトリック・メヴゼク
ソース
こんにちはパトリック。この詳細情報を投稿していただきありがとうございます。いくつかの注意事項：1）コードページ1252は無視できます。これは、VARCHARここでは使用されていない（非Unicode）データ用です。そのため、ēキャラクターは問題なく動作します。2）「照合チャート」情報は少し時代遅れです。これはこの照合の前バージョン用であり、2009年以降何も投稿していません。3）ここのUnicodeバージョンは間違いなく最新のものではありません（バージョン10）。_100_これは、Unicode 5.0または5.1になるように、一連の照合順序は、SQL 2008に付属している：unicode.org/standard/versions/#TUS_Earlier_Versions
— ソロモンRutzky
allKeys.txt 新しい文字の追加を除いて、Unicodeバージョン間の変更はないと思いますので、上記は真のままである必要がありますが、もちろん以前の古いデータでやり直すことができます。CP1252に関しては、MS-SQLで指定された定義に基づいています（この製品は自分では使用しません）。
— パトリックメヴゼク
1）バージョン間の大きな変更はおそらくないでしょうが、少なくとも重量/分類の修正があることはかなり確信しています。しかし、はい、確かに時間の制約があります;）2） CP1252に関しては、Unicodeにはコードページの概念が存在しないため、言及していました。Unicodeは、コードページを必要としない手段です。MS docはこれについては明らかに不明ですが、「非Unicode文字データを格納するために使用されるコードページ」の上部に言及しています。1文字はCP1252に含まれていませんが、コードページはここでは使用しません。
— ソロモンラツキー
はい、Unicodeに関連するコードページについては何も言いませんでした。この照合名が「コードページ1252」で機能することを示すのは、MS SQLドキュメントだけです。おそらく意味をなさないでしょう（私にとってはそうではありませんが、そのユーザーではありません）が、それはこのソフトウェアのドキュメントに書かれているものです。ジョブのやり直しについては、自由に実行するか、必要に応じて、Unicode 5以降のプレイ中のキャラクターに関連するソートに関する変更を提供してください。私の答えはそのままで、正確で、入力に基づいて結果を構築するものであり、他の方法ではないと考えています。
— パトリックメヴゼク
3） re：センテンス＃1：主にユニコードについてですが、MSが仕様を実装しており、すべてを完了していないか、ミスを犯している可能性があるため、この質問はOSの問題です。特定の文字が属する「カテゴリ」または「ブロック」を決定する方法に関する2つのバグを.NETで見つけました（小さな文字セグメントを誤認していました）。また、これは少なくともわずかにSQL Serverの問題です。これは、SQL Serverが特定の時点で各照合順序のスナップショットを効果的に持っているためです（バージョン間の一貫性のため）。
— ソロモンラツキー
16

ここで見ている動作は、一般的な意味で、Unicode Collat​​ion Algorithm（UCA）が複雑なマルチレベルのソートを許可しているという事実によるものです。すなわち：

  1. ソートは比較ではありません：

    2つの文字列が同じであるか異なるかを判断するのはかなり簡単です（特定のロケール/言語と感度のセットが与えられた場合）。ただし、2つ以上の文字列の順序を決定するのは非常に複雑です。

  2. ソートは一連のステップで行われ、各ステップは文字ごとではなく、文字列全体に適用されます。

    1. 標準：基本文字を並べ替えます（アクセントや大文字と小文字の違いに関係なく）
    2. アクセントを区別する場合は、アクセント/分音記号の重みを適用します
    3. 大文字と小文字を区別する場合は、ケーシングの重みを適用します

col1（単一文字）で並べ替えると、すべての文字が同じ「e」であるため、すべての文字の重みが同じであると最初に判断されます。次に、アクセント/発音区別符号の重みを適用します。大文字と小文字の違いはないため、3番目のステップで何も変わりません。したがって、唯一の違いはステップ2にあります。これが、に基づいてこれらの行に優先順序がある理由col1です。

col2（2文字）で並べ替えると、両方の文字が並べ替えの重み（「ea」、「eb」など）を決定するために使用されるため、最初に各行の重みが異なると判断されます。次に、アクセント/発音区別符号の重みを適用します。大文字と小文字の違いはないため、3番目のステップで何も変わりません。したがって、今回は手順1と2に違いがあります。ただし、ステップ1の重みは、ステップ2の重みが考慮される前に各文字列に既に適用されているため、ステップ2の重みは順序に影響しません。2行以上のステップ1からの重みが同じ場合にのみ適用されます。

質問からのサンプルコードの次の適応は、上記のソート動作を示しています。照合順序が大文字と小文字を区別することの影響を示すために、いくつかの行と列を追加しました（元のサンプルデータはすべて小文字であるため）。

セットアップ

USE [tempdb];

-- DROP TABLE dbo.OddSort;
CREATE TABLE dbo.OddSort
(
    id INT IDENTITY(1,1) PRIMARY KEY,
    col1 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS,
    col2 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS,
    col3 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS
);
GO

INSERT dbo.OddSort (col1, col2, col3)
VALUES (N'e', N'eA', N'e A')
     , (N'ê', N'êE', N'ê E')
     , (N'é', N'éH', N'é H')
     , (N'ë', N'ëC', N'ë C')
     , (N'E', N'EG', N'E G')
     , (N'Ë', N'ëh', N'ë h')
     , (N'è', N'èD', N'è D')
     , (N'é', N'éB', N'é B')
     , (N'ë', N'ëH', N'ë H')
     , (N'ē', N'ēF', N'ē F');

テスト1

SELECT [id], [col1], UNICODE([col1]) AS [CodePoint]
FROM dbo.OddSort 
ORDER BY col1;

戻り値：

id    col1    CodePoint
1     e       101
5     E       69
8     é       233
3     é       233
7     è       232
2     ê       234
4     ë       235
9     ë       235
6     Ë       203
10    ē       275

上記の結果で見ることができるもの：

  1. コードポイントがソート順を決定していません
  2. アクセント記号のない文字は、アクセント記号の付いた文字の前にソートされます（同じ文字内では、これらすべての後にfが続きます）。明らかに、アクセントの重みは、ケースの重みの前に適用されます。
  3. 同じアクセント記号（または非アクセント）文字内の大文字（すなわち前小文字の種類Eその後、E、およびëその後、Ë）。この調整はほとんどのWindows照合順序で使用されますが、ほとんどのSQL Server照合順序は大文字を最初にソートします。

テスト2

SELECT [id], [col2]
FROM dbo.OddSort 
ORDER BY col2;

戻り値：

id    col2
1     eA
8     éB
4     ëC
7     èD
2     êE
10    ēF
5     EG
3     éH
6     ëh
9     ëH

上記の結果で見ることができるもの：

  1. 第1レベルの並べ替えは、基本文字です。アクセント/発音区別符号である場合、ëC（id = 4）、ēF（id = 10）、およびEG（id = 5）の行は存在しません。ケーシングの場合、EG（id = 5）行は現在の場所ではありません。
  2. 第二レベルのソートは、本当にアクセント/発音区別符号です。これが、最後の3行がëh- > éH- > ëHではなくéH- > ëh- > ëH（つまり、IDが3-> 6-> 9-> 9-> 9ではなく9）である理由を説明しています。
  3. 第三レベルのソートは、まさにケーシングです。これが、小文字のソートが最初であるため、最後の2行がëh- > ëHである理由です。

テスト3

SELECT [id], [col3]
FROM dbo.OddSort 
ORDER BY col3;

戻り値：

id    col3
1     e A
8     é B
4     ë C
7     è D
2     ê E
10    ē F
5     E G
3     é H
6     ë h
9     ë H

上記の結果で見ることができるもの：

  1. ソート順はテスト2とまったく同じです。ここでのテスト値の唯一の違いは、各文字の間にスペースがあり、コンテキストルールの可能性を排除していることです。したがって、col2質問のソート順序の違いの理由は、「コンテキスト依存性」ではなく「マルチレベル比較」によるものであることがわかります。

その他の注意事項：

  1. 正確なルールを取得することに関して、それはそうあるべきほど簡単ではありません。これらの規則の具体的な説明を取得する際の問題は、Unicodeの並べ替え規則が明確に文書化されている一方で推奨事項であることです。これらの推奨事項を実装するのは、Microsoftなどのベンダー次第です。マイクロソフトは、Unicodeのドキュメントに記載されているとおりに推奨事項を実装しなかったため、そこに断線があります（HTMLまたはCSS仕様が完全に、またはベンダー間で同じように実装されていないのに似ています）。次に、Windows照合のさまざまなバージョンがあり（100SQL Server 2008に付属のバージョンを使用しています）、現在のバージョンのUnicodeまたはICU照合デモよりもはるかに古いUnicodeバージョンに関連付けられています使っている。たとえば、SQL Server 2008の「照合とユニコードのサポート」ドキュメントの「SQL Server 2008照合の新機能」セクションでは、照合の_100_シリーズの「新規」について2つの非常に興味深い点を挙げています。

    1. Unicode 5.0のケーステーブル。

      Unicode 5.0は2006年7月に公開されました（文字データベースがリリースされ、2006年後半に完全な仕様が続きました）。現在のバージョンは10.0で、2017年6月に公開されました。また、過去4年間のリリースパターンを考えると、バージョン11.0は2018年半ばにリリースされる可能性があります。

    2. 同等に比較されていた、以前に重み付けされていない文字に重み付けが追加されました。

      これらの重みはUnicode規格で定義されている可能性が高く、その実装ではありません。

     
    それでも、上記のリンクされたUCAのドキュメントは開始するのに適した場所です。

  2. Windows / .NET / SQL Serverで使用されるソートキーは、Unicode標準（@Patrickの回答を参照）に示されているものとまったく同じではなく、ICUに実装されています。Windows / .NET / SQL Serverが使用しているものを確認するには、CompareInfo.GetSortKey Methodを試してください。これらの値を渡してソートキーを取得するSQLCLR UDFを作成しました。.NET Framework 4.5-4.6.1がインストールされたWindows 10でSQL Server 2017を使用しているため、.NET ではUnicode 6.0.0を使用する必要があります。また、これらの文字列にはLevel4は使用されていません。

    CHAR    L1     L2     L3     L4
e      0E21
E      0E21           12
ë      0E21    13
Ë      0E21    13     12

    テスト1のこれらの並べ替えキーを見て、レベルがORDER BY句内の複数の列のように並べ替えられていること（L3はL2の同じ値内に並べ替えられ、L1の同じ値内に並べ替えられます）が動作の理由を説明するはずです質問で指摘されているのは、実際にはユニコードのマルチレベルのソート機能です。同様に：

    CHAR       L1         L2       L3       L4
EG      0E210E25              1212
éH      0E210E2C      0E      0212
ëh      0E210E2C      13
ëH      0E210E2C      13      0212

    テスト2のソートキーの一部を見ると、ベース文字が最初にソートされ（L1）、次にアクセントがソートされ（L2）、次に大文字小文字がソートされている（L3）ことがわかります。

  3. データ型はNVARCHARであるため、Unicodeコードポイントと並べ替えアルゴリズム、つまりUNICODE()TEST 1 での関数の使用のみに関係しVARCHARます。コードページはほとんどの照合で指定されますが、データにのみ関係します。意味、コードページ1252はLatin1_General*つまり一連の照合順序ここでは無視できます。

  4. デフォルトのUnicode Collat​​ion Element Table（DUCET）（シリーズCollat​​ionsにマップする必要があるバージョン5.0.0）で説明されている重みは、_100_米国英語では問題ありませんが、他のロケール/言語では問題ありません。他の言語では、DUCETで開始してから、Common Locale Data Repository（CLDR）プロジェクトで定義されているロケール固有のオーバーライド規則を適用する必要があります。私の知る限り、バージョン1.4 / 1.4.1は2006年にリリースされました。これらのオーバーライドを取得するには、http：//unicode.org/Public/cldr/1.4.0/core.zipからCLDR 1.4 "core"ファイルをダウンロードしてください。、次にそのzipファイルで照合フォルダーに移動し、使用されているロケールに対応するXMLファイルを見つけます。これらのファイルにはオーバーライドのみが含まれており、照合ルールの完全なセットではありません。

— ソロモン・ラツキー
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.