Interclassement et jeu de caractères de base de données recommandés pour les sites multilingues

Que sont les jeux de caractères et les interclassements dans MySQL ?

Lorsque WordPress stocke le contenu de votre site dans la base de données (comme les articles, les titres, les chaînes de texte traduites, etc.), il utilise un jeu de caractères pour représenter les caractères et un interclassement pour définir comment ces caractères sont comparés et triés.

Jeu de caractères (Charset)

Définit comment les caractères sont stockés dans la base de données, c’est-à-dire quels octets représentent quels caractères.

Interclassement

Définit les règles de comparaison de ces caractères (par exemple, la sensibilité à la casse, la sensibilité aux accents et l’ordre de tri).

Pourquoi cela est important pour les sites multilingues

WPML prend en charge le contenu multilingue, qui inclut souvent :

• Des caractères spéciaux (par ex. ñ, é, ö)
• Des scripts non latins (par ex. arabe, japonais, chinois, hébreu)
• Des émojis et des symboles (🎉, ✔️, etc.)

La plupart d’entre eux nécessitent plus de 3 octets pour être stockés correctement. Si votre base de données utilise un interclassement incompatible, des caractères peuvent être perdus, remplacés par , ou générer des erreurs de base de données (par ex., « Incorrect string value »).

C’est pourquoi nous vous recommandons vivement d’utiliser un interclassement qui prend en charge les caractères Unicode sur 4 octets.

Quelle est la valeur par défaut dans MySQL ?

Version MySQL	Jeu de caractères par défaut	Interclassement par défaut	Compatible Unicode
< 5.5	latin1	latin1_swedish_ci	Non
5.5.x	utf8	utf8_general_ci	Non
5.7+	utf8mb4	utf8mb4_general_ci / utf8mb4_unicode_ci	Oui
8.0+	utf8mb4	utf8mb4_0900_ai_ci	Oui

WordPress ne suit pas toujours la valeur par défaut de MySQL — il peut la remplacer via la configuration ou des migrations.

Définir le jeu de caractères et l’interclassement pour les nouveaux sites

Pour vous assurer que WordPress crée de nouvelles tables avec le jeu de caractères et l’interclassement corrects, définissez ce qui suit dans votre fichier wp-config.php :

define( 'DB_CHARSET', 'utf8mb4' ); // If you have utf8 that's fine, WP will automatically map it as utf8mb4
define( 'DB_COLLATE', 'utf8mb4_unicode_ci' );

Cela s’appliquera aux nouvelles installations et aux tables nouvellement créées.

Vérifier le jeu de caractères et l’interclassement des sites et tables existants

Voici comment vérifier le jeu de caractères et l’interclassement sur vos sites existants.

Option 1 phpMyAdmin

1. Accédez à la base de données de votre site.
2. Vérifiez la colonne « Interclassement » à côté de chaque table.
3. Cliquez sur une table pour afficher l’interclassement individuel de chaque colonne.

Option 2 WP-CLI

bash

wp db query "SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.tables WHERE table_schema = 'your_db_name';"

Vous pouvez également inspecter des colonnes individuelles :

bash

wp db query "SHOW FULL COLUMNS FROM wp_posts;"

Si vous voyez que l’interclassement commence par utf8mb4_, alors il est prêt à prendre en charge tous les types d’Unicode et les idéogrammes sur 4 octets. Le jeu de caractères est également correct.

Si vous voyez autre chose, par exemple utf8_*, vous devez alors le modifier.

Veuillez noter que l’interclassement peut être différent pour chaque colonne.

Mettre à jour le jeu de caractères et l’interclassement pour les tables et colonnes existantes

La mise à jour des constantes DB_CHARSET et DB_COLLATE dans votre fichier wp-config.php n’affecte que les nouvelles tables. Pour appliquer les modifications aux tables et colonnes existantes, vous devez les convertir manuellement à l’aide de SQL.

Nous vous recommandons également de mettre à jour l’interclassement MySQL par défaut de la base de données à l’aide de la commande suivante :

ALTER DATABASE your_database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Commencez toujours par une sauvegarde

Avant d’exécuter des requêtes de conversion :

• Exportez votre base de données à l’aide de phpMyAdmin ou de mysqldump
• Stockez-la en lieu sûr au cas où un problème surviendrait

Avertissement : les mises à jour d’interclassement peuvent échouer en mode strict

Lors de la mise à jour de l’interclassement d’une table entière (ou d’une base de données), MySQL peut reconstruire les tables et revalider toutes les valeurs par défaut des colonnes, y compris celles qui ne sont pas liées, comme DATETIME. Si votre base de données s’exécute en mode SQL strict (STRICT_TRANS_TABLES, NO_ZERO_DATE), les colonnes avec des valeurs par défaut telles que « 0000-00-00 00:00:00 » déclencheront des erreurs telles que :

#1067 - Invalid default value.

Qu’est-ce que le mode strict ?

Le mode strict contrôle la façon dont MySQL gère les valeurs non valides ou manquantes lorsque des données sont ajoutées ou mises à jour dans la base de données. Une valeur peut être non valide pour plusieurs raisons. Par exemple, elle peut avoir un type de données incorrect pour la colonne, ou elle peut être hors limites.

Vous trouverez des informations sur les différents types de validation de données pour le mode strict dans la documentation MySQL.

Comment le mode strict affecte la base de données d’un site WordPress

Par défaut, WordPress utilise « 0000-00-00 00:00:00 » comme valeur par défaut pour certaines colonnes datetime, ce qui n’est pas accepté par le mode strict NO_ZERO_DATE.

Notez que ces valeurs par défaut étaient autorisées lors de la création initiale de la table (par ex., lors de la configuration de WordPress), mais échouent lors des opérations ALTER dans des environnements stricts.

Comment vérifier si le mode strict est activé

Exécutez la commande suivante :

SELECT @@SESSION.sql_mode, @@GLOBAL.sql_mode;

Recherchez :

• STRICT_TRANS_TABLES
• STRICT_ALL_TABLES
• NO_ZERO_DATE

Si vous trouvez l’un d’entre eux, le mode strict est activé.

Pour éviter les erreurs lors des mises à jour du jeu de caractères et de l’interclassement, il vous suffit de désactiver le mode strict NO_ZERO_DATE.

Comment procéder en toute sécurité

Effectuez l’une des actions suivantes pour procéder en toute sécurité :

1. Évitez de modifier les colonnes et les tables, sauf si l’interclassement doit réellement être modifié.

2. Désactivez temporairement le mode strict pour la session uniquement lors de l’exécution des requêtes de conversion. Vous pouvez le faire à l’aide de la commande suivante :

SET SESSION sql_mode = REPLACE(@@sql_mode, 'NO_ZERO_DATE', '');

Remarque : il est prévu à l’avenir que MySQL fusionne les modes stricts.

En cas d’autres problèmes spécifiques à vos données, vous souhaiterez peut-être désactiver tout mode strict à l’aide de la commande suivante :

SET SESSION sql_mode = '';

Requêtes pour la conversion de données

Convertir l’ensemble de la base de données

Ce qui suit génère une requête ALTER TABLE pour chaque table de votre base de données :

SELECT CONCAT(
  'ALTER TABLE `', TABLE_NAME, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;'
) AS query
  FROM INFORMATION_SCHEMA.TABLES
  WHERE TABLE_SCHEMA = 'your_database_name';

Exécutez les requêtes résultantes dans phpMyAdmin, ou copiez-collez-les dans l’interface de ligne de commande (CLI) MySQL / WP-CLI.

Cela garantit que toutes les tables de votre base de données adoptent les nouveaux jeux de caractères et interclassements.

Convertir une table spécifique Optionnel/Accessoire

ALTER TABLE wp_posts 
  CONVERT TO CHARACTER SET utf8mb4 
  COLLATE utf8mb4_unicode_ci;

Cela met à jour toutes les colonnes de texte de la table wp_posts pour utiliser utf8mb4 et l’interclassement spécifié.

---

Convertir une colonne spécifique Optionnel/Accessoire

ALTER TABLE wp_posts 
  CHANGE post_title post_title TEXT 
  CHARACTER SET utf8mb4 
  COLLATE utf8mb4_unicode_ci;

Erreurs courantes lors de la conversion

Voici deux erreurs courantes que vous pourriez rencontrer lors de la conversion de tables et de colonnes.

Incompatibilité entre le jeu de caractères et l’interclassement

-- INVALID: utf8 collation with utf8mb4 charset
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8_general_ci;
-- Error: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4'

Solution :

• Utilisez un interclassement correspondant : utf8mb4_*

---

Limite de longueur de clé d’index

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

Dans certaines configurations, en particulier pour les versions de MySQL antérieures à la 5.7, la longueur maximale de la clé d’index peut être dépassée lors de l’ajout d’un octet supplémentaire par caractère.

Solution :

• Raccourcissez les VARCHAR(255) indexés en VARCHAR(191) si nécessaire
• Ou passez à MySQL 5.7+ et assurez-vous que innodb_large_prefix est activé