Code page : problèmes courants, compatibilité et conversions

Qu'est-ce qu'une code page ?

C’est un tableau de correspondance entre des octets et des caractères. Selon la code page utilisée, les mêmes octets n’affichent pas les mêmes symboles.

Les familles de code pages et d'encodages les plus rencontrées :

1 ASCII et jeux mono-octet occidentaux

Jeux 7/8 bits historiques, utilisés dans de nombreux exports legacy.

ASCII (7-bit), ISO-8859-1 (Latin-1), ISO-8859-15 (Euro €)

2 Code pages Windows

Très répandues dans les applications bureautiques et certains systèmes.

Windows-1252 (CP1252), CP1250 (Europe centrale), CP1251 (Cyrillique)

3 Encodages multi-octets et internationaux

Recommandés pour les applications modernes et les contenus multilingues.

UTF-8 (sans BOM) - Standard du web

UTF-16 LE/BE - Souvent avec BOM

Shift_JIS, GBK - Encodages régionaux

UTF-32 - Rare, très verbeux

4 Pièges techniques liés aux code pages

Ce qui dérègle l’affichage ou la lecture des fichiers :

BOM (U+FEFF) - Marque d’ordre d’octets

Guillemets typographiques CP1252 (0x91/0x92)

� - Replacement character (caractère de remplacement)

Normalisation et variantes visuelles (NFC/NFD)

Problèmes classiques

Fichier enregistré dans la mauvaise code page

Un CSV en CP1252 servi en UTF-8 affiche Ã©, â€” et autres artefacts.

Chaînes "identiques" qui ne comparent pas

Accents décodés différemment (UTF-8 vs CP1252) font échouer les assertions.

Mojibake après import/export

Double encodage ou décodage avec une code page incorrecte.

Entêtes HTTP ou meta charset manquants

Sans charset explicite, le navigateur ou l’outil devine et se trompe.

Exemple de problème courant :

# Octets CP1252 interprétés comme UTF-8

string1 = "é"

string2 = "Ã©" # Fichier CP1252 lu en UTF-8

assert string1 == string2 # ❌ Échec

Symptômes qui doivent vous alerter

🚨 Signaux d'alarme

!

Un diff git montre des changements massifs après un “changement d’encodage”

!

Un parseur CSV découpe mal les colonnes à cause d’accentuation illisible

!

Un .env ou un JSON commence par ï»¿ (BOM) et échoue au chargement

!

Votre éditeur affiche “Windows-1252” ou “UTF-8 with BOM” dans la barre d’état

!

Au terminal, apparition de losanges � ou de points d’interrogation à la place des accents

Comment les détecter

✨ Solution recommandée : Clean ASCII

Clean ASCII met en évidence les octets hors ASCII et les marqueurs comme le BOM. En pratique, cela permet d’identifier rapidement si un texte provient d’une code page (CP1252, ISO-8859-1) ou s’il est déjà en UTF-8.

✅ Détection automatique

Octets hors ASCII, BOM, caractères de contrôle révélateurs

📊 Analyse complète

Indices d’encodage (fréquences, plages CP1252), positions exactes

🧹 Nettoyage automatique

Conversion vers UTF-8 et remplacement des caractères ambigus

💾 Export propre

Téléchargement en UTF-8 sans BOM, prêt à intégrer

🔍 Diagnostiquer ma code page

Autres méthodes de détection

Affichage dans l'éditeur

✓ Vérifiez l’encodage dans la barre d’état (UTF-8, CP1252) et changez-le si besoin

✓ Utilisez “Reopen with Encoding” (VS Code/JetBrains) pour tester l’affichage

En ligne de commande (Unix)

# Repérer des octets hors ASCII imprimable

grep -P "[^\x09\x0A\x0D\x20-\x7E]" fichier.txt

# Demander au système l’encodage supposé

file -I fichier.txt

# Tester une conversion vers UTF-8

iconv -f WINDOWS-1252 -t UTF-8 fichier.txt > sortie.txt

# Inspecter rapidement un BOM/entête

hexdump -C -n 4 fichier.txt

En code

JavaScript

Array.from(new TextEncoder().encode(str)).map(b => b.toString(16))

Python

__import__("chardet").detect(open("fichier.txt","rb").read())

Excel / Google Sheets

CODE(MID(cellule;position;1))

Nettoyer et prévenir

🚀 Solution rapide avec Clean ASCII

Avant d’écrire des scripts, utilisez Clean ASCII pour vérifier la présence d’un BOM, repérer des octets non-ASCII et convertir proprement en UTF-8.

✓ Détection d’encodage suspect

✓ Nettoyage et conversion UTF-8

✓ Export immédiat sans BOM

Nettoyer maintenant

Méthodes techniques avancées

🔧 Normaliser

✓ Convertissez toutes les sources en UTF-8 de bout en bout

✓ Supprimez les BOM inutiles dans les fichiers UTF-8

✓ Uniformisez les fins de ligne (dos2unix, gitattributes)

🧹 Filtrer

✓ Écrivez une fonction transcode_utf8() centralisée (iconv, mbstring)

✓ Remplacez les guillemets typographiques CP1252 par leurs équivalents ASCII

✓ Bloquez les octets hors plage attendue avant persistance

⚙️ Automatiser

✓ Hooks pre-commit qui refusent les fichiers non UTF-8

✓ Tests d’intégration vérifiant le charset des réponses HTTP

✓ CI avec lint encodage et conversions contrôlées

Checklist rapide

Fichiers en UTF-8 sans BOM

Fins de ligne uniformes via gitattributes

Éditeur configuré pour afficher/modifier l’encodage

Fonction de conversion UTF-8 intégrée à vos libs

Tests vérifiant l’absence d’octets invalides et de BOM

Documentation équipe sur code pages et conversions

Conclusion

Les code pages expliquent la plupart des soucis d’accents et de symboles brisés. En les maîtrisant, vous gagnez des heures de debug.

Unifiez l’encodage sur UTF-8, explicitez le charset dans vos flux et contrôlez vos conversions : la plupart des erreurs disparaissent.