ISO 8859-1 (Latin-1) : encodage, différences avec UTF-8 et pièges courants

Qu'est-ce que ISO 8859-1 ?

ISO 8859-1, aussi appelé Latin-1, est un encodage sur 1 octet couvrant l'anglais et la plupart des langues d'Europe occidentale.

Voici les aspects essentiels à connaître :

1 Jeu de caractères et plage de codes

ASCII (0x00–0x7F) + lettres accentuées et symboles (0xA0–0xFF).

é (0xE9), à (0xE0), ç (0xE7), ñ (0xF1), NBSP (0xA0)

2 Différences avec UTF-8

UTF‑8 est multioctet et couvre tout Unicode. ISO 8859‑1 ne gère pas l’€ ni les guillemets typographiques.

'é' en ISO‑8859‑1: E9
'é' en UTF‑8: C3 A9

3 Variantes proches à ne pas confondre

Windows‑1252 ressemble à ISO‑8859‑1 mais ajoute des caractères 0x80–0x9F (€, guillemets typographiques, tiret long).

€ (0x80), ‘ ’ (0x91–0x92), “ ” (0x93–0x94)

– (0x96), — (0x97), … (0x85)

4 Transport et métadonnées

Déclarez toujours le charset côté HTTP/HTML, base de données et email. ISO‑8859‑1 n'a pas de BOM.

Content-Type: text/html; charset=ISO-8859-1

Problèmes classiques

Copier-coller entre UTF-8 et ISO-8859-1

Produit du mojibake (ex: "é" → "Ã©") quand les octets UTF‑8 sont lus en Latin‑1.

Tests unitaires ou comparaisons qui échouent

Même rendu visuel mais octets différents (Latin‑1 vs UTF‑8) → égalités fausses, hachages différents.

En-têtes charset contradictoires

HTTP annonce ISO‑8859‑1, le fichier est UTF‑8 (ou l’inverse) → affichage cassé et import foireux.

Base MySQL en latin1, application en UTF-8

latin1_swedish_ci par défaut + SET NAMES incohérent = données corrompues lors des lectures/écritures.

Exemple de problème courant :

# Même texte affiché, octets différents

string1 = "café"

string2 = "cafÃ©" # UTF-8 lu en ISO-8859-1

assert string1 == string2 # ❌ Échec

Symptômes qui doivent vous alerter

🚨 Signaux d'alarme

!

Des accents deviennent Ã©, Ã€, â€” ou � après un import/export

!

Votre navigateur affiche correctement en local mais pas en prod (ou inversement)

!

Un CSV a des caractères exotiques qui décalent les colonnes chez certains outils

!

file -bi annonce un charset différent de ce que vous pensiez

!

Les emails contiennent =?ISO-8859-1?...?= et s'affichent mal chez certains clients

Comment les détecter

✨ Solution recommandée : Clean ASCII

Clean ASCII facilite le diagnostic autour d’ISO 8859-1 : il met en évidence les caractères hors Latin‑1, repère les séquences UTF‑8 glissées par erreur et propose des conversions sûres.

✅ Détection automatique

Caractères hors ISO‑8859‑1, séquences UTF‑8, entités CP1252 invisibles

📊 Analyse complète

Octets, points de code, positions exactes, équivalents possibles

🧹 Nettoyage automatique

Conversion UTF‑8 ou mappage intelligent vers ASCII/Latin‑1

💾 Export propre

Téléchargement du texte converti et prêt à intégrer

🔍 Vérifier mon encodage

Autres méthodes de détection

Affichage dans l'éditeur

✓ Utilisez "Reopen with Encoding" / "Save with Encoding" (VS Code, JetBrains, Sublime)

✓ Affichez l'encodage dans la barre d'état et forcez-le au projet

En ligne de commande (Unix)

# Détecter l'encodage probable

file -bi fichier.txt

uchardet fichier.txt

# Convertir ISO-8859-1 → UTF-8

iconv -f ISO-8859-1 -t UTF-8 fichier.txt > out.txt

# Valider si un fichier est bien UTF-8

iconv -f UTF-8 -t UTF-8 -o /dev/null fichier.txt || echo "UTF-8 invalide"

# Inspecter les octets

hexdump -C fichier.txt

En code

JavaScript

const decoder = new TextDecoder('iso-8859-1');
const texte = decoder.decode(bytes);

Python

b.decode('latin-1') # ISO-8859-1 → str
s.encode('latin-1', 'replace') # str → ISO-8859-1

Excel / Google Sheets

CODE(MID(cellule;position;1)) # repérer les octets > 127 (hors ASCII)

Nettoyer et prévenir

🚀 Solution rapide avec Clean ASCII

Avant de bricoler des scripts, passez votre texte dans Clean ASCII pour identifier les caractères hors ISO 8859‑1, convertir vers UTF‑8 proprement ou mapper vers des équivalents sûrs.

✓ Détection automatique

✓ Conversion maîtrisée

✓ Export immédiat

Nettoyer maintenant

Méthodes techniques avancées

🔧 Normaliser

✓ Choisissez un encodage unique (UTF‑8 recommandé). Si ISO‑8859‑1 est requis, documentez-le.

✓ Déclarez le charset sur HTTP, HTML, emails, drivers DB et ORM

✓ Uniformisez les fins de ligne (dos2unix, gitattributes)

🧹 Filtrer

✓ Remplacez les caractères non représentables sous ISO‑8859‑1 (guillemets typographiques, €) par des équivalents

✓ Convertissez à l'entrée/sortie (iconv, mb_convert_encoding) selon le contexte

✓ Bloquez les encodages inattendus dans vos pipelines

⚙️ Automatiser

✓ Hooks pre-commit pour refuser des fichiers non UTF‑8 (ou non ISO‑8859‑1 selon votre standard)

✓ Tests d'intégration vérifiant le charset des réponses HTTP et des exports

✓ Linting CI pour contrôler l'encodage des sources et des données

Checklist rapide

Encodage unique sur tout le projet (UTF‑8 recommandé) ou ISO‑8859‑1 clairement assumé

En-têtes HTTP/HTML/email déclarant le charset exact

Base de données configurée (utf8mb4 conseillé) et connexions alignées

Outil dans l’éditeur pour visualiser/changer l’encodage des fichiers

Tests qui valident le charset attendu des I/O et exports CSV

Documentation développeurs sur ISO‑8859‑1, Windows‑1252 et UTF‑8

Conclusion

ISO 8859‑1 a longtemps été la norme en Europe de l’Ouest. Aujourd’hui, l’unification sur UTF‑8 simplifie les échanges, mais comprendre Latin‑1 reste indispensable pour maintenir des systèmes existants et fiabiliser les imports/exports.

Déclarez clairement le charset, détectez les mélanges ISO‑8859‑1/UTF‑8 et convertissez proprement : vous évitez l’essentiel des problèmes d’affichage et de parsing.

ISO 8859-1 (Latin-1) : encodage, compatibilité et erreurs fréquentes