CSV a JSON

CSV parece trivial de analizar — dividir cada línea por comas, tratar la primera línea como encabezados — hasta que un valor en los datos reales contiene una coma propia, lo cual ocurre constantemente con exportaciones reales de hojas de cálculo: una dirección como "123 Main St, Apt 4", un nombre de empresa como "Smith, Jones & Co", o una descripción de producto que contiene una lista. La especificación CSV, formalizada como RFC 4180, maneja esto permitiendo que un campo se envuelva en comillas dobles, dentro de las cuales las comas, saltos de línea e incluso caracteres de comilla literal (escapados duplicándolos) son simplemente datos en lugar de estructura. Un analizador que ingenuamente divide por cada coma, ignorando las comillas por completo, corrompe exactamente esas filas — dividiendo "Smith, Jones & Co" en dos columnas separadas — y normalmente lo hace silenciosamente, sin ningún error que señale que algo salió mal, que es lo que hace peligroso este error en lugar de solo molesto.

El análisis correctamente consciente de las comillas rastrea si el lector está actualmente dentro de un campo entrecomillado e ignora los caracteres delimitadores y de salto de línea hasta llegar a la comilla de cierre, que es la única forma de reconstruir correctamente campos que legítimamente contienen los caracteres que de otro modo se confundirían con estructura.

Cada valor en un archivo CSV crudo es texto, ya que CSV no tiene ningún concepto nativo de número, booleano o nulo — una celda que contiene `42` y una celda que contiene `hello` se almacenan de forma idéntica como caracteres. La inferencia de tipos es el proceso de adivinar qué cadenas estaban "realmente" destinadas a ser números, valores verdadero/falso o nulos, y convertirlas en consecuencia para que el JSON resultante tenga valores realmente tipados en lugar de que todo esté envuelto en comillas como una cadena.

Sin embargo, la conjetura tiene que ser conservadora, porque bastantes valores que parecen numéricos no están destinados a tratarse como números en absoluto. Un cero a la izquierda — `007`, `042` — normalmente señala un identificador o un código con relleno donde el cero inicial es significativo y se destruiría silenciosamente al convertirse a un número, ya que `7` y `007` son el mismo número pero identificadores muy distintos. Un número de teléfono como `+44 20 7946 0958` parece parcialmente numérico pero no son datos aritméticos. Los valores más allá del rango entero seguro de JavaScript pierden precisión si se convierten a un número en absoluto. Esta herramienta deja todos esos como cadenas específicamente porque adivinar mal aquí significa corromper datos silenciosamente de una forma fácil de pasar por alto hasta mucho después.

Un objeto JSON no puede tener dos claves con el mismo nombre — la segunda encontrada simplemente sobrescribe la primera, descartando silenciosamente el valor de toda una columna sin ningún error levantado en ningún sitio. Las exportaciones de hojas de cálculo producen encabezados duplicados con más frecuencia de lo que parece probable: un informe con dos columnas "Total" con alcances distintos, o una exportación fusionada de dos fuentes que resultan usar ambas "Nombre". Detectar duplicados y renombrar la segunda aparición a `name_2` preserva los datos de cada columna en lugar de perder silenciosamente cualquiera que resultara aparecer primero en el objeto de fila. Los encabezados en blanco reciben el mismo tratamiento por la misma razón, ya que JSON no tiene forma de representar una clave que sea simplemente una cadena vacía como un campo significativo y direccionable.