テキスト

Regex Tester / Find & Replace

実際のテキストで正規表現をテスト:マッチ箇所のハイライトとキャプチャグループの解析、または見つかったマッチを新しいテキストに置換。


                        

                        

A regular expression (regex) is a compact language for describing patterns in text — for searching, validating a format, or replacing matches. This tool highlights matches in real text as you type the pattern, breaks out capture groups, and supports a find-and-replace mode.

How to use it

Common uses

Things to keep in mind

Greedy quantifiers (*, +) grab as many characters as possible — add ? for the minimal match instead (e.g. .*? instead of .*).

Syntax varies slightly between languages — an expression that works here (a JavaScript engine) may need adjusting for PCRE, .NET, or Python.

このツールに関する記事: 正規表現:基本と貪欲マッチの罠

よくある質問

どのregexエンジンが使われていますか?

このツールはPCREではなくJavaScriptのregexエンジンを使用しているため、一部のPCRE固有の構文(再帰的アサーションや特定の所有的マッチングモードなど)はここでは機能しません。g、i、m、s、uなどの一般的なフラグはサポートされています。

貪欲な量指定子と怠惰な量指定子の違い、およびTestとReplaceの違いは何ですか?

*や+のような貪欲な量指定子はできるだけ多くのテキストをキャプチャしますが、その怠惰なバージョン(*?、+?)はできるだけ早く停止します。モードについては、Testは一致をハイライトし、キャプチャグループ(名前付きを含む)をリストし、Replaceは各一致に$1のような参照を使った置換テキストを適用します。

私のテキストと式はサーバーに送信されますか?

いいえ、正規表現の評価はブラウザ内で完全にクライアントサイドで行われ、オンラインには何も送信されません。

破滅的バックトラッキングとは何ですか?

(a+)+のようなネストした数量詞は、特定の入力文字列に対してエンジンに指数関数的な数の組み合わせを試させることがあります — 一見単純に見える式で、ページやスクリプトが「フリーズ」してしまいます。これは実際の脆弱性(ReDoS)であり、複雑なネストした数量詞は長いほぼ一致する文字列に対してテストすべきです。

なぜ私の正規表現はあるプログラミング言語では動くのに、別の言語では動かないのですか?

regexの構文は完全には標準化されていません: PCRE(PHP、その他多くの言語)、.NET、Python re、JavaScriptは、特定の構文(look-behindや名前付きグループなど)のサポートに細かな違いがあります — あるエンジン向けに書かれた式が、別のエンジンでそのまま動くとは限りません。

記事: テキスト

camelCase、snake_case、kebab-case:どの場面でどれを使うか

なぜcamelCase、snake_case、kebab-caseが存在し、それぞれ普通どこで使われるか。

Text Diff:テキストの差分検出アルゴリズムの仕組み

diffアルゴリズムがテキストの2つのバージョン間の最小変更セットをどう見つけるか。

行のソート:アルファベット順と数値順はなぜ違うのか

アルファベット順ソートが数値をテキストとして扱う理由と、数値ソートとの違い。

文字列エスケープ:JS、JSON、シェル、正規表現でルールが異なる理由

あらゆる場面で通用する単一のエスケープルールが存在しない理由 — JS、JSON、シェル、正規表現それぞれに固有のルールがある。

CRLFとLF:改行コードが今も問題を引き起こす理由

CRLFとLFの違いがどこから来たのか、そしてgitやスクリプトで今も問題を引き起こす理由。

文字数と単語数のカウント:Unicodeがなぜこれを複雑にするか

Unicodeにおいて視覚的に1つの絵文字が複数のコードポイントから成り立つことがある理由。

Lorem Ipsum:このダミーテキストはどこから来て、なぜ意味がないのか

Lorem Ipsumテキストが実際どこから来たのか、そして実際のテキストの代わりに無意味なテキストが使われる理由。

Slugify:タイトルが有効なURLに変換される仕組み

記事タイトルがハイフンで区切られたクリーンで読みやすいURLに変換される仕組み。

Markdown:ドキュメント作成の標準になった理由

HTMLとは違い、Markdownが生のままでも読みやすい理由。

見えない空白文字:見た目が同じテキストの比較がなぜ失敗するのか

見えない空白文字1つが、見た目上同じ2つのテキストの比較を失敗させる仕組み。

テキストの反転:絵文字でなぜ壊れるのか

単純なテキスト反転が、複数のコードポイントから成る絵文字をなぜ壊してしまうのか。

テキスト頻度分析:ワードクラウドから暗号解読まで

文字頻度分析が歴史的にどう単純な換字式暗号の解読に役立ったか。