InDesignの正規表現検索チートシート - DTPab
【訂正 2018.9.4】一部表記を訂正しました（赤字部分）。 なんか前回も検索についての記事だったんですけど、今回もたまたま検索に関する記事です。やっぱりよく使うInDesignの正規表現検索。 で、InDesignの正規表現検索は標準機能ながら強力で使いやすいのですが、いかんせん入力が面倒。あの検索窓、少し大きくしたい…と思っている方は僕以外にもきっといるはず^^; 以前は、たまーに使う正規表現を（いちいち記憶してられないので）チートシートっぽく取っておいて、それをコピペするなどして使ってました。 特殊な数字の検索チートシート ということで、まずは僕が使っているInDesignの正規表現のチートシートの一部を上げます。以下はすべてUnicodeのコードポイントが付番されているものだけです。念のため書いておくと、ここに挙げている正規表現はすべて基底文字デフォルトグリフ*1で、字形を変えら
Sorekika 【第352回 イレギュラー・エクスプレッション】
第352回 イレギュラー・エクスプレッション 変わっている人というのはどこにでもいるものだろうけれど、コンピュータ業界には特に多いように思われる。たとえば、新しい言葉を聞いて「頭の中に単語登録しておきます」と言ったり、頼んだ出前がなかなか来ないと「ルーティングおかしいんじゃないか」と呟いたり、捜し物が見つからず「４０４だ」と叫んだりと、日常会話にコンピュータ用語を持ち込む人は結構いる。まあしかし、この程度ならどのような業種でもあることかもしれない。 だが、正木氏はそんなもんではない。 正木氏は取引先のエンジニアで、はじめて会ったのはある打ちあわせの席である。かなり大人数での打ちあわせだったし、その時はほとんど喋らなかったので、私は彼の「変わっている具合」に全く気付かなかった。ちょっと変だなと思ったのは、仕事でメールをやりとりするようになってからである。 正木氏のメールにこのような部分があっ
regex101: build, test, and debug regex
An explanation of your regex will be automatically generated as you type.
正規表現のパフォーマンスの話をされても全くピンと来なかった僕は、backtrackに出会いました。 - Qiita
となります。 （もちろん、上のパタンは、デタラメなものも引っかかるので、正しくないけど、そういうのはいったん無視。 感覚的には下の方がよさそうだけど。どういうことですか？ ステップ数を見てみる！ https://regex101.com/#pcre この素晴らしいサイトを利用します。 123-4567とのマッチングを考えます。 まず、/^\d{3}-\d{4}$/ はこんな感じで、7ステップ 一方、/^.*-.*$/ は..12ステップ ということで、.* の方がステップ数が増えてパフォーマンスが悪くなっていそうです。 （実際パフォーマンスはこのステップ数に依存しそうなので、悪くなっていると思います。後で時間測ります。 バックトラック（BACKTRACK）と出会いました。 上のツールを使うことで、正規表現の処理順序が視覚的に理解できます。 左から比較処理をしていくのですが、ステップ3を比較
よく使う正規表現はもうググりたくない！ - Qiita
タイトル通りによく使う正規表現を毎回ググるのが効率悪いのでまとめてみました。各言語で正規表現のサンプルを書いてみました。 正規表現式 Emailアドレス ^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$ ドメイン名 ^[a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}$ インタネットURL ^(http|https)://([\w-]+\.)+[\w-]+(/[\w-./?%&=]*)?$ ユーザー名 (Twitter username) ^[a-zA-Z0-9_\-.]{3,15}$ 固定電話 ^0\d-\d{4}-\d{4}$ 携帯電話 ^(070|080|090)-\d{4}-\d{4}$ IP電話 ^050-\d{4}-\d{4}$ フリーダイヤル ^0120-\d{3}-\d{3}
OS間で気をつけるべき正規表現 - DTPab
【訂正 2018.9.4】 正規表現の書き間違いを訂正しました（赤字部分）。 今回はスクリプトからちょっと離れまして、正規表現のお話です。 僕の勤める会社では、Mac環境とWin環境の両方があり、OSを跨いで作業することもしばしばあります。そんなときに、用意した正規表現スタイルがMacでは適用されるのにWinでは適用されない（もしくはその逆）ということがありました。割と知られているとは思うのですが、注意喚起も含めてご報告です。 段落スタイルを作成し、ひとつめの正規表現スタイルに「U+2212のマイナス記号」と「U+301Cの波ダッシュ」の文字カラーをマゼンタにするもの、ふたつめに「U+FF0Dのマイナス記号」と「U+FF5Eの波ダッシュ」の文字カラーをシアンにするものを登録します。 これを実際に適用すると下図のようになります。 このように見た目はほとんど変わらない文字ですが、正規表現ではし
正規表現サンプル集
検索したい文字列 ※クリックで詳細説明に移動 正規表現 ※赤い字がメタ文字、グレーの「\」はエスケープのための「\」 bから始まってkで終わる3桁の文字列
正規表現：悪い表現、いい表現、最良の表現 | POSTD
わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず
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\
99%のEmailアドレスにマッチする正規表現公開される | ソフトアンテナ
一見Emailアドレスにマッチする正規表現を組み立てるのは簡単そうに思えますが、RFC 5322に厳密に準拠した正規表現を創りだそうとするととんでも無い努力が必要となるようです。 「Email Address Regular Expression That 99.9% Works」は、様々なプログラミング言語ごとに、Emailアドレスに99%マッチする正規表現を掲載したサイトで、例えばPerl 5.10より前のバージョンのPerl用として、掲載されている長大な正規表現を見れば、その難易度の高さを確認することができます。 正規表現にはなんの解説もなくどのような意図をもって作られたのか説明はありません(よって99%マッチするかどうかは本当のところは不明)。ちなみに日本語で読める貴重な情報「Perlメモ」では、「perl5.6.0以前の perl ではメールアドレスの正規表現を正確に記述すること
メールアドレスの正規表現 - tmtms のメモ
たまにメールアドレスの形式を正規表現で表すのは不可能とかというのを目にするのですが、そんなことはありません。入れ子がなければたいていの文字列の形式は正規表現で表すことができます。 ということで、RFC5321, 5322 からメールアドレスの正規表現を書いてみました。 /\A([0-9a-z!\#$%&'*+\-\/=?^_`{|}~]+(\.[0-9a-z!\#$%&'*+\-\/=?^_`{|}~]+)*|\"([\x20\x21\x23-\x5b\x5d-\x7e]|\\[\x20-\x7e])*\")@[0-9a-z]([0-9a-z-]*[0-9a-z])?(\.[0-9a-z]([0-9a-z-]*[0-9a-z])?)*\z/i ちょっと長いですけど、最近の Ruby だと (?<hoge>) と \g<hoge> を使うことで、同じ正規表現の繰り返しを簡単に書くことができる
正規表現の略記法 \X
あかね @akane_neko Unicodeのテキストをperlなどで正規表現で処理する場合任意の一文字は.でなく\Xを使うべきなんでしょか。つまりà（\x{0061}\x{0300}）みたいな文字とかIVSとかを考慮。(これは多分ものかの先生に聞くべき@monokano ) 2014-07-11 11:53:46 ものかの @monokano @akane_neko ぉぉぉ「\X」知らなかった！ 試してみると確かに結合文字も含んでちゃんとマッチしますね。 「Grapheme Cluster」のすべてにマッチするわけではなさそうですけど、ほとんど問題なさそう。これはイイ！ 2014-07-11 12:23:09
[連載:正規表現] Unicode文字プロパティについて(1)｜TechRacho by BPS株式会社
はじめまして、hachi8833です。 正規表現において、使わないまま死ぬのはあまりにもったいない「Unicode文字プロパティ」について解説します。これについてネット上にまとまった情報がほとんどなく、しかたがないので自分で書くことにしました。書きながら早くも記事があふれてきたので、見出しに「連載」の文字を追加などしてみました。たぶん他所ではほとんど見かけることのない連載になると思います。よろしくお願いします。 通常の開発においては、目的を達成する正規表現を作成してコードが動けば事足りるものであり、コーディング中に正規表現と延々付き合うことは普通ないでしょう。料理人は包丁を研ぐのに時間をかけすぎないものです。しかし特殊な業界の特殊な人々(日本に5人もいないと思います)は、来る日も来る日も正規表現を書き続けていたりするので、このUnicode文字プロパティは本当にありがたいものです。私の場合
![[連載:正規表現] Unicode文字プロパティについて(1)｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/72655c8f30cd51d00009f98fbad3338ce2b8a8d5/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2013%2F09%2FRegex.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
まだ正規表現で消耗してるの？
なるべく短い正規表現で住所を「都道府県/市区町村/それ以降」に分けるエクストリームスポーツ - Qiita
Regexper
正規表現入門 星の高さを求めて
TEST CORDING » Sassの@functionの使い方まとめ – プログラマブルな処理は@function
正規表現の先読み・後読みを極める！ - あらびき日記
Regex Crossword
