CSV mal formé : diagnostiquer et corriger avec awk et sed

Vous avez déjà reçu un fichier CSV censé être bien carré — un nombre de colonnes fixe, une ligne par enregistrement — et découvert, au moment de l’importer, qu’il refusait de se charger correctement ? Décalages de colonnes, lignes en trop, données dans les mauvais champs : le CSV « mal formé » est l’un des problèmes les plus courants et les plus agaçants du traitement de données.

La bonne nouvelle, c’est que deux outils Unix classiques, awk et sed, permettent de diagnostiquer et de corriger la plupart de ces anomalies en quelques commandes, sans ouvrir le fichier dans un éditeur (ce qui est souvent impossible quand il fait plusieurs centaines de milliers de lignes). Cet article présente un cas pratique complet, du diagnostic à la correction.

Le problème : un CSV dont les colonnes « bougent »

Prenons un cas réaliste. Vous recevez un export de commandes, censé contenir 5 colonnes séparées par des points-virgules : id;client;adresse;ville;montant. À l’import, votre outil se plaint de lignes invalides. En apparence, le fichier semble normal ; en réalité, certaines lignes ont plus de champs que prévu.

Voici un extrait du fichier :

id;client;adresse;ville;montant
1001;Dupont SARL;12 rue des Lilas;Paris;1250.00
1002;Martin & Fils;5 avenue Victor Hugo;Lyon;890.50
1003;Durand SA;8 place du Marché; Bât. C;Marseille;2100.00
1004;Leroy EURL;3 impasse des Roses;Nantes;450.00

Repérez-vous l’anomalie ? La ligne 1003 contient une adresse « 8 place du Marché; Bât. C » : le point-virgule à l’intérieur du champ adresse est interprété comme un séparateur. Cette ligne a donc 6 champs au lieu de 5, ce qui décale toutes les données suivantes. C’est l’une des causes les plus fréquentes de CSV mal formé : un champ texte contient le caractère séparateur.

Étape 1 : cartographier la structure avec awk

La première chose à faire n’est pas de corriger, mais de comprendre l’ampleur du problème. Combien de lignes sont concernées ? À partir d’où ? La commande suivante parcourt le fichier et signale chaque changement du nombre de champs :

awk -F';' 'NR==1{next} NF!=prev{if(prev!="")print "lignes "start"-"NR-1": "prev" champs"; start=NR; prev=NF} END{print "lignes "start"-"NR": "prev" champs"}' commandes.csv

Décortiquons-la : -F';' définit le point-virgule comme séparateur. NR==1{next} saute la ligne d’en-tête. NF est le nombre de champs de la ligne courante ; à chaque fois qu’il change par rapport à la ligne précédente (prev), on affiche le bloc de lignes qui vient de se terminer. Le résultat ressemble à ceci :

lignes 2-3: 5 champs
lignes 4-4: 6 champs
lignes 5-5: 5 champs

En une commande, on sait exactement où se trouvent les ruptures de structure. Sur un gros fichier, cette cartographie est précieuse : elle révèle si le problème touche quelques lignes isolées ou des blocs entiers.

Étape 2 : isoler les lignes fautives

Maintenant qu’on sait qu’il existe des lignes à 6 champs, affichons-les précisément, avec leur numéro de ligne, pour les examiner :

awk -F';' 'NR>1 && NF!=5 {print "Ligne "NR" ("NF" champs) : "$0}' commandes.csv

Cette commande ne garde que les lignes qui n’ont pas exactement 5 champs (le format attendu). Résultat :

Ligne 4 (6 champs) : 1003;Durand SA;8 place du Marché; Bât. C;Marseille;2100.00

On voit immédiatement le coupable. Pour simplement compter combien de lignes sont concernées (utile pour évaluer l’ampleur avant de corriger) :

awk -F';' 'NR>1 && NF!=5 {count++} END{print count" ligne(s) mal formée(s)"}' commandes.csv

Étape 3 : traquer les caractères invisibles

Parfois, le problème ne saute pas aux yeux car il vient de caractères invisibles : espaces en trop, tabulations, ou surtout les fameux retours chariot Windows (CR, affichés ^M). Pour les révéler, on utilise cat -A, qui affiche tous les caractères de contrôle :

sed -n '4p' commandes.csv | cat -A

Ici, sed -n '4p' extrait uniquement la ligne 4, et cat -A l’affiche en montrant les caractères cachés. Le $ en fin de ligne marque la fin ; s’il était précédé d’un ^M, cela signalerait un retour chariot Windows. C’est un réflexe essentiel quand un fichier venu de Windows est traité sous Unix.

Étape 4 : corriger avec sed

Une fois le diagnostic posé, place à la correction. Le cas le plus simple et le plus fréquent : supprimer les retours chariot Windows d’un fichier au format CRLF. Une seule commande sed suffit :

sed 's/\r$//' commandes.csv > commandes_propre.csv

Elle remplace le retour chariot (\r) en fin de chaque ligne par rien, et écrit le résultat dans un nouveau fichier. Point important : toujours écrire vers un nouveau fichier plutôt que d’écraser l’original, pour garder une porte de sortie en cas d’erreur.

Pour le problème du point-virgule dans un champ, la correction dépend du contexte. Si les adresses fautives suivent un motif reconnaissable, sed peut cibler et remplacer le séparateur parasite. Mais la vraie solution, à la source, est que l’export encadre les champs texte de guillemets (le CSV correctement quoté), ce qui permet aux séparateurs internes d’être ignorés. Quand ce n’est pas possible, on nettoie au cas par cas.

Le cas du retour à la ligne dans un champ

Une variante redoutable : un champ texte contient lui-même un saut de ligne. Une ligne logique se retrouve alors coupée en deux lignes physiques, et le fichier paraît avoir des lignes « trop courtes ». On les repère en cherchant les lignes qui ont trop peu de champs :

awk -F';' 'NR>1 && NF<3 {print "Ligne "NR" suspecte ("NF" champs) : "$0}' fichier.csv

Une ligne qui n’a qu’un seul champ alors qu’on en attend plusieurs est presque toujours le fragment d’une ligne précédente qui a débordé. Le recollage de ces lignes est plus délicat et se traite souvent avec un script awk dédié, mais l’essentiel est déjà fait : vous avez identifié le problème et sa nature.

La méthode générale à retenir

Face à n’importe quel CSV récalcitrant, la démarche est toujours la même :

• Cartographier la structure avec awk (compter les champs par ligne, repérer les ruptures) — on ne corrige jamais avant d’avoir compris.
• Isoler les lignes fautives pour les examiner et comprendre la cause (séparateur dans un champ, retour à la ligne, CRLF…).
• Révéler l’invisible avec cat -A quand le problème ne saute pas aux yeux.
• Corriger avec sed, toujours vers un nouveau fichier, jamais sur l’original.

Cette approche, méthodique et non destructive, permet de reprendre le contrôle sur des fichiers que les outils graphiques refusent d’ouvrir. C’est là toute la force de la ligne de commande : quelques commandes bien choisies traitent en secondes des fichiers de centaines de milliers de lignes.

Pour approfondir chacun de ces deux outils, nos guides complets détaillent toutes leurs possibilités : la commande awk pour l’analyse et le traitement par champs, et la commande sed pour les substitutions et transformations de texte. Maîtriser ces deux commandes, c’est se doter d’une boîte à outils qui résout l’immense majorité des problèmes de fichiers texte.