要約

  • RFC 1502は、X.400 GeneralTextが複数の文字集合を告知できても、各バイトを読むにはISO 2022の指定・シフト状態を追う必要があると説明した。
  • 受信側は表せない文字を明示し、未知の文字集合で同じビット位置にある自国語の字を代わりに表示してはならない。送信側への推奨手順を、受信側の思い込みに変えてはいけない。

読めない文字が空白として残れば、受け手は異変に気づく。もっと厄介なのは、普通の文字に見える誤表示だ。Harald Alvestrandが1993年8月に書いたRFC 1502は、国際メールの搬送に加えて、その最後の表示まで問題にした。端末の字形不足を、差出人の文章に紛れ込ませないためである。

X.400のGeneralTextでは、封筒と本文のパラメーターに使用文字集合を列挙できる。一方、本文中ではISO 2022のエスケープとシフトによって、どの集合が有効かを変えられる。開始時はIA5がG0にあり、C0には標準制御集合があると想定する。別の状態から始めるなら、その知らせを本文の先頭に置く。集合の一覧だけでは途中の一バイトを読めない。そこまでの状態変化が答えを決める。

送信側には、US-ASCIIをG0に保ち、可能ならISO 8859の集合をG1に使う手順が勧められた。ASCIIのビット表現を揺らさないための整理である。ところが受信側の節は、送信者がその整理に従ったと仮定するなと釘を刺す。実際のメールを読む仕事は、理想的なメールの説明書を読む仕事とは違う。

表示に関する命令は具体的だ。GeneralTextを扱える利用者エージェントは、IA5と自分の標準的な文字を認識し、出力装置で十分に表せない文字があれば存在を示す。そして未知または表示不能な集合の文字を、同じビット位置にある手元の文字として描いてはならない。数字の位置が一致しても、文字の意味は一致しない。

RFCは、代替表現で読ませる表示と、表せない箇所を明示する表示を使い分け、文字集合の情報ごと保存することも望んだ。GeneralTextをMIMEなどへ変換するゲートウェイにも同じ考え方を求める。目の前の読みやすさを優先して、後で元の文字を調べる手掛かりを消しては困る。

変換先の集合に文字がなければ、置換記号、別途知らせる可逆的な略記、人向けの代用表記、変換拒否が選択肢になる。ただし損失を禁じる指定がある場合は拒否だけだ。RFC Editorの現在の記録はHistoricと示し、1993年の本文は当時の標準化過程を記している。文書には実際の製品試験はない。残った原則は明快だ。画面に字がなければ、その限界を見せる。別の字を作者に押しつけない。