Was die Prüfung bei einer ICS-Datei untersucht
Eine ICS-Datei ist reiner Text im Format iCalendar, beschrieben in RFC 5545. Dieses Werkzeug liest die Datei zeilenweise und prüft zuerst das Gerüst: Sie muss mit BEGIN:VCALENDAR beginnen und mit END:VCALENDAR enden (Abschnitt 3.4), VERSION und PRODID müssen vorkommen und dürfen nicht doppelt stehen (3.7.4 und 3.7.3). Jede Komponente braucht ihre eigenen Pflichtfelder. Ein Termin (VEVENT) verlangt UID und DTSTAMP, außerdem DTSTART, solange der Kalender keine METHOD-Angabe trägt (3.6.1).
Danach folgen die Beziehungen zwischen den Feldern. DTEND und DURATION dürfen nicht zusammen stehen, das Ende darf nicht vor dem Beginn liegen (3.8.2.2), und eine UID darf nicht in zwei Terminen vorkommen, weil Kalenderprogramme sonst einen Eintrag mit dem anderen überschreiben. Jede Meldung nennt die Regel mit Abschnitt und die Zeilennummer, damit Sie die Stelle im Texteditor finden.
Datumsangaben, Zeitzonen und VTIMEZONE
Das Format kennt drei Schreibweisen für Zeitpunkte (3.3.5): lokale Zeit wie 20261110T140000, UTC mit angehängtem Z und lokale Zeit mit Zeitzonenkennung (TZID). Ein reines Datum wie 20261112 ist ein Ganztagswert (3.3.4) und braucht in der Regel VALUE=DATE. Die Prüfung meldet falsche Formate, ungültige Kalendertage und gemischte Werttypen, etwa einen Beginn mit Uhrzeit und ein Ende als Datum.
Zeigt ein TZID auf eine Zeitzone, die im Kalender nicht als VTIMEZONE definiert ist (3.6.5), kann ein Programm die Uhrzeit nicht sicher deuten. Das Werkzeug meldet das, ändert aber nichts, denn welche Zeitzonenregeln gelten sollen, kann es nicht erraten. Ein Z zusammen mit einem TZID ist nach 3.2.19 nicht zulässig. Zeitangaben ohne Z und ohne TZID sind „schwebend“: Sie gelten in jeder Zeitzone zur gleichen Uhrzeit. Das ist erlaubt, wird aber als Hinweis gezeigt.
Zeilenenden, Faltung und Zeichensatz
Zeilen enden nach 3.1 mit CRLF. Zeilen sollen höchstens 75 Oktette lang sein; längere werden gefaltet, indem man nach einem Zeilenumbruch ein Leerzeichen oder einen Tabulator voranstellt. Gefaltet wird in Oktetten, ein mehrbytiges Zeichen wie ein Umlaut darf dabei nicht zerschnitten werden. Die Prüfung meldet Zeilen mit nur LF (bei geladenen Dateien; bei eingefügtem Text lässt sich das Zeilenende nicht prüfen), zu lange Zeilen und Faltungsfolgen ohne vorherige Zeile.
Als Zeichensatz gilt UTF-8 (3.1.4). Ein Byte Order Mark am Dateianfang kennt der RFC nicht; manche Programme verschlucken sich daran, weshalb das Werkzeug es als Hinweis meldet und beim Reparieren entfernt. Dass das BOM unerwünscht ist, folgt aus dem Format und steht nicht ausdrücklich im RFC. Enthält eine Datei Bytes, die kein gültiges UTF-8 sind, liest das Werkzeug sie als Windows-1252. Das ist eine Annahme, die für ältere deutsche Exporte meist zutrifft.
Was automatisch repariert wird und was nicht
Repariert wird nur, was eindeutig ist und keine vorhandenen Angaben ändert: das BOM entfernen, eine UTF-16- oder Windows-1252-Datei nach UTF-8 umwandeln, Zeilenenden auf CRLF setzen, leere Zeilen löschen, lange Zeilen korrekt falten, eine fehlende VERSION:2.0 ergänzen, eine fehlende PRODID eintragen, eine fehlende UID neu erzeugen und einen fehlenden DTSTAMP mit der aktuellen Zeit ergänzen. Die erzeugte PRODID und UID tragen den Namen dieses Werkzeugs, damit sie als ergänzt erkennbar bleiben. Jede Änderung steht im Reparaturprotokoll.
Nicht repariert werden Fälle, in denen mehrere Lösungen denkbar sind: ein Ende vor dem Beginn (welcher Wert ist falsch?), DTEND und DURATION gleichzeitig, ein fehlender Beginn, eine TZID ohne Zeitzonendefinition, falsch maskierte Texte und fehlende END-Zeilen. Diese Fälle erscheinen nur in der Befundliste. Die Originaldatei bleibt unverändert, Sie laden die reparierte Fassung als neue Datei herunter.
So lesen Sie das Ergebnis
Ein Fehler verletzt eine Pflicht des RFC, die Datei kann deshalb von strengen Programmen abgelehnt werden. Eine Warnung beschreibt etwas, das der RFC zwar zulässt, das aber häufig zu falschen Terminen führt, zum Beispiel eine Zeitangabe ohne Zeitzone. Ein Hinweis ist eine Beobachtung ohne Folgen, etwa schwebende Zeit. Unter den Befunden zeigt die Terminvorschau Titel, Beginn und Ende der gefundenen Einträge; so sehen Sie, ob die Uhrzeiten so gelesen werden, wie Sie es erwarten.
Grenzen der Prüfung
Das Werkzeug prüft Form und Beziehungen der Felder, nicht den Sinn der Termine. Wiederholungsregeln (RRULE) werden nicht ausgewertet; die Vorschau zeigt nur den ersten Beginn. Die Zeitzonendefinitionen in einer VTIMEZONE werden auf ihre Pflichtbestandteile geprüft, nicht gegen die Zeitzonendatenbank. Außerdem gilt: Outlook, Google Kalender und Apple Kalender sind in Einzelheiten strenger oder nachsichtiger als der RFC. Ein sauberer Befund ersetzt deshalb den Probeimport nicht.
Weiterarbeiten mit der Kalenderdatei
Wenn Sie aus einem einzelnen Termin einen scanbaren Code machen möchten, hilft der Kalender-Termin als QR-Code. Dienstpläne aus einer Tabelle verwandelt Dienstplan in Kalender in eine ICS-Datei. Für Kontaktdateien gibt es das Gegenstück VCF-Datei prüfen.