正規表現テスター
JavaScript の正規表現をブラウザ上でリアルタイムにテスト。マッチ箇所のハイライト・キャプチャグループの取得・全フラグ対応。
ハイライト結果
マッチ詳細
よく使うパターン
📖 つまずきやすいポイント
JavaScript の正規表現エンジンでパターンをリアルタイムに評価し、マッチ箇所のハイライトとキャプチャグループを表示します。処理はブラウザ内で完結します。使っているのは JavaScript の方言です — ここで通ったパターンが PHP・Python・Go でそのまま動くとは限りません。文字クラスの意味、lookbehind の有無、Unicode の扱いが言語ごとに違うためです。
| ケース | 何が起きるか | どうする |
|---|---|---|
| g フラグを付けると 2 回目の結果が変わる | g フラグの付いた正規表現オブジェクトは lastIndex という状態を持ちます。同じオブジェクトで test() を繰り返すと、前回のマッチ位置から探し始めるので、同じ文字列に対して true と false が交互に返ります。これが致命的になるのは、正規表現をモジュールのトップレベルで定義して使い回すときです — 状態がリクエストをまたいで残り、「たまに検証を通ってしまう」という再現しないバグになります。テストでは 1 回しか呼ばないので、まず気付けません。 |
test() や exec() で使う正規表現に g を付けないでください — 「全部にマッチさせたい」という意図で付けがちですが、test() は「1 つでもあるか」を見る関数なので g は不要です。全件を取りたいなら str.matchAll(re) を使ってください (こちらは g が必須です)。使い回すオブジェクトで g が必要なら、呼び出しの直前に re.lastIndex = 0 を入れてください。そもそも、正規表現リテラルを関数の中で毎回書くコストは無視できます — JavaScript エンジンはリテラルをキャッシュするので、共有を避けるほうが安全で、速度もほぼ変わりません。 |
| 日本語や絵文字が思ったようにマッチしない | \w は ASCII の英数字とアンダースコアだけを意味します — 日本語には一切マッチしません。\b (単語境界) も同じ理由で、日本語の文中では期待どおりに働きません。もう 1 つ深刻なのがサロゲートペアで、u フラグを付けないと、絵文字や一部の漢字 (𠮷・𩸽 など) が 2 文字として扱われます — . が半分だけマッチし、[𠮷] という文字クラスは「2 つのサロゲートのどちらか」という意味不明な集合になります。文字数のカウントや切り詰めで、文字が壊れる原因のほとんどがこれです。 |
u フラグを必ず付けてください — これだけでサロゲートペアが 1 文字として扱われ、さらに \p{...} という Unicode プロパティが使えるようになります。日本語なら \p{Script=Hiragana}・\p{Script=Katakana}・\p{Script=Han} です — [ぁ-んァ-ヶ一-龠] のような範囲指定より正確で、意図も読み取れます。絵文字を扱うなら \p{Extended_Pictographic} ですが、肌の色や家族の絵文字は複数のコードポイントの組み合わせなので、1 文字として扱うには Intl.Segmenter が必要です — 正規表現だけでは限界があります。文字数を数える目的なら、正規表現ではなく Intl.Segmenter を使ってください。 |
| 貪欲マッチで想定より広く取ってしまう | .* は可能な限り長くマッチしようとします。したがって <div>A</div><div>B</div> に対して <.*> を当てると、最初の < から最後の > まで、全体が 1 つのマッチになります。. は既定で改行にマッチしないので複数行なら止まりますが、s フラグを付けた瞬間にファイル全体を飲み込みます。この挙動は正しいのですが、期待と食い違うと、テストでは通って本番の長い入力で壊れるという形で出ます。 |
非貪欲の .*? にするか、より良いのは [^>]* のように「そこに現れない文字」で書くことです — 後者はバックトラックが起きないので速く、意図も明確になります。ただしより根本的な助言として、HTML を正規表現でパースしないでください — 属性値の中の >、コメント、CDATA、ネストした同名タグで必ず破綻します。ブラウザなら DOMParser、サーバーなら各言語の HTML パーサーを使ってください。正規表現が適しているのは「行単位で、構造を持たない、書式が決まったテキスト」です — ログの行、設定ファイルの 1 行、識別子の書式検証。入れ子のある構造は、正規表現の守備範囲の外です。 |
ネストした量指定子は ReDoS の温床です。(a+)+$ や (\w+\s?)*$ のように「繰り返しの中に繰り返し」がある式は、マッチしない入力に対して指数時間かかります — 30 文字程度の入力で、サーバーの CPU が数分間 100% になります。皮肉なことに、これが最も多く見つかるのは「厳密な」メールアドレス検証の正規表現で、実際に大規模サービスの障害原因になった事例が複数あります。対策は 3 つ — ネストした量指定子を書かない、入力の長さに上限を設ける、そしてバックトラックしないエンジン (Go の標準 regexp、Rust の regex、C++ の RE2) を使うことです。方言の違いも押さえておいてください — JavaScript には \A と \z がありません (m フラグ無しの ^ $ で代用します)。lookbehind は ES2018 で入りましたが、Safari の対応が 16.4 と遅かったので、古い環境を対象にするなら避けてください。
📖 使い方
-
1
パターンを入力正規表現を入力欄にタイプ (例: \\d{3}-\\d{4})。フラグ (g / i / m / s) をトグルで指定できます。
-
2
テスト文字列を貼り付けターゲット文字列をテキストエリアに入れると、マッチ箇所がリアルタイムでハイライトされます。
-
3
キャプチャグループを確認右側のパネルに各マッチの位置とキャプチャグループ値が一覧表示されます。置換プレビューも可能。
❓ よくある質問
対応している正規表現エンジンは?
日本語文字クラス (ひらがな・カタカナ・漢字) は使えますか?
パフォーマンスはどれくらい?
他の言語のコードに変換したい
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。