要約

  • RFC 3454 は写像、正規化、禁止、双方向検査の順を固定したが、利用する各プロトコルが profile と文字集合を選ぶ必要があった。
  • 準備後の出力が等しいとは、その profile と Unicode 版の下で等しいという意味に限られ、綴り、見た目、意図、アカウント支配、権限、身元を証明しない。

比較できることと、誰かを知ること

Unicode によって ASCII の外側を扱えるようになった一方、見た目が同じ文字列でもコードポイント列、大小文字、互換文字、不可視の印が異なる場合があった。2002年12月の RFC 3454 は、保存や比較の前に文字列を準備する stringprep を定めた。

目標は、二人が同じと考える文字列を入力したとき、文字単位で一致する可能性を高めることだった。世界中の言語の別綴りを同値にするとは約束していない。テキスト、RFC Editor 記録、Datatracker、履歴、参照文献、後続参照、正誤表は標準の来歴を示すが、入力者の意図やアカウントの所有者は示さない。

実際の方針は profile にあった

Stringprep は単独の規則ではない。利用プロトコルが、用途、レパートリー、写像表、正規化、禁止出力、双方向検査、追加制限を profile として定める。同じ入力でも異なる profile なら異なる結果が正当だった。

写像は文字を消し、一つを別の一つへ置換し、一つを複数へ展開できた。写像で生まれた文字は同じ段階では再走査されない。正規化を選ぶ場合は NFKC が必須であり、その仕組みは Unicode Standard Annex #15 にある。多くの表現が収束しても、全フォントで同じ外観、全言語で同じ意味になるわけではない。

順序そのものが実行契約だった

写像、正規化、禁止、bidi 検査は順番どおりに実行しなければならない。順序を変えれば結果も変わり得る。禁止段階は文字列かエラーのどちらかだけを返した。制御文字、私用領域、非文字、サロゲート、タグ文字などを profile が排除できた。

Bidi 規則は右から左へ書く文字を含む文字列の両端と方向クラスを制約した。これは識別子の表示安定性を守る規則であり、入力者の認証ではない。Unicode Technical Report #36 が後に整理した視覚的混同も、正規化だけでは消えない。外観が似ることも、出力が等しいことも、所有者が同じ証拠にはならない。

Unicode の版も証拠だった

RFC 3454 は Unicode 3.2 の表を固定し、将来版へ自動適用してはならないとした。再現性は得られたが、「有効だった」という記録には profile と表の版が不可欠になった。

未割当コードポイントは版差を露呈した。保存文字列では禁止されたが、照会では新しいクライアントと古い保存系を接続するため許容できた。同じ入力が作成時には失敗し、検索時には通ることがあり得る。操作種別も判定の一部だった。

最終出力だけを保存すれば、原入力、版、各変換、保存か照会かの区別が失われる。更新後の違いを、利用者の変更とソフトウェアの変更に分けられなくなる。

Nameprep は価値と更新負債を示した

RFC 3491 は初期 IDNA の profile として Nameprep を定め、RFC 3490 が処理へ組み込んだ。RFC 4690 は後の課題を記録し、RFC 5890 の IDNA2008 は stringprep を使わなかった。

比較が不要になったのではなく、固定版と profile の更新が難しかった。RFC 6885 が PRECIS の問題を示し、RFC 7564 が RFC 3454 を廃止し、RFC 8264 が最初の PRECIS を置き換えた。標準の継承は修正を示すが、既存識別子の意味が一斉に変わった証拠ではない。

Heng Lu の現実レイヤーに従えば、入力、profile、表、各段階、出力またはエラー、比較、アカウント結合、権限は別々の記録である。稼働コード優先は、プログラムが自分の計算を証明しても所有者を任命できないことを示す。最小初期仕様は、汎用枠組みが身元と権限を利用側へ残した節度を説明する。これは後世の編集上の読み方である。

RFC 3454 の教訓は、正規化が弱いことではない。明示した境界内でだけ強いということだ。決定的な比較は、身元確認ではない。

出典