我爱正则表达式 » 翻译 http://iregex.org 原创、翻译、转载关于正则表达式的文章 Fri, 30 Mar 2012 12:50:01 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 PHP中的递归正则 http://iregex.org/blog/recursive-regex-in-php.html http://iregex.org/blog/recursive-regex-in-php.html#comments Mon, 10 May 2010 04:57:28 +0000 rex http://iregex.org/?p=84 之前一篇文章翻译了Perl语言中的递归正则表达式. 其实不少语言中的正则都是支持递归的, 例如本文要介绍的PHP正则递归. 虽然, 工作中最常用的正则表达式都很”正则”, 只用最基本的语法就能解决85%以上的问题, 而且合理有效地使用普通正则来解决复杂问题也是一门技巧与学问; 但是高级一点的语法的确有它存的价值, 有时不用它还真办不了事儿; 况且学习正则的乐趣也在于尝试各种各样的可能性, 满足自己无穷无尽的好奇心.

本文内容, 整理自网文Finer points of PHP regular expressions. 其分析过程剥茧抽丝, 丝丝入扣, 值得一读. 该文系统地列出了PHP中正则表达式常见特性, 我只摘取其中递归部分翻译整理出来.

正文

例子

什么时候会用到递归正则表达式呢? 当然是待匹配的字串中递归地出现某种模式时(貌似废话). 最经典的例子, 就是递归正则处理嵌套括号的问题了. 例子如下.

假设你的文本中包含了正确配对的嵌套括号. 括号的深度可以是无限层. 你想捕获这样的括号组.

恕我剧透, 标准答案是这样的:

1
2
3
4
5
6
7
<?php
$string = "some text (a(b(c)d)e) more text";
if(preg_match("/\(([^()]+|(?R))*\)/",$string,$matches))
{
    echo "<pre>"; print_r($matches); echo "</pre>";
}
?>

其输出结果是:

1
2
3
4
5
Array
(
    [0] => (a(b(c)d)e)
    [1] => e    
)

可见, 我们所需要的文本, 已经捕获到$matches[0]中了.

原理

现在思考原理.

上面的正则表达式中的关键点是(?R). (?R)的作用就是递归地替换它所在的整条正则表达式. 在每次迭代时, PHP 语法分析器都会将(?R)替换为”\(([^()]+|(?R))*\)“.

因此, 具体到上述的例子, 其正则表达式等价于:

"/\(([^()]+|\(([^()]+|\(([^()]+)*\))*\))*\)/"

但是上面的代码只适合深度为3层的括号. 对于未知深度的括号嵌套, 就只好使用这种正则了:

"/\(([^()]+|(?R))*\)/"

它不但能够匹配无限深度, 还简化了正则表达式的语法. 功能强大, 语法简洁.

现在来细看一下"/\(([^()]+|(?R))*\)/"是怎样匹配"(a(b(c)d)e)"的:

  1. "(c)"这部分被正则式 "\(([^()]+)*\)" 匹配. 请注意, (c) 其实就相当于整个递归的一个缩影, 麻雀虽小五脏俱全, 因此它用到了整个正则表达式.
    换言之, 下一步中的(c), 可以使用(?R) 来匹配.
  2. (b(c)d)的匹配过程为:
    1. "\("匹配"(";
    2. "[^()]+"匹配"b";
    3.  (?R)匹配"(c)";
    4. "[^()]+"匹配"d";
    5. "\)"匹配")".

根据上面的匹配原理, 不难理解为什么数组的第2个元素$matches[1]与'e'等价. 子串'e'是在最后一次匹配迭代中被捕获. 匹配过程中, 只有最后一次的捕获结果才会保存到数组中.

rex注: 关于这个特性, 可以自行尝试一下, 看看使用正则式([a-z]+[0-9]+)+来匹配字串abc123xyz890, 其捕获结果$1是什么. 注意, 其结果与 Left Longest 原理并不冲突.

如果我们只需要捕获 $matches[0], 可以这样做:

1
2
3
4
5
6
7
<?php
    $string = "some text (a(b(c)d)e) more text";
    if(preg_match("/\((?:[^()]+|(?R))*\)/",$string,$matches))
    {
        echo "<pre>"; print_r($matches); echo "</pre>";
    }
?>

产生的结果相同:

1
2
3
4
Array
    (
     [0] => (a(b(c)d)e)
    )

所做的改动是捕获括号()改为非捕获捕获括号(?:)了.

还可以进一步完善为:

1
2
3
4
5
6
7
<?php
    $string = "some text (a(b(c)d)e) more text";
    if(preg_match("/\((?>[^()]+|(?R))*\)/",$string,$matches))
    {
        echo "<pre>"; print_r($matches); echo "</pre>";
    }
?>

这里我们用到了所谓的一次性模式(rex注: 余晟先生译的《精通正则表达式v3.0》中, 谓之”固化分组”. 可参考该书.) PHP手册也推荐只要条件允许, 就尽可能使用这种模式, 以便提升正则表达式的速度.

一次性模式很简单, 这里不再详述. 如果感兴趣, 可以参考PHP 官方手册. 如果您想深入学习PERL兼容式正则表达式, 请参考文末链接.

提到的链接

]]> http://iregex.org/blog/recursive-regex-in-php.html/feed 13 [译]递归正则表达式 http://iregex.org/blog/recursive-regular-expressions.html http://iregex.org/blog/recursive-regular-expressions.html#comments Wed, 16 Dec 2009 15:06:47 +0000 rex http://iregex.org/?p=73

原文在此。rex译于2009年12月15～17日，翻译过程中使用的是google docs@prism@firefox@ubuntu 9.10，很爽的体验。感谢余晟老师在正则和翻译方面的悉心指导。

递归正则表达式

平时我们用到的正则表达式，其实没那么“规则”。多数编程语言所支持的扩展的正则表达式，其运算能力比起形式语言理论所定义的“规则”正则表达式要强得多。

rex注：在这里其实可以看到，如果将正则表达式译为正规表达式，一切就都通顺了：
平时我们用到的正规表达式，其实没那么“正规”。多数编程语言所支持的扩展的正规表达式，其运算能力比起正式语言理论所定义的“正规”正规表达式要强得多。

regular expression的日文是“正规表现”，在鸟哥书中，好像也将其称为正规表达式。via

例如，经常用到的捕获缓存，就是用来帮助我们临时存储任意正则表达式模式，以便重复使用。 又如，“环视断言”能让正则表达式引擎在做决定之前先偷偷看看环视一下。这些扩展让正则表达式非常强大，足以描述一些“上下文无关语法”。

Perl语言的正则表达式引擎特性异常丰富，其特征之一是懒惰正则子表达式（Lazy regular subexpressions），格式为(??{code})，其中的“code”可以是任意一段perl程序，该子表达式可能匹配时，这段程序就会执行。

我们可以利用这一特征来编写出非常有趣的东西，即将正则表达式自身嵌在它的“code”部分，由此生成递归的正则表达式(a recursive regular expression)！

一直以来，正则表达式无法匹配0n1n这种表达式，也就是由若干个0以及同等数量的1所组成的字符串。如果使用懒惰正则子表达式，这一经典问题就迎刃而解。

下面是匹配0n1n字串的perl正则表达式代码。

1
$regex = qr/0(??{$regex})?1/;

rex注：紫龙书第四章有云：“文法是比正则表达式表达能力更强的表示方法。每个可以使用正则表达式描述的构造，都可以使用文法来描述，但是反之不成立。换句话说，每个正则语言都是一个上下文无关语言，但是反之不成立。”书中交待的正则，也应该是指的常规正则表达式，而非现代语言中的扩展的正则表达式。一般使用正则表达式来构造小部件，而使用文法来组建语言框架。

此正则表达式匹配一个字符0，之后是正则表达式自身0或1次，之后是字符1。如果正则表达式自身部分不能匹配，那么它只能匹配01；如果自身部分可以匹配，则正则表达式匹配的是00($regex)?11，此时若不能匹配自身则结果是0011，若可以匹配就是000($regex)?111，……依次顺延。

下面是匹配050000150000的Perl程序：

1
2
3
4
5
6
7
8
9
10
11
#!/usr/bin/perl                                                                                                                        

$str = "0"x50000 . "1"x50000;
$regex = qr/0(??{$regex})*1/;

if ($str =~ /^$regex$/) {
  print "yes, it matches";
}
else {
  print "no, it doesn't match";
}

现在来看题图所示的Yo Dawg正则表达式。你先猜猜它的作用？正确答案是，它匹配(foo(bar())baz)这样完全嵌套的括号表达式（fully parenthesized expression）或((()()())())这样的平衡括号表达式（balanced parentheses）。

1
2
3
4
5
6
7
8
9
$regex = qr/
  \(                 # (1) match an open paren (                               #(1)，此处匹配开括号
    (                # followed by                                                      #(2)，紧接着是
      [^()]+       #   (3) one or more non-paren character            #(3)，1个或多个非括号字符
    |               # OR                                                                    #(4)，或
      (??{$regex})   #   (5) the regex itself                                   #(5)，正则式自身
    )*              # (6) repeated zero or more times                     #(6)，重复0或多次
  \)                 # (7) followed by a close paren )                         #(7)，紧接着是闭括号
/x;

rex注：关于Yo Dawg图片的含义，可以参考这里。基本上是全是“Yo dawg, I herd you like X, so we put a Y in your Y so you can Z while you Z”的结构的配图文字。

构造此正则表达式的思路是这样的。对于完全嵌套的括号表达式，它的开始字符是一个开括号。这是最简单的一步，我们直接写出（上面程序中的(1)）。同理，它的结束字符是闭括号，于是得到(7)。现在该动脑筋了，括号中间是什么呢？对，它可以是既不是开括号又不是闭括号的任意字符（第(3)点），也可以是另一个完全嵌套的表达式（即第(5)点）。所有的这些，既可以只匹配0次（第(3)点），以便构造最小的完全嵌套括号表达式()，也可以匹配多次来匹配较复杂的表达式。

去掉 /x 选项（即，不再使用多行风格的注释模式），可以简记为：

1
$regex = qr/\(([^()]+|(??{$regex}))*\)/;

但是切勿在正式产品中使用这一特性，它太诡异，不好把握。建议使用较稳定成熟的Text::Balanced 或 Regexp::Common 模块。

rex注：对于(??{code})，perl官方的提示是：此正则表达式仅作测试使用，可能有更新而不作提示。代码执行时产生的副作用，因版本而异，运行结果或有不同，取决于正则引擎的后期优化。

最后提醒大家，在Perl 5.10中已经可以使用递归捕获缓存来替代懒惰代码子表达式了，运行结果相同。

下面是匹配0n1n的递归捕获缓存语法(?N)的实现：

1
my $rx = qr/(0(?1)*1)/;

(?1)*的含义是“匹配第一组0或多次”，这里的第一组是指整个正则表达式。

请自行动手，重写平衡括号的正则表达式，当作练习。

祝玩得开心！

]]> http://iregex.org/blog/recursive-regular-expressions.html/feed 11 链接：正则表达式术语表 http://iregex.org/blog/url-for-regex-terms.html http://iregex.org/blog/url-for-regex-terms.html#comments Sat, 19 Sep 2009 09:42:53 +0000 rex http://iregex.org/?p=66 8月份回家度假期间，整理了一下余晟老师译的《精通正则表达式》一书中的部分术语，以google docs形式贴出，这里给出链接。

]]> http://iregex.org/blog/url-for-regex-terms.html/feed 1 [转]正则表达式高级技巧基本概念实例详解[译] http://iregex.org/blog/crucial-concepts-behind-advanced-regular-expressions.html http://iregex.org/blog/crucial-concepts-behind-advanced-regular-expressions.html#comments Tue, 02 Jun 2009 01:03:26 +0000 rex http://iregex.org/?p=61

rex按：本文转自笨人干笨活的文章：正则表达式高级技巧基本概念实例详解[译]，其RSS在这里：http://blog.benhuoer.com/subscribe/。

英文原文来自Smashing Magazine。由笨活儿翻译。转载请注明出处。

正则表达式(Regular Expression, abbr. regex) 功能强大，能够用于在一大串字符里找到所需信息。它利用约定俗成的字符结构表达式来发生作用。不幸的是，简单的正则表达式对于一些高级运用，功能远远不够。若要进行筛选的结构比较复杂，你可能就需要用到高级正则表达式。

本文为您介绍正则表达式的高级技巧。我们筛选出了八个常用的概念，并配上实例解析，每个例子都是满足某种复杂要求的简单写法。如果你对正则的基本概念尚缺乏了解，请先阅读这篇文章，或者这个教程，或者维基条目。

这里的正则语法适用于PHP，与Perl兼容。

1. 贪婪/懒惰

Greed

所有能多次限定的正则运算符都是贪婪的。他们尽可能多地匹配目标字符串，也就是说匹配结果会尽可能地长。不幸的是，这种做法并不总是我们想要的。因此，我们添加“懒惰”限定符来解决问题。在各个贪婪运算符后添加“?”能让表达式只匹配尽可能短的长度。另外，修改器“U”也能惰化能多次限定的运算符。理解贪婪与懒惰的区别是运用高级正则表达式的基础。

贪婪操作符

操作符 * 匹配之前的表达式零次或零次以上。它是一个贪婪操作符。请看下面的例子：

1
2
preg_match( '/&lt;h1&gt;.*&lt;\/h1&gt;/', '&lt;h1&gt;这是一个标题。&lt;/h1&gt;
&lt;h1&gt;这是另一个。&lt;/h1&gt;', $matches );

句点(.)能代表除换行符外的任意字符。上面的正则表达式匹配 h1 标签以及标签内的所有内容。它用句点(.)和星号(*)来匹配标签内的所有内容。匹配结果如下：

1
&lt;h1&gt;这是一个标题。&lt;/h1&gt;&lt;h1&gt;这是另一个。&lt;/h1&gt;

整个字串都被返回。* 操作符会连续匹配所有内容—— 甚至包括中间的 h1 闭合标签。因为它是贪婪的，匹配整个字串是符合其利益最大化原则。

懒惰操作符

把上面的式子稍作修改，加上一个问号(?)，能让表达式变懒惰：

1
/&lt;h1&gt;.*?&lt;\/h1&gt;/

这样它会觉得，只需匹配到第一个 h1 结尾标签就完成任务了。

另一个有着类似属性的贪婪操作符是 {n,} 。它代表之前的匹配模式重复n次或n次以上，如果没有加上问号，它会寻找尽可能多的重复次数，加上的话，则会尽可能少重复（当然也就是“重复n次”最少）。

1
2
3
4
5
6
# 建立字串
$str = 'hihihi oops hi';
# 使用贪婪的{n,}操作符进行匹配
preg_match( '/(hi){2,}/', $str, $matches );  # matches[0] 将是 'hihihi'
# 使用堕化了的 {n,}? 操作符匹配
preg_match( '/(hi){2,}?/', $str, $matches );  # matches[0] 将是 'hihi'

2. 回返引用(Back referencing)

Back Referencing

有什么用？

回返引用(Back referencing)一般被翻译成“反向引用”、“后向引用”、“向后引用”，个人觉得“回返引用”更为贴切[笨活儿]。它是在正则表达式内部引用之前捕获到的内容的方法。例如，下面这个简单例子的目的是匹配出引号内部的内容：

1
2
3
4
5
6
7
8
9
10
11
# 建立匹配数组
$matches = array();
 
# 建立字串
$str = &quot;&quot;This is a 'string'&quot;&quot;;
 
# 用正则表达式捕捉内容
preg_match( &quot;/(\&quot;|').*?(\&quot;|')/&quot;, $str, $matches );
 
# 输出整个匹配字串
echo  $matches[0];

它会输出：

1
&quot;This is a'

显然，这并不是我们想要的内容。

这个表达式从开头的双引号开始匹配，遭遇单引号之后就错误地结束了匹配。这是因为表达式里说：

1
("|')

，也就是双引号（

1
"

）和单引号（

1
'

）均可。要修正这个问题，你可以用到回返引用。表达式\1,\2,…,\9 是对前面已捕获到的各个子内容的编组序号，能作为对这些编组的“指针”而被引用。在此例中，第一个被匹配的引号就由

1
\1

代表。

如何运用？

将上面的例子中，后面的闭合引号替换为1：

1
preg_match( '/(\&quot;|').*?\1/', $str, $matches );

这会正确地返回字串：

1
&quot;This is a 'string'&quot;

译注思考题：

如果是中文引号，前引号和后引号不是同一个字符，怎么办？

还记得PHP函数

1
preg_replace

吗？其中也有回返引用。只不过我们没有用 \1 … \9，而是用了 $1 … $9 … $n （此处任意数目均可）作为回返指针。例如，如果你想把所有的段落标签

1
&lt;p&gt;

都替换成文本：

1
2
$text = preg_replace( '/&lt;p&gt;(.*?)&lt;/p&gt;/',
&quot;&amp;lt;p&amp;gt;$1&amp;lt;/p&amp;gt;&quot;, $html );

参数$1是一个回返引用，代表段落标签

1
&lt;p&gt;

内部的文字，并插入到替换后的文本里。这种简便易用的表达式写法为我们提供了一个获取已匹配文字的简单方法，甚至在替换文本时也能使用。

3. 已命名捕获组(Named Groups)

当在一个表达式内多次用到回调引用时，很容易就把事情搞混淆，要弄清那些数字（1 … 9）都代表哪一个子内容是件很麻烦的事。回调引用的一个替代方法是使用带名字的捕获组（下文简称“有名组”）。有名组使用

1
(?P&lt;name&gt;pattern)

来设定，name代表组名，pattern是配合该有名组的正则结构。请看下面的例子：

1
/(?P&lt;quote&gt;&quot;|').*?(?P=quote)/

上式中，quote就是组名，

1
"|'

是改组匹配内容的正则。后面的(?P=quote)是在调用组名为quote的有名组。这个式子的效果和上面的回调引用实例一样，只不过是用了有名组来实现。是不是更加易读易懂了？

有名组也能用于处理已匹配内容之数组的内部数据。赋予特定正则的组名也能作为所匹配到的内容在数组内部的索引词。

1
2
3
4
5
6
7
preg_match( '/(?P&lt;quote&gt;&quot;|\')/', &quot;'String'&quot;, $matches );
 
# 下面的语句输出“'”(不包括双引号)
echo $matches[1];
 
# 使用组名调用，也会输出“'”
echo $matches['quote'];

所以，有名组并不只是让写代码更容易，它也能用于组织代码。

4. 字词边界(Word Boundaries)

Word Boundaries

字词边界是字串里的字词字符（包括字母、数字和下划线，自然也包括汉字）和非字词字符之间的位置。其特殊之处就在于，它并不匹配某个实在的字符。它的长度是零。

1
\b

匹配所有字词边界。

不幸的是，字词边界一般都被忽视掉了，大部分人都没有在意他的现实意义。 例如，如果你想要匹配单词“import”：

1
/import/

注意了！正则表达式有时候很调皮的。下面的字串也能和上面的式子匹配成功：

1
important

你或许觉得，只要在import前后加上空格，不就可以匹配这个独立的单词了：

1
/ import /

那如果遇上这种情况呢：

1
The trader voted for the import

当 import 这个词在字串开头或者结尾时，修改后的表达式仍然不能用。因此，考虑各种情况是必须的：

1
/(^import | import | import$)/i

别慌，还没完呢。如果遇到标点符号了呢？就为了满足这一个单词的匹配，你的正则可能就需要这样写：

1
/(^import(:|;|,)? | import(:|;|,)? | import(\.|\?|\!)?$)/i

对于只匹配一个单词来说，这样做实在是有点大动干戈了。正因如此，字词边界才显得意义重大。要适应上述要求，以及很多其他情况变种，有了字符边界，我们所需写的代码只是：

1
/\bimport\b/

上面所有情况都得到了解决。

1
\b

的灵活性就在于，它是一个没有长度的匹配。它只匹配两个实际字符之间想象出的位置。它检查两个相邻字符是否是一个为单字，另一个为非单字。情况符合，就返回匹配。如果遇到了单词的开头或结尾，

1
\b

会把它当成是非单词字符对待。由于import里面的

1
i

仍然被看成是单词字符，import 就被匹配出来了。

注意，与

1
\b

相对，我们还有

1
\B

，此操作符匹配两个单字或者两个非单字之间的位置。因此，如果你想匹配在某个单词内部的‘hi’，可以使用：

1
\Bhi\B

“this”、“hight”，都会返回匹配，而“hi there”则不会返回匹配。

5. 最小组团(Atomic Groups)

Advanced Operators

最小组团是无捕捉的特殊正则表达式分组。通常用来提高正则表达式的效能，也能用于消除特定匹配。一个最小组团可以用(?>pattern) 来定义，其中pattern是匹配式。

1
/(?&gt;his|this)/

当正则引擎针对最小组团进行匹配时，它会跳过组团内标记的回溯位置。以单词“smashing”为例，当用上面的正则表达式匹配时，正则引擎会先尝试在“smashing”里寻找“his”。显然，找不到任何匹配。此时，最小组团就发挥作用了：正则引擎会放弃所有回溯位置。也就是说，它不会尝试再从“smashing”里查找“this”。为什么要这样设置？因为“his”都没有返回匹配结果，包含有“his”的“this”当然就更匹配不了了！

上面的例子并没有什么实用性，我们用

1
/t?his?/

也能达到效果。再看看下面的例子：

1
/\b(engineer|engrave|end)\b/

如果把“engineering”拿去匹配，正则引擎会先匹配到“engineer”，但接下来就遇到了字词边界，

1
\b

，所以匹配不成功。然后，正则引擎又会尝试在字串里寻找下一个匹配内容：engrave。匹配到eng的时候，后面的又对不上了，匹配失败。最后，尝试“end”，结果同样是失败。仔细观察，你会发现，一旦engineer匹配失败，并且都抵达了字词边界，“engrave”和“end”这两个词就已经不可能匹配成功了。这两个词都比engineer短小，正则引擎不应该再多做无谓的尝试。

1
/\b(?&gt;engineer|engrave|end)\b/

上面的替代写法更能节省正则引擎的匹配时间，提高代码的工作效率。

6. 递归(Recursion)

Recursion

递归(Recursion)用于匹配嵌套结构，例如括弧嵌套， (this (that))，HTML标签嵌套

1
&lt;div&gt;
1
&lt;div&gt;&lt;/div&gt;
1
&lt;/div&gt;

。我们使用

1
(?R)

来代表递归过程中的子模式。下面是一个匹配嵌套括弧的例子：

1
/\(((?&gt;[^()]+)|(?R))*\)/

最外层使用了反义符的括号“

1
\(

”匹配嵌套结构的开端。然后是一个多选项操作符

1
( * | * )

，可能匹配除括号外的所有字符 “

1
(?&gt;[^()]+)

”，也可能是通过子模式“

1
(?R)

”来再次匹配整个表达式。请注意，这个操作符会尽量多地匹配所有嵌套。

递归的另一个实例如下：

1
/&lt;([\w]+).*?&gt;((?&gt;[^&lt;&gt;]+)|((?R)))*&lt;\/\1&gt;/

以上表达式综合运用了字符分组，贪婪操作符、回溯，以及最小化组团来匹配嵌套标签。第一个括弧内分组

1
([w]+)

匹配出标签名，用于接下来的应用。若找到这尖括号样式的标签，则尝试寻找标签内容的剩余部分。下一个括弧括起来的子表达式和上一个实例非常相似：要么匹配不包括尖括号的所有字符

1
?&gt;[^&lt;&gt;]+

，要么递归匹配整个表达式

1
(?R)

。表达式最后的

1
&lt;/1&gt;

代表闭合标签。

7. 回调(Callbacks)

Callbacks

匹配结果中的特定内容有时可能会需要某种特别的修改。要应用多重而复杂的修改，正则表达式的回调就有了用武之地。回调是用于函数

1
preg_replace_callback

中的动态修改字串的方式。你可以为

1
preg_replace_callback

指定某个函数为参数，此函数能接收匹配结果数组为参数，并将数组修改后返回，作为替换的结果。

例如，我们想将某字串中的字母全部转变成大写。十分不巧，PHP没有直接转化字母大小写的正则操作符。要完成这项任务，就可以用到正则回调。首先，表达式要匹配出所有需要被大写的字母：

1
/\b\w/

上式同时使用了字词边界和字符类。光有这个式子还不够，我们还需要一个回调函数：

1
2
3
function upper_case( $matches ) {
return strtoupper( $matches[0] );
}

函数

1
upper_case

接收匹配结果数组，并将整个匹配结果转化成大写。 在此例中，

1
$matches[0]

代表需要被大写化的字母。然后，我们再利用

1
preg_replace_callback

实现回调：

1
preg_replace_callback( '/\b\w/', &quot;upper_case&quot;, $str );

一个简单的回调即有这般强大的力量。

8. 注释(Commenting)

Commenting

注释不用来匹配字串，但确实是正则表达式中最重要的部分。当正则越写越深入，越写越复杂，要推译出究竟什么东西被匹配就会变得越来越困难。在正则表达式中间加上注释，是最小化将来的迷糊和困惑的最佳方式。

要在正则表达式内部加上注释，使用

1
(?#comment)

格式。把“comment”替换成你的注释语句：

1
/(?#数字)\d/

如果你打算把代码公之于众，为正则表达式加上注释就显得尤为重要。这样别人才能更容易看懂和修改你的代码。和其他场合的注释一样，这样做也能为你重访自己以前写的程序时提供方便。

考虑使用“x”或“(?x)”修改器来格式化注释。这个修改器让正则引擎忽略表达式参数之间的空格。“有用的”空格仍然能够通过

1
[ ]

或

1
\

（反义符加空格）来匹配。

1
2
3
4
5
/
\d    #digit
[ ]   #space
\w+   #word
/

上面的代码与下面的式子作用一样：

1
/\d(?#digit)[ ](?#space)\w+(?#word)/

请时刻注意代码的可读性。

更多资源（英文）

关于作者

Karthik Viswanathan 是一个喜欢编程和做网站的高中生。你可以到他的博客上查看他的作品：Lateral Code。你也可以关注一下他的线上Twitter应用。

]]> http://iregex.org/blog/crucial-concepts-behind-advanced-regular-expressions.html/feed 3 [译]正则表达式：从菜鸟到大师 http://iregex.org/blog/from-regex-newbie-to-regex-guru.html http://iregex.org/blog/from-regex-newbie-to-regex-guru.html#comments Tue, 03 Feb 2009 02:06:11 +0000 rex http://iregex.org/?p=55 Author: Jan Goyvaerts

Publish Date: 2 Feb. 2009

Blog entry: http://www.regexguru.com/2009/02/from-regex-newbie-to-regex-guru/

Translated By: Rex (http://iregex.org)

Rex注：本文是Jan Goyvaerts为自己的著作《Regular Expression Cookbook》写的序言中的一段。

One of my last tasks for the Regular Expression Cookbook was to write the preface, including my author bio. I told the story of how I went from my first real encounter with regular expressions in 2000, to the expert I am almost a decade later.

《Regular Expression Cookbook》即将完工，剩余的工作之一是作序，包括写我的作者小传。我讲述了自己如何在2000年第一次遭遇正则表达式，并在近乎十年之后才成为专家的经历。

My first attempt at writing the bio came out way too long compared with the other sections in the preface. The final bio is only half as long. Rather than let the long bio go to waste, I’m publishing it here, with added links.

我写的小传初稿，比序言中其它小节的篇幅要长得多，最终还是压缩到一半的长度。原版的较长自传并没有丢到故纸堆里，我将其发布到这里，并加上了链接。

In 1996, fresh out of high school, Jan Goyvaerts started a hobby project publishing his own software on his own website. It was less than a year before that Internet access had become available at local call rates to his Belgian hometown. In 1999, he decided that a university degree was only a ticket to joining the rat race, and focused on his ever more successful software development venture. He set up the business that would eventually become Just Great Software in 2000.

1996年，Jan Goyvaerts高中毕业刚毕业，就在其个人网站上发布自编的软件作为业余爱好项目。一年之后，互联网才在他的比利时老家以市话费的价格普及起来。1999年，他意识到，大学学位充其量不过是一块通向更加残酷的竞争之路的敲门砖，因此他集中精力继续做自己更加成功的软件开发。2000年，他成立了自己的公司，该公司是后来的Just Great Software（绝佳软件）公司的前身。

At that time, Jan had no idea he would ever become an expert on regular expressions. One of his early successes was a postcardware text editor called EditPad. Since postcards don’t pay the bills, he developed a commercial text editor called EditPad Pro. EditPad Pro, released mid-2000, needed regular expression support to compete. Only the best regex engine would do for “Just Great Software”. Jan decided to go with PCRE.

那时，Jan从未料到他有朝一日会成为正则表达式专家。他早期的成功项目之一是一款叫作EditPad的名信片软件。由于名信片不足以补贴家用开支，他开发了一款收费版的文本编辑器：EditPad Pro，发布时间是2000年中期。该软件以正则表达式支持作为卖点。只有最好的正则引擎才配得上“Just Great Software（绝佳软件）”这个招牌。Jan决定采用PCRE。

(rex注：名信片软件并不是编辑名信片的软件，而是该软件近乎免费，只要给作者寄一张名信片就可以注册。)

The regular expression features in EditPad Pro proved quite popular, particularly because PCRE offered a regex syntax compatible with Perl, which was all the rage. Most other text editors, even the big IDEs from Microsoft and Borland, had much simpler regular expression support. (In 2009, Visual Studio and Delphi still use those same old regex flavors. This frustrates Jan, because old and limited regex flavors don’t make good book material, and both IDEs are built on .NET, which provides a very rich regex flavor fully covered in this book.)

事实证明，EditPad Pro中的正则表达式风格极受欢迎，主要是因为PRCE中的正则表达式语法与Perl兼容，这种风格风靡一时。其它大多数的文本编辑器，包括当时的MicroSoft和Borland公司的集成开发环境，也仅仅提供非常简单的正则表达式支持。（时至2009年，Visual Studio和Delphi仍在延用其古老的正则式风格。两种集成开发环境均基于.Net，它的正则表达式风格异常丰富，这些特性在书中都在书中有全面介绍。可惜的是，这两款IDE基于.Net却在编辑器中没有体现出.Net正则式的支持，因此无法为本书提供更好的素材，这一点让Jan大皱眉头。）

(rex注：本段末尾括号中的长句，翻译时调整了顺序，以便于理清逻辑顺序；添加了一句话作为辅助，便于读者掌握原义。)

Sensing a need for more powerful tools for working with regular expressions on text files, Jan developed PowerGREP. PowerGREP took a slow start in late 2002. Today, it is clearly the most powerful tool on the Microsoft Windows platform for doing anything with regular expressions. One of the differentiating features early on was the inclusion of a detailed regular expression tutorial in the help file. Most other grep tools had only help topic listing all the syntax features that you could print on a single sheet of paper. PowerGREP had a separate detailed help topic for every feature in PCRE.

Jan感觉到在使用正则式处理文本文件，需要一款更强大的工具，于是他开发了PowerGREP软件。PowerGREP项目始于2002年底，起步时进展缓慢。如今，它无疑是微软平台下处理任何正则表达式工作的最强大的工具。原先它卓而不群的标志之一就是在帮助文档中包含了完备翔实的正则表达教程。其它大多数grep工具仅仅列出了所有的语法风格，篇幅不大，在一页纸上就能打印完毕。而PowerGREP对于PCRE中每一个正则式语法要点都言之甚详。

Jan didn’t have a big budget to advertise his software. With many internet marketers preaching that content is king on the search engines, Jan set up http://www.regular-expressions.info with the text from tutorial he had already written for PowerGREP. As he watched the site’s traffic and Google rank rise, ultimately beating the Wikipedia entry at the top, Jan started getting the idea that maybe this could become his area of expertise. Writing his own regular expression engine was still a scary thought.

那时Jan并没有太多的预算来为他的软件打广告。在许多互联网营销专家鼓吹内容为王的大环境下，Jan建立了http://www.regular-expressions.info，内容来源于他已经为PowerGREP写好的教程。当他看到网站流量和Google Rank值不断攀升，远远超过了顶部的Wikipedia条目，Jan意识到或许这才是他的英雄用武之地。不过，编写自己的正则表达式引擎，对于那时的Jan来说，就像是建造空中楼阁一样不敢想像。

(rex注：存疑：是页面顶部的wikipedia条目，还是排行名列前矛的..?)

Regular expressions hit the mainstream development community when .NET was released including a set of powerful regex classes. Not much later the Java platform added the same with the JDK 1.4 release. Seeing lots of Windows developers using regular expressions, and a customer base of EditPad Pro and PowerGREP users needing to test their regular expressions, Jan felt there was a need for a comprehensive tool to create, test, and edit regular expressions. RegexBuddy was released in 2004.

附有一整套正则式类库的.NET发布后，正则表达式成为开发界的主流。不久之后，Java平台也在JDK1.4发行版中加入相同内容。看到众多的Windows开发人员用上了正则表达式，以及相当数量的EditPad Pro和PowerGREP客户群需要对正则表达式进行测试，Jan感觉到，有必要开发一种集创建、测试、编辑正则式于一体的综合工具。2004年，RegexBuddy诞生了。

The PCRE engine which had been such a blessing in 2000 was now seriously limiting both PowerGREP and RegexBuddy. PowerGREP needed to search files larger than 2 GB, and RegexBuddy needed to be compatible with all major regex flavors, not just PCRE. Jan bit the bullet and sweat several months implementing a brand new regular expression engine. The result was a fusion regex flavor that supports almost all the features found in all the regex flavors discussed in this book, and that was fast and flexible enough to meet the needs of PowerGREP’s customers. The new regex engine made the 2005 releases of PowerGREP and RegexBuddy very successful.

对于PowerGREP和RegexBuddy来说，在2000年时PCRE引擎真可谓是来自上天的恩赐，可时至如今，它却成了一种极大的限制了。PowerGREP需要搜索2GB以上的大文件，RegexBuddy也需要兼容所有的主流正则风格，而不仅仅是PCRE风格。于是Jan咬紧牙关，大干数月，终于实现了一种全新的正则式引擎。它是正则式风格集大成者，支持本书中提及的所有正则流派的几乎所有的特性。它足够快速、灵活，满足了PowerGREP客户的需求。新的正则引擎给2005年发布的PowerGREP和RegexBuddy带来极大的成功。

By this time, Jan had become very aware of the differences between all the regular expression flavors. While RegexBuddy could now emulate nearly all the abilities of the popular regular expression flavors, it could not emulate their deficiencies. After much research and testing, Jan released RegexBuddy 3 in 2007 which can emulate the features, and lack thereof, of 15 different regular expression flavors.

到那时，Jan对于所有正则表达式流派之间的区别了如指掌。RegexBuddy能够模拟流行的正则表达式流派的所有性能，却不能模拟它们的缺陷。经过大量研究和测试之后，Jan于2007年发布了RegexBuddy 3，该版本可以模拟15种不同的正则表达式流派的所有风格，包括缺陷。

Having spent so much time researching regular expressions, Jan felt he was ready to write the book on regular expressions. But he didn’t actually set out to do it. It was Steven Levithan, a very enthusiastic RegexBuddy user, who asked him early 2008 if he wanted to co-write a book on regular expressions. Jan hesitated at first, books being much less profitable than software. After some reflection, he decided he would realize his childhood dream of seeing his name in print, before the printed book becomes obsolete.

Jan在研究正则表达式上花费的时间如此之久，他觉得自己可以写一本关于正则表达式的书了。但是他并没有动手写作。一位狂热的RegexBuddy用户，Steven Levithan，在2008年年初询问Jan是否愿意共同写一本关于正则表达式的书。Jan开始有些犹豫，毕竟写书不像写软件那样利润丰厚。再三考虑过之后，他意识到可以实现儿时的梦想，那就是在纸版书绝迹之前，看到自己的名字印到封面。

The result will be published in May 2009. Enjoy.

本书将于2009年5月出版，敬请期待。

Meanwhile, Jan has left cloudy Belgium for tropical Thailand. He now lives with his wife in Phuket, where he enjoys pretending to be a tourist, even though in reality he still spends far too much time flipping the switches on his DataHand.

于此同时，Jan离开了乌云密布的比利时，来到了泰国这个热带国家。他和妻子在普吉岛安顿下来。在这里他喜欢假装成游客，实际上他太多太多的时间还是花费在敲击自己的DataHand键盘上。

Rex评：读过了《Mastering Regular Expressions》，现在很期待读一下这本CookBook。不过，作者也明示、暗示过了，RegexBuddy和PowerGREP的应用会占用书中的相当篇幅；并坦言写书不如写软件赚钱。与《MRE》的作者Jeffrey Friedl相比，Jan的商人味更浓一些，而Jeffrey的学者味更浓。我敬佩资深的学者，羡慕成功的商人，Jan集二者于一身了。理解正则表达式的原理，MRE是一本很好的教材。而CookBook的书名暗示，它就像是菜谱一样，是实用的具体技术实践的指导。这两本我都想深入读，以便了解其术。我更想读的，还包括编译原理，什么时候能够真正写一款自己的编译器，写出自己的正则表达式引擎，即使是很简单地实现。

]]> http://iregex.org/blog/from-regex-newbie-to-regex-guru.html/feed 2