学无止尽: 精通正则表达式

 

你觉得自己的正则表达式足够精通了么，当遇上实际问题的时候，能很熟练的解决问题么，即使解决问题了，解决问题的方法足够漂亮么，效率够高么。 我这段时间正在学习和内容抽取方面的东东，当然少不了大量和正则表达式打交道了，刚开始的时候还以为自己以前用过不少正则表达式，用起来应该能得心应手，可是面对一些奇怪而特殊的要求时，写起来就特别的别扭，才发现自己那三脚猫功夫根本不够用了。正好在公司的书架上翻到了 这本 《精通正则表达式 第三版》，由Friedl,J.E.F. 著作，余晟译著。信手翻阅之后，立即深深的被它吸引了。这本书绝对不是那种只能让你入门，让你只懂得怎么用却不懂得原理的书。这本书详细的讲解了正则表达式实现的原理，NFA引擎和DFA引擎的区别，更难能可贵的是，书中全面而详细的讲解了正则表达式的各种知识点，读过之余，绝对让你重新认识正则表达式！ 嘿嘿，现在这书被我“据为己有”啦，每天课余有时间都要好好翻阅... 嗯啊，要是觉得自己的正则表达式很牛了，麻烦再看看一下的这堆代码，对你肯定会有帮助的，这些代码可是出自余晟老师之手的哦， IMG_LINK_RE = re.compile('(?is)(?:<img[^>]*?//ssrc//s*=//s*['/"]?)([^'/"//s>]+)(?:[^>]*>)') RELATIVE_LINK_RE = re.compile('(?i)(?:href|src)/s*=/s*[/'"]?(?!http:)(?!mailto:)(?!javascript)(?:/[^/'"/s]+|[^/'"/s./]+/[^/'"/s]*|[^/'"/s./]+?.[^/'"/s./]+)(?=[/'"/s])') RELATIVE_SUB_RE = re.compile('(?i)(?<=[/'"=/s])(?=[0-9a-z.])') TITLE_RE = re.compile('(?i)(?<=<title>)[^<]+') EMAIL_RE = re.compile('(?i)[a-z0-9][-a-z0-9._]*@(?:/w[-/w]+/.)+[a-z]{2,4}') HTML_ENTITY_RE = re.compile('(&#(//d{5});)') LINE_RE = re.compile('(?is)<tr.*?</tr>') SPACE_RE = re.compile(r'(?is)(<br/s*/?>|</?p>|(?<=/n)/s*)') CONTENT_SUB_RE = re.compile(r"(?i)(<[^>]+>|&[0-9a-z]{3,5};|<(?:no)?script.*?</(?:no)?script>)") HYPERLINK_RE = re.compile('(?i)(?<=href)(/s*=/s*[/'"]?)(?!mailto:)([^/'"/s]+)') EMPTY_ELEMENT_RE = re.compile('(?is)<([^/s>]+)[^/>]*>[/s/r/n]*(</?/s*br>)*<///1/s*>') LINEFEED_RE = re.compile(r'(?is)(?<=/n)/s*') RELATIVE_RE = re.compile('(?<=[/'"/s])(?=/)') ENCODE_RE = re.compile('(?i)(?<=content=["/']text/html; charset=)[^/'"]+') SCRIPT_RE = re.compile('(?is)<(?:no)?script.*?</(?:no)?script>') 嘿嘿，还是上点读书笔记吧.. 简单的正则入门就不写啦，需要的话看我以前的笔记吧，正则表达式基础 http://hi.baidu.com/ismayday/blog/item/7f5b86942741d11dd21b708f.html ， 环视（look-around） 环视是很有意思的功能，它用来检查两端的字符，但不会把检查时匹配的字符加入匹配的最终结果。 例如，表达式『/bJeff/b』只能匹配“Jeff”这个单词，如果我们需要精确匹配“Jeffrey”这个单词中的“Jeff”，就可以使用环视『Jeff(?=rey)』，后面的『(?=rey)』表示，如果匹配成功，“Jeff”之后必须出现“rey”。有的读者可能会说，那我直接使用『(Jeff)rey』，先找出来，再提取分组，不是一样吗？请注意，环视的对象又可以是正则表达式，『Jeff(?=(rey|erson))』就可以找到“Jeffrey”或“Jefferson”中的“Jeff”，这种灵活性是前一种做法无法提供的，而且，『(Jeff)rey』使用括号来捕获文本，效率有所降低。 按照环视的方向不同，可以分为顺序环视（lookahead，表示从左向右检查）和逆序环视（lookbehind，从右向左检查）；按照环视成立的条件不同，又可分为肯定环视（positive lookaround，只有在环视对象能匹配时才成功）和否定环视（negative lookaround，只有在环视对象无法匹配时才成功）。两者组合起来，就得到四种环视： * 肯定顺序环视 * 肯定逆序环视 * 否定顺序环视 * 否定逆序环视 所使用的标记也很好识别，『(?=Regex)』表示肯定顺序环视，『(?!Regex)』表示否定顺序环视，『(?<=Regex)』表示肯定逆序环视，『(?<!Regex)』表示否定逆序环视。 在日常的HTML解析中，如果我们需要精确获得“src=...”中的资源地址（这里假定“src=...”的格式统一规范，等号两端没有空格，也没有引号），可以在表达式之前添加『(?<=).*?(?=< /B>)』来精确匹配“...”之中的内容。在这两个例子中，当然也可以使用匹配-括号提取的办法，但使用环视的效率更高，也更切合程序的本意。 环视还可以多个连用，我曾遇到过这样的情形：有站点siteA.com，需要在Apache的配置文件中设定重定向规则，以一个正则表达式匹配除sub1, sub23之外的所有子域名（注意，是匹配所有子域名），首先我想到的是 『^[^.]*(?<!--b(1|23)).siteA.com$』 但这行不通，因为多数系统都不容许在逆序环视中使用变长表达式（只有.NET容许），所以必须连用多个逆序环视 『^[^.]*(?<!--ub1)(?<!^sub23).siteA.com$』 固化分组（Atomic-grouping） 回溯（back-tracking）是匹配过程中常见的现象，如果用『.*ab』来匹配“123456ab”，『.*』首先会匹配整个字符串，之后轮到『ab』，『.*』需要“依次释放”之前匹配的两个字符，供『ab』匹配，整个表达式才能匹配成功。这样“依次释放”的过程，就叫做回溯。但有时回溯完全是徒劳的，例如我们用『/w+:』来匹配“Subject”。因为字符串中不存在冒号，匹配肯定会失败，但引擎仍然必须依次回溯，最终得出失败的结果，而我们知道，『/w』“释放”的字符，:肯定无法匹配。此时可以使用固化分组，将『/w+』匹配的内容“固定”下来，禁止回溯： 『(?>/w+):』 这样报告匹配失败的速度就提高了许多倍，如果字符串很长，使用固化分组就能节省大量的时间。 固化分组的另一个用途是精确控制匹配，防止不期望的匹配。例如，表达式『<(/w+).*?』，本意是匹配对称的tag之间的文本，但它会错误地匹配“ …”。如果使用固化分组『<((?>/w+)).*?』，就能解决这个问题。 模式修饰符（mode-modifier） 模式（mode)表示正则表达式在匹配时所采取的规则，模式修饰符用来设定模式。 最常见的模式是Case-Insensitive Mode（简写为i），它表示“不区分大小写”。在默认情况下，CAT只能匹配单词CAT，如果采用不区分大小写的匹配模式，则『CAT』可以匹配“Cat”， “CAT”，“cat”等任意形式的“cat”。 另一个常用的模式是Dot-match-all Mode（简写为s），它表示“点号通配”。在默认情况下，点号是不能匹配换行符的，此时，如果用『.*?』匹配一个 IMG tag，而这个tag的内容又跨越了两行，那么匹配是不会成功的。但如果使用“点号通配”模式，则点号可以匹配换行符，整个tag得以匹配。 还有个常见的模式是Free-spacing and Comment Mode（简写为x），它表示忽略正则表达式中的空白字符（必须使用『/s』来表示空白字符，同时容许在正则表达式中加入注释）。 最后介绍的模式是Multi-line Mode（多行模式，简写为m），又叫Enhanced Line-anchor Mode（增强的行锚点模式），在默认情况下，『^』和『$』只能匹配字符串的开头和结尾，但在此模式下，『^』和『$』可以匹配字符串当中的行开头/行结束，如果我们需要在包括多行文本的字符串中精确查找满足某条件的一行文本，就可以启用此模式，并使用『^』和『$』精确定位文本的两端。 模式修饰符通常以flag（标志位）的形式指定， 例如在Java中使用 Pattern.compile("CAT", PATTERN.CASE_INSENSITIVE) 在Python中使用 re.compile("CAT", re.IGNORECASE) 如果需要同时使用多个模式修饰符，可以以逻辑运算符“AND”来连接 Pattern.compile("C(?#comment1)A(?#comment2)T", PATTERN.CASE_INSENSITIVE|PATTERN.COMMENTS)。 模式作用范围（mode-modified-span) 这是与模式修饰符对应的概念。通常，我们需要显式地设定标志位，指定匹配模式，但此时模式是对整个表达式起作用的，无法进行更细的限制。而模式修饰范围则可以精确限定各元素的匹配模式，解决此类问题。 不妨考虑这样的情况，一个正则匹配函数，接收两个参数，第一个参数为Tag的名字，第二个参数为匹配Tag内容中内容的表达式，而且，Tag名可以不分大小写，但内容匹配必须区分大小写。如果我们用一个匹配模式统摄整个表达式，必然无法完成要求，此时必须使用模式修饰范围，限定各个元素所使用的匹配模式。以Java为例，如果第一个参数为tagNameRegex，第二个参数为tagContentRegex，那么我们可以这样： Pattern.compile("(?i)<" + tagNameRegex + ">" + ">(?-i)" + tagContentRegex + "(?i)</"＋tagNameRegex + ">" + ">(?-i)") 如果传入的tagNameRegex是“td”，tagContentRegex是“/d{4}[a-z]3/d{3}”，则编译所用的表达式就是 『(?i)<td>(?-i)/d{4}[a-z]3/d{3}(?i)</td>(?-i)』 其中，我们在“<td>”和“</td>”两端分别以『(?i)』和『(?-i)』来开启/关闭不区分大小写的匹配模式，精确限定了此匹配模式的作用范围，而内部的tagContentRegex则不受影响，仍采用默认的匹配模式，如此，这个表达式能匹配<Td>4444azz333<tD>，但不能匹配<td>4444AZZ333</td>，这正是我们需要的。 即使整个表达式采用同一种匹配模式，我们也可以使用模式修饰范围，例如『(?i)CAT』就表示，对整个表达式『CAT』进行不区分大小写的匹配。