re_syntax - Tcl正規表現の文法。
regular expression は文字の文字列を示します。
これはある文字列にマッチして、他のものにマッチしないパターンです。
- +
- ?
- {m}
- {m,}
- {m,n}
- *? +? ?? {m}? {m,}? {m,n}?
- (re)
- (?:re)
- ()
- (?:)
- [chars]
- .
- \k
- \c
- {
- x
- ^
- $
- (?=re)
- (?!re)
大括弧式
- エスケープ
- \a
- \b
- \B
- \cX
- \e
- \f
- \n
- \r
- \t
- \uwxyz
- \Ustuvwxyz
- \v
- \xhhh
- \0
- \xy
- \xyz
- \d
- \s
- \w
- \D
- \S
- \W
- \A
- \m
- \M
- \y
- \Y
- \Z
- \m
- \mnn
メタ文法
- b
- c
- e
- i
- m
- n
- p
- q
- s
- t
- w
- x
POSIXによって定義された正規表現 ( REs ) は2つの様式があります。extended
REs ( ”EREs” ) 、そしてbasic REs (” BREs” )です。EREsはおおまかにいえば伝統的なegrep
です。一方、BREsは伝統的なed です。この実装は三つ目の様式advanced
REs (” AREs” )
を追加しました。これは基本的にいくらかの有意義な拡張を持つEREsです。
このマニュアルページはAREsを主として示します。BREsは主に古いプログラムに対する下位互換性のため存在します。
それらについて後述されています。 POSIX EREsはほとんどAREsの完全なサブセットです。EREsに存在しないAREsの特徴をここで示します。
Tcl正規表現は1003.2の仕様、そして部分的な(全てではなく)Perl5拡張(ヘンリーへ感謝します)
に基づくHenry Spencerによって書かれたパッケージを用いて実装されます。以下の正規表現の記述の大部分は彼のマニュアルエントリからそのままコピーしています。
AREは’|’で分離された1つ以上のbranches であり、分枝のうちのいずれかにマッチする全部のものはマッチ結果です。
分枝は0個以上連結されたconstraints かquantified atoms です。これは一番目に対するマッチして、続いて2番目のマッチをして、以下同様です。空分枝は空文字列にマッチします。
定量化原子は1つのquanifier が続いているatom です。数量詞quanifier
ない場合、原子をマッチに使います。
数量詞また定量化原子がマッチする方法は以下です。
- *
- 0個以上の原子マッチのシーケンス。
- +
- 1個以上の原子マッチのシーケンス。
- ?
- 0 個か1個の原子マッチ。
- {m }
- ちょうどm 個の原子マッチのシーケンス。
- {m, }
- m 個以上の原子マッチのシーケンス。
- {m,n }
- m 個からn 個までの原子マッチのシーケンス。m はn
を超えることができません。
- * ?+? ??.{m}? {m,}?{m,n }?
- non-greedy
数量詞。同じ可能性をマッチをしますが、最も大きい数ではなく、最も小さい数の方を選びます(マッチングを参照して下さい)。
"{" と "}" を使用しているフォーマットはbounds
といいます。数m とn は0から255まの値を持つ符号なし10進整数です。
原子は以下のうちの1つです。
- (re)
- (re はあらゆる正規表現です ) re
のマッチにマッチして、これらのマッチ結果
が将来可能な報告のために保存されます。
- (?:re)
- 先のと同じですが、報告をしません(括弧の”non‐capturing”セット)。
- ()
- 空文字列にマッチします、これらのマッチ結果が将来可能な報告のために保存されます。
- (?:)
- 空文字列にマッチします。報告しません。
- [chars]
- chars のいずれかにマッチする大括弧式(より詳細の情報が大括弧式を参照して下さい)。
- .
- あらゆる単一の文字にマッチします。
- \k
- (k が非英文数字の文字です)
マッチする文字は普通の文字として扱われます。例えば、\\はバックスラッシュ文字にマッチします。
- \c
- c が英文数字(恐らくは他の文字を続いています)でescape
( AREsのみ ) です。下記のエスケープを参照します。
- {
- 数字以外の文字が続いていると左中括弧文字'{ 'にマッチします。数字が続いていると、それがbounds
の初まりとみなします(上を参照して下さい)。
- x
- x が他の意味がない単一の文字で、その文字にマッチします。
特定の条件が満たされるとき、constraint は空文字列にマッチします。制約には数量
詞が続いていなくても良いです。簡単な制約は次のとおりです。
より多い制約が下記のエスケープで示されます。
- ^
- 行の初めのマッチ。
- $
- 行の終りのマッチ。
- (?=re)
- positive lookahead (AREsのみ) はre にマッチするサブ文字列が始まるあらゆるポイントでマッチします。
- ( ?!re)
- negative lookahead (AREsのみ)はre にマッチしないサブ文字列が始まるあらゆるポイントにマッチします。
lookahead
制約は後への参照(後で参照)を含んではいけません。制約の中の全ての括弧は捕らられないものとみなします。
REは` \ 'で終わらなくでも良いです。
bracket expression は’[ ]’で囲まれる文字のリストです。通常これはリストからいかなる単一の文字にマッチします(
例外は下を参照)。そのリストが' ^ 'で始まればリストの文字以外のいかなる単一の文字にマッチします(例外は下を参照)。
リストの2つの文字が’-’によって分離されると、それらの2つ
(を含む)の文字の間全ての文字の完全な範囲を表す照合シーケンスとなります。例えば、ASCIIの[
0-9 ]はあらゆる10進数字にマッチします。 2つの範囲は端を共有することができないので、例えばa-c-eは違法です。
範囲は照合シーケンスに非常に依存してるので、移植意向のあるプログラムは範囲に依存することを回避するべきです。
リストに本来の文字の]、また-を使う最も簡単な方法は、[.
と .] に入れて照合要素にすることです
(下を参照して下さい)。もう1つの方法は、それを最初の文字(可能な^の後に続く)にするか、先頭に'
\ 'を付けることです(AREsのみ)。 -に対してもう1つの方法は、最後の文字にするか、範囲の2番目の端にします。リテラル-を範囲の最初の端として使うためにそれを照合要素にするか、先頭に'
\ 'を付けます(AREsのみ)。これらの例外を基づいて、[ やエスケープや他の特別
な文字の組合せ(次の段落を参照)は、大括弧式の中に位置する場合、特別な意味を失います。
大括弧式において、[ と ]で囲まれている照合要素(文字、単一の文字として扱われる多重文字、
またはこの2種類のどれかのための照合シーケンス名)は、照合要素の文字シーケンスを表します。このシーケンスは大括弧
式のリストの単一の要素です。
多重文字照合要素を持つ地域の大括弧式は1個以上の文字をマッチします。従って(だまして)、^で始まる大括弧
式は大括弧式に現れなくても、多重文字照合要素にマッチできます。
注意事項:Tclは現在に多重文字照合要素をを持っていません。この内容は説明のみです。
例えば、照合シーケンスがch多重文字照合要素を含むと仮定すると、RE
[ [ .ch.]]*c ( 0個以上のchの後にcが続く ) は` chchcc 'の最初の5文字にマッチします。同じく、RE
[ ^c]bは` chb 'の全てにマッチします([ ^c ]が多重文字chにマッチするので)。
大括弧式の中で、[= と =] で囲まれている照合要素は、自身を含んでそのものに相当する全ての照合要素の文字のシーケンスを表す同値クラスです(他の相当する照合要素がなければ、まるで’[.’と’.]’で囲まれているように扱われます)。
例えば、 oとôが同値クラスのメンバーである場合、’[[=o=]]’、’[[=ô=]
]’、そして ` [ oô ] 'は同義です。同値クラスは範囲の端に使えません。
注意事項:Tclは現在Unicode locale
のみを実装します。同値クラスを全く定義していません。上の例は単に説明のみです。
大括弧式の中で、[: と :]に囲まれるcharacter class の名前はそのクラスに属する全ての文字(必ずしも全ての照合要素ではない)のリストを表します。標準の文字クラスは以下です。
- alpha レター。upper 大文字。 lower
小文字。 digit 10進数字。 xdigit 16進数字。 alnum
英文字数字 ( レターか数字 ) 。 print 英文字数字 ( alnumと同じ
)。 blank スペースかタグ文字。 space 表示されたテキストに空白を産出する文字。
punct 句読点文字。 graph 可視な文字。 cntrl コントロール文字。
Localeは他のものを与えることができます。現在のTcl実装に、LocaleがUnicode Locale1つしかないことにご注意して下さい。
文字クラスは範囲の端として使えません。
大括弧式に2つの特別なケースがあります。 大括弧式[[:<:]]と[[:>:]]は、それぞれ単語の先頭と末尾の空文字列
にマッチする制約です。単語は、先頭にも末尾にも単語文字がない単語文字のシーケンスと、定義されます。
単語文字はalnum文字かアンダースコアです。特別な大括弧式は排除されます。
AREsのユーザーはその代りに制約エスケープを使うべきです(
下を参照して下さい)。
英文字数字に続く\で始まるエスケープ (AREsのみ)は、下記いくつかの種類があります。
文字エントリ、クラスの短縮、制約エスケープ、
そして後への参照。
正当なエスケープを構成しない英文字数字に続く\はAREsで違法とされます。EREsにエスケープがありません。
大括弧式の外では、 英文字数字の先頭にある\は、その続く文字を普通文字として扱います。
一方、大括弧式中の\は普通の文字です(後者はEREsとAREsの間の1つの実際の不一致なところです。)
。
文字エントリエスケープ ( AREsのみ ) はREsで、非印字や不便な文字を指定することをより容易にするために存在します。
- \a
- C言語と同様の警告音文字(ベル) 。
- \b
- C言語と同様のバックスペース。
- \B
- \の同義語。多重レベルのバックスラッシュ処理があるアプリケーションに2重バックスラッシュを減らすために役立ちます。
- \cX
- (Xがいかなる文字です)下位5ビットがXと同じ、かつ他のビットは全てゼロである文字。
- \e
- 照合シーケンス名が' ESC'であるか、8進値033を持つ文字。
- \f
- C言語と同様の改頁。
- \n
- C言語と同様の改行。
- \r
- C言語と同様のキャリッジリターン。
- \t
- C言語と同様の水平のタブ。
- \uwxyz
- (wxyz がちょうど4つの16進数字)ローカルなバイト順番おけるUnicode文字U+wxyz。
- \Ustuvwxyz
- (stuvwxyz がちょうど8つの16進数字)将来のためのUnicode32ビットへの拡張に用意されたもの。
- \v
- C言語と同様の垂直のタブが利用可能。
- \xhhh
- (hhh が16進数字のシーケンス) 16進値が0xhhh (
多くの16進数字が使われても1つの文字として)である文字。
- \0
- 値が0である文字。
- \ xy
- (xy がback reference ではないちょうど2つの8進数字で、)
8進値が0xyである文字。
- \xyz
- (xyz がback reference ではないちょうど3つの8進数字で、)
8進値が0xyzである文字
16進数字は'0 '- 9、'a'- 'f'、そして’A’- ’F’です。8進数字は’0’-’7’です。
文字エントリエスケープは常に普通の文字とみなされます。
例えば、\135はASCIIにおける]ですが、\135は大括弧
式を終了させません。 しかし、あるアプリケーション ( 例えば、Cコンパイラ
)
が正規表現パッケージがそれらを分析し始める前に、自分自身でこのようなシーケンスを解釈します。
それは' \ . 'の倍増 ( 4倍になること等 )
を必要とすることに注意して下さい。
クラス短縮エスケープ ( AREsのみ )
は、一般に使われた文字クラスに短縮を提供します。
- \d
- [[:digit:]]
- \s
- [[:space:]]
- \w
- [[:alnum:]_] (アンダースコアに注意)
- \D
- [^[:digit:]]
- \S
- [^[:space:]]
- \W
- [^[:alnum:]_](アンダースコアに注意)
大括弧式の中の' \d'、' \s'、そして'\w'は、外側の大括弧
を失います。'\D'、'\S'そして'\W'は認められていません(例えば、[
a-c\d ]は[ a-c[:digit:] ]と同じ、[ a-c\D ]は[ a-c^[:digit:] ]と同じく、ずべてが認められていません。)
。
制約エスケープ (AREsのみ)はエスケープと書かれて、特定の条件が満たされるならば空文字列にマッチする制限です。
- \A
- 文字列の初めのみにマッチ(これが’^’と異なる点は下記のマッチングを参照して下さい)
。
- \m
- 単語の初めのみにマッチ。
- \M
- 単語の終りのみにマッチ。
- \y
- 単語の初めか終りのみにマッチ。
- \Y
- 単語の初めと終りの以外のみにマッチ。
- \Z
- 文字列の終わりのみにマッチ(これが’^’と異なる点は下記のマッチングを参照して下さい)
。
- \m
- back reference ( m が非ゼロの数字) 。 下を参照してください。
- \mnn
- back reference ( m が非ゼロの数字で、nn
がさらに多くの数字で、そして、10進値mnn がここまで見つけた右括弧の数より大きくありません
) 。 下を参照してください。
単語は上で述べた[[:<:]]と[[:>:]]の仕様と同様に定義されます。制約エスケープは大括弧式の中で認められていません。
後への参照 ( AREsのみ )
は番号によって指定された括弧されたサブ式にマッチされる同じ文字列にマッチします。従って、(例えば、)
([bc])\1は` bc 'ではなく、bbまたはccにマッチします。、REのサブ式全体は、後へ参照より先になければなりません。サブ式は先頭にある括弧の順番によって番号をつけられます。捕らえられない括弧はサブ式を定義しません。
8進文字エントリエスケープと後ろの参照の間に固有の歴史的な曖昧性があります。先頭のゼロは常に8進エスケープを示します。別
の数字が続かない単一の非ゼロの数字は、常に後ろの参照と考えられます。
それが適当なサブ式 (すなわち、その数は後ろの参照のの正当な範囲にある
)
の後に続くと、ゼロから始まらない多桁数字のシーケンスは後ろの参照と考えられます。
そうでないと8進であると考えられます。
上で述べた主要な文法以外に、利用可能な特別なフォーマットや、種々細かな統語論のメカニズムがあります。
通常、使われるREの様式はアプリケーション依存の方法によって指定されます。しかしながら、これはdirector
にオーバライドされることがあります。’***:’で始まるあらゆる様式のREの残りは、AREです。
'***='で始まるあらゆる様式のREの残りは、普通の文字列(全ての文字が普通
の文字と見なされる)であると考えられます 。
AREはembedded options で始まることが可能です。シーケンス(?xyz)
は(xyzが1以上の英文文字です ) 、REの残りに影響を及ぼすオプションを指定します。
AREはは、アプリケーションによって指定したあらゆるオプションを補足またはオーバライドすることができます。
利用可能なオプションレターは、以下です。
- b
- REの残り部分はBREです。
- c
- 大文字か小文字かをはっきり区別するマッチング (
通常のデフォルト ) 。
- e
- REの残り部分はEREです。
- i
- 大文字か小文字かを区別しないマッチング (下記のマッチングを参照して下さい
) 。
- m
- nの歴史的な同義語。
- n
- 改行敏感なマッチング (下記のマッチングを参照して下さい
) 。
- p
- 部分的な改行敏感なマッチング (下記のマッチングを参照して下さい)
。
- q
- REの残り部分は逐語的な ( "quoted")
文字列であり、全てが普通の文字です。
- s
- 非改行敏感なマッチング( 通常のデフォルト )。
- t
- 簡潔な文法 ( 通常のデフォルト、下を参照して下さい ) 。
- w
- 逆の部分的な改行敏感な ( "weird" ) マッチング(下記のマッチングを参照して下さい)
。
- x
- 拡張した文法 ( 下を参照して下さい ) 。
埋め込まれたオプションは ) で終了するシーケンスに対して効果的です。それらはAREの開始にのみ利用可能です。AREの中では後で使えなくなります。
通常の全ての文字が有効である(tight ) RE文法に加えて、-expandedスイッチによる全てのREに対して利用可能な拡張(expanded
)文法と、埋め込まれたxオプションを持つAREsで利用可能な拡張(expanded
)文法があります。拡張された文法において、空白文字は無視されて、#と次の改行(
あるいは、REの終わり) の間の全ての文字も無視されます。複雑なREに対して段落化か注釈化させることができます。この基礎的規則には3つの例外があります。
- 空白文字や` \ 'で先行される` # 'は保持されます。
空白または大括弧式の中の`
# 'は保持されます。
AREの’(?:’またはBREの’ \ (’のような、多重文字記号の中で空白とコメントは認められません。
拡大される文法の空白文字はブランク、タブ、改行、そしてsapce
文字クラスに属するあらゆる文字です。
最終的に、AREで、大括弧式の外側の ’(?#ttt )’シーケンス (
ttt は’)’を含まないいかなる文字)
が、完全に無視されたコメントです。これも、’(?:’のような多重文字記号の文字の間では許されません。
このようなコメントは有益な機能ではなく、歴史的な名残りで、使用は薦めません。その代りに拡張された文法を使います。
アプリケーション ( あるいは***=ディレクタで始め )
がユーザーの入力がREとしてではなく、普通
の文字列として扱われることを指定した場合、これらのメタ文法の拡張のうちのどれも利用不可能になります。
REがある文字列の1つ以上のサブ文字列にマッチする場合は、REはその文字列の最も早い段階で見つかったものにマッチします。
REがスタートポイントから1つ以上のサブ文字列にマッチできる場合、結果の選択方法は優先順位
(preference)によって決定されます。
最も長いサブ文字列をマッチするか、最も短いサブ文字列をマッチするかのいずれかです。
ほとんどの原子と全ての制約は優先順位を持っていません。括弧で括られたREは、REと同じ優先順位
( 恐らくは何もない) を持っています。 数量詞{m}又は{m
}?によって数量化された原子は、原子そのものと同じ優先順位
( 恐らくは何もない ) を持ちます。他の通常な数量詞 ( mがnに等しい{m,n}
を含む)
を持つ数量化された原子は、最も長いマッチの方を好みます。他の非欲張りの数量詞
(m がnに等しい{m , n}?を含む)
を持つ定量化された原子は、最も短いマッチの方を好みます。
分枝は、その中の最初に定量化された原子と同じ優先順位(優先順位を持れば)を持っています。
"|"演算子でつながった2つ以上の分枝から成るREは、最も長いマッチの方を好みます。
全体REにマッチするルールに付けられた制約に従って、先に開始するサブ式は後で開始する式より優先にされることによって、サブ式はそれらの優先順位
に基づいて最長あるいは最短の可能なサブ文字列にマッチします。
これで外側のサブ式がコンポーネントサブ式より優先されることに注意して下さい。
また注意すべきのは、数量詞{1,1}と{1,1}?はそれぞれサブ式または全体のREに、最長と最短優先を強制するために使われる場合がある点です。
マッチの長さは照合要素単位ではなく、文字単位で測定されます。
空文字列は全くマッチしないものよりは長いと考えられます。
例えば、bb*は’abbbc’の中間の3つの文字にマッチして、(week|wee)
( night|knight) は’weeknight’の全ての10文字にマッチします。 (.*).*がabcとマッチするとき、括弧
に入れられたサブ式が全ての3文字にマッチさせます。(a*)*がbcとマッチするとき、全体REと括弧
に入れられたサブ式の両方は空文字列にマッチします。
ケース独立のマッチングが指定された場合、その効果はまるで全てのケース区別がアルファベットから消えたかのようになります。
多重ケースに存在するアルファベットが大括弧式の外側で普通の文字として現れるとき、それは双方のケースを含む大括弧
式に効果的に変換されます。 従って、xは[xX]になります。それが大括弧
式の中に現れるとき、それの全てのケース相対するもの物は大括弧式に加えられます。
従って、[x]が[xX]となり、そして[^x]が[^xX]になります。
改行敏感マッチングが指定されると、". "そして"^"を使う大括弧
式は、決して改行文字にマッチしません。 マッチするとREは改行が明確に用意しない限り、マッチが決して改行を横切らないようにします。
文字列の初めと終わりにそれぞれマッチする上に、^と$はそれぞれ改行の後と前の空文字列にマッチします。
AREの \Aと\Zは文字列の始めと終わりのみにマッチし続けます。
部分的改行敏感マッチングが指定さた場合、これは改行敏感マッチングと同じで、"
."と大括弧式に影響しますが、^と` $ 'に影響しません。
逆に、部分的な改行敏感なマッチングが指定されると、これは改行敏感マッチングと同じで^と$に影響を及ぼします。そして、"
."と大括弧式に影響しません。
これはあまり役に立ちませんが、対称のために提供されます。
REsの長さに特別な限界は付けられていません。 POSIX準拠の実装が、そのようなREsを受け入れることを拒絶できるので、高い移植性を意図しているプログラムは256バイトより長くREsを使わないほうがいいでしょう。
実際に、POSIX EREsとAREsの互換性がない唯一のところは、\が大括弧式の中で特別な意味を失わないことです。他のAREsの全ての特徴は、POSIX
EREsにおける違法か未定義か、または指定されていないとされます。
ディレクタの***文法は同様にBREsとEREsの両方に対してPOSIX文法にあっていません。
多数のARE拡張がPerlから借用されましたが、「きれい」にするためにいくつか変更が加えられ、そして少数のPerl拡張がなくなりました。
不一致のところは、` \b'、` \B'、末尾の改行の特別処置の欠乏、改行敏感なマッチングによって影響を受けたものへの補足として大括弧
式の追加、
先取り制約における括弧と後への参照に対する制限、そしてマッチする最長/最短マッチを含みます。
正常な、そして非欲張りの数量詞を含むREsに対するマッチングルールは、このパッケージの早期のベータテストバージョンより変わりました。
新しい規則ははるかに簡単で「きれい」ですが、あまりユーザーの真の意図を推測しようとしません。
広範囲で使用( 例えば、Tclの8.1リリースの前のバージョン)されているHenry
Spencerのオリジナル1986年regexpパッケージは、今のEREsより早期のバージョンを実装しました。regexpのEREs(
略してRREs )とAREsの間には、大体4つの不一致があります。簡単に意味が増える順で説明します。
- AREsにおいて、英文字数字の文字に続いている\はエスケープかエラーのいずれかです。一方、RREsにおいて、それは英文字数字を書くための別の方法でした。RREsでそのようなシーケンスを書く理由がないので、これは問題にはなりません。
AREsにおける数字が後続している"{"は、範囲の初め端です。一方、RREsにおいて、{は常に普通
の文字です。
このようなシーケンスはまれです。後続の文字は正当な範囲の端ではないので、しばしばエラーを起こします。
AREsにおいて、’[ ]’内の\は特別の文字のままです。
従って、[ ]中の本来の意味の\ は` \\ 'と書かれなければなりません。
RREsで同じく、\\は[ ]中の文字通りの\を与えます。
しかし、本当に偏執なプログラマだけが、慣例的にバックスラッシュを2重にします。
AREsは指定された検索順番に最初に発見されるものではなく、REに対する最長/最短マッチを報告します。
これは最初のマッチが報告されることを期待して書かれたRREsに影響を及ぼすでしょう。
速いマッチングのため、検索順番を最適化するのにRREsの注意深いcraftingを使うことは時代遅れです。
AREsが並列において全ての可能なマッチを検査し、パフォーマンスがそれほど大く複雑さに影響されません
。しかし、最長/最短でないマッチを慎重に発見するために、検索順番が利用された場合には(文を効率よく)書き直すことが必要です。
BREsはいくらかの点においてEREsと異なります。'|'、'+'、そして?は普通
の文字であり、それらの機能に相当するものがありません。{
と }は普通 の文字ですが、限度のデリミッターが\ { と\
}です。ネストしたサブ式の括弧 は\( と\) ですが、 (
と ) そのものは普通の文字です。^はREの初め、及び、括弧
に入れられたサブ式の初めを除いて普通の文字です。 $はREの終わり、及び、括弧
に入れられたサブ式の終わりを除いて普通の文字です。 *はREの初め、及び、括弧
に入れられたサブ式の初めに現れると普通の文字です。 最後に、1桁数字の後への参照は利用可能で、そして、\〈と\〉はそれぞれ[[:<:]]と[[:>:]]の同義語です。他のエスケープは利用不能です。
RegExp, regexp, regsub, lsearch, switch, text
match, regular expression, string
Copyright © 1998 Sun Microsystems, Inc.
Copyright © 1999 Scriptics Corporation
Copyright © 1995-1997 Roger E. Critchlow Jr.
|