翻译者：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这一点做得实在太滥。

最近拾起了以前的小项目，在完善上篇文章发布后，“那个谁”的回复让我很感兴趣。他问，“为什么不用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只能解析实体内容，不能”囫囵吞枣”地解析。例如：

<li>
	<a href='http://a.com'>hello world</a>
</li>

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

<a href='http://a.com'>hello world</a>

全部内容；

但是在python下，使用

method=doc.xpath(u'''string(/li/a)''')

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

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

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

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

    def __getMsgByPage__(self,page):        
 
        url="http://fanfou.com/"+self.user+"/p."+str(page)
        node = minidom.parse(urllib2.urlopen(url))
        list = node.getElementsByTagName("ol")[0]
        doc = Parse(str(list.toxml()))
        cu=self.sql.cursor()
        max=doc.xpath(u'''count(/ol/li)''')
        max=int(max)+1
        if max==1:
            return 0
        max=int(max)
        for index in range(1,max):
            method=doc.xpath(u'''string(/ol/li[%d]//span[@class='method'])''' % index)[2:]	
            method=method.replace(' ','')
            if method=="彩信":
                time=doc.xpath(u'''string(/ol/li[%d]//span[@class="time"]/@title)'''\
                        % index)
                uuid=doc.xpath(u'''string(/ol/li[%d]//a[@class='photo']/@href)'''\
                        % index) [-11:]
            else:
                time=doc.xpath(u'''string(/ol/li[%d]//a[@class='time']/@title)'''\
                        % index) 
                uuid=doc.xpath(u'''string(/ol/li[%d]//a[@class='time']/@href)''' % index)[-11:]
 
            content = list.childNodes[index-1].firstChild.toxml()[22:-7]
            # content, uuid, time, method are now available for further use.

最关键的代码，只有几行而已。省掉了原来长篇累牍的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

作者：

A.M. Kuchling(amk@amk.ca)。

简要介绍：
本书主要介绍如何在python下使用re模块的正则表达式来处理问题。
本电子书是英文的，没有中文版。不过，内容比较简单，正则式和python的初学者可以看看。

不足：
（只针对书本身，不针对内容）虽然是pdf，虽然有目录，但是点击目录不能跳转。由于本书只有短短25页，一会就能看完。所以，还是将就看吧。

文件：
21页，pdf尺寸130kb。MD5：0a223f1ad3f932c8a0a7494120c10b05。

下载地址（如果您是通过FEED读本文，请移步到原始地址下载）：
Note: There is a file embedded within this post, please visit this post to download the file.

另：关于python下使用正则式，还有两个链接可供参考，在这里：
python正则表达式链接

2. 正则表达式指南

作者：
张子阳，（博客http://jimmyzhang.cnblogs.com）。

简要介绍：
本电子书是中文版的，有概念有解释有例子，适合偏爱中文的初学者阅读。
本书提到了一款正则式测试工具，RegexTester，由于现在在ubuntu下，尚未安装wine，这款软件有时间再测试。先略过不谈。

不足之处：
对正则表达式的语言没有明确指出，或许作者的意图是写适合各种语言的正则表达式的教程吧。以笔者之见，初级程度的正则表达式区别不大，而深究起来，各种正则表达式的语言、工具各有其不同风格。本书忽略了这些特点，或许是为了不让初学者心存芥蒂，先了解正则表达式的概念。

文件：
45页，pdf，362kb。MD5：77e36c693bc2d3248fb0dcfd70250037。

下载地址（如果您是通过FEED读本文，请移步到原始地址下载）：
Note: There is a file embedded within this post, please visit this post to download the file.

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

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

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

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

^?View Code PERL

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的快捷方式。这里使用完整的路径，以便体现其一般性。），观察可见，有用的饭否消息在这个框架里面：（代码较长，阅读请点击展开）

 
<ol>
    <li>
        <span class="content">
            代码非抄不能懂也。</span>
        <span class="stamp">
            <a class="time" title="2008-10-03 12:07" href="/statuses/QD6qHiqUbeE">
                2008-10-03 12:07</a>
            <span class="method">
                通过 <a href="http://del.icio.us/fanfou/API%E5%BA%94%E7%94%A8" target="_blank">
                    API</a>
            </span>
        </span>
    </li>
 
    <li>
        <span class="content">
            向自由的身心致敬！ - 早嗷嗷也盼~晚安安也盼~望穿安安双眼~~怎知道今日里打土匪进深山自己的队伍来哎到嗷~面安前安呐啊啊啊啊啊~~~ <a href="http://fanfou.com/linkto/aHR0cDovL3d3dy5kb3ViYW4uY29tL2V2ZW50LzEwMjczNDg3Lw" target="_blank">
                http://www.douban.com/event/10273487/</a>
        </span>
        <span class="stamp">
            <a class="time" title="2008-10-06 14:07" href="/share/bd96z1U-gHw">
                2008-10-06 14:07</a>
            <span class="method">
                通过<a href="http://help.fanfou.com/share_button.html" target="_blank">
                    饭否分享</a>
            </span>
        </span>
    </li>
 
    <li>
        <span class="content">
            <a class="photo" href="http://fanfou.com/photo/8JsezhHM_VU">
                <img src="http://photo.fanfou.com/m0/00/19/e2_36807.jpg" alt="caixinceshi - no description" />
            </a>
            上传了新照片：caixinceshi - no description</span>
        <span class="stamp">
            <span class="time" title="2008-10-03 11:33">
                2008-10-03 11:33</span>
            <span class="method">
                通过<a href="http://help.fanfou.com/mobile_mms.html" target="_blank">
                    彩信</a>
            </span>
        </span>
    </li>
    #更多的<li>...</li>条目，每页最多20条。
</ol>

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

使用regex解析饭否消息

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

my $ffmsg=qr{
    <li>
        <span class="content">
            (.*?)
        </span>
        <span class="stamp">
            <a href="/(?:statuses|share)/([-_a-zA-Z0-9]{11})" class="time" title="([-: 0-9]{16})">
                [^<]+
            </a> 
            <span class="method">
                通过(网页|(?:\s*<[^>]+>)[^<]+(?:</a>))
            </span>
        </span>
    </li>
' }xi;

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

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

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

使用xml解析饭否消息

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

from xml.dom import minidom, Node #引人解析工具：xml小马驹！ 
node = minidom.parse(urllib2.urlopen("http://fanfou.com/zhasm/p.1")) 
#抓取页面http://fanfou.com/zhasm/p.1 的全部内容到变量node中 
l = node.getElementsByTagName("ol")[0] 
#将饭否消息部分内容保存到变量l中 
for c in range(0, number): 
    # 时间 
    if l.childNodes[c].hasAttribute("class"): 
        continue 
    content = ( 
            #时间: 
            l.childNodes[c].childNodes[5].\ 
            firstChild.getAttribute("title"), 
            #消息正文 :
            childNodes[c].childNodes[0].toxml()[22:-7], 
            #uuid 
            l.childNodes[c].childNodes[5].firstChild.\ 
            getAttribute("href")[10:]
            )