[正規表現] .*?は最短マッチではない - Qiita
# Ruby 2.4.2 "<<<hoge>>>".match(/<.*?>/)[0] #=> "<<<hoge>" なぜこうなるのか .*?は、 最短マッチ 最左マッチ の2つの原則に従い、しかも最左マッチの原則の方が優先順位としては高いからである。 より嚙み砕いて言うと <.*?>は先頭の<がマッチした後に、そこからマッチする部分をできるだけ最小化しようと試みる。 <<<hoge>>>に対して<.*?>をパターンマッチさせる際に行われる実際の処理の流れは、次のようなイメージになるだろう。 < # <までマッチ << # <>のマッチに失敗、.の数を増やしてリトライ << # <.までマッチ <<< # <.>のマッチに失敗、.の数を増やしてリトライ <<< # <..までマッチ <<<h # <..>のマッチに失敗、.の数を増やしてリトライ <<<h # <...までマッチ <<<ho
![[正規表現] .*?は最短マッチではない - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/542637a002d442a95e32ca29b038cefc658a698f/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU2JUFEJUEzJUU4JUE2JThGJUU4JUExJUE4JUU3JThGJUJFJTVEJTIwLiUyQSUzRiVFMyU4MSVBRiVFNiU5QyU4MCVFNyU5RiVBRCVFMyU4MyU5RSVFMyU4MyU4MyVFMyU4MyU4MSVFMyU4MSVBNyVFMyU4MSVBRiVFMyU4MSVBQSVFMyU4MSU4NCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NDQ0YWVmNmM2OTlmZDVkNThhNTVlMWFjOGNlNTJjMDU%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MWI2YjM3NTQ2NWU2MzcxNDBlNWEzZjNkY2NjMTI2MTQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da996653f627dce69f871d2f75c209414)
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
Email Address Regular Expression That 99.99% Works.
Just copy and paste the email regex below for the language of your choice. Feeling hardcore (or crazy, you decide)? Read the official RFC 5322, or you can check out this Email Validation Summary. Note there is no perfect email regex, hence the 99.99%. General Email Regex (RFC 5322 Official Standard) (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\
TM Regetor
TM Regetor は, 正規表現の結果をリアルタイムで反映, 確認できるツールです. Input に正規表現を入力すると, Target に Input 内容でマッチ判定をし 結果を Output に表示します. また, 入力内容は URL の Hash に保存されるので, URL をコピペすれば周りの人と共有できます!! 正規表現を学ぶ際などに使ってくださいな♪
私がどのようにしてAtomの奇妙なバグを修正したか : 正規表現が暴走を起こすとき | POSTD
Atom は、今注目の最新テキストエディタです。私は、このエディタをソフトウェア開発に使用しているのですが、オープンソースになっているので、少しでも貢献できればとAtomが抱えるIssuesについて検証してみることにしました。私は、 ある奇妙なバグ を見つけました。それは、Atomのユーザ speter がテキストを1行書き、行末で Enter を押した時に起こりました。新たな行が書けるようになるまで、Atomは30分も計算していたのです。私は、そんな単純かつよくあるオペレーションもろくにできないことに大きな衝撃を受け、早速その原因を探ることにしました。 検索 これが、問題のテキストです。 vVar.Type().Name() == "" && vVar.Kind() == reflect.Ptr && vVar.Type().Elem().Name() == "" && vVar.Typ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
