La exportación JSON conserva tres cosas para las que el CSV no tiene columna
Publicado el 9/9/2026 · 3 min de lectura · Herramientas de archivos
Daniel Okonkwo — Desarrollador front-end y redactor de Tecnología en OneKitly
Rendimiento web · Formatos de archivo
Verificado con 3 fuentes
Ambas exportaciones leen el mismo .ics con el mismo analizador y luego divergen en lo que pueden llevar. El CSV escribe ocho columnas fijas — resumen, inicio, fin, lugar, descripción, organizador, estado, uid — porque una hoja de cálculo es un rectángulo y cada evento tiene que rellenar el mismo. El JSON escribe cada evento como un objeto: un campo que solo algunos eventos tienen aparece simplemente en esos. En la práctica, tres cosas sobreviven al JSON y no al CSV: tzid, la zona con nombre en la que se escribió un inicio; allDay, el marcador que dice que una fecha es un día entero y no un instante; y rrule, la regla de recurrencia. Una reunión semanal exportada a JSON vuelve con "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" adjunto, y una entrada de Navidad con "allDay": true. Ninguno tiene dónde ir en una tabla. Coge el CSV para leer y ordenar; coge el JSON cuando lo vaya a consumir un script, una rutina de importación u otro calendario.
Mismo archivo, mismo analizador, dos salidas. La hoja de cálculo recibe ocho columnas; el JSON recibe además la zona con nombre, el indicador de día entero y la regla de recurrencia.
Un rectángulo contra una forma
Un CSV tiene que fijar sus columnas antes de escribir su primera fila, y todas las siguientes tienen exactamente esas. Es una fuerza cuando quieres ordenar por fecha de inicio o contar eventos por lugar — una hoja de cálculo hace eso al instante y un nido de objetos no. Se vuelve debilidad en cuanto los datos son irregulares, y los datos de calendario lo son por naturaleza: casi ningún evento tiene recurrencia, unos pocos sí; casi todos tienen zona, los de día entero no.
Hay una segunda diferencia, más discreta, que conviene conocer cuando un script lee la salida. En el CSV un campo vacío es una celda vacía siempre presente; en el JSON un campo opcional sin valor puede faltar del objeto por completo. Escribe tu lector de modo que una clave ausente y una cadena vacía se traten igual y ninguna de las dos exportaciones te sorprenderá.
| Propiedad | En el CSV | En el JSON |
|---|---|---|
| Título, inicio, fin, uid | Sí, cuatro de las ocho columnas | Sí |
| Zona con nombre | Sin columna | "tzid": "Europe/Paris" |
| Día entero en vez de un instante | Sin columna | "allDay": true |
| Regla de recurrencia | Sin columna | "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" |
| Un campo vacío | Una celda vacía, siempre presente | Una cadena vacía, o la clave falta |
Preguntas frecuentes
- ¿Puedo volver a convertir el JSON en calendario?
- No directamente aquí — el lado de importación toma CSV — pero el JSON es lo indicado para alimentar un script que escriba .ics por su cuenta, precisamente porque conserva la zona, el indicador de día entero y la regla. Si solo quieres mover un calendario sin cambiarlo, no pases por ninguna de las dos exportaciones: fusionar archivos .ics lo conserva todo y evita la cuestión.
- ¿El JSON despliega los eventos recurrentes?
- No, y no debería: lleva la regla en su lugar, que es estrictamente más información. Un objeto con un rrule de FREQ=WEEKLY;COUNT=12 te dice a la vez que hay doce ocurrencias y cómo se espacian, mientras que doce objetos desplegados te darían las fechas perdiendo el hecho de que van juntas. Desplegar es tarea de lo que consuma el archivo.
- ¿Cuál debo archivar?
- El .ics en sí. Ambas exportaciones son lecturas de él, y una lectura siempre deja algo fuera — el JSON deja asistentes, alarmas y adjuntos, igual que el CSV deja la zona y la regla. Conserva el original como referencia y genera la exportación que necesites cuando la necesites.
Artículos que podrían interesarte
Todas las guías →Herramientas relacionadas
Fuentes
¿Has detectado un error en este artículo?