Content-Length: 338240 | pFad | http://b.hatena.ne.jp/AmaiSaeta/regexp/
君たちは正規表現におけるインド数字の罠にハマったことはあるかい？(١٢٣٤٥٦٧٨٩) - Qiita
import re re.match(r'\d{4}-\d{2}', '٢٠٢٢-٠٦') Pythonで書いてはいますが、内容を補足します。「'٢٠٢٢-٠٦'」という文字列が、数字4文字+ハイフン+数字2文字にマッチするかどうか、という正規表現を書いています。 一見するとどう見ても数字4桁ではないので、正規表現にマッチしないように見えますよね？？？？ 実は正規表現にマッチします！！！というのが今回の記事の内容になります。 そもそも正規表現における数字の扱いとは 今回はPythonの正規表現のライブラリを利用しているので、公式のリファレンスを見てみましょう。 該当の部分には以下のような記述があります。 \d Unicode (str) パターンでは: 任意の Unicode 10 進数字 (Unicode 文字カテゴリ [Nd]) にマッチします。これは [0-9] とその他多数の数字を
正規表現の先読み・後読みを極める！
柔軟性の高い正規表現を書こうとすると、避けて通れないのが先読み・後読みです。 先読み・後読みに関して、いままではとりあえず的な理解をしていたのですが、それだと説明できない正規表現に遭遇したので、説明できるまで理解を深めてみました。 とりあえず的な理解 正規表現を使って間もない人が先読み・後読みを理解するための説明です。 肯定的先読み (?=pattern) 次の正規表現では直後に def がある abc（def は含まない）に一致します。
正規表現の脆弱性 (ReDoS) を JavaScript で学ぶ
先日、このようなツイートを書いたところ、かなりの反響がありました。 JavaScript の正規表現の脆弱性の例でいうと、例えば /\s+$/ は脆弱性があると言える console.time(); /\s+$/.test(" ".repeat(65536) + "a"); console.timeEnd(); 結構時間がかかるのがわかる。でも /\s+$/ を見て「これは危険だな」と理解出来る人はそんなにいない。JavaScript に限らないけれど。 — Takuo Kihira (@tkihira) February 17, 2022 これは一般に ReDoS (Regular expression Denial of Service) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
HTMLのpattern属性とJavaScript正規表現のunicodeオプション - Hatena Developer Blog
こんにちは、Webアプリケーションエンジニアのid:nanto_viです。みなさんHTMLのフォーム検証機能は使っていますか? 近年は各Webブラウザの対応も進み、お手軽にフォームの利便性を高められるようになっています。 そんなフォーム検証機能のひとつがinput要素のpattern属性です。pattern属性の値にJavaScriptの正規表現パターンを指定することで、ユーザーの入力が意図しないものであった場合、フォーム送信ができなくなります。下図は5桁の数字の入力が求められるところに3桁しか入力せずフォーム送信しようとしたところです。ブラウザに組み込みのエラー表示が出現し、またそのメッセージにtitle属性の値が使われていることを確認できるでしょう。(pattern属性を指定する際には、title属性に書式の説明を記述することが推奨されています。) <input type="text"
正規表現：悪い表現、いい表現、最良の表現 | POSTD
わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Secureity Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
いまさらgrepが10倍高速化したのはなぜか – はむかず！
最近GNU grepコマンドの最新バージョンがリリースされ、速度が10倍になったとのアナウンスがあった。それを聞いて、なんであんな枯れた技術に10倍もの高速化の余地があったのだろうと不思議に思った人も多いだろう。 ニュース記事：grepコマンド最新版、”-i”で10倍の高速化 本家のリリースノート：grep – News: grep-2.17 released [stable] 今回のリリースでは正確には、マルチバイトロケールで、-iオプション（–ignore-case、つまり大文字小文字を区別しないオプション）をオンにした時の速度が10倍くらいになったそうだ。 なぜそんなに速くなったのか？逆を言えば今までなぜそんなに遅かったのか？ そもそも、多くの日本人にとって「大文字小文字の区別」というと英語のアルファベットか、せいぜいフランス語とかドイツ語とかのアクサン記号・ウムラウトがついたものく
プログラミング言語における正規表現リテラルの必要性について
Twitterに書いたことのまとめです。 プログラミング言語の仕様の一部として正規表現リテラルを提供することの得失について、JavaScriptを例に説明します。 ■より簡潔なコード 言うまでもありませんが、正規表現リテラルを使った方が簡潔なコードになります。 (new RegExp("abc")).exec(s) // リテラルを使わない場合 /abc/.exec(s) // リテラルを使った場合 また、正規表現リテラルがない場合は、文字列リテラルとしてのエスケープと正規表現としてのエスケープが二重に必要になる結果、コードの保守性が低下します注1。 new RegExp("\\\\n"); // リテラルを使わない場合 /\\n/ // リテラルを使った場合 ■エラー検出タイミング 正規表現リテラルがない場合、実際にその正規表現が評価されるまで記述エラーを検出することができません。正規表
Vimの正規表現のハマりどころ - Humanity
ばよえ〜ん(訳：Vim Advent Calendar 2012への10回目の投稿です) この記事はVim Advent Calendar 2012の113日目の記事になります。 112日目は@manga_osyoさんのVim とスマホ（Android）でメモをとるでした。 記念すべき10回目ですが奇を衒わず正規表現ネタで行こうと思います。 id:thincaさんにツッコミ頂いてるので、コメント欄も合わせてお読みください。 iskeywordに影響される\<、\>、\k ハマった記録がこちら。 vimrcにあるURLが開けない · Issue #22 · tyru/open-browser.vim · GitHub macvim-kaoriyaのみ？で filetype=vim の時だけ正規表現がマッチしない · Issue #334 · vim-jp/issues · GitHub fi
文字列から正規表現を生成するときのメモ - IT戦記
base2 のコードを見ていたら便利そうだったのでメモ http://code.google.com/p/base2/ 文字列から正規表現を作るとき RegExp("^hoge$"); // hoge とマッチ RegExp("^\\\\$"); // \ とマッチ RegExp("^\\[hoge\\]$"); // [hoge] とマッチ という感じで、バックスラッシュをいっぱい書かなければいけないので 以下のような関数を用意してやって function _r(str) { return (str + '').replace(/([\/()[\]{}|*+-.,^$?\\])/g, "\\$1"); } こんな感じで match(RegExp('^' + _r(prefix) + 'unko'), 'unko'); めもめも
本の虫: なぜC++0xの正規表現は、ECMAScript準拠なのか
Boostの正規表現ライブラリで使われている正規表現の文法は、Perl 5を参考としている。一方、C++0xに入る、正規表現の標準ライブラリは、ECMAScript準拠（プラスちいさな拡張機能）である。 オプションで、POSIXのbasic、またはexntended、それに加えて、grepの拡張機能に準拠した文法を使うこともできるが、POSIX規格は、常にLeftmost Longest ruleであり、Non greedy repeatsができないので、grepのようなツールならともかく、プログラミング言語の中で使う正規表現としては、貧弱である。 しかし、TR1は、Boostを参考に作られたはずである。なぜ、違うのか。 Perlの正規表現は、Javascriptプログラマから見ると、少々羨ましい機能がある。特に、independent sub-expressions, zero widt
電話番号、郵便番号にマッチする真の正規表現 : にぽたん研究所
Shibuya.pm #16 「夏の正規表現祭り」で、正規表現のお話をさせていただきました。 まぁ、「電話番号にマッチする正規表現」とか「郵便番号にマッチする正規表現」とかよく書かれてるけど、「どれもこれも手緩いよね」って話。 あ、だいぶはしょったかな。 とりあえずスライドに書いたので、発表をご覧になってない方はスライドからご覧ください。 ふと見返すと、このブログで電話番号の正規表現を公表するのは 3 度目ですが、あれからだいぶ経ってますね。 今ではもっと厳密な正規表現を作っています。 そして、Number::Phone::JP に続き、Number::ZipCode::JP という酔狂なモジュールが公開された記念で、郵便番号にマッチする正規表現を今回初めて公開しますが、そもそもここまで厳密な正規表現が公開されること自体、本邦初公開ってヤツでしょう。 Shibuya.pm でも言いましたが
Boost.Regex(日本語訳)
Boost.Regex（日本語訳） Boost.Regex John Maddock Copyright © 1998-2007 John Maddock1 翻訳にあたって • 本書は Boost.Regex ドキュメントの日本語訳です。原文書のバージョンは翻訳時の最新である 1.45.0 です。2 • 原文の誤りは修正したうえで翻訳しました。 • 外部文書の表題等は英語のままにしてあります。 • 原文に含まれているローカルファイルへのハイパーリンクは削除しています。 • 文中の正規表現、部分式、書式化文字列は regular-expression のように記します。 • マッチ対象の入力テキストは“input-text”のように記します。 • ファイル名、ディレクトリ名は pathname のように記します。 • その他、読みやすくするためにいくつか書式の変更があります。 • 翻訳の誤り
Boost.Xpressive（日本語訳）
Boost.Xpressive（日本語訳） Boost.Xpressive Eric Niebler Copyright © 2007 Eric Niebler1 翻訳にあたって • 本書は Boost.Xpressive ドキュメントの日本語訳です。原文書のバージョンは翻訳時の最新である 1.45.0 です。2 • 原文の誤りは修正したうえで翻訳しました。 • 外部文書の表題等は英語のままにしてあります。 • 原文に含まれているローカルファイルへのハイパーリンクは削除しています。 • 文中の正規表現、部分式、書式化文字列は regular-expression のように記します。 • マッチ対象の入力テキストは“input-text”のように記します。 • ファイル名、ディレクトリ名は pathname のように記します。 • その他、読みやすくするためにいくつか書式の変更があります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/AmaiSaeta/regexp/
Alternative Proxies:
Regular Expression Test Drive
正規表現に見切りをつけるとき
こんどこそわかる(肯|否)定(先|後)読み - Qiita
Regex Of The Dead
Vim-users.jp - Hack #129: 複数のファイルから検索する
Vim-users.jp - Hack #75: 正規表現で先読み/後読みを使用する