在线文档


 

前言

提到正则表达式,许多人很有点不屑一顾:这东西,不登大雅之堂,再说也不是总要用到,何必专门花时间学习?

没错,正则表达式并不是“总要用到”,但到了需要的场合用不上,往往产生“一分钱难倒英雄汉”的尴尬。经常需要处理文本的程序员自然会知道正则表达式的价值,其它的程序员如果不会正则表达式,即便开发的领域与文本处理没什么关系,也难免“躺着中枪”的命运——前几天我遇到一个问题,将一行长长的地址拆分成多行,负责这部分的程序员日常的工作只是制作PDF而已,拆分地址是很“边缘”的功能,但不会正则表达式就无法准确折行(一般需要在标点符号出现的地方折行,而不能只在空白字符处折行,但是不同语言中的标点符号各有不同),结果一筹莫展;相反,如果了解正则表达式,就可以很容易地处理各种语言中的标点字符。

以我的开发经验来看,专门花点时间掌握正则表达式,确实是非常有必要的。目前可以见到的关于正则表达式的书籍和资料已经有不少,但又各有不足。

在互联网上,流传着一些编程语言的正则文档和《30分钟教会你正则表达式》之类的帖子。这类资料的好处是简单直接,查到了,如果有现成的例子,而且适用于自己的语言,可以直接拿来用;然而,其坏处也是简单直接,因为缺乏背后原理的讲解,如果找不到现成的例子,或者找不到能在自己所使用语言中行得通的例子(须知道,同样的正则表达式并不能直接套用到不同的语言中),则束手无策。

在正式的出版领域,已经有《精通正则表达式》、《正则表达式必知必会》之类的书籍出版,尤其是前者,堪称关于正则表达式的经典著作,如果想认真学习正则表达式,这类书籍是必须阅读的。但是这类书籍也有一个弱点,即它们都是从英文版本翻译而来,更多地侧重英文文本的处理,身为中文世界的开发人员,我们经常需要处理中文文本,对于处理英文之外的字符,正则表达式已经提供了足够丰富的功能,但如何用对、用好这些功能,资料却很匮乏。

我经常需要给人讲解正则表达式的相关知识,时常惋惜的是,开发人员为这些问题所困然;正因为如此,本书的写作动机便是着力弥补现有资料的缺陷。

相对于正则文档和速成教学帖子,它深入讲解了匹配背后的原理,往往会举一反三,告诉读者,这里为何这样写,如果改成其它形式,会造成什么结构;并且,集中讲解和比较了多种语言中正则表达式用法的异同,方便读者把现成的正则表达式“移植”到自己的工作环境中。

相对于《精通正则表达式》等正式的书籍,本书辟出专门的内容讲解语言和编码,告诉读者如何设定编码,如何正确处理中文等字符,另外,本书还涵盖了.NET、Java、JavaScript、PHP、Python、Ruby六种常用语言,对每种语言给出专门章节,不但详细介绍了语言中正则表达式的用法,更点明了版本之间的细微差异,不但可以作为专门学习的教材,还可以成为有用的参考手册。

本书的结构

本书可以分为三大部分。

第一部分主要讲解正则表达式的基础知识,覆盖常见正则表达式中的各种功能和结构。看完前面三章,就可以基本弄明白现在流行的各种正则表达式;尤其如果你之前有一些经验,会觉得阅读起来并不困难。但是我也希望读者不要忽略其它的内容,断言和匹配模式现在已经是正则表达式的“标准配备”了,而且确实可以派上大用场,所以第4章和第5章的内容,即便不是很熟悉,阅读起来可能有一些麻烦,也不应该忽略。最后的第6章,则厘清了正则表达式在使用中的若干疑惑,了解它们,你就可以相对自由地在正则表达式的世界里行走了。

第二部分主要讲解关于正则表达式的更深入的知识,这一部分用三章的内容,详细探讨了编码问题、匹配原理、解题思路。这部分内容更抽象,需要多花一点时间来阅读和理解,但是它们确实可以帮你在正则表达式的世界里登堂入室,脱离“术”的层面,掌握万变不离其宗的“道”。

第三部分的作用是接地气,将之前介绍的各种知识落实到六种常用语言.NET、Java、JavaScript、PHP、Python、Ruby中来。每一章的开头有正则功能列表,其中的功能都对应到前面部分的讲解,这些功能的具体应用实例,以及不同版本之间的差异,则在章节中详细讲解,每一章的最后还给出了常见任务的示例代码,方便日后查询。在最后,第16章简要介绍了正则表达式在Linux下常用工具vi、grep、awk、sed中的使用,并通过一个实际的例子将这几种工具串起来,对比说明了它们适合解决的问题。

在本书的最后提供了用作参考的附录,分为三部分。

第一部分是正则表达式的常用功能在不同语言中的比对,希望能给需要在多种语言中使用正则表达式或者移植正则表达式的读者来说提供一份有用的参考;第二部分给出了若干常见的正则表达式,比如匹配邮政编码、身份证号、手机号、QQ号、电子邮件地址等等,希望能成为常见问题的“速查手册”;最后一部分列出了常用正则表达式的工具和资源,方便大家调试自己的正则表达式,以及继续深入学习。

本书的读者

本书适合以下几类读者。

经常需要进行文本处理(比如日志分析或网络运维)的技术人员。这些读者或许已经熟悉了正则表达式的基本用法,但面对日益复杂化和海量化的数据,阅读本书可以帮助你更准确、更高效地处理文本,提升自己工作的价值。

熟悉常用开发语言的程序员。虽然这些读者不需要专职进行文本处理,但源代码和许多数据其实也是文本,如果不会正则表达式,在偶然遇到处理源代码或文本数据的任务时,往往会产生躺着中枪的无力感。本书第三部分可以帮你迅速找到有关的例子,并落实在自己的编程语言中,当然前两部分也非常有必要,因为它们可以帮你夯实基础。

已经对正则表达式有一定了解的读者。这些读者虽然能用正则表达式解决常见的任务,不一定了解正则表达式的编码问题、匹配原理、解题思路,仔细阅读本书的第二部分,可以深化并完善对正则表达式的理解,而第三部分详细比较了使用正则表达式时各种语言、以及同一种语言中各种版本的差异。所有这一切,应该可以让你对正则表达式的掌握更上层楼。

致谢

一本书的完成,必然离不开众多人的帮忙。

首先需要感谢的是周筠老师和徐定翔、卢鸫翔两位编辑,他们在我写作的最初阶段做了大量细心耐心的工作,完全可以说,没有他们的这些工作,我就不会有写作这本书的念头,或者坚持写完的动力。

然后要感谢的是电子工业出版社的杨福平社长和张月萍编辑,没有他们的关照和辛劳工作,这本书的出版定然会遇到更多的困难。

感谢我的朋友霍炬和韩磊,虽然我之前阅读过《精通正则表达式》,但与翻译和写作结缘,他们给了我莫大的帮助,有了这个契机,才有现在的《正则指引》。尤其值得一提的是霍炬的夫人西乔,精心手绘了这本书的封面,在这里表示诚挚的谢意。

感谢我曾工作过的盛大创新院以及创新院的各位同事(李骏、郝培强、庄表伟、丁宇、许式伟、莫华枫、李道兵、赵劼、樊一鹏、张一宁等),创新院给了大家宽松自由的工作环境,与各位同事的讨论加深了我对正则表达式理解,也为我贡献了许多例子。

感谢张东亮、陆亦斌、孙勇、叶劲峰等各位朋友,愿意拨冗阅读本书的草稿,并提出了大量专业的意见。

感谢何源、陈钢、贺钧、陈驰等读者,试读本书之后提出了大量的宝贵意见,在最后关头打消了我心中的许多忐忑。

在更早之前,我的父母从小就鼓励研究和了解各种科学原理(“玩也要动脑筋”),没有这种思维行为习惯,我很可能浅尝辄止而没有兴趣探究正则表达式背后的图景;此外,在中小学阶段,我的语文老师罗碧玉、郭志鸿、易玺铭培养了我对于文字的兴趣,在大学阶段,东北师范大学文学院的王确老师给了我这个理科生非常多的帮助和指引,在此一并表示感谢,能遇到你们是我的幸运。

最后需要还需要感谢许多为这本书做出过贡献的人,你们的名字我可能暂时无法记起,或者无法一一罗列,但我会在心中存留对你们的谢意。

几经周折,《正则指引》终于要截稿了,将目录列在这里,有兴趣的读者可以留言申请试读感兴趣的部分(试读条件:申请试读的读者必须有自己的blog,每人最多试读2章(附录分3章),且须在试读一周内提供试读报告)。

第一部分

第1章 字符组

1.1 普通字符组
1.2 关于Python的基础知识
1.3 普通字符组(续)
1.4 元字符与转义
1.5 排除型字符组
1.6 字符组简记法
1.7 字符组运算
1.8 POSIX字符组

第2章 量词

2.1 一般形式
2.2 常用量词
2.3 数据提取
2.4 点号
2.5 滥用点号的问题
2.6 忽略优先量词
2.7 转义

第3章 括号

3.1 分组
3.2 多选结构
3.3 引用分组
3.4 非捕获分组
3.5 补充

第4章 断言

4.1 单词边界
4.2 行起始/结束位置
4.3 环视
4.4 补充

(more…)

今天我的同事老赵 @jeffz_cn 问我,有没有办法用正则表达式匹配“不包含某个字符串”的文本,正好,我在写作的《正则表达式傻瓜书》中也提到了这类问题,就把这一节放出来,给大家参考,也希望大家多提建议(尤其是配图方面)。

正则表达式的与或非

我们都知道,写正则表达式有点像搭积木,复杂的功能总可以拆分开来,由不同的元素(也就是子表达式)对应,再用合适的关系将它们组合起来,就可以完成。在这一节,我们讲解常见的与或非关系的表达。

“与”是最简单的关系,它表示若干个元素必须同时相继出现,比如匹配单词cat,其实就是要求字符c、字符a和字符t必须同时连续出现。

正则表达式表达“与”关系非常简单,直接连续写出相继出现的元素就可以,我们可以想象,在各个元素之间,存在看不见的连接操作符·,比如上面匹配单词cat的正则表达式,就是『cat』,我们可以将它想象为『c·a·t』。

“与”关系也不限于字符之间,任何子表达式都可以用它来连接,如果我们把上面单词中的a替换为字符组『[au]』,表达式就变为『c[au]t』,你可以想象为『c·[au]·t』。

“或”是正则表达式灵活性的重要体现,我们可以规定某个位置的文本的“多种可能”,比如要匹配cat或是cut,在正则表达式看来,就是“字符c,然后是a或u,然后是t”。

如果“或”的多种可能都是单个字符(一般要求ASCII字符,中文字符等多字节字符的情况,可以参考本书专门论述的章节,此处仅以ASCII字符为例),就可以用字符组来表达“或”的关系,比如上面的cat或者cut的情况,正则表达式写做『c[au]t』,其原理如下:

更复杂的情况是“或”的多种可能,并非都是单个字符,有些可能是多个字符。比如,我们可以看一个更复杂的例子,不仅要匹配cut,还要匹配c开头、t结尾的单词chart、conduct和court。也就是说,在开头的c,结尾的t之间“可能”出现的是:uharonducour。

遇到这种情况,就不应使用字符组,而应当使用多选分支『(…|…)』,将各个“可能选项”列在多选分支中。于是,正则表达式变为『c(u|har|onduc|our)t』,其原理如下:

关于多选分支,还有两点要补充:

多选分支也可用于“每个选择都是单个字符”的情况,比如『c[au]t』写成『c(a|u)t』是没错的,但字符组的效率要远高于多选分支,所以,在这种情况下,推荐使用字符组『c[au]t』;

默认的多选分支『(…|…)』使用的括号是会捕获文本的,也就是说,括号内的表达式真正匹配成功的文本会记录下来,匹配完成之后可以提取出来,具体到上面的例子,就是我们有办法在匹配完成后“提取”出u或har或onduc或our。但许多时候,我们需要的只是整个表达式的匹配,而不关心“匹配时到底选择的哪种可能情况”,在这种情况下,我们稍加修改,使用“不捕获文本的括号”,可以提高效率。不捕获文本的写法也很简单,只是在开扩号之后加上字符『?:』,也就是『(?:…|…)』,具体到上面的例子,就应该写成『c(?:u|har|onduc|our)t』。这样做虽然繁琐点,但效率有保障,阅读起来也不困难,我推荐养成这种习惯,只要用到了括号,就想想是否真的要捕获括号内表达式匹配的文本,如果不需要,就是用不捕获文本的括号。

“非”看起来简单,其实是最复杂的,以下分几种情况讨论。

首先讨论针对字符的“非”:不容许出现某个或某几个字符。这是最简单的情况,直接用排除型字符组就可以对付,仍然用上面的例子,如果要匹配的单词是c开头、t结尾,中间有一个字符,但不能是u(也就是说,整个单词不能是cut),直接用『c[^u]t』就可以了,若中间的字符不能是a或u(也就是说,整个单词不能是cat或cut),则表达式改为『c[^au]t』。

如果你认真读过关于排除型字符组的章节,肯定会知道,这个表达式能匹配的只是cot之类的单词,因为中间的排除型字符组『[^au]』必须匹配一个字符。可是,如果我们还想要匹配chart、conduct和court,怎么办?最简单的想法是去掉排除型字符组的长度限制,改成『c[^au]+t』——不幸的是,这样行不通,因为这个表达式的意思是:c和t之间,是由多于一个“除a或u之外的字符“构成的,而chart、conduct和court,都包含a或u。

我们回头仔细看看这个“非”的逻辑,我们发现,其实我们要否定的是“单个出现的a或u”,而不仅仅是“出现的a或u”,所以才出现这样的问题,要解决这个问题,就应当把意思准确表达出来,变成“在结尾的t之前,不容许只出现一个a或u”。想到这一步,我们就可以用否定顺序环视『(?!…)』来解决了,它表示“在这个位置向右,不容许出现子表达式能够匹配的文本,我们把子表达式规定为『[au]t\b』(最后的『\b』很重要,它出现在t之后,保证t是单词的结尾子母)。

有了这点限制,匹配a和t之间文本的表达式就随意很多了,我们可以用匹配单词字符的简记法『\w』表示,于是整个表达式就变成了『c(?![au]t\b)\w+t』。请注意,这里出现的并不是排除型字符组『[^au]』,而是普通的字符组『[au]』,因为否定顺序环视『(?!…)』本身已经表示了“否定”的功能。

如果我们再进一步,“整个匹配文本中都不能出现字符串cat”,要怎么办呢?许多人的思路就是借鉴处理“或”关系的思路:既然字符组对应单个字符的情况,多选分支对应多个字符的情况,那么在否定时也是这样。可惜,正则表达式并没有提供与多选分支对应的“否定”结构,那么,应该怎么办呢?

解决的办法还是得依靠否定顺序环视——“整个匹配文本中都不能出现字符串cat”,换句话说,就是“在文本中的任意位置,向右,都不能出现该字符串”。因此,我们用两个锚点『^』和『$』,分别匹配整个字符串的开头和结尾位置,再用否定顺序环视『(?!cat)』表达“不能出现字符串cat”。

即便知道了原理,也不见得能写对正则表达式,比如『^(?!cat).+$』就是不正确的,因为它只限定了在文本的开头(也就是『^』)右边不能出现cat,而我们真正要做的是,在文本的每一个位置右边,都不能出现cat,所以应该改成『^((?!cat).)+$』;但这还说不上完美,根据前面提到的关于括号捕获的知识,因为此处并不需要括号捕获的文本,所以最好使用非捕获型括号『(?:…)』,最终我们得到的表达式就是『^(?:(?!cat).)+$』。

这两天,我的同事丁宇@felixding,极具艺术气质的设计师,推荐)遇到了一个正则表达式的问题,我琢磨了半天写了个表达式,暂时能用;今天庄表伟@zhuangbiaowei)跟我说,遇到正则表达式的问题,大家一般只能查手册,但具体的问题要怎么思考和解决问题,往往束手无策;恰好我在写作《正则表达式傻瓜书》,也希望多讲讲这方面的内容。尽管目前的写作还没有进展到介绍解题经验的阶段,但可以先在blog上写这方面的内容,希望对大家有所帮助,也希望大家多提意见;如果大家愿意,我可以继续写这类文章。
另:本例解决过程中王晖同学(@cnhacktnt)提供了大量的帮助,他使用正则表达式的熟练程度远在我之上,在此深表感谢。

要想写好、写对正则表达式,第一步就是分析需求,把模糊的应用要求清楚归纳为几条程序性特征;本例中的正则表达式用于验证“密码字符串”,仔细分解应用场景,可以得到四条明确的要求(一般来说,密码字符串对长度都有要求,但本例中,需要验证的密码字符串已经由其它语句保证了是6-12位长的字符串,所以这里不考虑长度):

1.只能由小写字母、数字和横线(-)组成;
2.开头和结尾不允许是横线;
3.不允许全部是数字;
4.不允许有连续(超过一个)的横线。

下面我们一一解析:

1.只能由小写字母、数字和横线(-)组成
这一条很好办,用字符组『[-a-z0-9]』即可解决,注意我们没有用字符组『\w』,因为一般来说『\w』等价于『[a-z0-9_]』,下划线_也可以匹配;在使用正则表达式时准确限定范围、避免错误匹配,是需要谨记的规矩;

2.开头和结尾不容许是横线
这也很好办,我们知道,在正则表达式中,字符串的开头位置用『^』表示,结束位置用『$』表示(关于『\A』和『\Z』的情况暂不讨论,因为密码字符串中不可能出现换行符),这两个锚点(anchor)只匹配位置,不匹配任何字符;开头不容许出现横线,也就是说,从开头位置向后,不容许出现横线字符,我们可以用否定顺序环视(negative lookahead)功能解决。在本例中,它写作『(?!-)』,其中的『(?!…)』是否定顺序环视的标志符,其中的横线,整个结构表示,在当前位置之后(也就是右边一位),不容许出现横线字符,把它和表示字符串开头的『^』连在一起,得到『^(?!-)』,就表示“从字符串的开始位置,向右边看,不容许马上出现横线”;类似的,我们在表达式的末尾使用否定逆序环视,正则表达式『(?<!-)$』就表示“从字符串的末尾位置,向左边看,不容许马上出现横线”;

3.不容许全部是数字
这个要求得动点脑筋,有人一看到“不容许全部是数字”,就想到否定型字符组『[^0-9]*』,这其实是不对的。我们仔细想想,“不容许全部是数字”就是“必须出现至少一个非数字字符”,而第一条要求字符只能是小写字母、数字和横线,那么这个“非数字字符”只能是小写字母,或者横线。这样一来我们就知道了,在这个正则表达式中,必须出现一个『[-a-z]』匹配的字符;

4.不容许有连续(超过一个)的横线
这种“不容许出现某种连续字符”的情况,是正则表达式中最难处理的地方,因为常见的表示“不容许”的功能,就是排除型字符组『[^…]』,于是,遇到“不容许出现两个连续横线”的情况,许多人就想当然地写下『[^–]』,但这其实大错特错——我们需要谨记,字符组的作用只限于单个字符,所以『[^–]』的意思是“在这个位置,不能匹配横线”。那么要怎么办呢?
一般来说有两个办法,我们可以规定,在一个横线字符匹配之后,不容许继续出现横线,还是应用上面说过的否定顺序环视,『-(?!-)』,就保证了匹配了一个横线之后,不容许继续出现横线,如果在每一个可能匹配横线的地方都加上这个限定,“不容许有连续(超过一个)横线”的要求也就满足了;或者我们也可以在整个正则表达式的最开头,使用否定顺序环视『^(?![-a-z0-9]*–)』,因为表达式『[-a-z0-9]*–』会“尽力寻找可能的匹配”,对它加以否定,就保证了整个字符串中绝对不容许出现两个连续的横线。
在这个例子中,我们观察第一条要求对应的表达式,发现横线一般是与小写字母和数字同时出现在一个字符组『[-a-z0-9]』中,如果采取上述第一种办法,因为字符组中只能出现对单个字符的规定(而无法使用类似环视之类的结构),『[-(?!-)a-z0-9]』的意思完全不对,所以整个字符组就要改成括号,以多选结构表示为『(-(?!-)|[a-z0-9])』,显得很累赘,所以优选第二种方法。

好了,四条要求已经分别解决完毕,现在我们把它们组合起来。

首先,是开头的『^(?!-)』,这就表示“开头不容许出现横线”,在结尾用『(?<!-)$』,表示“结尾不容许出现横线”;
其次,之中的内容都只可能是小写字母、数字和横线,所以用字符组『[-a-z0-9]』,因为长度不确定,所以使用量词『*』,变成『[-a-z0-9]*』;
再次,整个正则表达式中必须出现一个非数字字符,也就是必须让『[-a-z]』匹配一个字符,因为这个非数字字符出现的位置不确定,我们不妨把上面的表达式『[-a-z0-9]*』“切开”,把『[-a-z]』塞进去,得到『[-a-z0-9]*[-a-z][-a-z0-9]*』,这样就保证了“在所有由小写字母、数字和横线构成的字符串中,至少出现了一个非数字字符”;
最后,不容许出现两个连续的横线,我们的解决办法是在字符组的最开始位置,添加一个否定顺序环视,也就是『(?![-a-z0-9]*–)』,我们把它与之前的『^(?!-)』合并起来,得到『^(?!(-|[-a-z0-9]*–))』。

所以,整个正则表达式就是这样:

^(?!(-|[-a-z0-9]*--))[-a-z0-9]*[-a-z][-a-z0-9]*(?<!-)$

看起来完全没有问题,但放到Ruby on Rails框架里运行,却报正则表达式错误——原来是Ruby不支持逆序环视,所以最后的『(?<!-)』无法使用;那么要如何解决呢?
这时候又有两个办法,第一是用字符串函数判断最后一个字符是否横线,来“辅助”正则表达式,许多新手往往会陷入思维的误区,或者追求“漂亮”,非要用一个正则表达式解决所有问题,这其实是不必要的;如果非要用正则表达式,可能要动用一些复杂的结构——不过还好,在本例中,我们可以“取巧”,再添加一个否定顺序环视,『(?![-a-z0-9]*-$)』,表示“不容许出现 横线+字符串结尾 的情况”,也就等于“在字符串结尾之前,不能出现横线”。

我们把这个字符组与之前的『^(?!(-|[-a-z0-9]*–))』合并,就得到『^(?!(-|[-a-z0-9]*–| [-a-z0-9]*-$))』;于是,整个正则表达式就成了:

^(?!(-|[-a-z0-9]*--|[-a-z0-9]*-$))[-a-z0-9]*[-a-z][-a-z0-9]*$

输入这个正则表达式,编译不再报错,运行测试,发现完全符合要求。

上一章,我们通过Word中的“使用通配符”模式,粗略见识了正则表达式的使用方法。然而通配符并不等于正则表达式,遇到复杂的情况,通配符就力不从心了。所以从本章开始,我们来看“正宗”的正则表达式。

安装Regular Expression Tester

“工欲善其事,必先利其器”,学习正则表达式也是如此。尽管正则表达式的思想和规则是基本确定的,应用起来却有许多讲究(比如,在Java、C++、Python等不同的编程语言中,同一个表达式的具体写法是不同的,在Word、Excel等软件中也是这样)。所以,学习正则表达式最好采用“中立而规范”的工具——这有点像学习摄影,开始应该学习的是构图、用光,而不是尼康、佳能或索尼相机的特性。

本书中,我们采用Firefox的插件Regular Expression Tester(意思是“正则表达式测试工具”)来学习和讲解正则表达式,选择它的好处在于:不需要搭建编程语言环境(许多时候我们并不需要在编程语言中应用正则表达式);在Windows/Unix/Mac上都可以使用;并且支持大多数通用的正则表达式功能。如果你没有接触过它,也不用担心,下面我们介绍它的安装和使用。

(more…)

第一章:通配符

我们已经说过,这本《正则表达式傻瓜书》并非把读者当傻瓜,而是保证“傻瓜都能看懂”。如果你到现在还没听说过“通配符”或是“正则表达式”,那么,请看这一章。
要说明的另一点是,因为一般的Linux/Unix用户都熟悉通配符,所以,本章假设读者工作于Windows平台下,所举的例子也全部面向Windows平台。

从Windows的搜索谈起

正则表达式是进行文本处理的工具。那么,它到底进行哪些“处理”?简而言之,正则表达式的主要功能就是对文本进行查找(匹配)和替换(修改)。在这一章里,我们先从最简单的文本查找说起。
正则表达式所“搜索/查找”功能的对象,就是我们说的“文本”——它可以是Word文档、Excel表格、浏览器看到的网页等等,也可以是文件名(工作日报20090925.doc)、电话号码(400-82055555)、电子邮件地址(somebody@someone.net)等等。所以也有这样一种说法:正则表达式处理的是“字符串”——也就是一系列的字符。想想也是,Word文档的内容、Excel表格的内容、网页的内容、文件名、电话号码、电子邮件等等,无非都是“连接起来”的字符,也就是“字符串”了。
几乎每种文本处理工具(Word、Excel、记事本、写字板)都提供了查找(和替换)功能:


图1-1 Word中的查找

(more…)

按:《精通正则表达式》是一本好书,我翻译之后,一直都奢望写本关于正则表达式的书,为《精通正则表达式》接上地气,今年终于有机会把“奢望”变成“苦差”。下面是本书(暂定名《正则表达式傻瓜书》,大家对此有意见或建议也请直说)的前言,其中介绍了本书的结构、读者和价值,请大家多提建议,在这里先行谢过。

前言

正则表达式简介

“正则表达式”,这个名字看起来有点古怪。不过别着急,我们先看看它到底是有什么用,再解释这古怪名字的来历。

简而言之,正则表达式就是一套专门处理文本的强大工具。“学术”地说,它能够做的事情主要是:

  • 复杂的文本查找/匹配/提取
  • 复杂的文本替换

请注意,这里说的是“复杂”的操作,而不是“简单”的查找/匹配/提取/替换(几乎任何一种文本处理工具,例如Word和记事本,都提供了这种功能)。或者,通俗地说,正则表达式能够做的事情是这样的:

如果你是一般用户:

  • 把多行的文本迅速拼成用逗号分隔的一行文本(群发邮件时这非常有用);
  • 把一长篇文章里的手机号码都找出来(除了匹配13x15x18x开头的号码,还可以处理开头有‘0’和/或有‘+86’的情况);
  • 把一篇文章里可能拼写错的某个单词。比如把separetesaparatesaperete之类“自动纠正”到separate,而且不受大小写限制(seParate, separaTe也可以纠正);

如果你是专业用户:

  • 验证用户输入的手机号、邮件地址是否合法(还记得填写网页表单时常见的提示吗?);
  • 提取网页源代码中的所有图片链接、超链接(搜索引擎就是这么干的);
  • 提取文本中的邮件地址(现在你知道自己的邮件地址怎么被“抓”走了吧?);
  • 进行复杂的格式检查(把各种小数“统一”成精度为0.01的格式,去掉重复的单词);

这样的任务可能并不是我们日常工作的主要内容,“不幸”遇上了却非常烦人——简单重复劳动往往要耗费我们大量的时间。所以,在《卓有成效的程序员》(Neal Ford著,机械工业出版社2009年版)中,作者写道:

在我刚才提到的例子中,开发人员用了1小时58分建立正确的(正则表达式)语法,然后用了不足两分钟运行。在一些未曾培训过的人眼里,他的大多数时间都没有效率(这就是为什么他们反对使用正则表达式的原因),但最后,他节省的是几天的时间!

正则表达式还可以玩出更炫更酷的花样;不过现在,你只需要记得一点:不管任务有多么复杂,多么“不可思议”,只要掌握了关于正则表达式的基础知识,就能“以不变应万变”。这有点像搭积木,如果你学会了搭积木,就能随心所欲地搭出各种结构。而这本书的目的,就是教会你“搭积木”,也就是学会正则表达式;如果加以锻炼,相信不久你就能游刃有余地解决各种古怪的问题了。

现在我们回头说说正则表达式的古怪名字。我估计,古怪主要的原因来自“正则”——我们的生活中很少见到“正则”这个词。其实,“正则”的原文是英文单词regular,也就是“规则”、“规范”的意思。谈到这个regular,就必须提到一个概念:“正规语言(regular language)”,概略地说,“正规语言”就是严格遵照一系列规则构造出来的“语言”(不同于规则模糊且“可能出错”的自然语言)。“正则表达式”的“正则”,也就是这个“正规”的意思,它可以进行精确(很细致但也很“繁琐”)的描述:举个例子,我们都能一眼判断出,一串字符是不是“邮政编码”,但用正规语言来描述,大概是这样的——“邮政编码是前后相连的六个十进制数字字符(也就是说,每个字符都是0123456789之一),而且在这六个字符前后不能再出现数字字符”,如果我们能这样“规范”地表达自己的意图,计算机就可以匹配邮政编码字符串了。正则表达式的功能之所以强大,正是因为它可以“正规(规范)”的方式进行精确的描述/表达自己操作文本的意图——有了规矩才有方圆,计算机才能完整准确“理解”我们的想法。

回过头来,无论你看“正则表达式”这个名字是否顺眼,现在只要明白它是用来处理文本的强大工具,就可以了。

谁适合阅读这本书

本书名为《正则表达式傻瓜书》,并非假设读者都是傻瓜,而是保证“傻瓜都能看懂”。从这个定义出发,我们假设读者对正则表达式没有任何基础。如果您真的“不幸”成为其中一员,那么恭喜你,整本书都是为你而写的,如果你能循序渐进,一路修炼下来,一定能把正则表达式玩弄于股掌之间。

如果你之前已经稍微了解了正则表达式,那么更要恭喜你。我发现,许多接触过正则表达式的开发人员,并不真正理解正则表达式。要用的时候,他们往往从网上搜索一个正则表达式应急,如果不能用就改改——却往往被“这个字符是否要转义呢?”、“这门语言是否支持这个功能”之类的问题困扰。如果你能细心读完本书的基础章节,一定能厘清概念、正本清源,功力再上层楼。

如果你自认为在这两种人之外,或者毫无兴趣,也不必“自绝于”本书。你可能会在很多地方遇到正则表达式:你的浏览器是否有插件屏蔽某些网站的广告?如果有,你想不想设定应当屏蔽“哪些”广告?你在访问一些网站时是否遇到了困难,而需要为“某些”网站设定使用代理服务器?如果是,那么你不妨学一点正则表达式。俄罗斯有句谚语是这么说的:年轻人,多学一点本领总不是坏事!

学习方法

关于正则表达式,最重要的概念就是“规定可变的范围”:它匹配和处理的文本的是“变化”的(如果你只想寻找“中华人民共和国”之类的固定字符串,直接进行简单的查找就是了;电子邮件地址则不同,它的样子千变万化,这时候就得正则表达式上场了),但这些“变化”又必须遵循一定的规则(“电子邮件地址不就是“用户名 + @ + 主机名”嘛,超文本链接不就是“http:// + 主机名 + 路径 + 参数[可能出现]”嘛,而“用户名”、“主机名”之类都有明确的规定:可以按什么次序,出现什么字符),只要想明白了这回事,再弄明白正则表达式的规则和门道,把这些“变化规则”准确描述出来,就可做到“万变不离其宗”——任文本的形式怎么变化,都逃不出你的手掌心。

要学会正则表达式的规则和门道,可以分三步,据此,本书也分为三个部分:

第一步,基础,提供“入门”和“基础”。如果你从未接触过“正则表达式”,我们将从最简单的通配符的概念介绍起,帮你建立最基本的感性认识,并介绍正则表达式中最最基本的功能,它们不但可以用在编程语言里,也可以应用在平常的工具中。所以,看完这一部分,你应该能了解最基本最常用的关于正则表达式的概念,并把它们应用的日常工作中去。

第二步,进阶,在这里,我们会跟进一步,介绍普通文字编辑软件没有提供,但正则表达式中常用的重要知识、譬如多选结构、分组等等。并辅以恰当的例子,让读者通过对比,深刻牢固地认识这些概念。可以说,如果能充分认识、恰当运用这些概念,就能完成80%基本的字符处理任务,这也是本书的重中之重。

第三步,深入,向读者介绍更复杂、更高级的功能。包括其它类型的量词、匹配模式、锚点等,并会讲解一些常见的应用思路。了解了这些概念,你就能玩出更炫更酷的花样,也能解决更复杂、更罕见的问题。另外,在本章,我们会简单介绍不同的语言对于正则表达式的实现,以及各自的特点。

对于一般人,掌握这些已经完全足够了,如果学完这些,你还不满足,要“百尺竿头更进一步”,推荐你阅读本人翻译的《精通正则表达式(第三版)》(Jeffery Friedl著,电子工业出版社2007年版)的高级内容,相信你一定会有新的收获。

本书的价值

可能有读者会问,现在关于正则表达式的书那么多,有《精通正则表达式》,有《正则表达式必知必会》……为什么还要有“傻瓜书”?

确实,为什么要有“傻瓜书”呢?我学正则表达式的时候,也就是生吞活剥了《精通正则表达式》的影印版,就大致掌握了这东西嘛。

不过,在后来的开发中,我逐渐发现,对于处于开发前线、需要亲手写正则表达式的广大同行,从阅读关于正则表达式的经典作品,到熟练解决手上的难题,还有一个艰难的过程。比如,我曾遇到过这样的任务:要把一段文本里的“湖南株洲”智能地替换为“湖南省株洲市”,简单的文本替换在这里是行不通的,因为原文中可能也存在“湖南株洲市”,简单替换之后就成了“湖南省株洲市市”(出现了两个重复的“市”)(程序员可能会说,用程序检查“株洲”之后的那个字符就可以了嘛,但这是不行的,因为可能遇到越界错误:如果文本最后的两个字符就是“株洲”,后面不存在任何字符,检查“后一个”字符的程序就会报错退出)。再比如,不同的语言/环境在对正则表达式的支持上也有细微的区别,许多时候我们明白“理论上”应该怎么做,但实际操作起来又有诸多掣肘(譬如在ApacheRewrite规则中,怎样用一条表达式匹配“除aaa.somesite.combbb.somesite.com之外somesite.com的所有子域名”呢),该怎样绕过它们,很多书都没有讲,只能依靠猜测和经验来解决。本书在讲解相关的知识点时,会尽可能贴近实际的应用,举出针对具体开发环境的例子,降低大家从“阅读外版书借鉴国外经验”到“消化、吸收,应用到具体开发”之间的学习成本。

另一方面,不少关于正则表达式的书籍往往追求全面,把各条知识事无巨细地罗列出来。然而广大应用正则表达式的人员,却不太可能有精力通读这些“百科全书”,对他们来说,最重要的就是在遇到问题的时候迅速地找到最合适表达式,或者看懂某个复杂的表达式,加以改造,服务于自己的工作。这一点,我自己也深有体会。因此,本书会着重讲解一些常用的正则表达式,并提供它们在各种语言中的版本,并讲解一些常见问题的解决思路(常见的“与、或、非”的逻辑要怎么表达,掌握了这些,你就可以解决“长度在8到16之间,同时包含字母、数字、符号的密码字符串怎么用一条正则表达式验证”的问题了);即便您找不到直接使用的例子,也可以触类旁通。从某种意义上说,您也可以将本书放在案头,当成“正则表达式速查手册”。

最后,在《精通正则表达式》中文版出版之后,我收到了许多热心读者的来信,也看到许多读者的评论。有不少读者觉得,《精通》一书确实不错,但详略安排可以更好:许多简单的问题往往花费了太多时间,生怕读者不懂,而复杂问题的讲解又不够到位,读来总有十全九美的遗憾;也有读者觉得,《精通》的篇幅太长,价格太贵,并非人人都要“精通”,降低点成本,“够用”就好。有鉴于此,我会努力根据读者的意见,尽力调整这本书的详略安排。当然,贯彻始终的原则是“简明扼要”。毕竟,学习正则表达式就是为了节省时间,如果让读者在“不值得”的内容上浪费时间,就违背了本书的写作初衷。

勘误

我向读者保证会尽力避免犯错,但是我不敢保证这本书里没有错误。所以,如果您在阅读时发现有错误,请一定来信告知,您的意见,经过确认,会进入勘误列表,并在下次重印时进行订正。当然,我也欢迎您来信告知建议、感想。我的电子邮箱是 yusheng.regex@gmail.com,诚挚地等待您的邮件。