在解决问题之前,我们需要了解一些关于‘零宽断言’特性
⑴ 断言(锚点也一样)和一般的正则表达式符号不同,它不匹配实际的任何字符,而是寻找文本的中的位置,是0长度。
他们匹配的是字符之前或之后的位置。如$并不是匹配换行符,而是匹配目标字符串的末尾或整个字符串末尾的换行符之前的位置
(?=pattern), (?<=pattern), (?!Pattern), (?<!pattern) ^, $, \b, \A, \Z 都是这样的只找‘位置’的元字符
⑵ 对于断言来说,明白两个重要概念:‘当前位置’和‘不消耗字符’,非常重要两条,如(?<=Auto)(?=It)和(?=It)(?<=Auto)是等价的,你能解释吗?
$sResA = StringRegExpReplace("AutoIt", "(?<=Auto)(?=It)", "'")
$sResB = StringRegExpReplace("AutoIt", "(?=It)(?<=Auto)", "'")
你打印下会发现,$sResA和$sResB的结果是一样。若你能解释为什么一样的,说明你理解所谓的‘断言’已经有一定深度了。
(?<=Auto)表示当前位置的左边是‘Auto’,而(?=It)表示当前位置右边是‘It',也就是只要是断言,匹配了断言的子表达式之后的‘当前位置’
跟匹配之前的‘当前位置’是同一个位置,这也就是当引擎匹配完断言的子表达式之后,不会消耗掉如上面‘It’两个字符的,
下一次匹配还是这Auto的o后面开始。
这也是为什么象表达式:foo(?=bar)bee 无论匹配什么字串,它的结果永远为空的原因,因为无论在断言子表达式匹配前还是匹配后,
引擎的当前查找位置都在foo后面,这时已经匹配了bar了,而该表达式又想在foo后面匹配bee,那就不可能了。此时到可以这样匹配
foo(?=bar)bar,虽然可以匹配,但不过是画蛇添足而已
好了,理解了上面基础的两点,我们就可以来做这道题了
① 第一步,我们先来个稍简单的,让:
$sStr = "1234567890" 也就是字符串只有一个纯多位数字
这个问题核心就是从数字的最后开始三位三位地数,然后添加逗号,也就是逆序(从右到左),最容易想到的当然是逆序断言了(方向一至嘛)
于是就有两个思路,一则就是纯只找符合要求的位置,二则就是找符合要求的数字后面,先看第一个思路:
那么从末尾向右数3位3位地数,用正则很容易想到: ((\d{3})+$), 用$来定位串末尾的位置;再考虑不能在第一位数字前给加上逗号了,于是我们用
逆序肯定断言 (?<=\d) 来保证(这个表达式的意思就是要找的‘位置’前面不能是数字),这个也容易。因为这里是用的纯找位置的方法,而表达式
((\d{3})+$) 在匹配时是要消耗字符的,跟思路不合,于是限定一下,马上想到用顺序肯定断言来限制,((\d{3})+$)于是就变成了 (?=((\d{3})+$))
现在把二者联系起来,不就可以了
上面代码已经达成简化过的目标了,我们再深入一下,去掉那个$,表达式成为 (?<=\d)(?=(\d{3})+),结果却成为了 $sStr = "1,2,3,4,5,6,7,890"
试想一下为什么?这就想从你上面帖子所说的正则引擎如何工作的入手了,不然很难想象为什么会如此结果。我们来解析一下引擎的工作原理:
第一次匹配:当前搜索位置在1的前面,也就是元字符'^'代表的位置,引擎解析(?<=\d)后发现1前面没有数字,于是这次匹配失败。于是引擎把‘当前位置’移一个字符到达1和2之间
第二次匹配:引擎从‘当前位置’解析 (?<=\d),发现前面是1,符合“这个位置前面必须是数字”的要求,于是再解析 (?=(\d{3})+)
三位三位往后搜有 234 567 890,符合此表达式,于是在1和2之间加上‘,’,匹配完这次后,当前搜索位置再向右移动一个字符,也就是到了2和3之间
第三次匹配:引擎从‘当前位置’解析 (?<=\d),发现前面是2,符合“这个位置前面必须是数字”的要求,于是再解析 (?=(\d{3})+)
三位三位往后搜有 345 678,也符合此表达式(这里虽然90不合要求,但前面已经搜出两组,满足'+'元字符要求的),所以在2和3之间加上逗号
第四次匹配:以及后的匹配,就跟第三次一样类推了。
所以表达式里的$保证了字符串以3的倍数位数数字结尾,这很重要!
再来考虑下别的,若把里面的'+'换成 '*'会怎么样,结果是:$sRes = "1,234,567,890,",也就是0后面多了个逗号,怎么来的呢?
我们自然想到'+'跟'*'的区别,因为后者也可以是零次重复,当引擎的当前位置是0之后时,还会匹配最后一次,此时当然这个‘当前位置’前面是数字0,满足
(?<=\d),而后面是空位,当'*'取零次时也满足 (?<=\d)(?=(\d{3})*$),于是0后面逗号也就加上了。
② 第二步,来看看复杂点情况,也就是你给的:$sStr = "first1234567890back987654321end"
这时,我们不能再用'$'来确定最后数字的边界了,仔细想想跟上面的有什么不同呢?不同就在于最后数字0后面不再是串结尾位置,而是任意字符了。
当然这个‘任意’不能是数字,也就是如何找到:后面字符不是数字的位置,这不简单嘛,用顺序否定断言嘛,于是用(?!\d)替换'$',就可以得到答案了:
(考虑下,我们这里为什么不用'\D'来替换'$',它也表示非数字呀)
看上面的代码,已经基本满足要求了,但仔细一看,居然在k和9之间也插入了一个逗号。若你把这多余的逗号倒底是怎么来的考虑明白了,
基本上你对什么是零宽断言和引擎工作原理已经登堂入室了。留给你自己考虑,希望能发帖回复这个是啥原因?对比下面更精确的表达式
⑴ 断言(锚点也一样)和一般的正则表达式符号不同,它不匹配实际的任何字符,而是寻找文本的中的位置,是0长度。
他们匹配的是字符之前或之后的位置。如$并不是匹配换行符,而是匹配目标字符串的末尾或整个字符串末尾的换行符之前的位置
(?=pattern), (?<=pattern), (?!Pattern), (?<!pattern) ^, $, \b, \A, \Z 都是这样的只找‘位置’的元字符
⑵ 对于断言来说,明白两个重要概念:‘当前位置’和‘不消耗字符’,非常重要两条,如(?<=Auto)(?=It)和(?=It)(?<=Auto)是等价的,你能解释吗?
$sResA = StringRegExpReplace("AutoIt", "(?<=Auto)(?=It)", "'")
$sResB = StringRegExpReplace("AutoIt", "(?=It)(?<=Auto)", "'")
你打印下会发现,$sResA和$sResB的结果是一样。若你能解释为什么一样的,说明你理解所谓的‘断言’已经有一定深度了。
(?<=Auto)表示当前位置的左边是‘Auto’,而(?=It)表示当前位置右边是‘It',也就是只要是断言,匹配了断言的子表达式之后的‘当前位置’
跟匹配之前的‘当前位置’是同一个位置,这也就是当引擎匹配完断言的子表达式之后,不会消耗掉如上面‘It’两个字符的,
下一次匹配还是这Auto的o后面开始。
这也是为什么象表达式:foo(?=bar)bee 无论匹配什么字串,它的结果永远为空的原因,因为无论在断言子表达式匹配前还是匹配后,
引擎的当前查找位置都在foo后面,这时已经匹配了bar了,而该表达式又想在foo后面匹配bee,那就不可能了。此时到可以这样匹配
foo(?=bar)bar,虽然可以匹配,但不过是画蛇添足而已
好了,理解了上面基础的两点,我们就可以来做这道题了
① 第一步,我们先来个稍简单的,让:
$sStr = "1234567890" 也就是字符串只有一个纯多位数字
这个问题核心就是从数字的最后开始三位三位地数,然后添加逗号,也就是逆序(从右到左),最容易想到的当然是逆序断言了(方向一至嘛)
于是就有两个思路,一则就是纯只找符合要求的位置,二则就是找符合要求的数字后面,先看第一个思路:
那么从末尾向右数3位3位地数,用正则很容易想到: ((\d{3})+$), 用$来定位串末尾的位置;再考虑不能在第一位数字前给加上逗号了,于是我们用
逆序肯定断言 (?<=\d) 来保证(这个表达式的意思就是要找的‘位置’前面不能是数字),这个也容易。因为这里是用的纯找位置的方法,而表达式
((\d{3})+$) 在匹配时是要消耗字符的,跟思路不合,于是限定一下,马上想到用顺序肯定断言来限制,((\d{3})+$)于是就变成了 (?=((\d{3})+$))
现在把二者联系起来,不就可以了
上面代码已经达成简化过的目标了,我们再深入一下,去掉那个$,表达式成为 (?<=\d)(?=(\d{3})+),结果却成为了 $sStr = "1,2,3,4,5,6,7,890"
试想一下为什么?这就想从你上面帖子所说的正则引擎如何工作的入手了,不然很难想象为什么会如此结果。我们来解析一下引擎的工作原理:
第一次匹配:当前搜索位置在1的前面,也就是元字符'^'代表的位置,引擎解析(?<=\d)后发现1前面没有数字,于是这次匹配失败。于是引擎把‘当前位置’移一个字符到达1和2之间
第二次匹配:引擎从‘当前位置’解析 (?<=\d),发现前面是1,符合“这个位置前面必须是数字”的要求,于是再解析 (?=(\d{3})+)
三位三位往后搜有 234 567 890,符合此表达式,于是在1和2之间加上‘,’,匹配完这次后,当前搜索位置再向右移动一个字符,也就是到了2和3之间
第三次匹配:引擎从‘当前位置’解析 (?<=\d),发现前面是2,符合“这个位置前面必须是数字”的要求,于是再解析 (?=(\d{3})+)
三位三位往后搜有 345 678,也符合此表达式(这里虽然90不合要求,但前面已经搜出两组,满足'+'元字符要求的),所以在2和3之间加上逗号
第四次匹配:以及后的匹配,就跟第三次一样类推了。
所以表达式里的$保证了字符串以3的倍数位数数字结尾,这很重要!
再来考虑下别的,若把里面的'+'换成 '*'会怎么样,结果是:$sRes = "1,234,567,890,",也就是0后面多了个逗号,怎么来的呢?
我们自然想到'+'跟'*'的区别,因为后者也可以是零次重复,当引擎的当前位置是0之后时,还会匹配最后一次,此时当然这个‘当前位置’前面是数字0,满足
(?<=\d),而后面是空位,当'*'取零次时也满足 (?<=\d)(?=(\d{3})*$),于是0后面逗号也就加上了。
② 第二步,来看看复杂点情况,也就是你给的:$sStr = "first1234567890back987654321end"
这时,我们不能再用'$'来确定最后数字的边界了,仔细想想跟上面的有什么不同呢?不同就在于最后数字0后面不再是串结尾位置,而是任意字符了。
当然这个‘任意’不能是数字,也就是如何找到:后面字符不是数字的位置,这不简单嘛,用顺序否定断言嘛,于是用(?!\d)替换'$',就可以得到答案了:
(考虑下,我们这里为什么不用'\D'来替换'$',它也表示非数字呀)
看上面的代码,已经基本满足要求了,但仔细一看,居然在k和9之间也插入了一个逗号。若你把这多余的逗号倒底是怎么来的考虑明白了,
基本上你对什么是零宽断言和引擎工作原理已经登堂入室了。留给你自己考虑,希望能发帖回复这个是啥原因?对比下面更精确的表达式