L'esportazione JSON conserva tre cose per cui il CSV non ha colonna
Pubblicato il 09/09/2026 · 3 min di lettura · Strumenti per file
Daniel Okonkwo — Sviluppatore front-end e redattore Tech presso OneKitly
Performance web · Formati di file
Verificato su 3 fonti
Entrambe le esportazioni leggono lo stesso .ics con lo stesso analizzatore, poi divergono su ciò che sanno portare. Il CSV scrive otto colonne fisse — oggetto, inizio, fine, luogo, descrizione, organizzatore, stato, uid — perché un foglio di calcolo è un rettangolo e ogni evento deve riempire lo stesso. Il JSON scrive ogni evento come oggetto: un campo che solo alcuni eventi hanno compare semplicemente su quelli. In pratica tre cose sopravvivono al JSON e non al CSV: tzid, il fuso nominato in cui un inizio è stato scritto; allDay, il marcatore che dice che una data è una giornata intera e non un istante; e rrule, la regola di ricorrenza. Una riunione settimanale esportata in JSON torna con "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" allegato, e una voce di Natale con "allDay": true. Nessuno dei due ha dove andare in una tabella. Prendi il CSV per leggere e ordinare; prendi il JSON quando lo consumerà uno script, una routine d'importazione o un altro calendario.
Stesso file, stesso analizzatore, due uscite. Il foglio di calcolo riceve otto colonne; il JSON riceve in più il fuso nominato, l'indicatore di giornata intera e la regola di ricorrenza.
Un rettangolo contro una forma
Un CSV deve fissare le sue colonne prima di scrivere la prima riga, e tutte le successive hanno esattamente quelle. È una forza quando vuoi ordinare per data d'inizio o contare gli eventi per luogo — un foglio di calcolo lo fa all'istante, un nido di oggetti no. Diventa debolezza appena i dati sono irregolari, e i dati di calendario lo sono per natura: quasi nessun evento ha ricorrenza, qualcuno sì; quasi tutti hanno un fuso, quelli di giornata intera no.
C'è una seconda differenza, più discreta, da conoscere quando uno script legge l'uscita. Nel CSV un campo vuoto è una cella vuota sempre presente; nel JSON un campo facoltativo senza valore può mancare del tutto dall'oggetto. Scrivi il tuo lettore in modo che una chiave assente e una stringa vuota siano trattate allo stesso modo e nessuna delle due esportazioni ti sorprenderà.
| Proprietà | Nel CSV | Nel JSON |
|---|---|---|
| Titolo, inizio, fine, uid | Sì, quattro delle otto colonne | Sì |
| Fuso nominato | Nessuna colonna | "tzid": "Europe/Paris" |
| Giornata intera anziché un istante | Nessuna colonna | "allDay": true |
| Regola di ricorrenza | Nessuna colonna | "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" |
| Un campo vuoto | Una cella vuota, sempre presente | Una stringa vuota, o la chiave manca |
Domande frequenti
- Posso ritrasformare il JSON in calendario?
- Non direttamente qui — il lato importazione prende CSV — ma il JSON è la cosa giusta da dare a uno script che scriva .ics per conto proprio, proprio perché conserva ancora il fuso, il marcatore di giornata intera e la regola. Se ti serve solo spostare un calendario senza cambiarlo, non passare da nessuna delle due esportazioni: unire file .ics conserva tutto ed evita la domanda.
- Il JSON dispiega gli eventi ricorrenti?
- No, e non dovrebbe: porta invece la regola, che è strettamente più informazione. Un oggetto con un rrule di FREQ=WEEKLY;COUNT=12 ti dice insieme che ci sono dodici occorrenze e come sono spaziate, mentre dodici oggetti dispiegati ti darebbero le date perdendo il fatto che stanno insieme. Dispiegare è compito di ciò che consuma il file.
- Quale devo archiviare?
- L'.ics stesso. Entrambe le esportazioni sono letture di esso, e una lettura lascia sempre qualcosa fuori — il JSON lascia partecipanti, avvisi e allegati, così come il CSV lascia il fuso e la regola. Conserva l'originale come riferimento e genera l'esportazione che ti serve quando ti serve.
Articoli che potrebbero interessarti
Tutte le guide →Strumenti correlati
Fonti
Hai notato un errore in questo articolo?