要約

  • RFC 9839 は Unicode Scalars、XML Characters、Unicode Assignables という、段階的に狭くなる三つの集合を定義した。
  • 正しい JSON 文書でも、エスケープの解読後には制御コード、単独サロゲート、非文字が現れ得る。パース成功は UTF-8 出力や用途上の適格性を証明しない。
  • 運用上の統制はフィールドごとの集合、拒否か置換かの明示、そして入口から下流まで同じ試験ベクトルが同じ結果を出すことにある。

緑色の「成功」は範囲を明示しなければ危険である。JSON ライブラリがオブジェクトを返したとき、証明されたのは括弧、引用符、エスケープの構文だった。そこに NUL や単独サロゲートが含まれていないこと、識別子として安全であることまでは証明されていない。

RFC 9839 は 2025 年 8 月に Standards Track として公開された。公式記録、テキスト、XML は同じ三つの再利用可能な境界を示す。標準化は実装率や製品の適合性を示すものではない。

一つの「Unicode 対応」では足りない

Unicode Scalars は U+D800〜U+DFFF の 2,048 個のサロゲートを除くが、従来型制御コードと非文字は残す。XML Characters は有用な三つを除く C0 制御の大半と U+FFFE、U+FFFF も除く。Unicode Assignables はサロゲート、従来型制御、すべての非文字を除き、現在または将来割り当て可能なコードポイントを残す。

Unicode 標準はコード空間を定義し、UAX 44 は属性を説明する。RFC 3629 は UTF-8、RFC 2277 はインターネットプロトコルの文字集合方針を定める。しかし符号化方式は、許された値をバイトにする方法であって、顧客 ID や署名対象に何を許すかではない。

ABNF で集合を示す意義は、曖昧な「有効な Unicode」を実装者ごとの判断にしない点にある。XML 1.0 の Char 規則も一つの既知プロファイルであり、完全な文字安全策ではない。

エスケープは許可証にならない

RFC 8259 とその記録は JSON を規定する。RFC 9839 の例は、構文上適合しながら、解読後に NUL、C1 制御、単独サロゲート、非文字を含む。その値は整形式 UTF-8 にできず、ライブラリ間で処理が割れる可能性がある。

エスケープ表記は内容を変更しない。検査位置はエスケープ解読後、権威ある状態への保存前である。汎用パーサーには、そのフィールドが表示用か、アクセス制御か、署名か、監査証拠かを決める権限がない。

I-JSON、Net-Unicode、PRECIS は用途別プロファイルの必要性を示す。Unicode Assignables だけでは正規化、類似文字、双方向表示、文脈規則を解決しない。

拒否と置換は別の資産を守る

拒否は曖昧な値を権威ある記録に入れない。U+FFFD への置換は画面表示を継続し、破損を可視化できる一方、原値の同一性を失う。署名、ハッシュ、重複排除キー、権限比較、法的記録では重大な変更である。

無言の削除はさらに悪い。異なる入力が同じ値になり、受信記録と保存記録が一致しなくなる。RFC 9413 が示す堅牢性は、無効入力への明示的な応答であって、無条件受理ではない。

拒否にも可用性設計が要る。高価な診断を繰り返せば攻撃面になる。レート制限、短いエラー、隔離、原証拠の保持は運用者が決める。

証跡は処理系全体を通過する

共通ベクトルをゲートウェイ、パーサー、検証器、キュー、DB ドライバー、保存層、ログ、エクスポート、消費側へ流す。構文失敗、集合違反、意図的置換、後段の直列化失敗を分離し、スカラー列、判断、エラー種別、保存値を照合する。

CBOR のテキストは既定で Unicode スカラー値を使うためサロゲートを除くが、すべての制御や非文字は除かない。コンテナ変更だけでフィールド方針は完成しない。

TR36 は Unicode セキュリティ、TR55 はソースコード、W3C は文字、コードポイント、コード単位、バイトを整理する。RFC 9839 はそれらすべてを解くのではなく、交換不能な値を排除する最小境界を与える。

本稿は製品、データベース、実運用経路を試験しておらず、採用率も示さない。結論は限定的である。パーサーは構文を調整するが、内容を承認しない。実行中の全境界が同じ判断を示して初めて、受け入れの証拠になる。

情報源