An explanation of your regex will be automatically generated as you type.
regex101: build, test, and debug regex
An explanation of your regex will be automatically generated as you type.
最近のruby-core (2016年2月) - Money Forward Developers Blog
こんにちは。卜部です。 ruby-coreというRuby本体の開発の議論がされているメーリングリストがあります。 新機能やバグ報告などがだいたいここに集約されてくるので購読しておくとRubyの動きが分かります。 最近興味深かったトピックを紹介します。 [#12039] Fixnum#infinite?/Bignum#infinite or Numeric#infinte, consistent with Float#infinite? and BigDecimal#infinite? Float と BigDecimal には #infinite? メソッドがあるのに Fixnum と Bignum には存在しないので困る/欲しい、という提案です。これはあると便利ですね。 [#12040][Win32] File.stat fails on a mounted volume Windows
私がどのようにしてAtomの奇妙なバグを修正したか : 正規表現が暴走を起こすとき | POSTD
Atom は、今注目の最新テキストエディタです。私は、このエディタをソフトウェア開発に使用しているのですが、オープンソースになっているので、少しでも貢献できればとAtomが抱えるIssuesについて検証してみることにしました。私は、 ある奇妙なバグ を見つけました。それは、Atomのユーザ speter がテキストを1行書き、行末で Enter を押した時に起こりました。新たな行が書けるようになるまで、Atomは30分も計算していたのです。私は、そんな単純かつよくあるオペレーションもろくにできないことに大きな衝撃を受け、早速その原因を探ることにしました。 検索 これが、問題のテキストです。 vVar.Type().Name() == "" && vVar.Kind() == reflect.Ptr && vVar.Type().Elem().Name() == "" && vVar.Typ
正規表現：悪い表現、いい表現、最良の表現 | POSTD
わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず
HFS+のテキストエンコーディング – ものかの
HFS+はファイルやフォルダなどのアイテム名をどのテキストエンコーディングで扱っているのでしょうか？ Appleは最近までこの情報をドキュメントに記載して公開していたのですが、今はしていません（2016年10月現在）。それでも第三者によるアーカイブがかろうじて残っており、典拠として貴重なのでここに記録しておきます。 2009年時点のFile Systems and Unicode Support 追記：いつのまにかリンク切れしていました。キャプチャを貼っておいてよかった…。 見ての通りUTF-16ですね。インターネット上ではUTF-8-MACであるとの説明が散見されますが間違いです。 HFS+のUnicode正規化形式 Unicode正規化形式はUAX#15で4種類が正式に決められています。HFS+はそのうちのNFDをさらにAppleが改変した特殊な正規化形式を実装しています。アイテム名は
正規表現を解析して可視化してくれるサイトが凄すぎる件
ある正規表現に対して、特定の文字列がマッチするかどうかをチェックするツールやサイトは沢山ありますが、正規表現そのものが何を意味しているのか、どんな文字列を期待しているのかを解析・解読・説明してくれるツールやサイトってなかなか見ない気がします。 他人の書いた正規表現を見て、「ん？」ってなったことはありませんか？ 例えばこれ。 1 ^[a-zA-Z0-9-_.]@([a-zA-Z0-9_-]+\.)+[a-zA-Z]{2,4}$ これくらいなら分かりますが、複雑になってくるとつらい… いつかはマスターしたいけど…今は楽したい。 そう思ってググってみると…ありました！ それがこちら。 Regexper http://www.regexper.com/ 正規表現を入力して Display をクリックすると、その正規表現が表す内容を図にして表示してくれます。 例えば先程の正規表現は、当記事の一番上の
モダンなインターフェースで正規表現が学べる『RegExr v2.0』 | 100SHIKI
よくあるツールではあるが、今風のインターフェースだったのでご紹介。 RegExr v2.0を使えば、さまざまな正規表現をブラウザ上で試すことができる。 ちゃんとリファレンスも付いているので、迷った時に参照してみるといいだろう。 また作った正規表現はコミュニティとシェアしたりお気に入りに入れることもできる。 そろそろ正規表現をマスターしたい・・・という人はいかがだろうか。
CVE-2013-2266 [JP]: 不正に細工された正規表現によってnamedがメモリ不足になる
BIND 9の深刻な欠陥により、攻撃者が、named、およびlibdnsをリンクする他のプラグラムのメモリを過大に消費させることが可能となります。 CVE: CVE-2013-2266 文書バージョン: 2.0 公開日付: 2013年3月26日 影響を受けるプログラム: BIND 影響を受けるバージョン: BIND 9.7.x, 9.8.0 から 9.8.5b1, 9.9.0 から 9.9.3b1(いずれも"Unix"版のみ。Windows版は影響を受けない。9.7.0より前のバージョン(9.6-ESVを含む)も影響を受けない。BIND 10も影響を受けない) 深刻度: 重大(Critical) 攻撃方法: 遠隔から可能 詳細: Unix系のオペレーティングシステムでコンパイルされたBIND 9.7, 9.8, および9.9で利用されているライブラリの欠陥により、攻撃者が意図的にnamed
![CVE-2013-2266 [JP]: 不正に細工された正規表現によってnamedがメモリ不足になる](https://cdn-ak-scissors.b.st-hatena.com/image/square/33006d49b56e36a164d4d70961c8f6735cbd4d3b/height=288;version=1;width=512/https%3A%2F%2Fcdn.document360.io%2F956e37e2-5ec0-4942-8b27-35533899f099%2FImages%2FDocumentation%2FISC-logo-rgb-2048x1149.png){kind=logo}
電話番号、郵便番号にマッチする真の正規表現 : にぽたん研究所
Shibuya.pm #16 「夏の正規表現祭り」で、正規表現のお話をさせていただきました。 まぁ、「電話番号にマッチする正規表現」とか「郵便番号にマッチする正規表現」とかよく書かれてるけど、「どれもこれも手緩いよね」って話。 あ、だいぶはしょったかな。 とりあえずスライドに書いたので、発表をご覧になってない方はスライドからご覧ください。 ふと見返すと、このブログで電話番号の正規表現を公表するのは 3 度目ですが、あれからだいぶ経ってますね。 今ではもっと厳密な正規表現を作っています。 そして、Number::Phone::JP に続き、Number::ZipCode::JP という酔狂なモジュールが公開された記念で、郵便番号にマッチする正規表現を今回初めて公開しますが、そもそもここまで厳密な正規表現が公開されること自体、本邦初公開ってヤツでしょう。 Shibuya.pm でも言いましたが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
正規表現入門 星の高さを求めて
IDEA * IDEA