Convertir una exportación de una sola línea en algo legible, encontrar la coma que sobra y pasar los registros a una tabla. Los tres pasos más habituales del día a día, con las trampas de los datos anidados y del CSV.
Para que unos datos JSON se puedan leer, pégalos en un formateador y deja que los indente; si son inválidos, ve a la posición que indica el mensaje de error; para llevarlos a una hoja de cálculo, pásalos por un conversor de JSON a CSV. Casi todos los archivos rotos se deben a cuatro causas: una coma después del último elemento, comillas simples, una comilla doble sin escapar o una línea de comentario. Lo habitual es que una exportación llegue como una única línea interminable que no se puede leer y que, pegada en una hoja de cálculo, no sirve de nada. Esta guía recorre por orden el formateo, la validación y la conversión.
Las herramientas son sencillas: el formateador JSON indenta y comprueba la sintaxis, convertir JSON a CSV lleva los registros a una tabla y convertir CSV a JSON hace el camino inverso. Cuando hay datos binarios codificados, codificar y decodificar Base64 los abre, y codificar y decodificar URL vuelve legibles las direcciones. Todas funcionan en tu navegador y lo que pegas no se envía al servidor, algo importante si el archivo contiene datos de clientes o configuraciones.
Indentar no cambia el contenido; solo añade espacios. Aun así, el efecto es enorme: se ve la profundidad de cada estructura anidada, una llave de cierre que falta salta a la vista y deja de ser un misterio a qué objeto pertenece cada campo. El formateador indenta cada nivel con dos espacios. Una línea como {"id":7,"nombre":"Lucía","direccion":{"ciudad":"Lima"}} se convierte en un bloque de cinco líneas en el que cada campo ocupa la suya y el objeto direccion aparece un nivel más adentro.
Lo que va a producción debe seguir compactado, pero cualquier cosa que vayas a revisar merece un formateo previo. Solo hay que vigilar la codificación de caracteres. Un texto con tildes o eñes abierto con la codificación equivocada muestra secuencias raras como “ñ”, y el fallo es del programa que lo abre, no del archivo. Si lo abres como UTF-8, se ve bien.
El orden de los campos dentro de un objeto no tiene ningún significado técnico: el software produce el mismo resultado llegue en el orden que llegue. Para una persona, en cambio, importa mucho. Si vas a leer la salida a ojo, poner los identificadores al principio y los textos largos al final te permite recorrerla mucho más rápido.
La única forma fiable de saber si un archivo es válido es pasarlo por un analizador; decidirlo a ojo engaña, sobre todo con estructuras anidadas. Ante una entrada inválida, el formateador muestra un mensaje con la posición donde falló el análisis. Mirar hacia atrás desde ese punto es mucho más rápido que buscar al azar, porque el error real suele estar justo antes del lugar indicado. Casi todos los errores de sintaxis encajan en unos pocos patrones:
{"a": 1,}, es con diferencia el fallo más común, y en archivos editados a mano casi una costumbre.{'a': 1} no es válido."pantalla de 20\"".Si la posición del mensaje no te ayuda, divide el archivo en dos mitades y comprueba cuál es válida; así encuentras el error de un archivo de cien líneas en unos siete intentos.
Pasar la validación de sintaxis no garantiza que estén los campos que esperas. Un campo numérico puede haber llegado como texto, puede faltar una clave obligatoria o una fecha puede venir en otro formato. Para revisarlo a mano ayuda una lista corta: campos obligatorios, tipos esperados y valores que no pueden quedar vacíos. Si necesitas comparar dos exportaciones, formatea ambas igual y ponlas una junto a otra en comparar textos, que trabaja línea por línea y muestra las líneas cambiadas con su número.
Aquí es donde chocan los dos mundos. Una tabla es plana: filas y columnas. Una estructura JSON es un árbol, y cualquier campo puede contener otro objeto o una lista. El conversor de JSON a CSV resuelve la diferencia con reglas fijas:
| Forma de los datos | Qué hace el conversor | Qué te toca hacer |
|---|---|---|
| Lista de objetos planos | Cada campo es una columna y cada objeto una fila | Nada |
| Objeto anidado | Los subcampos se abren en columnas con punto, como direccion.ciudad | Revisar los nombres de columna |
| Lista dentro de un campo | Se escribe en la celda como texto JSON | Sacarla a otra tabla si necesitas analizarla |
| Objetos con campos distintos | Las columnas son la unión de todos los campos; los huecos quedan vacíos | Interpretar las celdas vacías |
| Un único objeto | Genera una tabla de una sola fila | Revisar el origen si esperabas una lista |
Un ejemplo concreto: la entrada [{"id":7,"nombre":"Lucía","etiquetas":["a","b"],"direccion":{"ciudad":"Lima"}}] se convierte en una tabla con la cabecera id,nombre,etiquetas,direccion.ciudad, y la lista queda en su celda como el texto ["a","b"]. Como ese texto contiene comas y comillas, la celda va entre comillas dobles y las comillas internas se duplican, tal como establece la norma RFC 4180.
En sentido inverso, el conversor sigue la RFC 4180: lee bien los campos entre comillas, el escape "" y los saltos de línea dentro de una celda. El separador se detecta solo; admite coma, punto y coma, tabulador y barra vertical, así que los archivos separados por punto y coma, habituales en muchas hojas de cálculo configuradas en español, se abren sin problemas. La primera fila se toma como cabecera; si un nombre se repite, al segundo se le añade _2. Los valores se mantienen como texto: un código como 007 conserva sus ceros iniciales, pero si necesitas hacer cálculos tendrás que convertir los tipos en tu propio código. Guardar los identificadores y códigos postales como texto desde el principio evita este problema.
Los errores caros en el intercambio de datos no son de sintaxis, sino de nombres. Cuando dos sistemas emiten el mismo dato con claves distintas, la capa que traduce entre ellos se llena de casos especiales hasta que nadie se atreve a tocarla. El remedio es un pequeño diccionario escrito desde el principio: cada campo, su tipo, su unidad y si puede faltar.
Tres reglas de nombres cubren casi todo. Primera: elige un estilo de escritura y mantenlo; ver nombreCliente y nombre_cliente en el mismo archivo indica que pasó por dos manos distintas. Segunda: evita las abreviaturas, porque un campo llamado ttl se convierte en un acertijo en una semana. Tercera: incluye la unidad en el nombre; duracion_segundos en lugar de duracion evita un error de cálculo que costaría una tarde encontrar.
En cuanto a la estructura, el fallo típico es la profundidad innecesaria. Un objeto anidado cinco niveles no parece más ordenado; solo alarga cada fragmento de código que tiene que llegar hasta él y, al pasarlo a CSV, produce columnas ilegibles como a.b.c.d.e. Si llegar a un valor exige más de tres pasos, la estructura probablemente es demasiado profunda. Por último, la ausencia: que un campo falte y que llegue con null son cosas distintas, y los consumidores que las confunden generan errores silenciosos. Decide una vez qué significa cada caso y déjalo por escrito.
Las estructuras de datos no están congeladas: se añaden campos, se renombran y cambian de tipo. El problema nunca es el cambio en sí, sino el cambio que nadie anunció. La regla segura: añadir un campo es libre; eliminarlo o cambiar su significado, no. Si de verdad hay que retirar uno, añade primero el sustituto, publica ambos durante un tiempo y elimina el antiguo solo cuando todos los consumidores se hayan pasado al nuevo.
%C3%B1. El decodificador deja intactas las secuencias de porcentaje mal formadas y no convierte el + en espacio; tenlo en cuenta con los datos de formularios.=, suelen ser Base64. El decodificador acepta también la variante segura para URL (con - y _, sin relleno) y el formato MIME con saltos de línea, y te avisa si el contenido decodificado no es texto.Casi siempre es un problema de codificación. Aunque el archivo se haya guardado bien, si el programa que lo abre supone otra codificación, las letras acentuadas se desfiguran. Revisa la codificación del lugar donde lo abriste antes de modificar el archivo.
El formato no lo permite. La solución habitual es añadir la explicación como un campo más, con un nombre como _nota, que el programa ignore. No es elegante, pero funciona y mantiene el archivo válido.
Abrir cientos de megabytes en el navegador no es razonable. En esos casos conviene reorganizar la exportación para que cada línea contenga un registro independiente; así el procesamiento y la depuración son mucho más sencillos.
Las hojas de cálculo adivinan el separador, el signo decimal y la codificación según su configuración regional. El conversor genera el CSV separado por comas, así que un programa configurado para esperar punto y coma puede meter cada fila entera en una sola columna. Usa el asistente de importación y elige a mano la coma como separador y UTF-8 como codificación.
Cuándo conviene cada formato lo explicamos en CSV vs JSON: diferencias, y la lógica de los campos codificados en qué es Base64. Para las claves e identificadores que acaban en archivos de configuración, consulta contraseñas seguras e identificadores; si los datos van a terminar en un enlace o en una tarjeta para escanear, la guía de uso de códigos QR te explica ese camino.
