[20] [[正規表現]]における[DFN[文字クラス]]は、 複数種の[[文字]]のいずれかに[[一致]]すればよいことを表します。 [SEE[ 正規表現に限らない文字クラスについては[[文字の集合]] ]] * POSIX 式文字クラス [: ... :] [16] [CITE@ja[Lesson1 Step2 検索条件を設定しよう ~簡易表現と正規表現~ - 超漢字ウェブサイト]] ([TIME[2008-07-09 11:32:56 +09:00]] 版) >日本基本、日本補助、GT、大漢和、中国、韓国、台湾、各国、JIS第1第2、JIS第3、JIS第4が使用できます。 [26] [CITE[Character Classes]], [TIME[2005-08-24T23:33:46.000Z]], [TIME[2025-08-27T08:53:01.108Z]] [[エチオピア文字]]用[[文字クラス]] * 文字クラスの文字クラス - [1] [[正規表現]]なんかの文字クラス、こんなのは悪い例でしょう。 [SAMP(regex)[ [ぁ-ん] ]] -- [2] >>1 のような例は、特定の[[文字コード]]の文字の配列に依存してます。使う文字コードが決まってるならいいじゃないかと思うかもしれませんが、文字コードでの配列順を知らないと何を表しているのかがはっきりしないのはいただけません。 -- [3] 同様に [SAMP(regex)[ [!-~] ]] も悪い例です。 [[ASCII]] に含まれている [[SP]] 以外の[[印字可能文字]]の集合を表したいのなら面倒でも94文字列挙するべきですし、範囲 [CODE[0x21]]〜[CODE[0x7E]] を示したいなら [CODE(regex)[ [\x21-\x7E] ]] のような書き方 (が出来るなら。) をした方が意味がはっきりします。 - [4] 但し、[[用字系]]で確立した文字配列順があるなら、それを使うのもいいかとは思います。例えば [SAMP(regex)[ [A-Z] ]] や [SAMP(regex)[ [あ-ん] ]] は十分論理的です。 (但し、実際には前者は [[EBCDIC]] の場合に、後者は''ほとんど全て''の場合に、意図したようには動きません。[WEAK[[SAMP(char)[A]]〜[SAMP(char)[Z]] の間の並びにそれ以外の文字が混じっているからです。]]) -- [5] そのような場合には、処理系によっては [SAMP(regex)['''['''[:[[digit]]:]''']''']] とか [SAMP(regex)[ [[\p]]{InHiragana} ]] のような書き方が出来るかもしれません。これなら、可搬性・可読性の高い正規表現がかけます。 --- [6] >>5 しかし問題もあって、処理系によって書き方が違うこと、同じ名前でも実際の中身は異なる可能性があること、意図した集合が用意されているとは限らない [WEAK[(用字系に付属する記号類 ([[句読点]]や[[字上符]]など) の扱いとか。)]] ことなど、本当に使い物になるかは未知数です。 [WEAK[(それを言ったら [CODE(regex)[[[\s]]]] とかも同じことなんですが。)]] * 空の文字クラス [7] [[Perl]] では、 [] や [^] のような[[空]]の[[文字クラス]]はエラーになります。 [8] [[ES3]] では、空の文字クラスが認められています。 [[Firefox]]、[[Safari]]、[[Chrome]] もそれに従っているようです。 [] は何にも一致しません。 [^] はどんな文字にも一致します。 [9] [[Opera]] 9.61 ではなぜか逆になっています。 [^] は何にも一致しません。 [] はどんな文字にも一致します。 [10] [[WinIE 7]] ではエラーになります。 [11] []x] [[ES3]], [[Firefox]], [[Opera]], [[Safari]], [[Chrome]] では空の[[文字クラス]] + x + ] と解釈されるらしく、何も一致しません。 [[WinIE 7]] と [[Perl]] では ] と x が含まれる[[文字クラス]]として解釈されるようです。 * 文字クラス中のエスケープ [[エスケープ]]の項を参照。 * 文字クラス中の範囲と文字クラスを表すエスケープ [12] [[ES3]] (15.10.2.15 の定義や 15.10.2.16 の non-normative note) によれば、 [\w-\d] のように範囲の一方または両方が[[文字クラス]]を表す[[エスケープ]]の場合、 [[SyntaxError]] になるはずです。ですが、実際にはどのブラウザでも \w、文字 -、 \d のようにばらばらに処理されます。 [13] ちなみに [[Perl]] でもブラウザと同じみたいです。 [14] [\s--?] のような範囲は [[ES3]] 的には構文エラーになるはずですが、 ブラウザではどれも、 \s と - から ? までになります。 [15] [[Perl]] でもブラウザと同じみたいです。 * Unicode 文字クラス [22] [[Unicode正規表現]]には[DFN[[RUBYB[[RUBY[文][も]][RUBY[字][じ]]クラス][Character Class]]]]があります。 構文と意味が定められています。 ただし[[規定]]ではなく、既存の構文に合わせたものとして良いとされています。 [SRC[>>21]] [REFS[ - [21] [CITE@en-us[UTS #18: Unicode Regular Expressions]], [TIME[2022-02-08T14:02:12.000Z]], [TIME[2022-11-13T03:17:30.759Z]] ]REFS] * [CODE[\p]] [SEE[ [CODE[\p]] ]] * メモ [17] [CITE[Perlの正規表現のバグ? (前編) - muddy brown thang]] ( ([TIME[2011-02-20 23:38:57 +09:00]] 版)) [18] [CITE[perlre - search.cpan.org]] ([TIME[2016-04-23 01:02:26 +09:00]] 版) [19] [CITE[perlrecharclass - search.cpan.org]] ([TIME[2016-04-23 01:04:50 +09:00]] 版) - [24] [CITE[文字セット定義の記法 v1.0 - CharacterSetNotation_V10_20180323.pdf]], [TIME[2022-09-27T21:23:34.000Z]], [TIME[2022-12-02T05:14:37.048Z]] - [23] [CITE[使用文字規制の記法 v1.0 - CharacterSetRegulationNotation_V10_20180323.pdf]], [TIME[2022-09-27T21:23:35.000Z]], [TIME[2022-12-02T05:13:52.422Z]] [25] [CITE@en[GitHub - tc39/proposal-regexp-v-flag: UTS18 set notation in regular expressions]], [TIME[2023-04-28T10:00:28.000Z]]