ICSファイルとは

ICS はプレーンテキスト形式です。どのエディターでも開けます。 プログラム間のデータ受け渡しのために使われます。

拡張子は .ics、正式名称は iCalendar です。ただしどちらも、そのファイルが中に何を持てるかほどには多くを語りません。このページの残りは、その中身についての話です。

1998 年までさかのぼります。 仕様は RFC 5545 です。

これだけ長く読まれ続けてきた形式なら、10 年後に取り出したいものを預けても大丈夫です。

仕様書がそのまま公開されているので、中身を推し量るのではなく文書を読んで実装できます。この形式が数多くのプログラムに載っているのはそのためであり、20 年前に書かれたファイルが今も開けるのもそのためです。ただし「仕様が公開されている」ことと「使用料が要らない」ことは別の話です。中でコーデックを包んでいる形式では、特許のライセンスは仕様書が答えていない別の問題として残ります。

ICS ファイルは中身をそのまま保存します。保存し直しても何も変わらないので、開いて、直して、また保存する——それを何度繰り返しても劣化は積み上がりません。これが、渡すための形式ではなく作業のための形式である理由です。

Google Calendar、Apple Calendar、Microsoft Outlookが読めますし、同じ種類のプログラムならたいてい読めます。

ファイルが開かないとき、形式が悪いことはめったにありません。たいていはプログラムのほうが形式より古いのです。もっと古い形式に変換してしまうのが確実な逃げ道で、このサイトの残りの部分はそのためにあります。

これを読めるブラウザーはありません。

これを変換するいちばんよくある理由がこれです。形式が悪いのではありません。ファイルを見せたい場所が、それを読めないというだけのことです。

ICS は、開いて手を入れるために作られています。作業が続いているあいだはこの形式でファイルを持ち、完成したものが必要になるたびに、ここから書き出してください。

ICS ファイルは、送られてきた一つの予定か、購読しているカレンダーのどちらかで、この形式にまつわるほとんどの問題は、この二つを取り違えることから始まります。

前者はメールに添付された招待状です。一つの予定、あるいは小さな一連の予定を表していて、一度開いて取り込むためのものです。後者はウェブ上のアドレスにあるフィードで、カレンダーアプリが繰り返し取得しに行きます。時間割、試合日程、シフト表、祝日カレンダーなどです。ファイルの構造としてはどちらも同じですが、使われ方はまるで違います。購読すべきものをダウンロードして取り込んでしまうと、二度と更新されない凍結されたコピーになってしまい、これが一番よくある間違いです。

プレーンテキストで、いかにもそれらしい古めかしい構造です。一行に一つのプロパティを、すべて大文字で書き、75 文字で折り返し、続く行の先頭にスペース一つを置くという継続の慣習があります。各予定は BEGIN と END の間に置かれ、開始時刻、終了時刻、概要、たいていは説明と場所、そして一意の識別子を持ちます。

この識別子が、思わぬ振る舞いをする部分です。カレンダーは、更新が新しい予定なのか既存の予定への上書きなのかを、この識別子で判断します。同じ識別子で招待状を送り直せば、元の予定が更新されます。新しい識別子で送ると、全員のカレンダーに予定が二つになってしまいます。

予定の時刻は三通りの書き方ができ、それぞれ振る舞いが違います。タイムゾーンのないローカル時刻は「どこにいても十時」という意味で、誕生日には正しく、会議には不適切です。末尾に Z を付けた UTC 時刻は、固定された瞬間を表し、どのカレンダーも読む側の地域に合わせて変換します。名前付きのタイムゾーンを持つ時刻は、タイムゾーンの定義そのものをファイルの中に持っていて、夏時間の切り替えをまたいでも変換が正しく保たれます。

ある参加者だけ一時間ずれて表示される予定は、たいていこのケースです。全員が一つの国にいると想定したシステムが、ローカル時刻として予定を書き出したのです。時計の切り替え前までは正しかった予定も、同じ問題が一段深いところにあります。名前付きのタイムゾーンを使うべきところに、固定のオフセットが記録されているのです。

繰り返しは、すべての回を書き出すのではなくルールとして記述されます。第二火曜日ごと、月の最後の金曜日、ある日まで平日ごと、といった具合です。コンパクトで正確なので、一年分の朝会が数百バイトで済みます。

複雑になるのは例外の扱いです。キャンセルされた回や、別の日に移動した一回の会議は、どちらも一連の予定に対する修正として記録され、それをどこまで正確に実装しているかはアプリによって異なります。繰り返し会議の一回だけを動かしたつもりが、他人のカレンダーではすべての回が動いてしまうことがあるのはこのためです。ルールは正しく引き継がれても、例外の情報が引き継がれなかったのです。

一回きりのファイルであれば、三つとも同じ動作をします。予定を一度だけコピーする取り込みです。Google カレンダーでは設定のインポートとエクスポート、Outlook ではファイル、開く/エクスポート、Mac ではファイル、読み込む、から行います。予定を受け取るカレンダーは確定前に選んでください。あとから分けるのは面倒です。

フィードの場合は、ダウンロードしたファイルではなく、購読の機能にアドレスを渡してください。Google では「URL から」、Apple では「カレンダー購読」、Outlook では「ウェブから購読」と呼ばれています。カレンダーはその後、自分のスケジュールで再取得します。Google と Outlook は時間単位でしか取得間隔を測らず設定もできませんが、Apple は購読の自動更新メニューで五分まで短縮できます。元データの変更がすぐに反映されないのは普通のことで、故障ではありません。

何かを予約するシステム — チケット販売、予約フォーム、講座の登録 — は、いずれ ICS を添付して顧客が自分のカレンダーに入れられるようにする必要が出てきます。うまく機能するものと、問い合わせを生むものを分ける要点は三つです。

裸のローカル時刻ではなく名前付きのタイムゾーンを使うか、固定の瞬間なら UTC を使うことです。確認、リマインダー、変更通知のすべてで一意の識別子を変えずに保つことで、更新が既存の予定に反映されるようにします。そして正しいメディアタイプでファイルを添付することです。汎用のバイナリ添付として送ると、メールソフトは招待として承認する画面ではなく、単なるダウンロード可能なファイルとして表示してしまいます。

テキストなのでどんなエディターでも開け、一つの予定だけを確認したいときには、これがカレンダーに実際に何が伝わっているかを見る一番速い方法です。行の折り返しの慣習だけは尊重してください。継続行の先頭にはスペースが一つ必要で、それを削除するとプロパティの内容が静かに変わってしまいます。

間違った日付、タイトルの誤字、共有する前に匿名化しておくべき概要といった、ちょっとした修正には手編集も現実的です。構造に関わる部分、特に繰り返しのルールは、カレンダーアプリに書かせてください。ルールの構文は厳密で、間違えると一年間にわたって間違った日に予定が表示され続け、誰かが会議に来なくなるまで気付かれないことがあります。