ICSの75オクテット折り返しで日本語が化ける理由とセミコロンの書き忘れ
.ics ファイル(iCalendar)を自分で組み立てると、テキストの扱いで2つの問題に当たりやすい。1つは長い行の折り返し、もう1つは ; や , のエスケープである。
折り返しは RFC 5545 の 3.1 節で「1行は改行を除いて75オクテットを超えるべきではない(SHOULD NOT)」と決まっている。単位は文字ではなくオクテット(バイト)である。日本語は UTF-8 で1文字3バイトなので、length で75文字を数えると、実際には200バイト以上の行ができる。逆にバイト数で機械的に切ると、文字の途中で切れることがある。
この記事では、どちらの失敗も Node.js で再現し、読む側で文字化けが起きる条件を確かめる。あわせて、ハシトシステムの ICS ファイル生成 の実装も読み、見つかった問題を書く。
検証環境は Windows 11、Node.js v24.11.1、ical.js 2.2.1(Mozilla のカレンダー用ライブラリ)である。
折り返しの決まり
RFC 5545 の折り返しは次のとおりである。
- 75オクテットを超える行は、途中に CRLF と空白1文字(SPACE か HTAB)を入れて分ける。
- 読む側は「CRLF の直後に空白1文字」を見つけたら、その3バイトを取り除いて元の1行に戻す(unfold)。
- 継続行の先頭の空白も1行の長さに含まれる。継続行に入れられる中身は74オクテットまでになる。
同じ節には、単純な実装は UTF-8 のマルチバイト文字の途中で折り返すことがあるので、読む側は元のバイト列を正しく戻せるように unfold する必要がある、という注記もある。書く側は文字の途中で切らないのが望ましく、読む側は切られていても戻せるようにしておけ、という意味である。
文字数で数えると折り返されない
次の件名で試す。
1 | |
この行は46文字だが、UTF-8 では112バイトある。line.length で75文字ごとに区切る実装では、46文字なので1度も折り返されず、112バイトの行がそのまま出る。
ical.js 2.2.1 は、この行を折り返さなくても問題なく読めた。SHOULD NOT なので、長い行を受け付ける実装は多い。ただし、どのアプリでも読めるとは限らないので、書く側は規定どおりにしておくほうがよい。
バイトで切ると文字が割れる
今度は UTF-8 のバイト列を75バイト目で機械的に切り、CRLF と空白を挟む。112バイトの行は75バイトと38バイト(先頭の空白を含む)の2行になる。75バイト目は「け」(3バイト)の途中にあたり、「け」の先頭2バイトが1行目に、残り1バイトが2行目に入る。
このファイルの読み方を3通り試した。
| 読み方 | 結果 |
|---|---|
| 1行ずつ UTF-8 として読んでから unfold する | 参加者向��案内 になる |
| ファイル全体を UTF-8 として読んでから unfold する | 同じく �� が入る |
| バイト列のまま unfold してから UTF-8 として読む | 元の文字列と一致する |
2つ目も壊れるのは、割れた「け」の間に CRLF と空白の3バイトが挟まっているためである。UTF-8 のデコーダーから見ると、続きのバイトが来るはずの位置に 0x0D が来るので、不正なバイト列として U+FFFD(置換文字)に置き換える。いったん U+FFFD になった文字は、後で CRLF と空白を取り除いても戻らない。
JavaScript で .ics を読むとき、fs.readFileSync(path, 'utf8') や await file.text() で文字列にしてから ical.js などのパーサーに渡すのが普通である。この順番だと、デコードが unfold より先になる。ical.js の ICAL.parse は文字列を受け取る関数なので、ここで割れた文字を直す手段はない。RFC の注記にある「元のバイト列を戻せるように」を満たすには、文字列にする前にバイト列で unfold する必要がある。
ical.js が書き出す継続行は76オクテット
ical.js 2.2.1 で長い値を書き出すと、ICAL.foldLength(既定75)にしたがって折り返す。helpers.foldline のソースでは、UTF-8 のバイト数を数えながらコードポイント単位で切っているので、文字の途中では割れない。
ただし、継続行の中身を75オクテットまで詰めてから先頭に空白を足している。DESCRIPTION: に ASCII の a を200文字入れて toString() すると、各行のバイト数は次のようになった。
1 | |
BEGIN:VEVENT(12)の次の 75 が1行目、76 と 63 が継続行、10 が END:VEVENT である。継続行は空白を含めて76オクテットあり、RFC の75を1つ超える。読む側で困ることはまず無いが、厳密に検査するバリデーターに通すなら注意がいる。
エスケープが必要な文字
RFC 5545 の 3.3.11 節では、TEXT 型の値の中にある次の文字をバックスラッシュでエスケープすると決めている。
| 文字 | 書き方 |
|---|---|
\ |
\\ |
; |
\; |
, |
\, |
| 改行 | \n(\N も可) |
: はエスケープしない。また URI 型の値(URL プロパティなど)は 3.3.13 節でバックスラッシュによるエスケープを定義していないので、TEXT と同じ処理を通してはいけない。
ical.js 2.2.1 で次の2行を読むと、こうなった。
| 入力 | 読んだ値 |
|---|---|
SUMMARY:打合せ;議事録あり |
打合せ;議事録あり |
LOCATION:会議室A\, 3F\; 西側 |
会議室A, 3F; 西側 |
URL:https://example.com/a?x=1\,2&y=3 |
https://example.com/a?x=1\,2&y=3 |
ical.js は ; がエスケープされていなくても SUMMARY を1つの値として読んだ。一方、URL に入った \, は URI 型として扱われるので、バックスラッシュが残ったまま URL になる。この URL を開くとクエリが x=1\,2 になり、元のページに届かない。
ハシトシステムの ICS ファイル生成では
ICS ファイル生成 は、件名、日時、場所、説明、URL、繰り返し、通知を入力すると .ics ファイルを作るツールである。2026-11-12 に本番の HTML から escapeText と foldLine を取り出して、上と同じ入力を通した。
- 折り返しは規定どおりだった。UTF-8 のバイト数を数え、サロゲートペアも1文字として扱い、1行目は75、継続行は空白を含めて75オクテット以内に収める。上の件名は73バイトと40バイトの2行になり、
\r\nを取り除くと元に戻った。絵文字を含む行でも文字は割れなかった。 ;がエスケープされていなかった。escapeTextは.replace(/;/g,'\;')と書かれているが、JavaScript の文字列リテラルでは'\;'は';'と同じなので、;が;に置き換わるだけになる。A;B,Cを通すとA;B\,Cになった。正しくは'\\;'である。URLにもescapeTextを通しているので、,を含む URL は\,になる。上の表のとおり、読む側では URL にバックスラッシュが残る。
ical.js のように ; のエスケープ漏れを許すパーサーでは件名が壊れることはないが、規定どおりではない。この2点は修正対象として記録した。
入力した予定の内容はブラウザ内で処理され、サーバーには送られない。予定を QR コードで配る方法は iCalendar(VEVENT) を QR にする記事 に書いた。バイト数の数え方そのものは 文字数カウント で確かめられる。
実際に試す
前提: Node.js(確認は v24.11.1)。外部パッケージは不要である。
書く側はコードポイント単位で UTF-8 のバイト数を数えて折り返す。読む側はバイト列のまま unfold してから UTF-8 として読む。
1 | |
実行結果は次のとおりである。
1 | |
1行目が73バイトで止まっているのは、次の文字(3バイト)を足すと76になるからである。ASCII だけの行は75、75(空白1+中身74)、64 で、どの行も75を超えない。
unfoldBytes は TextDecoder に fatal: true を渡しているので、unfold した後もまだ不正な UTF-8 が残っていれば例外になる。黙って U+FFFD に置き換えて先へ進むことはない。ファイルから読むときは fs.readFileSync(path) のようにエンコーディングを指定せずに Buffer で受け取り、unfoldBytes に渡してから ical.js などのパーサーに文字列を渡す。
ical.js の継続行が76オクテットになることは、空のディレクトリで npm i ical.js@2.2.1 を実行してから次を打つと確かめられる。
1 | |
まとめ
- iCalendar の1行は改行を除いて75オクテットまで。文字数ではなく UTF-8 のバイト数で数え、継続行の先頭の空白も含める。
- 日本語46文字の件名は112バイトある。
lengthで数えると折り返されない。 - バイト数で機械的に切ると文字が割れる。割れたファイルを先に UTF-8 の文字列にすると、unfold の前に U+FFFD に置き換わり、戻らない。読む側はバイト列のまま unfold してからデコードする。
- ical.js 2.2.1 は文字を割らずに折り返すが、継続行は空白を含めて76オクテットになる。
- TEXT 型では
\、;、,、改行をエスケープする。JavaScript の'\;'は';'なので、置換先は'\\;'と書く。 URLなどの URI 型の値には TEXT のエスケープを通さない。通すと\,が URL に残る。
結果は 2026-11-12 時点の上記の環境とバージョンで得たものである。
参考
- RFC 5545 — 3.1 Content Lines(折り返しと unfold、UTF-8 の注記)、3.3.11 Text、3.3.13 URI、3.8.4.6 Uniform Resource Locator
- ical.js 2.2.1 のソース(
dist/ical.jsのfoldlineとfoldLength) - MDN —
TextDecoder(fatalオプション)、TextEncoder - WHATWG Encoding Standard — UTF-8 デコーダーのエラー処理(不正なバイト列を U+FFFD に置き換える)
このバージョンはその範囲に入るのか
依存の話でいちばん間違えやすいのは ^1.2.3 や ~1.2.3 がどこまでを許すかです(^0.2.3 のようにメジャーが 0 のときは規則が変わります)。範囲とバージョンを貼ると、下限・上限に展開したうえで一致・不一致とその理由を表示するsemver 範囲判定ツールを置いています。ブラウザの中だけで動き、入力はどこにも送信しません。