Vous ouvrez un fichier CSV exporté de votre ERP et tous les accents ont disparu. À la place de « Référence » vous lisez « Référence ». Votre collègue qui a exporté les données jure que tout allait bien de son côté. Bienvenue dans le monde du mojibake — ces caractères cassés qui apparaissent quand deux systèmes ne parlent pas le même langage d'encodage.
Pourquoi é au lieu de é ?
Le caractère é existe dans les deux encodages les plus répandus, mais il n'y est pas stocké de la même façon. En Latin-1 (ISO-8859-1), é tient sur un seul octet : E9. En UTF-8, il faut deux octets : C3 A9.
Le problème survient quand un logiciel qui attend du Latin-1 reçoit du UTF-8. Il lit les deux octets C3 et A9 séparément : C3 correspond à à et A9 à ©. Résultat affiché : é au lieu de é.
Les 5 types de corruption d'encodage les plus courants
1. Mojibake (UTF-8 lu comme Latin-1)
C'est le cas le plus fréquent. Tous les caractères accentués français sont touchés : é (é), è (è), à (à), ç (ç), ô (ô)… La réparation consiste à ré-interpréter les octets comme du UTF-8.
2. HTML entities non interprétées
Quand un texte destiné à être rendu en HTML est affiché en brut, les entités comme é, é ou é apparaissent telles quelles au lieu d'être converties en é. C'est courant lors d'exports de CMS ou de copier-coller depuis le code source.
3. URL encoding visible
Les URL utilisent le signe % suivi de deux chiffres hexadécimaux pour encoder les caractères spéciaux. %C3%A9 représente é en UTF-8. Quand ce texte est affiché sans décodage, on voit les %xx en clair.
4. Windows-1252 (guillemets courbes)
Windows utilise son propre encodage (Windows-1252) qui ajoute des caractères dans la plage 0x80-0x9F que Latin-1 laisse vide. Les guillemets courbes « » et les tirets cadratins — sont les victimes les plus fréquentes. Transférés vers un système Unix ou Mac, ils deviennent des caractères de contrôle invisibles ou des losanges.
5. Double encodage UTF-8
Le piège des bases de données mal configurées. Le texte est déjà en UTF-8, mais le driver de connexion le traite comme du Latin-1 et le ré-encode une deuxième fois. é → C3 A9 → interprété comme é → ré-encodé en C3 83 C2 A9. Le texte est alors doublement corrompu et nécessite deux passes de réparation.
Comment réparer ?
La première étape est toujours d'identifier le type de corruption. Notre détecteur d'encodage analyse votre texte caractère par caractère et identifie les séquences suspectes. Il propose ensuite une réparation automatique adaptée au type de problème détecté.
Pour les bases de données MySQL, vérifiez trois points : la connexion (SET NAMES utf8mb4), le charset de la table et la collation des colonnes. Pour les fichiers CSV, spécifiez l'encodage à l'ouverture (UTF-8 with BOM dans Excel). Pour les pages web, ajoutez <meta charset="UTF-8"> en tout premier dans le <head>.