Regular Expression(正規表現) Part14 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/03/15(水) 02:04:35.47

Regular Expressionスレです。

質問する場合は必ず実装言語や処理系ソフトウェア名を示してください。

前スレ
Regular Expression(正規表現) Part13
http://echo.2ch.net/test/read.cgi/tech/1415149975/

次スレは>>980宜しく
天ぷら等2以降

**デフォルトの名無しさん** · 2019/06/24(月) 23:17:52.70

そういえばブラウザに NG word に指定したのは自分だった
あらしが記号を使ってたことがあったので

**デフォルトの名無しさん** · 2019/06/25(火) 07:18:11.77

荒らしが記号を使うことと書き込みを制限することに全く関連が無い

**デフォルトの名無しさん** · 2019/06/25(火) 08:36:20.64

https://i.imgur.com/QA0OVK8.jpg

こう見えていたんだ
左がわひどいねごめんね

**デフォルトの名無しさん** · 2019/07/08(月) 00:38:09.05

●Regular Expressionの使用環境
サクラエディタ(か秀丸エディタ)

●検索か置換か？
置換

●説明
不定回数のパターンを置換したい。

●対象データ
[A=a,A=b,A=c,A=d,・・・・]
・・・・の部分はどこまで続くのかは決まってない。が、多くても20個くらい

●希望する結果
A=a,b,c,d・・・・

**デフォルトの名無しさん** · 2019/07/08(月) 05:29:01.40

(?<!^)A=

**854** · 2019/07/08(月) 23:27:17.45

>>855
ありがとうございます。
否定戻り読みってこうやって使うのですね。

もうちょっと深掘りして以下の場合どのようになるでしょう。
■対象データ
[A=a OR A=b OR A=c OR A=d・・・・]
[B=d OR B=c OR B=b OR B=a・・・・]
[C=a OR C=b OR C=c OR C=d・・・・]

■希望結果
A=a,b,c,d
B=d,c,b,a
C=a,b,c,d

ORの部分が難しくて混乱しています。。

**デフォルトの名無しさん** · 2019/07/10(水) 08:43:33.27

\s++OR\s++.=
,

**デフォルトの名無しさん** · 2019/07/10(水) 09:18:54.80

ここの住民の正規表現能力は超人的だ
お節介させてくれ
もし使用環境に perl があれば、
ウルトラ難しい正規表現を理解可能な小さなパーツに分類できる

cat /dev/clipboard
[A=a OR A=b OR A=c OR A=d・・・・]
[B=d OR B=c OR B=b OR B=a・・・・]
[C=a OR C=b OR C=c OR C=d・・・・]

cat /dev/clipboard | perl -ne 'if ( m{^ \[ ( \w+ [=] ) }xcm) {print $1}; { if ( m{ = (\w+) \s }xcg ) {print "$1,"; redo} if ( m{ = (\w+) \S }xc ) {print "$1\n"} }'
A=a,b,c,d
B=d,c,b,a
C=a,b,c,d

**デフォルトの名無しさん** · 2019/07/10(水) 09:35:40.67

そして同じような形を処理するのに
必要な正規表現が大きく変わったりしない

cat /dev/clipboard
[A=a,A=b,A=c,A=d,A=e,A=f,A=g,A=h,A=i,A=j]

cat /dev/clipboard | perl -ne 'if ( m{^ \[ ( \w+ [=] ) }xcm) {print $1}; { if ( m{ = ( \w+ [,] ) }cxg ) {print "$1"; redo} if ( m{ = (\w+) [^,] }xc ) {print "$1\n"} }'
A=a,b,c,d,e,f,g,h,i,j

**854** · 2019/07/11(木) 01:01:12.77

>>857
すごい。。
置換できましたありがとうございます。

が、情けない話ですがなぜこういう置換結果になるのかが理解できません。
良ければどなたか解説いただけないでしょうか

>>858
ほんと、超人的ですね。。

Perlでのご教授ありがとうございます。
1度組んでしまえば汎用的に使えそうですね。

**デフォルトの名無しさん** · 2019/07/11(木) 21:00:44.92

>>860
https://github.com/k-takata/Onigmo/blob/master/doc/RE.ja

**デフォルトの名無しさん** · 2019/07/13(土) 20:47:25.54

動作についての質問です。よろしくお願いします。

●Regular Expressionの使用環境
JavaScript (chrome)

●検索か置換か？
検索

●説明
'@time;prop1:style1;prop2:style2'.match(/(^|[@;])[^@;]*/g);　が
["", ";prop1:style1", ";prop2:style2"]　になる理由が分かりません。私の理解では、
["", "@time",";prop1:style1", ";prop2:style2"]　となって欲しいところです。
どなたか説明お願いします。
^は文字列検索位置を「動かさない」と認識しています。
（以前は「動かす」と誤認識していましたが、何かで見解を改められたことを記憶しています）

●対象データ
ID@time;style　形式の指定で、
ID、time、styleの省略は全てありで、timeとstyleの順序は自由(IDは必ず先頭）
@開始はtime指定、それ以外はstyle指定とし、デリミタは ; としています。
この形式で任意の文字列（ユーザー入力）を処理します。
なお、'@time;prop1:style1;prop2:style2'.match(/(^.|[@;])[^@;]*/g);　では希望の解
["@time", ";prop1:style1", ";prop2:style2"]　を得られていますが、
デバッグ中に上記に引っかかったので、分かりましたらよろしくお願いいたします。

**デフォルトの名無しさん** · 2019/07/13(土) 23:13:26.72

正規表現の問題ではなくJavaScript固有の問題のようなので、質問を閉じ、
JavaScriptスレにて質問し直します。
興味のある方は以下をご覧ください。(これからすぐ投稿します）
https://mevius.5ch.net/test/read.cgi/tech/1417749547/341-

**デフォルトの名無しさん** · 2019/07/13(土) 23:31:59.74

すいません自己解決しましたが一応。以下となりました。
https://mevius.5ch.net/test/read.cgi/tech/1417749547/341-342

**デフォルトの名無しさん** · 2019/07/14(日) 04:59:50.53

この質問内容ならここで合ってます、jsスレよりもこのスレ向きです
正規表現には統一規格みたいなものは存在しないので環境によって動作が異なります

このスレの住民なら2番目のマッチが t から始まる環境も想定します
["","time", ";prop1:style1", ";prop2:style2"]

詳しい仕様を知らなくても動作を確認するコードを作っていろいろ試すと
どう動く環境なのかだいたい分かってしまうことが多いです

**デフォルトの名無しさん** · 2019/07/14(日) 08:17:29.28

>>865
> 正規表現には統一規格みたいなものは存在しないので環境によって動作が異なります
これは知ってますがBREの範囲だと当然間違いなく動くし、
ほぼPCREに向けて統一中、といったところなのでは？
まあやたら複雑になってバックトラッキング等の問題が発生し、
結果的に速いライブラリに収束して行っているのはいいことだと思いますが。

> このスレの住民なら2番目のマッチが t から始まる環境も想定します
> ["","time", ";prop1:style1", ";prop2:style2"]
これは一応アウトなのでは？正規表現自体はデリミタごと取り込もうとしており、それが出来ていません。
これを言うならJavaScriptもアウトですが。

個人的にはJavaScriptは面白いのですが仕様がイマイチなところが散見されるのが難点ですね。
それが初心者に無用な混乱を引き起こし、上達の妨げになっている。
今回私も数時間無駄にしましたが、これが初心者だと脱出出来なくて誤解したままになってしまう。
そして本人はそれを自覚出来ず、Web上に間違った情報を垂れ流し、馬鹿が再生産されるというループになっている。

この意味では正規表現の現在の状況も同じようなものですが、
正規表現は「実装の幅がものすごくある」と共有されているだけまだましです。
JavaScriptの連中はその間違った実装を「正しい」と思いこんでいたりするので、会話が成立しません。
といってもJavaScriptのString.matchの仕様バグを今更直すことも出来ず、未来永劫このままだと思いますが。

**デフォルトの名無しさん** · 2019/07/14(日) 10:58:08.46

PCREに向けて統一中なんてどんな根拠で喋ってんだ
regex101で試してみれば分かるけどPCRE使ってるPHP以外のPython, ECMAScript, Goは全滅だぞ

**デフォルトの名無しさん** · 2019/07/14(日) 12:13:01.78

>>867
ゴミという意味でだろ。
逆にお前はどう思ってるんだ？

JavaScriptのString.matchについては単にパッチを実装する場所を間違えただけ。
結果、String.match と RegExp.exec での結果が異なるという、言語内での不一致を引き起こしてる。
そしてこれはもう修正されることはない。
仕様バグとして永久に残り、プログラマに無駄な時間を消費させるだけのものとなる。
結果、言語が腐っていく。

正しくは RegExp.exec 側を修正し、両方とも無限ループにならずに
["", "@time",";prop1:style1", ";prop2:style2"]
を返すべきだった。
RegExp.lastIndex だけで状態管理出来ると「間違えた」からそうなった。
本来は先頭マッチフラグ RegExp.canMatchHead みたいなのが必要で、それを実装すれば両方とも正しい結果を返せた。
それを実装せず、String.match に間違ったパッチを当てたからそうなった。
これは実装者（おそらくブレンダンアイク本人)の判断ミスだ。

正規表現はPerlが再定義したと言っていい状況だ。だからみんなPCREを見てる。
PHPはさっさと取り込んだ。これは正しい判断だ。
JavaScriptはPCREを見てる。というか本来は取り込みたいのだろうが、上記のように今更部分がありすぎる。
Pythonには歴史的経緯があるのだろう、状況は知らん。
Goは最初から既にゴミだ。確実に廃れるだろうし、俺もそれを願っている。
そもそもGoなんてPCREが覇権取ったあとに出てきたのにPCREを採用してない時点でゴミ。
それ以外にもあの言語は独自路線を行き過ぎていて、ユーザーに無駄な勉強時間を強いている。
結果、既に他言語で慣らした強者が近づかず、結果的に馬鹿の楽園になってWeb系の馬鹿共に大受けしてるだけ。
Goの正規表現については詳しくは知らんが、仮にそれが奇妙な振る舞いをしたとして、お前はGo側の怠慢だと思わないのか？
JavaScriptやPython等それなりの歴史があるのならともかく、Goの場合は確実に防げた問題でしかない。
連中はそれを「わざと」やらなかったんだぞ。俺はそんな言語は支持しないし、ゴミだと何度でも断言する。

いずれにしても、今からの初心者が学ぶべきはPCREだろ。
お前は何が言いたいんだ？

**デフォルトの名無しさん** · 2019/07/14(日) 12:35:52.54

ゼロ幅で永久にマッチし続けるのになんで@timeに進めると思うの？

**デフォルトの名無しさん** · 2019/07/14(日) 13:05:26.62

>>869
お前は実装と仕様の違いを理解出来てないタイプだな。

String.matchは「マッチ全部を配列で返す」メソッドだ。
当然、無限ループなんてしてはいけない。
(ただし無限ループしない為に空文字マッチだと一文字進めるパッチだから仕様バグになってるが）

RegExp.execは「gマッチを一つずつ実行し、ユーザーがそこで適宜処理を行う」為のメソッドだ。
当然、何もしなければ順に次のマッチをしていくのが正しく、今現在のように無限ループするようでは駄目だ。
結果、今はユーザーが本来不要なコードを毎回書く羽目になってる。
具体的に言えば、 if (match!=='') が毎回必要になる。これが無駄だ。

JavaScript界隈にはお前みたいな馬鹿が多い。
本来はどうあるべきか、或いは何故この無駄なコードが必要なのか分からず、
今の「実装」が正しいと思いこんでいるタイプだ。
動かさないと分からない、あるいは動いていればいい程度のコードしか書けないからだが。
とはいえ、今回のようなケースに遭遇するとそうなるのも分かる気はするが。

いずれにしても、これはJavaScript環境固有の問題で、ここでは割とどうでもいいと思うが。
お前が正規表現として /(^|[@;])[^@;]*/g を書いたとき、全ての環境で無限ループするべきだ！と思っているのならそれでいいが、
実際はそうではないだろ？なら無駄にいちゃもんつけるなよ。

**デフォルトの名無しさん** · 2019/07/14(日) 13:21:26.40

>>866
"t" からマッチは誤りでした、申し訳ない..

タグの外側だけ対象に置換する
http://www.din.or.jp/~ohzaki/regex.htm#ReplaceOutside

この記事の動作のことを言いたかったんですがうろ覚えのまま
適当に書いてしまいました、ごめんなさい

**デフォルトの名無しさん** · 2019/07/14(日) 13:28:58.74

>>868
PCREに統一中だという主張の根拠を聞いたんだがそれへの回答はないわけだ
PCREが素晴らしい実装で最初に触っとけばいいというのは同意するが, それが最良だなんてのはあり得ないし単なる妄想だよ

**デフォルトの名無しさん** · 2019/07/14(日) 14:15:14.24

>>871
ああなるほど、Perlも似たようなゴミ実装になってるな。

> そこで，Perl では空文字列にマッチするような場合には，初回は空文字列がマッチするがそれ以降はマッチせずに必ず 1文字分は進むようにマッチしようとする．
これも実装ミスだな。
正しくは、このフラグを「空文字以外のマッチごとにセット」すればいいだけで、修正は1行で済むのだが、こちらも今更なのだろう。
「初回は」というのが間違いで、「空文字にマッチした直後は」が正しい。
ついでにもっと具体的に言っておくと、「初回は」というのが正しければ、
今の実装は検索起動時にフラグをセットして空文字マッチ後にリセットしているはず。
このフラグを「空文字以外のマッチ後」に毎回セットし直すように1行入れる。これで直る。
君がPERL等のOSSか何かにcontributeする気があって修正案を出してくるのなら見てあげるけど。
(俺自身ではそこまでやる気はない)

まあしかし、JavaScriptだけがゴミじゃない、ってのは分かった。
というかもしかしてJavaScriptの実装ってPERL実装互換に敢えてしてる？

>>872
お前は何派なんだよ？
JavaScriptに関してはMDNでも前は「PCREで大体使えます」みたいな事書いてたぞ。
最近大幅リニューアルしてその記述はなくなったが。
(というより色々見にくくなってあまり確認してない）

鬼車派ならこの手の「実装ミス」をひたすら潰しておけばワンチャンあるかもしれんよ。
JavaScriptにしてもPerlにしてもこの辺のミスは確実に足枷になってる。
具体的に言うと遭遇した全プログラマが数時間ずつ無駄に検索その他をさせられる羽目になってる。
これは「新規プログラマ」からすると上達を妨げる障壁でしかない。
JavaScriptで言うと「IEデハー」な件を全部暗記してて今もそれにすがっている奴のウザさみたいなもんだ。
仕様バグがない、というのはそれなりに武器になる。

**デフォルトの名無しさん** · 2019/07/14(日) 15:13:19.95

>>867
今更regex101で確認してみたが、PCREだけは（これに関しては）正しく通るじゃねえかよ。

Perlの「初回は」というのはつまり g の時だけおかしくなるということであり、今回は当たらないからだが。
だからJavaScriptも仮にPerl実装互換にしようとしたとしてもしくってるな。

>>871
ちなみに
> > と < は後読みと先読みにして外に出すことができるので
の意味分かる？
おそらくはバックトラックを小さくする為（つまり高速化）だと思うのだが、
実際 regex101で試す限り余計に遅くなる。
テストサンプルはそこの下の「XMLタグを加工する」の上側半分のxmlで、こちらだと
(?:^|>)(.*?)(?:$|<) の場合は　29matches, 1277steps だが
(?:^|(?<=>))(.*?)(?:$|(?=<))　の場合は 29matches, 1875stepsで、余計に遅くなってる。
格好良くはないが別に $1$2$3 で置換しても問題ないと思うのだが。

**デフォルトの名無しさん** · 2019/07/14(日) 15:29:05.53

>>874
> > と < は後読みと先読みにして外に出すことができるので

これは文字を消費しないための措置
マッチさせたい部分以外の部分にまでマッチしてしまうと次回の
検索開始位置が意図しないところに進んでしまったりするので先読みを
使って消費しないようにします

あとあなたが言ってることにはおおむね同意です
変な挙動は無くなるといいですね、perl6に期待したいところだけど
perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
自分にとっては処理が重くなるのであまり嬉しくないですね..

**デフォルトの名無しさん** · 2019/07/14(日) 16:03:14.68

>>875
ああなるほど、\G使ってるからずれるのか、確かに。

BRE出身だから個人的には最初から　/>[^<]*</ が第一選択肢で、
筆者の発想が意味不明だったのだが、確かにそうだな。
ここら辺は正規表現だけで何とか出来る(Perl)思想と、
BREだけではどうにもならないからざっくり切り出して自前でプログラミングする(AWK)思想の違いだな。

Perl6はガン無視されてる感があるけどね。
今更Perlで組めるかよ、というのはPerlを使っている奴自身が感じていることらしいし。
（もっとも嫌われてる言語がPerl、2017はダントツの一位、
しかし同じStackOverflow実施の2018の結果はVBでperlは落ち着いたようだが)
https://stackoverflow.blog/2017/10/31/disliked-programming-languages/
https://news.mynavi.jp/article/20180604-639227/
もしかしてPerl6って徐々に使われだしてる？

> perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
ん？
全てのプログラミング言語では最長マッチがデフォ、
というかそもそも下位の正規表現(BRE等）にはそれしかないが。(non-greedyがない）
XPATH等の文書検索側の人かな？だからって別に特に問題はないが。

**デフォルトの名無しさん** · 2019/07/15(月) 15:22:14.71

Ruby で、

str = "@time;prop1:style1;prop2:style2"

re = /((^|[@;])[^@;]*)/

p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]

[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分

>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果

**デフォルトの名無しさん** · 2019/07/15(月) 16:42:33.19

>>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だ。
そもそもBREには　| がない。従って (^| のような「先頭の空文字」マッチなんて書けない。
だからBREだと先頭の「位置」なのか「文字」なのかを厳密に区別する必要がない。
| が導入されたのはEREからだが、EREなんて大して使われてない。
結果、BRE育ちの連中が「位置」だと厳密に認識せずにコーディングすると間違える、というわけ。
そしてJavaScript, Python, Go, Ruby は全滅だ。

JavaScriptに関してはPerlを模倣したわけでもなく、単なるミスだ。言語内不一致を生じているし。
他言語は知らん。

Rubyみたいに「実装が仕様だボケ」と言い張る糞言語ではこの手の仕様バグを永久に修正出来ない。
よって新人は毛嫌いして離れていく。当たり前の話だ。
JavaScriptはおそらくバグだと認識されているが、今更直せない。
Perl6はこの点、仕様と実装を分離したから、バージョンアップと共に確実に修正する。
従って最良は現時点でもPCREだし、今後ともPCREだ馬鹿タレ >>872

**デフォルトの名無しさん** · 2019/07/15(月) 23:23:32.64

BREの正規表現と今の正規表現の使い方の違いの話は面白いなぁ

しかしこの人こんなにすごいスキルとモチベがあるなら質問なんかせずに
自力でなんとか出来たのではｗ
質問してくれたおかげで面白い話をいろいろ聞けたからこちらは嬉しいけどネ

おかしな挙動と言えばperl5とOnigmoでは\Gの挙動に違いが
あってどちらかが違和感のある動作をしたはず
\Gの概念自体が微妙に違ったはずだけどメモるの忘れた
興味のある人はぐぐってね

**デフォルトの名無しさん** · 2019/07/16(火) 15:24:59.03

ネット弁慶がイキりたかっただけでしょ

**デフォルトの名無しさん** · 2019/07/16(火) 16:08:47.84

>JavaScript, Python, Go, Ruby, : ["",";prop1:style1", ";prop2:style2"]
深くて理解できないことが多いが、これはやばい気がする

**デフォルトの名無しさん** · 2019/07/16(火) 17:23:30.54

読んでるだけで何も考えてなかったけど

/(^|[@;])[^@;]*/g

この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？

**デフォルトの名無しさん** · 2019/07/16(火) 18:30:33.69

一所懸命挑発的に書いてるのに全然乗ってもらえなくてかわいそう

**デフォルトの名無しさん** · 2019/07/16(火) 19:27:45.24

言ってることに説得力がありすぎて聞き入ってしまってたよ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ

**デフォルトの名無しさん** · 2019/07/16(火) 20:41:55.62

入力フォーマットが正しいという前提で /@?[^@;]+/ の方が好み
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ

**デフォルトの名無しさん** · 2019/07/16(火) 21:03:17.33

>>881
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。

例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。

JavaScriptの場合はatomエディターなる物があって、htmlやプログラムソースコードを編集出来るが、
JavaScriptの場合はreplaceもバグっているので、命中すれば、全置換しても全置換出来てないケースが発生する。
リファクタ等で変数名を変えるとき、手でやるとバグるので、当然エディタ機能で全置換させるわけだが、この場合にもバグる訳だ。
そしてユーザーはこのときに置換漏れが発生するとは全く思わないので、かなり手間取ることになる。
(atomでは対策されていると信じたい)

JavaScriptの場合はこのバグも「仕様」としてしまっているので、
逆に言えば仕様通りならバグに命中したときの挙動も確定してる。だから対策は出来るが、
Rubyみたいに「実装が仕様だ」と言い張る糞言語だとどういう挙動か確認してみなければ分からず、対策が出来ない。
ここらへんもRubyの思想は数周遅れている。

いずれにしてもこんな基本的なところのバグはあっても迷惑でしかなく、さっさと直せ、でしかない。
「速い」以前に「ヒットしない」エンジンなんて使い物にならないだろ。
エンジン競争しているつもりの馬鹿共も、方向性を完全に間違ってる。
「間違いなく動作する」エンジンを提供すれば、文書検索側の人間はサクッと乗り換えてくれるだろうさ。
速い遅いはその後の話だ。

**デフォルトの名無しさん** · 2019/07/16(火) 21:18:41.35

>>879
BREの場合はやりきる前提ではないので、例えば例のタグ外側マッチだと、
元の文字列に > と < を足してしまって置換し、出力時に削る、みたいなことをする。
具体的には以下。

('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)

だからBREしか使えないAWKでも意外と何とかなったりする。
ただしこれはプログラミング出来る前提であって、
Webページに検索窓だけ提供されているような状態ではどうにもならないが。

>>885
それは正しい。実際俺もそれに近いことをしている。
デリミタが最初に出現もあり、最後に付加もあり、つまり
';prop:style1' や
'prop:style1;prop:style2;' もありなので、
結局 /(^|[@;])[^@;]*/g だと後のコードが綺麗に書けなかった。　/(^.|[@;])[^@;]*/g でも同じ。
意味的には @ もデリミタ扱いしているだけなので、実もフタもないが、@を ;@にしてsplitした。
具体的には以下。
str.replace(/@/g,';@').split(';').filter(v=>v)

**デフォルトの名無しさん** · 2019/07/16(火) 22:42:20.32

一度言った内容は繰り返さなくていいです

**デフォルトの名無しさん** · 2019/07/17(水) 08:28:41.50

>>873訂正
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)

Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<)　に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
その筆者の説明通り先頭タグを含んで次タグ或いは文末まで伸びることになる。

俺のケースでは、正規表現 (^|[@;])[^@;]* に対して、
1回目：(^|[@;])[^@;]*
2回目：(^|[@;])[^@;]+
だから '@time;prop1:style1;prop2:style2' に対して @time のマッチも正しく取れることになる。

こういった場合、実装者は安全側に倒したくなる物だが、
現実は安全側に倒しすぎて余分なケースを含んでしまい、結果、バグっているというわけだ。
JavaScriptは最高に安全な実装、「空文字マッチは1文字進める」とした。（おそらくRubyその他もそう）
これだと絶対に無限ループはしないが、俺のケースでバグる。
Perlの実装だと俺のケースは通るが、871内URLの筆者のケースでバグる。
その他バグケースも出してくれれば俺の推測で合っているかどうかは答える。

**デフォルトの名無しさん** · 2019/07/17(水) 08:28:59.00

正しい実装は、「経路全体」（つまりツリーのリーフ）に対してフラグを持たないといけない。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。

実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
ただしこれはリターンパスを辿ればいいので何らかのツールが有ればほぼ自動でいけるかもしれない。
次に上記リストを作成する為に全経路を出力させなければならない。
デバッグ用にこれが既にあればラッキーだが、なければ自前で作らなければいけない。
といっても内容はツリーのノードを辿るだけなので、ツリーのフォーマットが分かればすぐだが、
ゴリゴリに高速化とかしていると割と意味不明なコードになっていることが多いので、
その状態で確認するのは結構辛いとは思う。
リストの管理は、空文字マッチなら追記、非空文字マッチならクリア、なので、これはやるだけだ。
リストの管理も探索関数にやらせて、探索関数は
今：マッチ場所とマッチ長さを返す
修正後：マッチ場所とマッチ長さを含んだ『配列』を返す、とし、
「空文字マッチの場合は自動で継続、非空文字マッチまたは終了まで探索、まとめて配列で結果を返す」とするのがいいだろう。

**デフォルトの名無しさん** · 2019/07/17(水) 08:29:16.56

なおPerlの実装だと『上位関数のみ』で対策できるため、
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。

いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。

**デフォルトの名無しさん** · 2019/07/17(水) 09:46:24.93

話を単純化すると、
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する

つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う

(^|[@;])[^@;]*

だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！

OR の部分が、並列ではない。
ルール1を優先すべき！

**892** · 2019/07/17(水) 09:51:38.77

(^|[@;])[^@;]*

OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！

A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！

**デフォルトの名無しさん** · 2019/07/17(水) 09:53:34.46

左側優先とかないのかこれ？

**877** · 2019/07/17(水) 10:06:18.04

>>889
Ruby で、

str = "@time;prop1:style1;prop2:style2"

re = /((^|[@;])[^@;]*)/

p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]

[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分

>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果

# * を、+ に変えた。
re_2 = /((^|[@;])[^@;]+)/

p results_2 = str.scan( re_2 )
# [["@time", "@"], [";prop1:style1", ";"], [";prop2:style2", ";"]]

**デフォルトの名無しさん** · 2019/07/17(水) 13:38:56.68

小飼って糖尿病で死んだんだっけ

**デフォルトの名無しさん** · 2019/07/17(水) 14:01:11.32

質問させてください。
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？

**デフォルトの名無しさん** · 2019/07/17(水) 15:07:35.98

>>887
>('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)

おぉ、perlの正規表現なら正規表現だけで大抵のことは出来るから
自分には前処理をするという発想がなかった、目からうろこでした

今回のケースもこの方法でデータの前後に ; を付ければ簡単になりましたね

>>897
\w　が　あ　にマッチするくらいなので仕様なのでは
オプションでマッチしなくしたり出来るのでオプションのヘルプを見ましょう

**デフォルトの名無しさん** · 2019/07/17(水) 20:30:56.60

>>894
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。

**デフォルトの名無しさん** · 2019/07/17(水) 20:37:09.24

>>899
ちょっと知識が深まったよ　サンクス

**デフォルトの名無しさん** · 2019/07/17(水) 20:40:11.08

>>895
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。

+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
JavaScriptは少なくとも仕様に明記はしてる。
ただそれだと弱いからMDNにも書け、というのが俺の主張であり、JavaScriptスレに勝手に依頼しておいた。
以前RegExp.testの件で同様に依頼したら追記されたから、そうなるのを願っている。
そういう、「落とし穴」は共同して塞いでいかないと駄目なんだよ。

完璧な言語なんてない。だから多少バグがあるのは仕方ないとして、
それを未来永劫新規プログラマに押しつけて「キャハハー、お前も落ちたか！」なんてやっているようでは駄目なんだ。
Rubyはプログラマに対してリスペクトが全くない。だから廃れるし、俺もそうなることを願っている。
お前はRubyを吹聴しさえすれば布教出来ると勘違いしているようだが、そんなことはない。
当たり前だが新人にとってはこんなバグにつき合わされること自体大迷惑でしかないんだよ。
今回のでもPCREが一番ましだし、Rubyなんて選ばれる理由がないだろ。
ゴミだと分かっているものを広めるのは、単なる詐欺師でしかないぞ。
お前はお前の行為によってRubyへの反感を得ているだけなことを自覚した方がいい。
あちこちのスレでお前は相当ウザがられてる。

そういうのではなくて、バグを修正するとか、仕様書に明記するとか、
何でそういう建設的な方向に努力出来ないんだ？
こういう地道な積み重ねを全くやってないからRubyの現状はあるわけでさ。

**デフォルトの名無しさん** · 2019/07/18(木) 16:11:19.79

今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
予測が難しいところがあるのでは

バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ

あとrubyの正規表現エンジンは空文字マッチが～の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな

**デフォルトの名無しさん** · 2019/07/18(木) 20:03:10.71

>>902
Ruby周りにはお前みたいなクズしかいないから駄目なんだよ。
プログラミング出来ないのなら黙ってろ。

今のお前が為すべきは、お前が持っているonigmo環境で該当パターンを試し、結果を共有することだ。
Rubyの評判を気にすることではない。

Ruby+onigmoの組み合わせでばっちり動くのなら、
「他環境はゴミです！みなさんの悩みはRubyで解決出来ます！この機会に乗り換えてください！」と言えばいいだけだ。
動くんじゃないかな、みたいなお前の希望的観測なんて何の役にも立たない。

或いは、onigmo単独では動くがRubyのバグ互換モードでは動かない、というのが事実なら、
「Rubyは次のメジャーアップデートでここが対策されます！みなさんご期待ください！」
と言えばいいだけだ。
実際、正規表現の方言/バグに参っている連中はいるんだから、それで乗り換えてくれるだろうさ。

実際、Rubyの奴らはこういう事を全くしない。
そしてRubyの評判だけを気にしているからRubyはゴミのままなんだよ。

871の件、Perl5.6だがPCREもか？と思って試したが、PCREもだ。
そしてPCREには
> using the same syntax and semantics as Perl 5.
と書いてある。つまりこれが本当ならPerl5のバグも含めて挙動は同一、ということになる。
しかしバグまで含めて同一とするにはPerlがこれを仕様化していないとほぼあり得ない。
そこでPerlを確認してみたが、どうやら以下がそれらしい。
> Repeated Patterns Matching a Zero-length Substring
> https://perldoc.perl.org/perlre.html
グダグダ説明はしてあるがPerlは読めんから詳細まで俺の読み通りかは分からんが。
いずれにしても、JavaScriptとPerlは仕様化してる。
Rubyが仕様化しておらず、これが大問題だと認識出来ないのは、Ruby界隈にはまともなプログラマがいないからだよ。

**デフォルトの名無しさん** · 2019/07/18(木) 20:22:20.04

BREという超シンプルな正規表現エンジンが持っていた明解な動作の分かりやすさを
現代の超複雑な正規表現エンジンに求めることには無理がある

ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう

ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない

時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
しかもたった数例のコードの動作を見ただけでだ、あほらしい

**デフォルトの名無しさん** · 2019/07/18(木) 20:44:40.06

>>902
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。

> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
スクリプタがやってる、今書いて今動いたら捨てておｋ、なんて甘い世界ではない。

まともなコードなら未来永劫整備可能だし、また、それを目指しているのがプログラマだ。
実際、Linuxなんて30年越しで整備され続けてるだろ。
数年前にお前が書いたコードすら読めないのは、お前の問題であって、それを全体のように言うな。
だからスクリプタは馬鹿にされるし、嫌われるんだよ。

正規表現エンジンなんてプログラミング全体からするとかなり簡単な部類だ。
動けばいいだけのエンジンなら再帰しまくりで1000行程度だろう。
最悪全交換でいい規模だから、そこまでガチで整備されている事は期待出来ないが、
それにしてもこの程度の規模のプログラムを読めない、ってことはあり得ない。
高速化はプログラムに対して「複雑度」を増すものではない。
具体的に言うと、静的コールグラフを複雑化することはなく、
単に遅い関数を速い関数に入れ替える、というのが基本になる。
だから、正規表現エンジンを読めない、というのなら、書いた奴か読む奴が馬鹿なだけであって、
ちゃんとした奴が書いたエンジンをちゃんとした奴が読めば確実に読める。

**デフォルトの名無しさん** · 2019/07/18(木) 20:46:26.35

> バグと言えばバグだけど
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
Rubyの現状はバグに気づいてないか、敢えて黙っているかで、どちらにしても糞でしかない。

> つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
> 対応してると記憶してるから
お前がどんだけ馬鹿なのか分からないが、「バグ」ってのは意図してない動作のことを言うんだぞ。
つまり、対応してるつもりが対応できてないから「バグ」なんだよ。
> rubyモードの仕様なんじゃないかな
そう言うのはちゃんと調べてから言え。希望的観測ではミスリードを大量発生させる。
そしてこれをやりまくっているのがJavaScript界隈で、結果、JavaScripterは馬鹿が再生産されまくってる。
そういうのは止めろ。お互いに得る物がない。

>>904
まあ書いた後に読んだから投稿はしておいた。
話すつもりがないのならさようならでいい。
お前は、自身の問題を認識出来てないタイプだ。まあこのタイプもよくいるが。

**デフォルトの名無しさん** · 2019/07/18(木) 21:56:03.46

荒らしと会話するな！
荒らしと会話する者も、荒らしだぞ！

プログラマーとは、コードで語る者だけ！
能書きはいらない！

そいつらは荒らしだから、会話するな！

**デフォルトの名無しさん** · 2019/07/18(木) 22:31:51.56

>>907
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。

というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。

俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。

onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
どっちでもないってのは、俺には頭おかしいとしか思えないけどな。

まあ確実に言えるのは、Rubyを今から学ぶのは止めとけ、ってことだ。
Rubyはコミュニティの腐り方がどうも他とは違う。
(JavaScriptも腐ってはいるが、あれは「若すぎる」のが原因だ。
かといって放置しても自然に改善するものでもないが）

**デフォルトの名無しさん** · 2019/07/19(金) 00:09:18.78

PCREに非包含オペレータが搭載されたら起こしてくれ

**デフォルトの名無しさん** · 2019/07/19(金) 00:50:19.02

>>909
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。

ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> https://qiita.com/k-takata/items/4e45121081c83d3d5bfd
これって何？知ってたら教えてくれれば助かる。

**デフォルトの名無しさん** · 2019/07/19(金) 02:29:00.41

>>909
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。

> https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf
つまり理論畑の人には問題があるが、プログラミング上問題はないんだろ。
そりゃ入れないだろ。

**デフォルトの名無しさん** · 2019/07/19(金) 03:16:00.34

>>910
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
https://kkos.hatenadiary.org/entries/2007/05/25#1180100250
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。

ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。

**デフォルトの名無しさん** · 2019/07/19(金) 11:33:59.54

このスレでコミュニティうんぬんは脱線しすぎじゃないかい。スレタイとなんも関係ないやろ。

**デフォルトの名無しさん** · 2019/07/20(土) 15:46:35.52

本当にプログラマなのかな

**デフォルトの名無しさん** · 2019/07/20(土) 17:29:27.69

JSです
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？

/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？

**915** · 2019/07/20(土) 17:31:58.05

>>915
例を全部2文字にしちゃいましたが、　.+　と書いているとおり別に文字数は関係ありません

**915** · 2019/07/20(土) 17:37:46.94

>>915
そして度々すみませんが　/「(.+)+」/　じゃなくて　/「(.+)」+/　でした
とりあえずこれはダメな例ということで
いい例が知りたいです

**デフォルトの名無しさん** · 2019/07/20(土) 17:45:51.81

>>915-916
https://qiita.com/y-ken/items/7d5bf086be68d23e1318

**デフォルトの名無しさん** · 2019/07/20(土) 20:12:32.11

>>918
3つ目の

# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">

ですね、ありがとうございます…！

**デフォルトの名無しさん** · 2019/07/21(日) 20:31:55.31

>>912
ttps://kkos.hatenadiary.org/entry/20070906/1189084566
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？

rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？

まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。

現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。

**デフォルトの名無しさん** · 2019/07/22(月) 01:27:11.95

>>920
おおサンクス。
ただ、それって 2007/05/25 より後だから、別件だね。
無駄に喧嘩してるなあ。

内容はkkos氏の方が正しい。
鬼車は最速を目指したライブラリなのだから、無駄なことは出来る限り省かなければならない。
そもそもスクリプト言語で不完全な文字列って、バイト列を直接与えるとかしないと出来ないはずだし、
その場合にはRuby側でチェックしておけ、というのはその通りで、極めて妥当な要求だ。
Rubyなんてmutable stringなのだから最初に必ずコピーが必要で、普通はその時にやればいいだけ。
その方が今時の型安全にも合うし。

それを「実は僕も問題だと思ってたんだよね」みたいな受け方をするからそりゃ不信感が募る。
これは完全にMatzが糞で、実はC流のグダグダコードを書いていて、
どこで何をするべきか分かってないのだと思う。
そしてRuby界隈ではMatzは変に神格化されてて裸の王様化してる、ってとこだろう。
878の動作結果を見ても、誰も問題だとは指摘出来ないようだし。

これはkkos氏が言っているとおりがそのままで、普通は、というか本当は、
1. Rubyは rb_enc_mbclen(p,end,enc) で記述していたが、
2. 鬼車が rb_enc_mbclen(p,enc) で記述されていることに気づき、
3. 何で end が無いのか確認して、
4. Ruby側にチェックをつける
という流れになる。
1が無いのに、「し、知ってたし」みたいなことを言うから「嘘つくな」になる。
つってもこういうちょっとズルいというか卑怯というか、絶対俺のバグは認めないマンは残念ながら普通にいるから、
いちいち問いただしても始まらない。ただ、多分、kkos氏が切れたのはその後、
> それはそれとして、鬼車を呼ぶ前に「一文字を完成していない不完全なバイト列は含まない」ことをチェックするのはかなりコストが高いのですが、
これだとは思う。鬼車側でチェックしたらコストが安い訳でもないのに、これはない。
これはコイツとは一緒にはやれない、という結論を出すには十分だ。
本来Aでやるべき事をBでやる、みたいなことをすると、コードが一気に劣化していく。
長いこと保守するつもりなら絶対に飲めない。実際、鬼車は今も保守されているし、kkos氏の判断は妥当だ。

**デフォルトの名無しさん** · 2019/08/01(木) 15:57:12.21

>>789やってくれる人はいないか～
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな

onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ

**デフォルトの名無しさん** · 2019/08/24(土) 12:41:17.80

perlで

(?<=(aa|bb))c

ならokだが

(?<=(aa|bbb))c

だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん

秀丸のHmJre.dllだと通るようだ

**デフォルトの名無しさん** · 2019/08/24(土) 13:46:10.60

(?<=(aa.*|bbb))c

**デフォルトの名無しさん** · 2019/08/25(日) 15:17:23.04

(?<=aa|bbb)c

**デフォルトの名無しさん** · 2019/09/01(日) 12:33:19.59

JS（ES2017）です

「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい　この場合は「貫」だけ残して「樣」は消したい）
のですが

CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？

**926** · 2019/09/01(日) 12:38:35.03

「樣」は一応日本語でも使うみたいですね…
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？

**デフォルトの名無しさん** · 2019/09/01(日) 13:31:25.10

http://www.shuiren.org/chuden/teach/code/main8.htm

**デフォルトの名無しさん** · 2019/09/01(日) 13:35:35.35

ねむい
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK/gb2312-80.gif
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html

**デフォルトの名無しさん** · 2019/09/01(日) 18:46:39.31

>>927
樣は様の旧字で現在でも許容字体扱いだから「常用漢字表」にも
出て来る。
https://ja.wikipedia.org/wiki/%E5%B8%B8%E7%94%A8%E6%BC%A2%E5%AD%97%E4%B8%80%E8%A6%A7

>928-929みたいなのはあくまでコンピューター用のコードの
まとまりの話だから常用漢字か否かは区別していない。

上のリンクのウィキの本表をエクセルにコピーして２列目の
通用字体だけを残して改行を消してやり、それと平仮名や
記号を除外規定にして残り全部消すとかなら正規表現だけでも
さっさと終わるんじゃないかな。

JISの範囲内だけがほしいならシフトJISで保存したら他は
疑問符になるだろうからそれをまとめて削除したらおしまいだろうが
繁体字の樣は残る。簡体字の[木羊]は消える。

**デフォルトの名無しさん** · 2019/09/01(日) 21:04:09.80

Google謹製の正規表現ライブリ「re2」でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？

**デフォルトの名無しさん** · 2019/09/01(日) 22:01:25.54

>>931
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/

**デフォルトの名無しさん** · 2019/09/01(日) 22:50:02.12

RE2 regex とか RE2 正規表現とかでググれば

**デフォルトの名無しさん** · 2019/09/10(火) 22:48:57.92

直前の文字が1回以上出現することが確実なケースで、仮に0回の出現として考慮しても問題がないという場合に、
+ではなく*で正規表現を記述する理由はありますか？

例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう

**デフォルトの名無しさん** · 2019/09/10(火) 23:21:08.02

0回も許容するなら+ではなく*にする理由は0回も許容するからとしか

**デフォルトの名無しさん** · 2019/09/10(火) 23:26:41.78

具体例で示してくれんとなんか曖昧でよくわからんね

**デフォルトの名無しさん** · 2019/09/11(水) 12:05:55.89

>1回以上出現することが確実なケース

>仮に0回の出現として考慮しても問題がない

矛盾してるな

**デフォルトの名無しさん** · 2019/09/11(水) 15:12:05.49

>>934
出現が確実ではあるが、もしなかった場合にも対応したい
そういう要求があり、動作にも差し支えない場合なら * をつかう
ということに尽きるでは？

**デフォルトの名無しさん** · 2019/09/11(水) 16:12:55.15

>>762

**デフォルトの名無しさん** · 2019/09/12(木) 02:26:26.53

やっぱ質問して放置か、教える側も学習すべきだな
まともな質問じゃないと思ったらスルーでいい

**デフォルトの名無しさん** · 2019/09/12(木) 04:33:29.68

別におかしな質問じゃないだろ

**デフォルトの名無しさん** · 2019/09/12(木) 06:58:37.97

いや普通におかしいだろ
なんか無理矢理の条件考えて論争させようとしてるような気がする

**デフォルトの名無しさん** · 2019/09/12(木) 08:21:20.40

自分なら人にこういう質問レスを書くかなって考えてみて絶対書かないと
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも

**デフォルトの名無しさん** · 2019/09/12(木) 09:22:01.93

●Regular Expressionの使用環境
Mery

●検索か置換か？
置換

●説明
属性内のアルファベット小文字を削除

●対象データ
id="105I42b 104I41b"
id="99E65e 95B43d 92B87d"
id="97B22d 95D18a 93B22c 93E23b"

●希望する結果
id="105I42 104I41"
id="99E65 95B43 92B87"
id="97B22 95D18 93B22 93E23"

id="((\d+[A-Z]\d+)[a-z] ?){2,}"で検索は出来たのですが置換が思い浮かびません

**デフォルトの名無しさん** · 2019/09/12(木) 10:00:21.41

わかりやすいように、できるだけそのまま書くならこうかな

●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]

●置換文字列
\1\2

**デフォルトの名無しさん** · 2019/09/12(木) 10:04:35.65

置換に問題は無いけど()が二重になってたミス修正
(id="|\G )(\d+[A-Z]\d+)[a-z]

**デフォルトの名無しさん** · 2019/09/12(木) 10:30:50.86

>946
出来ました！
ありがとうございます。

田中哲スペシャルっていうやり方なのでしょうか

**デフォルトの名無しさん** · 2019/09/12(木) 11:08:37.62

\Gは照合開始位置と呼ばれる物で、マッチした箇所の後の境界にマッチしてくれるので
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番

田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな

**デフォルトの名無しさん** · 2019/09/12(木) 11:58:31.87

>948

勉強になります。

ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"

対応策ありますでしょうか？

**デフォルトの名無しさん** · 2019/09/12(木) 12:04:38.94

自分ならこの時点でスルー
\Gは文頭にもマッチするから誤爆対策を忘れずに

**デフォルトの名無しさん** · 2019/09/12(木) 15:04:33.55

>>949
自分でも書けない訳じゃないみたいだし、魚を与えるより釣り方を教えよの精神でヒント
変更のない置換後でも\Gは引っかかるので、小文字がないidも全部マッチするようにすれば

こういうのを後出しされるとお互い二度手間だから
質問するときはパターンを網羅的に書いといた方が良いよ

あと>>950が指摘してくれたように誤爆が懸念されるので、\Gを\G(?<=.)にした方が良いかもしれない
●対象データが正確で、実際の対象もidのみが載ったリスト形式みたいなものなら要らないけど