Règles CSV RFC 4180

La grammaire : enregistrements, champs, CRLF

La grammaire de la RFC 4180 tient en un paragraphe. Un fichier se compose d’enregistrements, chaque enregistrement étant une suite de champs séparés par des virgules ; les enregistrements sont séparés par CRLF — les deux octets 0x0D 0x0A, et non le LF seul de l’outillage Unix — et le dernier enregistrement peut se terminer ou non par un CRLF final. Les champs peuvent être entre guillemets ou non : le recours aux guillemets est conditionnel, pas une affaire de style. L’esquisse ABNF est file = [header CRLF] record *(CRLF record); record = field *(comma field) — notez l’en-tête optionnel entre les crochets.

id,name,score
1,Ada,99
2,Grace,98

enregistrement 1 : id=1, name=Ada,   score=99
enregistrement 2 : id=2, name=Grace, score=98

(chaque enregistrement se termine par les deux octets CRLF ;
le dernier peut légalement les omettre)

Guillemets : le doublement du guillemet, seul système d’échappement

Un champ est encadré de guillemets doubles quand c’est nécessaire, et la seule façon d’insérer un guillemet double dans un champ entre guillemets est de le doubler — "" à l’intérieur d’un champ entre guillemets désigne un seul guillemet littéral. C’est là tout le mécanisme d’échappement : pas de barre oblique inverse, pas d’entités nommées, pas de second caractère de guillemets. Les apostrophes sont des données ordinaires, et un espace superflu après une virgule fait partie du champ suivant — la spécification est explicite : les espaces sont préservées et ne doivent pas être rognées.

year,quote,note
1962,"she said ""look, no hands""","multi-word, no problem"

year   → 1962
quote  → she said "look, no hands"
note   → multi-word, no problem

Sauts de ligne et virgules à l’intérieur des champs

Comme les champs entre guillemets peuvent contenir des sauts de ligne, une ligne CSV n’est pas un enregistrement : un découpage naïf sur \n corrompt tout fichier comportant des champs multi-lignes — voilà pourquoi les blocs d’adresse, les colonnes de notes et les payloads JSON dans le CSV font échouer les importateurs naïfs. Un parseur conforme est une petite machine à états : entre guillemets, les virgules et les sauts de ligne sont des données ; à l’extérieur, ce sont des séparateurs. Il est impossible de l’écrire correctement avec split() seul.

La même machine à états tranche les cas limites du guillemet double : un guillemet ouvrant au milieu d’une valeur, un guillemet non refermé en fin de fichier, des guillemets doublés tout à la fin d’un champ. Ce sont exactement les cas que les quelques règles de la RFC 4180 ont été écrites pour trancher, et exactement là où les parseurs faits main se contredisent — d’où la plupart des signalements du type « ça marche dans Excel, ça casse dans l’importateur ».

name,address
"Ada","12 St James Square,
London"
"Grace","1 Loop Rd"

enregistrement 1 : Ada | 12 St James Square,
London
enregistrement 2 : Grace | 1 Loop Rd

(la virgule dans l’adresse est une donnée ;
le CRLF entre guillemets aussi)

CRLF, l’en-tête optionnel et text/csv

Trois détails sont fixés par la spécification, et l’on suppose pourtant systématiquement le contraire. Les enregistrements se terminent par CRLF — même si le dernier enregistrement peut s’en passer, et même si chaque parseur que vous utilisez au quotidien accepte un LF seul. Le premier enregistrement peut contenir des noms de colonnes, mais la grammaire le considère comme optionnel : un en-tête est une convention que le format prend en charge, pas une structure qu’il exige — voilà pourquoi il faut dire à l’outillage — ou le laisser deviner — si la première ligne est une donnée. Et le type MIME enregistré est text/csv — enregistré par la RFC 4180 elle-même —, les paramètres de charset étant laissés à l’expéditeur.

Autre frontière que la RFC trace fermement : le délimiteur est la virgule. Les fichiers séparés par des points-virgule relèvent d’une convention de paramètres régionaux des tableurs — courante partout où la virgule décimale est la norme —, ce n’est pas une variante que la norme reconnaît. Un générateur conforme ne devine jamais, et un parseur conforme sonde le délimiteur ou se le fait préciser ; mais le fichier lui-même ne porte aucun marqueur de la convention qu’il suit.

Là où les fichiers réels dérivent de la norme

Le CSV réel précède la RFC, si bien que la divergence est la norme plutôt que l’exception. Cinq dérives expliquent presque tous les incidents du type « ce CSV ne veut pas s’analyser » :

Les bons outils exposent ces écarts au lieu de deviner en silence. Quand un fichier compte — factures, imports financiers, tout ce qu’un régulateur peut lire —, confrontez-le à la grammaire ci-dessus et corrigez la dérive à la source, plutôt que d’enseigner la même exception à chaque parseur en aval.

Écrire un CSV qui survit aux allers-retours

La liste de contrôle du producteur fiable découle directement de la grammaire : mettez des guillemets uniformément — tous les champs, ou exactement ceux que les règles exigent ; les deux sont conformes, mais l’uniformité se relit plus sûrement — émettez CRLF, écrivez la ligne d’en-tête et encodez en UTF-8, en acceptant qu’un BOM soit parfois le prix de la reconnaissance par un tableur. Faites faire un aller-retour à tout ce qui compte : analysez le fichier que vous venez d’écrire, confirmez que chaque champ correspond aux données sources, puis expédiez-le. Le mode de défaillance récurrent est toujours le même — une valeur contenant le délimiteur que le générateur n’a jamais mise entre guillemets.