Envoyé par
esperanto
Un autre point que je connaissais mais que l'article m'a rappelé (section 1): toutes les collations ICU implémentent l'équivalence canonique, donc 'é' = 'é' (ça ne se voit pas mais la chaîne de gauche contient en réalité deux caractères Unicode, l'accent étant codé séparément de la lettre principale). Est-ce le cas des collations SQL Server? Pour en revenir au LIKE, est-ce que _ devrait accepter é mais refuser é (qui contient 2 caractères), alors que = l'accepterait? Vous voyez, ce n'est pas simple...
Merci à escartefigue d'avoir parlé de DB Fiddle, que je ne connaissais pas. Alors du coup j'ai cherché un équivalent SQL Server et j'ai trouvé SQL Fiddle, qui supporte MS SQL Server 2017.
Alors allons-y:
1 2 3 4
|
CREATE TABLE T_ACCENTS (ID INT IDENTITY PRIMARY KEY,
DATUM VARCHAR(256) COLLATE French_CS_AI);
insert into t_accents(datum) values ('é'); |
Précision importante, le contenu de la chaîne qui apparaît comme e&769; est en fait un é encodé sur 2 caractères: le &769; correspond au point Unicode 769, ou en hexadécimal 0301, qui correspond à l'accent aigu dans les diacritiques génériques.
Du coup en Unicode é a deux représentations, une sur 1 caractère et une sur 2. La seconde rend les traitements linguistiques plus facile, mais elle prend évidemment plus de place.
C'est la balise CODE du forum qui le montre sous cette forme: moi j'ai utilisé un convertisseur Unicode pour insérer réellement le caractère accent aigu dans le texte.
Et maintenant :
select * from t_accents where datum = 'é'
avec cette fois un é sur 1 caractère...
ne donne aucun résultat !!!
Maintenant le même test avec PostgreSQL :
1 2 3 4 5 6 7 8
|
testICU=# insert into t_accents2 (datum) values ('é');
INSERT 0 1
testICU=# select * from t_accents2 where datum='é';
id | datum
--------+-------
100015 | é
(1 row) |
En fin de compte, heureusement que la balise CODE du forum transforme l'accent, on voit bien qu'ici, ça marche. Et hop, voici donc une fonction des collations ICU non supportée par SQL Server et son French_AI_CI !!!
Au passage ça explique bien pourquoi le support du LIKE et surtout de son joker _ est compliqué: si j'ai le mot 'été' dans la base mais sous sa forme canonique (2 caractères) et que je cherche avec LIKE '_té', alors ça devrait être rejeté alors que = 'été' (sans forme canonique) devrait être accepté. Et j'imagine que c'est pas le genre de choses faciles à expliquer à un utilisateur...
SQL Pro vantait le mérite de Microsoft de supporter ça depuis 22 ans... alors qu'en fait ils sont restés aux conventions de l'époque, quand les formes canoniques Unicode n'en étaient encore qu'à leurs balbutiements !!!
Partager