Discussion :

[alassanediakite]

Salut
Ton problème doit venir de psql. J'utilise jamais cet outil, mais je pense qu'il y a une possibilité de changer son encodage.
@+

[MaximeCh]

Salut
Ton problème doit venir de psql. J'utilise jamais cet outil, mais je pense qu'il y a une possibilité de changer son encodage.
@+

Au oui, merci! C'est sûr que déjà psql sans 'set default encoding=UTF-8'... mais alors psql depuis powershell
Ca a été l'occasion de découvrir en plus HeidiSQL.

[alassanediakite]

Salut

mais alors psql depuis powershell

jamais utilisé!
Essaye pgAdmin ou DBeaver
@+

[MaximeCh]

Essaye pgAdmin ou DBeaver

Je connais les deux et oui tu as raison pgadmin était déjà installé sur ma machine par enterprisedb , essaie sinon pgModeler!

[alassanediakite]

...oui tu as raison pgadmin était déjà installé sur ma machine par enterprisedb

ça marche ou pas?

essaie sinon pgModeler!

pourquoi?
@+

[MaximeCh]

ça marche ou pas?

Oui tout marche bien!

pourquoi?

Parce que j'ai passé pas mal de temps à aider pour ce projet donc je fais un peu de pub!

[esperanto]

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 !!!

Dans le charset windows-1252 le "é" est un e avec un accent dessus, pas un e avec un accent à côté qu'on recolle ensuite dessus en post-production.
Par conséquent, il est parfaitement normal que SQL Server ne comprennent pas ce qu'est ce caractère supplémentaire, puisqu'il est en dehors de la plage du charset utilisé (ce sont mêmes deux caractères, tous deux non imprimables, le 1 (NUL) et le 3 (STX)

Sauf erreur de ma part, ni les caractères japonais ni les caractères demi-largeur comme ² ne sont dans windows-1252, et pourtant les collations French_* de SQL Server ont des flags pour modifier le traitement de ces caractères. Étonnant non?
En réalité, SQL Server fonctionne désormais en UTF-16 par défaut. Par contre il continue d'appliquer les algorithmes qui ont été écrits du temps où c'était la plage windows-1252 qui était utilisée, c'est bien ce que je dis dans le passage que tu cites.

Bizarrement, autant je pourrais être en accord avec Microsoft sur ce point:

Microsoft à dit dès le début que UTF 8 était un scandale pour toutes les langues non latines... Cela allait immanquablement générale de multiples problèmes de performances laissant toutes les langues sauf l'anglais sur le carreau. MS n'a pas voulu pendant très longtemps de l'UTF8... Ils viennent enfin de le mettre, mais cela n'est pas une bonne chose. La masse populaire, bien crétine veut de l'UTF8.... très bien, faisons comme marie Antoinette !!! Puisqu'ils n'ont pas de pain, qu'ils mangent des brioches....

antant quand je vois que Microsoft utilise UTF-16 avec des algorithmes prévus pour windows-1252, désolé ça sent le grand n'importe quoi.

A savoir qu'au final, un "e accentué", ou un "e avec un accent en plus qu'un rajoute au dessus", ça ne change rien :
- à la lecture
- à la signification du caractères dans la culture courante

Et donc ne devrait aucunement impacter le résultat d'une comparaison

Exact: aussi bien dans un = que dans un ORDER BY, la version 1 caractère et la forme canonique donnnent le même résultat (sous PostgreSQL, voir le test précédent)

: ce n'est donc pas une raison recevable, selon moins, pour le non support du LIKE.

Quand tu utilises l'opérateur =, aussi bien à gauche qu'à droite du signe = chaque caractère est à considérer dans son sens littéral, donc dépendant de la langue courante. Pour le ORDER BY, c'est pareil, puisqu'il utilise les opérateurs = et <=

Par contre dans un LIKE, certains caractères ont un sens particulier: la définition du joker _ relève d'une convention informatique, pas linguistique. Au sens strict ce qui est à droite du LIKE n'est même plus une vraie chaîne de caractères mais un motif, un peu comme une expression régulière mais en plus simple. Et par voie de conséquence le LIKE n'est pas une comparaison (on compare toujours des éléments de même type) mais une recherche de motifs.
Tu vas sans doute dire que je joue sur les mots et que le LIKE devrait se comporter comme = et ORDER BY. Mais c'est justement si on veut qu'ils se comportent de la même façon que le LIKE devient plus compliqué à implémenter dès lors que l'on sait que ICU fonctionne essentiellement avec les formes canoniques (avec séparation lettre/accent).
Ne pas oublier que le support des collations non déterministes est récent dans PostgreSQL, avant le = aurait fonctionné différemment. Et comme le prouvent les discussions de MaximeCH avec les développeurs PostgreSQL, ils n'ont pas dit qu'ils ne le feront jamais, ils n'ont juste pas voulu retarder l'arrivée des collations non déterministes juste pour être sûrs d'avoir un bon support du LIKE.
Quand j'ai fait le test avec SQL server, mon but était juste de confirmer qu'elles n'étaient pas utilisées par l'algorithme de collation (alors que c'est le cas dans ICU). Et j'ai moi-même été surpris de constater qu'elles ne fonctionnaient pas du tout.

Cela dit, je fais un EDIT aujourd'hui pour rajouter ceci:

- De l'autre, les défenseurs de PostgreSQL qui vantent les métires ICU qui permet de supporter plus de caractères (que french_ci_ai)

L'objectif n'était pas de vanter les mérites mais de chercher encore une explication aux problèmes avec le LIKE. En gros, Si les collations non déterministes ne supportent pas (encore) le LIKE c'est parce que c'est plus compliqué avec les formes canoniques et avec les collations incluant des suppressions de caractères (comme celles qui ne tiennent pas compte des ponctuations).
On peut se demander si c'était pertinent d'implémenter dès le début le support de ces options. Mais là il ne faut pas oublier une chose: la librairie ICU n'a pas été écrite pour PostgreSQL, le SGBD n'en est qu'un utilisateur parmi d'autres. Donc les concepteurs d'ICU n'avaient aucune raison de faire un autre choix parce qu'ils ne pouvaient pas savoir que ça serait un jour utilisé dans PostgreSQL et que ça pourrait poser des problèmes!
Encore une fois,

• si vous trouvez que les ambiguïtés évoquées ici et là n'existent pas, allez voir le code de PostgreSQL et implémentez vous-même les fonctions manquantes dans le LIKE, si vous y arrivez je doute que vos contributions soient refusées
• si vous trouvez l'approche Microsoft meilleure, rien ne vous empêche de rajouter un nouveau provider de collations dans PostgreSQL, et là encore, à moins qu'il fasse appel à une librairie non libre, je doute que la contribution soit refusée dans la mesure où les utilisateurs pourront choisir leur provider

et donc, si vous trouvez que c'est facile, arrêtez de jouer les "y'a qu'à" et faites le!!!

[esperanto]

Dans ton monde, probablement, mais chez 100% de mes clients, il n'y a aucun serveur Linux.
Pour la simple et bonne raison que :
- Historiquement, Linux est arrivé sur le tard dans le monde des serveurs d'entreprises. Autant 100% ou presque des "nouveaux marchés" sont pour Linux, autant l'existant est reste très majoritairement sous Windows. Quand on a un admin habitué à Windows, on n'a pas forcément envie d'investir (formation, temps, recrutement, etc.) pour aller vers Linux, surtout si les coûts Windows (1 serveur, youhou ! je suis ruiné) restent maîtrisés et qu'on n'y trouve aucun gain (si mon serveurs existant sous Windows fait l'affaire, que va-t-il faire de mieux sous Linux ? Je vais pas revendre ma barette de mémoire qui sert plus...).

Quand je suis arrivé sur le marché du travail, la plupart des serveurs hébergeant des SGBD fonctionnaient sur des Unix propriétaires. Et puis peu à peu tous les éditeurs ont cessé de les mettre à jour (le dernier étant Sun avec le rachat par Oracle) ce qui a entraîné une vague de migrations... mais vers Linux, pas vers Windows. Parce que c'était géré par des administrateurs venant du monde Unix, donc pour qui le passage à Linux était plus évident que vers Windows.
Par contre c'est vrai que le recrutement massif d'administrateurs ne connaissant que Windows a conduit à l'abandon progressif au moins des serveurs mails au profit d'Exchange, et parfois d'autres services, mais là où je suis, les SGBD résistent encore.

[Sodium]

C'est un peu normal que les admins serveurs soient plus à l'aise sous Unix. Jusqu'à Powershell, administrer un serveur Windows uniquement en ligne de commande c'était tout de même assez limité. Après Powershell... bah du peu que je l'ai utilisé, tout ce que je peux dire c'est que c'est sacrément verbeux.

Tiens, en faisant une recherche rapide par curiosité, l'équivalent de htop en Powershell : "while (1) { ps | sort -desc cpu | select -first 30; sleep -seconds 2; cls }"

[SQLpro]

Ton postgres vient d'où? Installateur tiers ou compilation maison?

Edit : je confirme le problème, avec postgresql-12.2-1-windows-x64 d'EnterpriseDB

Installer Windows Enterprise DB, tel que préconisé par le site pg.org... PGadmin 4

A +

[aieeeuuuuu]

Et maintenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from t_accents where datum = 'é'

avec cette fois un é sur 1 caractère...
ne donne aucun résultat !!!

C'est normal, vous utilisez de l'unicode dans une chaine qui n'est pas unicode... ça ne peut pas fonctionner.

en revanche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
CREATE TABLE T_ACCENTS (ID      INT IDENTITY PRIMARY KEY,
                        DATUM   NVARCHAR(256) COLLATE French_CS_AI);
insert into t_accents(datum) values (N'é');

(Notez le NVARCHAR et le N'é')

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
select * from t_accents 
where datum = 'é'

=>

| ID | DATUM |
|----|-------|
|  1 |    é |

[esperanto]

C'est normal, vous utilisez de l'unicode dans une chaine qui n'est pas unicode... ça ne peut pas fonctionner.

OK en effet je me suis trompé sur ce coup-là
Faut dire que, puisqu'on est beaucoup dans la sémantique ici, je trouve le N de NVARCHAR particulièrement inapproprié: pourquoi pas U pour Unicode? En fait le N signifiant NATIONAL aurait plutôt tendance à m'induire en erreur, parce que le code national de la France, c'est plutôt ISO-8859-15 ou éventuellement Windows-1250, alors que Unicode c'est pas vraiment national...

[SQLpro]

OK en effet je me suis trompé sur ce coup-là
Faut dire que, puisqu'on est beaucoup dans la sémantique ici, je trouve le N de NVARCHAR particulièrement inapproprié: pourquoi pas U pour Unicode? En fait le N signifiant NATIONAL aurait plutôt tendance à m'induire en erreur, parce que le code national de la France, c'est plutôt ISO-8859-15 ou éventuellement Windows-1250, alors que Unicode c'est pas vraiment national...

Cela vient de la norme SQL depuis 1986 !

En fait l'ASCII est considéré comme le support des caractères de la langue INTERNATIONALE qu'est l'anglais (au passage belle hégémonie !!!!). Toutes les autres langues disponibles dans l'UNICODE sont donc des langues NATIONALE….. D'où le N.

A +

[esperanto]

Cela vient de la norme SQL depuis 1986 !

1986, donc avant la publication de la première version d'Unicode (1991). SQL traîne donc toujours des vestiges du passé, c'est bien le COBOL des bases de données. Entre temps la plupart des langages ont soit adopté le type CHAR sur 2 octets (Java, C#) au lieu d'un, soit fait une distinction entre le CHAR à 1 octet et un type UCHAR ou WCHAR sur 2 octets (C et langages compilés en natif, généralement). Mais considérer Unicode comme national, là c'est le comble...

Au fait, j'ai pu insérer un 'é' dans un VARCHAR, donc le type VARCHAR est probablement en Windows-1250, pas en ASCII. SQL Server serait-il en dehors de la norme?

[MaximeCh]

SQL Server serait-il en dehors de la norme?

Suis tombé là dessus aujourd'hui :
http://troels.arvin.dk/db/rdbms/#legend

J'ai aussi réalisé qu'acheter le standard complet SQL 2016, ISO 9075:2016 coûte 3000 euros (et ai appris à haïr l'ISO un peu plus...), mais qu'on peut lire celui de 2011 gratuitement :
https://www.wiscorp.com/SQLStandards.html grâce à un membre du comité magnanime (chercher SQL:20nn Working Draft Documents).

[Sodium]

Et pendant qu'SQL machin s'acharne à démontrer la toute puissance de Window, Microsoft met du Linux dans ses serverurs

https://windows-azure.developpez.com...-personnalise/

[SQLpro]

...
… on peut lire celui de 2011 gratuitement :
https://www.wiscorp.com/SQLStandards.html grâce à un membre du comité magnanime (chercher SQL:20nn Working Draft Documents).

ATTENTION : aucun des documents figurant dans le cette page n'est officiel. Un document de travail n'est pas un document final; loin s'en faut !
Les PDF de l'ISO ont cette présentation :


A +

[SQLpro]

Pour information, extrait de la norme SQL IOS 9075-2 ("foundation"), § 4.2.1 :

The <key word>s NATIONAL CHARACTER are used to specify a character string data type with
a particular implementation-defined character repertoire. Special syntax (N'string') is provided for
representing literals in that character repertoire.

A +

[esperanto]

En lisant le document dans la version fournie par MaximeCH (d'accord c'est un brouillon d'une ancienne norme mais je doute que ces parties aient été réécrites entre temps), en faisant une recherche sur CHAR et VARCHAR je constate que

• NVARCHAR ne semble pas faire partie de la norme, il faudrait écrire NCHAR VARYING
• il n'est écrit nulle part que CHAR doit être en ASCII par défaut

Le choix de Microsoft d'utiliser un encodage 8 bits pour VARCHAR et 16 bits pour NVARCHAR est donc un peu curieux: j'aurais plutôt eu tendance à raisonner comme en Java ou en C#, donc faire l'inverse: utiliser CHAR et VARCHAR pour l'encodage le plus utilisé (et tu dis toi-même que Microsoft voulait pousser à l'UTF-16) et réserver NCHAR aux cas où on a une bonne raison de préférer un encodage 8 bits, pour des contraintes de place par exemple. Surtout s'il faut mettre un préfixe N à chaque fois devant les chaînes: ça pousse à ne le faire qu'en cas de nécessité (alors que la situation actuelle pousse plutôt à utiliser les encodages 8 bits).
Et au moins le sens du N serait cohérent.

Bon évidemment tu vas me sortir la raison historique, à savoir que UTF-16 est sorti bien après les premières versions de SQL Server et qu'il faut bien assurer la compatibilité... OK, l'argument est recevable quand tu as créé la base il y a longtemps et que tu veux juste la migrer d'une version à la suivante de SQL Server, mais pour les nouvelles bases, c'est autre chose. Et dans le pire des cas, la syntaxe SQL permet de spécifier l'encodage après CHAR, donc si le but est de pouvoir restaurer une sauvegarde, il suffit que celle-ci enregistre aussi quel était l'encodage par défaut de CHAR dans la base sauvegardée, de façon à pouvoir répliquer à l'identique sur une nouvelle base si besoin.

[SQLpro]

NCHAR et CHAR sont des synonymes de NATIONAL CHARACTER et CHARACTER, de même que NVARCHAR et VARCHAR sont des synonymes de NATIONAL CHARACTER VARYING et CHARACTER VARYING. Tous les SGBDR à ma connaissance les acceptent !

La définition des jeux de caractères est libre dans les limites suivantes (extrait de la norme SQL Foundation § 4.2.4) :

"
4.2.4 Named character sets
An SQL <character set specification> allows a reference to a character set name defined by a
standard, an implementation, or a user. The following SQL supported character set names are
specified as part of ISO/IEC 9075:

[…]

"
Que l'on peut traduire par :
Une spécification SQL de <character set specification> autorise une référence à un nom de jeu de caractères défini par une norme, une implémentation ou l'utilisateur.

Ensuite suit la liste des jeu de caractères définis par la norme ISO 9075... Parmi lesquels (je vous fais grâce de la liste entière sinon vous allez encore gueuler…) :

"

[…]

- ISO8BIT (or ASCII_FULL) specifies the name of a character repertoire that consists of all 255
characters, each consisting of exactly 8 bits, as specified in ISO 4873 and ISO 8859-1, including
all control characters and all graphic characters except the character corresponding to the
numeric value 0 (zero). The form-of-use is that corresponding to the coded representation of
each character by a single 8-bit byte, with no designation escape sequences for other character
sets. The default collating sequence is that corresponding to the bit combinations defined. The
ISO8BIT character set is a superset of LATIN1 and, when restricted to the LATIN1 characters,
produces the same collation and form-of-use.

— UTF16 and ISO10646 specify the name of a character repertoire that consists of every character
represented by The Unicode Standard Version 2.0 and by ISO/IEC 10646 UTF-16, where each
character is encoded using the UTF-16 encoding, occupying either 1 (one) or 2 octets.

— UTF8 specifies the name of a character repertoire that consists of every character represented
by The Unicode Standard Version 2.0 and by ISO/IEC 10646 UTF-8, where each character is
encoded using the UTF-8 encoding, occupying from 1 (one) through 6 octets.

— UCS2 specifies the name of a character repertoire that consists of every character represented
by The Unicode Standard Version 2.0 and by ISO/IEC 10646 UCS2, where each character is
encoded using the UCS2 encoding, in which each character occupies exactly 2 octets.

[…]

SQL Server est strictement conforme à l'ISO8BIT que l'on nomme couramment ASCII et pour le NCHAR/NVARCHAR est strictement conforme à l'USC2 (mea culpa).

En revanche, ni Oracle ni PostgreSQL ne reposent sur l'un des jeux de caractères décrit par la norme SQL, ce qui ne les empêche pas d'être conformes, puisque la norme laisse le choix d'une implémentation "utilisateur".

A +