Mes débuts sur MySQL

(reprise du message précédent)

Merci beaucoup
J'avais déjà modifié toutes les tables pour mettre utf8_general_ci, mais la base est créée par l'hébergeur avec latin1_general_ci et je n'a pas trouvé le moyen de modifier cette valeeur. Inutile de supprimer la base et de la renommer, j'aurais eu le même résultat.
J'ai donc ajouté la commande $pdo->exec("SET NAMES 'utf8'"); et il ne semble plus y avoir de problème, mais je vais tester ça plus à fond.
Je dois m'absenter pour quelques jours, je continuerai à mon retour.
Modifié par PapyJP (10 Jan 2019 - 09:28)

Bonjour,

Il fallait remplacer $pdo par $connexion (qui est le nom de la variable que tu emploies). Enfin bon, tu as sans doute dû le faire si ça marche).

Amicalement,

PapyJP a écrit :

J'ai donc ajouté la commande $pdo->exec("SET NAMES 'utf8'"); et il ne semble plus y avoir de problème, mais je vais tester ça plus à fond.

C'est le plus important, l'interclassement (utf8_general_ci) sert pour les tris et les comparaisons mais ne peut pas être la source de ce genre de problèmes d'encodages, car ça n'a aucune influence sur le stockage, l'insertion ou la lecture des données.

utf8_general_ci converti tout en majuscules et sans accent avant de trier/comparer, donc avec cet interclassement 'LéTRöS' == 'letros'. Mais c'est assez efficace et rapide et est généralement utilisé par défaut en français car MySQL ne gère pas le français (pas d'interclassement dédié). C'est assez minime pour le français (par exemple œ n'est pas équivalent à «oe» dans cet interclassement) donc ça va.
Mais on peut tout à fait vouloir appliquer d'autres interclassements à certaines colonnes.

Oui, je comprends bien la différence entre le codage et les règles de tri, pas de problème En allemand un Ä est trié comme un À, en suédois c’est la dernière lettre de l’alphabet. Ces sont donc des règles de tri différentes pour un même codage UTF8 et si on a une Database contenant un lexique allemand - suédois il faut bien des règles différentes selon les colonnes
Ce qui me laissait perplexe, c’est qu’en fait on ne dit pas à la base qu’elle contient de l'ASCII ou de l’utf8 et c’est défini pour chaque connexion. Dur d’imaginer ce qui se passe si on change le code à chaque connexion. Mais maintenant que ça marche...
Modifié par PapyJP (13 Jan 2019 - 23:47)

Bonsoir à tous
Je viens de rentrer chez moi après 4 jours en famille (sans mon PC).
Entre temps j'ai continué sur mon mobile mes recherches sur le problème du codage des databases.
J'ai trouvé un article qui a l'air sérieux qui recommande d'utiliser la syntaxe suivante:

$connection = new PDO("mysql:host=$host;dbname=$dbname;charset=utf8", $dbuser, $dbpw);

de préférence à l'exécution de

$connection -> exec("SET NAMES 'utf8'");

après l'ouverture de la connexion, ou tout autre mécanisme.
Je viens d'essayer cette syntaxe, ça semble donner le même résultat.
Personnellement je la préfère à celle qui consiste à ajouter une commande: si on peut préciser l'encodage dans l'ouverture de la connexion, plutôt que d'en faire une commande à part, il me semble qu'on gagne en clarté dans le code.
Encore faut il que cette syntaxe n'ait pas des vices cachés.
Quelle est l'opinion des experts?
Modifié par PapyJP (13 Jan 2019 - 23:48)

Bonjour,

C'est essentiellement une question de version du serveur PHP.

Si ça marche en ajoutant charset=utf8 à la fin du premier paramètre, c'est mieux en effet.

Amicalement,

Merci de cette confirmation