¿Por qué una coma es un separador / delimitador de registros incorrectos en archivos CSV?

Estaba leyendo este artículo y tengo curiosidad por la respuesta adecuada a esta pregunta.

Lo único que se me ocurre es que, en algunos países, el separador decimal es una coma, y ​​puede haber problemas al compartir datos en CSV , pero no estoy realmente seguro de mi respuesta.

La especificación del formato CSV se define en RFC 4180 . Esta especificación fue publicada porque

no existe una especificación formal, lo que permite una amplia variedad de interpretaciones de archivos CSV

Desafortunadamente, desde 2005 (fecha de publicación del RFC), nada ha cambiado. Todavía tenemos una amplia variedad de implementaciones. El enfoque general definido en RFC 4180 es encerrar los campos que contienen caracteres como comas entre comillas, sin embargo, esta recomendación no siempre se cumple con un software diferente.

El problema es que en varias configuraciones regionales europeas el carácter de coma sirve como punto decimal, por lo que escribe en 0,005lugar de 0.005. Sin embargo, en otros casos, se usan comas en lugar de espacios para señalar grupos de dígitos, por ejemplo 4,000,000.00(ver aquí ). En ambos casos, el uso de comas podría conducir a errores en la lectura de datos de archivos csv porque su software realmente no sabe si 0,005, 0,1hay dos números o cuatro números diferentes (vea el ejemplo aquí ).

Por último, pero no menos importante, si almacena texto en su archivo de datos, entonces las comas son mucho más comunes en el texto que, por ejemplo, punto y coma, por lo que si su texto no está entre comillas, esos datos también pueden leerse fácilmente con errores .

Nada hace que las comas sean mejores o peores separadores de campo en la medida en que los archivos CSV se utilizan de acuerdo con las recomendaciones como RFC 4180 que protegen de los problemas descritos anteriormente. Sin embargo, si existe el riesgo de usar el formato CSV simplificado que no encierra los campos entre comillas, o si la recomendación se puede usar de manera inconsistente, entonces otros separadores (por ejemplo, punto y coma) parecen ser un enfoque más seguro.

Técnicamente, la coma es tan buena como cualquier otro personaje para ser usado como separador. El nombre del formato se refiere directamente a que los valores están separados por comas (valores separados por comas).

La descripción del formato CSV está usando una coma como separador.

Cualquier campo que contenga una coma debe estar entre comillas dobles. Por lo tanto, eso no causa problemas para leer datos. Vea el punto 6 de la descripción :

6. Los campos que contienen saltos de línea (CRLF), comillas dobles y comas deben ir entre comillas dobles.

Por ejemplo, las funciones read.csvy write.csvde R por defecto usan una coma como separador.

Además de ser un separador de dígitos en números, también forma parte de la dirección (como la dirección del cliente, etc.) en muchos países. Si bien algunos países tienen direcciones cortas bien definidas, muchos otros tienen direcciones sinuosas que incluyen, a veces, dos comas en la misma línea. Los buenos archivos CSV encierran todos estos datos entre comillas dobles. Pero los analizadores excesivamente simplistas y mal escritos no permiten leer y diferenciarlos. (Luego, está el problema de usar comillas dobles como parte de los datos, como la cita de un poema).

Si bien la respuesta de @Tim es correcta, me gustaría agregar que "csv" en su conjunto no tiene un estándar común, especialmente las reglas de escape no están definidas en absoluto, lo que lleva a "formatos" que son legibles en un programa, pero no en otro . Esto se ve exaltado por el hecho de que cada "programador" bajo el sol simplemente piensa "oooh csv- ¡Construiré mi propio analizador!" y luego pierde todos los casos límite.

Además, csv carece por completo de la habilidad para almacenar metadatos o incluso el tipo de datos de una columna, lo que lleva a varios documentos que debe leer para comprender los datos.

Si puede deshacerse del delimitador de coma y usar un carácter de tabulación, tendrá mucho más éxito. Puede dejar el archivo llamado .CSV e importarlo a la mayoría de los programas no suele ser un problema. Simplemente especifique TAB delimitado en lugar de coma cuando importe su archivo. Si hay comas en sus datos, tendrá un problema cuando especifique comas delimitadas, como ya sabe.

ASCII nos proporciona cuatro caracteres "separadores", como se muestra a continuación en un fragmento de la página de manual ascii (7) * nix:

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

Esta respuesta proporciona una descripción general decente de su uso previsto.

Por supuesto, estos códigos de control carecen de la amabilidad humana (legibilidad y entrada) de los delimitadores más populares, pero son opciones aceptables para el intercambio interno y / o efímero de datos entre programas.

El problema no es la coma; El problema es la cita. Independientemente del registro y delimitadores de campo que use, debe estar preparado para cumplirlos en el contenido. Entonces necesita un mecanismo de cotización. Y ENTONCES, también necesita una forma para que aparezcan los caracteres de cita

Seguir el estándar RFC 4180 simplifica todo para todos.

Personalmente, tuve que escribir un script para probablemente corregir la salida de un programa que hizo esto mal, así que soy un poco militante al respecto. "probablemente arreglar" significa que funcionó para MIS datos, pero puedo ver situaciones en las que podría fallar. (En defensa de ese programa, fue escrito antes del estándar).