Le CSV n'est pas « juste du texte » ── La pratique du CSV dans les applications métier C# (encodage des caractères, compatibilité Excel, protection contre l'injection)

L’intégration de données via CSV reste aujourd’hui encore un acteur incontournable du monde des applications métier. Et parce qu’il donne l’impression de n’être « qu’un texte séparé par des virgules », c’est aussi un terrain où se répètent des incidents classiques : un analyseur maison qui casse sur une virgule à l’intérieur d’un champ, un fichier qui s’affiche mal une fois ouvert dans Excel, ou encore le zéro de tête d’un numéro de téléphone qui disparaît.

Cet article se place dans le contexte d’une application métier en C# qui lit et écrit du CSV, et fait le point, dans l’ordre où ces questions se posent en pratique, sur la spécification du CSV (RFC 4180) et ses variantes réelles, le choix de l’encodage des caractères, les problèmes de compatibilité avec Excel, la protection contre l’injection CSV, ainsi que les pièges liés à l’exploitation.

1. La conclusion d’abord (tableau de décision)

Les décisions de conception concernant le CSV se déduisent avant tout de la question : « qui (ou quoi) va ouvrir ce fichier ? »

Voici les conclusions, en premier lieu.

• L’analyse d’un CSV via String.Split(',') casse sur le plan des spécifications, même si elle semble fonctionner. En effet, elle ne peut pas traiter les virgules, sauts de ligne ou guillemets présents à l’intérieur d’un champ. Dans le cadre du standard .NET, utilisez TextFieldParser (chapitre 3).
• Les incidents d’encodage se produisent en fonction de la façon dont Excel interprète le fichier. Pour un CSV destiné à être ouvert par un humain dans Excel, l’UTF-8 avec BOM est actuellement le choix le plus sûr. Notons également un piège en .NET : le fait que le BOM soit ajouté ou non dépend de la manière dont l’Encoding est spécifié (chapitre 4).
• En .NET (Core), le Shift_JIS n’est pas utilisable sans package supplémentaire. Ce n’est qu’après avoir enregistré CodePagesEncodingProvider du package System.Text.Encoding.CodePages que Encoding.GetEncoding("shift_jis") réussit. C’est un point classique d’incident lorsqu’un traitement CSV migré depuis .NET Framework lève pour la première fois une exception en production.
• La perte des zéros de tête ou la conversion en date ne peuvent pas être évitées côté CSV. Le fait qu’entourer le champ de guillemets ne suffise pas à l’empêcher est un point important à retenir (chapitre 5).
• Une application qui écrit dans un CSV des données saisies par un utilisateur doit se protéger contre l’injection CSV. Un champ commençant par = ou + est interprété par Excel comme une formule (chapitre 6).

2. La « spécification » du CSV ── la RFC 4180 et ses variantes réelles

Le CSV dispose d’une norme de fait, la RFC 4180¹. Il n’y a en pratique que quatre règles essentielles à retenir.

1. Les enregistrements sont séparés par un saut de ligne (CRLF), les champs par une virgule.
2. Si un champ contient une virgule, un saut de ligne ou un guillemet double, l’intégralité de ce champ doit être entourée de guillemets doubles.
3. Un guillemet double à l’intérieur d’un champ est échappé en le doublant : "".
4. Un champ qui n’a pas besoin d’être entouré de guillemets peut l’être ou non, au choix.

Autrement dit, la ligne suivante constitue un enregistrement de 3 champs.

1001,"株式会社サンプル 営業部","住所は""東京都○○区1-2-3""です,と入力された備考"

Et la RFC 4180 n’étant qu’une « norme de fait », le CSV réel présente une multitude de variantes : saut de ligne en LF seul, absence de traitement des guillemets, séparateur tabulation ou point-virgule, ligne d’en-tête présente ou non… C’est précisément pour cela que préciser dans le cahier des charges d’intégration la mention « conforme à la RFC 4180 », ainsi que l’encodage des caractères, la présence du BOM, le caractère de fin de ligne et la présence ou non d’un en-tête constitue le travail au meilleur rapport coût/efficacité pour prévenir les problèmes ultérieurs.

3. Ne pas faire de traitement maison avec Split(‘,’) ── la pratique de la lecture

Compte tenu des règles du chapitre précédent, la raison pour laquelle String.Split(',') casse est évidente : une virgule à l’intérieur d’un champ provoque un découpage superflu, et un saut de ligne à l’intérieur de guillemets coupe la ligne en plein milieu. Si « le fichier reçu actuellement fonctionne parce qu’il ne contient pas de données avec des virgules », cela peut casser à tout moment selon les données.

Pour lire correctement dans le cadre du standard .NET, on peut utiliser Microsoft.VisualBasic.FileIO.TextFieldParser. L’espace de noms appartient à Visual Basic, mais il s’utilise sans problème depuis C#.

using Microsoft.VisualBasic.FileIO; // Microsoft.VisualBasic.Core (inclus dans le SDK pour applications de bureau Windows)

using var parser = new TextFieldParser(path, System.Text.Encoding.UTF8)
{
    TextFieldType = FieldType.Delimited,
    HasFieldsEnclosedInQuotes = true, // Traite correctement les champs entourés de guillemets
    TrimWhiteSpace = false, // La valeur par défaut est true (les espaces en début/fin sont supprimés silencieusement). À désactiver si les espaces ont une signification dans les données
};
parser.SetDelimiters(",");

while (!parser.EndOfData)
{
    try
    {
        string[]? fields = parser.ReadFields();
        if (fields is null) break;
        // Traiter fields[0], fields[1], ...
    }
    catch (MalformedLineException ex)
    {
        // Ligne mal formée : ErrorLine / ErrorLineNumber permettent d'enregistrer le contenu et le numéro de ligne
        logger.LogWarning("La ligne {Line} du CSV est dans un format invalide : {Content}",
            ex.LineNumber, parser.ErrorLine);
    }
}

L’avantage pratique de TextFieldParser, au-delà du traitement des guillemets (HasFieldsEnclosedInQuotes), est de pouvoir détecter les lignes mal formées sous forme d’une MalformedLineException accompagnée du numéro de ligne. Dans l’import de CSV en milieu métier, la question « faut-il rejeter tout le fichier si une ligne est mal formée, ou seulement ignorer cette ligne en le signalant ? » est un point de bascule des spécifications ; cette gestion des exceptions peut donc être directement traduite dans le cahier des charges.

Si l’on a en plus besoin du mapping colonnes/objets, de la conversion de types, ou de performances à l’échelle de plusieurs millions de lignes, il convient d’envisager une bibliothèque CSV éprouvée (largement utilisée sur NuGet). Quel que soit le choix de la bibliothèque, il y a quatre points à vérifier : « le traitement des guillemets conforme à la RFC 4180 », « la spécification de l’encodage », « la gestion des lignes mal formées » et « la possibilité d’une lecture en streaming ».

Côté écriture, les spécifications étant plus simples, un traitement maison reste réaliste, mais il faut impérativement centraliser l’échappement dans une seule fonction.

// Centraliser l'échappement d'écriture dans cette seule fonction
static string ToCsvField(string? value)
{
    value ??= string.Empty;
    bool needsQuoting = value.Contains(',') || value.Contains('"')
        || value.Contains('\r') || value.Contains('\n');
    return needsQuoting ? $"\"{value.Replace("\"", "\"\"")}\"" : value;
}

S’il reste ne serait-ce qu’un seul endroit où « seule la colonne des montants fait l’objet d’un string.Join écrit à la main », c’est là que se produira l’incident futur.

4. L’encodage des caractères ── le comportement d’Excel et les pièges de .NET

4.1 Pour une ouverture dans Excel, utiliser de l’UTF-8 avec BOM

La majorité des problèmes d’affichage dans un CSV vient du fait qu’Excel se trompe sur l’encodage du fichier. Si l’on ouvre en double-cliquant un CSV en UTF-8 sans BOM (les quelques octets en tête de fichier qui servent de marqueur), certains environnements l’interprètent comme de l’ANSI (Shift_JIS en environnement japonais), ce qui rend le japonais totalement illisible. Avec de l’UTF-8 avec BOM, le fichier est reconnu comme de l’UTF-8 ; pour un CSV qu’un humain ouvre en double-cliquant dans Excel, l’UTF-8 avec BOM est donc actuellement le choix le plus sûr.

À cela s’ajoute un piège côté .NET : la présence ou non du BOM dépend de la façon dont l’Encoding est passé.

// UTF-8 sans BOM : comportement par défaut lorsque l'encodage n'est pas précisé
File.WriteAllText(path, csv);

// UTF-8 avec BOM : Encoding.UTF8 (propriété statique) est configuré pour produire un BOM
File.WriteAllText(path, csv, Encoding.UTF8);

// Pour expliciter clairement l'intention, préférer le passage par le constructeur
File.WriteAllText(path, csv, new UTF8Encoding(encoderShouldEmitUTF8Identifier: true));

Le fait que le fichier produit diffère selon que l’on passe Encoding.UTF8 ou que l’on omette l’encodage est une spécification qu’on ne peut découvrir qu’en la connaissant déjà. Une fois qu’on a décidé, en tant que spécification, « pas de BOM pour les intégrations entre systèmes » et « BOM pour Excel », il est recommandé d’expliciter cette intention dans le code également, via new UTF8Encoding(...).

4.2 Utiliser le Shift_JIS en .NET (Core) nécessite un enregistrement

Dans les intégrations avec des systèmes legacy, le CSV en Shift_JIS (page de code 932) reste encore aujourd’hui d’actualité. Le point important ici est que .NET (Core) / .NET 5 et versions ultérieures ne prennent en charge par défaut que la famille Unicode et quelques encodages comme l’ASCII. Encoding.GetEncoding("shift_jis") lève une exception tant qu’on n’a pas ajouté le package System.Text.Encoding.CodePages et enregistré CodePagesEncodingProvider.

using System.Text;

// À enregistrer une seule fois au démarrage de l'application (Program.cs, etc.)
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

// On peut désormais obtenir le Shift_JIS (page de code 932)
Encoding sjis = Encoding.GetEncoding("shift_jis");

C’est un incident classique lorsqu’une application ayant migré son traitement CSV depuis l’ère .NET Framework vers .NET reçoit pour la première fois en production un fichier en Shift_JIS et lève une exception. Les points de contrôle à vérifier lors d’une migration sont regroupés dans « Liste de contrôle avant la migration de .NET Framework vers .NET ».

Par ailleurs, dès lors qu’on utilise le Shift_JIS, on ne peut pas éviter les caractères dépendants du matériel (comme ① ou ㈱), le problème du tilde ondulé, ou la perte de caractères qui n’existent qu’en Unicode. Ces bases sur l’encodage des caractères sont détaillées dans « Les mécanismes de l’encodage des caractères et des problèmes d’affichage sous Windows » et « La pratique de l’encodage des caractères et des caractères de fin de ligne sous Windows ».

5. Les données qui se corrompent à l’ouverture dans Excel ── perte des zéros de tête, conversion en date, notation exponentielle

Même en corrigeant l’encodage des caractères, il subsiste un autre groupe de problèmes pour la consultation dans Excel : Excel « interprète » les valeurs lorsqu’il ouvre un CSV.

Et le point important est que rien de tout cela ne peut être évité en entourant le champ de guillemets doubles. Les guillemets ne font qu’indiquer une délimitation syntaxique du CSV ; Excel réinterprète ensuite le contenu.

En pratique, il existe trois options.

1. Faire ouvrir le fichier via la procédure correcte d’Excel. Plutôt qu’un double-clic, utiliser la fonction « Importation de données (à partir d’un fichier texte/CSV) » d’Excel en spécifiant le type « Texte » pour les colonnes concernées évite toute corruption. Cela vaut la peine d’être consigné dans un manuel d’exploitation.
2. Si la consultation est l’objectif principal, produire un fichier xlsx. Le format des cellules pouvant être contrôlé côté génération, ce groupe de problèmes disparaît à la racine. Pour la façon de créer une sortie Excel, voir « Comment créer une sortie de rapport Excel ». Notez par ailleurs que l’automatisation COM d’Excel sur un serveur ou dans un service n’est pas recommandée : comme expliqué dans « Le problème d’EXCEL.EXE qui reste en mémoire », cela favorise la persistance de processus résiduels ; il vaut donc mieux privilégier une génération basée sur une bibliothèque.
3. Produire un format ="007" est un dernier recours. C’est une astuce qui s’affiche comme du texte dans Excel, mais qui transforme le fichier CSV en un « fichier non standard contenant des formules », ce qui casse toute importation en dehors d’Excel. À ne pas utiliser pour un fichier partagé avec d’autres systèmes.

6. L’injection CSV ── ne pas transformer une saisie utilisateur en formule

Une application qui écrit dans un CSV des valeurs saisies par un utilisateur (nom, remarques, adresse, etc.) pour les faire ouvrir dans Excel est exposée à une voie d’attaque appelée injection CSV. Excel interprète comme une formule tout champ commençant par =, +, -, @, etc., ce qui signifie qu’une saisie malveillante (par exemple une formule visant à lancer un processus externe, du type =cmd|'/C calc'!A0) peut s’exécuter dans l’environnement d’un autre utilisateur qui ouvre le CSV.

La parade de base consiste à neutraliser à l’écriture les caractères de tête dangereux.

// Ajoute une apostrophe simple devant les champs susceptibles d'être interprétés comme des formules.
// En environnement japonais, les caractères pleine chasse ＝＋－＠ peuvent également être interprétés
// comme un début de formule : il faut donc les inclure
static string SanitizeForExcel(string value)
{
    if (value.Length > 0 && value[0]
        is '=' or '+' or '-' or '@' or '\t' or '\r' or '\n'
        or '＝' or '＋' or '－' or '＠')
    {
        return "'" + value;
    }
    return value;
}

L’apostrophe simple en tête sert de marqueur pour qu’Excel « traite la valeur comme du texte ». Notons que la liste des caractères de tête dangereux peut varier selon l’implémentation et la version du tableur : concevoir cette neutralisation sous la forme d’une liste d’autorisation (« ne laisser passer tel quel que si le premier caractère correspond à cette liste, par exemple alphanumérique ») rend le dispositif plus robuste face aux cas non prévus. Il faut toutefois noter que si un autre système importe ensuite ce CSV, l’apostrophe simple restera dans la donnée : on peut donc envisager de séparer les fichiers entre un usage « pour ouverture dans Excel » et un usage « pour import système ». Pour la question de combiner ou non cette mesure avec une validation de la saisie (par exemple, interdire d’emblée un = en tête), et plus généralement pour la conception de la sécurité de l’ensemble de l’application, voir « Liste de contrôle minimale de sécurité pour une application Windows ».

7. Les pièges de l’exploitation ── où l’on rencontre des incidents en dehors du format lui-même

Pour finir, voici un récapitulatif des points où des incidents pratiques surviennent en dehors de la syntaxe du CSV elle-même.

• Ne pas laisser le format des nombres et des dates dépendre de la culture du système d’exploitation. value.ToString() est influencé par les paramètres régionaux du système d’exploitation. Dans une région où la virgule est le séparateur décimal, on obtiendra une sortie du type 1,5, qui entre en conflit avec le séparateur du CSV. Pour toute conversion destinée à l’intégration de fichiers, expliciter CultureInfo.InvariantCulture, et utiliser pour les dates un format fixe du type yyyy-MM-dd. La conception des dates est détaillée dans « Conception des dates/heures et des fuseaux horaires dans une application métier ».
• Traiter les gros volumes de données en streaming ── mais la question de savoir si un traitement « ligne par ligne » convient dépend des spécifications. File.ReadAllLines charge toutes les lignes en mémoire sous forme de tableau, ce qui ne convient pas aux gros fichiers. Remplacer cela par File.ReadLines (énumération différée) ou par une lecture ligne par ligne avec StreamReader n’est acceptable que pour les fichiers dont la spécification indique explicitement qu’un saut de ligne à l’intérieur d’un champ n’est pas autorisé. Pour un CSV conforme à la RFC 4180, qui autorise un saut de ligne à l’intérieur de guillemets, un découpage ligne par ligne coupera un enregistrement en plein milieu. Dans ce cas, utilisez TextFieldParser en lui passant directement le chemin du fichier (il peut traiter le fichier sans tout charger en mémoire), ou la lecture en streaming d’une bibliothèque CSV.
• Ne pas faire lire, et ne pas lire soi-même, un « fichier en cours d’écriture ». Côté écriture, écrire d’abord sous un nom de fichier temporaire puis le renommer ; côté import, vérifier l’exclusion avant de lire : cette forme de base de l’intégration de fichiers est détaillée dans « Les bases du contrôle d’exclusion pour l’intégration de fichiers », et les précautions pour un import via surveillance de dossier sont regroupées dans « Guide pratique de FileSystemWatcher ».
• Se préparer aux ajouts ou suppressions de colonnes. Il faut préciser dans les spécifications si l’on associe les colonnes par le nom figurant dans la ligne d’en-tête, ou si l’ordre des colonnes est fixe avec un contrôle du nombre de colonnes rejetant tout écart. Une référence implicite du type fields[7], sorte de nombre magique, cassera silencieusement à la moindre colonne supplémentaire ajoutée par le partenaire d’intégration.
• Déterminer à l’avance le traitement du saut de ligne final et des lignes vides. La présence ou non d’un saut de ligne après la dernière ligne, ou le fait d’ignorer ou de rejeter les lignes vides, sont des points où le comportement diverge selon l’implémentation de l’analyseur. TextFieldParser ignore les lignes vides.

Résumé

Le CSV a l’apparence d’un format « qui ne fait que séparer par des virgules », alors qu’il est en réalité truffé de variantes. Quatre points essentiels en pratique : utiliser pour la lecture un composant capable de traiter les guillemets (ne pas faire de traitement maison avec Split), déterminer l’encodage des caractères en le déduisant de qui va ouvrir le fichier (Excel en particulier) et préciser jusqu’à la présence du BOM dans les spécifications, savoir que l’interprétation des valeurs par Excel (perte de zéro, conversion en date) ne peut pas être évitée côté CSV, et mettre en place une protection contre l’injection si l’on écrit des saisies utilisateur en sortie ── ces quatre points suffisent à éliminer, dès la phase de conception, la grande majorité des incidents liés à l’intégration CSV.

L’investigation des problèmes d’affichage ou de corruption de données dans une intégration CSV existante, la clarification des spécifications d’intégration avec un système legacy, ou l’implémentation de nouvelles fonctionnalités d’import/export CSV nécessitent souvent une évaluation au cas par cas, en fonction des fichiers réels et des spécifications du partenaire d’intégration : n’hésitez pas à nous consulter en cas de doute.

Articles connexes

• Les mécanismes de l’encodage des caractères et des problèmes d’affichage sous Windows
• La pratique de l’encodage des caractères et des caractères de fin de ligne sous Windows
• Comment créer une sortie de rapport Excel
• Le problème d’EXCEL.EXE qui reste en mémoire avec l’interopérabilité COM Excel
• Les bases du contrôle d’exclusion pour l’intégration de fichiers
• Guide pratique de FileSystemWatcher
• Conception des dates/heures et des fuseaux horaires dans une application métier
• Liste de contrôle avant la migration de .NET Framework vers .NET
• Liste de contrôle minimale de sécurité pour une application Windows

Domaines de conseil associés

Komura Soft LLC (合同会社小村ソフト) propose du conseil technique portant sur le développement d’applications métier incluant l’intégration CSV et de fichiers, l’investigation des causes de problèmes d’affichage ou de corruption de données dans des intégrations existantes, ainsi que la clarification des spécifications d’intégration avec des systèmes legacy.

• Développement d’applications Windows
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quel encodage de caractères faut-il utiliser pour un fichier CSV ?

Le principe de base est de s'aligner sur la spécification du destinataire si celui-ci est déjà défini. Lorsqu'il est possible de choisir librement, un bon point de départ consiste à préciser dans le cahier des charges que les fichiers destinés à être ouverts par un humain dans Excel utilisent de l'UTF-8 avec BOM, tandis que les intégrations entre systèmes utilisent de l'UTF-8 sans BOM. Si une intégration avec un système legacy impose le Shift_JIS, il faut convenir au préalable du traitement des caractères dépendants du matériel et des caractères hors norme, sous peine de conflits ultérieurs sur la responsabilité des problèmes d'affichage.

Faut-il utiliser une bibliothèque CSV, ou un traitement maison suffit-il ?

Pour la lecture, un traitement maison basé sur String.Split ne peut pas gérer correctement, sur le plan des spécifications, certains cas (virgule, saut de ligne ou guillemet à l'intérieur d'un champ) : il faut donc utiliser un composant dédié. Dans le cadre du standard .NET, TextFieldParser prend en charge un traitement des guillemets équivalent à la RFC 4180. Si l'on a besoin en plus du mapping colonnes/objets, de la conversion de types et de performances sur de gros volumes, il vaut mieux envisager une bibliothèque CSV éprouvée. L'écriture, dont les spécifications sont plus simples, peut raisonnablement rester maison, à condition de centraliser l'échappement des guillemets dans une seule fonction commune utilisée partout.

Faut-il privilégier un séparateur tabulation (TSV) plutôt que la virgule ?

Si les données contiennent fréquemment des virgules (adresses, noms, montants, etc.), passer au TSV réduit la fréquence du traitement des guillemets et facilite la vérification visuelle. Cependant, les tabulations et les sauts de ligne peuvent tout de même apparaître dans les données : cela ne dispense donc pas du traitement des guillemets. Attention à ne pas penser que « puisque c'est du TSV, il n'y a pas besoin de se soucier du séparateur ». Si un accord est possible avec le partenaire d'intégration, préciser dans le cahier des charges l'encodage, les guillemets, le caractère de fin de ligne et la présence ou non d'un en-tête est plus efficace pour prévenir les incidents que le choix du séparateur lui-même.

Si l'objectif est l'ouverture dans Excel, ne vaudrait-il pas mieux produire un fichier Excel plutôt qu'un CSV ?

Si l'objectif principal est qu'un humain consulte ou imprime le fichier dans Excel, il vaut la peine d'envisager une sortie au format xlsx. Le CSV est un format où, dès l'ouverture dans Excel, se produisent la perte des zéros de tête ou la conversion en date, et il n'existe aucun moyen d'empêcher totalement cela côté CSV. Avec du xlsx, le format des cellules peut être contrôlé côté génération. En revanche, si l'objectif principal est l'importation dans un autre système et que la consultation dans Excel n'est qu'accessoire, il est plus réaliste de conserver le CSV et d'indiquer, comme procédure d'exploitation, la marche à suivre pour l'importation (en utilisant la fonction d'import de données).

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.