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的书名暗示，它就像是菜谱一样，是实用的具体技术实践的指导。这两本我都想深入读，以便了解其术。我更想读的，还包括编译原理，什么时候能够真正写一款自己的编译器，写出自己的正则表达式引擎，即使是很简单地实现。

本书的最后期限是1月31日，作者在该日期之前提交最后的修改勘误，并将为本书新建网站http://www.regular-expression-cookbook.com/。

新闻来源：RegexGuru: Regular Expression Cookbook Available for Pre-Order

翻译者：rex，译者博客(http://iregex.org)。

rex注：URL是Uniform Resource Locator的缩写(wiki)，中文叫作统一资源定位符（百科），解释如下：Internet上的每一个网页都具有一个唯一的名称标识，通常称之为URL地址，这种地址可以是本地磁盘，也可以是局域网上的某一台计算机，更多的是Internet上的站点。简单地说，URL就是Web地址，俗称“网址”。

In his blog post The Problem with URLs points out some of the issues with trying to detect URLs in a larger body of text using a regular expression.

在他的博客文章URL难题一文中指出了使用正则表达式在大量文本中尝试检测URL所遇到的一些问题。

The short answer is that it can’t be done. Pretty much any character is valid in URLs. The very simplistic \bhttp://\S+ not only fails to differentiate between punctuation that’s part of the URL, and punctuation used to quote the URL. It also fails to match URLs with spaces in them. Yes, spaces are valid in URLs, and I’ve encountered quite a few web sites that use them over the years. It also forgets other protocols, such as https.

简言之，答案是做不到。在多数情况下，任何字符在URL中都是合法字符。这条过分简单化的表达式\bhttp://\S+之所以失败，不单因为它无法区分作为URL一部分的标点符号与引用URL的标点符号，还在于它对URL中包含空格的情况也是无能为力。是的，空格在URL中也是合法的，这几年我颇遇到一些网址中包含空格的情况。本条正则式还忽略了其它的网络协议，例如https。

In RegexBuddy’s library, you’ll find this regex if you look up “URL: Find in full text”:

在RegexBuddy’s library(RegexBuddy标准库)中，你如果你查找“URL: Find in full text”：

\b(https?|ftp|file)://[-A-Z0-9+&@#/%?=~_|!:,.;]*[A-Z0-9+&@#/%=~_|] (case insensitive大小写不敏感)

Like every other regex for extracting URLs, it’s not perfect. The key benefit of this regex is that it uses a separate character class for the last character in the URL, which allows less punctuation characters than the character class for the other characters in the URL. It excludes punctuation that is unlikely to occur at the end of the URL, and more likely to be punctuation that’s part of the sentence the URL is quoted in. It does not allow parentheses at all.

与其它试图析取URL的正则式一样，它并不完美。但是这条正则式的主要优势是，它在结尾处使用单独的文本类，这就限定了结尾处所允许出现的标点字符种类要少于URL的其它部分。它排除了在URL结尾处不太可能出现，而更像是URL所在文本结尾的标点。它根本不允许出现括号。

In EditPad Pro’s syntax coloring schemes, which are fully editable and entirely based on regular expressions, you’ll often find this regex:

EditPad Pro的语法色彩主题是可自定义的，完全基于正则表达式的。在其中，你会经常发现这条正则式：

\b(?:(?:https?|ftp|file)://|www\.|ftp\.)[-A-Z0-9+&@#/%=~_|$?!:,.]*[A-Z0-9+&@#/%=~_|$]

(case insensitive大小写不敏感)

The main difference with the previous regex is that this one matches URLs such as www.regex-guru.info without the http:// protocol. People often type URLs that way in their documents and messages, because most browsers accept them that way too.

本条正则式与上一条的主要区别是，它匹配www.regex-guru.info之类的URL，之前没有http://协议。人们经常在文件或消息中使用这种方式输入网址，同时大多数浏览器也接受这种方式。

EditPad’s built-in “clickable URLs” syntax highlighting uses this regex:

EditPad的内置“可点击的URL”语法高亮，是由这条正则式实现的：

\b(?:(?:(?:https?|ftp|file)://|www\.|ftp\.)[-A-Z0-9+&@#/%?=~_|$!:,.;]*[-A-Z0-9+&@#/%=~_|$]

   | ((?:mailto:)?[A-Z0-9._%+-]+@[A-Z0-9._%-]+\.[A-Z]{2,4})\b)

|”(?:(?:https?|ftp|file)://|www\.|ftp\.)[^"\r\n]+”?

|’(?:(?:https?|ftp|file)://|www\.|ftp\.)[^'\r\n]+’? (free-spacing, case insensitive空格宽松模式，大小写不敏感)

This log regex adds three alternatives to the previous regex. It adds the ability to match email addresses, with or without mailto:, and it matches URLs between single or double quotes. When the URL is quoted, it allows all characters in the URL, except line breaks and the delimiting quote. This way, any URL with weird punctuation can be highlighted correctly by placing it between a pair of quote characters. Because this regex is used to highlight text as you type, the closing quotes are optional. The highlighting will run until the end of the line until you type the closing quote. Remove the question marks after the quote characters if you will use this regex to extract URLs.

这条正则式在前一条的基础上增加了三种备选匹配项。现在它可以匹配电邮地址，有无mailto:均可；匹配单引号或双引号之间的URL。当URL在引号内时，它允许出现除换行符或起界作用的引号之外的任意字符。使用这种方法，不论使用何种怪异标点引用的URL，都能将URL与引号分离开来，从而正确高亮显示。由于此正则式是在你输入的同时高亮文本，因此右侧的结尾引号不是必需的。高亮持续显示到本行结尾，直到你输入右侧的结尾引号。如果你要使用本正则式析取URL，请删除引号后面的引号。

So how about Jeff’s problem?

我们再来看一下Jeff的问题：

I couldn’t come up with a way for the regex alone to distinguish between URLs that legitimately end in parens (ala Wikipedia), and URLs that the user has enclosed in parens.

我实在想不出，怎样仅仅使用正则式，就能正确地区分使用以括号结尾的URL和使用括号括起来的URL。

That’s not too hard, if we add the restriction that we only allow unnested pairs of parentheses in URLs. Using the second regex in this article as the starting point, add an alternative for a pair of parentheses to both character classes in that regex:

如果限制在URL只使用不嵌套的括号的话，那么该问题不难解决。使用本文中第二条正则式作为开始，在正则式的两组字符类中都加上一对可选的括号：

\b(?:(?:https?|ftp|file)://|www\.|ftp\.)

  (?:\([-A-Z0-9+&@#/%=~_|$?!:,.]*\)|[-A-Z0-9+&@#/%=~_|$?!:,.])*

  (?:\([-A-Z0-9+&@#/%=~_|$?!:,.]*\)|[A-Z0-9+&@#/%=~_|$]) (free-spacing, case insensitive空格宽松模式，大小写不敏感)

This regex allows the same set of characters in the middle of the URL, mixed with zero or more sequences of those characters between parentheses. It allows the URL to end with the same reduced set of characters, or a final run between parentheses. Because we require the opening parenthesis to be in the URL, we don’t have to do anything complicated to check if any closing parentheses we encounter are part of the URL or not.

这条正则式允许相同的字符集出现在URL中的括号内，组成0个或多个字符的序列。它允许URL以简化的字符集结尾，或者在结尾出现最后一组括号。由于我们要求在URL中出现开括号，所以就不必再做任何复杂工作来验证之后所遇到的闭括号是不是URL的一部分了。

It’s important that you observe that in order to allow any number of pairs of parentheses in the middle of the regex, I moved the star from the character class to the group it is now in. I did not add another star to the group. A double-star combination like (a|b*)* is a sure-fire recipe for catastrophic backtracking.

你或许注意到，为了允许正则式中出现任意多次的成对括号，我将字符类中的星号移到它所在组。我并没有再给此组加星号。这一点至关重要。像(a|b*)*这样的双星号组合，是灾难式回溯的保证。

All the regexes in this article will be included in RegexBuddy’s library with the next free minor update. Current version is 3.2.0.

本文提及的所有的正则式都将在RegexBuddy下次免费次要升级中添加到正则库库中。当前RegexBuddy的版本是3.2.0。

rex注：在RegexBuddy里，可以使用Alt+7唤出自带的正则库。输入URL回车，查到的结果如下：

译后：

我自己探索时，走得很兴奋；有人引路时，很走得很稳健。

抓饭最初就是使用正则表达式析取饭否消息的， 但是所有的文本都遵循良好的格式：XML。当然不可避免非法字符，这些在作为XML展示时会报错。不过，如果镶嵌在HTML中展示时安然无恙。

饭否、叽歪、做啥，都能完美地解析所输入的消息中的URL，并自做主张处理一下，变成自有格式，例如，饭否会把输入的http://regex.me 转换为http://fanfou.com/linkto/aHR0cDovL3JlZ2V4Lm1l，即使在http://regex.me之后加上一两个汉字，也不影响转换结果。不过twitter就没这么强大了。在twitter中输入“http://regex.me正则表达式交流论坛”，输入的的结果是http://tinyurl.com/5azr6y，点击展开，URL就成了http://www.regex.me正则表达式交流论坛/，很显然这是一个错误的URL。错误的原因就在于它没有正确地从文本解析URL。

撕烤者说过：“汉语的一个优势是，我们可以很轻易的把它们和代码区分开。”颇然其说。中英文的区别，不仅仅是肉眼上一目了然，即使使用程序来区分也是毫不费力。不同的编码方案有利于正确解析HTML代码，找到其中的URL结束点。可惜twitter这一点做得实在太滥。