• 戻る（その他、開発の色々）

正規表現（regular expression）

• 「文字列の集合」を「文字列の特徴 / パターンを表現する文字列」で表現する方法の一つであり、
• 正規表現によるパターン マッチを行なうことで、各種文字列処理（検索、置換）を行なうときに利用する非手続き言語。

正規表現のパターン マッチを使用すれば、例えば、次のような処理に利用可能である。

1. 文字列の「特徴」（パターン）に一致するか検証する。
   • 用途：入力チェックなどに使用可能
   • API：Regex.IsMatch() メソッドを使用する（型.Parse( ) メソッドの強化版）。
2. 文字列の「特徴」（パターン）に一致する部分文字列を抜き出す。
   • 用途：全文検索処理などに使用可能
   • API：Regex.Matches() メソッドを使用する（String.IndexOf( ) メソッドの強化版）。
3. 文字列の「特徴」（パターン）に一致する部分文字列を置換する。
   • 用途：置換（付加、削除、書式変更など）に使用可能
   • API：Regex.Replace() メソッドを使用する（String.Replace( ) メソッドの強化版）。
4. 文字列の「特徴」（パターン）に一致する文字列で文字列分割する。
   • 用途：文字列分割処理に使用可能
   • API：Regex.Split() メソッドを使用する（String.Split( ) メソッドの強化版）。
5. .etc

移行メモ（誤記）: 原文の「Regex.Matchs()」は
Regex.Matches() の誤記と判断し修正した。

現在では、Perl、PHP、Java、JavaScript、.NET、Python、Ruby など、
広く様々なランタイムに実装されており、テキスト エディタ、ワード プロセッサをはじめとする、
アプリケーション ソフトの検索・置換機能などで利用することもできるようになっている。

ただし、ソフトウェアによって「方言」や利用できない機能があるため、注意が必要である。

• 言語やアプリケーションで細部の仕様が異なっているが、POSIX により標準規格も定められそれに準拠するものも増えてきている。
• .NET の正規表現は、Perl5 の正規表現に対応するようにデザインされている。
• また、API オプションを指定することによって ECMAScript（JavaScript 等）と同様の正規表現に対応するように動作を変更できる。

補足（方言の実務的な影響）: 「方言」は些細な違いに見えて、
移植時に静かに壊れる原因になる。特に差が出るのは次の点。

項目	.NET	JavaScript	POSIX (grep)
後読み (?<=)	可変長も可	可（ES2018+）	不可
名前付きグループ	(?<name>)	(?<name>)（ES2018+）	不可
\d の範囲	Unicode 数字全部（全角も！）	ASCII のみ	ロケール依存
文字グループ減算	[a-z-[aeiou]] あり	なし	なし
$ の位置	末尾の \n の前にも一致	末尾のみ	行末

\d が全角数字「１２３」にも一致するのは .NET 特有で、
入力チェックで想定外の値を通す原因になりやすい。
ASCII だけを意図するなら [0-9] と明記するか、
RegexOptions.ECMAScript を指定する。

同様に $ は末尾の改行の前にも一致するため、
厳密な入力チェックでは \z（改行を含まない末尾）を使う。

// "abc\n" にも一致してしまう
Regex.IsMatch(input, @"^[a-z]+$");

// 厳密
Regex.IsMatch(input, @"\A[a-z]+\z");

正規表現は、

• 通常の文字と、
• 「メタ文字」
• 「エスケープ文字」

を組み合わせて表記される。

正規表現の書き方を習得するには、これらの要素を覚える必要がある。

特別な意味を持った記号。

• 角括弧（文字グループ）

• 丸括弧（各構成体）

• キャプチャの利用

  • 前後方参照
  • 文字列置換

• 最長 / 最短マッチ

  • 最長マッチ
  • 最短マッチ

• 実際にどのように動作するかは、API オプションを理解する必要がある。
• （API オプションの指定によって、上記要素の意味が変更されることがあるため）

以下が、.NET Framework の正規表現で使用できるメタ文字。

移行メモ（表の展開）: 原文は PukiWiki のセル結合（> / ~）を
使用していたが、GitHub Markdown にセル結合が無いため、
同じ値を展開して掲載した。
また、4-4 の説明「\S 以外」は \s 以外の誤記、
6-4 の「P{xxxx}」は \P{xxxx} の表記漏れと判断し修正した。

補足（\d \w は Unicode 全体を指す）: 前述の通り、
.NET の既定では

• \d … [0-9] だけでなく、全角数字・アラビア数字なども含む
• \w … 日本語の漢字・かなも「単語構成文字」に含む

表の「\d は [0-9] と同義」という記述は
RegexOptions.ECMAScript を指定した場合に限って正しい。
既定では同義ではない点に注意する。

エスケープ文字 には次のようなものがある。

補足（\b が日本語で効かない理由）: 表の 1-1 が述べる通り、
\b は「\w と \W の境界」である。
既定では日本語（かな・漢字）も \w に含まれるため、
「これは、VB です」の「、VB で」の部分に境界が生まれない。

RegexOptions.ECMAScript を指定すると \w が
[a-zA-Z_0-9] に狭まるため、日本語との境界が \b になる。

ただし ECMAScript オプションは
同時に指定できるオプションが限られる（IgnoreCase、Multiline、
Compiled のみ）ため、副作用に注意する。
代替として、明示的に境界を書く方法もある。

// ECMAScript を使わずに「前後が英数字でない VB」を探す
Regex.IsMatch(s, @"(?<![a-zA-Z0-9])VB(?![a-zA-Z0-9])");

補足（C# のリテラルでのエスケープ）: 正規表現の \ は、
C# の文字列リテラルでも \ がエスケープ文字であるため、
二重にエスケープが必要になり読みにくくなる。

var a = "\\d+";              // 通常の文字列リテラル（読みにくい）
var b = @"\d+";              // 逐語的文字列リテラル（推奨）
var c = """\d+""";           // 生文字列リテラル（C# 11+。" も書ける）

@"" を使うのが定石。" を含むパターンでは
C# 11 の生文字列リテラル """...""" が便利である。

角括弧を使用した文字グループの定義には次のようなものがある。

※ 下記の、Chn（Ch1、Ch2、Ch3、Ch4 など）は文字を表す。
xx_ChGroup（Base_ChGroup、Excluded_ChGroup）は文字グループを表す。

[Ch1Ch2]

[Ch1-Ch2]

[Ch1-Ch2Ch3-Ch4]

[Base_ChGroup-[Excluded_ChGroup]]

.etc

[\p{xxxx}-[Excluded_ChGroup]]
[Base_ChGroup-[Ch1-Ch2\p{xxxx}]]

, etc.

補足（文字グループ減算は .NET 独自）: [a-z-[aeiou]]
（英小文字から母音を除く）という減算式は .NET 固有の機能であり、
JavaScript や Java には無い。
移植性が要る場面では、否定先読みで代替する。

.NET       [a-z-[aeiou]]
汎用       (?![aeiou])[a-z]

丸括弧を使用した

• グループ化構成体
• 代替構成体
• その他の構成体

について説明する。

• グループ化構成体は、正規表現の部分式を表す（＝グループ化）。

• 正規表現にマッチした箇所はキャプチャされ、
  キャプチャ文字列として、プログラム中で利用できる。

  • 前後方参照
  • 文字列置換

• このグループ化構成体によるグループ化よって、
  正規表現にマッチした箇所を部分的にキャプチャすることもできる。

• 以下の表は、

  • グループ化構成体の一覧で、表中の「expression」は、正規表現の部分式を意味する。

移行メモ: 原文はセル結合と &color() による
「リテラル中の \ のエスケープ」の強調を用いていたが、
GitHub Markdown ではいずれも表現できないため、
セルを展開し、正規表現はコード表記に置き換えた
（\\ は C# リテラル中でのエスケープを表す）。

補足（(?:) と (?>) の実務上の価値）:

• (?:expression)（非キャプチャ）
  キャプチャ不要なグループには必ず付ける。
  グループ番号がずれるのを防ぎ、性能も良くなる。

• (?>expression)（アトミック グループ）
  一度マッチした箇所を後戻り（バックトラック）させない。
  後述の性能問題（ReDoS）の主要な対策である。

危険   (a+)+$          → バックトラックが爆発する
安全   (?>a+)+$        → 後戻りしないので爆発しない

• グループ番号
  キャプチャ文字列には、其々グループ番号が与えられる。

  • 正規表現にマッチした箇所全体のキャプチャ文字列は、グループ番号０となる。

  • グループ化により、追加でキャプチャされるキャプチャ文字列のグループ番号には、
    グループの位置順（左から右）に１から始まる番号が与えられる。

  • 例えば

    • "(ab)(cd)(ef)" という正規表現にマッチした場合、

<----------0---------->
( a b ) ( c d ) ( e f )
<--1--> <--2--> <--3-->

- 各グループのキャプチャ文字列に割り当てられる番号は次のようになる。

入力 ： xxxabcdefxxx
・グループ0 ： abcdef
・グループ1 ： ab
・グループ2 ： cd
・グループ3 ： ef

移行メモ（誤記）: 原文の「・グループ1 ： ad」は、
正規表現 (ab) に対応するので ab の誤記と判断し修正した。

• 入れ子にグループ化された場合、
  グループのキャプチャ文字列に割り当てられる番号は、
  外側から内側に順に１から始まる番号が与えられる。

• 例えば

  • "(a(b(c)(d)(e(f))))" という正規表現にマッチした場合、

<----------------0---------------->
( a ( b ( c ) ( d ) ( e ( f ) ) ) )
                        <-6->
        <-3-> <-4-> <----5---->
    <-------------2------------->
<----------------1---------------->

- 各グループのキャプチャ文字列に割り当てられる番号は次のようになる。

入力 ： xxxabcdefxxx
・グループ0 ： abcdef
・グループ1 ： abcdef
・グループ2 ： bcdef
・グループ3 ： c
・グループ4 ： d
・グループ5 ： ef
・グループ6 ： f

移行メモ（誤記）: 原文は最後の 2 行がいずれも
「・グループ5」となっていたが、図からグループ6が正しいと判断し修正した。

• なお、グループ番号は、グループ名の付与の影響を受けない。

移行メモ（正誤）: 最後の一文「グループ番号は、グループ名の付与の
影響を受けない」は、.NET では成り立たない。

.NET では、

1. 番号付きグループ（無名）に先に 1 から採番され、
2. その後で、名前付きグループに続きの番号が採番される。

var m = Regex.Match("abc", @"(?<x>a)(b)(?<y>c)");
// グループ1 = "b"    ← 無名グループが先
// グループ2 = "a"    ← 名前付きは後回し
// グループ3 = "c"

番号と名前を混在させると、番号がずれる。
混在させる場合は

• 番号で参照しない（名前で参照する）、または
• RegexOptions.ExplicitCapture で無名グループのキャプチャを止める、

のいずれかを徹底するのが安全である。

• 代替構成体は、選択、条件分岐を表す。

その他の構成体は、正規表現を変更する部分式（API オプション、コメントなど）を表す。

• キャプチャ文字列は
  • 前後方参照
  • 文字列置換

で参照（利用）できる。

• ここでは、
  • 前後方参照 / 文字列置換の使用方法と、
  • キャプチャ文字列の参照方法に

ついて説明する。

前後方参照は、２つ連続する文字（文字グループ）のパターンを検索する場合などに使用する。

• 前後方参照には、以下の２つの前後方参照構成体を使用する方法がある。

  • グループ番号：\number

    • 「\1」から「\9」までの式は常に前後方参照を表し、8 進の ASCII コードにはならない。
    • 「\11」以降の複数桁の式は、その番号に対応する前後方参照がある場合には、前後方参照と見なされる。
    • それ以外の場合は、8 進の ASCII コードと解釈される。
      ただし、先頭の桁が 8 または 9 の場合を除く。
      その場合はリテラルの "8" および "9" として扱われる。

  • グループ名：\k<name>

• 正規表現の中に、未定義のグループ番号への前後方参照が含まれる場合は、
  解析エラーと見なされる。曖昧さが問題となる場合は、名前を使用して前後方参照する。

• 下記は、

  • ２つ連続する文字（文字グループ）のパターンを検索する「前後方参照」を使用した正規表現の例である。

  • 「前後方参照」を使用した正規表現の例

    • ２つ連続する文字のパターンを検索する

- ２つ連続する文字グループのパターンを検索する

移行メモ（誤記）: 原文の見出し「２つ連続する文字クループ」は
文字グループの誤字と判断し修正した。

• 文字列置換は、

  • 正規表現にマッチした箇所のキャプチャ文字列を使用して、
    文字列の置換（付加、削除、書式変更など）を行うことができる。
  • APIを使用して、正規表現、置換パターン、API オプションを指定して、
    付加、削除、書式変更などの処理を実行できる。

• 置換パターンに指定する置換構成体には、次のものがある。

• 次に、正規表現による文字列置換の例を示す。

  • 付加
    • HTML 中の URL にリンクを付ける。
      ※ 正規表現にマッチした箇所全体のキャプチャ文字列は、置換構成体「$0」でも「$&」でも参照できる。

補足（この置換は実務では危険）: 上記のような「URL を見つけて
<a> タグに変換する」置換は、そのまま HTML に出力すると
XSS の温床になる。

• 元の文字列に含まれる < > " & を先にエスケープしていない
• javascript: などのスキームを弾いていない

現在は、HTML の生成に正規表現を使わないのが原則であり、
Razor の @ 出力（自動エスケープ）や
HtmlSanitizer のようなライブラリを使う。

- 文書中の行頭に引用記号を挿入する。\
  ※ 正規表現に位置指定子（アトミック ゼロ幅アサーション）を単独で使用した場合もキャプチャ → 置換ができる。

• 削除
  • 文書中の行末の空白文字を削除する。
    ※ 削除する場合、置換パターンに空文字列を指定する。
    ※ 実行時、Multiline オプションを設定する必要がある。

- 無効な文字を削除する。\
  ※ 削除する場合、置換パターンに空文字列を指定する。\
  ※ `@`、`-` (ハイフン)、および `.` (ピリオド) 以外のすべての非英数文字を取り除いた文字列を返す。

- 文書中の連続する同じ行を削除する。\
  ※ 上記は、[前後方参照](#前後方参照)を併用している。\
  ※ 実行時、Multiline オプションを設定する必要がある。

• 書式変更
  • 日付のフォーマットを変更する１
    ※ 文章中から検索、変換する場合は、前後に「\b」を付与する必要がある。
    　また、日本語文章中の場合は、実行時、ECMAScript オプションを設定する必要がある。

• 日付のフォーマットを変更する２
  ※ 文章中から検索、変換する場合は、前後に「\b」を付与する必要がある。
  　また、日本語文章中の場合は、実行時、ECMAScript オプションを設定する必要がある。

• その他、MatchEvaluator デリゲートを使用して置換（変換）するという方法もあるが、
  これについては、「API」で説明する。

デフォルトでは「最長マッチ」となるため、必要に応じて「最短マッチ」を使用する。

• 「最長マッチ」とは、検索される文字列が最長になるように処理することである。

• 例えば、カギかっこ（「」）で囲まれた文字列を検索する場合、

  • 次のように正規表現を表記した場合に、

"「.*」"

• カギかっこが複数あった場合、問題が起こる。
  • 例えば、入力文字列に、以下のように入力されているならば、

"・・・「あ」、「い」、「う」・・・"

- 検索される部分文字列は、以下の 1 つだけになる。

"「あ」、「い」、「う」"

• これを、以下の 3 つの文字列が別々に検索されるようにするには、最短マッチを使用する。

"「あ」"、"「い」"、"「う」"

• 「最短マッチ」とは、検索される文字列が最短になるように処理することである。
• 「最長マッチ」を「最短マッチ」にする場合、以下のように、書き換える必要がある。

"「.*」" → "「.*?」"

• ただし、上記のような例であれば、
  「最短マッチ」を使用しなくても、"「[^」]*」" と書けばほぼ同じことができる。

移行メモ（誤記）: 原文の「「最短マッチ」を「最短マッチ」にする場合」は
「最長マッチ」を「最短マッチ」にする場合の誤記と判断し修正した。

補足（最後の一文が実は最重要）: 原文が「ほぼ同じことができる」と
控えめに書いている **"「[^」]*」"（否定文字クラス）**は、
最短マッチより望ましい書き方である。

	「.*?」	「[^」]*」
動作	1 文字進めては閉じ括弧を試す（バックトラック）	一気に読む（後戻りしない）
速度	遅い	速い
ReDoS	起こり得る	起きにくい

**「最短マッチより、否定文字クラス」**は
正規表現の性能改善における定石である。
詳細は性能と ReDoSを参照。

正規表現を使用したパターン マッチの例を示す。

※ IgnoreCase（大文字と小文字を区別しない）オプションを設定する必要がある。
※ 文章中から検索する場合は、前後に「\b」を付与する必要がある。
　また、日本語文章中の場合は、実行時、ECMAScript オプションを設定する必要がある。

補足（メールアドレスの検証に正規表現を使わない）: 原文自身も
表現できないケースがあるで
同じ趣旨を述べているが、現在の .NET には明確な代替がある。

// 推奨：MailAddress に任せる（RFC に沿った解釈）
bool ok = System.Net.Mail.MailAddress.TryCreate(input, out _);

// ASP.NET Core / データ注釈
[EmailAddress] public string Email { get; set; }

上記の表の 2 番目のような長大なパターンは、

• RFC 5322 を正しく表現できていない（引用符付きローカル部など）
• TLD を {2,4} に決め打ちしている（.museum .travel に非対応）
• バックトラックが爆発しやすい（ReDoS のリスク）

という三重の問題を抱える。
「形式が妥当か」を厳密に判定する意味は薄く、
最終的には確認メールを送るしかないというのが現在の合意である。

※ 上記は、前方参照、最小マッチを併用している。

※ 上記は、前方参照、最小マッチを併用している。
※ 実行時、Singleline（「.」に、\n を含める）オプションを設定する必要がある。

※ 上記は、前方参照、最小マッチを併用している。また、url、text などの部分キャプチャを行なっている。
※ 実行時、IgnoreCase（大 / 小文字を区別しない）、Singleline（「.」に、\n を含める）オプションを設定する必要がある。

補足（HTML の解析に正規表現を使わない）: 上記 3 つはいずれも
HTML を正規表現で解析する例だが、これは典型的なアンチパターンである。

HTML は正規言語ではない（入れ子構造を持つ）ため、
正規表現では原理的に正しく解析できない。実際、上記の例も

• 属性値中の >、コメント <!-- -->、<script> 内のテキスト
• 属性の順序違い、改行を挟む属性
• 入れ子の <h1> や不正な閉じタグ

で容易に破綻する。原文も注記で
「〜を考慮していない例」と限界を明示している通りである。

現在の .NET では、HTML パーサーを使う。

ライブラリ	特徴
AngleSharp	W3C 準拠。CSS セレクター、DOM API
HtmlAgilityPack	古参。XPath で辿れる。壊れた HTML に寛容

var doc = await new HtmlParser().ParseDocumentAsync(html);
var urls = doc.QuerySelectorAll("a[href]").Select(a => a.GetAttribute("href"));

「使い捨てのスクリプトで、入力の形が完全に分かっている」場合を除き、
HTML には正規表現を使わない。

※ 最小マッチを使用している。また、プロトコル、ポート番号などの部分キャプチャを行なっている。

補足: URL の分解も、System.Uri を使うのが確実である。

if (Uri.TryCreate(s, UriKind.Absolute, out var uri))
{
    var proto = uri.Scheme;   // "https"
    var port  = uri.Port;     // 443（省略時も既定値が入る）
    var host  = uri.Host;
}

クエリ文字列の解析には Microsoft.AspNetCore.WebUtilities.QueryHelpers や
System.Web.HttpUtility.ParseQueryString を使う。

正規表現の処理に利用する API と、そのオプションについて説明する。

正規表現にて中心的役割を担うクラスにRegex クラスとMatch クラスがある。

Regex クラスは、正規表現パターンを格納し、パターン マッチングを実行するメソッドを備えたクラスである。
このオブジェクトからキャプチャ文字列の値を取り出して、引き続き、「手続き型の処理」を実装できる。

• 以下に、Regex クラスの主要なプロパティ / メソッドを一覧する。

移行メモ（正誤）: 2-1 の「入力チェックでは ^ と $ を付与」は、
$ が末尾の \n の前にも一致するため、厳密には不十分である
（前述の方言を参照）。
入力チェックでは \A と \z を使う方が確実である。

• オブジェクト階層は次のようになっている。
  • Matches メソッドで取得できる MatchCollection オブジェクト
  • Match メソッドで取得できるMatch オブジェクト

オブジェクト名                       ： 下位オブジェクトの取得方法  ： キャプチャ文字列の詳細データ
MatchCollectionオブジェクト          ： インデクサ（番号）
┗ Matchオブジェクト                 ： Groupsプロパティ
　┗ GroupsCollectionオブジェクト    ： インデクサ（番号、名称）
　　┗ Groupsオブジェクト            ： Capturesプロパティ
　　┗ CaptureCollectionオブジェクト ： インデクサ（番号）
　　　┗ Captureオブジェクト         ： 各種プロパティ
　　　　┣ Value（string）                                          ： キャプチャ文字列の値
　　　　┣ Length（int）                                            ： キャプチャ文字列の文字列長
　　　　┗ Index（int）                                             ： 入力文字列を基にした位置（インデックス）

移行メモ（誤記）: 原文の「キャプチャ文字列の長文字列」は
文字列長の誤記と判断し修正した。

• 其々のオブジェクトの説明

• １つのグループが複数の文字列をキャプチャする例
  正規表現によっては、１つのグループが複数の文字列をキャプチャすることがある。
  このような正規表現の例を以下、説明する。

  • 正規表現の例

• 上記を実行した結果、
  以下のオブジェクトが返される。
  • Match オブジェクト（２つ）
    ・前の "123456789" にマッチ
    ・後ろの "123456789" にマッチ
  • Groups オブジェクト（４つ）
    ・全体（123456789）のキャプチャ
    ・グループ 1（123）のキャプチャ
    ・グループ 2（"\d"=4）のキャプチャ
    ・グループ 3（"\d"=5）のキャプチャ
    ・グループ 4（"\d"=6）のキャプチャ
    ・グループ 5（789）のキャプチャ

移行メモ（正誤）: 原文の記述はやや不正確なので補足する。

• 「Groups オブジェクト（４つ）」とあるが、
  列挙されているのは 6 件であり、数が合わない。
• また、正規表現 (123)(\d)+(789) のグループは 3 つであり、
  グループ 4・5 は存在しない。

実際の挙動は次の通りで、まさにこれが
本節が説明しようとしている Captures の意義である。

Groups[0] = "123456789"    （全体）
Groups[1] = "123"
Groups[2] = "6"            ← Value は「最後の」キャプチャだけ
  Groups[2].Captures = ["4", "5", "6"]   ← 3 回分すべてがここに残る
Groups[3] = "789"

要点: (\d)+ のように量指定子の付いたグループは
複数回キャプチャするが、Group.Value は最後の 1 回しか返さない。
すべてを取り出すには Group.Captures を列挙する。
（原文が「グループ 2〜4」と書いたのは、この 3 回分の
キャプチャを指す意図だったと読める。）

• MatchEvaluator デリゲートを使用して置換（変換）する例
  • また、Regex.Replace ( ) メソッドの特殊な使い方に、
    MatchEvaluator デリゲートを使用した置換（変換）方法がある。
  • これを使用すると、非手続の「置換パターン」を使用した置換（変換）ではなく、
    手続き型言語（C#、VB）を使用した置換（変換）が可能になる。

public class Test_Regex {

  // 正規表現を使用して置換（変換）するメソッド
  public string Regex_Replace(string yyyymmdd)
  {
    // 日付（yyyy/mm/dd形式）を正規表現を用いて１日増やす
    return Regex.Replace(yyyymmdd,
      @"(?<year>\d{4})/(?<month>\d{2})/(?<day>\d{2})",
      new MatchEvaluator(this.IncrementDay));
  }
  
  // MatchEvaluatorデリゲートメソッド
  private string IncrementDay(Match m)
  {
    // 日付ワーク
    DateTime dt;

    // 日付（yyyy/mm/dd形式）をDateTime型に変換
    if (DateTime.TryParse(m.Value, out dt)) {
      // DateTimeクラスを使用して１日増やし、
      // 日付（yyyy/mm/dd形式）に戻す。
      return dt.AddDays(1).ToShortDateString();
    }
    else {
      // 変換できなかった場合、何もしないで戻す。
      return m.Value;
    }
  }
}

補足（MatchEvaluator は「逃げ道」として重要）: 正規表現だけでは
表現できない変換（計算、辞書引き、条件分岐）が必要になったとき、
無理に正規表現を複雑化せず、この方式に切り替えるのが定石である。

現在はラムダ式で簡潔に書ける。

var s = Regex.Replace(input, @"\d{4}/\d{2}/\d{2}",
    m => DateTime.TryParse(m.Value, out var d)
         ? d.AddDays(1).ToString("yyyy/MM/dd")
         : m.Value);

なお上記の原文の例で使われている ToShortDateString()
はカルチャ依存（実行環境の地域設定で書式が変わる）ため、
書式を固定したいなら ToString("yyyy/MM/dd") を明示する方がよい。

Match クラスは、Regex クラスで実行されたパターン マッチングの結果を格納するクラスである。

• 以下に、Match クラスのプロパティ / メソッドを一覧する。

補足（アロケーションを避ける新 API）: Match / Group は
いずれも string を生成するため、大量処理では確保が積み上がる。

.NET 7 以降では、Span<char> ベースの API が追加されている。

API	内容
Regex.EnumerateMatches(ReadOnlySpan<char>)	文字列を作らずに位置と長さだけ列挙
Regex.Count()	一致数だけを数える（.NET 7+）
ValueMatch	Index と Length のみを持つ構造体

foreach (var m in Regex.EnumerateMatches(span, pattern))
    Process(span.Slice(m.Index, m.Length));   // 文字列生成なし

以下、Regex クラスのオプションについて説明する。
これによって一部、動作（処理結果）が変更される。

補足（現在追加されたオプション／最新化）: 上記に加えて、
現在は次の 2 つが重要である。

オプション	内容
NonBacktracking（.NET 7+）	バックトラックしないエンジンを使う。ReDoS を原理的に防ぐ
RegexOptions.Compiled	現在も有効だが、ソース生成の方が上位

NonBacktracking は入力長に対して線形時間を保証する
（オートマトン方式のエンジンを使う）。
ただし後方参照・先読み/後読みが使えないという制約がある。

// 信頼できない入力を扱うなら、これが最も安全
new Regex(pattern, RegexOptions.NonBacktracking);

補足（[GeneratedRegex]：現在の推奨形／最新化）: .NET 7 以降、
ソース ジェネレーターによる正規表現が使える。

public partial class Validator
{
    [GeneratedRegex(@"\A[a-z0-9_]+\z", RegexOptions.IgnoreCase)]
    private static partial Regex UserName();

    public bool IsValid(string s) => UserName().IsMatch(s);
}

方式	生成タイミング	起動	実行	AOT
new Regex(...)（解釈）	実行時	速い	遅い	○
RegexOptions.Compiled	実行時に IL 生成	遅い	速い	×
[GeneratedRegex]	コンパイル時に C# 生成	速い	速い	○

[GeneratedRegex] が全面的に優れている
（起動が速く、実行も速く、トリミング/Native AOT でも動き、
生成された C# コードをデバッグで追える）。
静的なパターンには、これを使うのが現在の第一候補である。

なお、動的に組み立てるパターンには使えないため、
その場合は Regex インスタンスをstatic フィールドにキャッシュする
（毎回 new する、あるいは静的メソッド Regex.IsMatch(s, pattern) を
ループ内で呼ぶのは避ける）。

補足（原文に無い節。現在は必須の知識）: 本ページ執筆時点では
話題になっていなかったが、正規表現には
**ReDoS（Regular expression Denial of Service）**という
セキュリティ上の問題がある。

原理: バックトラック型のエンジンは、
一致しない入力に対してすべての分割を試すことがあり、
入力長に対して指数関数的に時間がかかる場合がある。

// 危険なパターン（「入れ子の量指定子」）
var re = new Regex(@"^(a+)+$");
re.IsMatch(new string('a', 30) + "!");   // 数十秒〜フリーズ

a が 1 個増えるごとに試行回数が倍増する。
攻撃者が入力を送れる箇所（フォーム、URL、ヘッダー）で
このようなパターンを使うと、CPU を占有されてサービスが止まる。

危険なパターンの兆候:

形	例
入れ子の量指定子	(a+)+、(a*)*、(.*)*
重なり合う選択肢	(a|a)*、(a|ab)+
最短マッチ + 貪欲の混在	.*?.*

対策（上から順に検討する）:

対策	内容
そもそも正規表現を使わない	メール→MailAddress、URL→Uri、HTML→パーサー
RegexOptions.NonBacktracking	線形時間を保証（.NET 7+）
タイムアウトを設定する	new Regex(p, opts, TimeSpan.FromSeconds(1))
否定文字クラスを使う	.*? より [^"]*
アトミック グループ	(?>a+)+ で後戻りを禁止
入力長を制限する	検証前に長さで弾く

タイムアウトの指定は、外部入力を扱うすべての Regex で
事実上必須である。指定がないと既定は無限（InfiniteMatchTimeout）。

private static readonly Regex _re =
    new(pattern, RegexOptions.None, TimeSpan.FromMilliseconds(200));

超過すると RegexMatchTimeoutException が送出されるので、
捕捉して「不正な入力」として扱う。

なお、原文のまとめが指摘する
「妥当性の検証が困難」という論点は、
この ReDoS の存在によって一層重みを増している。
「動くこと」だけでなく「一致しない入力で暴走しないこと」も
テストの対象になる。

正規表現を使用すると、高度な、

• 入力チェック
• 全文検索
• 置換（付加、削除、書式変更）
• 文字列分割

などの処理を、高い生産性で実装することができる。

ただし、以下の点は、正規表現により解決できない。

以下のように難解なため、妥当性の検証が困難である。

• 記述（処理の実装ステップ数）は、短かくなるが、

  • 正規表現を習得する必要がある。
  • アサインする技術者には正規表現の知識が必要になる。

• 「非手続き言語」の特徴として、開発したステップ数に対するテスト ケースが多い。

  • それを検証するテスト工数の削減はできないし、
  • テストケースが網羅的であるかどうか、カバレージを指標に利用できない。

補足（この指摘は現在も有効）: 「1 行のコードだが、
カバレッジでは 1 行としてしか数えられない」という指摘は本質的である。

緩和策としては、

手段	内容
IgnorePatternWhitespace でコメントを書く	パターン自体を読めるようにする
[GeneratedRegex]	生成コードをステップ実行で追える
境界値のテストを明示的に列挙	一致する例・一致しない例の両方
regex101.com 等での可視化	マッチ過程を確認する

// x モード：パターンにコメントを入れる
[GeneratedRegex("""
    \A                 # 先頭
    (?<user>[\w.+-]+)  # ローカル部
    @
    (?<host>[\w-]+(\.[\w-]+)+)  # ドメイン
    \z                 # 末尾
    """, RegexOptions.IgnorePatternWhitespace)]
private static partial Regex Mail();

• 「手続き言語」で実装しないと表現できないケースもある。
  例えば、メール フォーマット チェックなどを例に挙げて説明すると、
  • RFC に準拠したメール アドレスだけ許可するのか？
  • 携帯メールなどに見られる RFC 非準拠のメール アドレスも許可するのか？
  • また、電子メールの配送先 IP アドレスの直接指定を許可するのか？など。

• 正規表現は、
  • 入力チェック処理や、
  • 置換（書式変更）などの

共通処理を、比較的容易に開発できる。

• しかし、利便性と汎用性を両立する API 仕様を検討することは変わらず難しい。
  このため、強度を上げるなら、汎用性を犠牲にする以外に方法が無い。

補足（結論）: 本ページ全体を通じた実務上の指針を纏める。

1. 専用の型があるものには、正規表現を使わない
   （メール → MailAddress、URL → Uri、日付 → DateTime.TryParse、
   HTML/XML/JSON → 各パーサー）
2. 静的なパターンは [GeneratedRegex]
3. 外部入力を扱うなら、タイムアウトか NonBacktracking
4. .*? より否定文字クラス [^x]*
5. キャプチャ不要なら (?:)、名前と番号を混ぜない
6. 一致しない入力のテストを書く（性能も含めて）

• .NET の正規表現
  https://learn.microsoft.com/ja-jp/dotnet/standard/base-types/regular-expressions

• 正規表現の基本 - .NET Tips (VB.NET,C#...)
  http://dobon.net/vb/dotnet/string/regex.html

• 正規表現 (System.Text.RegularExpressions)
  Programming/.NET Framework - 総武ソフトウェア推進所
  http://smdn.jp/programming/netfx/regex/

• サルにもわかる正規表現入門
  http://www.mnet.ne.jp/~nakama/

• Regular-Expressions.info
  Regex Tutorial, Examples and Reference - Regexp Patterns
  http://www.regular-expressions.info/index.html

• .NET 正規表現ソース ジェネレーター
  https://learn.microsoft.com/ja-jp/dotnet/standard/base-types/regular-expression-source-generators
• 正規表現のベスト プラクティス
  https://learn.microsoft.com/ja-jp/dotnet/standard/base-types/best-practices-regular-expressions
• バックトラッキング
  https://learn.microsoft.com/ja-jp/dotnet/standard/base-types/backtracking-in-regular-expressions

Tags: 移行, .NET開発, その他、開発の色々