Trois endroits où MySQL a besoin d’un encodage
- Colonne ou table : le jeu de caractères de stockage, par exemple
utf8mb4oulatin1. - Connexion : le jeu de caractères que le client et le serveur utilisent entre eux, réglé par
SET NAMES utf8mb4ou dans les paramètres de connexion. - Fichier : l’encodage utilisé pour lire un import ou écrire un export, dans phpMyAdmin sous Jeu de caractères du fichier.
Si les trois ne concordent pas, les caractères se cassent. Cas le plus fréquent : du texte UTF-8 a été écrit via une connexion latin1 dans une colonne latin1. L’application semble correcte, mais phpMyAdmin et l’export affichent é.
Avant
"1","Élodie Lefèvre","12 rue de l’Église","Châteauroux"
Après
"1","Élodie Lefèvre","12 rue de l’Église","Châteauroux"
Vérifier les jeux de caractères
SHOW VARIABLES LIKE 'character_set%';affiche les réglages du serveur et de la connexion.SHOW CREATE TABLE clients;affiche le jeu de caractères de la table et de ses colonnes.SELECT nom, HEX(nom) FROM clients LIMIT 5;montre les octets réels : dans une colonneutf8mb4,C3A9est uné, tandis queC383C2A9est unédéjà cassé.
Réparer un export ou un dump
- Exportez la table dans phpMyAdmin en SQL ou CSV, ou avec
mysqldump --default-character-set=utf8mb4. - Déposez le fichier dans la zone ci-dessus. Mojibuster ne répare que les passages cassés ; les caractères corrects restent intacts.
- Contrôlez les passages réparés sous Qu’est-ce qui a changé ? puis téléchargez le fichier.
- Importez-le dans une table en
utf8mb4et choisissezutf-8comme jeu de caractères dans la boîte de dialogue d’import. - Testez d’abord sur une copie avant de remplacer la vraie table.
L’export ne quitte jamais votre ordinateur, ce qui compte pour des données clients. Si le texte contient déjà des accents doublement encodés, voyez la page sur à à la place des accents.
Corriger la cause
- Créez les nouvelles tables avec
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci. - Réglez la connexion de votre application sur
utf8mb4, en PHP par exemple aveccharset=utf8mb4dans le DSN de PDO. - Si des octets UTF-8 se trouvent dans une colonne
latin1, ne la convertissez pas directement avecCONVERT TO: les octets seraient encodés une seconde fois. Le chemin sûr passe par un type binaire : d’abordMODIFY nom VARBINARY(255), puisMODIFY nom VARCHAR(255) CHARACTER SET utf8mb4. - Si MySQL remplace des caractères par
?, la colonne ou la connexion ne sait pas les représenter. Ce qui est déjà stocké ainsi est perdu : détails sur les points d’interrogation à la place des accents.
Questions fréquentes
Pourquoi tout semble correct dans mon application mais pas dans phpMyAdmin ?
Parce que l’application et la base font deux fois la même erreur : l’application écrit de l’UTF-8 via une connexion latin1 et le relit de la même façon. phpMyAdmin se connecte correctement et montre donc ce qui est vraiment stocké. Si le texte était déjà doublement encodé, voir le double encodage ; pour une base WordPress, voir WordPress et base de données.
Quelle collation choisir ?
utf8mb4_unicode_ci convient à la plupart des applications ; depuis MySQL 8, utf8mb4_0900_ai_ci est la valeur par défaut. Le jeu de caractères utf8mb4 compte davantage, et non utf8, qui ne peut pas stocker les émojis dans MySQL.
Est-ce que cela fonctionne aussi avec MariaDB ?
Oui. MariaDB gère les jeux de caractères comme MySQL et les commandes sont les mêmes.
Quelle taille peut faire le dump ?
Jusqu’à 100 Mo par fichier. Exportez les grosses bases table par table.