水準2

UTS #18 Unicode 正規表現

仕様書

[3] UTS #18Unicode正規表現仕様書です。

[4] 正規表現には各言語等でいろいろな方言が (Unicode 以前から) あります。 Unicode正規表現は、それらについて Unicode 対応のための標準仕様を定めています。 しかし既存の方言の統一を企図したものではなく Unicode 対応部分だけを規定としています。

構文

[2] UTS #18 正規表現

処理

[16] 正規表現エンジンは、 正規表現の単独で一様な解釈のために、 入力テキストに常に NFC を適用しても構わない >>15 とされています。

[17] しかしながら、 NFC は破壊的な操作で、 入力テキストを非可逆に変化させてしまいます。 Unicode正規化 しかも、 正規表現一致部分を capture して利用するようなときに、 元の入力テキストと違った部分文字列もどきが出てきても困ることが多いのではないでしょうか。 利用者 (正規表現を書く人) が明示的に要求しない限り、 実装が勝手にUnicode正規化を適用するべきとは思えません。

適合性

[8] 実装は、 Unicodeの版UTS #18 の版、 (すい) (じゅん) (Level) の組に対して適合性を主張できます。 >>7 C0

[9] Unicodeの版の改訂によって UCD が改訂されるので、 同じ正規表現でも Unicodeの版によって挙動が変わる可能性が高いです。

[10] 現行 UTS #18 には水準1 (Level 1) >>7 C1水準2 (Level 2) >>7 C1, C2 があります。 過去の UTS #18 には水準3 (Level 3) >>7 C3 がありましたが、現在は廃止されています。

[11] 部分実装も許されていますが、どの水準、どの機能に対応しているのか明確に記述することが求められています。 >>7 C4

[12] 一体となるシステムの他の構成部品と組み合わせて機能を実現すること (例えば他の機構によりUnicode正規化された結果を入力として要求すること、 追加モジュールの利用を要求することなど) も認められますが、その旨を明確に記述することが求められています。 >>7

[13] 後方互換性のために既定の状態では機能を有効にせず、何らかの設定によって有効にするような形態の実装も認められています。 >>7

[14] ただ正規表現を書いただけではバイト列モードで動作し、 特定のオプションを与えるとUnicode文字列モードに切り替わるような実装もあり得ます。

実装

[5] 現在広く使われている多くのプログラミング言語等が標準で Unicode正規表現に対応しています。 具体的にどの機能をどの程度実装しているかには違いがあります。 また、 Unicode正規表現にない独自の機能なども多々あります。 詳しくはそれぞれの項を参照。

関連

[6] EBNF

メモ