Convertir entre formatos de lista sin perder datos: las reglas de comillas que nadie lee

La línea de código y el momento exacto en que se rompe

Lista con saltos de línea a lista con comas: es una unión. A la inversa: un corte. Ambas son correctas exactamente mientras ningún elemento contenga el delimitador, y en cuanto uno lo contiene la conversión deja de ser reversible sin decirlo. Nuestra lista de prueba de cinco elementos — Smith, John / Doe, Jane / O’Neill, «Bud» / una dirección de dos líneas / plain — unida por comas y vuelta a cortar devolvió ocho elementos. Nada lanzó una excepción, nada avisó, y tres de los ocho eran fragmentos de nombres. Ese silencio es todo el problema: un conversor de listas que pierde datos produce una lista plausible, no un error.

El mismo experimento en cada una de nuestras lenguas da la misma forma: tres entradas «apellido, nombre» se convierten en seis tras una ida y vuelta ingenua, en inglés, francés, español, portugués, alemán e italiano por igual. Escritas con un generador RFC 4180 y releídas con un analizador RFC 4180, todas vuelven como tres elementos idénticos a la entrada. La regla no es propia de una lengua; solo lo son los datos que la hacen tropezar.

Lo que dice de verdad la RFC 4180

La RFC 4180 es corta, de octubre de 2005 y — conviene saberlo — Informational, no una norma. Sus siete reglas: los registros se separan con CRLF; el último no necesita terminar con uno; puede haber una línea de cabecera opcional al principio; los campos se separan con comas y los espacios forman parte del campo; entrecomillar es opcional, pero un campo sin comillas no puede contener una comilla doble; los campos que contienen saltos de línea, comillas dobles o comas deben ir entre comillas dobles; y una comilla doble dentro de un campo entrecomillado se escapa anteponiéndole otra comilla doble. Esa última regla es la que la gente sustituye por un invento, normalmente una barra invertida, que ningún lector de CSV espera.

La gramática ABNF de la sección 2 es más estricta que cualquier uso real. TEXTDATA se define como %x20-21 / %x23-2B / %x2D-7E, lo que excluye la coma en %x2C y la comilla doble en %x22 — y también todo byte por encima de 127. Lo comprobamos: «plain» es conforme a TEXTDATA; «café», «naïve», «Straße» y «ação» no lo son. En la práctica el parámetro charset del tipo de medio text/csv lleva la codificación y todo el mundo escribe UTF-8, pero recuerda que la RFC codificó un desorden existente en lugar de diseñar un formato. El propio documento lo dice al recomendar ser conservador en lo que se produce y liberal en lo que se acepta.

Un campo CSV puede contener un salto de línea

Es la regla que rompe más importadores, porque contradice el modelo mental de un registro por línea. Escribimos un fichero de dos registros cuyo segundo campo es una dirección de dos líneas: los bytes son id-1,"Line one CRLF Line two",ok CRLF id-2,flat,ok. Cortado por el salto de línea da tres fragmentos; analizado correctamente da dos registros, el primero de los cuales contiene el salto intacto. Cualquier código que lea un CSV con readLines está mal ante esta entrada, y la entrada no es exótica — direcciones, descripciones de producto y notas pegadas contienen saltos de línea.

Los finales de línea merecen su propio párrafo. La RFC exige CRLF entre registros, y cortar «a,b CRLF c,d CRLF» solo por el salto de línea devuelve ["a,b\r", "c,d\r", ""] — dos campos con un retorno de carro invisible pegado y una cola vacía. Ese \r suelto explica que un valor se compare distinto de sí mismo entre dos sistemas y que una cadena vacía final se convierta en una última fila fantasma. Un analizador que consuma CRLF, LF y un CR aislado como separadores de registro maneja las tres familias de ficheros y devuelve los mismos dos registros para cada una.

Por qué media Europa escribe CSV con punto y coma

Pregunta a la plataforma qué aspecto tiene un número en cada una de nuestras seis locales y la colisión salta a la vista. Formatear 1234567.5 da 1,234,567.5 en en-US, 1 234 567,5 en fr-FR con un espacio fino irrompible U+202F como separador de grupos, 1.234.567,5 en es-ES, de-DE e it-IT, y 1 234 567,5 en pt-PT con U+00A0. Cinco de las seis usan la coma como marca decimal. Una lista de precios delimitada por comas en esas locales tiene por tanto una coma dentro de un campo en cada fila — y por eso mismo sus hojas de cálculo escriben y esperan el punto y coma.

La ejecución lo hace concreto. La fila Silla / 1.299,00 / 2 unida por comas se analiza como cuatro campos — Silla, 1.299, 00, 2 — porque la marca decimal es una coma en español. La fila Chair / 1,299.00 / 2 se analiza también como cuatro por la razón especular: el separador de miles es una coma en inglés. Entrecomilla el campo de precio y ambas vuelven a ser tres campos; usa un punto y coma y ambas son tres campos sin ninguna comilla. Ninguna vía es más correcta: el punto y coma es la que una hoja de cálculo europea abre sin diálogo de importación, y las comas entrecomilladas la que aceptará una API.

Elementos vacíos, separadores finales y lo que ninguna ida y vuelta puede recuperar

Cortar la cadena vacía por la coma devuelve un elemento vacío, no cero. «a,b,» devuelve tres elementos, el último vacío. «,a» devuelve dos, el primero vacío. «a,,b» devuelve tres, el del medio vacío. Ninguno es un error; todos son consecuencia de una sola definición — un separador separa, así que n separadores significan n+1 elementos. Lo que la gente suele querer es la versión filtrada, y filtrar es una decisión que borra en silencio un campo genuinamente vacío.

El caso irrecuperable está en la escritura. Unir la lista vacía y unir una lista con una cadena vacía producen ambas la cadena vacía, así que las dos son idénticas en el cable y ningún analizador puede distinguirlas. Nuestro propio analizador mínimo lo agravó: al leer la cadena vacía devolvía cero registros, lo cual es correcto para una de las dos entradas y falso para la otra. Cambiar a un generador que entrecomilla todos los campos lo arregla exactamente: un elemento vacío pasa a ser los dos caracteres "" y se relee como un único elemento vacío, mientras que cero elementos siguen siendo la cadena vacía y se releen como nada. Si en tus datos pueden aparecer elementos vacíos, entrecomillar siempre no es una cuestión de estilo.

JSON, tabuladores y elegir un delimitador a propósito

Un array JSON esquiva toda la discusión entrecomillando todo y escapando el resto: nuestra lista de cinco elementos sobrevivió a la ida y vuelta sin cambios, con la dirección de dos líneas guardada como una sola cadena que contiene \n. Es el formato a elegir cuando hay un programa en ambos extremos. Su coste es que todo consumidor debe ser un analizador JSON, y que JSON tiene tipos — una lista de códigos postales vuelve como números si alguien los escribe sin comillas, y 01234 vuelve como 1234 o como error de sintaxis.

Los valores separados por tabuladores son el formato sin especificación, y por eso funcionan tantas veces y fallan tan callados. Nuestra lista adversa contenía un tabulador dentro de un elemento, así que un delimitador de tabulador lo habría partido. Antes de elegir delimitador, mira: en esa lista la coma, el punto y coma y el tabulador aparecían dentro de elementos, mientras que la barra vertical, U+001F y el byte nulo no. Un delimitador que demostrablemente no aparece devuelve la conversión a la línea de código que parecía al principio — y si ninguno es seguro, entrecomilla. Una última nota práctica ajena al análisis: un campo que empieza por =, +, - o @ lo trata como fórmula una hoja de cálculo, así que una lista de cadenas suministradas por usuarios debe llevar esos campos neutralizados antes de que nadie abra el fichero.

Preguntas frecuentes

¿Un campo CSV puede contener de verdad un salto de línea?

Sí, y la RFC 4180 lo dice explícitamente: un campo que contenga saltos de línea debe ir entre comillas dobles, y la ABNF permite CR y LF dentro de un campo escapado. Escribimos un fichero de dos registros cuyo segundo campo tenía una dirección de dos líneas; ocupa tres líneas físicas, así que contar líneas da 3 y analizar da 2. Cualquier importador basado en leer líneas está mal ante ese fichero.

¿Un fichero delimitado por punto y coma sigue siendo CSV?

Según la RFC 4180 no, porque su ABNF fija el delimitador en %x2C, la coma. En la práctica es lo que escriben las hojas de cálculo en toda locale que use la coma decimal — cinco de nuestras seis. Conserva el resto de las reglas: entrecomilla los campos que contengan el delimitador, duplica las comillas, separa los registros con CRLF. Nombra el fichero con honestidad e indica el delimitador al entregarlo.

¿Una cadena vacía es un elemento o cero?

El corte dice uno: cortar «» por la coma devuelve una lista con un elemento vacío. La unión no puede decirlo, porque [] y [""] producen ambas la cadena vacía. Así que la respuesta es una convención que hay que elegir y anotar, no algo que contengan los datos. La única forma de conservar la distinción en una ida y vuelta es entrecomillar todos los campos, lo que convierte un elemento vacío en dos comillas y cero elementos en nada.

¿Cómo escapo una comilla doble dentro de un campo?

Duplicándola, dentro de un campo entrecomillado. El elemento say "hi" se escribe "say ""hi""" — una comilla de apertura, el texto con cada comilla interior escrita dos veces, una comilla de cierre. La barra invertida no hace nada: CSV no tiene escape por barra invertida. Nuestra lista adversa de once elementos, que incluía esa cadena y otra ya entrecomillada, hizo la ida y vuelta idéntica bajo esta regla.

¿Cuándo debería usar mejor un array JSON?

Siempre que en ambos extremos haya programas. JSON entrecomilla cada cadena y escapa los caracteres de control, así que los elementos con comas, comillas y saltos de línea no requieren trato especial: nuestra lista de cinco elementos hizo la ida y vuelta sin cambios, con el elemento de dos líneas guardado con \n dentro de una sola cadena. Prefiere CSV cuando al otro lado haya una hoja de cálculo o una persona, y recuerda que JSON tiene tipos: los identificadores con cero inicial deben seguir siendo cadenas.