イベント QRコード作成

iCalendarのペイロード、正確に

コードが運ぶのはRFC 5545の完全なオブジェクトであって、そこへのリンクではありません。BEGIN:VCALENDARで始まり、VERSION:2.0とこの生成ツールを示すPRODIDを持ち、1つのVEVENTを包み、END:VCALENDARで閉じます。イベントの中には、仕様が必須とするUIDとDTSTAMPが入り、その隣にDTSTART、DTEND、SUMMARY、そして入力したLOCATION、DESCRIPTION、URLが並びます。

内容行はすべて、復帰改行の順、つまりCRのあとにLFで終わります。パーサーはここに厳格で、LFだけのオブジェクトは、他が正しくてもイベントの取り込みに失敗する原因になります。75オクテットを超える行はCRLFに続けて空白1つを挟むことで折り返され、読み手は解析の前につなぎ直します。長い説明文があってもオブジェクトが壊れないのはそのためです。

イベント全体がパターンの中にあるので、スマートフォンは予定を作るのにネットワークを必要としません。同時にそれは、イベントが凍結されていることも意味します。あとから会場を変えるには、コードを作り直して印刷し直すしかありません。更新できるものが存在しないからです。

フローティング現地時刻とUTC

フローティングモードでは、DTSTARTは末尾のZもTZIDパラメータもない YYYYMMDDTHHMMSS の形で書かれます。RFC 5545はこれをフローティング時刻と呼び、意味は文字どおりです。19:00は、開いた端末がどこにあっても19:00です。コンサート、マルシェの出店、学校の説明会なら、ほとんどの場合これが望むものです。ポスターを読む人は全員、会場と同じタイムゾーンに立っているからです。

UTCモードでは同じプロパティが YYYYMMDDTHHMMSSZ と書かれ、末尾のZが時点を固定します。各端末は取り込みのときに現地時刻へ変換するので、14:00 UTCに設定したイベントは東京では23:00、ニューヨークでは09:00と表示されます。ウェビナーには正しい選択で、町内のお祭りには誤った選択です。

名前付きのタイムゾーン、つまり DTSTART;TZID=Asia/Tokyo は仕様上の3つめの可能性ですが、このツールは提供していません。きちんとやるには夏時間の切り替え規則を全部含んだVTIMEZONEコンポーネントを埋め込む必要があり、1つのシンボルに収めなければならないペイロードに数百バイトを足すことになります。しかも、定義していないTZIDを参照するオブジェクトは不正です。フローティングとUTCなら、その代償なしに印刷物の用途をカバーできます。

エスケープ、終日イベント、そしてサイズ

テキストの値は、ペイロードに入る前に仕様が求めるとおりにエスケープされます。まずバックスラッシュ、次にセミコロンとカンマ、最後に改行の順です。この順序を変えると、直前に入れたバックスラッシュを二重にエスケープしてしまいます。テキスト値の中のコロンはそのままにします。RFC 5545はコロンのエスケープを明確に禁じているからです。古いRFC 2445では必要とされていて、手書きの生成ツールがいまだにここを間違えるのはそのためです。

終日イベントは日付の形を使います。DTSTART;VALUE=DATE:20260904 です。そのDTENDは排他的なので、9月4日の1日だけなら DTEND;VALUE=DATE:20260905 と書きます。ここを間違えると、1日足りない、あるいは1日多いイベントができあがります。

実際の制約になるのはサイズです。QRシンボルが持てるのは最も低い復元レベルでも最大2,953バイトで、カレンダーの包みだけで、あなたの文字が始まる前におよそ200バイトを使います。説明文が長いとシンボルは上位のバージョンに押し上げられ、モジュールが小さくなるので、より大きく印刷するか、より近づいて読み取る必要が出てきます。プレビューは入力に合わせてバージョンを表示するので、その動きを見ていてください。

• バックスラッシュは \\ に、セミコロンは \; に、カンマは \, になります
• 改行は \n という2文字になります
• RFC 5545のテキスト値では、コロンをエスケープすることは決してありません