JSON a CSV

JSON está construido para representar datos arbitrariamente anidados en forma de árbol — objetos dentro de objetos, arrays dentro de objetos, valores de tipos genuinamente distintos uno junto a otro — mientras que CSV solo puede representar una tabla plana y uniforme: filas y columnas, cada fila con el mismo conjunto de columnas, cada celda un solo valor plano. Convertir de la primera forma a la segunda necesariamente significa tomar decisiones sobre cómo aplanar algo que no encaja naturalmente en filas y columnas, que es donde vive la mayor parte de la complejidad real de este tipo de conversión — no en leer la sintaxis JSON en sí, que es directa, sino en decidir qué debería siquiera significar una fila de hoja de cálculo para datos que nunca fueron tabulares para empezar.

Un objeto anidado como `{"user": {"name": "Ada", "id": 42}}` no tiene una sola columna obvia en la que convertirse en una tabla plana, así que se aplana en dos columnas separadas — `user.name` y `user.id` — con la notación de punto preservando exactamente de dónde vino cada valor en la estructura original. Esta es una convención ampliamente reconocida específicamente porque es reversible: una columna llamada `user.name` describe sin ambigüedad una ruta de vuelta a una estructura anidada, lo cual importa si el CSV alguna vez necesita convertirse de vuelta a JSON o importarse en un sistema que entiende rutas con puntos como campos anidados.

Los arrays anidados se manejan de forma distinta, y deliberadamente así: en lugar de explotar un array en filas adicionales — lo que cambiaría cuántas filas tiene la tabla dependiendo de cuántos elementos anidados resulten estar dentro de un registro, un efecto secundario genuinamente sorprendente y a menudo no deseado — un valor de array se serializa como texto JSON dentro de una sola celda. El número de filas permanece predecible y coincide exactamente con el número de registros de entrada, que es casi siempre lo que realmente quiere alguien que convierte a una hoja de cálculo, a costa de que esa celda necesite un análisis adicional si su contenido se necesita individualmente.

Las respuestas de API reales y el JSON ensamblado a mano frecuentemente contienen registros donde no todos los objetos tienen claves idénticas — un campo opcional presente en algunos registros y ausente en otros, o un esquema que evolucionó con el tiempo así que los registros más antiguos y más nuevos difieren ligeramente. CSV no puede representar esa variación directamente, ya que cada fila necesita alinearse al mismo conjunto fijo de columnas; un programa que lee un archivo CSV no tiene forma de saber que a una fila le "falta" una columna a menos que cada fila tenga explícitamente una celda para ella. La solución es calcular la unión de cada clave vista en cada registro, en el orden en que se encontró cada clave por primera vez, y rellenar una celda vacía para cualquier registro al que le falte un campo dado — así la forma se mantiene consistente en todo el archivo sin descartar silenciosamente las columnas de ningún registro ni desalinear valores en la columna equivocada.