特性データモデル [15]
Unicode正規表現 における特性 は、
[16] その域domain (定義域 ) がUnicode符号点 のもの、
文字列 のものがあります。
>>12 [17] その余域codomain (値域 ) が
二値Binary ,
列挙Enumerated ,
数値Numeric ,
符号点Code Point ,
文字列String 、
それらの集合Set や並びList のものがあります。
>>12 [98]
絵文字 系の特性 や
\p{Named_Sequence}
などいくつかの特性 は、域 が符号点 でなく文字列 です。
つまり \p が1つの文字 ではなく複数の文字列 に一致 する可能性があります。
[18]
この値域のデータ型 は基本的には UCD の特性値 のものに近いのですが、
少し違うので要注意です。
[19]
二値型は、列挙型の特殊形で、 True と False の2つの値があります。
>>12 UCD の二値特性 の特性値 では他にも多くの別名 があります。
[20]
列挙型は、 UCD の列挙型の他に、型録型にも対応 >>12 UCD では列挙型の値は固定的、型録型の値は将来追加される可能性がある、
という違いがあります。)
[21]
符号点型は、文字列型の特殊形で、常に1つの符号点 となります。
>>12
[22]
集合 型は、一般に含むか含まないかの検査がなされます。
>>12
[23]
並び 型は、含むか含まないかの検査をすることもありますが、
順序が意味を持つ場合があることに要注意とされています。
>>12
[50]
値の一致 判定においては、一般に UAX #44 の別名 の一致の規則が適用されます。
(>>33 , >>38 )
特性 によっては更に別の規定もあります。
General_Category , 文字の名前
特性の名前と値 [33]
UCD の特性 の名前と値は、
UCD のデータファイルに別名 として示されたもので、
省略名と長い名前を使うことが推奨されています。
両方の名前を認識すること、
UAX #44 の一致の規則に従うことが強く推奨されています。
>>12 >>38 )
[34] 別名 は、省略名と長い名前の他にその他の別名 が存在することもあります。
それらにも対応するべきなのかどうかは言及されていません。
区別なくすべての別名 に対応するのが無難と思われます。[35]
特性指定 において、
二値型の特性は名前だけを指定できます。
それ以外の特性は名前と値の両方が必要です。
>>12
[47]
あまり明確には示されていませんが、名前だけが指定されると =True
の省略が想定されるようです。また、二値型だからといって省略しなければならないということでもなさそうです。
[36]
例外的に、
General_Category
と
Script
は、
名前と関係 を省略して値だけを指定できます。
>>12
[80]
Perl 5.26 から、
Script のかわりに Script_Extensions
が値だけで指定できるように非互換変更 されました。
Script_Extensions
[38]
UCD特性 の特性 や特性値 の別名 の一致 については、 UAX #44 の規定によります。
>>12 RL1.2
[49]
二値型の時、値の別名 も認められるべきなのかどうか明瞭ではありません。
Perl はすべて認めているようです >>68 [48]
ただし is の無視については実装してなくても構いません。
>>12 RL1.2
[43] 之は既存の実装が is の有無を区別することが多いためです。
>>12 [81]
Perl は、 Perl 5.6 との後方互換性 のため、
compound form でなくても書ける特性 は先頭に Is Is_
があってもよいこととされています。 >>79
[82]
Perl でいう compound form とは名前と値を指定する形式のことです。
ところが \p{IsScript:Arabic} は \p{Arabic}
と等しいとも例示されています。 >>79
[83]
UCD の規定はこれを更に単純化したものになっています。
いっそその方が実装しやすそうです。
[85]
Perl では、
Block
も名前と関係 を省略して値だけを指定できます。
更に、先頭に
In や Is
を付けることができます。
ただし、
他と衝突するものは除外されています。
>>84
[86]
これは Perl 独自のものです。
いくつかは現に衝突して使えません。
将来の Unicode 側の新規追加で更に使えないものが増える
(プログラム を書く側から見れば非互換変更 される)
可能性があり、
新しいコードでは避けるべきとされています >>84 [96]
XML Schema の正規表現 では Is + ブロック名 の二値型の特性が提案されていました。
>>2
[2] Unicode block names for use in XSD regular expressions
( (2011-06-14 05:49:35 +09:00 版))
http://www.w3.org/TR/2011/NOTE-xsd-unicode-blocknames-20110609/
[42]
UCD の別名 以外に独自の別名 を追加しても構いません。
>>12
[40]
正規表現 の実装が対応している従来の特性 の名前との後方互換性 のため、
Unicode正規表現 本来の特性 の名前のかわりに、
Alphabetic
を
Unicode_Alphabetic
とするなど、
名前を変更することが認められています。
>>12 , >>61
[41] これら多くのバリエーションが認められている上、
対応しているUnicodeの版 によっても結果が変わってきます。
同じように見える正規表現 でも、
ある実装が対応しているかどうかだけではなく、
どのように対応しているかもチェックしないといけません。[37]
Unicode正規表現 の水準1では、数個の UCD特性 への対応が要求されます。
>>12 RL1.2
[62]
Unicode正規表現 の水準2では、加えて多数の UCD特性 や関連規格の特性 への対応が要求されます。
>>61 RL2.7
[39]
Unicode正規表現 の水準1では、数個の互換性特性への対応が要求されます。
>>12 RL1.2a, >>67 >>12 RL1.2a
[44]
General_Category に属する特殊な名前として、
Any,
Assigned,
ASCII
があります。
General_Category
[64]
その他いくつかの UCD特性 や関連規格の特性 へも対応して構わないとされます。
>>63
[66]
同じ構文で Unicode 以外の特性 を実装することも特に禁止されていないようです。
ただし将来の Unicode の拡張と衝突するリスクは伴います。
[88]
Perl は Unicode にない独自のものを多数提供しています >>87
[1]
Perl 5.8.4には \p{Compat}
がありましたが、 5.8.7 ではなくなっているみたいです。
(名無しさん 2006-01-29 13:18:12 +00:00 )
[93]
Perl では利用者 (プログラム の開発者) が二値特性を定義できます。
Is や In で始まる名前を使いますが、
パッケージ名 で修飾できるので
Foo ::InBar >>3
[55]
関係 は明確に定められていませんが、
= であれば指定された特性値 と一致 すること、
≠ や != であれば指定された特性値 と一致 しないことが求められるようです。
[72]
Perl では = のかわりに : も使えます。 >>68
[56]
特性値 は水準1では値そのものの指定だけですが、
水準2ではワイルドカード に対応しなければなりません。
>>51 RL2.6
[57]
ワイルドカード としては、
特性値 の条件を記述する正規表現 を与えるか、
特性値 と一致するべき特性 の名前を与えることができます。
>>51
[90]
Perl では正規表現 として記述できるものは、通常の
Perl の正規表現 よりかなり制限されています。
>>89
[58]
特性値 を正規表現 によって判断する場合、
大文字と小文字 の区別等の無視 (>>38 )
はなされません。
>>51
[91]
Perl では大文字と小文字 の区別が行われません (/i 相当)。
正規表現 内で (?-i) を明示的に指定すれば区別されるようになります。
ただし \p{name}
では区別されます。
>>89
[92]
Perl では一部の特性 は正規表現 一致を指定できません。
>>89
[59]
特性値 を特性 との一致によって判断する場合、
特性 の名前として
identitiy>>51
[60]
\p {toLowercase≠@identity@}小文字 が元の符号点 と等しくないことを意味します。
>>51
[65] identity は \p {identity =x >>63 [45]
なお、実装は名前と値の組という概念を実装することも厳密には要求されていません。
同等の機能があれば足ります。
具体的には、
\p{script=latin} の意味で \p{script_latin}、
\p{Block=Greek} の意味で \p{Greek Block}
のようにも表現し得ることが例示されています。
[46] 相互運用性 の低下やプログラマー の混乱の元ですから、
あまり無闇矢鱈に一般的な構文から離れるのも如何かと思いますが。。。