Trois octets par caractère : c’est la limite du jeu de caractères utf8 historique de MySQL, une limitation qui remonte à une décision d’implémentation antérieure à la norme Unicode complète. Un émoji, un caractère chinois rare ou certains symboles mathématiques nécessitent quatre octets pour être représentés correctement en UTF-8 réel. Sur une table WordPress créée avec l’ancien utf8, ces caractères ne sont pas stockés : ils sont silencieusement tronqués ou remplacés par un point d’interrogation.
Cette architecture détaille pourquoi le choix entre utf8 et utf8mb4, et entre les différentes collations disponibles pour ce dernier, conditionne directement la fiabilité du tri et de la recherche sur un site qui mélange plusieurs écritures : latin accentué, cyrillique, caractères chinois, japonais ou coréens, ou simplement des emoji dans les titres.
Le symptôme : un titre tronqué après une simple sauvegarde
Un titre d’article contenant un emoji, saisi normalement dans l’éditeur, se retrouve amputé après un aller-retour en base de données sur une table encore en utf8 : le caractère problématique est purement et simplement supprimé par MySQL au moment de l’insertion, sans qu’aucune erreur ne remonte à PHP dans la configuration par défaut. WordPress a résolu ce problème par défaut sur les installations récentes, mais de nombreux sites migrés depuis d’anciennes versions, ou hébergés sur des configurations imposées, conservent encore des tables en utf8 simple.
Vérifier le jeu de caractères réellement utilisé
La commande WP-CLI suivante affiche le moteur, le jeu de caractères et la collation de chaque table de la base :
wp db query "SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema = DATABASE();"
Une table encore en utf8_general_ci ou utf8_unicode_ci doit être convertie vers une variante utf8mb4. La conversion se fait table par table avec ALTER TABLE, en choisissant une collation cible cohérente sur l’ensemble de la base pour éviter des erreurs de jointure entre tables aux collations différentes.
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;Le choix de la collation détermine l’ordre de tri, pas seulement le stockage
Une fois utf8mb4 choisi comme jeu de caractères, il reste à choisir une collation, c’est-à-dire les règles de comparaison et de tri appliquées aux caractères. C’est un point souvent négligé : deux tables encodées de façon identique en utf8mb4 mais avec des collations différentes peuvent trier le même contenu dans un ordre différent, et refuser certaines jointures sans conversion explicite.
| Collation | Comportement de tri | Cas d’usage typique |
|---|---|---|
utf8mb4_general_ci | Tri simplifié, rapide, moins précis sur les langues à règles complexes | Sites monolingues sans besoin de tri fin |
utf8mb4_unicode_520_ci | Respecte les règles de tri Unicode standard, plus lent | Contenu multilingue avec tri alphabétique correct attendu |
utf8mb4_0900_ai_ci | Collation par défaut de MySQL 8, basée sur Unicode 9 | Nouvelles installations sur MySQL 8 |
L’effet concret sur une liste de termes triés
Sur un site qui liste des termes de taxonomie mélangeant du français accentué et des noms propres translittérés, une collation _general_ci peut placer « Étude » après « Zoologie » dans un tri alphabétique, parce qu’elle traite certains caractères accentués comme des caractères totalement distincts plutôt que comme des variantes de la lettre de base. Une collation _unicode_ci gère normalement mieux ce cas, en appliquant les règles de collation Unicode qui rapprochent « É » de « E » pour le tri.
Le cas des idéogrammes chinois, japonais et coréens
Pour les caractères chinois, japonais ou coréens, aucune collation MySQL générique ne propose un tri « alphabétique » au sens occidental, puisque ces écritures ne reposent pas sur un alphabet ordonné de la même façon. Le tri par défaut se fait alors le plus souvent par ordre de code point Unicode, ce qui ne correspond ni à l’ordre des traits, ni à l’ordre phonétique attendu par un lecteur natif. Un site qui a réellement besoin d’un tri correct pour ces écritures doit stocker une clé de tri dédiée, calculée côté application, plutôt que de compter sur la collation MySQL seule.
Migrer sans casser wp_options ni les clés primaires
La conversion d’une base WordPress entière doit être scriptée avec prudence : certaines colonnes, notamment les clés primaires de type VARCHAR utilisées par quelques extensions, ont une taille limite en octets qui peut être dépassée en passant de trois à quatre octets par caractère, provoquant une erreur d’index trop long sur d’anciennes versions de MySQL. Un test complet sur une copie de la base, avant toute conversion en production, reste la seule façon fiable de vérifier l’absence de ce type de blocage.
En résumé
Le choix du jeu de caractères et de la collation d’une base WordPress n’est pas un détail d’installation : il détermine quels caractères peuvent être stockés sans perte et dans quel ordre le contenu multilingue sera trié et comparé. Migrer vers utf8mb4 avec une collation Unicode adaptée règle la majorité des cas occidentaux ; les écritures sans ordre alphabétique, comme le chinois ou le japonais, demandent une clé de tri applicative en complément.
