9.7. 模式匹配

9.7.3.1. 正则表达式细节

PostgreSQL的正则表达式使用 Henry Spencer 写的一个包来实现。 下面的大部分描述都是从他的手册页里逐字拷贝过来的。

正则表达式(REs)，在POSIX 1003.2中定义， 它有两种形式：扩展 RE或ERE (基本上就是在egrep里的那些)，基本RE 或BRE(基本上就是在ed里的那些)。PostgreSQL 两种形式都实现了，并且还做了一些 POSIX 里面没有的， 但是因为在类似 Perl 或者 Tcl 这样的语言中得到广泛应用的一些扩展。 使用了那些非 POSIX 扩展的正则表达式叫高级RE 或ARE。ARE 几乎完全是 ERE 的超集，但是 BRE 有几个符号上的不兼容(以及更多的限制)。 我们首先描述 ARE 和 ERE 形式，描述那些只适用于 ARE 的特性，然后描述与 BRE 的区别是什么。

一个正则表达式定义为一个或多个分支， 由|分隔。它匹配其中任何一个分支的东西。

一个分支是零个或多个有修饰的原子或约束连接而成。 一个原子匹配第一个，后面的原子匹配第二个，以此类推；一个空分支匹配空字符串。

一个有修饰的原子是一个原子，后面可能跟着一个量词。 没有量词的时候，它匹配一个原子，有量词的时候，它可以匹配若干个原子。 原子可以是在Table 9-12里面显示的任何可能。 可能的量词和他们的含义在Table 9-13里显示。

一个约束匹配一个空字符串，但只是在满足特定条件下才匹配。 约束可以在能够使用原子的地方使用，只是它不能跟着量词。 最简单的原子在Table 9-14里显示；更多的约束稍后描述。

RE不能以(\)结尾。

{...}的形式被称作范围。 一个范围内的数字m和n都是无符号十进制整数， 允许的数值从 0 到 255 (闭区间)。

非贪婪的量词(只在 ARE 中可用)匹配对应的正常(贪婪)模式， 区别是它寻找最少的匹配，而不是最多的匹配。参阅Section 9.7.3.5 获取细节。

前瞻约束不能包含后引用(参阅Section 9.7.3.3)， 并且在其中的所有圆括弧都被认为是不捕获的。

9.7.3.2. 方括弧表达式

方括弧表达式是一个包围在[]里的字符列表。 它通常匹配任意单个列表中的字符(又见下文)。如果列表以^开头， 它匹配任意单个(又见下文)不在该列表中的字符。如果该列表中两个字符用 -隔开，那它就是那两个字符(包括在内)之间的所有字符范围的缩写， 比如，在ASCII里[0-9]包含任何十进制数字。 两个范围共享一个终点是非法的，比如a-c-e。这个范围与字符集关系密切， 可移植的程序不应该依靠它们。

想在列表中包含文本]，可以让它做列表的首字符(如果用到了， 跟在^ 后面)。想在列表中包含文本-， 可以让它做列表的首字符或者末字符，或者一个范围的第二个终点。 想在列表中把文本-当做范围的起点，把它用[. 和.]包围起来，这样它就成为一个集合元素(见下文)。 除了这些字符本身，和一些用[的组合(见下段)， 以及转义(只在 ARE 中有效)以外，所有其它特殊字符在方括弧表达式里都失去它们的特殊含义。 特别是，在 ERE 和 BRE 规则下\不是特殊的，但在 ARE 里， 它是特殊的(还是引入一个转义)。

在一个方括弧表达式里，一个集合元素(一个字符、一个当做一个字符的多字符序列、 或者一个表示上面两种情况的集合序列)包含在[.和.] 里面的时候表示该集合元素的字符序列。该序列是该方括弧列表的一个元素。 这允许一个包含多字符集合元素的方括弧表达式就可以匹配多于一个字符，比如， 如果集合序列包含一个ch集合元素，那么[[.ch.]]*c 匹配chchcc的头五个字符。译注：其实把 [. 和 .] 括起来的整体当一个字符看就行了。

在方括弧表达式里，在[=和=] 里包围的集合元素是一个等效表，代表等于这里所有集合元素的字符序列， 包括它本身(如果没有其它等效集合元素，那么就好像封装元素是[. 和.])。比如，如果o和^ 是一个等效表的成员，那么[[=o=]],[[=^=]], [o^]都是同义的。一个等效表不能是一个范围的端点。

在方括弧表达式里，在[:和:] 里面封装的字符表名字代表属于该表的所有字符的列表。标准的字符表名字是： alnum, alpha, blank, cntrl, digit, graph, lower, print, punct, space, upper, xdigit。 它们代表在ctype 里定义的字符表。本地化设置可能会提供其它的表。字符表不能用做一个范围的端点。

在方括弧表达式里有两个特例：方括弧表达式[[:<:]]和 [[:>:]]是约束，分别匹配一个单词开头和结束的空串。 单词定义为一个单词字符序列，前面和后面都没有其它单词字符。 单词字符是一个alnum字符(和ctype 里定义的一样)或者一个下划线。这是一个扩展，兼容POSIX 1003.2 ， 但那里面并没有说明，而且在准备移植到其它系统里去的软件里一定要小心使用。 通常下面描述的约束转义更好些；他们并非更标准，但是更容易输入。

9.7.3.3. 正则表达式转义

转义是以\开头，后面跟着一个字母数字字符的特殊序列。 转义有好几种变体：字符项、表缩写、约束转义、后引用。在 ARE 里，如果一个\ 后面跟着一个字母数字，但是并未组成一个合法的转义，那么它是非法的。在 ERE 里则没有转义： 在方括弧表达式之外，一个跟着字母数字字符的\只是表示该字符是一个普通的字符， 而在一个方括弧表达式里，\是一个普通的字符(后者实际上是 ERE 和 ARE 之间的不兼容)。

字符项转义用于方便我们声明正则表达式里那些不可打印的字符。 它们在Table 9-15里列出。

类缩写转义用来提供一些常用的字符类缩写。 他们在Table 9-16里列出。

约束转义是一个约束，如果满足特定的条件，它匹配该空字符串，以转义形式写出。 它们在Table 9-17里列出。

后引用(\n)匹配数字n 指定的前面的圆括弧子表达式匹配的同一个字符串(参阅Table 9-18)。 比如，([bc])\1匹配bb或cc但是不匹配bc或cb。 正则表达式里的子表达式必须完全在后引用前面。子表达式以它的括号的顺序排序。 非捕获圆括弧并不定义子表达式。

十六进制位是0-9, a-f, A-F。八进制位是0-7。

字符项转义总是被当作普通字符。比如，\135是 ASCII 中的]， 但\135并不终止一个方括弧表达式。

在方括弧表达式里，\d, \s, \w 会失去他们的外层方括弧，而 \D, \S, \W 是非法的。比如[a-c\d]等效于[a-c[:digit:]]。 同样[a-c\D]原来等效于[a-c^[:digit:]]的，也是非法的。

一个词的定义是上面[[:<:]]和[[:>:]]的声明。 在方括弧表达式里，约束转义是非法的。

9.7.3.4. 正则表达式元语法

除了上面描述的主要语法之外，还有几种特殊形式和杂项语法。

正则表达式可以以两个特殊的指示器前缀之一开始： 如果一个正则表达式以***:开头，那么剩下的正则表达式都被当作 ARE 。 （这在PostgreSQL中通常没有影响，因为正则表达式被假设为ARE； 但是如果ERE或BRE模式被flags参数指定为正则表达式函数时是有影响的。） 如果一个的正则表达式以***=开头，那么剩下的正则表达式被当作一个文本串， 所有的字符都被认为是一个普通字符。

一个 ARE 可以以嵌入选项开头：一个(?xyz) 序列(这里的xyz是一个或多个字母字符)声明影响剩余正则表达式的选项。 这些选项覆盖任何前面判断的选项—它们可以重写正则表达式操作符隐含的大小写敏感性， 或者正则表达式函数的flags参数。可用的选项字母在 Table 9-19显示。请注意， 正则表达式函数的flags参数使用相同的选项字母。

嵌入的选项在终止其序列的)发生作用。他们只在 ARE 的开始处起作用(如果有， 则在任何***:指示器后面)。

除了通常的(紧)正则表达式语法(这种情况下所有字符都重要)， 还有一种扩展语法，可以通过声明嵌入的x选项获得。 在扩展语法里，正则表达式中的空白字符被忽略，就像那些在# 和新行之间的字符一样（或正则表达式的结尾）。 这样就允许我们给一个复杂的正则表达式分段和注释。不过这个基本规则上有三种例外：

• 前置了\的空白字符或者 #保留

• 方括弧里的空白或者#保留

• 在多字符符号里面不能出现空白和注释，比如(?:

在这里，空白是空格、水平制表符、新行、和任何属于space(空白)字符表的字符。

最后，在 ARE 里，方括弧表达式外面，序列(?#ttt) (这里的ttt是任意不包含)的文本)是一个注释，完全被忽略。 同样，这样的东西是不允许出现在多字符符号的字符中间的，比如(?:。 这样的注释是比有用的机制的更久远的历史造成的，他们的用法已经废弃了； 我们应该使用扩展语法代替他。

如果声明了一个初始化的***=指示器，那么所有这些元语法扩展都 不能使用，因为这样表示把用户输入当作一个文本字符串而不是正则表达式对待。

9.7.3.5. 正则表达式匹配规则

在正则表达式可以匹配给出的字符串中多于一个子字符串的情况下， 正则表达式匹配字符串中最靠前的那个子字符串。 如果正则表达式可以匹配在那个位置开始的多个子字符串，要么是取最长的子字符串， 要么是最短的，具体哪种，取决于正则表达式是贪婪的还是 非贪婪的。

一个正则表达式是否贪婪取决于下面规则：

• 大多数原子，以及所有约束，都没有贪婪属性(因为它们毕竟无法匹配个数变化的文本)。

• 在一个正则表达式周围加上圆括弧并不会改变其贪婪性。

• 一个带一个固定重复次数的量词({m} 或{m}?) 量化的原子和原子自身有着同样的贪婪性(可能是没有)。

• 一个带其它普通的量词(包括{m,n} 中m等于n的情况)量化的原子是贪婪的(首选最长匹配)。

• 一个带非贪婪量词(包括{m,n}? 中m等于n的情况)量化原子是非贪婪的(首选最短匹配)。

• 一个分支(也就是一个没有顶级|操作的正则表达式) 和它里面的第一个有贪婪属性的量化原子有着同样的贪婪性。

• 一个由|操作符连接起来的两个或者更多分支组成的正则表达式总是贪婪的。

上面的规则所描述的贪婪属性不仅仅适用于独立的量化原子， 而且也适用于包含量化原子的分支和整个正则表达式。这里的意思是， 匹配是按照分支或者整个正则表达式作为一个整体 匹配最长或者最短的子字符串的可能。一旦整个匹配的长度确定， 那么匹配任意子表达式的部分就基于该子表达式的贪婪属性进行判断， 在正则表达式里面靠前的子表达式的优先级高于靠后的子表达式。

一个表达这些的例子：

SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
Result: 123
SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
Result: 1

在第一个例子里，正则表达式作为整体是贪婪的，因为Y*是贪婪的。 它可以匹配从Y开始的东西，并且它匹配从这个位置开始的最长的字符串， 也就是Y123。输出是这里的圆括弧包围的部分，或者说是123。 在第二个例子里，正则表达式总体上是一个非贪婪的正则表达式 ，因为Y*? 是非贪婪的。它可以匹配从Y开始的最短的子字符串，也就是说Y1。 子表达式[0-9]{1,3}是贪婪的，但是它不能修改总体匹配长度的决定； 因此它被迫只匹配1。

简单说，如果一个正则表达式同时包含贪婪和非贪婪的子表达式， 那么总匹配长度要么是最长可能，要么是最短可能，取决于给整个正则表达式赋予的贪婪属性。 给子表达式赋予的贪婪属性只影响在这个匹配里，各个子表达式之间相互允许 "吃进"的多少。

量词{1,1}和{1,1}? 可以分别用于在一个子表达式或者整个正则表达式上强制贪婪或者非贪婪。

匹配长度是以字符衡量的，而不是集合的元素。一个空字符串会被认为比什么都不匹配长。 比如：bb*匹配abbbc的中间三个字符； (week|wee)(night|knights)匹配weeknights的所有十个字符； 而(.*).*匹配abc的时候，圆括弧包围的子表达式匹配所有三个字符； 而如果用(a*)*匹配bc，那么正则表达式和圆括弧子表达式都匹配空字符串。

如果声明了大小写无关的匹配，那么效果就好像把所有字母上的大小写区别取消了一样。 如果一个存在大小写差别的字母以一个普通字符的形式出现在方括弧表达式外面， 那么它实际上被转换成一个包含大小写的方括弧表达式，也就是说，x 变成[xX]。如果它出现在一个方括弧表达式里面， 那么它的所有大小写的同族都被加入方括弧表达式中，也就是说，[x] 变成[xX]而[^x]变成 [^xX]。

如果声明了新行敏感匹配，.和使用^ 的方括弧表达式将永远不会匹配新行字符(这样，匹配就绝对不会跨新行， 除非正则表达式明确地安排了这样的情况)并且^和$ 除了分别匹配字符串开头和结尾之外，还将分别匹配新行后面和前面的空字符串。 但是 ARE 转义\A和\Z 仍然只匹配字符串的开头和结尾。

如果声明了部分新行敏感匹配，那么它影响.和方括弧表达式， 这个时候和新行敏感匹配一样，但是不影响^和$。

如果声明了反转部分新行敏感匹配，那么它影响^和$， 作用和新行敏感匹配里一样，但是不影响.和方括弧表达式。 这个没什么太多用途，只是为了对称提供的。

9.7.3.6. 限制和兼容性

在这个实现里，对正则表达式的长度没有特别的限制，但是， 那些希望能够有很好移植行的程序应该避免写超过 256 字节的正则表达式 ， 因为 POSIX 兼容的实现可以拒绝接受这样的正则表达式。

ARE 实际上和 POSIX ERE 不兼容的唯一的特性是在方括弧表达式里\ 并不失去它特殊的含义。所有其它 ARE 特性都使用在 POSIX ERE 里面是非法或者是未定义、 未声明效果的语法；指示器的***就是在 POSIX 的 BRE 和 ERE 之外的语法。

许多 ARE 扩展都是从 Perl 那里借来的，但是有些我做了修改，清理了一下， 以及一些 Perl 里没有出现的扩展。要注意的不兼容包括\b, \B， 对结尾的新行缺乏特别的处理，对那些新行敏感匹配的附加的补齐方括弧表达式， 在前瞻约束里对圆括弧和方括弧引用的限制，以及最长/最短匹配(而不是第一匹配)语义。

PostgreSQL 7.4 之前的版本里的 ARE 和 ERE 存在两个非常显著的不兼容：

• 在 ARE 里，后面跟着一个字母数字的\要么是一个转义，要么是错误， 但是在以前的版本里，它只是写那个字母数字的另外一种方法。这个应该不是什么问题， 因为在以前的版本里没有什么原因让我们写这样的序列。

• 在 ARE 里，\在[]里还是一个特殊字符， 因此在方括弧表达式里的一个文本\必须写成\\。

9.7.3.7. 基本正则表达式

BRE 在几个方面和 ERE 不太一样。在BRE里，|, +,? 都是普通字符，它们没有等效的功能替换。范围的分隔符是\{和\}， 因为{和}本身是普通字符。嵌套的子表达式的圆括弧是\( 和\)，因为(和)自身是普通字符。 除非在正则表达式开头或者是圆括弧封装的子表达式开头，^都是普通字符， 除非在正则表达式结尾或者是圆括弧封装的子表达式的结尾，$是一个普通字符， 而如果*出现在正则表达式开头或者是圆括弧封装的子表达式开头 (前面可能有^)，那么它是个普通字符。最后，可以用单数字的后引用， 以及\<和\>分别是[[:<:]]和[[:>:]] 的同义词；在BRE里没有其它的转义。