Discussion :

[JulienDev75]

Bonjour

Auriez vous un tuto ou cours clair sur l'interclassement en SQL ?
J'ai trouvé des choses évidemment sur le web mais ce n'est pas toujours clair... Ou alors je sature et j'ai besoin de parler à qqun

J'utilise phomyadmin

Merci

[proctl081]

Hello

T'as pas du chercher beaucoup... Ce n'est pourtant pas une notion complexe...

Tu as des tutos a foison sur YT notamment :

Bonne recherche

[escartefigue]

Il y a un article de SQLPro sur les collations (ou interclassements) ICI

[JulienDev75]

Ok merci je vais aller voir ça...

[Artemus24]

Salut à tous.

La seule question que tu dois te poser est celle de la langue que tu vas utiliser.
Si, comme je le suppose, tu vas utiliser le français et pourquoi pas l'anglais, tu dois utiliser LATIN1 et LATIN1_GENERAL_CI.
Si au contraire, tu vas utiliser le chinois, l'arabe ou une langue utilisant un alphabet particulier, il faut trouver le bon jeu de caractères.
Il en existe un qui répond à ce problème, qui est UTF8MB4 et UTF8MB4_GENERAl_CI.

En dehors de cela, tu peux vouloir faire la distinction entre les minuscules ou les majuscules, voire de trier dans un ordre particulier.
Alors oui, il existe d'autres collation qui peuvent répondre à cette attente. Je ne pense pas que ton besoin est de cet ordre là.

Il faut savoir que l'UTF8MB4 utilise de 1 à 4 octets pour stocker 1 caractère, ce qui peut provoquer inutilement des problèmes dans la longueur des chaînes de caractères, ce que tu n'auras pas avec le LATIN1 puisque 1 caractère = 1 octet.

Cordialement.
Artemus24.
@+

[Séb.]

Si, comme je le suppose, tu vas utiliser le français et pourquoi pas l'anglais, tu dois utiliser LATIN1 et LATIN1_GENERAL_CI.

Sûrement pas. Il faut utiliser utf8mb4 et utf8mb4_0900_ai_ci, les paramètres par défaut de MySQL.
Cela permet de gérer (presque) tout type de caractères sans problèmes. Utiliser du Latin-1 est une grosse régression.
Tout est expliqué ici => https://dev.mysql.com/doc/refman/8.0/en/charset.html

Il faut savoir que l'UTF8MB4 utilise de 1 à 4 octets pour stocker 1 caractère, ce qui peut provoquer inutilement des problèmes dans la longueur des chaînes de caractères

Il faut utiliser les bonnes fonctions :
-- LENGTH() = nombre d'octets
-- CHAR_LENGTH() = nombre de caractères

Les autres fonctions comme SUBSTRING() ou POSITION() gèrent cela de manière transparente.

[Artemus24]

Il n'y a aucune régression à utiliser le Latin1 (ou ISO-8859-1) puisque tu as tous les caractères dont tu as besoin pour écrire en français. Je ne vois pas ce que l'UTF8 peut t'apporter en plus.
L'inconvénient de l'UTF8 est de produire une volumétrie supérieure à celle du Latin1 pour la même quantité de caractères dans un texte.
Le "SET NAMES" par défaut est en Latin1, pas en UTF8. Tout comme la collation par défaut est Latin1_Swedish_ci.

[SQLpro]

Salut à tous.

La seule question que tu dois te poser est celle de la langue que tu vas utiliser.
Si, comme je le suppose, tu vas utiliser le français et pourquoi pas l'anglais, tu dois utiliser LATIN1 et LATIN1_GENERAL_CI.

Non, car pour le français le tri sera incorrect. Il faut utiliser une collation française. Pour l'anglais LATIN1 c'est OK, car pas d'accents. Pour un mélange de langues latines, il faudra piloter les tris en ajoutant une clause COLLATE fonction de la langue manipulée...

A +

[SQLpro]

Sûrement pas. Il faut utiliser utf8mb4 et utf8mb4_0900_ai_ci, les paramètres par défaut de MySQL.
Cela permet de gérer (presque) tout type de caractères sans problèmes. Utiliser du Latin-1 est une grosse régression.
Tout est expliqué ici => https://dev.mysql.com/doc/refman/8.0/en/charset.html


Il faut utiliser les bonnes fonctions :
-- LENGTH() = nombre d'octets
-- CHAR_LENGTH() = nombre de caractères

Les autres fonctions comme SUBSTRING() ou POSITION() gèrent cela de manière transparente.

Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère... Ce qui limite par exemple les index à environ 256 caractères....

Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...

A +

[Séb.]

Il n'y a aucune régression à utiliser le Latin1 (ou ISO-8859-1) puisque tu as tous les caractères dont tu as besoin pour écrire en français. Je ne vois pas ce que l'UTF8 peut t'apporter en plus.

Si si, il y a bien une régression puisque le paramétrage par défaut depuis des années est UTF-8 et qu'avec Latin-1 tu te LIMITES aux caractères dudit charset, un sous-ensemble. Pire, tu décrètes que JulienDev75 DOIT utiliser Latin-1 sans même connaitre son besoin.
UTF-8 permet d'utiliser n'importe quels caractères et autres emojis pour un coût faible. Il y a 1 an j'ai dû utiliser des caractères polonais, grâce à UTF-8 des Ł et des Ę n'ont posé aucune difficulté.

Le "SET NAMES" par défaut est en Latin1, pas en UTF8. Tout comme la collation par défaut est Latin1_Swedish_ci.

Il n'y a pas de SET NAMES par défaut côté serveur. Il y a des paramètres serveur par défaut, tous en UTF depuis des années. Il y a aussi des serveurs et des clients mal paramétrés. Les mauvais réglages client peuvent être outrepassés par le serveur.

Pour l'anglais LATIN1 c'est OK, car pas d'accents.

Il existe des mots ayant des caractères accentués dans le dico anglais, des restes du Français.
Je suppose que les anglais/américains s'en soucient encore moins que nous.

Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère...

La doc dit :

MySQL supports these Unicode character sets:
-- utf8mb4: A UTF-8 encoding of the Unicode character set using one to four bytes per character.
-- utf8mb3: A UTF-8 encoding of the Unicode character set using one to three bytes per character. This character set is deprecated in MySQL 8.0, and you should use utfmb4 instead.
-- utf8: An alias for utf8mb3. In MySQL 8.0, this alias is deprecated; use utf8mb4 instead. utf8 is expected in a future release to become an alias for utf8mb4.

Ton affirmation me semble au mieux datée. Je suis preneur de toute doc technique à ce propos.

Ce qui limite par exemple les index à environ 256 caractères....

Peut-être un mal pour un bien.

Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...

Il ne manque plus que l'argument écologique. Bref, je ne vois pas ce qu'il y a d'artificiel, c'est le comportement normal et connu d'UTF-8 => Le texte pèse davantage. J'accorde qu'il pèse tellement plus pour certains jeux de caractères exotiques que cela limite son utilisation face à des jeux spécialisés. Avec nos caractères latins on n'a pas à se plaindre.

[binarygirl]

Il n'y a aucune régression à utiliser le Latin1 (ou ISO-8859-1) puisque tu as tous les caractères dont tu as besoin pour écrire en français. Je ne vois pas ce que l'UTF8 peut t'apporter en plus.

C'est plus simple de tout faire en UTF-8. Même si on n'utilise que du français, ce ne sera pas forcément vrai demain et de toute façon il y aura toujours des éléments qui sortent du cadre.
Je m'en suis rendue compte il y a quelques années avec une application pour recueillir des commentaires bruts, où il y avait des smilies, des émojis... On aurait pu essayer de filtrer ce genre de chose (encore que, ce n'est pas si simple !) mais la volonté était vraiment de ne rien modifier aux commentaires reçus.

Il faut prendre en considération le front-end aussi. Si on a une application web moderne, les pages HTML et donc les formulaires seront habituellement en UTF-8. Si on envoie de l'UTF-8 à une DB qui tourne dans un charset différent, on risque d'avoir des problèmes avec les accents, en clair des pertes de données et de sens, à moins de gérer la conversion en amont, ce qui n'a pas de valeur ajoutée. Il faut penser ce problème de charset (et de collation) du début de la chaîne jusqu'à la fin.

[escartefigue]

Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère... Ce qui limite par exemple les index à environ 256 caractères....

Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...

A +

Il me semble que ce problème a été corrigé avec la version 8 de MySQL, me fourvoyais-je ?

[Artemus24]

Salut à tous.

@ JulienDev75 : le mieux est de consulter le Blog de SQLPRO à ce sujet.

@ SQLPRO : je préfère de loin utiliser le LATIN1 dans mes bases de données car il répond à mes besoins.
Tout comme sous Windows, j'utilise windows-1252 qui est une adaptation du latin1, enfin je devrais plutôt parler de l'ISO-8859-1.

Mon principale critère est d'avoir la volumétrie la plus faible en fonction des caractères utilisés.
Pour ce qui est du tri, je n'ai pas constaté de gros problèmes dans le respect de l'ordre de classement du français.
Pour ce qui est de la casse, je préfère un tri sans accents et de ce fait "latin1_general_ci" me convient.

Il faut utiliser une collation française.

A quoi pensez vous en disant cela ?

Non, l'UTF8 est très mal géré par MySQL qui utilise systématiquement 3 octets pour 1 caractère...

D'où ma préférence dans le choix du Latin1 puisque 1 caractère = 1 octet et répond à une volumétrie plus faible que l'UTF8.

Cela enfle artificiellement les bases et rejaillit immanquablement sur les sauvegardes, la maintenance, etc...

Entièrement d'accord.

et qu'avec Latin-1 tu te LIMITES aux caractères dudit charset, un sous-ensemble.

Pourquoi voulez vous m'imposer l'UTF8 alors que le LATIN1 répond à mes besoin ?
Je n'ai besoin que des caractères utilisés dans la langue française et de l'anglais.
Je n'ai aucun besoin d'un alphabet différent du latin.

Pire, tu décrètes que JulienDev75 DOIT utiliser Latin-1 sans même connaitre son besoin.

Je n'ai rien décrété du tout. J'ai juste dit que la seule question que l'on doit se poser est le choix de la langue utilisée.

UTF-8 permet d'utiliser n'importe quels caractères et autres emojis pour un coût faible.

Comme SQLPRO le fait remarquer, et moi-même, le cout en volumétie n'est pas du tout faible.

Il y a 1 an j'ai dû utiliser des caractères polonais, grâce à UTF-8 des L et des E n'ont posé aucune difficulté.

Parce que votre problème est différent du mien. Je ne comprends cette volonté de vouloir tout faire en UTF8 même quand cela pose des problèmes de volumétie.

Il n'y a pas de SET NAMES par défaut côté serveur.

Vu votre réflexion, je crois que vous n'avez pas compris à quoi sert le SET NAMES.
Quand on envoie un jeu de caractères vers le serveur MySql, le client MySql doit préciser par le paramètre "SET NAMES", le jeu de caractères utilisés.
Si ce CHARSET n'est pas pris en charge par le serveur, celui-ci va considérer que c'est le CHARSET par défaut qui sera utilisé.
Lisez cette page MySql consacré aux erreurs des charset de connexions.

C'est plus simple de tout faire en UTF-8.

C'est la solution de facilité.

Si on a une application web moderne, les pages HTML et donc les formulaires seront habituellement en UTF-8.

J'utilise WampServer et tout est en latin1. C'est normal car c'est moi qui gère cela.
Ce n'est pas forcément le cas chez un hébergeur qui ne va pas faire de la spécificité pour un client.

Il faut penser ce problème de charset (et de collation) du début de la chaîne jusqu'à la fin.

C'est ce que j'ai fait et chez moi, ça fonctionne bien.

Il me semble que ce problème a été corrigé avec la version 8 de MySQL, me fourvoyais-je ?

La norme est au UTF8MB4 qui utilise au maximum 4 octets pour coder 1 caractère.
Avec un moteur InnoDB, la limite est de 767 octets, ce qui correspond à 255 caractères en UTF8 et à 191 en UTF8MB4.

Comment trouve-t-on ces deux nombres :
767 / 3 = 255,66.
767 / 4 = 191,75.
ce qui voudrait dire que MySql prend systématiquement 3 octets en UTF8 et 4 octets en UTF8MB4.
Et après vous vous demandez pourquoi je n'utilise pas UTF8.

Cordialement.
Artemus24.
@+

[binarygirl]

J'utilise WampServer et tout est en latin1. C'est normal car c'est moi qui gère cela.

latin1 character est le charset par défaut dans MySQL jusque 5.7. A l'origine c'était même latin1_swedish_ci, puisque le produit vient de Suède...
Aujourd'hui le charset par défaut dans MySQL 8 est utf8mb4.

De nos jours, je ne suis pas sûre que l'argument de la volumétrie est déterminant, surtout avec le storage qui est bon marché, les disques SSD qui deviennent la norme, et le cloud et les snapshots incrémentaux...

Quand je fais un dump Mysql à backuper, je le zippe d'abord. Et je ne suis pas certaine que le résultat final sera très différent selon que les tables sont définies en latin1 ou utf8mb4, mais c'est un test qu'on peut faire.

En réalité, c'est rare qu'on ne traite qu'une seule langue à la fois. En fait, on ne le remarque pas car même en étant en CP1252 (ou ISO-8859-1), on peut encaisser pas mal de caractères non-français.
Même si c'était vrai ce ne sera pas forcément le cas demain.
Sur les sites que je gère il y a des clients de monde entier, et ils ne se privent pas de mettre leur adresse dans leur alphabet natif (ex: coréen). D'ailleurs il est malaisé pour eux de faire autrement car ils n'ont pas le même clavier que nous.

Toutefois, la question du stockage des données est distincte de la collation à appliquer.

[SQLpro]

Encodage et stockage sont deux choses différentes. L'encodage UTF8 est à "pas variables". Certaines lettres (les 128 du jeu ASCII de base) sur 1 octet, d'autres (latin, grec et cyrillique) sur 2 octets, langues orientales, arabe, hébreu... sur trois octets... et ainsi de suite. Cependant et pour des raisons de tri, classement, comparaisons, unicité en fonction de la collation, MySQL ramène tout à 3 octets ou 4 suivant le jeu choisi.... par caractères...

Lire : 10.9.1 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)

A +

[Artemus24]

Aujourd'hui le charset par défaut dans MySQL 8 est utf8mb4.

Je suis en MySql version 8.0.33.
Si je regarde le CHARSET du système (character_set_system), il est en "UTF8MB3" et je ne peux pas le modifier.
Ce qui est en défaut mais modifiable est le CHARSET "UTF8MB4" de la création des bases de données.

Si tu stockes des émoticônes, tu es obligé d'utiliser la collation "UTF8MB4". Ils sont stockés sur 4 octets.

En réalité, c'est rare qu'on ne traite qu'une seule langue à la fois.

La langue internationale est l'anglais, ma langue maternelle est le français, ça fait deux.
Chez un hébergeur, il est plus facile de tout mettre en "UTF8MB4".
En ce qui me concerne, je ne vais pas commencer à utiliser le chinois, l'arabe, le cyrillique, ou l'araméen, et je ne sais quoi d'autres comme alphabet que je ne connais pas.

La langue est une barrière, surtout si l'on n'arrive pas à la lire à cause de son alphabet. En dehors de sa langue maternelle et de la langue internationale, je me demande s'il existe des combinaisons de plusieurs langues sur des sites, dans le cadre professionnel.

[binarygirl]

La langue est une barrière, surtout si l'on n'arrive pas à la lire à cause de son alphabet. En dehors de sa langue maternelle et de la langue internationale, je me demande s'il existe des combinaisons de plusieurs langues sur des sites, dans le cadre professionnel.

Bien sûr, les forums internationaux, les réseaux sociaux où chacun converse dans sa langue et son alphabet... ainsi que les sites e-commerce. Par exemple, sur le chat du service clientèle, toutes sortes de langues sont utilisées. On ne peut certainement pas se limiter à l'alphabet latin.

Et il y a aussi les emojis.

Ou alors il faut expliquer aux clients/utilisateurs pourquoi leur input (dans les zones "texte libre") n'est pas enregistré correctement sur le site et qu'ils se retrouvent avec de la bouillie dans leur texte parce que certains caractères ne passent pas. Ce qui est une cause de frustration. Les utilisateurs s'en fichent de nos soucis de volumétrie, de chatset ou des choix techniques, ils veulent juste que ça maaaarche

[SQLpro]

Tout dépend donc des utilisateurs (langue, culture...) de la nature du dev (web ou Win form) et des développeurs, qui pour la grande majorité ne savent pas programmer des composants qui limitent la saisie à l'essentiel...

A +