要約

  • RFC 2152は+で、=パディングを省いたModified Base64へのシフトを開始し、上位バイト優先の16ビットUnicode量を運んだ。シフトはBase64外の文字で終わり、改行をまたぐことはできなかった。
  • Set Oの記号は、ゲートウェイで壊れる可能性を承知で直接送ることも、シフト内に置くこともできた。同じ復号結果は、元のUTF-7バイト、行構造、通過経路、著者の意図が同じだとは示さない。

古いメールを移行するとき、最初に目に入るのは残った文字である。英数字が読め、UTF-7の断片もエラーなく展開できれば、作業は成功したように見える。しかし元のメッセージを派生Unicodeテキストで置き換えた瞬間、どの記号が直接表現され、どの改行が中継で作り直され、どのバイトを送信者が署名したのかは分からなくなる。

David GoldsmithとMark DavisによるRFC 2152は1997年5月、RFC 1642を置き換えるInformational文書として発行された。Internet Standardではない。対象は7ビットUS-ASCIIを前提とするメールだった。UTF-8にMIME転送符号化を重ねれば非ASCII文が大きく膨らむ。UTF-7はASCIIオクテットだけを出力し、ASCII中心の部分を古い機器にも読める形で残した。

RFC自身が用途を狭くした。通常はメールのような7ビット経路だけで使い、それ以外では直接UnicodeかUTF-8を選ぶべきだとした。

直接表現にも危険度の差があった

Set Dは英字、数字、九つの記号からなり、+と=を除外した。Set Oの記号も任意に直接表現できたが、ヘッダーでは違法になり得るものや、ある種のゲートウェイを正しく通らないものがあると明記された。バックスラッシュとチルダはASCII変種で再定義されることが多いため外された。

付録Aは同じ中国語テキストを二通り示す。Set Oを直接使う版は読みやすいが、一部のゲートウェイを通らない可能性がある。もう一版はその選択を避ける。見えることと残ることが別問題だと、例そのものが語っている。

プラス記号が状態を切り替えた

+の後は、RFC 2045のBase64文字集合から=を除いたSet Bとして解釈された。Set B外の文字でシフトは終了する。終端がなら吸収され、+-はリテラルのプラスを表す。+直後がSet Bでもでもなければ不正列である。

内部では16ビットUnicode量を上位オクテットから直列化し、UTF-16サロゲートペアの各半分も別々の16ビット量として扱った。復号後のオクテット数が奇数なら不正で、Base64境界まで補った末尾ビットはゼロでなければならない。

この文法は厳密に検査できる。しかし出所は認証しない。RFCのHi Mom +Jjo-!は入力が完全なら笑顔を戻すが、最初のエンコーダーがどの合法表現を選び、途中の装置が何を変更し、著者がどの字形を見たかは答えない。

行末は状態境界だった

シフト列は行末で必ず終わり、改行を越えられない。そのため先に行分割してからUTF-7化するか、両者を同時に行う。符号化後に長すぎる場合は、途中で勝手に折るのではなく、適切なMIME content-transfer encodingを使う。

RFCは短いSMTP行とCRLFも勧め、古い環境での可読性のためU+2028とU+2029をメールの改行へ変換する案を示した。これは相互運用として正しくても、原文字列やバイトの保存とは両立しない場合がある。

復号は複数の履歴を一つに畳む

Rule 2は任意のUnicode列をシフトでき、Rule 1とRule 3は一部を直接表現できる。異なるUTF-7バイト列が同じUnicode列になるのは、この重なりから導ける。復号器が経路の選択を捨てても、文字処理としては仕様どおりである。

したがって受け入れ証跡を分ける。生オブジェクトのハッシュと行末、厳密なUTF-7構文判定、復号したコード単位、クライアント表示である。署名、訴訟、事故調査が目的なら、変換前の原物を残さなければならない。

IANAはUTF-7、MIBenum 1012、csUTF7を今も登録している。これは名称の証拠であり、導入率や安全性の証拠ではない。UTF-7-IMAPはIMAPメールボックス名だけに用いる別の符号化で、外部利用を避けるよう明記される。MIME本文と同一視できない。

RFC 2152のSecurity Considerationsは問題を論じていない。後年のUnicode文書はコンポーネント間の比較・変換差を警告するが、UTR 36は現在、保守されない安定化文書で一部勧告に後継があると注記される。1997年の沈黙を安全証明に変えることも、後年の警告を製品測定に変えることもできない。

検証済みerrataは二件ある。値96の文字をgrave accentへ直すものと、シフト列が「行末」で終わる文の欠語を補うものだ。別の一件は棄却されている。件数より状態が重要である。

Heng Luの最小仕様の考え方で見れば、UTF-7は共通層を七ビット搬送に必要な決定規則へ絞った。Running-Code Primacyは実際のゲートウェイ出力を求め、Reality Layersはcharsetラベルや可読面を実行済みの保存結果と取り違えないよう求める。

出典