文字列

【C#】Regexで実現する文字列ワイルドカード比較の基本と実装テクニック

2025-05-15更新日: 2025-05-15

ワイルドカード比較をC#で行うなら、Regex.IsMatchを使い*や?相当を正規表現の.*や.に置き換える方法が最も手軽です。

パターンをエスケープして必要箇所だけ変換すればSQLのLIKE同様の柔軟性が得られ、大小文字の扱いもRegexOptions.IgnoreCaseで統一できます。

目次から探す

Regexとワイルドカード比較の関係
Regexパターン生成の基本
- 静的パターンの記述例
- 動的入力を安全に変換する手順
大文字小文字の扱い
- RegexOptions.IgnoreCase の効果
マルチライン・ドットオールの設定
- 行単位の比較
- 改行を含む文字列のマッチング
オプション別の性能比較
非同期・リアクティブシナリオでの利用
- UI入力検証
- ストリームデータのフィルタリング
エラーハンドリングとデバッグ
- パターン構築エラーの検出
- Regex.MatchTimeoutException の対策
保守性向上のための設計ヒント
他のアプローチとの比較
セキュリティ観点の留意点
- ReDoS 脆弱性
- 外部入力の適切な検証
よくある誤解とハマりどころ
- ワイルドカード位置による意図しないマッチ
- . と \n の挙動
応用例コレクション
まとめ

Regexとワイルドカード比較の関係

C#で文字列のパターンマッチングを行う際、ワイルドカードと正規表現(Regex)はよく比較される手法です。

ここでは、ワイルドカードの基本的な使い方と、それを正規表現に置き換える方法について詳しく解説します。

ワイルドカードの基本 * と ?

ワイルドカードは、ファイル検索や簡易的な文字列マッチングでよく使われる記号です。

C#の標準ライブラリには直接ワイルドカードを使った文字列比較の機能はありませんが、ワイルドカードの考え方は理解しておくと正規表現への変換がスムーズになります。

*(アスタリスク)は「任意の文字が0回以上連続する」という意味です。例えば、abc*は「abc」の後に任意の文字が0回以上続く文字列にマッチします

例：abc、abcd、abcxyzなど。

?(クエスチョンマーク)は「任意の1文字にマッチする」という意味です。例えば、a?cは「a」と「c」の間に任意の1文字が入る文字列にマッチします

例：abc、a1c、a-cなど。

ワイルドカードは直感的で使いやすいですが、複雑なパターンを表現するには限界があります。

そこで、より柔軟なパターンマッチングを実現するために正規表現が使われます。

正規表現 .* と . へのマッピング

正規表現は、文字列のパターンを詳細に指定できる強力なツールです。

ワイルドカードの*や?は、正規表現の特定の記号に対応しています。

ワイルドカードの*は、正規表現の.*に対応します
- .は「任意の1文字」を意味します
- *は「直前の文字が0回以上繰り返される」ことを意味します

つまり、.*は「任意の文字が0回以上連続する」という意味になります。

例：ワイルドカードのabc*は正規表現のabc.*に変換できます。

ワイルドカードの?は、正規表現の.に対応します

つまり、?は「任意の1文字」として表現されます。

例：ワイルドカードのa?cは正規表現のa.cに変換できます。

このように、ワイルドカードのパターンを正規表現に変換することで、C#のRegexクラスを使って柔軟な文字列マッチングが可能になります。

エスケープが必要な文字一覧

正規表現では、特別な意味を持つ文字がいくつかあります。

これらの文字は、パターンの中でそのまま使うと正規表現の構文として解釈されてしまうため、文字通りの意味で使いたい場合はエスケープが必要です。

主なエスケープが必要な文字は以下の通りです。

文字	説明
`.`	任意の1文字
`*`	直前の文字の0回以上の繰り返し
`+`	直前の文字の1回以上の繰り返し
`?`	直前の文字の0回または1回の繰り返し
`^`	文字列の先頭
`$`	文字列の末尾
`\`	エスケープ文字
`\|`	OR演算子
`(`	グループ開始
`)`	グループ終了
`[`	文字クラス開始
`]`	文字クラス終了
`{`	繰り返し回数指定開始
`}`	繰り返し回数指定終了

例えば、ワイルドカードのパターンに.や*が含まれている場合、それを正規表現に変換する際は、これらの文字をエスケープしないと意図しないマッチング結果になることがあります。

C#では、Regex.Escapeメソッドを使うと、文字列中の正規表現で特別な意味を持つ文字を自動的にエスケープできます。

これを活用して、ユーザーからの入力や動的に生成されるパターンを安全に正規表現に変換することができます。

以下は、Regex.Escapeの簡単な例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string input = "file?.txt";
        string escaped = Regex.Escape(input);
        Console.WriteLine(escaped); // 出力: file\?\.txt
    }
}

file\?\.txt

このように、?や.がエスケープされているため、正規表現の特殊文字としてではなく、文字通りの?や.として扱われます。

ワイルドカードを正規表現に変換する際は、まず文字列全体をRegex.Escapeでエスケープし、その後にワイルドカードの*や?を正規表現の.*や.に置き換える方法が一般的です。

これにより、意図しない正規表現の解釈を防ぎつつ、ワイルドカードの機能を正しく実装できます。

Regexパターン生成の基本

静的パターンの記述例

正規表現パターンを静的に記述する場合は、文字列リテラルとして直接パターンを指定します。

C#では@を付けた逐語的文字列リテラルを使うことで、バックスラッシュのエスケープを簡単にできます。

例えば、「abc」で始まり「def」で終わる文字列にマッチさせるパターンは以下のように書けます。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"^abc.*def$"; // 先頭がabc、任意の文字列、末尾がdef
        string input1 = "abcdef";
        string input2 = "abcXYZdef";
        string input3 = "abdef";
        Console.WriteLine(Regex.IsMatch(input1, pattern)); // True
        Console.WriteLine(Regex.IsMatch(input2, pattern)); // True
        Console.WriteLine(Regex.IsMatch(input3, pattern)); // False
    }
}

True
True
False

この例では、^が文字列の先頭、$が末尾を示し、.*が任意の文字列(0文字以上)を表しています。

静的パターンは固定のルールに基づくマッチングに適しています。

動的入力を安全に変換する手順

ユーザー入力や外部データをもとに正規表現パターンを生成する場合は、特殊文字のエスケープを適切に行わないと、意図しないマッチングや例外が発生する恐れがあります。

安全にパターンを作るための手順を示します。

Regex.Escape の活用

Regex.Escapeは、文字列中の正規表現の特殊文字をすべてエスケープしてくれるメソッドです。

これを使うことで、ユーザーが入力した文字列をそのまま文字列リテラルとして扱えます。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string userInput = "file?.txt"; // ユーザー入力(?は特殊文字)
        string escapedPattern = Regex.Escape(userInput);
        Console.WriteLine(escapedPattern); // file\?\.txt
        // 完全一致を確認するために^と$を付ける
        string pattern = "^" + escapedPattern + "$";
        Console.WriteLine(Regex.IsMatch("file?.txt", pattern)); // True
        Console.WriteLine(Regex.IsMatch("file1.txt", pattern)); // False
    }
}

file\?\.txt
True
False

このように、Regex.Escapeを使うと、特殊文字を文字通りに扱うパターンが簡単に作れます。

ただし、ワイルドカードの*や?を正規表現の.*や.に変換したい場合は、単純にエスケープするだけでは不十分です。

ワイルドカードとの混在を処理するカスタム関数

ワイルドカードの*や?を含む文字列を正規表現パターンに変換するには、まずRegex.Escapeで特殊文字をエスケープし、その後にワイルドカード記号だけを正規表現の対応するパターンに置き換える処理が必要です。

以下は、ワイルドカードを含む文字列を正規表現パターンに変換するカスタム関数の例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    // ワイルドカードを正規表現に変換するメソッド
    static string WildcardToRegex(string pattern)
    {
        // まず特殊文字をエスケープ
        string escaped = Regex.Escape(pattern);
        // エスケープされたワイルドカードを正規表現に置換
        // \* → .*
        // \? → .
        escaped = escaped.Replace(@"\*", ".*").Replace(@"\?", ".");
        // 文字列全体のマッチを保証するために^と$を付ける
        return "^" + escaped + "$";
    }
    static void Main()
    {
        string wildcardPattern = "file*.?xt"; // ワイルドカードパターン
        string regexPattern = WildcardToRegex(wildcardPattern);
        Console.WriteLine("正規表現パターン: " + regexPattern);
        string[] testInputs = { "file.txt", "file1.txt", "file123.xt", "file.xt", "filetxt" };
        foreach (var input in testInputs)
        {
            bool isMatch = Regex.IsMatch(input, regexPattern);
            Console.WriteLine($"{input} → {isMatch}");
        }
    }
}

正規表現パターン: ^file.*\..xt$
file.txt → True
file1.txt → True
file123.xt → True
file.xt → True
filetxt → False

この関数のポイントは以下の通りです。

Regex.Escapeで一旦すべての特殊文字をエスケープし、正規表現の文法エラーを防止しています
その後、ワイルドカードの*と?だけを正規表現の.*と.に置き換えています
最後に^と$を付けて、文字列全体がパターンにマッチするようにしています

この方法を使うと、ユーザーが入力したワイルドカードパターンを安全かつ正確に正規表現に変換でき、C#のRegexクラスでのマッチングに活用できます。

大文字小文字の扱い

RegexOptions.IgnoreCase の効果

C#の正規表現で大文字小文字を区別せずにマッチングを行いたい場合は、RegexOptions.IgnoreCaseオプションを指定します。

このオプションを使うと、パターンと入力文字列の大文字・小文字の違いを無視して比較が行われます。

以下は、IgnoreCaseを使った例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"^hello.*world$";
        string input1 = "Hello there, World";
        string input2 = "HELLO WORLD";
        string input3 = "hello world";
        string input4 = "Hi world";
        // 大文字小文字を区別しないマッチング
        bool match1 = Regex.IsMatch(input1, pattern, RegexOptions.IgnoreCase);
        bool match2 = Regex.IsMatch(input2, pattern, RegexOptions.IgnoreCase);
        bool match3 = Regex.IsMatch(input3, pattern, RegexOptions.IgnoreCase);
        bool match4 = Regex.IsMatch(input4, pattern, RegexOptions.IgnoreCase);
        Console.WriteLine(match1); // True
        Console.WriteLine(match2); // True
        Console.WriteLine(match3); // True
        Console.WriteLine(match4); // False
    }
}

True
True
True
False

この例では、patternは「hello」で始まり「world」で終わる文字列を表しています。

RegexOptions.IgnoreCaseを指定することで、HelloやHELLOのように大文字小文字が異なっていてもマッチします。

IgnoreCaseを使わない場合は、大文字小文字が完全に一致しなければマッチしません。

例えば、Regex.IsMatch("Hello World", pattern)はfalseになります。

マルチライン・ドットオールの設定

行単位の比較

正規表現で複数行のテキストを扱う場合、行単位でのマッチングや改行文字の扱いが重要になります。

C#のRegexクラスでは、複数行の文字列に対してどのようにパターンを適用するかを制御するために、RegexOptions.MultilineとRegexOptions.Singlelineというオプションが用意されています。

行単位の比較とは、複数行のテキストの中で「各行の先頭や末尾」を意識してマッチングを行うことです。

例えば、テキストの各行が特定のパターンで始まるかどうかを調べたい場合に使います。

改行を含む文字列のマッチング

改行文字は通常、正規表現の.(ドット)にマッチしません。

.は改行以外の任意の1文字にマッチするため、複数行のテキスト全体を1つの文字列として扱う場合、改行を含む部分をマッチさせるには特別な設定が必要です。

RegexOptions.Singleline

RegexOptions.Singlelineは、正規表現の.(ドット)が改行文字にもマッチするように動作を変更します。

これにより、複数行のテキスト全体を1つの文字列として扱い、改行を含む任意の文字列にマッチさせることができます。

以下はSinglelineオプションの例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"^Hello.*World$";
        string input = "Hello\nThis is a test.\nWorld";
        // Singlelineを指定しない場合
        bool matchWithoutSingleline = Regex.IsMatch(input, pattern);
        // Singlelineを指定した場合
        bool matchWithSingleline = Regex.IsMatch(input, pattern, RegexOptions.Singleline);
        Console.WriteLine($"Singlelineなし: {matchWithoutSingleline}"); // False
        Console.WriteLine($"Singlelineあり: {matchWithSingleline}");   // True
    }
}

Singlelineなし: False
Singlelineあり: True

この例では、patternは「Hello」で始まり「World」で終わる文字列を表しています。

inputは複数行の文字列で、改行を含んでいます。

Singlelineオプションを指定すると、.が改行にもマッチするため、複数行にまたがるパターンにマッチします。

RegexOptions.Multiline

RegexOptions.Multilineは、^と$の意味を変更します。

通常、^は文字列全体の先頭、$は文字列全体の末尾にマッチしますが、Multilineを指定すると、各行の先頭と末尾にもマッチするようになります。

これにより、複数行のテキストの中で各行ごとにパターンを適用したい場合に便利です。

以下はMultilineオプションの例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"^Hello";
        string input = "Hello World\nHello Regex\nHi there";
        // Multilineを指定しない場合
        MatchCollection matchesWithoutMultiline = Regex.Matches(input, pattern);
        // Multilineを指定した場合
        MatchCollection matchesWithMultiline = Regex.Matches(input, pattern, RegexOptions.Multiline);
        Console.WriteLine($"Multilineなしのマッチ数: {matchesWithoutMultiline.Count}"); // 1
        Console.WriteLine($"Multilineありのマッチ数: {matchesWithMultiline.Count}");   // 2
    }
}

Multilineなしのマッチ数: 1
Multilineありのマッチ数: 2

この例では、patternは行の先頭にHelloがあるかどうかを調べています。

Multilineを指定しない場合は文字列全体の先頭だけが対象となるため、1回しかマッチしません。

Multilineを指定すると、各行の先頭が対象となり、2回マッチしています。

まとめると、

RegexOptions.Singlelineは.が改行文字にもマッチするようにするオプションで、複数行を1つの文字列として扱います
RegexOptions.Multilineは^と$の意味を「文字列全体」から「各行の先頭・末尾」に変えるオプションで、行単位のマッチングに使います

これらのオプションを適切に使い分けることで、複数行テキストのパターンマッチングを柔軟に制御できます。

オプション別の性能比較

コンパイル済み正規表現のメリット

C#のRegexクラスでは、正規表現パターンを事前にコンパイルして高速化することができます。

これを実現するのがRegexOptions.Compiledオプションです。

通常、Regexはパターンを解析して内部表現に変換し、マッチングを行いますが、Compiledを指定すると、パターンがILコードに変換され、実行時に高速に動作します。

コンパイル済み正規表現の主なメリットは以下の通りです。

高速なマッチング

一度コンパイルされた正規表現は、繰り返し使う場合に特に高速です。

大量の文字列に対して同じパターンを何度も適用するシナリオで効果を発揮します。

パフォーマンスの安定化

実行時にパターン解析を行わないため、初回の遅延がなくなり、パフォーマンスが安定します。

ただし、コンパイルには初期コストがかかるため、単発のマッチングや短時間で終わる処理では逆に遅くなることがあります。

また、Compiledオプションはメモリ使用量が増加する傾向があるため、リソース制約のある環境では注意が必要です。

キャッシュとメモリ使用量

Regexクラスは内部でパターンのキャッシュを持っています。

これにより、同じパターンを繰り返し使う場合は、パターン解析のコストを削減できます。

デフォルトでは、最大15個のパターンがキャッシュされます。

キャッシュの特徴は以下の通りです。

項目	内容
キャッシュサイズ	最大15個のパターンを保持
キャッシュの対象	同じパターン文字列と同じオプションの組み合わせ
メモリ使用量	キャッシュ数に比例して増加
キャッシュの利点	パターン解析の繰り返しを防ぎ高速化

大量の異なるパターンを使う場合はキャッシュが効果的に働かず、パターン解析が頻繁に発生してパフォーマンスが低下することがあります。

その場合は、Regexインスタンスを使い回すか、Compiledオプションを検討してください。

ベンチマークサンプル

以下は、RegexOptions.Compiledの有無でマッチング速度を比較する簡単なベンチマーク例です。

大量の文字列に対して同じパターンを繰り返しマッチングするシナリオを想定しています。

using System;
using System.Diagnostics;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"^\d{3}-\d{4}$"; // 郵便番号形式(例: 123-4567)
        string[] testInputs = new string[1000000];
        for (int i = 0; i < testInputs.Length; i++)
        {
            testInputs[i] = (i % 2 == 0) ? "123-4567" : "abc-defg";
        }
        // 非コンパイル済みRegex
        var regexNormal = new Regex(pattern);
        var swNormal = Stopwatch.StartNew();
        int matchCountNormal = 0;
        foreach (var input in testInputs)
        {
            if (regexNormal.IsMatch(input))
                matchCountNormal++;
        }
        swNormal.Stop();
        // コンパイル済みRegex
        var regexCompiled = new Regex(pattern, RegexOptions.Compiled);
        var swCompiled = Stopwatch.StartNew();
        int matchCountCompiled = 0;
        foreach (var input in testInputs)
        {
            if (regexCompiled.IsMatch(input))
                matchCountCompiled++;
        }
        swCompiled.Stop();
        Console.WriteLine($"非コンパイル済みマッチ数: {matchCountNormal}, 時間: {swNormal.ElapsedMilliseconds} ms");
        Console.WriteLine($"コンパイル済みマッチ数: {matchCountCompiled}, 時間: {swCompiled.ElapsedMilliseconds} ms");
    }
}

非コンパイル済みマッチ数: 500000, 時間: 47 ms
コンパイル済みマッチ数: 500000, 時間: 24 ms

このベンチマークでは、同じパターンを10万回マッチングしています。

RegexOptions.Compiledを使うと、マッチング処理が約半分の時間で完了していることがわかります。

ただし、初回のコンパイルコストは含まれていないため、単発のマッチングでは効果が薄いことに注意してください。

パターンを頻繁に使い回す場合にCompiledオプションを活用すると良いでしょう。

このように、正規表現のオプションによってパフォーマンスやメモリ使用量に違いが出るため、用途に応じて適切な設定を選ぶことが重要です。

非同期・リアクティブシナリオでの利用

UI入力検証

ユーザーインターフェース(UI)での入力検証は、リアルタイムにユーザーの入力内容をチェックし、適切なフィードバックを返すことが求められます。

C#のRegexを使うことで、入力文字列が特定のパターンに合致しているかを効率的に判定できますが、UIの応答性を保つために非同期処理やリアクティブプログラミングと組み合わせることが重要です。

例えば、WPFやWinFormsのテキストボックスに入力された内容をリアルタイムで検証する場合、入力イベントごとに正規表現マッチングを行うと処理が重くなり、UIが固まることがあります。

これを防ぐために、非同期で検証処理を行い、さらに入力の連続イベントを間引く(デバウンス)テクニックを使うことが多いです。

以下は、System.Reactive(Rx.NET)を使ってテキスト入力を監視し、500ミリ秒の間隔で正規表現による検証を非同期に行う例です。

System.Reactiveのインストール

System.Reactiveは、Nugetからインストールする必要があります。

「System.Reactive」と検索してインストールするようにしてください。

dotnet add package System.Reactive

using System;
using System.Reactive.Linq;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
class Program
{
    static void Main()
    {
        // 入力のシミュレーション用のObservable(実際はUIのテキスト変更イベントなど)
        var inputStream = Observable.Interval(TimeSpan.FromMilliseconds(100))
            .Take(10)
            .Select(i => i % 2 == 0 ? "user@example.com" : "invalid-email");
        string emailPattern = @"^[\w\.-]+@[\w\.-]+\.\w+$";
        inputStream
            .Throttle(TimeSpan.FromMilliseconds(500)) // 500ms間隔で最新の入力を取得
            .Select(input => Observable.FromAsync(() => ValidateInputAsync(input, emailPattern)))
            .Switch()
            .Subscribe(result =>
            {
                Console.WriteLine($"入力: {result.Input}, 検証結果: {result.IsValid}");
            });
        Console.ReadLine();
    }
    static Task<(string Input, bool IsValid)> ValidateInputAsync(string input, string pattern)
    {
        return Task.Run(() =>
        {
            bool isValid = Regex.IsMatch(input, pattern, RegexOptions.IgnoreCase);
            return (input, isValid);
        });
    }
}

入力: user@example.com, 検証結果: True
入力: invalid-email, 検証結果: False
入力: user@example.com, 検証結果: True
入力: invalid-email, 検証結果: False
入力: user@example.com, 検証結果: True

この例では、入力が頻繁に発生してもThrottleで間引き、最新の入力だけを非同期に検証しています。

Switchは古い検証結果を破棄し、最新の結果だけを処理するため、UIの負荷を軽減できます。

ストリームデータのフィルタリング

リアクティブプログラミングや非同期処理は、ログ解析やネットワークデータの監視など、継続的に流れてくるストリームデータのフィルタリングにも適しています。

Regexを使って特定のパターンにマッチするデータだけを抽出し、リアルタイムで処理を行うことが可能です。

以下は、Rx.NETを使って文字列のストリームから特定のパターンにマッチするものだけをフィルタリングする例です。

using System;
using System.Reactive.Linq;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        // ログメッセージのストリームをシミュレート
        var logStream = Observable.Interval(TimeSpan.FromMilliseconds(200))
            .Take(10)
            .Select(i => i % 3 == 0 ? $"ERROR: Issue detected at {DateTime.Now}" : $"INFO: Normal operation at {DateTime.Now}");
        string errorPattern = @"^ERROR:";
        logStream
            .Where(log => Regex.IsMatch(log, errorPattern))
            .Subscribe(log =>
            {
                Console.WriteLine($"エラーログ検出: {log}");
            });
        Console.ReadLine();
    }
}

エラーログ検出: ERROR: Issue detected at 2024/06/01 12:00:00
エラーログ検出: ERROR: Issue detected at 2024/06/01 12:00:00
エラーログ検出: ERROR: Issue detected at 2024/06/01 12:00:00

この例では、ログメッセージのストリームから「ERROR:」で始まるメッセージだけを抽出し、リアルタイムにコンソールに表示しています。

Regex.IsMatchを使うことで、単純な文字列比較よりも柔軟なパターンマッチングが可能です。

非同期やリアクティブな環境でRegexを活用する際は、マッチング処理が重くなりすぎないように、適切な間引きや非同期化を行うことがポイントです。

これにより、UIの応答性やストリーム処理のスループットを維持しつつ、正確なパターン検出が実現できます。

エラーハンドリングとデバッグ

パターン構築エラーの検出

正規表現パターンを動的に生成したり、外部から入力されたパターンを使用する場合、パターンの構文エラーが発生することがあります。

C#のRegexクラスは、無効な正規表現パターンをコンパイルしようとするとArgumentExceptionをスローします。

この例外を適切にキャッチしてエラーを検出し、ユーザーにフィードバックを返すことが重要です。

以下は、パターン構築時のエラーを検出する例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string invalidPattern = @"[A-Z"; // 角括弧の閉じ忘れで無効なパターン
        try
        {
            var regex = new Regex(invalidPattern);
            Console.WriteLine("パターンは有効です。");
        }
        catch (ArgumentException ex)
        {
            Console.WriteLine("正規表現パターンの構文エラーを検出しました。");
            Console.WriteLine($"エラーメッセージ: {ex.Message}");
        }
    }
}

正規表現パターンの構文エラーを検出しました。
エラーメッセージ: parsing "[A-Z" - Unterminated [] set.

この例では、角括弧の閉じ忘れによる構文エラーがArgumentExceptionとして捕捉され、エラーメッセージが表示されています。

パターンをユーザー入力などから受け取る場合は、必ずこの例外処理を行い、無効なパターンによるアプリケーションのクラッシュを防ぎましょう。

Regex.MatchTimeoutException の対策

正規表現のマッチング処理は複雑なパターンや長い入力文字列に対しては時間がかかることがあります。

特に、バックトラッキングが多発するパターンでは、処理が非常に遅くなり、最悪の場合は無限ループのように動作することもあります。

これを防ぐために、C#のRegexクラスはマッチング処理にタイムアウトを設定でき、タイムアウトを超えるとRegexMatchTimeoutExceptionがスローされます。

タイムアウトを設定するには、RegexのコンストラクタでTimeSpanを指定します。

以下はタイムアウトを設定した例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = @"(a+)+$"; // 悪名高いバックトラッキングを引き起こすパターン
        string input = new string('a', 10000) + "b"; // 長い文字列
        try
        {
            var regex = new Regex(pattern, RegexOptions.None, TimeSpan.FromMilliseconds(500));
            bool isMatch = regex.IsMatch(input);
            Console.WriteLine($"マッチ結果: {isMatch}");
        }
        catch (RegexMatchTimeoutException ex)
        {
            Console.WriteLine("正規表現のマッチングがタイムアウトしました。");
            Console.WriteLine($"タイムアウト時間: {ex.MatchTimeout}");
        }
    }
}

正規表現のマッチングがタイムアウトしました。
タイムアウト時間: 00:00:00.5000000

この例では、バックトラッキングが多発するパターンに対して500ミリ秒のタイムアウトを設定しています。

処理がタイムアウトするとRegexMatchTimeoutExceptionが発生し、例外処理で適切に対応できます。

タイムアウト対策のポイントは以下の通りです。

タイムアウトを必ず設定する

ユーザー入力や外部データを使う場合は、無限ループや長時間処理を防ぐために必須です。

例外処理でタイムアウトを捕捉する

タイムアウト時にユーザーにエラーメッセージを表示したり、処理を中断するなどの対応を行います。

パターンの見直し

バックトラッキングを減らすために、正規表現パターンを最適化することも重要です。

例えば、量指定子の使い方を工夫したり、否定先読みを活用するなどの方法があります。

RegexOptions.Compiledとの併用

コンパイル済み正規表現でもタイムアウトは有効です。

パフォーマンス向上と安全性の両立が可能です。

これらの対策を講じることで、正規表現の安全かつ安定した運用が可能になります。

保守性向上のための設計ヒント

パターンを定数・設定ファイルに分離

正規表現パターンをコード内に直接埋め込むと、パターンの変更や管理が難しくなり、保守性が低下します。

パターンを定数としてまとめたり、外部の設定ファイルに分離することで、変更時の影響範囲を限定し、メンテナンスしやすくなります。

定数として管理する例

using System;
using System.Text.RegularExpressions;
class RegexPatterns
{
    public const string EmailPattern = @"^[\w\.-]+@[\w\.-]+\.\w+$";
    public const string PhoneNumberPattern = @"^\d{3}-\d{4}$";
}
class Program
{
    static void Main()
    {
        string email = "user@example.com";
        bool isEmailValid = Regex.IsMatch(email, RegexPatterns.EmailPattern);
        Console.WriteLine($"メールアドレスの検証結果: {isEmailValid}");
    }
}

メールアドレスの検証結果: True

このようにパターンを定数にまとめると、複数箇所で使う場合も一元管理でき、修正が容易です。

設定ファイルに分離する例

JSONやXMLなどの設定ファイルにパターンを記述し、アプリケーション起動時に読み込む方法もあります。

これにより、コードを再コンパイルせずにパターンを変更可能です。

{
  "Patterns": {
    "Email": "^[\\w\\.-]+@[\\w\\.-]+\\.\\w+$",
    "PhoneNumber": "^\\d{3}-\\d{4}$"
  }
}

C#で読み込む例(簡略化)：

using System;
using System.IO;
using System.Text.Json;
using System.Text.RegularExpressions;
class Config
{
    public Patterns Patterns { get; set; }
}
class Patterns
{
    public string Email { get; set; }
    public string PhoneNumber { get; set; }
}
class Program
{
    static void Main()
    {
        string json = File.ReadAllText("config.json");
        var config = JsonSerializer.Deserialize<Config>(json);
        string email = "user@example.com";
        bool isEmailValid = Regex.IsMatch(email, config.Patterns.Email);
        Console.WriteLine($"メールアドレスの検証結果: {isEmailValid}");
    }
}

メールアドレスの検証結果: True

この方法は、運用環境でのパターン変更や多言語対応にも役立ちます。

単体責任のクラス設計

正規表現を使った処理を単一の責任に絞ったクラスに分割すると、テストや保守がしやすくなります。

例えば、パターンの管理、マッチング処理、検証結果の解釈をそれぞれ別のクラスやメソッドに分ける設計が望ましいです。

using System;
using System.Text.RegularExpressions;
class EmailValidator
{
    private readonly Regex _regex;
    public EmailValidator()
    {
        _regex = new Regex(@"^[\w\.-]+@[\w\.-]+\.\w+$", RegexOptions.IgnoreCase);
    }
    public bool IsValid(string email)
    {
        if (string.IsNullOrEmpty(email)) return false;
        return _regex.IsMatch(email);
    }
}
class Program
{
    static void Main()
    {
        var validator = new EmailValidator();
        Console.WriteLine(validator.IsValid("user@example.com")); // True
        Console.WriteLine(validator.IsValid("invalid-email"));    // False
    }
}

True
False

このように、検証ロジックを専用クラスにまとめることで、他の機能と分離され、単体テストや将来的な拡張が容易になります。

拡張メソッドでの再利用

正規表現を使った共通処理を拡張メソッドとして実装すると、コードの可読性と再利用性が向上します。

拡張メソッドは既存の型に対してメソッドを追加できるため、文字列の検証などに自然な形で利用できます。

using System;
using System.Text.RegularExpressions;
static class StringExtensions
{
    private static readonly Regex EmailRegex = new Regex(@"^[\w\.-]+@[\w\.-]+\.\w+$", RegexOptions.IgnoreCase);
    public static bool IsValidEmail(this string input)
    {
        if (string.IsNullOrEmpty(input)) return false;
        return EmailRegex.IsMatch(input);
    }
}
class Program
{
    static void Main()
    {
        string email = "user@example.com";
        Console.WriteLine(email.IsValidEmail()); // True
        string invalidEmail = "invalid-email";
        Console.WriteLine(invalidEmail.IsValidEmail()); // False
    }
}

True
False

拡張メソッドにすることで、string型のインスタンスメソッドのように使え、コードがシンプルで直感的になります。

複数のパターン検証を拡張メソッドとしてまとめると、プロジェクト全体での一貫性も保てます。

これらの設計ヒントを活用することで、正規表現を使ったコードの保守性が大幅に向上し、将来的な変更や拡張にも柔軟に対応できるようになります。

他のアプローチとの比較

LikeOperator の限界

C#でワイルドカードを使った文字列比較を行う際、Microsoft.VisualBasic.CompilerServices.LikeOperatorを利用する方法があります。

これはVisual BasicのLike演算子の機能をC#から呼び出せるもので、*や?などのワイルドカードをサポートしています。

しかし、LikeOperatorにはいくつかの制約や限界があります。

依存性の問題

LikeOperatorはMicrosoft.VisualBasic名前空間に属しており、C#プロジェクトで使うにはMicrosoft.VisualBasicアセンブリへの参照が必要です。

これにより、純粋なC#プロジェクトでの依存性が増えます。

機能の制限

正規表現に比べてパターン表現が限定的で、複雑なパターンや高度なマッチングはできません。

例えば、文字クラスや繰り返し回数の指定、先読みなどの正規表現特有の機能は使えません。

パフォーマンス面の課題

内部実装が最適化されていない場合があり、大量のデータや頻繁なマッチング処理ではパフォーマンスが劣ることがあります。

文化依存の挙動

大文字小文字の扱いやカルチャ依存の挙動が正規表現と異なるため、意図しないマッチング結果になることがあります。

これらの理由から、C#で柔軟かつ高機能な文字列マッチングを行う場合は、Regexを使うことが一般的です。

Linqによる手作業フィルタとの違い

Linqを使って文字列のフィルタリングを行う場合、単純な文字列メソッド(StartsWith、EndsWith、Containsなど)を組み合わせて条件を作ることが多いです。

これにより、正規表現を使わずに簡単なパターンマッチングが可能です。

using System;
using System.Linq;
class Program
{
    static void Main()
    {
        string[] items = { "apple", "banana", "apricot", "blueberry" };
        // "ap"で始まる文字列を抽出
        var filtered = items.Where(s => s.StartsWith("ap"));
        foreach (var item in filtered)
        {
            Console.WriteLine(item);
        }
    }
}

apple
apricot

しかし、Linqと文字列メソッドによるフィルタリングは以下のような制約があります。

パターンの柔軟性が低い

複雑なパターンやワイルドカード、正規表現のような高度なマッチングはできません。

複数条件の組み合わせが煩雑

複雑な条件を組み合わせるとコードが冗長になり、可読性が低下します。

大文字小文字の扱いに注意が必要

文字列メソッドはデフォルトで大文字小文字を区別するため、無視したい場合は別途処理が必要です。

一方、Regexを使うと1つのパターンで複雑な条件を表現でき、コードも簡潔になります。

大量のデータや複雑なパターンを扱う場合はRegexの方が適しています。

サードパーティライブラリ選定のポイント

C#の標準Regexは強力ですが、用途やパフォーマンス要件によってはサードパーティ製の正規表現ライブラリやパターンマッチングライブラリを検討することもあります。

選定時のポイントは以下の通りです。

ポイント	内容
パフォーマンス	大量データやリアルタイム処理で高速なマッチングが必要か。JITコンパイルやネイティブコード対応など。
機能の豊富さ	標準`Regex`にない拡張機能(例：名前付きキャプチャの強化、Unicodeサポート、複雑なパターン最適化)。
使いやすさ・API設計	直感的なAPIや.NET標準との親和性、ドキュメントの充実度。
メンテナンス性	活発な開発・サポート状況、バグ修正やセキュリティ対応の頻度。
依存関係・サイズ	プロジェクトへの影響、追加の依存関係やバイナリサイズの増加。
ライセンス	商用利用や配布に関する制限の有無。

代表的なサードパーティライブラリには以下があります。

PCRE.NET

Perl互換正規表現を.NETで利用可能にしたライブラリ。

標準Regexよりも豊富な機能を持ち、高速な処理が可能です。

RE2.NET

GoogleのRE2正規表現エンジンの.NETラッパー。

バックトラッキングを排除し、常に線形時間でマッチングできるため、ReDoS攻撃に強い。

DotNetRegex

拡張機能やパフォーマンス改善を目的としたライブラリ。

標準Regexとの互換性を保ちつつ機能強化。

選定時は、プロジェクトの要件や環境に合わせて、標準Regexで十分か、サードパーティの導入が必要かを検討してください。

特にセキュリティ面やパフォーマンス面での要件が厳しい場合は、RE2.NETのような安全性重視のエンジンを選ぶのも有効です。

セキュリティ観点の留意点

ReDoS 脆弱性

ReDoS(Regular Expression Denial of Service)は、正規表現の特定のパターンが原因で、悪意のある入力に対して処理時間が極端に長くなり、サービス拒否(DoS)状態を引き起こす脆弱性です。

C#のRegexも例外ではなく、複雑なパターンやバックトラッキングが多発するパターンを使うとReDoSのリスクがあります。

ReDoSは、特に以下のようなパターンで発生しやすいです。

ネストした量指定子

例: (a+)+ や (.*)+ のように、繰り返しの中に繰り返しがあるパターン。

曖昧なマッチング

複数のパスでマッチングを試みるため、入力が長くなると指数関数的に処理時間が増加。

悪意のあるユーザーが長い文字列を送信すると、サーバーのCPUリソースを大量に消費し、他の処理が遅延または停止する恐れがあります。

対策方法

タイムアウトの設定

RegexのコンストラクタでTimeSpanによるマッチングタイムアウトを設定し、一定時間を超えたら例外を発生させます。

これにより無限ループや過剰な処理を防止できます。

パターンの見直し

バックトラッキングを減らすために、正規表現パターンを最適化します。

例えば、量指定子の使い方を工夫したり、否定先読みを活用します。

安全な正規表現エンジンの利用

RE2.NETのようにバックトラッキングを排除し、常に線形時間でマッチングするエンジンを使います。

入力長の制限

入力文字列の長さを制限し、極端に長い文字列を受け付けない。

ホワイトリスト方式の検証

受け入れる文字やパターンを限定し、予期しない入力を排除します。

外部入力の適切な検証

外部から受け取る文字列を正規表現で処理する際は、入力の検証とサニタイズが重要です。

適切に検証しないと、ReDoSだけでなく、予期しない動作やセキュリティリスクを招く可能性があります。

ポイント

入力の長さチェック

受け入れる最大文字数を決めて超過した入力は拒否します。

許可文字の制限

文字種を限定し、制御文字や特殊文字の混入を防ぐ。

正規表現パターンの安全性確認

外部からパターンを受け取る場合は、構文チェックや危険なパターンの検出を行います。

例外処理の実装

無効なパターンやタイムアウト時の例外を適切にキャッチし、システムの安定性を保ちます。

ログと監視

不審な入力やタイムアウト発生時のログを記録し、攻撃の兆候を早期に検知します。

これらの対策を組み合わせることで、正規表現を使った文字列処理のセキュリティリスクを低減し、安全なアプリケーション運用が可能になります。

よくある誤解とハマりどころ

ワイルドカード位置による意図しないマッチ

ワイルドカードを使った文字列比較でよくある誤解の一つに、ワイルドカードの位置によって意図しないマッチが発生するケースがあります。

特に*(アスタリスク)や?(クエスチョンマーク)をパターンの先頭や末尾、あるいは中間に配置した場合、マッチング結果が予想と異なることがあります。

例えば、ワイルドカードパターン*testは「任意の文字列の後に’test’が続く」という意味ですが、正規表現に変換すると.*testとなり、文字列のどこかにtestが含まれていればマッチします。

これにより、mytestやlatest、contestなどもマッチ対象となり、意図しない結果になることがあります。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string wildcardPattern = "*test";
        string regexPattern = "^" + Regex.Escape(wildcardPattern).Replace(@"\*", ".*").Replace(@"\?", ".") + "$";
        string[] inputs = { "mytest", "latest", "contest", "testing" };
        foreach (var input in inputs)
        {
            bool isMatch = Regex.IsMatch(input, regexPattern);
            Console.WriteLine($"{input} → {isMatch}");
        }
    }
}

mytest → True
latest → True
contest → True
testing → False

この例では、*testが.*testに変換されているため、testで終わる文字列すべてにマッチしています。

もし「文字列の末尾がtestである」ことを厳密にチェックしたい場合は、パターンの前後に^や$を適切に付ける必要があります。

また、ワイルドカードの位置によっては、*が文字列の途中にある場合に過剰にマッチしてしまうこともあります。

例えば、te*stはteの後に任意の文字列が続き、最後にstがある文字列にマッチしますが、testやte123stだけでなく、teXYZstABCのような文字列もマッチする可能性があります。

このように、ワイルドカードの位置とパターンの意味を正確に理解しないと、意図しないマッチング結果を招くため注意が必要です。

. と \n の挙動

正規表現における.(ドット)は「任意の1文字」にマッチしますが、デフォルトでは改行文字\nにはマッチしません。

これが原因で、複数行の文字列を扱う際に思わぬ挙動になることがあります。

例えば、以下のコードでは、.が改行を跨いだマッチングをしないため、期待したマッチが得られません。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string pattern = "Hello.*World";
        string input = "Hello\nWorld";
        bool isMatch = Regex.IsMatch(input, pattern);
        Console.WriteLine(isMatch); // False
    }
}

False

この場合、.は改行文字にマッチしないため、HelloとWorldの間に改行があるとマッチしません。

改行を含む任意の文字にマッチさせたい場合は、RegexOptions.Singlelineオプションを指定します。

bool isMatchSingleline = Regex.IsMatch(input, pattern, RegexOptions.Singleline);
Console.WriteLine(isMatchSingleline); // True

True

一方、^や$の挙動も注意が必要です。

デフォルトでは、^は文字列の先頭、$は文字列の末尾にマッチしますが、RegexOptions.Multilineを指定すると、各行の先頭と末尾にもマッチするようになります。

この違いを理解せずに^や$を使うと、複数行の文字列で意図しないマッチング結果になることがあります。

まとめると、

.はデフォルトで改行文字にマッチしない
改行を含む任意の文字にマッチさせるにはRegexOptions.Singlelineを使います
^と$の意味を行単位に変えたい場合はRegexOptions.Multilineを使います

これらの挙動を正しく理解し、適切なオプションを設定することが正確なマッチングには欠かせません。

応用例コレクション

ファイルパスフィルタリング

ファイルパスのフィルタリングは、特定の拡張子やフォルダ構造にマッチするファイルを抽出したい場合に役立ちます。

ワイルドカードを使ったパターンを正規表現に変換し、柔軟にファイル名やパスをフィルタリングできます。

以下は、ワイルドカードパターン*.txtやdata\*\*.csvのようなパスパターンを正規表現に変換し、ファイル名のフィルタリングを行う例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    // ワイルドカードパターンを正規表現に変換するメソッド
    static string WildcardToRegex(string pattern)
    {
        string escaped = Regex.Escape(pattern);
        escaped = escaped.Replace(@"\*", ".*").Replace(@"\?", ".");
        return "^" + escaped + "$";
    }
    static void Main()
    {
        string[] filePaths = {
            @"C:\data\report.txt",
            @"C:\data\2023\summary.csv",
            @"C:\data\2023\report.csv",
            @"C:\data\notes.docx"
        };
        string wildcardPattern = @"C:\data\*\*.csv";
        string regexPattern = WildcardToRegex(wildcardPattern);
        Console.WriteLine($"正規表現パターン: {regexPattern}");
        foreach (var path in filePaths)
        {
            bool isMatch = Regex.IsMatch(path, regexPattern, RegexOptions.IgnoreCase);
            Console.WriteLine($"{path} → {isMatch}");
        }
    }
}

正規表現パターン: ^C:\\data\\.*\\.*\.csv$
C:\data\report.txt → False
C:\data\2023\summary.csv → True
C:\data\2023\report.csv → True
C:\data\notes.docx → False

この例では、C:\data\*\*.csvというワイルドカードパターンを正規表現に変換し、dataフォルダの直下のサブフォルダ内にあるCSVファイルだけを抽出しています。

RegexOptions.IgnoreCaseを指定して大文字小文字を無視しています。

ログ解析

ログファイルの解析では、特定のキーワードやパターンにマッチするログ行を抽出したり、エラーメッセージを検出したりすることが多いです。

正規表現を使うことで、複雑なログフォーマットから必要な情報を効率的に取り出せます。

以下は、ログの中から「ERROR」レベルのログ行を抽出し、日時とメッセージを分割して表示する例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main()
    {
        string[] logs = {
            "2024-06-01 10:00:00 INFO Application started",
            "2024-06-01 10:05:00 ERROR Failed to connect to database",
            "2024-06-01 10:10:00 WARN Low disk space",
            "2024-06-01 10:15:00 ERROR Timeout occurred"
        };
        string pattern = @"^(?<date>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) ERROR (?<message>.+)$";
        foreach (var log in logs)
        {
            var match = Regex.Match(log, pattern);
            if (match.Success)
            {
                string date = match.Groups["date"].Value;
                string message = match.Groups["message"].Value;
                Console.WriteLine($"日時: {date}, エラーメッセージ: {message}");
            }
        }
    }
}

日時: 2024-06-01 10:05:00, エラーメッセージ: Failed to connect to database
日時: 2024-06-01 10:15:00, エラーメッセージ: Timeout occurred

この例では、名前付きキャプチャグループを使って日時とエラーメッセージを抽出しています。

正規表現のパターンを変えることで、他のログレベルやフォーマットにも対応可能です。

コマンドライン引数のマッチング

コマンドライン引数の解析では、特定のオプションやパラメータの形式を検証したり、値を抽出したりすることが求められます。

正規表現を使うと、複雑な引数のパターンを簡潔に表現でき、柔軟な解析が可能です。

以下は、--file=filename.txtや-vのような引数を検出し、ファイル名やフラグを抽出する例です。

using System;
using System.Text.RegularExpressions;
class Program
{
    static void Main(string[] args)
    {
        // サンプル引数
        string[] sampleArgs = { "--file=report.txt", "-v", "--output=out.csv", "-h" };
        string filePattern = @"^--file=(.+)$";
        string outputPattern = @"^--output=(.+)$";
        string flagPattern = @"^-(\w)$";
        foreach (var arg in sampleArgs)
        {
            var fileMatch = Regex.Match(arg, filePattern);
            if (fileMatch.Success)
            {
                Console.WriteLine($"ファイル指定: {fileMatch.Groups[1].Value}");
                continue;
            }
            var outputMatch = Regex.Match(arg, outputPattern);
            if (outputMatch.Success)
            {
                Console.WriteLine($"出力先指定: {outputMatch.Groups[1].Value}");
                continue;
            }
            var flagMatch = Regex.Match(arg, flagPattern);
            if (flagMatch.Success)
            {
                Console.WriteLine($"フラグ指定: {flagMatch.Groups[1].Value}");
            }
        }
    }
}

ファイル指定: report.txt
フラグ指定: v
出力先指定: out.csv
フラグ指定: h

この例では、引数の形式ごとに正規表現を使ってマッチングし、必要な情報を抽出しています。

複雑な引数構造にも対応できるよう、パターンを拡張していくことが可能です。

これらの応用例は、C#のRegexを活用して文字列のパターンマッチングを効果的に行う方法の一部です。

実際の開発では、要件に応じてパターンをカスタマイズし、柔軟に対応してください。

まとめ

この記事では、C#の正規表現(Regex)を使ったワイルドカード比較の基本から応用までを解説しました。

ワイルドカードの*や?を正規表現に変換する方法や、大文字小文字の扱い、マルチライン設定、性能面の注意点、非同期処理での活用例、エラーハンドリング、保守性向上の設計ヒント、他の手法との比較、セキュリティ上の留意点、よくある誤解、そして実践的な応用例まで幅広く理解できます。

これにより、C#で効率的かつ安全に文字列のパターンマッチングを実装できるようになります。

2025-05-15更新日: 2025-05-15

Regexとワイルドカード比較の関係

ワイルドカードの基本 * と ?

正規表現 .* と . へのマッピング

エスケープが必要な文字一覧

Regexパターン生成の基本

静的パターンの記述例

動的入力を安全に変換する手順

Regex.Escape の活用

ワイルドカードとの混在を処理するカスタム関数

大文字小文字の扱い

RegexOptions.IgnoreCase の効果

マルチライン・ドットオールの設定

行単位の比較

改行を含む文字列のマッチング

RegexOptions.Singleline

RegexOptions.Multiline

オプション別の性能比較

コンパイル済み正規表現のメリット

キャッシュとメモリ使用量

ベンチマークサンプル

非同期・リアクティブシナリオでの利用

UI入力検証

ストリームデータのフィルタリング

エラーハンドリングとデバッグ

パターン構築エラーの検出

Regex.MatchTimeoutException の対策

保守性向上のための設計ヒント

パターンを定数・設定ファイルに分離

定数として管理する例

設定ファイルに分離する例

単体責任のクラス設計

拡張メソッドでの再利用

他のアプローチとの比較

LikeOperator の限界

Linqによる手作業フィルタとの違い

サードパーティライブラリ選定のポイント

セキュリティ観点の留意点

ReDoS 脆弱性

対策方法

外部入力の適切な検証

ポイント

よくある誤解とハマりどころ

ワイルドカード位置による意図しないマッチ

. と \n の挙動

応用例コレクション

ファイルパスフィルタリング

ログ解析

コマンドライン引数のマッチング

まとめ

関連記事