Vous voyez apparaître des textes comme Français, café ou l’addition sur votre site Internet ? Ce problème d’affichage porte un nom : le mojibake. Il est généralement provoqué par une mauvaise interprétation des caractères ou par un double encodage UTF-8. Bien qu’il soit surtout visible sur les lettres accentuées, il peut aussi affecter les apostrophes, les symboles monétaires, les emojis et de nombreux caractères issus d’alphabets étrangers. Le mojibake peut apparaître après une migration de site, un import de données, une modification de serveur ou l’utilisation d’un ancien plugin WordPress. Dans certains cas, le texte est correctement enregistré, mais mal interprété par le navigateur. Dans d’autres, les caractères corrompus sont déjà présents dans la base de données. Pour corriger durablement le problème, il faut donc comprendre à quel moment la chaîne d’encodage a été rompue.

Qu’est-ce que le mojibake ?

Le terme japonais mojibake désigne un texte devenu partiellement ou totalement illisible à cause d’une incompatibilité d’encodage. Les caractères d’origine ne sont pas nécessairement perdus : ils ont souvent été enregistrés sous forme d’octets valides, mais ces octets ont ensuite été décodés avec un jeu de caractères différent de celui qui avait été utilisé au départ. Le navigateur ou l’application affiche alors une succession de signes inattendus. Ce phénomène est particulièrement courant lorsque du texte encodé en UTF-8 est interprété comme du Windows-1252 ou de l’ISO-8859-1. Les caractères ASCII simples, comme les lettres de A à Z et les chiffres, restent généralement lisibles, car ils possèdent la même représentation dans ces encodages. En revanche, les lettres accentuées et les caractères typographiques sont composés d’octets différents. Leur mauvaise interprétation produit des séquences facilement reconnaissables.

Le mojibake ne constitue donc pas une faute de frappe ou un problème lié à la police d’écriture. Changer la typographie du site ne permettra pas de le corriger. Il s’agit d’un défaut technique dans la manière dont les données sont enregistrées, transmises ou interprétées. La solution consiste à retrouver l’encodage d’origine, à localiser l’étape responsable et à rétablir une chaîne cohérente.

Comment fonctionne l’encodage UTF-8 ?

Un fichier informatique ne contient pas directement des lettres ou des symboles tels que nous les voyons à l’écran. Il contient des nombres enregistrés sous forme d’octets. Un encodage définit la correspondance entre ces valeurs numériques et les caractères à afficher. Sans cette convention commune, un logiciel ne peut pas savoir si une suite d’octets représente une lettre accentuée, un symbole ou plusieurs caractères distincts. UTF-8 est aujourd’hui l’encodage de référence sur le Web. Il repose sur la norme Unicode et peut représenter les caractères utilisés dans la plupart des langues, ainsi que les symboles techniques et les emojis. Il présente également l’avantage d’être compatible avec l’ASCII : les lettres latines non accentuées, les chiffres et les signes courants utilisent la même représentation. Cette caractéristique explique pourquoi un problème d’encodage peut passer inaperçu dans un texte anglais, puis devenir immédiatement visible dans un contenu français. Certains caractères UTF-8 sont représentés par plusieurs octets. Le caractère « é », par exemple, utilise deux octets. Si un logiciel interprète chacun de ces octets comme un caractère Windows-1252 indépendant, il affiche « é ». Le texte semble avoir été transformé, mais il résulte en réalité d’une lecture incorrecte des mêmes données numériques. Pour éviter cette situation, tous les éléments impliqués doivent s’accorder sur le même encodage : le fichier source, la page HTML, la connexion à la base de données, les tables SQL, le serveur HTTP, les scripts d’importation et le navigateur. Une seule étape mal configurée peut suffire à produire du mojibake.

Qu’est-ce que le double encodage UTF-8 ?

Le double encodage se produit lorsqu’un texte déjà encodé en UTF-8 est traité une seconde fois comme s’il devait encore être converti vers UTF-8. Le premier défaut transforme généralement un caractère lisible en une séquence comme « é ». Si cette séquence corrompue est ensuite enregistrée ou convertie une nouvelle fois, elle peut devenir « é ». Chaque traitement supplémentaire ajoute ainsi un nouveau niveau de déformation. Prenons l’exemple du mot café :

1. Le caractère é est initialement enregistré correctement en UTF-8.
2. Ses octets sont interprétés à tort comme des caractères Windows-1252.
3. Le caractère é devient alors é.
4. Cette version incorrecte est enregistrée comme s’il s’agissait du texte réel.
5. Une nouvelle conversion peut produire une séquence encore plus dégradée, comme é.

La présence de groupes comme Ã, Â, ’ ou € constitue donc un indice révélateur. Elle ne permet toutefois pas toujours de connaître immédiatement le nombre de conversions effectuées. Certaines données peuvent avoir subi une seule mauvaise interprétation, tandis que d’autres ont pu être importées, exportées puis réenregistrées plusieurs fois. Cette distinction est importante, car une seule conversion inverse ne suffit pas forcément à réparer tous les contenus. Une base de données peut même contenir plusieurs niveaux de corruption selon la date de création des articles, le plugin employé ou l’origine des données.

Quelles sont les causes les plus fréquentes au mojibake ?

Une base de données mal configurée

La base de données, ses tables et ses colonnes peuvent employer des jeux de caractères différents. Une ancienne table peut, par exemple, être configurée en Latin-1 tandis que les nouvelles tables utilisent utf8mb4. Une application peut également envoyer du texte UTF-8 à une connexion MySQL qui déclare recevoir du Latin-1. MySQL effectue alors une conversion fondée sur une information incorrecte, ce qui peut altérer les données au moment de leur insertion. Il faut également distinguer le jeu de caractères de la collation. Le jeu de caractères détermine la manière dont le texte est enregistré. La collation définit surtout les règles de comparaison et de tri, notamment la gestion des accents et des majuscules. Modifier une collation ne répare donc pas automatiquement des caractères déjà corrompus.

Une connexion MySQL sans encodage explicite

Même lorsque les tables sont correctement configurées, la connexion entre PHP et MySQL doit annoncer le bon encodage. Dans un projet utilisant PDO, il est recommandé d’intégrer charset=utf8mb4 à la chaîne de connexion. Cette information permet au serveur de connaître l’encodage des données échangées avec l’application.

$pdo = new PDO(
    'mysql:host=localhost;dbname=monsite;charset=utf8mb4',
    $utilisateur,
    $motDePasse
);

Une connexion mal déclarée peut produire un affichage incorrect, mais elle peut aussi enregistrer définitivement les mauvaises valeurs. Le problème devient alors visible sur toutes les pages qui réutilisent ces données, même après correction de la connexion.

Un en-tête HTTP incorrect

Le serveur Web indique au navigateur la nature du contenu transmis grâce à un en-tête HTTP. Si cet en-tête annonce un encodage différent de celui du document, le navigateur peut employer la mauvaise table de correspondance. Pour une page HTML moderne enregistrée en UTF-8, l’en-tête attendu est généralement le suivant :

Content-Type: text/html; charset=UTF-8

L’en-tête HTTP peut avoir priorité sur la déclaration présente dans le code HTML. Il est donc utile de vérifier les deux éléments au lieu de se limiter à la balise visible dans le document.

Une déclaration HTML absente ou erronée

La page doit annoncer son encodage dès le début de la section <head>. Cette déclaration aide le navigateur à interpréter correctement le document avant d’en afficher le contenu :

<meta charset="UTF-8">

Cette balise doit apparaître suffisamment tôt dans le fichier. Elle ne transforme cependant pas les données : si le texte « café » est déjà enregistré tel quel dans la base, déclarer UTF-8 ne le fera pas redevenir « café ».

Un import CSV ou une migration

Les imports depuis Excel, un fichier CSV, un ancien CMS ou une base de données externe sont des sources fréquentes de mojibake. Un outil peut exporter un fichier en Windows-1252 alors que le script d’import suppose qu’il est en UTF-8. L’inverse est également possible. Les séparateurs, les guillemets typographiques, les espaces insécables et les caractères spéciaux rendent ces opérations particulièrement sensibles. Avant une migration, il est conseillé de vérifier l’encodage réel du fichier et de tester l’importation sur quelques lignes représentatives. Un bon échantillon doit contenir des accents, des apostrophes, le symbole euro et, si nécessaire, des emojis.

Une conversion appliquée plusieurs fois

Des fonctions comme utf8_encode(), utf8_decode(), iconv() ou mb_convert_encoding() peuvent être utiles lorsque l’encodage d’origine est connu. Utilisées au hasard ou appliquées systématiquement, elles risquent en revanche de créer un double encodage. Une fonction de conversion ne doit jamais servir à masquer un problème sans en identifier la source.

Comment corriger un mojibake ?

1. Faire une sauvegarde complète

Avant toute intervention, sauvegardez les fichiers et la base de données. Une mauvaise conversion peut écraser les derniers octets permettant de reconstruire le texte d’origine. La sauvegarde doit être réalisée avant les commandes SQL, les remplacements automatiques et les changements de jeu de caractères. Idéalement, effectuez les premiers essais sur une copie du site plutôt que directement en production.

2. Identifier l’endroit où le texte est corrompu

La première étape du diagnostic consiste à déterminer si le texte est correctement enregistré dans la base. Consultez la valeur avec un outil d’administration fiable, puis comparez-la avec la réponse brute envoyée par le serveur et avec le rendu du navigateur. Le problème peut se trouver :

• dans les données enregistrées en base ;
• dans la connexion entre PHP et MySQL ;
• dans un fichier du thème ou d’une extension ;
• dans un script d’importation ou une API ;
• dans les en-têtes de la réponse HTTP ;
• ou uniquement pendant l’interprétation par le navigateur.

Si la base contient déjà café, les données devront probablement être réparées. Si elle contient bien café mais que la page affiche une version corrompue, il faut corriger la transmission ou l’interprétation sans modifier le contenu enregistré.

3. Uniformiser le projet en UTF-8

Une correction durable exige une configuration cohérente de bout en bout. Les fichiers HTML, PHP, JavaScript et CSS doivent être enregistrés en UTF-8. Les en-têtes HTTP et la balise meta doivent annoncer UTF-8. La connexion SQL, les tables, les colonnes et les outils d’importation doivent employer un encodage compatible. Pour les projets récents basés sur MySQL ou MariaDB, utf8mb4 est généralement préférable à l’ancien jeu nommé utf8. Il prend en charge l’ensemble des caractères Unicode, notamment ceux nécessitant quatre octets, comme de nombreux emojis. Cette uniformisation empêche la réapparition du défaut, mais ne corrige pas les contenus déjà endommagés.

4. Réparer les données avec prudence

Lorsqu’un texte UTF-8 a été interprété comme du Windows-1252 ou de l’ISO-8859-1, une conversion inverse peut parfois restaurer le contenu. Il n’existe toutefois pas de commande universelle : la bonne opération dépend du chemin exact suivi par les données. Une conversion adaptée à « café » peut être insuffisante pour « café » et incorrecte pour un texte qui n’a jamais été corrompu.

// Exemple à adapter uniquement après avoir identifié
// l’encodage réel et le sens de la conversion
$texteCorrige = mb_convert_encoding(
    $texteCorrompu,
    'UTF-8',
    'Windows-1252'
);

Testez d’abord la méthode sur un petit échantillon et comparez les résultats caractère par caractère. Conservez également une trace des lignes modifiées afin de pouvoir revenir en arrière. Sur une base hétérogène, il peut être nécessaire de détecter les séquences suspectes avant d’appliquer une correction ciblée.

Comment corriger le problème dans WordPress ?

WordPress fonctionne normalement en UTF-8 et utilise aujourd’hui utf8mb4 sur les installations compatibles. Dans le fichier wp-config.php, la constante suivante doit généralement être présente :

define('DB_CHARSET', 'utf8mb4');

La constante DB_COLLATE peut habituellement rester vide, ce qui permet à WordPress de sélectionner la collation appropriée :

define('DB_COLLATE', '');

Il ne faut pas modifier ces valeurs à l’aveugle sur un site existant. La configuration déclarée dans WordPress, le jeu réellement utilisé par les tables et l’encodage des données déjà présentes sont trois éléments différents. Un changement dans wp-config.php ne convertit pas automatiquement les anciens articles. En cas de mojibake sur WordPress, examinez les données importées par les plugins, les contenus provenant d’un ancien CMS, les fichiers du thème, les flux XML, les réponses d’API et les tables créées par de vieilles extensions. Si le problème ne touche que certains articles, recherchez ce qu’ils ont en commun : date de migration, outil d’importation, éditeur utilisé ou source du contenu. Les sauvegardes WordPress peuvent aussi contenir des données déjà corrompues. Avant une restauration complète, vérifiez donc la date d’apparition du défaut. Une sauvegarde saine permet souvent de récupérer les contenus plus sûrement qu’une série de conversions automatiques.

Les erreurs à éviter

La principale erreur consiste à appliquer une conversion globale sans diagnostic préalable. Une base peut contenir à la fois des textes corrects, des textes mal décodés une fois et des textes doublement encodés. Une seule règle appliquée partout risque alors de réparer certaines lignes tout en détériorant les autres.

• Convertir toute la base de données sans sauvegarde.
• Utiliser une fonction de conversion sur un texte déjà en UTF-8.
• Effectuer des remplacements manuels sans rechercher la cause.
• Confondre le jeu de caractères et la collation MySQL.
• Modifier seulement la balise meta lorsque la base est corrompue.
• Réenregistrer plusieurs fois les contenus mal décodés.
• Tester directement une correction sur le site en production.

Il faut également éviter de corriger uniquement les séquences visibles. Remplacer « é » par « é » peut sembler efficace, mais cette méthode oubliera d’autres caractères et ne traitera pas la cause technique. Le problème risque donc de réapparaître au prochain import ou à la prochaine modification.

Comment prévenir le double encodage ?

La meilleure prévention consiste à utiliser UTF-8 de bout en bout et à documenter clairement l’encodage de chaque source externe. Une application ne devrait jamais deviner arbitrairement l’encodage d’un fichier. Lorsqu’elle reçoit un CSV, un flux XML ou une réponse d’API, elle doit connaître le format annoncé et vérifier qu’il correspond réellement au contenu.

• Enregistrez tous les fichiers sources en UTF-8.
• Utilisez utf8mb4 pour les nouvelles bases MySQL.
• Déclarez UTF-8 dans les pages et les réponses HTTP.
• Configurez explicitement l’encodage des connexions SQL.
• Contrôlez les fichiers CSV avant leur importation.
• Évitez les conversions automatiques non documentées.
• Testez les accents, les symboles, les emojis et les alphabets étrangers.

Ces tests doivent idéalement être effectués lors de chaque migration ou changement d’infrastructure. Une courte phrase contenant « Éléphant, français, 20 €, l’été 😊 » permet déjà de vérifier plusieurs catégories de caractères sensibles. Si elle traverse correctement toutes les étapes, la chaîne d’encodage est probablement cohérente. Le mojibake n’est pas un simple défaut typographique. Il révèle une rupture dans la chaîne reliant le fichier, l’application, la base de données, le serveur et le navigateur. Le double encodage UTF-8 correspond à un cas particulier dans lequel un texte déjà encodé ou déjà mal interprété subit une nouvelle conversion. Pour résoudre durablement le problème, il faut commencer par sauvegarder le site, identifier l’étape responsable, uniformiser l’environnement en UTF-8 puis réparer les données déjà corrompues avec une méthode adaptée. Une fois la chaîne correctement configurée, les accents, les apostrophes, les symboles et les caractères internationaux retrouvent leur apparence normale.

Quelques questions fréquentes sur le mojibake

Vous vous demandez peut-être :

Pourquoi « é » devient-il « é » ?

Le caractère « é » est représenté par plusieurs octets en UTF-8. Lorsque ces octets sont interprétés séparément selon Windows-1252 ou ISO-8859-1, ils produisent les caractères « Ã » et « © ». Le problème vient donc du décodage, et non du caractère accentué lui-même.

Une balise meta UTF-8 suffit-elle à corriger le problème ?

Non. Elle indique au navigateur comment lire la page, mais elle ne répare pas une valeur déjà enregistrée sous une forme corrompue. Si la base contient « café », il faudra corriger les données ou les restaurer depuis une sauvegarde saine.

UTF-8 et utf8mb4 sont-ils identiques dans MySQL ?

Pas exactement. Dans MySQL, l’ancien jeu nommé utf8 ne prend en charge qu’une partie d’Unicode. utf8mb4 accepte aussi les caractères utilisant quatre octets, dont de nombreux emojis. Il constitue généralement le meilleur choix pour un nouveau projet.

Peut-on réparer automatiquement tous les textes ?

Une correction automatique est possible lorsque la même transformation incorrecte a été appliquée à toutes les données. Si la base contient plusieurs formes de corruption, une analyse ciblée est nécessaire. Il faut alors classer les contenus selon leur état et appliquer uniquement la conversion correspondant à chaque cas.