オライリーの正規表現本を書店で見たところ、Perl/Python/JavaScriptなどの 各言語での表現例がそろっていてわかりやすかった。

div の body-tab0 内は「注目情報」、div の doby-tab1内に div class="001"から div class="005"までがある。body-tab2は 「お知らせ」という文字があるが、使われていないらしいが、 よくわからない。

まず、ごみであるdiv id="00[1-5]" noneのdivブロックを削除する ことにした。また、div id="field-title"のタグを最後の 区切りになるようにした。HTMLコメント文の<!-- /Tabs -->は なぜか正規表現でひっかからなくなっていた。/ は \ で エスケープしたのだが。

  $title        =~ s/
        (について|を|の)        #
        (発表|掲載|公表)        #
        (いた)?(しました)?。?   # しました いたしました しました。
        ( \( [^)]* \) )? \s*    # 末尾の ( .... )
        $/
	/x;			# 正規表現内に空白文字を入れてよい

上の正規表現による文字列の削除で、「の発表」とか「について公表しました」 とか「を掲載いたしました。」などの文字列を削除している。

1 while $numeric =~ s/(\d)(\d\d\d)(?!\d)/$1,$2/g;

(sub, Comma, comma, perl, regex)

strfriendを作ろうとすると、正規表現がスタック型の言語に見えてくる。

最初、"strfriend" という、誰かのブックマーク名だけ見たときは、 てっきり「友達リストを一発で返すAPI」かと思った。

strfriendがイケてないのは、改行やタブ、空白文字で整形した 正規表現記述 //x に対応していないこと。

関連: 正規表現実装の 処理方式の違いを説明するアニメーション。

/(?: [^\p{Han}]+ (\p{Han}+) )+ /x

[^\p{Han}]+は、漢字ではない文字の1文字以上の羅列。 \p{Han}+は、漢字(\p{Han})の1文字以上の羅列(+)だ。 後半の(\p{Han}+)の括弧のくくりで、この範囲の 文字列を、正規表現のキャプチャ文字列として返す。 さらに大きな外側の (?: ... ) 括弧では、このカッコ内が 繰り返しパターンとして(+)照合する形になっている。 ここで、+の特徴として、最後に照合して合致した文字列だけを 返すので、最後の漢字の羅列が取り出せる。

/$\d+\.txt$/

とあるのは、正規表現の最後に /ms オプションがついていればよさそうな気もしたが、

/$\d+\.txt$/ms

やはり正規表現最初の文字が ^ でないと、マッチしない。

/^\d+\.txt$/ms

これなら、マッチする

Perlの正規表現で、/x オプションを指定すると、正規表現内の スペース、タブ、改行は無視され、自由にスペースを入れたり 改行したり、インデントして記述でき、たいへんわかりやすい。 また、# に続けてコメント文も記述でき、これまたたいへん わかりやすい正規表現コーディングが可能になる。

が、正規表現内のコメント文内に / が現れると、 文法エラーになったり、0除算例外になったりするので注意。

0除算例外になる例:

% perl -e '$a="abc";$a=~/(b) #/co
/x;'

この一文字オペレータはどこか来た道。あ、sendmail.cf か。

• ^ は文字列の先頭ではなく行頭にマッチして欲しいな

• % man perlre
  ...
  Modifiers
  ...
  m   Treat string as multiple lines.  That is, change "^" and "$" from
      matching the start or end of the string to matching the start or
      end of any line anywhere within the string.
  

UTF-8 での正規表現は日本語でもかなり自由に書けるようになった。

/ ( .+? ) ( [。？] ) /sx;

% time perl -e '
use utf8; \
use encoding "utf-8"; \
open(I,"200804file.html"); \
binmode(I, ":encoding(euc-jp)"); \
undef($/); \
<I>; \
for($n=0;$n<100000;$n++){$_ = s/a/b/isg;}'

ただの検索 /a/i; にしても、やはり長時間がかかる。

もともと UTF-8 のファイルを読み込んで、/a/i で検索すれば、 /i ありでも /i なしの 50% 増し程度の時間で完了するので、 use encoding の問題らしい。 かかる処理時間も、10万回の /a/i で 0.3秒。