« 予約フォーム » devient « ??? » dans le fichier ZIP exporté, alors que la même page s’affiche parfaitement sur le site public. Ce décalage entre un rendu correct côté navigateur et un export corrompu constitue un signal classique de problème d’encodage, et c’est exactement ce qui s’est produit sur un projet destiné à une clientèle japonophone, où plusieurs titres de widgets et de sections utilisaient des caractères hors table latine.
Le symptôme est déroutant parce qu’il touche uniquement l’export, jamais l’affichage ni même l’édition dans l’interface. Comprendre pourquoi demande de suivre le chemin exact que prend une chaîne de caractères entre la base de données et le fichier ZIP final.
Symptôme : un export tronqué, un affichage intact
Dans l’éditeur Elementor, le titre du widget s’affiche correctement, caractère par caractère. La page publiée aussi. Le problème survient uniquement au moment d’exporter le Kit — fonctionnalité qui empaquette templates, réglages globaux et styles dans une archive réutilisable sur un autre site. À l’ouverture du fichier JSON contenu dans ce ZIP, les caractères japonais sont remplacés par des points d’interrogation ou des blocs vides.
Diagnostic : où se situe la rupture d’encodage
La table MySQL qui stocke _elementor_data était déclarée avec un jeu de caractères utf8 classique plutôt que utf8mb4. La différence semble anodine, mais elle est décisive : l’encodage utf8 historique de MySQL ne couvre que les caractères codés sur un maximum de trois octets, alors qu’une bonne partie des caractères CJK (chinois, japonais, coréen) ainsi que les emojis nécessitent quatre octets en UTF-8 réel. MySQL, en silence, tronque ou remplace ce qu’il ne peut pas stocker correctement.
Le test le plus rapide pour confirmer ce diagnostic consiste à interroger directement le jeu de caractères de la colonne concernée :
SHOW FULL COLUMNS FROM wp_postmeta WHERE Field = 'meta_value';Si la collation retournée commence par utf8_ sans le suffixe mb4, la table ne peut tout simplement pas stocker fidèlement certains caractères japonais, même si l’affichage frontal semble correct grâce à un cache d’objets qui, lui, conserve la version en mémoire non tronquée.
Correctif : migrer proprement vers utf8mb4
La procédure de conversion touche la base entière, pas seulement la table concernée, pour éviter des incohérences entre tables liées par des jointures. WordPress fournit une documentation officielle sur ce sujet précis, à consulter avant toute migration en production.
- Sauvegarder intégralement la base de données avant toute opération.
- Convertir chaque table avec
ALTER TABLE nom_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;. - Vérifier la constante
DB_CHARSETdanswp-config.php, qui doit refléterutf8mb4. - Réexporter le Kit une fois la conversion terminée et rouvrir le fichier JSON pour confirmer que les caractères sont intacts.
Sur le projet concerné, la conversion complète de la base, hébergeant une douzaine de tables personnalisées en plus du cœur WordPress, a représenté une trentaine de minutes d’indisponibilité programmée en dehors des heures d’ouverture du site.
Prévention pour les projets multilingues
Pour tout projet destiné à une audience utilisant des caractères hors table latine, la vérification du jeu de caractères de la base devrait figurer dans la checklist de recette, avant même l’installation d’Elementor. La documentation d’installation de WordPress recommande d’ailleurs utf8mb4 comme configuration par défaut depuis plusieurs versions déjà.
- Vérifier
DB_CHARSETdès la création de la base, avant tout import de contenu. - Tester un export de Kit dès les premiers contenus saisis, pas en fin de projet.
- Se méfier d’un affichage correct en front : il ne garantit rien sur le stockage réel.
Un affichage correct dans le navigateur ne prouve jamais qu’une chaîne est stockée fidèlement en base : seul un export ou une requête SQL directe le confirme.
En résumé
Ce type de bogue silencieux illustre un principe général de développement WordPress : l’encodage doit être cohérent à chaque étape, de la déclaration de la base jusqu’au fichier final généré, sans maillon faible. La traduction du contenu, elle, relève d’un tout autre chantier, généralement traité avec un plugin multilingue dédié.
