8768 sujets

Développement web côté serveur, CMS

[Résolu] [MySQL] Quel ut8mb4 choisir ?

Bonjour à tous, une petite question me taraude, je viens de mettre à jour mon phpmyadmin en local (sur wamp) et sur la nouvelle mouture, le charset par défaut n'est plus UTF8 (enfin), mais UTF8MB4.

Ma question est la suivante, j'utilise depuis plusieurs années l'UTF8MB4_UNICODE_CI sur tous mes projets. Là, celui par défaut est autre, UTFMB4_0900_AI_CI.

Quelle différence ?

Dois-je migrer mes projets futurs (et actuels) vers ce dernier ?

En vous remerciant d'avance (oui, j'ai conscience que ca revient à questionner le sexe des anges Smiley rolleyes )
Modifié par C@scou (07 Mar 2024 - 11:07)
Modérateur
Bonjour,

J'imagine que c'est de MySQL dont tu parles.

Ce qu'il y a après le UTF8MB4 concerne la manière dont on fait les comparaisons et les tris "alphabétiques". On appelle ça "collation" en anglais.

UTF8MB4_UNICODE_CI signifie encodage en UTF8MB4 (UTF8 jusqu'à 4 caractères), collation effectuée selon l'ordre défini par le consortium UNICODE sans faire référence à une version (unicode en a publié plusieurs et ça continue d'évoluer, mais ça ne concerne que des caractères bizarres pour nous a priori) ou une langue en particulier, et CI ("case insensitive").

UTFMB4_0900_AI_CI signifie encodage en UTF8MB4, collation effectuée selon l'ordre défini par le consortium unicode dans sa version 9.0.0, AI ("accent insensitive") et CI ("case insensitive").

La différence essentielle est donc ici "accent incensitive" (c'est à dire par exemple que "a"="à"). Tu peux très probablement rester avec ton ancien paramétrage, ou passer au nouveau paramétrage par défaut sans que ça ait beaucoup d'importance dans les résultats que tu obtiens (mais il n'y a que toi qui peut déterminer si c'est critique ou pas selon ce que tu bricoles avec ta base de données). Et l'encodage lui-même est fondamentalement le même de toutes façons.

Le support des différentes options (version unicode ou langue, ai, ci) et leur combinaison éventuelle peut dépendre du système de base de données que tu utilises.

Référence pour mySQL : https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html

Amicalement,
Meilleure solution
Salut Parsimonhi et merci pour ton retour. Oui effectivement il s'agit de MySQL. Smiley cligne
J'ai du mal à comprendre comment peut on avoir la casse ou les accents insensibles dans le cas présent. Je veux dire si j'entre un accent, il encode et enregistre bien un accent, pas juste une lettre simple ?
A moins que ce soit pour les opérations de comparaison / recherche ?
Ce qui rendrais cet encodage Ai plus intéressant car généralement on ne souhaite pas qu'un moteur de recherche s'arrête à des différences d'accents.
Ce qui voudrais dire également qu'avec mon encodage actuel un WHERE ignore la casse ?
J'ignore si c'est précisé dans le lien que tu as mis, je me bouquinerais tout ça quand j'aurais davantage les yeux en face des trous.

Encore merci pour ton retour. Smiley smile
Modérateur
Bonjour,
C@scou a écrit :
J'ai du mal à comprendre comment peut on avoir la casse ou les accents insensibles dans le cas présent. Je veux dire si j'entre un accent, il encode et enregistre bien un accent, pas juste une lettre simple ?
A moins que ce soit pour les opérations de comparaison / recherche ?

Oui, c'est uniquement pour les opérations de comparaison / rechercher et tri que les "options" ai et ci ont de l'importance.

Ce qui est enregistré dans la base contient bien entendu les accents, les majuscules, et est encodé en UTF8MB4 (en gros, tous les caractères possibles). Que tu utilises UTF8MB4_UNICODE_CI ou UTFMB4_0900_AI_CI, c'est pareil de ce point de vue.

EDIT:
C@scou a écrit :
Ce qui voudrais dire également qu'avec mon encodage actuel un WHERE ignore la casse ?
Ça dépend. Il y a ce qui se passe par défaut, et ce que fait effectivement une requête donnée selon les clauses que tu y mets. Lire https://dev.mysql.com/doc/refman/8.0/en/case-sensitivity.html

Amicalement,
Modifié par parsimonhi (14 Mar 2024 - 08:58)
Oui effectivement, j'ai un usage assez "par dessus la jambe" de MySQL. Du genre à passer sur InnoDB sans vraiment comprendre ce qu'est une clé étrangère, puis finalement repasser à MyISAM X années plus tard en tombant sur un article qui explique que la perte de perf c'est pas 0.5% mais beaucoup plus. xD

Déjà ma migration sur mysqli c'était un grand chantier très traumatisant il y a quelques années. ^^'
Et je suis toujours pas entièrement dépêtré de la portée de la variable de bdd qui parfois est hors scope d'une page ou d'un script AJAX à l'autre et m'oblige à basculer cette dernière en $GLOBALS.

Et je parle pas de la découverte des jointures il y a dix ans après 10 ans passés à imbriquer des requêtes les unes dans les autres (ce qui m'arrive encore quand je pige pas comment obtenir le même résultat en jointure Smiley lol ).

Enfin bref, merci pour les liens, je vais me bouquiner tout ça dès que je sort un peu du rush.
Passe un bon week-end.
Prévenir un modérateur
Répondre au sujet
Aller à