要約

  • RFC 2044 では ASCII の 00〜7F がその文字だけに使われ、先頭オクテットが長さを示し、後続は 10 で始まり、FE と FF は現れない。旧来のソフトウェアは ASCII 構文と文字境界を局所的に確認できた。
  • UCS-4 の数値辞書順が保存されても文化的には有効でないと RFC 自身が述べ、安全性は扱っていない。MIME の UTF-8 ラベルは方式の宣言であり、正規化、描画、本人性や安全性の証明ではない。

古いパーサは日本語を読めなくても、スラッシュ、改行、パーセント記号、NUL の役割を知っていた。多バイト文字の途中に同じ ASCII 値が潜めば、そのパーサはデータを命令として読むおそれがある。RFC 2044 の中心は、この既存資産との境界を壊さないことだった。

Unicode 1.1 と ISO/IEC 10646 は大きな文字空間を示したが、UCS-2 や UCS-4 の固定幅表現を七・八ビット前提のプログラムへそのまま持ち込むのは難しかった。UTF-8 は文字の知識を旧ソフトに与える代わりに、旧ソフトが頼る ASCII のバイト文法を保存した。

バイト列自身が役割を示す

ASCII 範囲は 0xxxxxxx の一オクテットで、元の値を保つ。それ以外の文字では、先頭オクテットに並ぶ 1 の数が全長を告げ、その後に 0 が来る。継続オクテットは必ず 10xxxxxx で始まる。

この差によって、途中から読み始めた走査器も継続バイトを飛ばし、次の先頭へ戻れる。RFC の「境界を容易に見つけられる」という性質は、別のフレーミング情報を要求しない局所的な回復可能性である。FE と FF が現れないことも同じ文法から得られる負の条件だ。

ただし、境界が分かることと、列全体が正当であることは別である。宣言された長さ、継続形、復元される値、現行規格の範囲を検査しなければならない。

文字コード順は日本語の並べ方ではない

RFC 2044 は UTF-8 の辞書順が UCS-4 の辞書順を保つと記した。バイト索引には便利である。しかし同じ箇条書きで、それは文化的に妥当な順序ではないため関心が限定的だと明記した。

読み手のための照合順序には、言語、濁点、長音、大小文字、合字、スクリプトや製品方針が関わる。数値順は再現可能な機械手順であって、普遍的な五十音順でもアルファベット順でもない。UTF-8 の整然とした並びを文化的権威へ変換してはいけない。

ラベルはデコーダーを選ぶだけである

RFC 2044 は MIME charset 値として UTF-8 を提案した。MIME は媒体へ文字セット名を付ける場所を作り、以前の Unicode/MIME 文書は文字集合、オクテット化、転送符号化を別々の選択として扱っていた。

ラベルは受信側へ「この方式で解釈せよ」と伝える。切断された列、違法な形、配送途中の改変を検査せず、送信者も認証しない。IANA の現行登録に UTF-8、MIBenum 106、別名 csUTF8 があり RFC 3629 を参照している事実も、名称の現在位置を示すだけだ。

六オクテットの歴史と四オクテットの現在

RFC 2044 は Informational であり、Internet Standard ではないと自ら述べる。Datatracker でも Legacy とされ、RFC 2279、さらに RFC 3629 に置き換えられた。

1996 年版は一〜六オクテットを定義した。現行の RFC 3629 は U+10FFFF まで、一〜四オクテットに限定し、サロゲートと過長形式を禁止する。古い表に合う五・六オクテット列は歴史資料にはなっても、現行 UTF-8 として受理できない。RFC 2044 に登録済み erratum が見つからないことも、この更新関係を消さない。

安全性と正規化は別の契約である

RFC 2044 の Security Considerations は、安全問題を論じないとだけ記す。RFC 3629 は後に違法列、過長符号化、バッファー想定、見かけ上同じでも異なる文字列が検査へ与える危険を扱った。RFC 5198 は NFC 正規化をさらに別のネットワーク文字規則として置く。

したがって、ASCII 値が多バイト文字に潜まないことは安全なパーサを証明せず、正しい UTF-8 は正規化済みを意味せず、有効なコードポイントは正しい字形や本人性を保証しない。

Heng Lu の最小初期仕様という見方では、RFC 2044 の共通層は必要最小限の決定的バイト規則だった。Running-Code Primacy は実装と運用観測を追加で要求し、Reality Layers は文書やラベルを、実際の表示・理解・行為へ飛躍させない。

この RFC の教訓は「テキストが解決した」ではない。意味を支配せずに構文を保存したことだ。狭い約束だったからこそ、移行の力になった。

情報源