[過去ﾛｸﾞ] Regular Expression(正規表現) Part14 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
862(2): 2019/07/13(土)20:47 ID:57lWPs8z(1/3) AAS
動作についての質問です。よろしくお願いします。
●Regular Expressionの使用環境
JavaScript (chrome)
●検索か置換か？
検索
●説明
'@time;prop1:style1;prop2:style2'.match(/(^|[@;])[^@;]*/g); が
["", ";prop1:style1", ";prop2:style2"] になる理由が分かりません。私の理解では、
["", "@time",";prop1:style1", ";prop2:style2"] となって欲しいところです。
どなたか説明お願いします。
省10
863: 2019/07/13(土)23:13 ID:57lWPs8z(2/3) AAS
正規表現の問題ではなくJavaScript固有の問題のようなので、質問を閉じ、
JavaScriptスレにて質問し直します。
興味のある方は以下をご覧ください。(これからすぐ投稿します）
2chｽﾚ:tech
864: 2019/07/13(土)23:31 ID:57lWPs8z(3/3) AAS
すいません自己解決しましたが一応。以下となりました。
2chｽﾚ:tech
865(1): 2019/07/14(日)04:59 ID:XILHsvHP(1/3) AAS
この質問内容ならここで合ってます、jsスレよりもこのスレ向きです
正規表現には統一規格みたいなものは存在しないので環境によって動作が異なります
このスレの住民なら2番目のマッチが t から始まる環境も想定します
["","time", ";prop1:style1", ";prop2:style2"]
詳しい仕様を知らなくても動作を確認するコードを作っていろいろ試すと
どう動く環境なのかだいたい分かってしまうことが多いです
866(1): 2019/07/14(日)08:17 ID:LdVrbIxu(1/6) AAS
>>865
> 正規表現には統一規格みたいなものは存在しないので環境によって動作が異なります
これは知ってますがBREの範囲だと当然間違いなく動くし、
ほぼPCREに向けて統一中、といったところなのでは？
まあやたら複雑になってバックトラッキング等の問題が発生し、
結果的に速いライブラリに収束して行っているのはいいことだと思いますが。
> このスレの住民なら2番目のマッチが t から始まる環境も想定します
> ["","time", ";prop1:style1", ";prop2:style2"]
これは一応アウトなのでは？正規表現自体はデリミタごと取り込もうとしており、それが出来ていません。
これを言うならJavaScriptもアウトですが。
省8
867(2): 2019/07/14(日)10:58 ID:wR6d2dgQ(1/2) AAS
PCREに向けて統一中なんてどんな根拠で喋ってんだ
regex101で試してみれば分かるけどPCRE使ってるPHP以外のPython, ECMAScript, Goは全滅だぞ
868(1): 2019/07/14(日)12:13 ID:LdVrbIxu(2/6) AAS
>>867
ゴミという意味でだろ。
逆にお前はどう思ってるんだ？
JavaScriptのString.matchについては単にパッチを実装する場所を間違えただけ。
結果、String.match と RegExp.exec での結果が異なるという、言語内での不一致を引き起こしてる。
そしてこれはもう修正されることはない。
仕様バグとして永久に残り、プログラマに無駄な時間を消費させるだけのものとなる。
結果、言語が腐っていく。
正しくは RegExp.exec 側を修正し、両方とも無限ループにならずに
["", "@time",";prop1:style1", ";prop2:style2"]
省18
869(1): 2019/07/14(日)12:35 ID:QmWR+pGh(1) AAS
ゼロ幅で永久にマッチし続けるのになんで@timeに進めると思うの？
870: 2019/07/14(日)13:05 ID:LdVrbIxu(3/6) AAS
>>869
お前は実装と仕様の違いを理解出来てないタイプだな。
String.matchは「マッチ全部を配列で返す」メソッドだ。
当然、無限ループなんてしてはいけない。
(ただし無限ループしない為に空文字マッチだと一文字進めるパッチだから仕様バグになってるが）
RegExp.execは「gマッチを一つずつ実行し、ユーザーがそこで適宜処理を行う」為のメソッドだ。
当然、何もしなければ順に次のマッチをしていくのが正しく、今現在のように無限ループするようでは駄目だ。
結果、今はユーザーが本来不要なコードを毎回書く羽目になってる。
具体的に言えば、 if (match!=='') が毎回必要になる。これが無駄だ。
JavaScript界隈にはお前みたいな馬鹿が多い。
省7
871(2): 2019/07/14(日)13:21 ID:XILHsvHP(2/3) AAS
>>866
"t" からマッチは誤りでした、申し訳ない..
タグの外側だけ対象に置換する
外部ﾘﾝｸ[htm]:www.din.or.jp
この記事の動作のことを言いたかったんですがうろ覚えのまま
適当に書いてしまいました、ごめんなさい
872(2): 2019/07/14(日)13:28 ID:wR6d2dgQ(2/2) AAS
>>868
PCREに統一中だという主張の根拠を聞いたんだがそれへの回答はないわけだ
PCREが素晴らしい実装で最初に触っとけばいいというのは同意するが, それが最良だなんてのはあり得ないし単なる妄想だよ
873(1): 2019/07/14(日)14:15 ID:LdVrbIxu(4/6) AAS
>>871
ああなるほど、Perlも似たようなゴミ実装になってるな。
> そこで，Perl では空文字列に マッチするような場合には，初回は空文字列がマッチするがそれ以降は マッチせずに必ず 1文字分は進むようにマッチしようとする．
これも実装ミスだな。
正しくは、このフラグを「空文字以外のマッチごとにセット」すればいいだけで、修正は1行で済むのだが、こちらも今更なのだろう。
「初回は」というのが間違いで、「空文字にマッチした直後は」が正しい。
ついでにもっと具体的に言っておくと、「初回は」というのが正しければ、
今の実装は検索起動時にフラグをセットして空文字マッチ後にリセットしているはず。
このフラグを「空文字以外のマッチ後」に毎回セットし直すように1行入れる。これで直る。
君がPERL等のOSSか何かにcontributeする気があって修正案を出してくるのなら見てあげるけど。
省14
874(1): 2019/07/14(日)15:13 ID:LdVrbIxu(5/6) AAS
>>867
今更regex101で確認してみたが、PCREだけは（これに関しては）正しく通るじゃねえかよ。
Perlの「初回は」というのはつまり g の時だけおかしくなるということであり、今回は当たらないからだが。
だからJavaScriptも仮にPerl実装互換にしようとしたとしてもしくってるな。
>>871
ちなみに
> > と < は後読みと先読みにして外に出すことができるので
の意味分かる？
おそらくはバックトラックを小さくする為（つまり高速化）だと思うのだが、
実際 regex101で試す限り余計に遅くなる。
省4
875(1): 2019/07/14(日)15:29 ID:XILHsvHP(3/3) AAS
>>874
> > と < は後読みと先読みにして外に出すことができるので
これは文字を消費しないための措置
マッチさせたい部分以外の部分にまでマッチしてしまうと次回の
検索開始位置が意図しないところに進んでしまったりするので先読みを
使って消費しないようにします
あとあなたが言ってることにはおおむね同意です
変な挙動は無くなるといいですね、perl6に期待したいところだけど
perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
自分にとっては処理が重くなるのであまり嬉しくないですね..
876: 2019/07/14(日)16:03 ID:LdVrbIxu(6/6) AAS
>>875
ああなるほど、\G使ってるからずれるのか、確かに。
BRE出身だから個人的には最初から />[^<]*</ が第一選択肢で、
筆者の発想が意味不明だったのだが、確かにそうだな。
ここら辺は正規表現だけで何とか出来る(Perl)思想と、
BREだけではどうにもならないからざっくり切り出して自前でプログラミングする(AWK)思想の違いだな。
Perl6はガン無視されてる感があるけどね。
今更Perlで組めるかよ、というのはPerlを使っている奴自身が感じていることらしいし。
（もっとも嫌われてる言語がPerl、2017はダントツの一位、
しかし同じStackOverflow実施の2018の結果はVBでperlは落ち着いたようだが)
省8
877(2): 2019/07/15(月)15:22 ID:y88H95dP(1) AAS
Ruby で、
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
省2
878: 2019/07/15(月)16:42 ID:xqOJLOC2(1) AAS
>>877
テストしてくれたって事か？なら一応まとめておく。
/(^|[@;])[^@;]*/g に対してテスト文字列 '@time;prop1:style1;prop2:style2' で
PCRE: ["", "@time",";prop1:style1", ";prop2:style2"]
JavaScript, Python, Go, Ruby, : ["",";prop1:style1", ";prop2:style2"]
結論、PCRE以外全部ゴミ
現時点でPCREが最良だ馬鹿タレ >>872
お前が何派か知らんが、PCREが最良でないと言い張るのなら少なくとも通るライブラリを具体的に提示しろ
ただまあこれにはちょっと情状酌量の余地有りで、
おそらく ^ が「先頭文字」ではなく「位置」にマッチすると再定義したのはPerlだ。
省12
879(1): 2019/07/15(月)23:23 ID:3MPTmFRg(1) AAS
BREの正規表現と今の正規表現の使い方の違いの話は面白いなぁ
しかしこの人こんなにすごいスキルとモチベがあるなら質問なんかせずに
自力でなんとか出来たのではｗ
質問してくれたおかげで面白い話をいろいろ聞けたからこちらは嬉しいけどネ
おかしな挙動と言えばperl5とOnigmoでは\Gの挙動に違いが
あってどちらかが違和感のある動作をしたはず
\Gの概念自体が微妙に違ったはずだけどメモるの忘れた
興味のある人はぐぐってね
880: 2019/07/16(火)15:24 ID:wQsYVdH6(1) AAS
ネット弁慶がイキりたかっただけでしょ
881(1): 2019/07/16(火)16:08 ID:cpfSTA9t(1) AAS
>JavaScript, Python, Go, Ruby, : ["",";prop1:style1", ";prop2:style2"]
深くて理解できないことが多いが、これはやばい気がする
882: 2019/07/16(火)17:23 ID:hAAouWtx(1/2) AAS
読んでるだけで何も考えてなかったけど
/(^|[@;])[^@;]*/g
この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？
883: 2019/07/16(火)18:30 ID:AvaVqNzm(1) AAS
一所懸命挑発的に書いてるのに全然乗ってもらえなくてかわいそう
884: 2019/07/16(火)19:27 ID:hAAouWtx(2/2) AAS
言ってることに説得力がありすぎて聞き入ってしまってたよ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ
885(1): 2019/07/16(火)20:41 ID:bFMew56o(1) AAS
入力フォーマットが正しいという前提で /@?[^@;]+/ の方が好み
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ
886: 2019/07/16(火)21:03 ID:hMJFhr7R(1/2) AAS
>>881
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。
例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。
省14
887(1): 2019/07/16(火)21:18 ID:hMJFhr7R(2/2) AAS
>>879
BREの場合はやりきる前提ではないので、例えば例のタグ外側マッチだと、
元の文字列に > と < を足してしまって置換し、出力時に削る、みたいなことをする。
具体的には以下。
('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)
だからBREしか使えないAWKでも意外と何とかなったりする。
ただしこれはプログラミング出来る前提であって、
Webページに検索窓だけ提供されているような状態ではどうにもならないが。
>>885
それは正しい。実際俺もそれに近いことをしている。
省7
888: 2019/07/16(火)22:42 ID:P37s1FHo(1) AAS
一度言った内容は繰り返さなくていいです
889(1): 2019/07/17(水)08:28 ID:2/Bgill9(1/5) AAS
>>873訂正
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)
Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<) に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
省11
890: 2019/07/17(水)08:28 ID:2/Bgill9(2/5) AAS
正しい実装は、「経路全体」（つまりツリーのリーフ）に対してフラグを持たないといけない。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。
実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
省11
891: 2019/07/17(水)08:29 ID:2/Bgill9(3/5) AAS
なおPerlの実装だと『上位関数のみ』で対策できるため、
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。
いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。
892(1): 2019/07/17(水)09:46 ID:u050lnGw(1/3) AAS
話を単純化すると、
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する
つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う
(^|[@;])[^@;]*
だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！
OR の部分が、並列ではない。
省1
893(1): 892 2019/07/17(水)09:51 ID:u050lnGw(2/3) AAS
(^|[@;])[^@;]*
OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！
A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！
894(1): 2019/07/17(水)09:53 ID:RL7WDafS(1/2) AAS
左側優先とかないのかこれ？
895(2): 877 2019/07/17(水)10:06 ID:u050lnGw(3/3) AAS
>>889
Ruby で、
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
省6
896(1): 2019/07/17(水)13:38 ID:FD/sfaX1(1) AAS
小飼って糖尿病で死んだんだっけ
897(1): 2019/07/17(水)14:01 ID:fOq5lc1d(1) AAS
質問させてください。
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？
898: 2019/07/17(水)15:07 ID:Jmalh7Yl(1) AAS
>>887
>('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)
おぉ、perlの正規表現なら正規表現だけで大抵のことは出来るから
自分には前処理をするという発想がなかった、目からうろこでした
今回のケースもこの方法でデータの前後に ; を付ければ簡単になりましたね
>>897
\w が あ にマッチするくらいなので仕様なのでは
オプションでマッチしなくしたり出来るのでオプションのヘルプを見ましょう
899(1): 2019/07/17(水)20:30 ID:2/Bgill9(4/5) AAS
>>894
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。
900: 2019/07/17(水)20:37 ID:RL7WDafS(2/2) AAS
>>899
ちょっと知識が深まったよ サンクス
901: 2019/07/17(水)20:40 ID:2/Bgill9(5/5) AAS
>>895
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。
+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
省16
902(2): 2019/07/18(木)16:11 ID:Y8yxmCyC(1/2) AAS
今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
予測が難しいところがあるのでは
バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ
あとrubyの正規表現エンジンは空文字マッチが〜の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな
903: 2019/07/18(木)20:03 ID:PnG1z3PK(1/4) AAS
>>902
Ruby周りにはお前みたいなクズしかいないから駄目なんだよ。
プログラミング出来ないのなら黙ってろ。
今のお前が為すべきは、お前が持っているonigmo環境で該当パターンを試し、結果を共有することだ。
Rubyの評判を気にすることではない。
Ruby+onigmoの組み合わせでばっちり動くのなら、
「他環境はゴミです！みなさんの悩みはRubyで解決出来ます！この機会に乗り換えてください！」と言えばいいだけだ。
動くんじゃないかな、みたいなお前の希望的観測なんて何の役にも立たない。
或いは、onigmo単独では動くがRubyのバグ互換モードでは動かない、というのが事実なら、
「Rubyは次のメジャーアップデートでここが対策されます！みなさんご期待ください！」
省15
904(1): 2019/07/18(木)20:22 ID:Y8yxmCyC(2/2) AAS
BREという超シンプルな正規表現エンジンが持っていた明解な動作の分かりやすさを
現代の超複雑な正規表現エンジンに求めることには無理がある
ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう
ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない
時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
省1
905: 2019/07/18(木)20:44 ID:PnG1z3PK(2/4) AAS
>>902
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。
> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
省14
906: 2019/07/18(木)20:46 ID:PnG1z3PK(3/4) AAS
> バグと言えばバグだけど
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
省13
907(1): 2019/07/18(木)21:56 ID:xdHI+pcE(1) AAS
荒らしと会話するな！
荒らしと会話する者も、荒らしだぞ！
プログラマーとは、コードで語る者だけ！
能書きはいらない！
そいつらは荒らしだから、会話するな！
908: 2019/07/18(木)22:31 ID:PnG1z3PK(4/4) AAS
>>907
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。
というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。
俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。
onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
省5
909(2): 2019/07/19(金)00:09 ID:KcCrOwH9(1) AAS
PCREに非包含オペレータが搭載されたら起こしてくれ
910(1): 2019/07/19(金)00:50 ID:CNkXpMDT(1/3) AAS
>>909
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。
ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> 外部ﾘﾝｸ:qiita.com
これって何？知ってたら教えてくれれば助かる。
911: 2019/07/19(金)02:29 ID:CNkXpMDT(2/3) AAS
>>909
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。
> 外部ﾘﾝｸ[pdf]:staff.aist.go.jp
省2
912(1): 2019/07/19(金)03:16 ID:CNkXpMDT(3/3) AAS
>>910
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
外部ﾘﾝｸ:kkos.hatenadiary.org
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。
ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。
913: 2019/07/19(金)11:33 ID:bgAzEf51(1) AAS
このスレでコミュニティうんぬんは脱線しすぎじゃないかい。スレタイとなんも関係ないやろ。
914: 2019/07/20(土)15:46 ID:KXtQuYxh(1) AAS
本当にプログラマなのかな
915(3): 2019/07/20(土)17:29 ID:AFOF1ubv(1/4) AAS
JSです
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？
/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？
916(1): 915 2019/07/20(土)17:31 ID:AFOF1ubv(2/4) AAS
>>915
例を全部2文字にしちゃいましたが、 .+ と書いているとおり別に文字数は関係ありません
917: 915 2019/07/20(土)17:37 ID:AFOF1ubv(3/4) AAS
>>915
そして度々すみませんが /「(.+)+」/ じゃなくて /「(.+)」+/ でした
とりあえずこれはダメな例ということで
いい例が知りたいです
918(1): 2019/07/20(土)17:45 ID:kkJ7q95a(1) AAS
>>915-916
外部ﾘﾝｸ:qiita.com
919: 2019/07/20(土)20:12 ID:AFOF1ubv(4/4) AAS
>>918
3つ目の
# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">
ですね、ありがとうございます…！
920(1): 2019/07/21(日)20:31 ID:Bdf0kkIf(1) AAS
>>912
外部ﾘﾝｸ:kkos.hatenadiary.org
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？
rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？
まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。
現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。
921: 2019/07/22(月)01:27 ID:dN38X5eV(1) AAS
>>920
おおサンクス。
ただ、それって 2007/05/25 より後だから、別件だね。
無駄に喧嘩してるなあ。
内容はkkos氏の方が正しい。
鬼車は最速を目指したライブラリなのだから、無駄なことは出来る限り省かなければならない。
そもそもスクリプト言語で不完全な文字列って、バイト列を直接与えるとかしないと出来ないはずだし、
その場合にはRuby側でチェックしておけ、というのはその通りで、極めて妥当な要求だ。
Rubyなんてmutable stringなのだから最初に必ずコピーが必要で、普通はその時にやればいいだけ。
その方が今時の型安全にも合うし。
省19
922: 2019/08/01(木)15:57 ID:BVNOJ7mG(1) AAS
>>789やってくれる人はいないか〜
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな
onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ
923: 2019/08/24(土)12:41 ID:fR0bFJ1E(1) AAS
perlで
(?<=(aa|bb))c
ならokだが
(?<=(aa|bbb))c
だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん
省1
924: 2019/08/24(土)13:46 ID:6nD2xE5w(1) AAS
(?<=(aa.*|bbb))c
925: 2019/08/25(日)15:17 ID:GRZE+Rz9(1) AAS
(?<=aa|bbb)c
926(1): 2019/09/01(日)12:33 ID:fodjUzDJ(1/2) AAS
JS（ES2017）です
「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい この場合は「貫」だけ残して「樣」は消したい）
のですが
CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？
927(1): 926 2019/09/01(日)12:38 ID:fodjUzDJ(2/2) AAS
「樣」は一応日本語でも使うみたいですね…
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？
928(1): 2019/09/01(日)13:31 ID:kCJZVLuH(1/2) AAS
外部ﾘﾝｸ[htm]:www.shuiren.org
929(1): 2019/09/01(日)13:35 ID:kCJZVLuH(2/2) AAS
ねむい
画像ﾘﾝｸ[gif]:kanji.zinbun.kyoto-u.ac.jp
外部ﾘﾝｸ[html]:kanji.zinbun.kyoto-u.ac.jp
930: 2019/09/01(日)18:46 ID:VXfAHt8z(1) AAS
>>927
樣は様の旧字で現在でも許容字体扱いだから「常用漢字表」にも
出て来る。
外部ﾘﾝｸ:ja.wikipedia.org
>928-929みたいなのはあくまでコンピューター用のコードの
まとまりの話だから常用漢字か否かは区別していない。
上のリンクのウィキの本表をエクセルにコピーして２列目の
通用字体だけを残して改行を消してやり、それと平仮名や
記号を除外規定にして残り全部消すとかなら正規表現だけでも
さっさと終わるんじゃないかな。
省3
931(1): 2019/09/01(日)21:04 ID:fO6VcsLE(1) AAS
Google謹製の正規表現ライブリ「re2」でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？
932: 2019/09/01(日)22:01 ID:Zrnas7uJ(1) AAS
>>931
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/
933: 2019/09/01(日)22:50 ID:8GDP8quV(1) AAS
RE2 regex とか RE2 正規表現 とかでググれば
934(1): 2019/09/10(火)22:48 ID:CokwQGf+(1) AAS
直前の文字が1回以上出現することが確実なケースで、仮に0回の出現として考慮しても問題がないという場合に、
+ではなく*で正規表現を記述する理由はありますか？
例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう
935: 2019/09/10(火)23:21 ID:1dbF51qB(1) AAS
0回も許容するなら+ではなく*にする理由は0回も許容するからとしか
936: 2019/09/10(火)23:26 ID:L5QX1JAH(1) AAS
具体例で示してくれんとなんか曖昧でよくわからんね
937: 2019/09/11(水)12:05 ID:zFEVPQj4(1) AAS
>1回以上出現することが確実なケース
>仮に0回の出現として考慮しても問題がない
矛盾してるな
938: 2019/09/11(水)15:12 ID:wb8QVF41(1) AAS
>>934
出現が確実ではあるが、もしなかった場合にも対応したい
そういう要求があり、動作にも差し支えない場合なら * をつかう
ということに尽きるでは？
939: 2019/09/11(水)16:12 ID:h8Pfy2ne(1) AAS
>>762
940: 2019/09/12(木)02:26 ID:xpiKRNxb(1/3) AAS
やっぱ質問して放置か、教える側も学習すべきだな
まともな質問じゃないと思ったらスルーでいい
941: 2019/09/12(木)04:33 ID:+6m2JHnd(1) AAS
別におかしな質問じゃないだろ
942: 2019/09/12(木)06:58 ID:1ik9S0iw(1) AAS
いや普通におかしいだろ
なんか無理矢理の条件考えて論争させようとしてるような気がする
943: 2019/09/12(木)08:21 ID:xpiKRNxb(2/3) AAS
自分なら人にこういう質問レスを書くかなって考えてみて絶対書かないと
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも
944: 2019/09/12(木)09:22 ID:TOasMGF3(1/4) AAS
●Regular Expressionの使用環境
Mery
●検索か置換か？
置換
●説明
属性内のアルファベット小文字を削除
●対象データ
id="105I42b 104I41b"
id="99E65e 95B43d 92B87d"
id="97B22d 95D18a 93B22c 93E23b"
省5
945: 2019/09/12(木)10:00 ID:bJPykHLq(1/4) AAS
わかりやすいように、できるだけそのまま書くならこうかな
●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]
●置換文字列
\1\2
946(1): 2019/09/12(木)10:04 ID:bJPykHLq(2/4) AAS
置換に問題は無いけど()が二重になってたミス修正
(id="|\G )(\d+[A-Z]\d+)[a-z]
947: 2019/09/12(木)10:30 ID:TOasMGF3(2/4) AAS
>946
出来ました！
ありがとうございます。
田中哲スペシャルっていうやり方なのでしょうか
948(1): 2019/09/12(木)11:08 ID:bJPykHLq(3/4) AAS
\Gは照合開始位置と呼ばれる物で、マッチした箇所の後の境界にマッチしてくれるので
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番
田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな
949(1): 2019/09/12(木)11:58 ID:TOasMGF3(3/4) AAS
>948
勉強になります。
ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"
対応策ありますでしょうか？
950(1): 2019/09/12(木)12:04 ID:xpiKRNxb(3/3) AAS
自分ならこの時点でスルー
\Gは文頭にもマッチするから誤爆対策を忘れずに
951(1): 2019/09/12(木)15:04 ID:bJPykHLq(4/4) AAS
>>949
自分でも書けない訳じゃないみたいだし、魚を与えるより釣り方を教えよの精神でヒント
変更のない置換後でも\Gは引っかかるので、小文字がないidも全部マッチするようにすれば
こういうのを後出しされるとお互い二度手間だから
質問するときはパターンを網羅的に書いといた方が良いよ
あと>>950が指摘してくれたように誤爆が懸念されるので、\Gを\G(?<=.)にした方が良いかもしれない
●対象データが正確で、実際の対象もidのみが載ったリスト形式みたいなものなら要らないけど
952: 2019/09/12(木)18:04 ID:TOasMGF3(4/4) AAS
>951
ヒントありがとうございます。
残りは自分でがんばってみます。
953: 2019/09/12(木)18:08 ID:EfYu2rO4(1) AAS
文字列 "プログラマー" を "プロクライマー" に書き換える正規表現を教えて下さい
954: 2019/09/12(木)21:50 ID:Jdu1U3XN(1) AAS
そこにソースがあるから登るんだ。
955: 2019/09/12(木)22:19 ID:cqw0/uFd(1) AAS
正規表現の使い方じゃなく作り方、バックトラックなど理論から解説している書籍やそれに準ずるサイトなど知っていたらご教示ください。
こうやればこうなるよ、こういうときはこうすればいいんだよ的な学習では身に付かなくて…
956: 2019/09/12(木)22:56 ID:Yy9Clfy1(1/2) AAS
自分が参考にしたのはここだったかな
外部ﾘﾝｸ[htm]:fussy.web.fc2.com
実装の仕方がある程度分かれば鬼車の作者さんのブログ(rubyの一件以前の記事)も参考になると思う
957: 2019/09/12(木)23:14 ID:Uy9QyXie(1) AAS
ありがとうございます！
rubyの一件って何ですか？（何て検索したらいいですか？）
958(1): 2019/09/12(木)23:43 ID:Yy9Clfy1(2/2) AAS
Rubyの作者さんと何かあったようで嫌気が差したのかそれ以後ブログで正規表現のことを
取り上げる頻度がめっきり減っちゃったんですよ
959: 2019/09/13(金)08:32 ID:sQZEDK+j(1) AAS
>>958
ありがとうございます！
なるほど、残念ですね…
960: 2019/09/13(金)10:47 ID:wKEqF87n(1) AAS
955
外部ﾘﾝｸ:codezine.jp
外部ﾘﾝｸ:tociyuki.hatenablog.jp
外部ﾘﾝｸ:hellocode.jugem.jp
961: 2019/09/13(金)11:54 ID:X5DxpBbM(1) AAS
正規表現はどの言語でも共通で使えますか？それともちょっと違ったりしますか？
上下前次1-新書関写板覧索設栞歴
あと 41 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s