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,005
lugar 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,1
hay 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.