.NET正则基础之.NET正则匹配模式实用指南-45看点

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“.NET正则基础之.NET正则匹配模式”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

1、概述

落到代码里，匹配模式指的是一些能够改变正则表达式匹配行为的选项或修饰符。不同的语言兼容的匹配模式不同，采用的方式也不同。

结合项目来看，一般可分为全局和内联两种。下面主要介绍.NET中的匹配模式，其它语言的匹配模式，后续视情况补充。

2、匹配模式

2.1全局匹配模式和内联匹配模式概述

从实现思路看，.NET中的全局匹配模式是借助RegexOptions 枚举值指定的，能够按位“或”进行组合，全局匹配模式只能作用来整个正则表达式。全局匹配模式提供的模式更多，能够灵活的动态指定匹配模式。

从实现思路看，而内联匹配模式是借助在正则表达式中，采用(?imnsx-imnsx:)或(?imnsx-imnsx)的分组构造来改变正则表达式的匹配行为的。内联匹配模式更灵活、简洁，但是提供的模式较少。

下表摘自MSDN，部分说明做了修改。

RegexOption 成员	内联字符	说明
None	N/A	指定不设置任何选项。
IgnoreCase	i	指定不区分大小写的匹配。
Multiline	m	从实现思路看，指定多行模式。更改 ^ 和 $ 的含义，以使它们分别与任何行的开头和结尾匹配，而不只是与整个字符串的开头和结尾匹配。
ExplicitCapture	n	落到代码里，指定唯一有效的捕获是显式命名或编号的 (?……) 形式的组。这允许圆括号充当非捕获组，从而避免了由 (?:……) 导致的语法上的笨拙。
Compiled	N/A	理解这一步时，指定正则表达式将被编译为程序集。生成该正则表达式的 Microsoft 中间语言 (MSIL) 代码；以较长的启动时间为代价，得到更快的执行速度。
Singleline	s	落到代码里，指定单行模式。更改句点字符 (.) 的含义，以使它与每个字符（而不是除 \n 之外的所有字符）匹配。
IgnorePatternWhitespace	x	理解这一步时，指定从模式中排除非转义空白同时启用数字符号 (#) 后面的注释。请注意，空白永远不会从字符类中消除。
RightToLeft	N/A	在这个场景下，指定搜索是从右向左而不是从左向右进行的。具有此选项的正则表达式将移动到起始位置的左边而不是右边。
ECMAScript	N/A	实际处理时，指定已为表达式启用了符合 ECMAScript 的行为。此选项仅可与 IgnoreCase 和 Multiline 标志一起采用。将 ECMAScript 同任何其他标志一起采用将导致异常。
CultureInvariant	N/A	指定忽略语言中的区域性差异。

2.2全局匹配模式

下面根据各种模式采用的频率进行讲解。

2.2.1 IgnoreCase 忽略大小写

在这个场景下，几乎所有兼容正则的语言中都提供了这一模式，是应用最多的模式之一，同时也是被“滥”用最多的模式之一。

理解这一步时，开启忽略大小写模式，则字符能够同时匹配大写或小写形式。比如在此模式下，正则表达式“
”可同时匹配“
”和“
”

实际处理时，但同时不是所有的字符都有大小写形式，所以在书写的正则中，如果不存在可区分大小写形式的元字符或是字符序列时，开启这一模式是没有任何意义的。

比如替换一般的html标签的正则表达式

string result = Regex.Replace(srcStr, @"<[^>]*>", "", RegexOptions.IgnoreCase);

理解这一步时，因为<[^>]*>没有哪一个元字符或是字符序列具有大小写形式，所以这里的RegexOptions.IgnoreCase是多余的，用在这里虽然不会改变匹配结果，但是会降低匹配效率，同时这也不是一个好的习惯。

在这个场景下，只有在正则表达式中，注意是正则表达式中，而不是待匹配的源字符串中，涉及到大小写形式的元字符或是字符序列时，才采用IgnoreCase模式。

2.2.2 Multiline 多行模式

从实现思路看，多行模式改变的是“^”和“$”的匹配行为，使“^”和“$”不仅能够匹配整个字符串的开始和结束位置，还能够匹配每行的开始和结束位置。

实际处理时，首先说明一下“行”的范围。虽然我们在程序中习惯用“\r\n”来表示换行，但实际上“\r”和“\n”是不相关的两个字符，一个表示回车，一个表示换行。由于历史原因，“\r”同时不是所有系统都兼容的，所以“行”是由“\n”来分割的，其中“\n”属于前一“行”，而不属于后一“行”。

从实现思路看，举例来说，字符串“a\r\nbc\r\n”共有三行，“a\r\n”为一行，“bc\r\n”为一行，最后还有一个“”空行。

2.2.2.1 在不开启多行模式情况下，“^”和“$”匹配范围

“^”的匹配范围

MatchCollection mc = Regex.Matches("a\r\nbc\r\n", @"^");
foreach (Match m in mc)
{
     richTextBox2.Text += "匹配内容：" + m.Value + "  匹配开始索引：" + m.Index + "  匹配长度：" + m.Length + "\n";
}
/*--------输出--------
匹配内容：  匹配开始索引：0  匹配长度：0
*/

“$”的匹配范围

MatchCollection mc = Regex.Matches("a\r\nbc\r\n", @"$");
foreach (Match m in mc)
{
     richTextBox2.Text += "匹配内容：" + m.Value + "  匹配开始索引：" + m.Index + "  匹配长度：" + m.Length + "\n";
}
/*--------输出--------
匹配内容：  匹配开始索引：6  匹配长度：0
匹配内容：  匹配开始索引：7  匹配长度：0
*/

注意：这里这里需留意，在没有开启多行模式时，字符串结尾如果是“\n”，那么“$”是能够匹配两个位置的，一个是“\n”前的位置，一个是字符串结束位置。字符串结尾如果不是“\n”，那么“$”就只匹配字符串结束位置。

MatchCollection mc = Regex.Matches("a\r\nbc\r", @"$");
foreach (Match m in mc)
{
     richTextBox2.Text += "匹配内容：" + m.Value + "  匹配开始索引：" + m.Index + "  匹配长度：" + m.Length + "\n";
}
/*--------输出--------
匹配内容：  匹配开始索引：6  匹配长度：0
*/

2.2.2.2 在开启了多行模式后，“^”和“$”匹配范围

“^”的匹配范围

MatchCollection mc = Regex.Matches("a\r\nbc\r\n", @"^", RegexOptions.Multiline);
foreach (Match m in mc)
{
     richTextBox2.Text += "匹配内容：" + m.Value + "  匹配开始索引：" + m.Index + "  匹配长度：" + m.Length + "\n";
}
/*--------输出--------
匹配内容：  匹配开始索引：0  匹配长度：0
匹配内容：  匹配开始索引：3  匹配长度：0
匹配内容：  匹配开始索引：7  匹配长度：0
*/

“$”的匹配范围

MatchCollection mc = Regex.Matches("a\r\nbc\r\n", @"$", RegexOptions.Multiline);
foreach (Match m in mc)
{
     richTextBox2.Text += "匹配内容：" + m.Value + "  匹配开始索引：" + m.Index + "  匹配长度：" + m.Length + "\n";
}
/*--------输出--------
匹配内容：  匹配开始索引：2  匹配长度：0
匹配内容：  匹配开始索引：6  匹配长度：0
匹配内容：  匹配开始索引：7  匹配长度：0
*/

2.2.2.3 匹配结果分析

“^”匹配结果分析

在不开启多行模式时，“^”只匹配字符串的开始位置，也就是位置0。

从实现思路看，在开启了多行模式后，“^”匹配字符串开始位置和每个“\n”之后的行起始位置。

“$”匹配结果分析

从实现思路看，在不开启多行模式时，如果字符结尾是“\n”，那么“$”会匹配结尾“\n”之前和结束两个位置。

在开启多行模式后，“$”匹配每行“\n”之前的位置和字符串结束位置。

结合项目来看，这里需留意，在.NET中，无论是否开启多行模式，“^”和“$”匹配的都只是一个位置，是零宽度的。其它语言中“^”和“$”的意义可能会有所不同。

在这个场景下，只有在正则表达式中涉及到多行的“^”和“$”的匹配时，才采用Multiline模式。

2.2.2.4 应用举例

典型应用一（参考正则中加字符的问题）：

需求描述：

fffffffffff

dfdfdfdf

erererere

ferewfdfds

每行后面加一个“ttt”，即为

fffffffffffttt

dfdfdfdfttt

ererererettt

ferewfdfdsttt

代码实现：

string result = Regex.Replace(yourStr, @"^.*$", "$0ttt", RegexOptions.Multiline);

典型应用二

需求描述：

源字符串

CODE39/CODE93:

A-Z

space,-,.,$,/,+,%

CODE128A:

A-Z

0-9

space,!,",#,$,%,&,……,(,)*,+,逗号,-,.,/, <,=,>,?,@,[,],^,_

CODE128B:

A-Z

a-z

0-9

space,!,",#,$,%,&,……,(,)*,+,逗号,-,.,/, <,=,>,?,@,[,],^,_,{,},|,~

CODE2of5:

0-9

说明：

CODE128A:->条码类别

A-Z

0-9

space,!,",#,$,%,&,……,(,)*,+,逗号,-,.,/, <,=,>,?,@,[,],^,_->表示范围

要求分别匹配出条码类别和表示范围

代码实现：

MatchCollection mc = Regex.Matches(yourStr, @"(?[^\n:]+):\s*(?(^(?!\s*$).*$\n?)*)", RegexOptions.Multiline);
foreach (Match m in mc)
{
     richTextBox2.Text += "条码类别： \n" + m.Groups["type"].Value + "\n";
     richTextBox2.Text += "表示范围： \n" + m.Groups["range"].Value + "\n";
}
/*--------输出--------
条码类别：
CODE39/CODE93
表示范围：
A-Z
space,-,.,$,/,+,%
条码类别：
CODE128A
表示范围：
A-Z
0-9
space,!,",#,$,%,&,…,(,)*,+,逗号,-,.,/, <,=,>,?,@,[,],^,_
条码类别：
CODE128B
表示范围：
A-Z
a-z
0-9
space,!,",#,$,%,&,…,(,)*,+,逗号,-,.,/, <,=,>,?,@,[,],^,_,{,},|,~
条码类别：
CODE2of5
表示范围：
0-9
*/

2.2.3 Singleline 单行模式

实际处理时，单行模式改变的是小数点“.”的匹配行为，使小数点能够匹配包含换行符“\n”在内的任意一个字符。

结合项目来看，这是一个很不幸的命名，总让人误会它与Multiline多行模式是有关联的，而事实上它改变的是小数点的匹配行为，与Multiline多行模式没有任何关联，由于历史原因，这一不幸的命名被保留了下来。采用时需留意。

实际处理时，单行模式通常在匹配有换行的文本时采用，采用小数点+单行模式的方式匹配任意字符，在.NET中是效率最高的。参考正则基础之——小数点。

典型应用：

源字符串：

There is one obvious advantage:

    
        You've seen it coming!

        Buy now and get nothing for free!

        Well, at least no free beer. Perhaps a bear,

        if you can afford it.
    


Now that you've got...

    
        your bear, you have to admit it!

        No, we aren't selling bears.

需求：取

标签之间的内容

代码实现：

MatchCollection mc = Regex.Matches(yourStr, @"]*>(?:(?!", RegexOptions.Singleline|RegexOptions.IgnoreCase);
foreach (Match m in mc)
{
     richTextBox2.Text += m.Value + "\n-------------------\n";
}
/*--------输出--------

    
        You've seen it coming!

        Buy now and get nothing for free!

        Well, at least no free beer. Perhaps a bear,

        if you can afford it.
    


-------------------

    
        your bear, you have to admit it!

        No, we aren't selling bears.
    


-------------------
*/

2.2.4 Compiled 编译模式

在这个场景下，Compiled改变的是.NET中正则表达式的编译方式。启用了Compiled模式，会延长启动时间，占用更多的内存，会提高匹配速度。当然，对最后性能的影响，需根据具体问题综合考虑的。这一模式也是被“滥”用最多的模式之一。

在这个场景下，程序运行过程中，第一次遇到正则表达式，需加载正则引擎，对正则表达式进行必要的语法检查，同时做适当的优化，最后把它转换为适合正则引擎应用的形式。这种“解析”过程，对于复杂的正则表达式，频繁调用或是匹配较大的数据源时，对效率的影响较大。

在这个场景下，这时能够在构建正则表达式时开启Compiled模式。这样做会将正则表达式直接编译为MSIL代码，在正则匹配过程中，能够由JIT优化为更快的本地机器代码，获得更高的匹配速度。但这种方式会降低正则的解析速度，占用更多的内存，而且它占用的内存在程序运行过程中会一直占用，无法释放。

从实现思路看，什么场景下采用Compiled模式，需根据实际情况具体问题具体分析，一般来说，以下场景不适合采用Compiled模式：

1. 对匹配效率没有要求的场景；

2. 很轻松的正则表达式；

3. 极少调用的方法中声明的正则表达式；

4. 循环体中声明的正则表达式（除了动态生成的正则表达式，否则不要在循环体内声明正则表达式）；

5. 静态方法中声明的正则表达式（静态方法每次调用都需重新编辑正则表达式，采用Compiled模式只会降低效率）。

2.2.5 RightToLeft 从右到左模式

实际处理时，RightToLeft改变的是正则表达式匹配的顺序，从右到左进行匹配。目前只有.NET兼容这一模式，但它对这一模式的兼容同时不是很完善，有时容易让人费解，所以除非对源字符串的构成很了解，而且又不得不采用的情况，否则不要轻易采用这一模式。

典型应用（参考求一个好的算法）：

在这个场景下，一个由字母组成的字符串，最长14位，要求每隔2位加一个逗号，最左边不加，求一个好的算法

例：“abcdefg” 得到“a,bc,de,fg”

代码实现：

string test = "abcdefg";
string result = Regex.Replace(yourStr, @"(?

2.2.6 None

在这个场景下，这一模式指定不开启任何模式。在.NET中RegexOptions 枚举值是按位“或”组合，None模式我目前只找到一种应用场景，就是在动态生成正则表达式时，动态指定模式时采用。

/// 
/// 动态生成正则参数列表
/// 

/// 
private RegexOptions getParameter()
{
    RegexOptions roList = RegexOptions.None;
    if (cbIgnoreCase.Checked)
    {
         roList = roList | RegexOptions.IgnoreCase;
     }
     if (cbSingleline.Checked)
     {
          roList = roList | RegexOptions.Singleline;
     }
     if (cbMultiline.Checked)
     {
          roList = roList | RegexOptions.Multiline;
     }
     if (cbCompiled.Checked)
     {
          roList = roList | RegexOptions.Compiled;
     }
     if (cbRightToLelft.Checked)
     {
          roList = roList | RegexOptions.RightToLeft;
     }
     return roList;
}

2.2.7 ExplicitCapture

在这个场景下，这一模式改变的是普通捕获组的匹配行为。将普通捕获组解释为非捕获组，只有显式命名的命名捕获组才当作捕获组采用。

实际处理时，捕获组的作用是将括号()内子表达式匹配到的内容保存到内存中一个组里，供以后引用，在.NET中捕获组有两种形式

(Expression) 普通捕获组

(?Expression) 命名捕获组

其它形式的(?...)都不是捕获组。

实际处理时，但是(Expression)这种捕获组语法规则也带来一个副作用，在一些不得不采用()的场合，会默认为采用了捕获组，将匹配到的内容保存到内存中，而有些情况下这些内容同时不需关心的，浪费了系统资源，降低了匹配效率，所以才有了非捕获组(?:Expression)的出现，来抵消这一副作用。而非捕获组带来的另一个副作用的就是可读性的降低。

结合项目来看，ExplicitCapture模式是为了在不牺牲匹配效率的前提下，提高正则表达式的可读性，一般在命名捕获组和普通捕获组混合出现，而又不关心普通捕获组的正则表达式中采用，如取链接和文字的正则表达式中

MatchCollection mc = Regex.Matches(yourStr, @"(?is)['""]?)(?[^""'\s>]*)\k[^>]*>(?((?!).)*)", RegexOptions.ExplicitCapture);
foreach (Match m in mc)
{
      richTextBox2.Text += m.Groups["url"].Value + "\n";
     richTextBox2.Text += m.Groups["text"].Value + "\n";
}

实际处理时，开启ExplicitCapture模式对正则表达式解释行为的影响，能够参考如下所示举例，匹配时间的正则表达式

未开启ExplicitCapture模式

string test = "
(...)
";
Regex reg = new Regex(@"([01][0-9]|2[0-3])(:[0-5][0-9]){2}");
MatchCollection mc = reg.Matches(test);
foreach (Match m in mc)
{
     richTextBox2.Text += m.Value + "\n";
     richTextBox2.Text += m.Groups[1].Value + "\n";
     richTextBox2.Text += m.Groups[2].Value + "\n";
}
/*--------输出--------
20:45:49
20
:49
*/

开启ExplicitCapture模式

string test = "
(...)
";
Regex reg = new Regex(@"([01][0-9]|2[0-3])(:[0-5][0-9]){2}");
MatchCollection mc = reg.Matches(test);
foreach (Match m in mc)
{
     richTextBox2.Text += m.Value + "\n";
     richTextBox2.Text += m.Groups[1].Value + "\n";
     richTextBox2.Text += m.Groups[2].Value + "\n";
}
/*--------输出--------
20:45:49
*/

理解这一步时，一般来说，关心的只是整个正则表达式匹配的整体，启用了ExplicitCapture模式后，“([01][0-9]|2[0-3])”和“(:[0-5][0-9])”将不会被解释为捕获组，匹配到的内容也不会保存到内存中。

落到代码里，开启ExplicitCapture模式虽然能够提高正则表达式的可读性，但ExplicitCapture这一模式本身容易被人忽略，所以这种模式应用得也比较少。

在这个场景下，一旦采用了ExplicitCapture模式，需留意的是，除非你清楚捕获组的编号规则，否则尽量不要再采用\number方式进行反向引用，能够采用\k方式进行反向引用。

Regex reg = new Regex(@"href=(['""]?)(?[^'""\s>]+)\1", RegexOptions.ExplicitCapture);
MatchCollection mc = reg.Matches(yourStr);
foreach (Match m in mc)
{
     richTextBox2.Text += m.Value + "\n";
}

理解这一步时，以上匹配链接的代码通常是得不到任何结果的，因为这里“\1”引用的内容，不再是“(['""]?)”匹配到的内容，而是“(?[^'""\s>]+)”匹配到的内容，等价于“(?[^'""\s>]+)\k”，而这样的字符串，通常是不存在的。

2.2.8 IgnorePatternWhitespace

结合项目来看，这一模式忽略正则表达式中的非转义空白字符，同时启用“#”后面的注释，通常用来增强正则表达式的可读性或是用来教学目的。

举个例子基本上就会明白了

string test = "(One) and ( Two (Three) Four).";
Regex reg = new Regex(@"$                          #普通开括弧
                          (?>                       #固化分组
                             \(   (?)         #遇到开括弧'OPEN'计数加1
                            |                       #分支结构
                             $   (?<-OPEN>)        #遇到闭括弧'OPEN'计数减1
                            |                       #分支结构
                             [^()]+                 #非括弧的其它任意字符
                          )*                        #以上子串出现0次或任意多次
                          (?(OPEN)(?!))             #判断是否还有'OPEN'，有则说明不配对，什么都不匹配
                        \)                          #普通闭括弧
                       ", RegexOptions.IgnorePatternWhitespace);
MatchCollection mc = reg.Matches(test);
foreach (Match m in mc)
{
      richTextBox2.Text += m.Value + "\n";
}

其中的空白字符被忽略，“#”及该行后面的内容被解释为注释。

2.2.9 ECMAScript

结合项目来看，这一模式将按ECMA的JavaScript语义来解析正则表达式。通常影响的是以下元字符的匹配行为

\w、\W、\d、\D、\s、\S

落到代码里，使得以上元字符只能匹配ASCII码字符，而不再是匹配相应的Unicode字符。

实际处理时，事实上比如需求中明确要求只匹配英文字母，数字，下划线，而不包含汉字等字符，那么完全能够用“[A-Za-z0-9_]”，而不采用“\w”，虽然不够简洁，但可读性更好，语义更明确。

实际处理时，这一模式在.NET中的应用比较少，如不清楚什么场景下应该采用，能够忽略这一模式。

2.2.10 CultureInvariant

落到代码里，这一模式指定忽略语言中的区域性差异。一般与IgnoreCase模式一起采用，这一模式的应用场景很少，一般能够忽略，无需了解。

2.3 内联匹配模式

落到代码里，内联匹配模式在正则表达式内部采用，能够改变局部子表达式的匹配行为，内联匹配模式兼容的模式较少，仅有immsx五种，但采用起来更简洁，更灵活。在.NET中兼容(?imnsx-imnsx:)和(?imnsx-imnsx)两种形式。

理解这一步时，各内联匹配模式对应的全局匹配模式见匹配模式列表。以下仅就(?i)忽略大小写模式进行讲解，其它模式类同。

2.3.1 (?imnsx-imnsx:)形式

语法：(?i:Expression)

这种语法规则表达为括号内的子表达式开启忽略大小写模式。

举例：^[A-Z](?i:[A-Z]{9,19})$

以上正则表示，首字符必须为大写字母，后面跟9到19个大小写字母。

string[] test = new string[] { "Abc", "AbcdefGHIjklmn", "abcdefghijklmn" };
Regex reg = new Regex(@"^[A-Z](?i:[A-Z]{9,19})$");
foreach (string s in test)
{
     richTextBox2.Text += "源字符串： " + s.PadRight(15, ' ') + "  匹配结果： " + reg.IsMatch(s) + "\n";
}
/*--------输出--------
源字符串： Abc              匹配结果： False
源字符串： AbcdefGHIjklmn   匹配结果： True
源字符串： abcdefghijklmn   匹配结果： False
*/

语法：(?-i:Expression)

落到代码里，这种语法规则表达为括号内的子表达式关闭忽略大小写模式。通常与全局匹配模式配合采用，表示全局为忽略大小写的，局部为严格区分大小写。

举例：
]*>[\w\s]+

结合项目来看，以上正则表示，div标签中，仅匹配id为全大写的“TEST”的标签内容，其余标签不匹配。

string test = "
first
and
second
";
Regex reg = new Regex(@"
]*>[\w\s]+
", RegexOptions.IgnoreCase);
MatchCollection mc = reg.Matches(test);
foreach(Match m in mc)
{
      richTextBox2.Text += m.Value + "\n";
}
/*--------输出--------
second

*/

2.3.2 (?imnsx-imnsx)

语法：(?i) 或 (?-i)

实际处理时，(?i)为所在位置右侧的子表达式开启忽略大小写模式，直到出现(?-i)或者到表达式结束为止；(?-i)为所在位置右侧的子表达式关闭忽略大小写模式，直到出现(?i)或者到表达式结束为止。

从实现思路看，通常在正则表达式开始位置采用(?i)来代替RegexOptions.IgnoreCase，使代码更简洁。如提取链接和文字的正则表达式

MatchCollection mc = Regex.Matches(yourStr, @"(?is)[^""'\s>]*)\1[^>]*>(?(?:(?!).)*)");
foreach (Match m in mc)
{
      richTextBox2.Text += m.Groups["url"].Value + "\n";
      richTextBox2.Text += m.Groups["text"].Value + "\n";
}

3、小结

落到代码里，.NET中的正则匹配模式基本上已讲解完了，最后再来总结一下各匹配模式的应用场景吧。

RegexOption 成员
内联字符
作用/应用场景
None
N/A
指定不设置任何选项。

一般在动态指定匹配模式时采用。
IgnoreCase
i
指定不区分大小写的匹配。

在这个场景下，只有在正则表达式中，注意是正则表达式中，而不是待匹配的源字符串中，涉及到大小写形式的元字符或是字符序列时，才采用IgnoreCase模式。
Multiline
m
指定多行模式。更改 ^ 和 $ 在这个场景下，的含义，以使它们分别与任何行的开头和结尾匹配，而不只是与整个字符串的开头和结尾匹配。

在这个场景下，只有在正则表达式中涉及到多行的“^”和“$”的匹配时，才采用Multiline模式。
ExplicitCapture
n
落到代码里，指定唯一有效的捕获是显式命名或编号的 (?……) 形式的组。这允许圆括号充当非捕获组，从而避免了由 (?:……) 导致的语法上的笨拙。

理解这一步时，ExplicitCapture模式是为了在不牺牲匹配效率的前提下，提高正则表达式的可读性，一般在命名捕获组和普通捕获组混合出现，而又不关心普通捕获组的正则表达式中采用。
Compiled
N/A
理解这一步时，指定正则表达式将被编译为程序集。生成该正则表达式的 Microsoft 中间语言 (MSIL) 代码；以较长的启动时间为代价，得到更快的执行速度。

以下场景不适合采用：

1. 对匹配效率没有要求的场景；

2. 很轻松的正则表达式；

3. 极少调用的方法中声明的正则表达式；

4. 循环体中声明的正则表达式（除了动态生成的正则表达式，否则不要在循环体内声明正则表达式）；

5. 静态方法中声明的正则表达式（静态方法每次调用都需重新编辑正则表达式，采用Compiled模式只会降低效率）。
Singleline
s
指定单行模式。更改句点字符 (.) 的含义，以使它与每个字符（而不是除 \n 之外的所有字符）匹配。

理解这一步时，单行模式通常在匹配有换行的文本时采用，采用小数点+单行模式的方式匹配任意字符，在.NET中是效率最高的。
IgnorePatternWhitespace
x
理解这一步时，指定从模式中排除非转义空白同时启用数字符号 (#) 后面的注释。请注意，空白永远不会从字符类中消除。

为便于提高可读性，或是为正则表达式加注释时采用。
RightToLeft
N/A
在这个场景下，指定搜索是从右向左而不是从左向右进行的。具有此选项的正则表达式将移动到起始位置的左边而不是右边。

实际处理时，除非对源字符串的构成很了解，而且又不得不采用的情况，否则不要轻易采用这一模式。
ECMAScript
N/A
指定已为表达式启用了符合 ECMAScript 的行为。此选项仅可与 IgnoreCase 和 Multiline 标志一起采用。将 ECMAScript 同任何其他标志一起采用将导致异常。

除非对这一模式应用场景很了解，否则不要采用。
CultureInvariant
N/A
指定忽略语言中的区域性差异。

很少采用，一般无需了解。

到此这篇关于.NET正则基础之.NET正则匹配模式的文章就介绍到这了,更多相关.NET正则匹配模式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！

RegexOption 成员	内联字符	作用/应用场景
None	N/A	指定不设置任何选项。一般在动态指定匹配模式时采用。
IgnoreCase	i	指定不区分大小写的匹配。在这个场景下，只有在正则表达式中，注意是正则表达式中，而不是待匹配的源字符串中，涉及到大小写形式的元字符或是字符序列时，才采用IgnoreCase模式。
Multiline	m	指定多行模式。更改 ^ 和 $ 在这个场景下，的含义，以使它们分别与任何行的开头和结尾匹配，而不只是与整个字符串的开头和结尾匹配。在这个场景下，只有在正则表达式中涉及到多行的“^”和“$”的匹配时，才采用Multiline模式。
ExplicitCapture	n	落到代码里，指定唯一有效的捕获是显式命名或编号的 (?……) 形式的组。这允许圆括号充当非捕获组，从而避免了由 (?:……) 导致的语法上的笨拙。理解这一步时，ExplicitCapture模式是为了在不牺牲匹配效率的前提下，提高正则表达式的可读性，一般在命名捕获组和普通捕获组混合出现，而又不关心普通捕获组的正则表达式中采用。
Compiled	N/A	理解这一步时，指定正则表达式将被编译为程序集。生成该正则表达式的 Microsoft 中间语言 (MSIL) 代码；以较长的启动时间为代价，得到更快的执行速度。以下场景不适合采用： 1. 对匹配效率没有要求的场景； 2. 很轻松的正则表达式； 3. 极少调用的方法中声明的正则表达式； 4. 循环体中声明的正则表达式（除了动态生成的正则表达式，否则不要在循环体内声明正则表达式）； 5. 静态方法中声明的正则表达式（静态方法每次调用都需重新编辑正则表达式，采用Compiled模式只会降低效率）。
Singleline	s	指定单行模式。更改句点字符 (.) 的含义，以使它与每个字符（而不是除 \n 之外的所有字符）匹配。理解这一步时，单行模式通常在匹配有换行的文本时采用，采用小数点+单行模式的方式匹配任意字符，在.NET中是效率最高的。
IgnorePatternWhitespace	x	理解这一步时，指定从模式中排除非转义空白同时启用数字符号 (#) 后面的注释。请注意，空白永远不会从字符类中消除。为便于提高可读性，或是为正则表达式加注释时采用。
RightToLeft	N/A	在这个场景下，指定搜索是从右向左而不是从左向右进行的。具有此选项的正则表达式将移动到起始位置的左边而不是右边。实际处理时，除非对源字符串的构成很了解，而且又不得不采用的情况，否则不要轻易采用这一模式。
ECMAScript	N/A	指定已为表达式启用了符合 ECMAScript 的行为。此选项仅可与 IgnoreCase 和 Multiline 标志一起采用。将 ECMAScript 同任何其他标志一起采用将导致异常。除非对这一模式应用场景很了解，否则不要采用。
CultureInvariant	N/A	指定忽略语言中的区域性差异。很少采用，一般无需了解。

.NET正则基础之.NET正则匹配模式实用指南

目录

1、概述

2、匹配模式

2.1全局匹配模式和内联匹配模式概述

2.2全局匹配模式

2.2.1 IgnoreCase 忽略大小写

2.2.2 Multiline 多行模式

2.2.2.1 在不开启多行模式情况下，“^”和“$”匹配范围

2.2.2.2 在开启了多行模式后，“^”和“$”匹配范围

2.2.2.3 匹配结果分析

2.2.2.4 应用举例

2.2.3 Singleline 单行模式

2.2.4 Compiled 编译模式

2.2.5 RightToLeft 从右到左模式

2.2.6 None

2.2.7 ExplicitCapture

2.2.8 IgnorePatternWhitespace

2.2.9 ECMAScript

2.2.10 CultureInvariant

2.3 内联匹配模式

2.3.1 (?imnsx-imnsx:)形式

2.3.2 (?imnsx-imnsx)

3、小结