Cette question n'est pas tellement liée aux bases de données mais plutôt à la gestion et aux règles Unicode.
Basé sur https://docs.microsoft.com/en-us/sql/t-sql/statements/windows-collation-name-transact-sql Latin1_General_100_CS_AS signifie: "Le classement utilise les règles de tri du dictionnaire général Latin1 et correspond à la page de code 1252 "avec le CS = sensible à la casse et AS = sensible à l'accent ajouté.
Le mappage entre la page de codes Windows 1252 et Unicode ( http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT ) affiche les mêmes valeurs pour tous les caractères avec lesquels nous traitons (sauf e avec macron qui n'existe pas dans le mappage Microsoft, donc aucune idée de ce qu'il fait avec ce cas), nous pouvons donc nous concentrer sur les outils et la terminologie Unicode pour l'instant.
Tout d'abord, faites-nous savoir précisément à quoi nous avons affaire, pour toutes vos cordes:
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
L'algorithme de classement Unicode est décrit ici: https://www.unicode.org/reports/tr10/
Jetez un œil à la section 1.3 "Sensibilité contextuelle" qui explique que le tri ne peut pas dépendre d'un seul caractère après l'autre car certaines règles sont contextuelles.
Notez également ces points en 1.8:
Le classement n'est pas une propriété des chaînes. L'ordre de classement n'est pas conservé lors des opérations de concaténation ou de sous-chaîne, en général.
Par défaut, l'algorithme utilise trois niveaux entièrement personnalisables. Pour l'écriture latine, ces niveaux correspondent grosso modo à:
alphabetic ordering
diacritic ordering
case ordering.
Mais l'algorithme en lui-même est un peu dense. L'essentiel est le suivant: En bref, l'algorithme de classement Unicode prend une chaîne Unicode d'entrée et une table d'éléments de classement, contenant des données de mappage pour les caractères. Il produit une clé de tri, qui est un tableau d'entiers 16 bits non signés. Deux ou plusieurs clés de tri ainsi produites peuvent ensuite être comparées en binaire pour donner la comparaison correcte entre les chaînes pour lesquelles elles ont été générées.
Vous pouvez afficher les règles de tri latin spécifiques ici: http://developer.mimer.com/collations/charts/latin.htm
ou plus directement et spécifiquement pour MS SQL:
http://collation-charts.org/mssql/mssql. 0409.1252.Latin1_General_CS_AS.html
Pour le e
personnage, il montre:
e E é É è È ê Ê ë Ë
Cela explique vos résultats lors de la commande, col1
sauf que ē n'existe pas dans la page de code 1252, donc je n'ai absolument aucune idée de ce qu'il en fait.
Ou si nous faisons l'algorithme Unicode à la main, en utilisant la valeur de clés de DUCET à http://www.unicode.org/Public/UCA/latest/allkeys.txt :
étape 1: Formulaire de normalisation D, donc chaque cas devient:
e => U+0065
é => U+0065 U+0301
ë => U+0065 U+0308
è => U+0065 U+0300
ê => U+0065 U+0302
ē => U+0065 U+0304
étape 2, produire des tableaux de classement (recherche dans le fichier 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]
étape 3, Formulaire de tri des clés (pour chaque niveau, prenez chaque valeur dans chaque tableau de classement, puis mettez 0000 comme délimiteur et recommencez pour le niveau suivant)
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
étape 4, Comparer les clés de tri (simple comparaison binaire de chaque valeur une par une): La quatrième valeur suffit pour toutes les trier, donc l'ordre final devient:
e
é
è
ê
ë
ē
De même pour commander sur col2
:
étape 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
étape 2: tableaux de classement
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]
étape 3: clés de tri du formulaire
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
étape 4: Comparer les clés de tri: La deuxième valeur suffit pour toutes les trier, et elle est en fait déjà en ordre croissant, donc l'ordre final est en effet:
eA
éB
ëC
èD
êE
ēF
Mise à jour : ajout du troisième cas de Solomon Rutzky, ce qui est plus délicat en raison de l'espace qui permet de nouvelles règles (j'ai choisi le "cas non ignorable"):
étape 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
étape 2, produire des tableaux de classement:
è 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]
étape 3, clés de tri du formulaire:
è 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
étape 4, comparer les clés de tri:
Fondamentalement, la troisième valeur détermine l'ordre, et elle n'est en fait basée que sur le dernier chiffre, donc l'ordre doit être:
è 1
e 2
ē 3
é 4
ê 5
ë 6
Deuxième mise à jour basée sur le commentaire de Solomon Rutzky sur les versions Unicode.
J'ai utilisé les allkeys.txt
données sur la dernière version d'Unicode à ce moment, c'est-à-dire la version 10.0
Si nous devons plutôt prendre en compte Unicode 5.1 , ce serait:
http://www.unicode.org/Public/UCA/5.1.0/allkeys.txt
Je viens de vérifier, pour tous les caractères ci-dessus, les tableaux de classement sont les suivants à la place:
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]
et:
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]
et:
è 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]
qui calcule ensuite les clés de tri suivantes:
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
et:
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
et:
è 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
ce qui donne à nouveau ces trois résultats triés:
e
é
è
ê
ë
ē
et
eA
éB
ëC
èD
êE
ēF
et
è 1
e 2
ē 3
é 4
ê 5
ë 6
VARCHAR
(c'est-à-dire non Unicode), qui ne sont pas utilisées ici. C'est pourquoi leē
personnage fonctionne très bien. 2) L'information "collation-charts" est un peu dépassée. C'est pour une version précédente de ce classement et ils n'ont rien publié depuis 2009. 3) La version Unicode ici n'est certainement pas la dernière (version 10). La_100_
série Collations est venue avec SQL 2008, donc ce serait Unicode 5.0 ou 5.1: unicode.org/standard/versions/#TUS_Earlier_Versions