要約

  • RFC 1468は、ASCIIから始まり、4種類のエスケープ列でASCII、JIS X 0201ローマ字、二つのJIS X 0208を選ぶ狭い7ビット・プロファイルを定めた。二バイト状態を使った行はCRLFより前に一バイト状態へ戻る必要があった。
  • MIMEのISO-2022-JP表示は、使うべき復号規則を指したにすぎない。本文の文法適合、中継での指定列保存、復号結果、フォントが描いた字形、読者が受け取った意味はそれぞれ別に確かめなければならない。

次の行を読むために、前の行のはるか手前まで戻らなくてよい。この性質は、文字の種類そのものと同じくらい重要だった。

RFC 1468 は1993年6月、JUNETで生まれ、日本のIPコミュニティで使われていた符号化を記録した。本文はASCIIで始まる。日本語を表す区間へ入るときはエスケープ列を置き、行が終わる前に一バイト状態へ戻る。文書全体の最後はASCIIでなければならない。

これは古いメール輸送路に日本語を「そのまま」通した話ではない。7ビットという既存の制約の内側に、小さな状態機械を組み込んだ話である。ネットワークの全機器に日本語理解を要求せず、送信側が限定された表現を作り、中継側がそれを壊さず、受信側が同じ履歴を再生する。その分業こそが互換性だった。

一つの値は、直前の状態で別物になる

ESC $ B はJIS X 0208-1983を、ESC $ @ は1978年版を指定する。その後の文字は二バイトずつである。ESC ( B はASCIIへ、ESC ( J はJIS X 0201のローマ字集合へ切り替える。

デコーダは、最後に有効だった指定を覚えていなければならない。ある二つの値がJIS X 0208の文字になるのは、先行する指定がその状態を開いている間だけだ。ASCIIへ戻った後では、同じ値の並びは同じ文字を意味しない。各バイトに意味が完全に埋め込まれているのではなく、意味の一部が時間方向の文脈に置かれている。

一バイト側にも差がある。JIS X 0201ローマ字は、ASCIIのバックスラッシュとチルダに当たる位置を円記号とオーバーラインとして扱う。特定の端末やフォントが両者を同じように見せても、符号化上の指定は消えない。またJIS X 0201のカナ集合は、このプロファイルでは使わない。「JP」という名前から半角カナまで許されると推測する余地はなかった。

形式構文がESC、SI、SOを通常の一バイト文字から除外しているのも重要だ。制御の役割と本文の役割を同じ値に都合よく兼任させない。ISO-2022-JPという名称が有用なのは、日本語一般を曖昧に包むからではなく、許される機械を小さく指し示すからである。

CRLFの手前で状態を畳む

JIS X 0208の文字を含む行は、CRLFの前にASCIIまたはJIS X 0201ローマ字へ切り替えなければならない。次の行は、直前に選ばれた一バイト状態から始まる。そして最終的にはASCIIへ戻る。

この規則は冗長さを意図的に受け入れる。日本語が何行も続けば、指定と復帰を何度も書くことになる。それでも、状態が無制限に持ち越されるより扱いやすい。引用ソフトが行頭へ>を挿入しても、それが二バイト文字の片割れにならない。途中行から表示するツールも、文書の先頭から全指定を再生する必要がない。一行が壊れても、後続の全行が永続的に二バイト状態へ閉じ込められにくい。

もちろん完全な自己同期ではない。行末にJIS X 0201ローマ字を選べるため、ASCIIとの差は残る。不正なエスケープ列をどう回復するかも実装差を生む。それでも、二バイト状態が行境界を無言で越えることは禁じられた。行末は見た目の区切りだけでなく、解釈の作用範囲を閉じる境界になった。

RFCの最小性は、何もしないことではない。共通部分を、独立実装が同じ入口と出口を持てる大きさに制限することである。

7ビットであることと、読めることは違う

MIMEでの表記はContent-Type: text/plain; charset=iso-2022-jpである。すべての値が7ビットに収まるため、旧来の経路を通るためだけに別のContent-Transfer-Encodingをかける必要はなかった。

しかし7ビット安全性が保証するのは値の幅だけだ。ESCを一つ落とす、指定列を別のものへ置換する、二バイト文字の中央で折り返す、改行を再構成する。どの操作も、出力を7ビットのまま保ちながら内容を変えられる。輸送路がバイトを受け入れることと、受信端が同じ文字を得ることの間には、順序と状態の保全がある。

RFCは、Base64やquoted-printableを適用すると当時のJUNETソフトで読めなくなるとも記した。これは1993年の稼働環境に関する記述であり、可逆な変換が本質的に原文を壊すという主張ではない。外側の転送符号化を外してから内側のcharsetを解く実装が普及していなければ、紙面上の可逆性は運用上の互換性にならない。

後の RFC 2046 は、MIMEテキストのcharsetを重要なパラメータとし、本文が指定されたcharsetの文字から成ること、テキストの行規則が残ることを明確にした。ラベルは契約を選ぶ。経路の各プログラムが契約を実行したという領収書ではない。

見分けられない中継系にも保存義務があった

RFC 1468は、一部のシステムが表示上ESC ( BとESC ( Jを、あるいはESC $ @とESC $ Bを区別しないと認めている。それでも、他システムへ中継するときはエスケープ列を一切変更してはならないとした。

ローカル表示での同一性は、転送されるオブジェクトの同一性ではない。ある本文が1978年版と1983年版で同じ字形になるとしても、別の本文や将来の変換器まで同じとは限らない。あるフォントが円記号とバックスラッシュの差を隠しても、受信者の環境を拘束できない。中継者が差を利用しないことは、その差を消す権限の根拠にならない。

原バイトの保存は、問題が起きたときの因果も残す。送信された表現、中継での変化、デコードされた文字、描画された字形を別々に比べられる。親切な「正規化」で指定列を書き換えると、見た目が整う代わりに、どこで意味が変わったかを証明しにくくなる。

この保存義務はメッセージの真偽や送信者の身元を保証しない。中継者の役割を、自分の解釈で他人のオブジェクトを書き換えないところまでに限定する。

文字数と桁数とバイト数

文書は、引用記号を入れる余地として75から80表示桁程度を利用者へ勧めた。JIS X 0208文字は二バイトかつ二桁、エスケープ列は複数バイトだがゼロ桁として扱われる。表示のために二バイト文字を中央で分割してはならない。

したがって、同じ一行に少なくとも三つの座標がある。原データを指すバイト位置、復号後の文字位置、画面上の表示桁だ。ASCII区間では重なって見えても、指定列を越えれば分離する。80バイト目で切る処理は80桁目で折る処理ではない。印字されない値を先に除去する処理は、残りを読むための状態そのものを捨てうる。

原文ハッシュは表現の同一性を証明するが、フォントの出力は証明しない。スクリーンショットは一つの表示結果を証明するが、入力列を復元しない。両者は競合する証拠ではなく、別の現実層を固定する証拠である。

charsetは「文字の箱」ではない

RFC 2978 は、charsetをオクテット列から文字列へ変換する方法と定義し、ISO 2022のような複雑な表切り替えも含むとした。名称に結びつく定義は、外部の隠れたプロファイルに頼らず変換を完全に指定しなければならない。

現在の IANA Character Setsレジストリ は、ISO-2022-JPを番号39としてRFC 1468とRFC 2237へ結び、csISO2022JPという別名も示す。ISO-2022-JP-2は番号40として別に存在する。登録は、同じ名前が別々の規則へ勝手に割り当てられるのを防ぐ。本文を検査したり、デコーダを認証したり、現在の利用率を測ったりはしない。

RFC Editorの書誌情報 が示す区分はInformationalである。これをInternet Standardと呼ぶのは誤りだが、「情報提供だから運用上重要でなかった」と読むのも誤りだ。文書区分、名称登録、実装状況は別の記録で確かめる必要がある。

拡張は古い名前の中へ隠されなかった

1993年12月の RFC 1554 は、実験的な多言語拡張ISO-2022-JP-2を定義した。中国語、韓国語、補助日本語、ラテン文字、ギリシャ文字などの指定を増やし、行頭で一部状態をクリアする第二の指定領域も持つ。受信側が再生すべき機械が変わるため、MIME名も変わった。

1997年の RFC 2237 は、JIS X 0212をESC $ ( Dで追加するISO-2022-JP-1を記述した。最後をASCIIにする条件は残り、JIS X 0212を使わない本文では通常のISO-2022-JPを使うよう求めた。

新しい能力へ新しい名前を与えると、古い受信者は理解できない契約を正直に拒否できる。既存名の下で未知の状態を正当化してしまえば、不正入力と将来拡張の区別がつかない。更新可能性と過去の意味の安定性は、名称を分けることで両立した。

規格が届くのは読者の手前まで

標準文書が示すのは、適合する列をどう作るかである。特定の人が何を見てどう理解したかは示さない。MIMEフィールド、原バイト、状態遷移、中継変換、デコーダ版、復号文字列、フォント、レンダリング、利用者の行動を一つずつ分ける必要がある。

Heng Luの公開論考は、この分離を運用原則として読ませる。Minimum Initial Specification は小さな共通仕様とローカルな採否を分ける。Running-Code Primacy は公刊された規則と実際に動くコードを分ける。On Reality Layers は名称、表現、知覚、行為を一つの象徴へ押し込めない。

RFC 1468の強さは、最終結果まで支配しようとしなかった点にある。名前が規則を示し、エスケープ列が現在状態を示し、行末がその作用を閉じ、中継系が対象を保存し、端点が実行する。日本語を理解しない経路でも日本語メールを運べたのは、それぞれの権限が境界を越えなかったからだ。