- RFC 9839 は、ソフトウェア開発時にテキストフィールドへ含まれうる 問題のあるUnicode文字 を明確に定義している
- このRFCは、異なる言語やライブラリ 間でそれらの文字の処理に一貫性が欠けることによって生じる問題を扱っている
- 9839では、比較的問題の少ない 3つのサブセット を提案しており、選択的に活用できる
- 既存の PRECISフレームワーク と比べて、適用がより容易でシンプルである
- RFC 9839向けの Go言語ライブラリ もあわせて公開され、実運用での活用に役立つ
背景とRFC 9839の概要
- Unicodeは、ほぼあらゆるテキストデータ処理で標準として使われている
- しかし実際のデータ構造やプロトコル設計で、すべてのUnicode文字を許可すると問題が発生する
- Paul Hoffman と筆者は、繰り返し起こるUnicodeの問題に対する明確な基準を示すため、IETFへの個人草案 を提出した
- 2年間の議論を経て正式な標準として採択され、RFC 9839として公開された
- この文書は、問題のある文字の種類、なぜ問題になるのか（技術的・標準的理由）、そして利用者が選べる3つのサブセットを詳しく説明している
RFC 9839の主な内容
- ソフトウェアやネットワーク環境で テキストフィールド を設計する際に、必ず参照すべき文書である
- RFC 9839は 10ページ構成 で、IETF標準文書としては簡潔な部類に入る
- 主にソフトウェア開発者とネットワークエンジニアを対象に、わかりやすく説明されている
問題のあるUnicode文字の例
JSONの設計と限界
- これはJSONの作者である Doug Crockford の責任ではない
- Unicodeが十分に成熟していない時期に設計されたため、文字集合を厳密に制限できなかった
- 今では標準そのものを変更できないため、問題文字を経験的に除外する方法 が必要になる
IETFのPRECISフレームワークとの違い
- 2025年のRFC 9839以前にも、IETFでは RFC 8264（PRECIS Framework） などさまざまな標準が提供されていた
- このフレームワークは、国際化文字列の整形・適用・比較方法を詳しく扱っている
- 43ページ構成で、背景説明と解決策が包括的 である
- PRECISはUnicodeバージョンへの依存が強く、複雑で適用しにくいという欠点がある
- RFC 9839 は簡潔で実用性を重視しており、新しいプロトコル定義時に 迅速に採用しやすい
RFC 9839のサブセットと活用例
- 9839は、現実的な3つのサブセット（scalars、XML、assignables）を提示している
- 各サブセットは、除外する問題文字の範囲が少しずつ異なる
- 以下は、主要なデータフォーマットとRFC 9839のサブセットが問題文字をどう処理するかの表の要約である
- CBOR、TOML、XML、YAML など一部のフォーマットは、サロゲートや制御文字を部分的に除外している
- I-JSON はサロゲートとnoncharacterを除外する
- 一般的なJSON、Protobufs は除外しない
- XML、YAML は文字セットの特性上、noncharacterや制御コードを部分的にしか除外しない
- 参考: XMLとYAMLは、Basic Multilingual Plane以外のnoncharacterは除外しない
Go言語向けRFC 9839ライブラリ
- RFC 9839の3つのサブセットに対する 文字検証 をサポートする小さなGoライブラリが公開された
- 十分にテストされているが、最適化はまだ進行中である
- 実際の現場でのテストとフィードバックが歓迎されている
RFC 9839の意義と作業過程
- RFC 9839は、共著者たちとの度重なるフィードバックを経て、15回以上の草案修正の後に正式公開された
- 多くのコミュニティ専門家による議論と貢献を通じて、初期案よりはるかに完成度の高い文書 へと発展した
- 「Acknowledgements」セクションに貢献者が記載されている
RFC個人提出の経験
- RFC 9839は 個人提出（individual submission） として進められた
- Working Groupを通す従来方式よりも、労力と手続きの負担 が大きい
- Working Groupへの参加経験と比べると、従来方式のほうが効率的で勧めやすい
まだコメントはありません。