csharp encoding : encodage, BOM et Unicode en C#

csharp encoding, c’est quoi dans .NET ?

C’est la façon dont des caractères sont transformés en octets et inversement. En C#/.NET, l’API System.Text.Encoding pilote ces conversions.

Les familles d’encodages les plus fréquentes dans les projets C# :

1 Encodages Unicode courants

Compatibles multi-langues, sûrs et recommandés par défaut.

UTF-8, UTF-16 LE/BE, UTF-32 — Encoding.UTF8, Encoding.Unicode, Encoding.UTF32

2 Pages de codes héritées (legacy)

Dépendent de la locale; utiles pour interop mais sources de bugs.

Windows-1252, ISO-8859-1, Shift-JIS — CodePagesEncodingProvider

3 Caractères Unicode piégeux

Ils semblent identiques à l’écran mais diffèrent en mémoire ou en octets :

NBSP (U+00A0) - Espace insécable

ZWSP (U+200B) - Zero Width Space

Caractères combinants (ex. e + U+0301)

Ligatures et espaces fins (U+2009, U+200A)

4 Marques techniques et fins de ligne

Impact direct sur csharp encoding et le parsing :

BOM (U+FEFF) - Preamble UTF-8/UTF-16

Soft Hyphen (U+00AD)

CRLF (Windows) vs LF (Unix)

Problèmes classiques en csharp encoding

Lectures/écritures implicites

Un fichier Windows-1252 lu en UTF-8 avec StreamReader produit des caractères cassés.

HTTP sans charset explicite

Un serveur omet charset. HttpClient suppose UTF-8 et vos accents sont erronés.

Normalisation Unicode différente

Deux chaînes visuellement identiques ne matchent pas (NFC vs NFD), créant des tests qui échouent.

Regex et classes Unicode

Sans RegexOptions adaptés, les motifs ne couvrent pas tous les blancs/lettres Unicode.

Exemple de problème courant :

// Deux chaînes visuellement identiques

var s1 = "é"; // U+00E9 (NFC)

var s2 = "e\u0301"; // 'e' + COMBINING ACUTE (NFD)

Assert.Equal(s1, s2); # ❌ Échec

Symptômes qui doivent vous alerter

🚨 Signaux d'alarme

!

Un diff git montre des changements massifs après “Enregistrer avec l’encodage” dans votre IDE

!

Des parseurs CSV affichent des points d’interrogation ou des losanges noirs

!

Un JSON/XML refuse de charger à cause d’un BOM au début du flux

!

Votre éditeur affiche des symboles � ou des carrés pour certains caractères

!

Copier-coller dans un terminal/console produit des ? à la place des accents

Comment les détecter

✨ Solution recommandée : Clean ASCII

Clean ASCII repère immédiatement les caractères problématiques avant ingestion par votre code C#. Collez vos données, l’outil révèle les caractères non-ASCII, NBSP, ZWSP, BOM et propose des remplacements sûrs.

✅ Détection automatique

NBSP, ZWSP, BOM, soft hyphens, caractères de contrôle

📊 Analyse complète

Codes Unicode, positions exactes, suggestions de remplacement

🧹 Nettoyage automatique

Conversion vers ASCII/UTF-8 propre pour vos pipelines C#

💾 Export propre

Téléchargement du texte nettoyé prêt pour vos tests et CI

🔍 Inspecter mes textes avant C#

Autres méthodes de détection

Affichage dans l'éditeur

✓ Activez “render whitespace”, “show BOM” dans VS/VS Code/JetBrains

✓ Vérifiez l’encodage du fichier (UTF-8 sans BOM recommandé)

En ligne de commande (Unix)

# Détecter l’encodage annoncé

file -bi fichier.txt

# Convertir de Windows-1252 vers UTF-8

iconv -f windows-1252 -t utf-8 fichier.txt > out.txt

# Inspecter la présence d’un BOM

head -c 3 fichier.txt | hexdump -C

# Visualiser fins de ligne et contrôles

sed -n l fichier.txt

En code

C# (.NET)

using var r = new StreamReader(path, new UTF8Encoding(false), detectEncodingFromByteOrderMarks: true);

PowerShell

Get-Content -Path .\fichier.txt -Encoding Byte | Select-Object -First 3 | ForEach-Object { '{0:X2}' -f $_ }

Excel / Google Sheets

CODE(MID(cellule;position;1)) # repérer NBSP/U+00A0 et autres

Nettoyer et prévenir

🚀 Solution rapide avec Clean ASCII

Avant d’écrire des conversions dans votre code, passez vos textes par Clean ASCII pour isoler les caractères piégeux et générer une version propre prête pour C#.

✓ Détection automatique

✓ Nettoyage intelligent

✓ Export immédiat

Nettoyer maintenant

Méthodes techniques avancées

🔧 Normaliser

✓ Utilisez string.Normalize(NormalizationForm.FormC) pour homogénéiser

✓ Écrivez en UTF-8 sans BOM: new UTF8Encoding(false)

✓ Uniformisez les fins de ligne (dos2unix, gitattributes)

🧹 Filtrer

✓ Remplacez NBSP/ZWSP et contrôles non désirés avant persistance

✓ Pour des sources legacy: CodePagesEncodingProvider.Instance puis re-encodez en UTF-8

✓ Bloquez les caractères de contrôle hors LF/CR/HT avec des validations

⚙️ Automatiser

✓ .editorconfig: charset = utf-8 et gitattributes pour EOL

✓ Tests unitaires pour valider encodage des fichiers et flux (BOM interdit, UTF-8 exigé)

✓ Vérifications CI: scan des octets hors plage et lints de textes

Checklist rapide

Fichiers en UTF-8 sans BOM

Fins de ligne uniformes via gitattributes

Affichage des blancs, contrôles et BOM dans l’éditeur

Helpers C# pour nettoyer NBSP/ZWSP et normaliser

Tests empêchant l’introduction de BOM et de pages de codes legacy

Documentation d’équipe sur csharp encoding et flux texte

Conclusion

csharp encoding n’est pas une option : maîtriser UTF-8, BOM et normalisation évite la plupart des corruptions de texte et des surprises en production.

Spécifiez toujours l’encodage, contrôlez la normalisation et automatisez les vérifications. Vous éliminez l’immense majorité des bugs d’affichage et de parsing.

csharp encoding en C# : éviter les pièges d'Unicode, BOM et pages de codes