要約

  • RFC 1922では、中国語を含むISO-2022-CNの各行が必要な文字集合をその行で指定し、CRLFの前にSIでASCIIへ戻る。途中の行から表示しても、上方の見えない状態を引き継がずに済む。
  • エスケープによる指定、SI/SO、一文字だけのSS2/SS3は七ビットの解釈規則を作った。正しい規則は、配送、フォント収録、字形、送信者の身元を証明しない。
  • charset-editionとcharset-extensionは版の年やベンダー拡張への依存を露出させた。相違を記録できても、受信側の実装や字体を自動的に一致させるものではない。

一文字だけ状態を借りる

状態を持つ文字符号では、同じバイトが現在の文字集合によって別の意味を持つ。SOで二バイト集合へ入り、SIでASCIIへ帰るような切替は、その後の文字列に効き続ける。一方、SS2とSS3は次の二バイト、すなわち一文字にしか効かなかった。読み終えると、以前のSI/SO状態が再開する。

この差はログに残す価値がある。「中国語状態」という一つのフラグだけでは、どの集合が指定され、永続的に切り替えたのか、一文字だけ借りたのか、どこで元へ戻ったのかが分からない。誤った実装が短い借用を永続化すれば、その後の正常なバイトまで別の文字になる。

1996年3月にInformationalとして出たRFC 1922は、さらに行そのものを復旧単位にした。ISO-2022-CNはASCIIから始まる。中国語を含む行では、その行の中で文字集合を指定し直す。CRLFの直前にはSIを置き、ASCIIへ戻す。各行は既知の状態から始まり、既知の状態で終わった。

スクロール位置が解釈を決めてはいけない

メールは必ず先頭から表示されるわけではない。読者は途中へスクロールし、返信は数行を引用し、障害は前半だけを失わせる。先頭のエスケープ列に全行が依存していれば、見えている行が完全でも読み方だけが欠ける。

行内で指定を繰り返す設計は数バイトを余計に使った。しかし、その冗長性が現在の行へ判断材料を戻した。前の指定が失われても、誤りを後続全体へ連鎖させにくい。表示器はメッセージ先頭まで巻き戻らず、その行から状態を構築できる。

ISO-2022-CN-EXTは、登録済みの文字集合や面を増やした。将来のISO登録に備え、未割当の終端文字を含む形式も予約したが、割当が行われるまで使用を禁じた。将来用の空欄は、先に独自の意味を書き込む権限ではなかった。

七ビット形式と八ビット輸送を分ける

ISO-2022-CNとISO-2022-CN-EXTは七ビット内に収まった。そのため、高位ビットを守るという理由だけでContent-Transfer-Encodingを付ける必要は通常なかった。ただし、MIMEのcharset、合法な状態遷移、対応デコーダーは依然として必要だった。

CN-GBとCN-Big5は八ビット形式である。七ビット経路ならBase64またはQuoted-Printableで包み、直接送るならSMTPで8BITMIMEが実際に交渉されていなければならない。古いメール転送器が高位ビットを落とせば、転送自体が完了しても文字は読めなくなる。

charsetは解釈の宣言、転送符号化は表現の保護、8BITMIMEは輸送能力の合意である。それぞれの証拠範囲は狭い。どれも作者を認証せず、フォントを補わず、画面に正しい字形が出たことを保証しない。

年号は表を選べても、字形を保証しない

中国語文字規格には版がある。charset-editionは期待する版の年を記録した。理解する実装は対応表を選べる。理解しない実装はパラメーターを無視し、旧版による少数の誤りを生む可能性があった。年を明記することは診断材料であり、正しさの証明書ではない。

charset-extensionはベンダー固有または地域固有の追加集合を名前で示した。登録名や私用のx-名は依存関係を見えるようにしたが、受信側にない字形を作り出さない。拡張は相互運用性を下げ得るとRFC自身が認めている。

Big5とCNS 11643の対応も、変換表と実装に残った。正しいバイト列が異なる表やフォントで違って見えることはあり得る。符号化方式が字体の慣行を示唆しても、国籍、所在地、利用権限は示さない。

引用記号のために幅を残す

エスケープ列はバイトを使うが表示幅を使わない。中国語の一文字は通常二バイト、二桁を使う。RFC 1922は二バイトを行の途中で分断しないよう求め、表示幅をおよそ75桁に抑えるよう勧めた。返信時に先頭へ>が加わる余白を残すためである。

これは、符号化がメールの日常動作まで考えていたことを示す。運搬時に壊れないだけでは足りない。引用、切出し、再表示という普通の操作にも耐える必要があった。行ごとの復帰と幅の余白は、同じ復旧思想の別の表現だった。

資料が示すのは仕様であり、普及率ではない

中心資料はRFC 1922である。RFC 1468とRFC 1557は、日本語・韓国語の七ビットメール設計という隣接文脈を与える。RFC 1521は当時のMIME、RFC 1652は8BITMIMEの交渉境界、RFC 2046は後のMIME整理を示す。RFC 3629は、さらに後のUTF-8標準化を記録する。

この並びから導入台数は分からない。RFC 1922は、少なくともISO-2022-CNを送受信し、実用上可能な限り多くの記載形式を受信するよう勧告した。特定製品の準拠も、UTF-8への自動かつ無損失の移行も証明していない。Security Considerationsでは、セキュリティは論じられていない。

Running-Code Primacyは後世の分析規律として役立つ。RFCと登録名は調整面を記述し、実際のパーサー、転送器、変換表、フォントが運用結果を作る。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionを重ねると、共有核は指定、切替、バイト範囲、復帰という決定的規則に絞られ、集合の実装や移行は各参加者に残る。この後世の考えをRFC著者の意図とみなしてはならない。

RFC 1922は、状態を消したのではなく、借りる範囲と返す場所を明確にした。見えない過去より、現在の一行を信頼できるようにしたのである。