Provided by: manpages-ja_0.5.0.0.20210215+dfsg-1_all bug

名前

       regex - POSIX.2 正規表現

説明

       正規表現  (Regular expression: RE) は POSIX.2 で定義されており、 二つの形式がある。新しい正規表現 (modern
       RE) と古い正規表現 (obsolete RE)  である。新しい正規表現はだいたい egrep のものと同じで、 POSIX.2  では「
       拡張」正規表現 ("extended" RE)  と呼ばれている。古い正規表現はだいたい ed(1)  のものと同じで、 POSIX.2 で
       は「基本」正規表現 ("basic" RE) である。 古い正規表現は、古いプログラムとの互換性を保つためのものである。
       これについては最後に議論する。   POSIX.2   では、正規表現の文法や記号の一部が、未定義のまま残されている。
       "(!)"  は、このような意味で、他の POSIX.2 の実装と 完全には互換でないかも知れない部分である。

       (新しい) 正規表現は一つ以上(!) の空白でない  (branch) からなる。 枝どうしは '|'  で区切られる。正規表現
       は、 枝のどれかにマッチ (match) したものにマッチする。

       枝は一つ以上の文節  (piece)  が結合されたものである。 枝は第一の文節がマッチし、 続いて第二の文節がマッチ
       し、... したものにマッチする。

       文節はアトム (atom) からなる。ただしアトムの後には一つ(!) の '*', '+', '?' あるいは 繰り返し指定  (bound)
       が続くこともある。 '*' が後置されたアトムは、マッチしたアトムの 0 個以上の並びにマッチする。 '+' が後置さ
       れたアトムは、マッチしたアトムの 1 個以上の並びにマッチする。 '?'  が後置されたアトムは、マッチしたアトム
       の 0 個または 1 個にマッチする。

       繰り返し指定とは  '{'  に続いて、符号なし  10  進整数、','、  もう一つの  10 進整数、'}' を並べたものであ
       る。',' と二つめの 10 進整数は省略できる。二つめの 10 進整数だけを省略することもできる (最後の `}' は省略
       できない)。 整数は 0 以上 RE_DUP_MAX (255(!)) 以下の間で指定できる。 二つ指定する場合には、最初の数値は後
       の数値を越えてはならない。 整数 i だけからなる繰り返し指定を後置されたアトムは、 アトムをぴったりちょうど
       i  個だけ並べたものにマッチする。  整数 i とコンマが指定された繰り返し指定を後置されたアトムは、 アトムを
       i個以上並べたものにマッチする。 整数 ij が指定された繰り返し指定を後置されたアトムは、 アトムを i個以
       上 j 個以下だけ並べたものにマッチする。

       アトムの種類は以下の通り。"()" に囲まれた正規表現 (その正規表現がマッチする文字列にマッチする)、 中身が空
       の "()" (null 文字列にマッチする)(!)、 ブラケット表現 (bracket expression :後述)、 '.' (任意の  1  文字に
       マッチする)、 '^' (行頭の空白文字にマッチする)、 '$' (行末の空白文字にマッチする)、 '\' に "^.[$()|*+?{\"
       のいずれか一文字を後置したもの (通常の文字として扱われ、その文字にマッチする)、 '\'  にそれ以外の文字を後
       置したもの(!)  ('\' がない場合と同じように、その文字にマッチする(!))、 特に意味を持たない文字一つ (その文
       字にマッチする)。 '{' は数字以外の文字が後置されると通常の文字として扱われ、 繰り返し指定の始まりとはされ
       ない(!)。'\' で終わる正規表現は不正なものとみなされる。

       ブラケット表現は "[]" によって閉じられた文字のリストである。 これは通常リスト中に存在している文字にマッチ
       する。 (例外あり、後述。) リストが '^' で始まると、  ブラケット表現はリストに存在していない文字一つにマッ
       チする  (例外あり、後述)。  リスト中の二つの文字が '-' で区切られている場合は、 これは照合順序 (collating
       sequence) でその二つの文字に挟まれる、 すべての文字の並びを短縮したものとみなされる  (両端含む)。  例えば
       "[0-9]" は ASCII では 10 進の数字 (digit) のいずれかにマッチする。 二つの領域指定が端点を共有してはならな
       い(!)。 つまり "a-c-e" のようなものは不正である。領域指定は照合順序に強く依存する。  したがって移植性の高
       いプログラムを作る場合は、  領域指定には頼らないほうが良いだろう。  【訳注: 照合順序 (collating sequence)
       というのは、国際化 (Internationalization) に関連した用語です。アルファベット順に単語を並 べる際には、言語
       によって並べる基準が異なります。照合順序は、その差異を  吸収するための仕組みです。 例えば、スペイン語では
       ch という文字並びを特別扱いするため、アルファベッ ト順が a, b, c, ch, d, e, ...  の順になるそうです。この
       ようなシーケンス  のことを collating sequence と言います。このとき `ch' という文字並びは、 単語整列の際に
       あたかも「一文字」のように扱われます。ここで、 順序付けを行う際に最小の単位となる、`a'、`b' の文字や `ch'
       のような特別な文字並びなど、照合順序の要素のことを   collating   element  と言います。collating  sequence
       は、文字単位ではなく collating element を単位として定義されます。】

       文字 ']'  そのものをリストに入れたい場合は、  最初の文字として指定すれば良い  ('^')  の後に続けるのでも良
       い)。 文字 '-' そのものをリストに入れたい場合は、 最初か最後の文字とすれば良い。 あるいは領域指定の終端文
       字として指定しても良い。 '-' を領域指定の先頭文字に指定するには、"[." と ".]"  で囲って、  照合順序の要素
       (collating element: 後述) にすれば良い。 他の特殊文字 ( も含む) は、 ブラケット表現の内部ではすべて通常の
       文字として扱われる。

       ブラケット表現の内部では、"[." と ".]" に囲われた照合順序の要素は、 その要素に対応する文字並びを表す。 「
       照合順序の要素」とは、  [1] 文字、 [2] 単一文字のように扱われる複数文字のシーケンス、 [3] 1, 2 いずれかに
       対応する照合順序上の名前、のいずれかである。 この繰り返しは、ブラケット表現のリストにおける単一の要素とな
       る。 上記 [2] の、「複数文字からなる照合順序要素」を含むブラケット表現は、 したがって一文字以上にマッチす
       ることがある。 例えば、もし照合順序が  "ch"  という要素を含んでいる場合には、  正規表現  "[[.ch.]]*c"  は
       "chchcc" の最初の 5 文字にマッチする。

       ブラケット表現の内部では、"[="  と  "=]" に囲まれた照合順序の要素は、 等価クラス (equivalence class) とな
       る。 これは、その要素と等価な要素すべてからなる文字シーケンス (自身も含む) を表す。  他に等価な要素がなけ
       れば、 取り扱いは "[." と ".]" で囲まれている場合と同じである。 例えば o と ou が等価クラスのメンバーであ
       れば、 "[[=o=]]", "[[=o^=]]", "[oo^]" はすべて同じ意味になる。 等価クラスは領域指定の端点にはなれない(!)。

       ブラケット表現の内部では、"[:" と ":]" で囲われた文字クラス (character class)  はそのクラスに属するすべて
       の文字のリストを表す。 標準で用意されている文字クラスの名前は以下の通り:

              alnum   digit   punct
              alpha   graph   space
              blank   lower   upper
              cntrl   print   xdigit

       これらは wctype(3)  で定義されている文字クラスを表している。ロケール (locale) によって、 これら以外のクラ
       スが定義されることもある。 文字クラスは領域指定の端点にはなれない。

       正規表現が、与えられた文字列の複数の部分文字列 (substring) にマッチできるような場合には、  最も先頭の近く
       から始まるものにマッチする。  その位置から始まり、正規表現がマッチできる部分文字列が複数ある場合には、 最
       長のものにマッチする。 部分正規表現 (subexpression) も最も長い部分文字列にマッチする。 ただし、全体のマッ
       チが最長であるように、という条件が優先される。 正規表現の中で先に現れる部分正規表現は、後に現れるものより
       優先される。 ただし、より高位の部分正規表現は、  それを構成する低位の部分正規表現よりも優先されることに注
       意すること。

       マッチ長は照合順序の要素ではなく、文字数を単位としてカウントされる。  null 文字列は、全くマッチしなかった
       場合よりも長いとみなされる。    例えば    "bb*"    は    "abbbc"    のまん中の    3    文字にマッチする。
       "(wee|week)(knights|nights)" は "weeknights" の全体にマッチする。 "(.*).*" を "abc" にマッチさせると、 括
       弧の内部の部分正規表現が 3 文字すべてにマッチする。 "(a*)*" を "bc" にマッチさせると、正規表現全体も、 括
       弧で括られた部分正規表現も null 文字列にマッチする。

       マッチが大文字・小文字を無視するように指定されると、 アルファベット全体から大小文字の区別が無くなったかの
       ような効果となる。 大文字・小文字を持つアルファベットがブラケット表現の外部で  通常の文字として現れると、
       これは実効的に大小両方の文字のブラケット表現のように変換される。  すなわち 'x' は "[xX]" となる。ブラケッ
       ト表現の内部に現れると、 大文字なら小文字が、小文字なら大文字がそのブラケット表現に加えられる。  すなわち
       "[x]" は "[xX]" に、"[^x]" は "[^xX]" になる。

       正規表現の長さには特に制限はない(!)。 ただし移植性を高くしたいプログラムでは、 256 バイトより長い正規表現
       は実行しないようにするほうが良い。 なぜなら、そのような正規表現を拒否し、 しかも POSIX 互換を保つような実
       装が可能だからである。

       古い  ("基本") 正規表現は、いくつかの点において異なる。 '|', '+', and '?' は通常の文字となる。 対応する機
       能は存在しない。繰り返し指定の区切りは "\{" および "\}" となる。'{' と '}' は、  単独では通常の文字として
       扱われる。  部分正規表現をネストする括弧は  "\(" および "\)" となり、 '(' と ')' は単独では通常の文字とな
       る。 '^' は正規表現の先頭か、 括弧でくくられた部分表現の先頭(!)を除いて通常の文字となる。 '$'  は正規表現
       の末尾か、  括弧でくくられた部分正規表現の末尾(!)を除いて通常の文字となる。 '*' は、正規表現の先頭か、 括
       弧でくくられた部分文字列の先頭に置かれた場合は通常の文字となる ('^') が前置されていてもよい)。

       最後に、アトムとして別のタイプが存在する。 後方参照 (back reference) である。 '\' の後に 0 でない 10 進数
       値文字 d が続くと、 括弧でくくられた部分正規表現の d 番目にマッチした文字並びと同じものにマッチする。 (部
       分正規表現の番号付けは、  開き括弧  `('   の位置が左のものから右のものへ向かってなされる。)    したがって
       "\([bc]\)\1" は "bb" または "cc" にはマッチするが、"bc" にはマッチしない。

バグ

       正規表現が 2 種類あるのは格好悪い。

       現在の POSIX.2 規格においては、')' は、 対応する '(' がない場合には通常の文字として扱われることになってい
       る。 しかしこれは、本来の意図とは異なる記述上のエラーであり、  修正される可能性が高い。これに依存したコー
       ドは使わないこと。

       後方参照はひどく出来の悪い代物である。  効率の良い実装をするのはとても難しい。 また定義があいまいである。
       ("a\(\(b\)*\2\)*d" は "abbbd" にマッチすると思うか?)  使わないほうが良い。

       POSIX.2 の規格では、case (大文字か小文字か)  に依存しないマッチの記述があいまいである。  現在のところでは
       「一つの  case がすべての case を意味する」 という上記の定義が正しい解釈であるというのが、 実装者の間での
       共通認識のようである。

著者

       このページは Henry Spencer の regex パッケージから採録したものである。

関連項目

       grep(1), regex(3)

       POSIX.2, section 2.8 (Regular Expression Notation).

この文書について

       この man ページは Linux man-pages プロジェクトのリリース 3.79 の一部 である。プロジェクトの説明とバグ報告
       に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。

                                                   2009-01-12                                           REGEX(7)