要約

  • RFC 3536 は、プロトコル上の符号化オクテット、抽象文字、文字体系、言語、レンダラーが選ぶグリフを分けた。ある層の成功は、次の層の自動的な証拠ではない。
  • 2003 年の用語集は情報提供であり、非規範的かつ不完全だと明記され、2011 年に RFC 6365 によって廃止された。それでも、見た目の妥当性は描画の受領証にすぎないという教訓は残る。

海外から届いた顧客名が、業務端末に崩れず表示されたとする。四角い代替文字もなく、行の高さも揃っている。担当者は「文字化けなし」と判定する。しかし同じ見た目は、誤った charset が偶然似た形を出した場合にも、未記録の正規化やフォント代替を経た場合にも成立し得る。端末が証明したのは、描ける形を一つ見つけたことだけである。

RFC 3536 は 2003 年 5 月に Terminology Used in Internationalization in the IETF として公開された。符号化方式を定める規格ではなく、相互運用プロファイルでもない。似た言葉が違う対象に使われる技術議論を整理するための Informational な用語集だった。本文は、定義が規範ではなく、一覧も完全ではなく、とくに「言語」について意見の不一致があると明記する。凍結した RFC Editor の errata ページに項目はないが、それは用語体系の完全性を保証しない。

通信路が運ぶのはビットとオクテットである。charset はオクテットを抽象文字へ対応づける規則で、RFC 3536 は符号化文字集合と文字符号化方式の組として説明し、IANA 登録名で識別する。RFC 3629 の UTF-8 も、この復号問題への答えである。charset の名前だけでは、得られた文が日本語か、英語か、別の言語かは決まらない。正しい文法や意味も保証しない。

文字とグリフにも断絶がある。文字は名前と属性によって識別される抽象的な要素であり、固定された絵ではない。グリフはフォント、文脈、組版規則を使って選ばれた描画形である。一つの文字に複数のグリフがあり、異なる文字列が同じように見える場合もある。人が「正しく見える」と言えても、その像から入力オクテット列を一意に逆算することはできない。

文字体系と自然言語も一対一ではない。一つの文字体系を複数の言語が使い、一つの言語が複数の文字体系で書かれることもある。script の判定は字形選択に役立つが、言語名の代わりにはならない。RFC 3066、そして後継の RFC 5646 は言語タグを別のメタデータとして定義した。正しい構文のタグであっても、推測や誤分類の可能性は残り、文章の自然さや読者の理解を証明しない。

RFC 2277 は目的を人に置いていた。プロトコルそのものが自然言語を話すのではなく、そこで運ばれる文字列を人が使う。したがって、非 ASCII のオクテットを受理できるだけでは国際化は完了しない。入力、保存、比較、検索、並べ替え、視覚・聴覚・触覚による提示、そして利用者が行動できることまで、別々の遷移が続く。

正規化は、外見による判定の弱さを明らかにする。Unicode では異なるコードポイント列が正準等価になり得る。Unicode Standard Annex #15 が正規化形式を定め、RFC 5198 はネットワーク交換向けの準備形式を後に示した。RFC 3536 の重要な要求は、どこで正規化するかをプロトコルが示すことだった。入口、保存、照合で勝手に処理すれば、同じ見た目の文字列が別キーになったり、別記録が証跡なしに統合されたりする。

この論点は既存の RFC 5137 記事とは重ならない。そちらは Unicode エスケープからコードポイント、正規化識別子、アカウントの曖昧性を扱う。本稿はもっと手前から続く表現の連鎖、すなわちオクテットが文字になり、文字体系と言語文脈を得て、グリフへ描画されるまでを扱う。識別子政策はその応用の一つにすぎない。

照合順序も別の層である。人が期待する並びは言語と慣習に依存し、コードポイントの数値順とは通常一致しない。同じ文字体系を使う共同体でも、辞書順が異なることがある。データベースが決定的な順で正常終了しても、読者には間違った索引となり得る。「sort 成功」は、選んだ collation の妥当性を証明しない。

双方向テキストではメモリ順と表示順が分かれる。スクリーンショットだけでは元の順序を復元できず、カーソル移動、コピー、音声読み上げで隠れていた構造が現れることがある。また RFC 3536 の rendering は視覚だけでなく、音声と触覚も含む。画面が自然でも、読み上げが誤り、点字出力が使えない可能性は残る。

歴史上の権威も区別しなければならない。RFC 3536 は Internet Standard ではなかった。2011 年 9 月、IETF の合意と公開レビューを経た RFC 6365 が BCP 166 として発行され、RFC 3536 を明示的に Obsoletes とした。さらに RFC 7997 は RFC 文書内の非 ASCII 文字の扱いを変えた。後の改善を、2003 年の全定義の遡及的な規範化として扱ってはならない。

RFC 3536 の Security Considerations は、セキュリティを論じないとだけ述べる。現在知られている符号化、方向制御、紛らわしい表示のリスクを分析することはできるが、それを当時の用語集が完成した脅威モデルとして提示したとは言えない。確実に言えるのは、データ、文字、言語、表示を一つの状態へ潰すと監査能力が失われることだ。

必要な証拠列は、受信オクテットと charset、復号結果、文字列検証、正規化形式と実行点、言語タグと来歴、文字体系と方向の区間、シェーピングエンジン、指定フォントと代替フォント、視覚・聴覚・触覚出力、照合規則、対象読者による理解確認である。光るグリフが閉じるのは、その中の一つだけだ。

情報源