上周在深圳见朋友，聊天时仍然把“正则表达式”和我联系在一起，这真让人惭愧，因为我已经很久不写正则表达式了，甚至有些生疏。估计是Jeffrey Fridel的《精通正则表达式》写得太好，身为译者的我也沾了不少光，收获不少虚名。为避免误解，撇去虚名，有必要专门写写我和正则表达式的故事。 我和正则表达式的缘份，始于我的第一份工作。那时我刚刚离开学校，除了在学校里认真写过些程序实现书上的理论和练习，根本没做过实际的项目。找工作当然也不顺利，尤其不是北京的高校毕业，在北京找工作更加困难。好不容易找到一家公司愿意收留我，周四上午面试、下午复试、周五就签合同，通知“下周一来上班”了。 我清楚地记得，上班的第一天，为了不让其他人看穿自己其实没有项目经验，我特意带了那本厚厚的影印版《the Java Programming Language》，一来充门面，二来也抱抱佛脚，之前在学校写的都是C++程序，Java确实不熟悉。而且，上午确实没太多事情干，这本书救了我的命。 好日子在下午就到了头，项目经理给我们做培训。当我满心欢喜地参加培训，希望通过培训来“软着陆”时，等来的却是高强度的信息轰炸：一小时内讲完了JBuilder、JUnit、Ant三样东西，我完全没有接触过，但公司要求“明天就开始使用”。读书时虽然不排斥学习新的知识，毕竟习惯“循序渐进”，这种“培训”闻所未闻，结束之后只觉得大脑一片混沌。在QQ向同学吐槽说“公司这么不讲道理，纯粹血汗工厂”，答复却出乎我的意料：“赚翻了，赶紧学，我们想用还不让用呢”。在当时，被“堵”的感觉特别糟糕，但转念一想，这么说也有道理，所以我拼命忍住反感，硬着头皮学习。 (more…)
最近有幸在开源中国和51CTO两家网站作为嘉宾参与了于正则表达式的专题问答。在问答过程中，我收集到学习正则表达式过程中的某些普遍问题，在这里专门花一点篇幅来回答 正则表达式是难学的，这不存在疑义。但是我认为，难点也只在语法方面。正则表达式已经有年头了，它（的语法）诞生于上世纪七十年代。那是个怎样的情景？举个简单的例子吧，Unix下的usr、dev等名字，就是那时留传下来的，现在已经有很多人诟病了，usr不是user，dev不是device，难学，也难记。经过这些年的飞速发展，当年的很多问题已经被包装得美轮美奂，如今的用户可能更习惯直接点击“用户目录”、“驱动器”之类的图标，再也不用为那些不规则的简短名字发愁。但是不幸的是，一直以来正则表达式的语法却没有太多的变化，甚至后续增加的功能，也沿袭了之前的语法风格，在编程语言日渐人性化的今天，它自然显得非常难懂了。今天的开发人员可能更习惯Regex.CharRange('a', 'z')这样的写法，而不习惯[a-z]；遇到(?![a-z])这样的结构就更是抓瞎，除非转为Regex.CheckRight(Regex.CharRange('a', 'z'))的写法。 不过，换一个角度来看，两者其实是一回事，只是表现形式不同，一个类似要诀，一个类似大白话。如果我们能在头脑里构建出从要诀到大白话的转换，正则表达式就简单了许多，甚至可以说就是模块的拼接。比如支付宝的流水号为18或26位数字，用正则表达式匹配，就是^([0-9]{18}|[0-9]{26})$，或者^[0-9]{18}([0-9]{8})?$。其中的逻辑很简单：^用来锁定开头，$用来锁定结尾，[0-9]匹配数字字符，([0-9]{18}|[0-9]{26})表示两个并列的选项，即数字字符串长度为18位或26位，而[0-9]{18}([0-9]{8})?表示至少需要出现18位的数字字符串，在这之后可能还有一个8位的数字字符串（所以总长度是26位）。一般的正则表达式应用，就是这么简单。 如果你觉得上面说的没错，那么学习正则表达式的难题就只剩下了选择得当的方法。我们学习编程语言时，都强调不能只看书，要动手写程序，甚至最好的办法是把书上的例子亲自输入运行一遍，这样才算真正学会了。但在许多人眼里，正则表达式或许算不上编程语言，所以学习是点到即止，甚至是满足于从网络上抄一些现成的表达式。所以，常见的问题之一是“有没有什么学习的捷径”，很不幸，答案是没有——既然拷贝他人的代码不能学会编程，抄阅现成的表达式、随便翻几篇文档，当然也学不会正则。不过也有幸运的消息，真正学会正则表达式并不需要花太长的时间。 以我的经验，学习正则表达式，真正要做的是深入理解常用功能：字符组、多选分支、匹配模式、环视。可以说，弄明白了这几点，80%的正则问题都可以解决。但是要弄明白这几点，就需要专门的学习：字符组是解决什么问题的，它是怎么使用的？多选分支是解决什么问题的，它是怎么使用的？应当抽一些时间专门学习、思考；这些都弄明白了，再研究解决复杂问题的表达式是怎么构成的。如果你可以每天抽1-2小时专门学习，两周内就会有明显收效，一个月几乎就可以修炼到相当水平。而且，以我的经验，在学习新的编程语言时，不但要把书上的例子都亲自输入运行一遍，更要自己动手去改一改示例代码，看看会出现什么现象，再想想为什么会这样。如果你在学习正则表达式时也做到这一点，必然能够事半功倍。 如果你真正理解了这些常用功能，对它们的价值和使用有清晰的概念，那么另一个麻烦也就迎刃而解了——不同语言的正则表达式不同，如何解决？虽然不同语言中的正则表达式规定各有不同，但背后的思想是统一的，不同的只是表现形式，或者说概念的落地方式。好处在于，编程语言的文档不会详细讲解什么是字符组，什么是多选分支，但会详细告诉你字符组在本语言中是如何表示的，多选分支又是如何表示的（不信你可以在这些文档中搜索character class或者alternation）。所以如果你的脑子足够清楚，即便不确定最终的表达式如何写，也只需要查文档就可以解决。举个例子，匹配空白字符的字符组\s，在Java字符串中要写作\\s，因为\s并不是Java字符串中的一个合法转义序列，所以之前还必须有\来转义\；在PHP中可以直接写作\s，因为PHP处理字符串时会把无法识别的转义序列原封不动地保存下去；在Unix下的某些工具中，必须写作[[:space:]]，这是Perl风格的\s在POSIX规范中的表示法。看起来比较麻烦，也仅此而已，因为我们知道，这里需要用到的，就是“匹配空白字符的字符组”。 以上写了这么多，可能有人会说：正则表达式这东西，不登大雅之堂，没必要花那么多精力。或许正是这种观点，形成了“不认真学习正则表达式”思想根源。幸运的是，这个问题其实很好想明白，因为很多事情都是这个道理。比如写文章，我们不要求人人都是作家，但是人人都有可能在需要的时候写出几篇拿得出手的正经文章，“不是作家”并不是“需要时写不出正经文章”的理由。为了能在需要的时候写出正经文章，就必须专门抽出时间来学习和练习写作。正则表达式的学习，其实也是这个道理。 这种说法可以说服一些人，但还有一些人是说服不了的。同时据我观察，那些不能被说服的人，似乎也没有花太多精力在其它“正事”上，反而会不时为正则表达式所困扰。与此相反的是，真正有职业素质的程序员，就像the Productive Programmer中说的那样，会愿意花2小时写出一个正则表达式，为以后节省无穷无尽的时间。当然，以上说的这一切的前提，都是能端正学习正则表达式，或者说学习有价值技能的的态度。做软件的人大都读过布鲁克斯的名文《没有银弹》，所以这里不妨借用他的话说，正则表达式的学习，也不存在银弹。
前言 提到正则表达式，许多人很有点不屑一顾：这东西，不登大雅之堂，再说也不是总要用到，何必专门花时间学习？ 没错，正则表达式并不是“总要用到”，但到了需要的场合用不上，往往产生“一分钱难倒英雄汉”的尴尬。经常需要处理文本的程序员自然会知道正则表达式的价值，其它的程序员如果不会正则表达式，即便开发的领域与文本处理没什么关系，也难免“躺着中枪”的命运——前几天我遇到一个问题，将一行长长的地址拆分成多行，负责这部分的程序员日常的工作只是制作PDF而已，拆分地址是很“边缘”的功能，但不会正则表达式就无法准确折行（一般需要在标点符号出现的地方折行，而不能只在空白字符处折行，但是不同语言中的标点符号各有不同），结果一筹莫展；相反，如果了解正则表达式，就可以很容易地处理各种语言中的标点字符。 以我的开发经验来看，专门花点时间掌握正则表达式，确实是非常有必要的。目前可以见到的关于正则表达式的书籍和资料已经有不少，但又各有不足。 在互联网上，流传着一些编程语言的正则文档和《30分钟教会你正则表达式》之类的帖子。这类资料的好处是简单直接，查到了，如果有现成的例子，而且适用于自己的语言，可以直接拿来用；然而，其坏处也是简单直接，因为缺乏背后原理的讲解，如果找不到现成的例子，或者找不到能在自己所使用语言中行得通的例子（须知道，同样的正则表达式并不能直接套用到不同的语言中），则束手无策。 在正式的出版领域，已经有《精通正则表达式》、《正则表达式必知必会》之类的书籍出版，尤其是前者，堪称关于正则表达式的经典著作，如果想认真学习正则表达式，这类书籍是必须阅读的。但是这类书籍也有一个弱点，即它们都是从英文版本翻译而来，更多地侧重英文文本的处理，身为中文世界的开发人员，我们经常需要处理中文文本，对于处理英文之外的字符，正则表达式已经提供了足够丰富的功能，但如何用对、用好这些功能，资料却很匮乏。 我经常需要给人讲解正则表达式的相关知识，时常惋惜的是，开发人员为这些问题所困然；正因为如此，本书的写作动机便是着力弥补现有资料的缺陷。 相对于正则文档和速成教学帖子，它深入讲解了匹配背后的原理，往往会举一反三，告诉读者，这里为何这样写，如果改成其它形式，会造成什么结构；并且，集中讲解和比较了多种语言中正则表达式用法的异同，方便读者把现成的正则表达式“移植”到自己的工作环境中。 相对于《精通正则表达式》等正式的书籍，本书辟出专门的内容讲解语言和编码，告诉读者如何设定编码，如何正确处理中文等字符，另外，本书还涵盖了.NET、Java、JavaScript、PHP、Python、Ruby六种常用语言，对每种语言给出专门章节，不但详细介绍了语言中正则表达式的用法，更点明了版本之间的细微差异，不但可以作为专门学习的教材，还可以成为有用的参考手册。 本书的结构 本书可以分为三大部分。 第一部分主要讲解正则表达式的基础知识，覆盖常见正则表达式中的各种功能和结构。看完前面三章，就可以基本弄明白现在流行的各种正则表达式；尤其如果你之前有一些经验，会觉得阅读起来并不困难。但是我也希望读者不要忽略其它的内容，断言和匹配模式现在已经是正则表达式的“标准配备”了，而且确实可以派上大用场，所以第4章和第5章的内容，即便不是很熟悉，阅读起来可能有一些麻烦，也不应该忽略。最后的第6章，则厘清了正则表达式在使用中的若干疑惑，了解它们，你就可以相对自由地在正则表达式的世界里行走了。 第二部分主要讲解关于正则表达式的更深入的知识，这一部分用三章的内容，详细探讨了编码问题、匹配原理、解题思路。这部分内容更抽象，需要多花一点时间来阅读和理解，但是它们确实可以帮你在正则表达式的世界里登堂入室，脱离“术”的层面，掌握万变不离其宗的“道”。 第三部分的作用是接地气，将之前介绍的各种知识落实到六种常用语言.NET、Java、JavaScript、PHP、Python、Ruby中来。每一章的开头有正则功能列表，其中的功能都对应到前面部分的讲解，这些功能的具体应用实例，以及不同版本之间的差异，则在章节中详细讲解，每一章的最后还给出了常见任务的示例代码，方便日后查询。在最后，第16章简要介绍了正则表达式在Linux下常用工具vi、grep、awk、sed中的使用，并通过一个实际的例子将这几种工具串起来，对比说明了它们适合解决的问题。 在本书的最后提供了用作参考的附录，分为三部分。 第一部分是正则表达式的常用功能在不同语言中的比对，希望能给需要在多种语言中使用正则表达式或者移植正则表达式的读者来说提供一份有用的参考；第二部分给出了若干常见的正则表达式，比如匹配邮政编码、身份证号、手机号、QQ号、电子邮件地址等等，希望能成为常见问题的“速查手册”；最后一部分列出了常用正则表达式的工具和资源，方便大家调试自己的正则表达式，以及继续深入学习。 本书的读者 本书适合以下几类读者。 经常需要进行文本处理（比如日志分析或网络运维）的技术人员。这些读者或许已经熟悉了正则表达式的基本用法，但面对日益复杂化和海量化的数据，阅读本书可以帮助你更准确、更高效地处理文本，提升自己工作的价值。…
许多年前，我第一次读到《第三次浪潮》，里面有一句话非常激励人：在第三次浪潮面前，知识已经取代了资本，变为生产力提升的最重要因素。我读到这个观点，总觉得平添了无穷的力量，它比从小就耳熟能详的“知识就是力量”更加有说服力，更令人向往。 而且，我逐渐发现，知识与资本相比，其实是一种更独特，也更坦诚更健康的力量：资本的力量往往是独属于个人，或某个小团体的，固守起来，价值并不会贬低，知识却不是如此，知识的价值和增值，更多体现在交流与分享之中，“保守秘密“的做法，反而得不偿失。 举个自己经历的例子吧：上中学的时候，有一些同学对自己使用的复习资料守口如瓶，似乎这样就可以保住自己的名次和优势，我当时觉得这类做法有点奇怪，但也有朴素的味道，可以理解。 到了大学才发现天外有天，更深刻觉得这种做法真是不太好。一来因为大学里能人太多了，在中学觉得很“了不起”的东西，在大学显得非常稀松平常，往日那些“绝学”立刻显得很苍白了；二来大家都住校，基本没什么秘密可言，你看什么书，花多少精力学习，旁人不可能完全不知道。“固守自己绝技”或许能建立一些的优势，但总的来看，还是不如心态开放、愿意交流和分享的同学，尤其是，不少愿意分享的同学本身也学的很不错。 毕业以后工作了，逐渐发现自己经常在某些方面浪费了很多时间：比如非常简单的技术问题，因为不熟悉，或者没有想明白，总是“不得其门而入”，若有人点拨，往往很快就能解决了。但许多时候，人家“就是不告诉你”，甚至自己就“觉得”人家不会告诉，因而都不好意思去问。 2007年，我翻译了《精通正则表达式》，此后常常遇到各路朋友关于正则表达式的问题。平心而论，我也只是用过一点正则表达式，多一点经验而已，而且正则表达式，实在不是什么高深的技术。但是，我却发现不少朋友乃至技术高手所问的，往往多是这类看来比较简单的问题，只是没有遇到过，或者不熟悉而已，所以他们也“不得其门而入”。换位思考，我逐渐体会到，简单的问题，解决起来未必简单，其实是因为“术业有专攻”而已。没有人能做到面面俱到，即便是某个领域的行家，在不熟悉的领域，也难免被简单问题困住——我问他人的问题是如此，他人问我的问题，也是如此。 或许，也正是因为有这样的情境，“固守自己绝技”的做法，才体现出价值？我不知道。 可是再后来，见的再多一点，读的书再多一点，我却越来越否定“固守自己绝技”的做法了，因为无论从个人，还是从社会来说，其实都是得不偿失的。 从个人来说，长期来看，我们的脑细胞一直在不断减少，但智力却没有明显的下降，甚至会上升。这是因为，通过不断的学习和思考，脑细胞的突触会增加，脑的结构也会不断变化，知识体系的索引结构也在不断优化。所以，质量的提升取代了数量的下降（可以参考Richar Restark博士的Think Smart）。而固守自己绝招，不愿与人交流的人，大都满足于守住自己的一亩三分地，却忽略了不断的学习和思考。这样的生活，或许过得确实“不错”，无可厚非；但我相信，在另一个平行宇宙中，很可能有一个同样的人，却更善于学习新知识、思考新问题，他的生活，或许“更不错”。我想做的，是那个“更不错”的人。 从社会来说，一个社会要想运转正常，让成员生活幸福，必须是一个足够有效率的社会。分属熟悉不同领域的人，通过交流知识，节省了彼此的时间，这就是为社会的效率做出了贡献。也就是说，作为社会的一分子，我们所能利用的他人的知识越多，这些知识的质量越高，利用的难度越低，我们自己工作生活的效率就越高，他人为我们提供服务的效率也就越高。伟大的经济哲学家哈耶克早就发现，社会中除了存在劳动的分工，还存在知识的分工，社会发展、达致均衡的过程，就是把分散在个人之间的知识顺利协调起来的过程。 就我对中文技术资料的了解，哈耶克的观点真是伟大的洞见——网上的中文技术资料，细心整理的很少，“无责任转载”居多，即便有交流，许多也局限于小圈子的彼此欣赏。其直接后果，就是大家时常为了一个简单的问题费尽周折，也导致论坛里总是出现重复的问题……中文开发世界的整体水准不尽如人意，缺乏高质量的知识协作，肯定是原因之一。 故而，我时常为自己没有能迅速发现和利用其它知识，浪费了时间而惋惜，同时也为被正则表达式困扰的朋友而惋惜；基于此，就更加感激坦诚贡献自己的知识，指点、帮助我解决不熟悉领域问题的朋友。所以，我要把自己关于正则表达式的经验悉数总结出来，整理好，写成一本书。它或许比不上《精通正则表达式》，但终归是自己的知识总结，除去讲解了功能，还点出了自己学习时犯过的错误，更提供了常见开发问题的解决方案：正则表达式问题的分类和解决步骤、URL转发的规则、中英文混排文本的处理、正则表达式中使用Unicode的细节…… 其实，这也是我长久以来的梦想：我不希望看到更多的朋友同仁，为了这类已经有现成答案的问题，再浪费时间和精力，尤其是在大家生活压力都很大的今天。我可以尽力为大家写各种表达式；但我更希望这本书能成为“木牛流马”，跨越时空的距离，为更多的人送去便利。当然，其中也有一点私心——如果这本书真的能帮到大家，它也可以分担我亲自帮各位同仁解决正则表达式问题的压力；这样，我也有更多的时间，再学点新知识，再思考点新问题罢。
今天我的同事老赵 @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之间“可能”出现的是：u或har或onduc或our。 遇到这种情况，就不应使用字符组，而应当使用多选分支『(…|…)』，将各个“可能选项”列在多选分支中。于是，正则表达式变为『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』。…
今天金山的刘鑫老师在邮件里谈到了“工程师思维”（工程师的思维能力，就是一种可以把想法实现出来，一步步的变成现实的思维和实践训练），借题发挥一下吧。 我上高中的时候，学校算是本市最好的中学，班主任物理老师也是特级教师，但我一直不是觉得，他讲课说不上多好，无非是循规蹈矩的套路，甚至有点死板——就拿受力分析的题目来说吧，多简单的题目，都要画坐标系，而且就只有那么几个力：重力、摩擦力、牵引力等等，来来去去地分解，真是麻烦，许多题目明明一眼就能看透的嘛。 到我大学快毕业的时候，辅导一个小朋友做高中物理题，忽然就让我改变了之前的看法：那是个很简单的问题，物体在斜面上的受力分析，我问他：这个题目要怎么想呢？出乎我所料的是，他胡乱画出了一堆力：扯力、顶力、拉力… 就在那一瞬间，我明白了，我们的物理老师的做法有多么高明：复杂问题是不能单纯依靠直观思维来解决的，我们往往需要从简单的情况中提炼出章法，再循序渐进，把章法练到纯熟，这样才有能力解决更复杂的问题。物理老师那看似繁琐的重复，其实就是在培养章法，把握问题的核心——做到了这一点，再复杂的问题，都可以一眼看到本质，而不会困扰、迷惑。 可惜的是，这样的思维和习惯，似乎还没有在我们身边扎下根基。我目力所及，看到的很多问题的解决方案，很多教育、探索和反思还只停留在对天赋、才气的吹捧和推崇上，而没有强调练习章法、探究规律、把握本质的工作。可是，才气、天赋等等都是太微妙的因素，难以把握，无法复制，也不易推广，甚至很可能遗失——研究中国古代科技史的李约瑟博士就指出，中国古代的发明有个特点是“重复发明”，前人发明了某件东西，后人不重视，于是失传了，直到许多年后，再由后人发明…… 在这方面，西方似乎比我们做的好得多，他们会有人不满足于直观的思维，努力探究日常生活各种现象背后的原理，总结出不依赖“才气”、“天赋”的章法，再经由一代又一代的人传承、积累，结果知识与生产力就像滚雪球一样，越来越多，能量也越来越大。 再举个例子，小时候我做过不少“智力题”：比如几个人各说了一句话，其中几个人说了真话几个人说了假话，让你判断到底谁说了真话谁说了假话；又比如河上有一条船，河边有狼、羊、人、草等等，一次只能渡两样过去，要怎样安排顺序，才能全部安全渡过去。这样的问题，我有一段时间做起来很快，也尝试总结过一些思路，但还是碰运气、凭感觉的成分居多，而且，这样的习题书，也没有告诉我们应该怎么解这类问题，它的本质是什么。直到后来学了离散数学，我才恍然大悟：第一个题目其实就是真值表，第二个题目其实就是图算法。问题提炼到了这个层面，就有现成的章法（或者说“套路”）解决了，再不需要什么才气、天赋：天赋再高、才气再旺盛，也无法大规模推广，也快不过计算机。于是，普通人也可以解决这类问题，其他人（也包括我们）的精力就不用再耗费摸索这类问题的答案上，而可以探索更加深入、更加新鲜、更有价值的问题。 我们还可以再举一个身边的例子：西方的很多书中，一个简单的道理，往往要翻来覆去地讲，非要把各个细节、各种情况都涉及了，才善罢甘休；许多人觉得很罗嗦、很累赘，他们关心的是“正对我胃口的知识”、“核心的结论”。但是，如果有时间认真研究这些细节，了解了各种情况，往往可以站在一个更高的角度来审视这些“核心的结论”，对它的认识更加全面——不但知道价值在哪里，也知道局限在哪里。 其实，这也是我当年阅读《精通正则表达式》之后的体会，在细细阅读了整本书之后，我不但了解了各种功能，用正则表达式解题的一般套路，也知道了在什么情况下要使用什么功能，更知道了什么情况下不应该使用正则表达式——这样的知识，很多就来自书中那些“繁琐”的内容。 正是因为有了这样的体会，我也奢望为大家提供一些这样的便利：《怎样翻译更地道》系列文章尝试总结一些应对翻译难点的通用套路，希望读者遇到这类问题时，查到对应内容就可以解决；《正则表达式傻瓜书》希望重点讲明白的（也是本书的重点），不但有各种功能的应用场景和选择规则，还有正则表达式解题的思维步骤：归纳一个应用场景的文本特征（转化为对正则表达式的需求）；照这些特征一一写出子表达式，合理组合起来；最后优化整个表达式。掌握了这三步，并有意训练，就可以熟练准确地运用正则表达式，解决各种问题。 希望我可以努力做到。
这两天，我的同事丁宇（@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])』，显得很累赘，所以优选第二种方法。 好了，四条要求已经分别解决完毕，现在我们把它们组合起来。…
上一章，我们通过Word中的“使用通配符”模式，粗略见识了正则表达式的使用方法。然而通配符并不等于正则表达式，遇到复杂的情况，通配符就力不从心了。所以从本章开始，我们来看“正宗”的正则表达式。 安装Regular Expression Tester “工欲善其事，必先利其器”，学习正则表达式也是如此。尽管正则表达式的思想和规则是基本确定的，应用起来却有许多讲究（比如，在Java、C++、Python等不同的编程语言中，同一个表达式的具体写法是不同的，在Word、Excel等软件中也是这样）。所以，学习正则表达式最好采用“中立而规范”的工具——这有点像学习摄影，开始应该学习的是构图、用光，而不是尼康、佳能或索尼相机的特性。 本书中，我们采用Firefox的插件Regular Expression Tester（意思是“正则表达式测试工具”）来学习和讲解正则表达式，选择它的好处在于：不需要搭建编程语言环境（许多时候我们并不需要在编程语言中应用正则表达式）；在Windows/Unix/Mac上都可以使用；并且支持大多数通用的正则表达式功能。如果你没有接触过它，也不用担心，下面我们介绍它的安装和使用。 (more…)
老话说“业精于勤，而荒于嬉”，这是非常对的。许多朋友认为我写正则表达式很有经验，其实不然，我虽然翻译《精通正则表达式》，其实自己写正则表达式的机会并不多，充其量是帮朋友写写一些“够用就好”的表达式，在“精于勤”的朋友面前，是不值一提的。 相反，2010年1月11日晚我在上海龙阳路地铁站附近见到的两位朋友rex和cnhacktnt，都是“精于勤”的榜样：因为工作的原因，他们几乎每天都需要用到正则表达式，所以他们几乎是“全方位地”精通正则表达式：对语法的精确把握，对未知情况的处理，对匹配效率的要求……或许平时我们不需要注意这么多的方面，但多了解一点经验以供借鉴，总不是坏事。 举例来说吧：撰写高效率的正则表达式，需要注意哪些方面？更极端一点：正则表达式怎样匹配“0…1…”但‘0’和‘1’出现次数相同的字符串？这样的问题，对正则表达式没有相当研究和经验的人，是无法回答的。而答案和讨论，也让我这种半瓶醋看得眼花缭乱，大呼过瘾。 目前，国内已经有大量专业的开发论坛和社区，但是正则表达式这种“关键时候要命”的匕首式应用，总没有专门的场合讨论，这不能不说是一大遗憾。有鉴于此，rex同学开设了专门的正则表达式论坛 http://www.regex.me，大家有任何关于正则表达式的疑惑，都可以提问讨论，对《精通正则表达式》有什么意见，也可以自由发问，我会尽力解答。