Reglas de CSV RFC 4180

La gramática: registros, campos, CRLF

La gramática de RFC 4180 cabe en un párrafo. Un archivo consta de registros, cada uno una secuencia de campos separados por comas; los registros se separan con CRLF — los dos bytes 0x0D 0x0A, no el LF desnudo de las herramientas de Unix — y el último registro puede terminar o no con un CRLF final. Los campos pueden ir entre comillas o no: el entrecomillado es condicional, no un estilo. El boceto ABNF es file = [header CRLF] record *(CRLF record); record = field *(comma field) — fíjate en la cabecera opcional dentro de los corchetes.

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

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

(cada registro termina con los dos bytes CRLF;
el último puede omitirlos legalmente)

Entrecomillado: la comilla doble es todo el sistema de escape

Un campo va entre comillas dobles cuando tiene que ir, y la única manera de poner una comilla doble dentro de un campo entre comillas es duplicarla — "" dentro de un campo entre comillas significa una comilla literal. Ese es el mecanismo de escape al completo: sin barras invertidas, sin entidades con nombre, sin un segundo carácter de comillas. Las comillas simples son datos corrientes, y un espacio suelto tras una coma forma parte del campo siguiente — la especificación es explícita en que los espacios se conservan y no deben recortarse.

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

Saltos de línea y comas dentro de los campos

Como los campos entre comillas pueden contener saltos de línea, una línea de CSV no es un registro: un divisor ingenuo por \n corrompe cualquier archivo con campos de varias líneas — por eso los bloques de dirección, las columnas de notas y los JSON dentro de CSV hacen fracasar a los importadores ingenuos. Un analizador conforme es una pequeña máquina de estados: dentro de las comillas, las comas y los saltos de línea son datos; fuera, son separadores. No se puede escribir correctamente usando solo split().

Esa misma máquina de estados resuelve los casos límite de la comilla doble: una comilla que abre a mitad de valor, una comilla sin cerrar al final del archivo, comillas duplicadas justo al final de un campo. Son exactamente los casos que las pocas reglas de RFC 4180 pretendían resolver, y exactamente donde los analizadores hechos a mano discrepan entre sí — el origen de la mayoría de los partes del tipo «funciona en Excel, falla en el importador».

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

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

(la coma dentro de la dirección es dato;
también lo es el CRLF entre comillas)

CRLF, la cabecera opcional y text/csv

Tres detalles los fija la especificación y, con frecuencia, se da por hecho lo contrario. Los registros terminan con CRLF — aunque el último puede omitirlo, y cualquier analizador que uses a diario acepta un LF desnudo. El primer registro puede contener nombres de columna, pero la gramática lo trata como opcional: la cabecera es una convención que el formato admite, no una estructura que exija, y por eso hay que decirle a las herramientas — o deben adivinar — si la primera fila son datos. Y el tipo MIME registrado es text/csv — registrado por el propio RFC 4180 — con los parámetros charset a discreción del remitente.

Una frontera más que el RFC traza con firmeza: el delimitador es la coma. Los archivos separados por punto y coma son una convención regional de las hojas de cálculo — habitual donde la coma decimal es la norma — no una variante que el estándar reconozca. Un generador conforme nunca adivina, y un analizador conforme o detecta el delimitador o se le indica, pero el archivo en sí no lleva ninguna marca de qué convención sigue.

Dónde se desvían los archivos reales del estándar

El CSV real es anterior al RFC, así que la divergencia es la norma y no la excepción. Cinco desviaciones explican casi todos los incidentes de tipo «este CSV no se analiza»:

Las buenas herramientas muestran estas desviaciones en lugar de adivinar en silencio. Cuando un archivo importa — facturas, importaciones financieras, cualquier cosa que pueda leer un regulador — compáralo con la gramática de arriba y corrige la desviación en el origen, en vez de enseñarle la misma excepción a cada analizador posterior.

Escribir CSV que sobreviva a los viajes de ida y vuelta

La lista de comprobación del generador fiable se deduce directamente de la gramática: entrecomilla de forma uniforme — todos los campos, o exactamente los campos que exigen las reglas; ambos son conformes, pero el uniforme es más seguro al releer —, emite CRLF, escribe la fila de cabecera y codifica en UTF-8, aceptando que un BOM a veces es el precio del reconocimiento por parte de una hoja de cálculo. Haz ida y vuelta con todo lo importante: analiza el archivo que acabas de escribir, confirma que cada campo coincide con los datos de origen y, después, envíalo. El modo de fallo recurrente es siempre el mismo — un valor que contiene el delimitador y que el generador nunca entrecomilló.