Der JSON-Export behält drei Dinge, für die das CSV keine Spalte hat
Veröffentlicht am 9.9.2026 · 3 Min. Lesezeit · Datei-Tools
Daniel Okonkwo — Front-end-Entwickler und Tech-Redakteur bei OneKitly
Web-Performance · Dateiformate
Anhand von 3 Quellen geprüft
Beide Exporte lesen dieselbe .ics mit demselben Parser und gehen dann darin auseinander, was sie tragen können. Das CSV schreibt acht feste Spalten — Betreff, Beginn, Ende, Ort, Beschreibung, Organisator, Status, UID —, weil eine Tabelle ein Rechteck ist und jeder Termin dasselbe füllen muss. Das JSON schreibt jeden Termin als Objekt: Ein Feld, das nur manche Termine haben, erscheint eben bei diesen. In der Praxis überleben drei Dinge das JSON und nicht das CSV: tzid, die benannte Zeitzone, in der ein Beginn geschrieben wurde; allDay, der Marker, der sagt, dass ein Datum ein ganzer Tag und kein Zeitpunkt ist; und rrule, die Wiederholungsregel. Eine wöchentliche Besprechung kommt im JSON mit "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" zurück und ein Weihnachtseintrag mit "allDay": true. Für beides gibt es in einer Tabelle keinen Platz. Nimm das CSV zum Lesen und Sortieren; nimm das JSON, wenn ein Skript, eine Importroutine oder ein anderer Kalender es verarbeiten wird.
Dieselbe Datei, derselbe Parser, zwei Ausgaben. Die Tabelle bekommt acht Spalten; das JSON bekommt zusätzlich die benannte Zeitzone, den Ganztagsmarker und die Wiederholungsregel.
Ein Rechteck gegen eine Gestalt
Ein CSV muss seine Spalten festlegen, bevor es die erste Zeile schreibt, und alle folgenden haben genau diese. Das ist eine Stärke, wenn du nach Beginn sortieren oder Termine je Ort zählen willst — eine Tabelle tut das sofort, ein Geflecht aus Objekten nicht. Zur Schwäche wird es, sobald die Daten unregelmäßig sind, und Kalenderdaten sind es von Natur aus: Die meisten Termine haben keine Wiederholung, einige schon; die meisten haben eine Zone, Ganztagseinträge keine.
Es gibt einen zweiten, kleineren Unterschied, den man kennen sollte, wenn ein Skript die Ausgabe liest. Im CSV ist ein leeres Feld eine immer vorhandene leere Zelle; im JSON kann ein optionales Feld ohne Wert im Objekt ganz fehlen. Schreibe deinen Leser so, dass ein fehlender Schlüssel und ein leerer String gleich behandelt werden, und keiner der beiden Exporte wird dich überraschen.
| Eigenschaft | Im CSV | Im JSON |
|---|---|---|
| Titel, Beginn, Ende, UID | Ja, vier der acht Spalten | Ja |
| Benannte Zeitzone | Keine Spalte | "tzid": "Europe/Paris" |
| Ganzer Tag statt Zeitpunkt | Keine Spalte | "allDay": true |
| Wiederholungsregel | Keine Spalte | "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" |
| Ein leeres Feld | Eine leere Zelle, immer vorhanden | Ein leerer String, oder der Schlüssel fehlt |
Häufige Fragen
- Kann ich das JSON wieder in einen Kalender verwandeln?
- Hier nicht direkt — die Importseite nimmt CSV —, aber das JSON ist genau das Richtige für ein Skript, das selbst .ics schreibt, eben weil es Zone, Ganztagsmarker und Regel noch trägt. Willst du einen Kalender nur unverändert bewegen, geh durch keinen der beiden Exporte: .ics-Dateien zusammenzuführen behält alles und umgeht die Frage.
- Faltet das JSON die Serientermine auf?
- Nein, und das soll es auch nicht: Es trägt stattdessen die Regel, was strikt mehr Information ist. Ein Objekt mit einem rrule von FREQ=WEEKLY;COUNT=12 sagt dir zugleich, dass es zwölf Termine gibt und wie sie liegen, während zwölf aufgefaltete Objekte dir die Daten gäben und den Zusammenhang verlören. Das Auffalten ist Sache dessen, was die Datei verarbeitet.
- Welches soll ich archivieren?
- Die .ics selbst. Beide Exporte sind Lesarten davon, und eine Lesart lässt immer etwas weg — das JSON Teilnehmer, Erinnerungen und Anhänge, so wie das CSV Zone und Regel. Behalte das Original als Beleg und erzeuge den Export, den du brauchst, wenn du ihn brauchst.
Artikel, die dich interessieren könnten
Alle Ratgeber →Ähnliche Tools
Quellen
Hast du einen Fehler in diesem Artikel entdeckt?