piapia123
ja

ICS カレンダー読み取り

変換

処理はすべてブラウザ内で完結します。データは送信されません

入力
ファイルをここにドロップすると読み込めます
出力

`.ics` はカレンダーの共通交換形式(RFC 5545)で、Google カレンダー・Outlook・Apple カレンダーが書き出すものです。問題は開けないことではなく読みにくいことです:予定は `BEGIN:VEVENT` ブロックで、知りたいこと(「来週木曜の午後 3 時、毎週、年末まで」)は `DTSTART`・`RRULE`・`UNTIL` に散らばり、間に何十行もの `VTIMEZONE` 定義が挟まります。ここではそれを表として読み取ります。 ⚠️ 既定では換算を一切しません:`TZID` 付きの時刻はファイルに書かれているその鐘時を表示し、ゾーン名を添えます。これは生の事実で、換算はそこから導かれるもの —— 両方を別々に並べるからこそ換算を検算できるのです。 換算したい場合は、オプションに IANA のゾーン名を入れてください(`Asia/Tokyo`・`America/New_York`・`UTC`)。各予定に「その瞬間が選んだゾーンでは何時か」という行が増え、その日の UTC オフセットも表示されます。 ⚠️ これは固定オフセットを引くことではありません:オフセットはプラットフォームのタイムゾーンデータベースから取るため、その予定の日付時点の値になります(ニューヨークは 1 月が −05:00、7 月が −04:00)。過去の規則変更も反映されます。境界の 2 ケースは黙って処理せず明示します:夏時間で飛ばされた鐘時はそのゾーンに存在せず(近い時刻にずらしません)、戻しで重複する鐘時は 2 つの瞬間に対応します(早いほうを使い、その旨を注記します)。 ⚠️ また、`Z` もゾーン名もない時刻はフローティング時刻で、どこで見ても同じ壁時計の時刻という意味です。これは「特定の瞬間」とは別のことで、ここではそのように表示します。該当する場合は結果に説明を添えます。すべてブラウザー内で完結します。

機能

  • 予定ごとに:概要、開始と終了、所要時間、場所、説明(任意)、状態、UID
  • 主催者とすべての参加者(`CN` があれば名前、なければアドレス)
  • ⚠️ 繰り返し規則を文章で表示 —— `FREQ=WEEKLY;BYDAY=TH;COUNT=4` ではなく「毎週(木)、計 4 回」
  • ⚠️ 解釈できない修飾子は原文のまま末尾に付記 —— 分かったふりをしません。それらの条件が特定の回の発生可否を決めるからです
  • アラーム数(`VALARM` サブコンポーネント)
  • 終日の予定はその旨を示し、所要時間は日数で数えます
  • 集計:予定数、繰り返しありの数、アラームありの数、全体の期間
  • ⚠️ RFC 5545 の折り返しを正しく処理(1 行 75 オクテット、継続行は空白で始まる)—— 誤ると本文に空白が増えたり語が途中で切れます
  • ⚠️ 既定では換算せず、ファイルの鐘時とゾーン名(またはフローティング)をそのまま示します
  • ⚠️ 任意のタイムゾーンで表示できます:IANA 名を入れると、各予定に換算後の時刻とその日の UTC オフセットの行が増えます
  • オフセットは予定のその日付時点の値です(今日ではありません)—— 夏時間をまたぐ 2 つの日付では違う値になります
  • 夏時間で飛ばされた鐘時(そのゾーンに存在しない)と戻しで重複する鐘時(2 つの瞬間)はいずれも明示し、黙って近い時刻にずらしたりしません
  • 換算の行は「ファイルどおり」の行と並んで表示され、元の行は置き換えません
  • すべてブラウザー内で完結し、ファイルは送信されません

使い方

  1. .ics ファイルの中身を最初から最後まで貼り付けます(BEGIN:VCALENDAR 〜 END:VCALENDAR)
  2. 説明が必要なら「予定の説明も出力」をオンにします
  3. 結果は予定ごとのブロックで表示され、末尾にタイムゾーンの注意書きが付きます

よくある質問

なぜ自分のタイムゾーンに換算しないのですか?
既定で換算しないのは、ファイルに書かれているのが生の事実であり、換算はそこから導かれるものだからです —— 両方を別々に並べれば突き合わせられます。換算したいときはオプションに IANA ゾーン名を入れてください。⚠️ そのときも固定オフセットを引いているのではなく、プラットフォームのタイムゾーンデータベースからその日付時点のオフセットを取っています(夏時間の規則は何度も変わっており、固定値ではありません。`Europe/London` に固定値を当てれば夏の数か月は 1 時間ずれます)。夏時間で飛ばされた鐘時や重複する鐘時も、黙って近い時刻にずらさず明示します。誤った時刻は時刻がないより悪いからです。
「フローティング時刻」とは何ですか?
`Z` もゾーン名もない時刻は、iCalendar では「現地の壁時計でその時刻」という意味です —— つまり東京でもロンドンでも 14:00 は 14:00 で、誰の現地時間でも同じです。「毎朝 7 時に服薬」のような場所に依存しない事柄に適します。これを特定の瞬間として換算すると、もっともらしいが誤った結果になります。だからここでは明示します。
繰り返しの説明の後ろに `BY...=` が付くことがあるのはなぜですか?
解釈できなかった修飾子であり、それらが特定の回の発生可否を決めることが多いからです。たとえば `BYDAY=-1FR`(毎月最後の金曜)と `BYSETPOS=-1`(その集合の最後)は単独なら読み取れますが、組み合わせた意味を確定するには完全な展開アルゴリズムが必要です。ここでは読み取れた部分だけを文章にし、残りは原文のまま末尾に付けます —— 通りのよい文で制約を黙って落とすより、生の条件が見えるほうがましです。
説明の文字がくっついて見えることがあるのはなぜですか?
たいていそのファイルが別のツールで書き直されたためです。RFC 5545 は 1 行 75 オクテットを上限とし、超えた分は次の行に空白 1 つで折り返します。正しい展開は区切りを入れない純粋な連結です。独自の改行規則で保存し直したり、折り返しを「空白を入れる」と解釈するツールがあるため、余分な空白が戻ってきます。ここは規格どおりに処理しています —— 不自然な空白があるなら、原因はファイルを生成した側です。
CSV に書き出せますか?
現在はできません。結果全体をコピーでき、行の値は 1 つずつコピーできるので、表計算ソフトに貼るには十分です。何十ものカレンダーファイルを一括処理するのは、ブラウザーのページに貼り付ける範囲を超えています。

関連ツール