RFC 1456：六つの制御コードが文字になった

要約

RFC 1456 は ASCII にないベトナム語の文字・ダイアクリティカルマーク結合を 134 と数え、印字可能な ASCII をすべて残す代わりに六つの大文字を C0 制御位置へ置く VISCII を記録した。
VIQR は七ビット経路向けに、括弧や疑問符などを記憶しやすい発音記号として用いたため、同じ記号が句読点か文字の一部かは文脈とエスケープ状態で決まった。
MIME の charset は読む規則を指示できても、バイトの適合、変換器、フォント、往復可能性、利用者が見た結果までは証明しなかった。

VIQR の発想は、すべての機械に同じ表示能力を要求しないことだった。左括弧は breve、キャレットは circumflex、プラス記号は horn を連想させる。アポストロフィ、バッククォート、疑問符、チルダ、ピリオドは声調を表し、dd と DD は横棒付き D を表した。

七ビットのメールやニュースを通る間、これらは印字可能な ASCII のままでいられた。専用表示がなくても人は記憶表記を読める。対応ソフトがあれば、同じキー列からベトナム語の字形を得られる。

しかし疑問符には疑問符の仕事がある。RFC 1456 は “How are you?” を例に、意図しない合成を防ぐ仕組みが必要だと示した。完全なエスケープ規則は別文書に委ねられているため、RFC の短い説明だけで細部を補ってはならない。

見た目の記号は、自分の役割を宣言しない。VIQR を選んだという情報、文字列内の位置、解析状態がそろって初めて発音記号になる。人が読めるフォールバックも構文解析を不要にはしなかった。

VISCII は別の制約を扱った。ベトナム語はラテン文字を使うが、ASCII 既存字母に加えて 134 の文字・記号結合が必要だと文書は説明する。しかも日常的に頻出するため、たまに compose キーを押す設計では負担が大きい。

基底文字と結合記号を分ければ位置数は節約できる。ところが 1993 年当時の多くのプラットフォームは、その方式を既存アプリケーションに統合しにくかった。VISCII は各ベトナム語文字を一単位にして、古い一文字一バイトの処理へ合わせた。

その代わり、256 個の表を再配分しなければならない。VISCII は印字可能な ASCII を全部残した。既存のコマンド、ファイル、句読点、英語用アプリケーションを壊さないためである。最後の六つの大文字は、比較的使用頻度が低いとして、問題が少ないと判断された六つの C0 制御位置に入った。

同じ低い値は ASCII なら制御、VISCII なら文字になる。経路上の端末ドライバが先に反応すれば、デコーダへ届かないこともある。バイトが残ってもフォントがなければ表示されない。VISCII は制御と文字が同じだと主張したのではなく、どの互換性費用を負うかを明記した。

RFC 1456 は Unix、MS-DOS、Windows、メール、ニュース、印刷、データベースなどで利用するソフトを報告し、Plan 9 の tcs に ISO 10646/Unicode 1.1 との変換があったと述べた。この記録は重要だ。仕様だけでなく、実行可能な道具があった。

一方、それは全利用者の採用調査でも全変換の検証でもない。製品名が出たからといって、すべての版が同じ表を使い、全データが往復できたとは言えない。実装報告と普遍的な互換性は別の命題である。

既存設備は、どの設計が現実的かを決める権力を持っていた。ASCII の印字領域を守れば道具を再利用できる。だが C0 を文字にした負債は、変換と保存の境界に残る。古いバイトを「制御文字だから」と清掃する処理は、VISCII 文書では文字を削除する。

RFC 1456 は MIME 用の名前として VISCII と VIQR を示し、本文に適切な charset を付けるよう求めた。ただし MIME 対応ソフトすべてに実装を義務づけたわけではない。

ラベルは送信者が意図した表を示す。内容検査はしない。VISCII と書かれた本文が壊れている場合も、受信側が名前だけ知って変換器を持たない場合もある。正しくデコードしても、フォント不足で字形が出ないことがある。

後の MIME 規則では、charset のない plain text は US-ASCII とされ、明示が推奨された。VISCII のラベル喪失は、六文字を制御へ戻しかねない。VIQR は肉眼で残っても、検索や再変換が異なる可能性がある。

IANA の現行 Character Sets レジストリには VISCII と VIQR が残り、MIBenum は 2082 と 2083、別名は csVISCII と csVIQR である。これは公開識別子の継続を示すだけで、現在の利用量や実装品質を示さない。

UTF-8 は US-ASCII の値をそのまま保ち、それ以外を可変長列で表す。世界の文字を一つの 256 枠へ押し込む必要はなくなった。だが新しい規則は古いファイルの読み方を自動発見しない。

VISCII は元の表で一度解釈し、VIQR は文脈構文を実行してから、Unicode の文字列へ移す必要がある。古いバイトに UTF-8 を直接適用するのは変換ではなく誤読である。

画面が正しそうでも、正規化やコードポイント列が変われば、検索、識別子、署名は一致しない。共通レパートリは広がったが、バイトから意味への証拠境界は残った。

必要な連鎖は次の通りである。

言語上の文字 → 表現方式 → バイト列 → charset → 解析状態 → コードポイント → 字形 → 読者

ハッシュはバイトを固定するが charset を決めない。charset はデコーダを選ぶが実装を保証しない。スクリーンショットは字形を示すが可逆変換を証明しない。読めたという証言は、検索や署名が同じ列を使った証拠ではない。

公開情報は RFC 1456 の情報ページによる。134 の結合、VISCII、VIQR、実装報告、安全性の扱いは RFC 1456 本文による。同時代の MIME 枠組みは RFC 1341、後の charset 規則は RFC 2046に基づく。UTF-8 の比較は RFC 3629、識別子は IANA Character Setsで確認した。記録と実行結果を分ける解釈は Lu Heng の Running Code Is Primary と Reality Layersを明示的な論拠とする。

これらは普遍的採用、現在の普及、完全な変換、特定事故、Unicode への直接因果を証明しない。RFC 1456 自身もセキュリティ問題を論じていない。