Convertir NDJSON a CSV

Es la aritmética más sencilla de cualquier origen de este sitio. Un archivo NDJSON guarda un registro completo por línea, así que el número de filas es el número de líneas: lo que te dice `wc -l`, o el contador de cualquier editor capaz de abrirlo. Ningún dato puede partir una línea, porque un salto dentro de una cadena JSON va escapado.

Las líneas en blanco se saltan, incluida la última que casi todos los programas dejan al final del archivo. De modo que si el origen tiene 412.000 líneas y el CSV trae menos filas, el problema estaba en el archivo y no en la conversión. Con un JSON envuelto en un array esa comprobación no existe.

Cada línea es independiente y nada obliga a la segunda a llevar las claves de la primera. Un flujo de registro que emite varios tipos de suceso —una petición, un error, una tarea terminada— mete todos en el mismo archivo con campos distintos, lo cual es razonable como flujo y desagradable como tabla.

La conversión recorre el archivo completo, va anotando cada clave nueva que ve y le da una columna, en el orden en que aparecieron por primera vez. Ninguna se pierde por asomar tarde. El precio es la anchura: cuarenta columnas de las que cada fila usa ocho. Cuando salga así, lo útil es filtrar el origen a un solo tipo de suceso antes de convertir, no ensanchar la hoja después.

Si una línea no es JSON válido, la conversión no sigue adelante: para y nombra el número de línea. Eso es deliberado y es la conducta que conviene querer, aunque de entrada parezca menos cómoda que saltarse el renglón.

Una línea rota en un registro casi nunca significa un carácter suelto. Significa una escritura truncada —un proceso muerto a mitad de vaciado, un archivo rotado por el medio, una descarga incompleta— y todo lo que viene después es sospechoso. Saltarla en silencio produciría una tabla a la que le faltan filas sin nada que lo indique. Con el número delante, recortar la cola es una orden y sabes exactamente qué has perdido.

El registro estructurado anida casi siempre: un objeto de petición con su método y su ruta, un usuario con su identificador, un bloque de contexto con la traza. Todo eso se aplana en una columna por valor final, nombrada con el camino completo y puntos entre los tramos: `peticion.metodo`, `usuario.id`.

Uno o dos niveles dan una tabla con la que trabaja cualquiera. Más abajo la cosa se ensancha deprisa, y una línea que arrastre una carga entera serializada producirá una columna por cada campo de dentro. Cuando eso pase, la respuesta honesta es que lo interesante del archivo es una rama, y extraerla antes de convertir da una tabla mucho mejor que aplanarlo todo y esconder columnas después.

Un registro que lleve una lista —etiquetas, marcos de una traza de error, reglas aplicadas— se aplana en columnas numeradas: `etiquetas.0`, `etiquetas.1`, `etiquetas.2`. No se pierde ningún valor, y la tabla acaba con tantas columnas como elementos tuviera la lista más larga del archivo, la mayoría vacías.

Para analizar casi nunca es lo que quieres. Si la lista es accesoria, unirla en una sola cadena antes de convertir da una columna legible. Si la lista es justo lo que vas a contar, lo que necesitas es una fila por elemento, y eso significa expandir el archivo en el origen. Cualquiera de las dos cosas es una expresión de `jq` y las dos ganan a ordenar una hoja por `etiquetas.3`.

El archivo que sale de aquí separa con coma, siempre y sin opción. Windows configurado en español —y también en portugués, en francés o en alemán— trae el punto y coma como separador de listas, porque la coma ya está ocupada haciendo de separador decimal. Excel obedece a esa configuración regional, no al archivo.

El resultado es el clásico: doble clic en el CSV y aparece todo el contenido metido en la columna A. No está roto. Abre Excel primero y usa Datos, luego «Obtener datos» o «Desde un archivo de texto/CSV», y elige la coma como delimitador en el asistente. Si vas a repetir la operación muchas veces, convierte el mismo NDJSON a TSV en lugar de a CSV: el tabulador no colisiona con ninguna configuración regional y es el atajo que se usa poco y ahorra más.

Un CSV no tiene tipos: todo es texto y quien lo abre decide qué es cada cosa. Los valores se escriben con fidelidad —un número con sus cifras, un booleano como `true` o `false`, un nulo como celda vacía— y a partir de ahí manda el programa que lo lee.

Excel decide mal y de forma previsible, y en un archivo español hay tres víctimas habituales. Los códigos postales que empiezan por cero: 01001 de Vitoria y 08001 de Barcelona se quedan en 1001 y 8001. Cualquier cosa con forma de fecha se convierte en fecha. Y un identificador numérico largo —una referencia de pedido, un número de expediente— pierde las últimas cifras al pasar a coma flotante. El remedio es importar en lugar de abrir, marcando esas columnas como texto, o convertir a XLSX, donde los tipos van declarados dentro del archivo y no se adivina nada.

Los valores que contienen una coma, una comilla doble o un salto de línea se envuelven entre comillas dobles y las comillas interiores se duplican, que es la convención de la RFC 4180 y la que lee correctamente cualquier importador que merezca la pena. El resto se escribe tal cual, de modo que el archivo sigue siendo legible con un editor.

Los datos de registro tiran de ese mecanismo más que ningún otro: los agentes de usuario, las rutas con cadena de consulta, los mensajes de error y las trazas están llenos de comas y comillas. Si el destino no es una hoja de cálculo sino una tubería de intérprete de órdenes —`awk`, `cut`, un `split` ingenuo por comas—, el entrecomillado es exactamente lo que esas herramientas no implementan, y convertir a TSV evita la discusión entera.

El análisis es rápido y el techo es la memoria, porque el archivo se lee entero y el juego completo de columnas queda decidido antes de poder escribir la primera fila. El límite gratuito son 100 MB por archivo; decenas de megabytes se convierten sin drama y varios cientos es donde una pestaña empieza a sufrir.

Por encima de eso el formato de origen juega a tu favor. Un NDJSON se parte sin riesgo en cualquier salto de línea, así que `split -l 500000` produce archivos válidos y convertir un registro enorme por trozos es un procedimiento legítimo y no un apaño. Para un archivo de varios gigabytes el instrumento correcto es una herramienta de flujo y esta página no lo es.

La tabla es una vista, no un sustituto. Ha perdido los tipos, ha aplanado la estructura y ha conciliado registros que nunca estuvieron obligados a coincidir, y nada de eso se recupera desde el CSV.

El archivo original además es mejor en lo que vas a querer después: se le añaden líneas sin reescribirlo, se filtra con `jq` sin cargarlo entero y se puede volver a convertir extrayendo otra rama cuando cambie la pregunta. Guarda los dos y borra la tabla, no la fuente.

La conversión es JavaScript corriente ejecutándose en esta pestaña. Ninguna petición lleva el archivo a ninguna parte, no hay cuenta ni cupo diario, y puedes comprobarlo abriendo el panel de red del navegador mientras conviertes algo.

En este par no es un detalle de cortesía. Un registro de producción lleva direcciones IP, identificadores de sesión, rutas de petición, agentes de usuario y, más veces de las que nadie admite, una cadena de consulta con un testigo dentro. Bajo el RGPD eso son datos personales, y subirlos a un conversor ajeno es una cesión que alguien tendría que haber documentado. Aquí no hay nada que subir. Se pueden soltar hasta cien archivos de una vez y descargarlos juntos en un ZIP.