CentOS7

一覧

CentOS7

REGEX(7)                                    Linux Programmer's Manual                                   REGEX(7)



名前

       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個以上並べたものにマッチする。

       整数     i     と     j     が指定された繰り返し指定を後置されたアトムは、     アトムを     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^]"     はすべて同じ意味になる。

       等価クラスは領域指定の端点にはなれない(!)。



       ブラケット表現の内部では、"[:"      と      ":]"       で囲われた文字クラス       (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.51      の一部

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



                                                   2009-01-12                                           REGEX(7)

 Manual page regex(7) line 106/163 (END) (press h for help or q to quit)

REGEX(3)                                    Linux Programmer's Manual                                   REGEX(3)



名前

       regcomp, regexec, regerror, regfree - POSIX regex 関数



書式

       #include <sys/types.h>

       #include <regex.h>



       int regcomp(regex_t *preg, const char *regex, int cflags);



       int regexec(const regex_t *preg, const char *string, size_t nmatch,

                   regmatch_t pmatch[], int eflags);



       size_t regerror(int errcode, const regex_t *preg, char *errbuf,

                       size_t errbuf_size);



       void regfree(regex_t *preg);



説明

   POSIX regex コンパイル

       regcomp()  は、正規表現をコンパイルして、 regexec()  での検索処理に適合する形態にする。



       regcomp()     はパターンを記憶するバッファへのポインタ    preg、    ヌル文字で終端された文字列    regex、

       そしてコンパイルの形式を決めるためのフラグ cflag を引数に伴う。



       全ての正規表現検索は、コンパイルされたパターンによって行わなければならない。      よって、      regexec()

       に指定するのは、必ず                         (regcomp()                         によってコンパイルされた)

       パターンバッファへのアドレスでなければならない。



       cflags には以下に示す定数一つ以上のビットごとの OR (bitwise-or) を指定する。



       REG_EXTENDED

              regex     に      POSIX      拡張正規表現を使用する。もしこのフラグが設定されない場合、      POSIX

              標準正規表現が使われる。



       REG_ICASE

              大文字小文字の違いを無視する。このフラグを指定してコンパイルされた        パターンバッファを用いて

              regexec() 関数を呼び出すと、大文字小文字の区別を付けずに検索が行われる。



       REG_NOSUB

              マッチの場所を報告しない。渡されたパターンバッファがこのフラグを設定してコンパイルされていた場合、

              regexec() の引き数 nmatch, pmatch が無視される。



       REG_NEWLINE

              全ての文字にマッチするオペレータに改行をマッチさせない。



              改行を含まない非マッチング文字リスト ([^...])  に改行をマッチさせない。



              regexec()             の実行時に指定するフラグ            eflags           に           REG_NOTBOL

              を含むかどうかにかかわらず、行頭にマッチするオペレータ (^)  を改行直後の空文字列にマッチさせる。



              eflags     に      REG_NOTEOL      を含むかどうかにかかわらず、行末にマッチするオペレータ      ($)

              を改行直前の空文字列にマッチさせる。



   POSIX regex マッチング

       regexec()   は、  プリコンパイルされたパターンバッファ  preg をヌル文字で終端された文字列にマッチさせる。

       nmatch と  pmatch  はマッチングの位置に関する情報を取得するのに用いられる。  eflags  には  REG_NOTBOL  と

       REG_NOTEOL               のどちらか、もしくは両方のビットごとの              OR              (bitwise-or)

       を指定し、以下で説明するようにマッチング動作を変化させる。



       REG_NOTBOL

              行頭にマッチするオペレータは、必ずマッチに失敗する        (コンパイル時のフラグ        REG_NEWLINE

              の項目も参照)。                  このフラグは、複数行にまたがる文字列を                  regexec()

              で検索する際に、文字列の先頭を行の先頭として解釈させない場合に用いる。



       REG_NOTEOL

              行末にマッチするオペレータは、必ずマッチに失敗する        (コンパイル時のフラグ        REG_NEWLINE

              の項目も参照)。



   バイトオフセット

       パターンバッファのコンパイル時に  REG_NOSUB  が設定されない場合は、マッチング位置情報を得ることができる。

       pmatch      は、少なくとも      nmatch       の大きさを持つように指定しなければならない。       regexec()

       の実行によって、それらに部分文字列マッチング位置情報が代入される。                                      i

       番目の括弧で始まる部分正規表現のオフセットは    pmatch[i]    に格納される。正規表現全体のマッチアドレスは

       pmatch[0]  に格納される。  (N  個の部分正規表現のマッチのオフセットを返すためには、  nmatch  は最低限 N+1

       でなければならない点に注意すること。) 未使用の構造体要素には -1 が値として代入される。



       pmatch の型である regmatch_t 構造体は、 <regex.h> 内で定義される。



           typedef struct {

               regoff_t rm_so;

               regoff_t rm_eo;

           } regmatch_t;



       構造体要素     rm_so     の値が      -1      でない場合、それは文字列内での次の最大のマッチング部分の開始

       オフセット位置を示す。それに対し、構造体要素      rm_eo      はマッチング部分の終了オフセット位置を示し、

       マッチング部分の直後の文字のオフセット位置が使用される。



   POSIX エラーレポート

       regerror()  は、 regcomp()  と regexec() の実行によって得られるエラーコードから、エラーメッセージ文字列を

       得るのに用いられる。



       regerror()    はエラーコード   errcode、   パターンバッファ  preg、  文字列バッファへのポインタ  errbuf、

       文字列バッファのサイズ                             errbuf_size                             を引数にとる。

       この関数は、ヌル文字で終端されたエラーメッセージ文字列を格納するのに必要な   errbuf  のサイズを返す。もし

       errbuf   と   errbuf_size   の両方が非   0   値であれば、   errbuf    には最初の    errbuf_size    -    1

       文字分にエラーメッセージと終端の NULL バイト ('\0')  が収まるように代入される。



   POSIX パターンバッファ解放

       引数にコンパイルされたパターンバッファ     preg     を与えて    regfree()     を呼び出すと、    regcomp()

       によるコンパイル時にパターンバッファに割り当てられたメモリが解放される。



返り値

       regcomp()  は、コンパイルの成功時には 0 を返し、失敗時にはエラーコードを返す。



       regexec()  は、マッチングの成功時には 0 を返し、失敗時には REG_NOMATCH を返す。



エラー

       regcomp()  は以下のエラーを返す。



       REG_BADBR

              無効な後方参照オペレータの使用。



       REG_BADPAT

              グループやリストなどの、パターンオペレータの無効な使用。



       REG_BADRPT

              '*' が最初の文字としてくるような、無効な繰り返しオペレータの使用。



       REG_EBRACE

              インターバルオペレータ {} (brace interval operators) が閉じていない。



       REG_EBRACK

              リストオペレータ [] (bracket list operators) が閉じていない。



       REG_ECOLLATE

              照合順序の要素 (collating element) として有効ではない。 (訳注) 詳細は regex(7)  を参照。



       REG_ECTYPE

              未知のキャラクタクラス名。



       REG_EEND

              未定義エラー。これは POSIX.2 には定義されていない。



       REG_EESCAPE

              正規表現がバックスラッシュで終っている。



       REG_EPAREN

              グループオペレータ () (parenthesis group operators) が閉じていない。



       REG_ERANGE

              無効な範囲オペレータの使用。 例えば、範囲の終了位置が開始位置よりも前にあるような場合。



       REG_ESIZE

              正規表現のコンパイルに、64Kb 以上のパターンバッファが必要。 これは POSIX.2 には定義されていない。



       REG_ESPACE

              regex ルーチンがメモリを使いはたしている。



       REG_ESUBREG

              サブエクスプレッション \(...\)  (subexpression) への無効な後方参照。



準拠

       POSIX.1-2001.



関連項目

       grep(1), regex(7)

       glibc マニュアルのセクション Regular Expression Matching



この文書について

       この      man      ページは      Linux      man-pages      プロジェクトのリリース       3.51       の一部

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



GNU                                                2013-02-11                                           REGEX(3)

 Manual page regex(3) line 130/169 (END) (press h for help or q to quit)