为行文方便，先定义两个概念。

• 误匹配：指正则表达式所匹配的内容范围超出了所需要范围，有些文本明明不符合要求，但是被所写的正则式“击中了”。例如，如果使用\d{11}来匹配11位的手机号，\d{11}不单能匹配正确的手机号，它还会匹配98765432100这样的明显不是手机号的字符串。我们把这样的匹配称之为误匹配。
• 漏匹配：指正则表达式所匹配的内容所规定的范围太狭窄，有些文本确实是所需要的，但是所写的正则没有将这种情况囊括在内。例如，使用\d{18}来匹配18位的身份证号码，就会漏掉结尾是字母X的情况。

写出一条正则表达式，既可能只出现误匹配（条件写得极宽松，其范围大于目标文本），也可能只出现漏匹配（只描述了目标文本中多种情况种的一种），还可能既有误匹配又有漏匹配。例如，使用\w+\.com来匹配.com结尾的域名，既会误匹配abc_.com这样的字串（合法的域名中不含下划线，\w包含了下划线这种情况），又会漏掉ab-c.com这样的域名（合法域名中可以含中划线，但是\w不匹配中划线）。

精准的正则表达式意味着既无误匹配且无漏匹配。当然，现实中存在这样的情况：只能看到有限数量的文本，根据这些文本写规则，但是这些规则将会用到海量的文本中。这种情况下，尽可能地（如果不是完全地）消除误匹配以及漏匹配，并提升运行效率，就是我们的目标。本文所提出的经验，主要是针对这种情况。

1. 掌握语法细节。正则表达式在各种语言中，其语法大致相同，细节各有千秋。明确所使用语言的正则的语法的细节，是写出正确、高效正则表达式的基础。例如，perl中与\w等效的匹配范围是[a-zA-Z0-9_]；perl正则式不支持肯定逆序环视中使用可变的重复（variable repetition inside lookbehind，例如(?<=.*)abc），但是.Net语法是支持这一特性的；又如，JavaScript连逆序环视（Lookbehind,如(?<=ab)c）都不支持，而perl和python是支持的。《精通正则表达式》第3章《正则表达式的特性和流派概览》明确地列出了各大派系正则的异同，这篇文章也简要地列出了几种常用语言、工具中正则的比较。对于具体使用者而言，至少应该详细了解正在使用的那种工作语言里正则的语法细节。
2. 先粗后精，先加后减。使用正则表达式语法对于目标文本进行描述和界定，可以像画素描一样，先大致勾勒出框架，再逐步在局步实现细节。仍举刚才的手机号的例子，先界定\d{11}，总不会错；再细化为1[358]\d{9}，就向前迈了一大步（至于第二位是不是3、5、8，这里无意深究，只举这样一个例子，说明逐步细化的过程）。这样做的目的是先消除漏匹配（刚开始先尽可能多地匹配，做加法），然后再一点一点地消除误匹配（做减法）。这样有先有后，在考虑时才不易出错，从而向“不误不漏”这个目标迈进。
3. 留有余地。所能看到的文本sample是有限的，而待匹配检验的文本是海量的，暂时不可见的。对于这样的情况，在写正则表达式时要跳出所能见到的文本的圈子，开拓思路，作出“战略性前瞻”。例如，经常收到这样的垃圾短信：“发*票”、“发#漂”。如果要写规则屏蔽这样烦人的垃圾短信，不但要能写出可以匹配当前文本的正则表达式 发[*#](?:票|漂)，还要能够想到 发.(?:票|漂|飘)之类可能出现的“变种”。这在具体的领域或许会有针对性的规则，不多言。这样做的目的是消除漏匹配，延长正则表达式的生命周期。
4. 明确。具体说来，就是谨慎用点号这样的元字符，尽可能不用星号和加号这样的任意量词。只要能确定范围的，例如\w，就不要用点号；只要能够预测重复次数的，就不要用任意量词。例如，写析取twitter消息的脚本，假设一条消息的xml正文部分结构是<span class=”msg”>…</span>且正文中无尖括号，那么<span class=”msg”>[^<]{1,480}</span>这种写法的思路要好于<span class=”msg”>.*</span>，原因有二：一是使用[^<]，它保证了文本的范围不会超出下一个小于号所在的位置；二是明确长度范围，{1,480}，其依据是一条twitter消息大致能的字符长度范围。当然，480这个长度是否正确还可推敲，但是这种思路是值得借鉴的。说得狠一点，“滥用点号、星号和加号是不环保、不负责任的做法”。
5. 不要让稻草压死骆驼。每使用一个普通括号()而不是非捕获型括号(?:…)，就会保留一部分内存等着你再次访问。这样的正则表达式、无限次地运行次数，无异于一根根稻草的堆加，终于能将骆驼压死。养成合理使用(?:…)括号的习惯。
6. 宁简勿繁。将一条复杂的正则表达式拆分为两条或多条简单的正则表达式，编程难度会降低，运行效率会提升。例如用来消除行首和行尾空白字符的正则表达式s/^\s+|\s+$//g;，其运行效率理论上要低于s/^\s+//g; s/\s+$//g; 。这个例子出自《精通正则表达式》第五章，书中对它的评论是“它几乎总是最快的，而且显然最容易理解”。既快又容易理解，何乐而不为？工作中我们还有其它的理由要将C==(A|B)这样的正则表达式拆为A和B两条表达式分别执行。例如，虽然A和B这两种情况只要有一种能够击中所需要的文本模式就会成功匹配，但是如果只要有一条子表达式（例如A）会产生误匹配，那么不论其它的子表达式（例如B）效率如何之高，范围如何精准，C的总体精准度也会因A而受到影响。
7. 巧妙定位。有时候，我们需要匹配的the，是作为单词的the（两边有空格），而不是作为单词一部分的t-h-e的有序排列（例如together中的the）。在适当的时候用上^，$，\b等等定位锚点，能有效提升找到成功匹配、淘汰不成功匹配的效率。

总结完发现，《精通正则表达式》的第5章、第6章已经以更为有条理的方式总结出了常用的优化方法。不过，泛泛地读过的印象是肤浅的，过后即忘的；而真正若有所悟时在书上得到了系统地印证，这种感觉才是真的爽。

所谓正则表达式，其实是一种抽象，是从现有的文本中找到规律，然后用正则的语言描述出来。例如，上次有人问，以http开头的，以空格结尾的正则式如何写？这个问题不难，我们只要符合这两个要求即可，即^(http\S+)\s。至于http后面的冒号、双斜杠，都不必劳神去匹配。这样写出来的正则表达式简洁明快，清晰易读。当然，从效率出发，越精确的正则式越有利于尽早失败，有利于提升效率。权衡写的效率与执行的效率，其过程也是很不错的。

Regulator的界面，比Expresso要新潮，与以前介绍过的Mtracer有几分相像。看界面：

与Expresso一样，它同样支持.Net版的正则，支持将正则式导出为VB或C#格式。比起Expresso来，它的亮点之一是正则式部分支持语法高亮显示。

Regulator有一个功能是网络搜索，即支持在软件界面上直接搜索regexlib.com上的正则代码库。这原本应该是个很实用的功能。可惜的是，我在多种情况下（代理）试用了该功能，一直不能返回搜索结果。或许是随着时间的迁移，regexlib.com更换了查询输出接口，而Regulator还站在望夫涯上，傻傻地使用原来的方式与regexlib.com通讯，自然接收不到任何反馈。

帮助文件中的搜索结果列表：

这是在我的机器上返回的空列表：

我登录到作者Roy Osherove的博客，搜索到他的一些其它正则式项目，例如2006年10月份的Realazy（将普通文本转换为正则表达式的小工具，比较傻瓜），2005年11月份的VS2005下的正则式可视化工具（Regular Expression Visualizers for VS 2005），只可惜最近两年没有在正则式方面更新文章或软件。因此该软件估计以后也不会更新了吧。作为一款经典的免费的正则式软件，估计Regulator曾经风光一时；不过，在我接触正则式时起，一直用的就是Regex了。

最近搜集了一大堆网页正则式工具，有时间跟大家分享一下。敬请期待。

附：the Regulator 2.0 (3.2MB)下载地址：via sourceforge | via 深柳堂

最近拾起了以前的小项目，在完善上篇文章发布后，“那个谁”的回复让我很感兴趣。他问，“为什么不用xpath？”

xpath是什么东东？我反问。反问之前，当然少不了先google一番，以免……那个啥。

首先映入眼帘的是w3c ，对xpath的介绍如下：

XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer.

直译为中文就是，

XPath 是一种语言，用于在XML文档中定位各部分内容，可由XSLT或XPointer调用。

还搜索到xpath的教程，在这里。草草看过，当时并未着意。

虽如此，但是python里的minidom模块，也有此功效呀。为什么非要使用xpath呢？尤其是考虑到在python中还需要额外安装，不如minidom之放之四海而皆可运行。

跟那个谁再交流，意见仍是“力荐”。还推荐我细读教程，并在firefox里使用XPath Checker插件。

于是就照办了。

发硎新试,其快可知

一试XPath Checker，果然石破天惊。选中部分网页文字后，在右键菜单中选”View Xpath”，立即显示出该节点的XPath路径。层次清晰，定位精准。只是我对其语法尚未了了。于是细读教程，边学边用；半小时后，已经能够运用到之前写的饭否信息抓取程序上。虽然写代码还有些吃力，但是思路很清晰，不会纠缠于细节中无法脱身。

那个谁还提议，一般的html文档不是标准的xml文档，因此用xpath解析时，最好格式化一下。

我也注意到这个问题了。从饭否html中取出的有用内容，只占全文的一小部分；额外的部分白白拖慢速度，增强析取难度。

经过实验，我将原代码改进如下：

1. 仍用原来的minidom模块下载、分析文档，只取<ol>与</ol>之间的部分。这部分保存成字符串格式，备用。只取需要的那部分，使结构清晰，层次浅显。

2. 使用xpath来解析上一步取出的字串。

到现在，/，//，@，[]，=，等等，每个符号都从原来的meaningless变成helpful，在我的工具箱中有了合适的位置，随取随用，十分方便。我已经成了xpath的受益者。现在才觉得学习xpath真是很有趣、有用。

目前还有个小问题，无法使用纯粹的xpath语法解决。问题描述如下：

xpath只能解析实体内容，不能”囫囵吞枣”地解析。例如：

在view xpath 下，使用/li/a，得到的是

全部内容；

但是在python下，使用

虽然，也能通过/li/a/@href得到’http://a.com’的内容。

却只能得到hello world。xpath把所有的<>之内的东西给消灭掉了。很诡异。

遇到这种情况，如果我想得到整条的信息，就使用list.childNodes[index-1].firstChild.toxml()[22:-7]这种变通方式。不过，之前的doc = Parse(str(list.toxml()))我觉得用得挺好，是自己的一个”创举”，在程序中再度使用一下传统的xml解析方式，也无可厚非。当然，如果能够在xpath下把上述所有的事情都处理掉，是最好的。

经过了一点点的修补、改进，最终的饭否消息程序如下（核心代码部分）：

最关键的代码，只有几行而已。省掉了原来长篇累牍的coding。效率也错，我将自己近3000条饭否消息批量下载，共150余页，历时86秒。饭否服务器也很给面子，中途没有封锁我。

总结一下：Xpath很适合在xml中定位各部分内容，定位精准，描述性极佳，是xml中的搜索利器。经常做xml解析的，不妨尝试一把。

个人感言

从纯手工正则表达式解析，到使用minidom解析，再到使用xpath，看似弯路，其实蛮有收获。从自己事必躬亲精确控制每一个细节（用手工作），再到借助工具实现一部分功能（手脑并用），再到完全用合适的工具来处理全部事情（用脑工作），似乎正是良性的发展路径。自豪地说，由于我已经使用过纯手工正则表达式的解析，即使现有的工具不适合我，我进可攻，退可守；我知道解析的细节，现有的工具（好看的封装而已嘛）骗不了我，即使它包装得再好，还是正则表达式在作引擎（曾经读过python处理xml的相关库文件的python代码，感谢开源）；从追求实现(it works!)到追求卓越的实现(the excellent solution)，也是进步的必然。我不是说使用正则式就低级——我从来没有说过诸如此类的话，不论是对正则表达式，还是对正则表达式的使用者；事实上，正则表达式一直是我的箧中飞刃；我爱正则表达式！——只是说，不同的工具在合适的场合，有不同的效用。不单要知道某种工具的缺点以便能够避其短，更重要的是要知道它的优点以便扬其长。这样才能从容地调兵遣将，手下无不可用之工具。

相关链接：

• W3C关于XPath的介绍
• xpath教程，有中文版，图文并茂，清晰易懂。
• 4suite，python的xpath套件
• perl其实也有xpath的。未测试试。
• XPath Checker

• 能否只用官方的API来获取全部饭否消息？
• 饭否消息结构
• 使用regex解析饭否消息
• 使用xml解析饭否消息
• 两相比较
• 相关阅读

批量导出饭否程序的方法很多，但是基本思路都是先将该网页保存到本地，然后将有用的饭否消息析取出来。本文不讨论如何下载饭否网页了（使用迅雷、wget、curl等），重点讨论对于下载到本地的网页，如何将有用的饭否消息析取出来。

小插曲：能否只用官方的API来获取全部饭否消息？

您或许会提议为什么不使用饭否自身的API。是的，饭否的API更快捷方便，兼容性很强。只是，饭否官方只提供下载前20条饭否消息的API。如果纯粹使用饭否官方API来下载全部饭否消息的方法也不是没有，只是很邪恶：

1 2 3 4 5 6

while (true) {     download 20 messages via API;     store them;     delete this 20 messages via API; }

一边下载一边删除，确实总能得到全部消息。删除了前面的20条，能保证后面的20条以新消息的面目出现。这在理论上是行得通的。但是我们需要的是英雄Heroes里Peter那样无损的复制方式，而不是Sylar那样的残忍的剪切方式，呵呵。既然官方的API有限制，我们就自己动手了。请继续阅读本文。

饭否消息结构

打开一个饭否消息网页的源代码，例如本人的
http://fanfou.com/regex/p.1（其实http://fanfou.com/regex是http://fanfou.com/regex/p.1的快捷方式。这里使用完整的路径，以便体现其一般性。），观察可见，有用的饭否消息在这个框架里面：（代码较长，阅读请点击展开）

Tips：在分析饭否源代码时，饭否消息全在一行，不便于阅读。您可以拷贝所需要的代码（注意前后结构的匹配呼应）到vim中，执行:%s/>/>\r/g(将每个>后面加上一个换行符)，再按ggvG全选，按=格式代码，所有的代码就成了漂亮的缩进格式，便于阅读了。

使用regex解析饭否消息

下面是使用regex来解析饭否消息的代码（直接拷贝自本人原来的perl抓饭程序。）

可以看出，使用正则表达式，能够比较真实地再现原网页代码的风貌。有几处小地方需要说明一下：

• 在第一组小括号里，我使用了([^<]+?)来捕获消息正文（一条完整的消息可以分为：消息正文；发送时间；消息uuid例如QD6qHiqUbeE，发送方法，类型（彩信还是文本））。最初是使用.*?的。但是这样不精确，有时候两条消息竟然混合在一起。而([^<]+?)捕获的是从当前位置开始至下一个<之前的所有内容。或许您会问，这不怕受到消息正文中可能出现的<的影响吗？答案是：不会受到影响。因为饭否会把所有的<以及其实有可能影响解析的字符，都转换成<的形式了，因此它不影响解析。同时，使用精确的正则表达式有助于提高效率，让不匹配的正则式尽早失败。
• (?:statuses|share)。这条正则表达式是用来捕获饭否的uuid。它不但能捕获以普通方法发布的消息（网页、短信、手机、API、IM工具等），还能捕获由“饭否分享”工具发布的消息。我不是很喜欢饭否分享这个工具。（或许改天有时间写篇文章，揭露它的缺点？）之所以把“饭否分享”消息和普通消息分开来说，是因为两者的结构是不一样的。
• 通过(网页|(?:\s*<[^>]+>)[^<]+(?:))这条正则式，既用了捕获型括号，又用了非捕获型括号。使用后者，能有效地避免程序太复杂，便于按序号引用（$1,$2等，如果越多则越混乱，修改正则式后，更是乱成一团遭），还能节省内存（如果程序中捕获了太多的内容，而不及时释放，或许会占尽资源。毕竟不是只捕获几十字节。要考虑到饭否用户或许有近十万条的饭否消息。指的是苹果流冰这样的“万玻南痨话”）
• xi选项：x是为了使用忽略空白字符和允许注释；i选项是忽略大小写。

使用正则表达式来析取饭否消息文本，需要考虑的细节很多。一处不细致，程序运行起来就会给你难看。饭否彩信的格式就略过不分析了。道理相同，点到为止。

使用xml解析饭否消息

再来看一下在python下，使用xml来解析饭否消息。注：该程序参考了ppip的pyfan程序。