正则表达式绕过案例

一，正则表达式

(1) 需要转义的特殊字符

$ ( ) * + . ? [ \ ^ {

在文本中遇到 这几种特殊字符想转为文本，需要通过反斜杠\转义：  

/\$ \( \) \* \+ \. \? \[ \\ \^ \{/g

也许你会问到 -减号符，}右花括号，]右中括号为何不在内？首先减号符是在[]中的，在前面没遇到转义的[左方括号时，减号符及右方括号-]是当普通文本处理，无需转义，而花括号也如此

• Regexp : /\{\w+}\[hello-world]/

• Text : {abc}[hello-world] hey! hey! hey!

(2) 再次匹配先前匹配的文本

如果需要匹配一个 yyyy-mm-dd 格式的日期，其中月份和日期都是年份的个十位

/\b\d\d(\d\d)-\1-\1\b/

反斜杠\1-9可以得到前面分组(\d\d)捕获到的结果，如果是10-99呢？那就\10至\99

• Regexp : /\b\d\d(\d\d)-\1-\1\b/

• Text : 2008-08-08

  (3) 单词边界

单词边界这个概念我开始比较抽象，也花了点时间去实践到底是啥，所以在这里作为一个案例来说说。

在单词边界匹配的位置，单词字符后面或前面不与另一个单词字符直接相邻。 不太明白，还是看实例吧！

"That dang-tootin' #!@#$ varmint's cost me $199.95!".replace(/\b/g,function(){
 console.log(arguments)
});

//output
["", 0, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 4, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 5, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 9, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 10, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 16, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 24, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 31, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 32, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 33, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 34, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 38, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 39, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 41, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 43, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 46, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 47, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]
["", 49, "That dang-tootin' #!@#$ varmint's cost me $199.95!"]

 通过控制台输出，我们可以发现\b匹配的位置如下：

 细心的你一定会发现数字的开始，小数点的左右都会有单词边界，这意味着单词边界不仅仅是英文字母，还包括数字。

\b`属于匹配位置的元字符，一般作占位作用，而不被捕获，同属于匹配位置的还有匹配行起始位`^`和行结束位`$

 

(4) 处理24小时制时间

24小时制可以分为三段：

1. 00 - 09

2. 10 - 19

3. 20 - 23

先匹配第一阶段： /[0][0-9]/

再接着匹配第二阶段：/[01][0-9]/

第三阶段以此类推？/[012][0-9]/

明显不合适，因为不可能出现大于23以上的数字，那么只能开分支了 /[01][0-9]|2[0-3]/

也许你会说，00-09如果要匹配“没有补零”的情况呢？（即：0,1,2,3,4,5...）

我们可以借助一下量词?匹配 /[01]?[0-9]|2[0-3]/

• Regexp : /([01]?[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]/

(5) 千分位

我们在一些场景里需要将7654321输出成7,654,321这样的格式，这就是千分位，用正则表达式去处理的话，关键是获取位置，那么首先想到的就是要利用非单词边界\B，下面这条正则是能成功取得千分位的位置的：

/\B(?=(\d{3})+(?!\d))/g

先将这个正则分解成三部分：

1 )、 /\B(?=\d)/ 这是\B是为了防止出现,123起始位置被匹配的问题，(?=\d)是非单词边界后紧跟数字

2 )、 尝试一下8位数的数字： '12345678' 在 /\B(?=(\d{3})+)/匹配得到什么结果呢？

'12345678'.replace(/\B(?=(\d{3})+)/g,function(){console.log(arguments);return '|'}) 
​

["", "567", 1, "12345678"]
["", "678", 2, "12345678"]
["", "456", 3, "12345678"]
["", "567", 4, "12345678"]
["", "678", 5, "12345678"]
​
"1|2|3|4|5|678"

首先符合非单词边界\B的有1，2，3，4，5，6，7的右边位置，而后面也同样紧跟数字2，3，4，5，6，7

其次符合\d{3}的有234，345，456，567，678，但后面跟个加号+结果就不一样了

那为什么会得到567，678，456，567，678，这样奇怪的匹配？原理如下：

1. 匹配`\B`第1个非单词边界 `1`的右边位置，则后面(\d{3})+的结果为：234、567，8后面无法补齐3位，匹配得到567
2. 匹配`\B`第2个非单词边界 `2`的右边位置，则后面(\d{3})+的结果为：345、678，匹配得到678
3. 匹配`\B`第3个非单词边界 `3`的右边位置，则后面(\d{3})+的结果为：456、78后面无法补齐3位，匹配得到456
4. 匹配`\B`第4个非单词边界 `4`的右边位置，则后面(\d{3})+的结果为：567、8后面无法补齐3位，匹配得到567
5. 匹配`\B`第5个非单词边界 `5`的右边位置，则后面(\d{3})+的结果为：678
6. 匹配`\B`第6个非单词边界 `6`的右边位置，但78无法补齐3位，
7. 同6
8. 最终小括号分组匹配得到的分别是：567,678,456,567,678

3)、最后 (?!\d) 是前面匹配成功后跟的非数字，那连起来就是：

12,345,678
1. 匹配`\B`第1个非单词边界 `1`的右边位置，则后面(\d{3})+的结果为：234、567，后面跟着8，不匹配
2. 匹配`\B`第2个非单词边界 `2`的右边位置，则后面(\d{3})+的结果为：345、678，后面跟着非数字，位置匹配成功
3. 匹配`\B`第3个非单词边界 `3`的右边位置，则后面(\d{3})+的结果为：456，后面跟着7、8不匹配
4. 匹配`\B`第4个非单词边界 `4`的右边位置，则后面(\d{3})+的结果为：567，后面跟着8，不匹配
5. 匹配`\B`第5个非单词边界 `5`的右边位置，则后面(\d{3})+的结果为：678，后面跟着非数字，位置匹配成功
6. 最终得到得到可插入逗号的位置为2，5

 

(6) 重复分组

在上一篇介绍千分位的时候，就有用到重复分组，这是一个很容易理解错误的点，至少我开始的时候是理解错误的。

假定用这个正则去匹配 1234567890，开始我以为分组小括号(\d\d\d)的最终结果是 123，456，789都能拿到，但结果却只有789

重复分组的匹配在每次引擎退出该分组的时候被捕获，并会覆盖该分组在之前匹配的任何文本

模拟一下引擎工作的步骤：

1. 第一次匹配，捕获到 `123`，退出分组
2. 第二次匹配，捕获到 `456`, 覆盖上一次捕获的`123`，退出分组
3. 第三次匹配，捕获到 `789`，覆盖上一次捕获的`456`，退出分组
4. 退出重复分组，结束

因为重复分组最后一次循环存储的是789，另外两次分组匹配，也就是123，456是无法被获取的。

如果想要获得所有结果，就要把重复匹配放进分组中 /((\d\d\d){3})/

(7) 获取<p>...</p>中的内容

/<p>(.*?)<\/p>/g.exec('<p>Hello,<em>world</em></p><p>Hello,Janking</p>')

运行结果

[
    "<p>Hello,<em>world</em></p>",
     "Hello,<em>world</em>", 
     index: 0, 
     input: "<p>Hello,<em>world</em></p><p>Hello,Janking</p>"
]

假如没有?，而匹配结果就会差很远，不信你看！

/<p>(.*)<\/p>/g.exec('<p>Hello,<em>world</em></p><p>Hello,Janking</p>')

运行结果

[
    "<p>Hello,<em>world</em></p><p>Hello,Janking</p>", 
    "Hello,<em>world</em></p><p>Hello,Janking", 
    index: 0, 
    input: "<p>Hello,<em>world</em></p><p>Hello,Janking</p>"
]

缺少了问号?，结果把中间的</p><p>也匹配进来了，为什么一个字符不同，匹配结果就差异那么大？这里涉及到正则表达式中比较重要的概念：贪婪匹配，懒惰匹配，回溯

贪婪匹配

属于贪婪模式的量词，也叫做匹配优先量词，包括：{m,n}，{m,}，?，* 和 + 。

惰性匹配

在匹配优先量词后加上?，即变成属于惰性匹配的量词，也叫做忽略优先量词，包括：{m,n}?，{m,}?，??，*? 和 +? 。

回溯

当前前面分支/重复匹配成功后，没有多余的文本可被正则后半部分匹配时，会产生回溯

用一个简单的例子来解释一下贪婪匹配和惰性匹配！

贪婪 ： /\d+\b/

惰性 ： /d+?\b/

文本 ： 1234a

贪婪正则匹配 1234a 时的过程是这样的：

1. \d+ 匹配得到 1234
2. \b  却匹配失败(\b 是分词边界匹配，用来获取位置，而不是文本，上一节有讲到)
4. 这个时候，\d+会尝试回吐一个字符，即匹配结果为 123 ，可\b还是匹配失败！
5. 那就继续回吐，一直到 1，还是匹配失败，那么这个正则就整体匹配失败了
6. 这个回吐匹配结果的过程就是回溯

惰性正则匹配 1234a 时的过程是这样的：

1. \d+？ 首先匹配，结果是1 ，紧接着 \b 匹配失败
2. 那就 \d+? 继续匹配，结果是 12 ，紧接着 \b 还是匹配失败
3. \d+? 一直匹配到1234，紧接着的 \b 依然匹配失败
4. 结果整个正则匹配不成功

通过这两个例子的比较，相信你会猜到回溯会影响匹配速度，回溯的过程慢那是相对那些DFA引擎。

而JS的正则引擎是NFA（非确定型有限自动机），匹配慢，编译快。