要約

  • 1993年12月のRFC 1557は、韓国語の平文メール本文にISO-2022-KRを用いる。ASCIIで始まり、ESC $ ) CでKSC 5601を指定し、SOで二バイト文字へ、SIでASCIIへ戻る。
  • 件名などのヘッダーでは韓国語をEUC-KRで表し、RFC 1522のBまたはQによる符号化語に包む。本文と件名を読む処理は別々だ。

件名だけ先に入国できた

会議の変更を知らせるメールを受け取る。件名には韓国語で用件が表示されている。ところが本文の新しい時刻は、画面上で意味のない記号に化けている。配送されたのは一通でも、表示までの経路は一本ではない。上の欄と下の文章で、受信ソフトに求められる仕事が違った。

RFC 822以来、インターネットメールは構造を持つヘッダーと、その後に続く本文を分けて扱ってきた。ヘッダーには住所や件名が並び、コンマやコロン、折り返しには文法上の意味がある。中継ソフトはアドレスの順番を変えたり、行を折り直したりする。本文は長く続くテキストとして運ばれる。韓国語を両方に載せるなら、この違いをまたぐ仕掛けが要る。

U. Choi、K. Chon、H. ParkがまとめたRFC 1557は、その仕掛けを1993年12月に記録した。著者らによれば、方式は1991年に定められ、当時の韓国のIPネットワークで広く使われていた。対象は平文メールである。本文に七ビットの状態切り替えを使い、ヘッダーには別の文字表現をASCIIで包む。この割り切りが文書の中心だ。

本文はASCII状態から出発する。ESC $ ) Cという列でKSC 5601を指定し、SOが出たら後続のバイトを二つ一組の韓国語文字として読む。SIでASCIIに帰る。KSC 5601にはハングルや漢字などが含まれる。同じように見えるバイトでも、直前にどちらのスイッチが入ったかで読みが変わる。本文のMIME文字集合名はISO-2022-KRだ。

細部を読むと、説明文は韓国語を含む行の冒頭で指定列を置くように見える。一方、形式文法は一つの指定列の後に複数の該当行が続く形を許す。RFC自身が、食い違う場合は形式文法を優先すると書いている。古いメールを調べるなら、行ごとの機械的な反復を想定するより、保存されたESC $ ) CとSO、SIの位置を追うべきだ。

本文は七ビットで表せるため、RFCはこの形式について追加のContent-Transfer-Encodingヘッダーを必要としないと説明した。さらに、当時の韓国語メールソフトは、符号化済み本文にBase64やQuoted-Printableを重ねる処理に対応していないとも記す。1993年の実装事情が見える箇所である。本文のISO-2022-KRという名札は、この状態機械を動かすためにある。

件名の窓口では手続きが変わる。韓国語をEUC-KRのバイトにしてから、RFC 1522のBまたはQ符号化語に収める。包みの形は=?charset?encoding?encoded-text?=。外側は旧来のヘッダー処理ソフトにも扱いやすい印字可能なASCIIで、内側に文字集合と符号化方式の手掛かりがある。件名の名札はEUC-KR、本文はISO-2022-KR。同じ言語という理由で同じ復号器に渡せば、どちらかが迷子になる。

受信者は件名から本文まで自然につながった一通を読む。その裏側では二つの復号が別々に成功している。RFC 1557が面白いのは、普通の文章の真ん中に埋まったソフトウェア上の境界を、逃げずに見せているところだ。