要約

  • RFC 1345は、転送用の文字集合にない文字を小さな共通の記号集合から作る名前で表し、区別を保って届ける仕組みを示した。
  • 導入列を0にすると、名前の開始記号と長い名前を囲む下線が消える。RFCは読みやすさと引き換えに可逆性が失われ、情報が欠けると明記した。

一つの名前を、少数の文字しか通さないメール経路に載せる。名前の中の一文字が、その経路の文字集合にない。近い文字へ置き換えれば画面には出るが、元の文字を後から確かめる手段は弱くなる。Keld Simonsenが1992年6月のRFC 1345で提案したのは、文字そのものの代わりに共通の記号で綴った名前を運ぶ方法だった。

その名前には始まりと終わりが要る。通常の二文字と、別の文字を意味する二文字をどう見分けるのか。RFCはASCIIのアンパサンドに当たる十進数38を導入列として勧めた。記号そのものを表したいときは導入列を二度書く。二文字を超える名前は下線で囲む。読みにくく見える記号は、後で元の文字に戻すための境界線でもあった。

共通の材料はISO 646の各種版で変わらない83の図形文字である。二文字の名前は主にラテン文字、ギリシャ文字、キリル文字、ヘブライ文字、アラビア文字などを対象とした。日本語や中国語のような非アルファベット系には可変長の名前を使う。受信端末がその字形を表示できなくても、どの文字だったかを記録として運べるようにした。

一方、4.3.2節には見栄えを選ぶつまみがある。導入列を0に指定すると、その記号を転送せず、長い名前の下線も外す。行はすっきりする。しかし、どこが元の普通の文字列で、どこが代替表記だったかを後から見分けられない。RFC自身が情報損失と非可逆性を明言し、mnemonic+ascii+0は普通のasciiと同じだと書いた。

これは経路の故障で文字が壊れた話ではない。仕様が、読みやすさのために復元の手掛かりを捨てる選択を認めた話だ。境界つきの表記は少々うるさいが、文字の身元を残す。ゼロの表記は静かで読みやすいが、原文の区別を一部消す。後から付けた文字集合の名前で、送られなかった境界を生み直すことはできない。

RFCは漢字について、机上の万能さにも釘を刺した。中国、日本、韓国に由来する漢字のニーモニック利用は勧めていない。想定する受信側は元の符号化を扱える可能性が高く、長い代替名は読みにくいからだ。文字に名前を割り振れることと、その名前で人が読むべきことは別の判断になる。

このRFCは情報提供文書である。重要なのは、変換の費用を隠さず示した点だ。境界を残せば往復できる。ゼロにすれば今の画面は見やすいが、次の管理者へ渡す記録は薄くなる。どちらを保存したかが、将来の調査で答えられる問いを決める。

資料：RFC 1345「Character Mnemonics & Character Sets」第2節、第4.3節、RFC Editorの記録。