🔍 Détecteur d'encodage de texte
Collez un texte et découvrez quel encodage a été utilisé — avec diagnostic caractère par caractère
📊 Encodages détectés
🔧 Texte réparé
| Méthode de réparation | Résultat |
|---|
🔬 Diagnostic caractère par caractère
Seuls les caractères non-ASCII et les séquences suspectes sont affichés.
| Position | Caractère | Code point | Octets UTF-8 | Interprétation |
|---|
Aucun caractère suspect détecté — le texte semble proprement encodé en UTF-8.
📖 Table de correspondance des caractères détectés
| Caractère | UTF-8 | HTML Entity | URL Encoded | Code point |
|---|
ℹ️ Comment ça marche ?
Quand un texte passe d'un système à l'autre, l'encodage peut être mal interprété. Le résultat : des caractères cassés (mojibake) comme é au lieu de é, ou des séquences comme é affichées en clair.
Cet outil analyse votre texte pour détecter l'encodage réel, identifier les séquences suspectes et proposer une réparation automatique.
❓ Questions fréquentes
C'est un cas classique de mojibake. Le caractère « é » est encodé en UTF-8 sur 2 octets (
C3 A9). Quand un logiciel lit ces octets en Latin-1 (ISO-8859-1), il interprète chaque octet séparément : C3 = à et A9 = ©. Résultat : « é » au lieu de « é ». La solution est de forcer la lecture en UTF-8.
Latin-1 (ISO-8859-1) encode chaque caractère sur 1 octet, ce qui limite le jeu à 256 caractères (langues d'Europe de l'Ouest). UTF-8 utilise 1 à 4 octets et couvre l'intégralité d'Unicode (plus de 140 000 caractères, dont le chinois, l'arabe, les emojis…). Aujourd'hui, UTF-8 est le standard du web — plus de 98% des sites l'utilisent.
Un HTML entity est une séquence comme
é (→ é) ou é (→ é) qui représente un caractère spécial en HTML. C'était indispensable à l'époque du Latin-1, mais avec UTF-8, on peut taper les caractères directement. Si vous voyez des entities en clair dans un texte, c'est qu'elles n'ont pas été interprétées par le navigateur (souvent un double-échappement).
Le double encodage se produit quand un texte déjà en UTF-8 est encodé une seconde fois en UTF-8. Exemple : « é » (
C3 A9) est interprété en Latin-1 comme « é », puis ces deux caractères sont ré-encodés en UTF-8 : C3 83 C2 A9. Le texte affiché montre alors « é » avec des octets doublés. C'est fréquent avec les bases de données mal configurées.
Vérifiez trois niveaux : la connexion (
SET NAMES utf8mb4), le jeu de caractères de la table (ALTER TABLE … CONVERT TO CHARACTER SET utf8mb4) et le collation de la colonne. Si les données sont déjà corrompues en base, il faut d'abord identifier le type de corruption (simple mojibake ou double-encodage) puis appliquer la réparation adaptée avant de convertir.