Regular Expressionスレです。
質問する場合は必ず実装言語や処理系ソフトウェア名を示してください。
前スレ
Regular Expression(正規表現) Part13
http://echo.2ch.net/test/read.cgi/tech/1415149975/
次スレは>>980宜しく
天ぷら等2以降
Regular Expression(正規表現) Part14 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
1デフォルトの名無しさん
2017/03/15(水) 02:04:35.47ID:e01p03UP868デフォルトの名無しさん
2019/07/14(日) 12:13:01.78ID:LdVrbIxu >>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だろ。
お前は何が言いたいんだ？
ゴミという意味でだろ。
逆にお前はどう思ってるんだ？
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だろ。
お前は何が言いたいんだ？
869デフォルトの名無しさん
2019/07/14(日) 12:35:52.54ID:QmWR+pGh ゼロ幅で永久にマッチし続けるのになんで@timeに進めると思うの？
870デフォルトの名無しさん
2019/07/14(日) 13:05:26.62ID:LdVrbIxu >>869
お前は実装と仕様の違いを理解出来てないタイプだな。
String.matchは「マッチ全部を配列で返す」メソッドだ。
当然、無限ループなんてしてはいけない。
(ただし無限ループしない為に空文字マッチだと一文字進めるパッチだから仕様バグになってるが）
RegExp.execは「gマッチを一つずつ実行し、ユーザーがそこで適宜処理を行う」為のメソッドだ。
当然、何もしなければ順に次のマッチをしていくのが正しく、今現在のように無限ループするようでは駄目だ。
結果、今はユーザーが本来不要なコードを毎回書く羽目になってる。
具体的に言えば、 if (match!=='') が毎回必要になる。これが無駄だ。
JavaScript界隈にはお前みたいな馬鹿が多い。
本来はどうあるべきか、或いは何故この無駄なコードが必要なのか分からず、
今の「実装」が正しいと思いこんでいるタイプだ。
動かさないと分からない、あるいは動いていればいい程度のコードしか書けないからだが。
とはいえ、今回のようなケースに遭遇するとそうなるのも分かる気はするが。
いずれにしても、これはJavaScript環境固有の問題で、ここでは割とどうでもいいと思うが。
お前が正規表現として /(^|[@;])[^@;]*/g を書いたとき、全ての環境で無限ループするべきだ！と思っているのならそれでいいが、
実際はそうではないだろ？なら無駄にいちゃもんつけるなよ。
お前は実装と仕様の違いを理解出来てないタイプだな。
String.matchは「マッチ全部を配列で返す」メソッドだ。
当然、無限ループなんてしてはいけない。
(ただし無限ループしない為に空文字マッチだと一文字進めるパッチだから仕様バグになってるが）
RegExp.execは「gマッチを一つずつ実行し、ユーザーがそこで適宜処理を行う」為のメソッドだ。
当然、何もしなければ順に次のマッチをしていくのが正しく、今現在のように無限ループするようでは駄目だ。
結果、今はユーザーが本来不要なコードを毎回書く羽目になってる。
具体的に言えば、 if (match!=='') が毎回必要になる。これが無駄だ。
JavaScript界隈にはお前みたいな馬鹿が多い。
本来はどうあるべきか、或いは何故この無駄なコードが必要なのか分からず、
今の「実装」が正しいと思いこんでいるタイプだ。
動かさないと分からない、あるいは動いていればいい程度のコードしか書けないからだが。
とはいえ、今回のようなケースに遭遇するとそうなるのも分かる気はするが。
いずれにしても、これはJavaScript環境固有の問題で、ここでは割とどうでもいいと思うが。
お前が正規表現として /(^|[@;])[^@;]*/g を書いたとき、全ての環境で無限ループするべきだ！と思っているのならそれでいいが、
実際はそうではないだろ？なら無駄にいちゃもんつけるなよ。
871デフォルトの名無しさん
2019/07/14(日) 13:21:26.40ID:XILHsvHP >>866
"t" からマッチは誤りでした、申し訳ない..
タグの外側だけ対象に置換する
http://www.din.or.jp/~ohzaki/regex.htm#ReplaceOutside
この記事の動作のことを言いたかったんですがうろ覚えのまま
適当に書いてしまいました、ごめんなさい
"t" からマッチは誤りでした、申し訳ない..
タグの外側だけ対象に置換する
http://www.din.or.jp/~ohzaki/regex.htm#ReplaceOutside
この記事の動作のことを言いたかったんですがうろ覚えのまま
適当に書いてしまいました、ごめんなさい
872デフォルトの名無しさん
2019/07/14(日) 13:28:58.74ID:wR6d2dgQ >>868
PCREに統一中だという主張の根拠を聞いたんだがそれへの回答はないわけだ
PCREが素晴らしい実装で最初に触っとけばいいというのは同意するが, それが最良だなんてのはあり得ないし単なる妄想だよ
PCREに統一中だという主張の根拠を聞いたんだがそれへの回答はないわけだ
PCREが素晴らしい実装で最初に触っとけばいいというのは同意するが, それが最良だなんてのはあり得ないし単なる妄想だよ
873デフォルトの名無しさん
2019/07/14(日) 14:15:14.24ID:LdVrbIxu >>871
ああなるほど、Perlも似たようなゴミ実装になってるな。
> そこで，Perl では空文字列に マッチするような場合には，初回は空文字列がマッチするがそれ以降は マッチせずに必ず 1文字分は進むようにマッチしようとする．
これも実装ミスだな。
正しくは、このフラグを「空文字以外のマッチごとにセット」すればいいだけで、修正は1行で済むのだが、こちらも今更なのだろう。
「初回は」というのが間違いで、「空文字にマッチした直後は」が正しい。
ついでにもっと具体的に言っておくと、「初回は」というのが正しければ、
今の実装は検索起動時にフラグをセットして空文字マッチ後にリセットしているはず。
このフラグを「空文字以外のマッチ後」に毎回セットし直すように1行入れる。これで直る。
君がPERL等のOSSか何かにcontributeする気があって修正案を出してくるのなら見てあげるけど。
(俺自身ではそこまでやる気はない)
まあしかし、JavaScriptだけがゴミじゃない、ってのは分かった。
というかもしかしてJavaScriptの実装ってPERL実装互換に敢えてしてる？
>>872
お前は何派なんだよ？
JavaScriptに関してはMDNでも前は「PCREで大体使えます」みたいな事書いてたぞ。
最近大幅リニューアルしてその記述はなくなったが。
(というより色々見にくくなってあまり確認してない）
鬼車派ならこの手の「実装ミス」をひたすら潰しておけばワンチャンあるかもしれんよ。
JavaScriptにしてもPerlにしてもこの辺のミスは確実に足枷になってる。
具体的に言うと遭遇した全プログラマが数時間ずつ無駄に検索その他をさせられる羽目になってる。
これは「新規プログラマ」からすると上達を妨げる障壁でしかない。
JavaScriptで言うと「IEデハー」な件を全部暗記してて今もそれにすがっている奴のウザさみたいなもんだ。
仕様バグがない、というのはそれなりに武器になる。
ああなるほど、Perlも似たようなゴミ実装になってるな。
> そこで，Perl では空文字列に マッチするような場合には，初回は空文字列がマッチするがそれ以降は マッチせずに必ず 1文字分は進むようにマッチしようとする．
これも実装ミスだな。
正しくは、このフラグを「空文字以外のマッチごとにセット」すればいいだけで、修正は1行で済むのだが、こちらも今更なのだろう。
「初回は」というのが間違いで、「空文字にマッチした直後は」が正しい。
ついでにもっと具体的に言っておくと、「初回は」というのが正しければ、
今の実装は検索起動時にフラグをセットして空文字マッチ後にリセットしているはず。
このフラグを「空文字以外のマッチ後」に毎回セットし直すように1行入れる。これで直る。
君がPERL等のOSSか何かにcontributeする気があって修正案を出してくるのなら見てあげるけど。
(俺自身ではそこまでやる気はない)
まあしかし、JavaScriptだけがゴミじゃない、ってのは分かった。
というかもしかしてJavaScriptの実装ってPERL実装互換に敢えてしてる？
>>872
お前は何派なんだよ？
JavaScriptに関してはMDNでも前は「PCREで大体使えます」みたいな事書いてたぞ。
最近大幅リニューアルしてその記述はなくなったが。
(というより色々見にくくなってあまり確認してない）
鬼車派ならこの手の「実装ミス」をひたすら潰しておけばワンチャンあるかもしれんよ。
JavaScriptにしてもPerlにしてもこの辺のミスは確実に足枷になってる。
具体的に言うと遭遇した全プログラマが数時間ずつ無駄に検索その他をさせられる羽目になってる。
これは「新規プログラマ」からすると上達を妨げる障壁でしかない。
JavaScriptで言うと「IEデハー」な件を全部暗記してて今もそれにすがっている奴のウザさみたいなもんだ。
仕様バグがない、というのはそれなりに武器になる。
874デフォルトの名無しさん
2019/07/14(日) 15:13:19.95ID:LdVrbIxu >>867
今更regex101で確認してみたが、PCREだけは（これに関しては）正しく通るじゃねえかよ。
Perlの「初回は」というのはつまり g の時だけおかしくなるということであり、今回は当たらないからだが。
だからJavaScriptも仮にPerl実装互換にしようとしたとしてもしくってるな。
>>871
ちなみに
> > と < は後読みと先読みにして外に出すことができるので
の意味分かる？
おそらくはバックトラックを小さくする為（つまり高速化）だと思うのだが、
実際 regex101で試す限り余計に遅くなる。
テストサンプルはそこの下の「XMLタグを加工する」の上側半分のxmlで、こちらだと
(?:^|>)(.*?)(?:$|<) の場合は 29matches, 1277steps だが
(?:^|(?<=>))(.*?)(?:$|(?=<)) の場合は 29matches, 1875stepsで、余計に遅くなってる。
格好良くはないが別に $1$2$3 で置換しても問題ないと思うのだが。
今更regex101で確認してみたが、PCREだけは（これに関しては）正しく通るじゃねえかよ。
Perlの「初回は」というのはつまり g の時だけおかしくなるということであり、今回は当たらないからだが。
だからJavaScriptも仮にPerl実装互換にしようとしたとしてもしくってるな。
>>871
ちなみに
> > と < は後読みと先読みにして外に出すことができるので
の意味分かる？
おそらくはバックトラックを小さくする為（つまり高速化）だと思うのだが、
実際 regex101で試す限り余計に遅くなる。
テストサンプルはそこの下の「XMLタグを加工する」の上側半分のxmlで、こちらだと
(?:^|>)(.*?)(?:$|<) の場合は 29matches, 1277steps だが
(?:^|(?<=>))(.*?)(?:$|(?=<)) の場合は 29matches, 1875stepsで、余計に遅くなってる。
格好良くはないが別に $1$2$3 で置換しても問題ないと思うのだが。
875デフォルトの名無しさん
2019/07/14(日) 15:29:05.53ID:XILHsvHP >>874
> > と < は後読みと先読みにして外に出すことができるので
これは文字を消費しないための措置
マッチさせたい部分以外の部分にまでマッチしてしまうと次回の
検索開始位置が意図しないところに進んでしまったりするので先読みを
使って消費しないようにします
あとあなたが言ってることにはおおむね同意です
変な挙動は無くなるといいですね、perl6に期待したいところだけど
perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
自分にとっては処理が重くなるのであまり嬉しくないですね..
> > と < は後読みと先読みにして外に出すことができるので
これは文字を消費しないための措置
マッチさせたい部分以外の部分にまでマッチしてしまうと次回の
検索開始位置が意図しないところに進んでしまったりするので先読みを
使って消費しないようにします
あとあなたが言ってることにはおおむね同意です
変な挙動は無くなるといいですね、perl6に期待したいところだけど
perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
自分にとっては処理が重くなるのであまり嬉しくないですね..
876デフォルトの名無しさん
2019/07/14(日) 16:03:14.68ID:LdVrbIxu >>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等の文書検索側の人かな？だからって別に特に問題はないが。
ああなるほど、\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等の文書検索側の人かな？だからって別に特に問題はないが。
877デフォルトの名無しさん
2019/07/15(月) 15:22:14.71ID:y88H95dP Ruby で、
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果
878デフォルトの名無しさん
2019/07/15(月) 16:42:33.19ID:xqOJLOC2 >>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
テストしてくれたって事か？なら一応まとめておく。
/(^|[@;])[^@;]*/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
879デフォルトの名無しさん
2019/07/15(月) 23:23:32.64ID:3MPTmFRg BREの正規表現と今の正規表現の使い方の違いの話は面白いなぁ
しかしこの人こんなにすごいスキルとモチベがあるなら質問なんかせずに
自力でなんとか出来たのではｗ
質問してくれたおかげで面白い話をいろいろ聞けたからこちらは嬉しいけどネ
おかしな挙動と言えばperl5とOnigmoでは\Gの挙動に違いが
あってどちらかが違和感のある動作をしたはず
\Gの概念自体が微妙に違ったはずだけどメモるの忘れた
興味のある人はぐぐってね
しかしこの人こんなにすごいスキルとモチベがあるなら質問なんかせずに
自力でなんとか出来たのではｗ
質問してくれたおかげで面白い話をいろいろ聞けたからこちらは嬉しいけどネ
おかしな挙動と言えばperl5とOnigmoでは\Gの挙動に違いが
あってどちらかが違和感のある動作をしたはず
\Gの概念自体が微妙に違ったはずだけどメモるの忘れた
興味のある人はぐぐってね
880デフォルトの名無しさん
2019/07/16(火) 15:24:59.03ID:wQsYVdH6 ネット弁慶がイキりたかっただけでしょ
881デフォルトの名無しさん
2019/07/16(火) 16:08:47.84ID:cpfSTA9t >JavaScript, Python, Go, Ruby, : ["",";prop1:style1", ";prop2:style2"]
深くて理解できないことが多いが、これはやばい気がする
深くて理解できないことが多いが、これはやばい気がする
882デフォルトの名無しさん
2019/07/16(火) 17:23:30.54ID:hAAouWtx 読んでるだけで何も考えてなかったけど
/(^|[@;])[^@;]*/g
この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？
/(^|[@;])[^@;]*/g
この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？
883デフォルトの名無しさん
2019/07/16(火) 18:30:33.69ID:AvaVqNzm 一所懸命挑発的に書いてるのに全然乗ってもらえなくてかわいそう
884デフォルトの名無しさん
2019/07/16(火) 19:27:45.24ID:hAAouWtx 言ってることに説得力がありすぎて聞き入ってしまってたよ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ
885デフォルトの名無しさん
2019/07/16(火) 20:41:55.62ID:bFMew56o 入力フォーマットが正しいという前提で /@?[^@;]+/ の方が好み
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ
886デフォルトの名無しさん
2019/07/16(火) 21:03:17.33ID:hMJFhr7R >>881
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。
例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。
JavaScriptの場合はatomエディターなる物があって、htmlやプログラムソースコードを編集出来るが、
JavaScriptの場合はreplaceもバグっているので、命中すれば、全置換しても全置換出来てないケースが発生する。
リファクタ等で変数名を変えるとき、手でやるとバグるので、当然エディタ機能で全置換させるわけだが、この場合にもバグる訳だ。
そしてユーザーはこのときに置換漏れが発生するとは全く思わないので、かなり手間取ることになる。
(atomでは対策されていると信じたい)
JavaScriptの場合はこのバグも「仕様」としてしまっているので、
逆に言えば仕様通りならバグに命中したときの挙動も確定してる。だから対策は出来るが、
Rubyみたいに「実装が仕様だ」と言い張る糞言語だとどういう挙動か確認してみなければ分からず、対策が出来ない。
ここらへんもRubyの思想は数周遅れている。
いずれにしてもこんな基本的なところのバグはあっても迷惑でしかなく、さっさと直せ、でしかない。
「速い」以前に「ヒットしない」エンジンなんて使い物にならないだろ。
エンジン競争しているつもりの馬鹿共も、方向性を完全に間違ってる。
「間違いなく動作する」エンジンを提供すれば、文書検索側の人間はサクッと乗り換えてくれるだろうさ。
速い遅いはその後の話だ。
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。
例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。
JavaScriptの場合はatomエディターなる物があって、htmlやプログラムソースコードを編集出来るが、
JavaScriptの場合はreplaceもバグっているので、命中すれば、全置換しても全置換出来てないケースが発生する。
リファクタ等で変数名を変えるとき、手でやるとバグるので、当然エディタ機能で全置換させるわけだが、この場合にもバグる訳だ。
そしてユーザーはこのときに置換漏れが発生するとは全く思わないので、かなり手間取ることになる。
(atomでは対策されていると信じたい)
JavaScriptの場合はこのバグも「仕様」としてしまっているので、
逆に言えば仕様通りならバグに命中したときの挙動も確定してる。だから対策は出来るが、
Rubyみたいに「実装が仕様だ」と言い張る糞言語だとどういう挙動か確認してみなければ分からず、対策が出来ない。
ここらへんもRubyの思想は数周遅れている。
いずれにしてもこんな基本的なところのバグはあっても迷惑でしかなく、さっさと直せ、でしかない。
「速い」以前に「ヒットしない」エンジンなんて使い物にならないだろ。
エンジン競争しているつもりの馬鹿共も、方向性を完全に間違ってる。
「間違いなく動作する」エンジンを提供すれば、文書検索側の人間はサクッと乗り換えてくれるだろうさ。
速い遅いはその後の話だ。
887デフォルトの名無しさん
2019/07/16(火) 21:18:41.35ID:hMJFhr7R >>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)
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)
888デフォルトの名無しさん
2019/07/16(火) 22:42:20.32ID:P37s1FHo 一度言った内容は繰り返さなくていいです
889デフォルトの名無しさん
2019/07/17(水) 08:28:41.50ID:2/Bgill9 >>873訂正
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)
Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<) に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
その筆者の説明通り先頭タグを含んで次タグ或いは文末まで伸びることになる。
俺のケースでは、正規表現 (^|[@;])[^@;]* に対して、
1回目：(^|[@;])[^@;]*
2回目：(^|[@;])[^@;]+
だから '@time;prop1:style1;prop2:style2' に対して @time のマッチも正しく取れることになる。
こういった場合、実装者は安全側に倒したくなる物だが、
現実は安全側に倒しすぎて余分なケースを含んでしまい、結果、バグっているというわけだ。
JavaScriptは最高に安全な実装、「空文字マッチは1文字進める」とした。（おそらくRubyその他もそう）
これだと絶対に無限ループはしないが、俺のケースでバグる。
Perlの実装だと俺のケースは通るが、871内URLの筆者のケースでバグる。
その他バグケースも出してくれれば俺の推測で合っているかどうかは答える。
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)
Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<) に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
その筆者の説明通り先頭タグを含んで次タグ或いは文末まで伸びることになる。
俺のケースでは、正規表現 (^|[@;])[^@;]* に対して、
1回目：(^|[@;])[^@;]*
2回目：(^|[@;])[^@;]+
だから '@time;prop1:style1;prop2:style2' に対して @time のマッチも正しく取れることになる。
こういった場合、実装者は安全側に倒したくなる物だが、
現実は安全側に倒しすぎて余分なケースを含んでしまい、結果、バグっているというわけだ。
JavaScriptは最高に安全な実装、「空文字マッチは1文字進める」とした。（おそらくRubyその他もそう）
これだと絶対に無限ループはしないが、俺のケースでバグる。
Perlの実装だと俺のケースは通るが、871内URLの筆者のケースでバグる。
その他バグケースも出してくれれば俺の推測で合っているかどうかは答える。
890デフォルトの名無しさん
2019/07/17(水) 08:28:59.00ID:2/Bgill9 正しい実装は、「経路全体」（つまりツリーのリーフ）に対してフラグを持たないといけない。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。
実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
ただしこれはリターンパスを辿ればいいので何らかのツールが有ればほぼ自動でいけるかもしれない。
次に上記リストを作成する為に全経路を出力させなければならない。
デバッグ用にこれが既にあればラッキーだが、なければ自前で作らなければいけない。
といっても内容はツリーのノードを辿るだけなので、ツリーのフォーマットが分かればすぐだが、
ゴリゴリに高速化とかしていると割と意味不明なコードになっていることが多いので、
その状態で確認するのは結構辛いとは思う。
リストの管理は、空文字マッチなら追記、非空文字マッチならクリア、なので、これはやるだけだ。
リストの管理も探索関数にやらせて、探索関数は
今：マッチ場所とマッチ長さを返す
修正後：マッチ場所とマッチ長さを含んだ『配列』を返す、とし、
「空文字マッチの場合は自動で継続、非空文字マッチまたは終了まで探索、まとめて配列で結果を返す」とするのがいいだろう。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。
実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
ただしこれはリターンパスを辿ればいいので何らかのツールが有ればほぼ自動でいけるかもしれない。
次に上記リストを作成する為に全経路を出力させなければならない。
デバッグ用にこれが既にあればラッキーだが、なければ自前で作らなければいけない。
といっても内容はツリーのノードを辿るだけなので、ツリーのフォーマットが分かればすぐだが、
ゴリゴリに高速化とかしていると割と意味不明なコードになっていることが多いので、
その状態で確認するのは結構辛いとは思う。
リストの管理は、空文字マッチなら追記、非空文字マッチならクリア、なので、これはやるだけだ。
リストの管理も探索関数にやらせて、探索関数は
今：マッチ場所とマッチ長さを返す
修正後：マッチ場所とマッチ長さを含んだ『配列』を返す、とし、
「空文字マッチの場合は自動で継続、非空文字マッチまたは終了まで探索、まとめて配列で結果を返す」とするのがいいだろう。
891デフォルトの名無しさん
2019/07/17(水) 08:29:16.56ID:2/Bgill9 なおPerlの実装だと『上位関数のみ』で対策できるため、
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。
いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。
いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。
892デフォルトの名無しさん
2019/07/17(水) 09:46:24.93ID:u050lnGw 話を単純化すると、
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する
つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う
(^|[@;])[^@;]*
だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！
OR の部分が、並列ではない。
ルール1を優先すべき！
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する
つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う
(^|[@;])[^@;]*
だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！
OR の部分が、並列ではない。
ルール1を優先すべき！
893892
2019/07/17(水) 09:51:38.77ID:u050lnGw (^|[@;])[^@;]*
OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！
A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！
OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！
A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！
894デフォルトの名無しさん
2019/07/17(水) 09:53:34.46ID:RL7WDafS 左側優先とかないのかこれ？
895877
2019/07/17(水) 10:06:18.04ID:u050lnGw >>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", ";"]]
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", ";"]]
896デフォルトの名無しさん
2019/07/17(水) 13:38:56.68ID:FD/sfaX1 小飼って糖尿病で死んだんだっけ
897デフォルトの名無しさん
2019/07/17(水) 14:01:11.32ID:fOq5lc1d 質問させてください。
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？
898デフォルトの名無しさん
2019/07/17(水) 15:07:35.98ID:Jmalh7Yl899デフォルトの名無しさん
2019/07/17(水) 20:30:56.60ID:2/Bgill9 >>894
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。
900デフォルトの名無しさん
2019/07/17(水) 20:37:09.24ID:RL7WDafS >>899
ちょっと知識が深まったよ サンクス
ちょっと知識が深まったよ サンクス
901デフォルトの名無しさん
2019/07/17(水) 20:40:11.08ID:2/Bgill9 >>895
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。
+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
JavaScriptは少なくとも仕様に明記はしてる。
ただそれだと弱いからMDNにも書け、というのが俺の主張であり、JavaScriptスレに勝手に依頼しておいた。
以前RegExp.testの件で同様に依頼したら追記されたから、そうなるのを願っている。
そういう、「落とし穴」は共同して塞いでいかないと駄目なんだよ。
完璧な言語なんてない。だから多少バグがあるのは仕方ないとして、
それを未来永劫新規プログラマに押しつけて「キャハハー、お前も落ちたか！」なんてやっているようでは駄目なんだ。
Rubyはプログラマに対してリスペクトが全くない。だから廃れるし、俺もそうなることを願っている。
お前はRubyを吹聴しさえすれば布教出来ると勘違いしているようだが、そんなことはない。
当たり前だが新人にとってはこんなバグにつき合わされること自体大迷惑でしかないんだよ。
今回のでもPCREが一番ましだし、Rubyなんて選ばれる理由がないだろ。
ゴミだと分かっているものを広めるのは、単なる詐欺師でしかないぞ。
お前はお前の行為によってRubyへの反感を得ているだけなことを自覚した方がいい。
あちこちのスレでお前は相当ウザがられてる。
そういうのではなくて、バグを修正するとか、仕様書に明記するとか、
何でそういう建設的な方向に努力出来ないんだ？
こういう地道な積み重ねを全くやってないからRubyの現状はあるわけでさ。
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。
+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
JavaScriptは少なくとも仕様に明記はしてる。
ただそれだと弱いからMDNにも書け、というのが俺の主張であり、JavaScriptスレに勝手に依頼しておいた。
以前RegExp.testの件で同様に依頼したら追記されたから、そうなるのを願っている。
そういう、「落とし穴」は共同して塞いでいかないと駄目なんだよ。
完璧な言語なんてない。だから多少バグがあるのは仕方ないとして、
それを未来永劫新規プログラマに押しつけて「キャハハー、お前も落ちたか！」なんてやっているようでは駄目なんだ。
Rubyはプログラマに対してリスペクトが全くない。だから廃れるし、俺もそうなることを願っている。
お前はRubyを吹聴しさえすれば布教出来ると勘違いしているようだが、そんなことはない。
当たり前だが新人にとってはこんなバグにつき合わされること自体大迷惑でしかないんだよ。
今回のでもPCREが一番ましだし、Rubyなんて選ばれる理由がないだろ。
ゴミだと分かっているものを広めるのは、単なる詐欺師でしかないぞ。
お前はお前の行為によってRubyへの反感を得ているだけなことを自覚した方がいい。
あちこちのスレでお前は相当ウザがられてる。
そういうのではなくて、バグを修正するとか、仕様書に明記するとか、
何でそういう建設的な方向に努力出来ないんだ？
こういう地道な積み重ねを全くやってないからRubyの現状はあるわけでさ。
902デフォルトの名無しさん
2019/07/18(木) 16:11:19.79ID:Y8yxmCyC 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
予測が難しいところがあるのでは
バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ
あとrubyの正規表現エンジンは空文字マッチが〜の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな
予測が難しいところがあるのでは
バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ
あとrubyの正規表現エンジンは空文字マッチが〜の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな
903デフォルトの名無しさん
2019/07/18(木) 20:03:10.71ID:PnG1z3PK >>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界隈にはまともなプログラマがいないからだよ。
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界隈にはまともなプログラマがいないからだよ。
904デフォルトの名無しさん
2019/07/18(木) 20:22:20.04ID:Y8yxmCyC BREという超シンプルな正規表現エンジンが持っていた明解な動作の分かりやすさを
現代の超複雑な正規表現エンジンに求めることには無理がある
ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう
ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない
時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
しかもたった数例のコードの動作を見ただけでだ、あほらしい
現代の超複雑な正規表現エンジンに求めることには無理がある
ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう
ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない
時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
しかもたった数例のコードの動作を見ただけでだ、あほらしい
905デフォルトの名無しさん
2019/07/18(木) 20:44:40.06ID:PnG1z3PK >>902
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。
> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
スクリプタがやってる、今書いて今動いたら捨てておｋ、なんて甘い世界ではない。
まともなコードなら未来永劫整備可能だし、また、それを目指しているのがプログラマだ。
実際、Linuxなんて30年越しで整備され続けてるだろ。
数年前にお前が書いたコードすら読めないのは、お前の問題であって、それを全体のように言うな。
だからスクリプタは馬鹿にされるし、嫌われるんだよ。
正規表現エンジンなんてプログラミング全体からするとかなり簡単な部類だ。
動けばいいだけのエンジンなら再帰しまくりで1000行程度だろう。
最悪全交換でいい規模だから、そこまでガチで整備されている事は期待出来ないが、
それにしてもこの程度の規模のプログラムを読めない、ってことはあり得ない。
高速化はプログラムに対して「複雑度」を増すものではない。
具体的に言うと、静的コールグラフを複雑化することはなく、
単に遅い関数を速い関数に入れ替える、というのが基本になる。
だから、正規表現エンジンを読めない、というのなら、書いた奴か読む奴が馬鹿なだけであって、
ちゃんとした奴が書いたエンジンをちゃんとした奴が読めば確実に読める。
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。
> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
スクリプタがやってる、今書いて今動いたら捨てておｋ、なんて甘い世界ではない。
まともなコードなら未来永劫整備可能だし、また、それを目指しているのがプログラマだ。
実際、Linuxなんて30年越しで整備され続けてるだろ。
数年前にお前が書いたコードすら読めないのは、お前の問題であって、それを全体のように言うな。
だからスクリプタは馬鹿にされるし、嫌われるんだよ。
正規表現エンジンなんてプログラミング全体からするとかなり簡単な部類だ。
動けばいいだけのエンジンなら再帰しまくりで1000行程度だろう。
最悪全交換でいい規模だから、そこまでガチで整備されている事は期待出来ないが、
それにしてもこの程度の規模のプログラムを読めない、ってことはあり得ない。
高速化はプログラムに対して「複雑度」を増すものではない。
具体的に言うと、静的コールグラフを複雑化することはなく、
単に遅い関数を速い関数に入れ替える、というのが基本になる。
だから、正規表現エンジンを読めない、というのなら、書いた奴か読む奴が馬鹿なだけであって、
ちゃんとした奴が書いたエンジンをちゃんとした奴が読めば確実に読める。
906デフォルトの名無しさん
2019/07/18(木) 20:46:26.35ID:PnG1z3PK > バグと言えばバグだけど
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
Rubyの現状はバグに気づいてないか、敢えて黙っているかで、どちらにしても糞でしかない。
> つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
> 対応してると記憶してるから
お前がどんだけ馬鹿なのか分からないが、「バグ」ってのは意図してない動作のことを言うんだぞ。
つまり、対応してるつもりが対応できてないから「バグ」なんだよ。
> rubyモードの仕様なんじゃないかな
そう言うのはちゃんと調べてから言え。希望的観測ではミスリードを大量発生させる。
そしてこれをやりまくっているのがJavaScript界隈で、結果、JavaScripterは馬鹿が再生産されまくってる。
そういうのは止めろ。お互いに得る物がない。
>>904
まあ書いた後に読んだから投稿はしておいた。
話すつもりがないのならさようならでいい。
お前は、自身の問題を認識出来てないタイプだ。まあこのタイプもよくいるが。
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
Rubyの現状はバグに気づいてないか、敢えて黙っているかで、どちらにしても糞でしかない。
> つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
> 対応してると記憶してるから
お前がどんだけ馬鹿なのか分からないが、「バグ」ってのは意図してない動作のことを言うんだぞ。
つまり、対応してるつもりが対応できてないから「バグ」なんだよ。
> rubyモードの仕様なんじゃないかな
そう言うのはちゃんと調べてから言え。希望的観測ではミスリードを大量発生させる。
そしてこれをやりまくっているのがJavaScript界隈で、結果、JavaScripterは馬鹿が再生産されまくってる。
そういうのは止めろ。お互いに得る物がない。
>>904
まあ書いた後に読んだから投稿はしておいた。
話すつもりがないのならさようならでいい。
お前は、自身の問題を認識出来てないタイプだ。まあこのタイプもよくいるが。
907デフォルトの名無しさん
2019/07/18(木) 21:56:03.46ID:xdHI+pcE 荒らしと会話するな！
荒らしと会話する者も、荒らしだぞ！
プログラマーとは、コードで語る者だけ！
能書きはいらない！
そいつらは荒らしだから、会話するな！
荒らしと会話する者も、荒らしだぞ！
プログラマーとは、コードで語る者だけ！
能書きはいらない！
そいつらは荒らしだから、会話するな！
908デフォルトの名無しさん
2019/07/18(木) 22:31:51.56ID:PnG1z3PK >>907
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。
というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。
俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。
onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
どっちでもないってのは、俺には頭おかしいとしか思えないけどな。
まあ確実に言えるのは、Rubyを今から学ぶのは止めとけ、ってことだ。
Rubyはコミュニティの腐り方がどうも他とは違う。
(JavaScriptも腐ってはいるが、あれは「若すぎる」のが原因だ。
かといって放置しても自然に改善するものでもないが）
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。
というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。
俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。
onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
どっちでもないってのは、俺には頭おかしいとしか思えないけどな。
まあ確実に言えるのは、Rubyを今から学ぶのは止めとけ、ってことだ。
Rubyはコミュニティの腐り方がどうも他とは違う。
(JavaScriptも腐ってはいるが、あれは「若すぎる」のが原因だ。
かといって放置しても自然に改善するものでもないが）
909デフォルトの名無しさん
2019/07/19(金) 00:09:18.78ID:KcCrOwH9 PCREに非包含オペレータが搭載されたら起こしてくれ
910デフォルトの名無しさん
2019/07/19(金) 00:50:19.02ID:CNkXpMDT >>909
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。
ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> https://qiita.com/k-takata/items/4e45121081c83d3d5bfd
これって何？知ってたら教えてくれれば助かる。
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。
ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> https://qiita.com/k-takata/items/4e45121081c83d3d5bfd
これって何？知ってたら教えてくれれば助かる。
911デフォルトの名無しさん
2019/07/19(金) 02:29:00.41ID:CNkXpMDT >>909
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。
> https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf
つまり理論畑の人には問題があるが、プログラミング上問題はないんだろ。
そりゃ入れないだろ。
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。
> https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf
つまり理論畑の人には問題があるが、プログラミング上問題はないんだろ。
そりゃ入れないだろ。
912デフォルトの名無しさん
2019/07/19(金) 03:16:00.34ID:CNkXpMDT >>910
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
https://kkos.hatenadiary.org/entries/2007/05/25#1180100250
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。
ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
https://kkos.hatenadiary.org/entries/2007/05/25#1180100250
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。
ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。
913デフォルトの名無しさん
2019/07/19(金) 11:33:59.54ID:bgAzEf51 このスレでコミュニティうんぬんは脱線しすぎじゃないかい。スレタイとなんも関係ないやろ。
914デフォルトの名無しさん
2019/07/20(土) 15:46:35.52ID:KXtQuYxh 本当にプログラマなのかな
915デフォルトの名無しさん
2019/07/20(土) 17:29:27.69ID:AFOF1ubv JSです
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？
/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？
/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？
917915
2019/07/20(土) 17:37:46.94ID:AFOF1ubv918デフォルトの名無しさん
2019/07/20(土) 17:45:51.81ID:kkJ7q95a919デフォルトの名無しさん
2019/07/20(土) 20:12:32.11ID:AFOF1ubv >>918
3つ目の
# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">
ですね、ありがとうございます…！
3つ目の
# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">
ですね、ありがとうございます…！
920デフォルトの名無しさん
2019/07/21(日) 20:31:55.31ID:Bdf0kkIf >>912
ttps://kkos.hatenadiary.org/entry/20070906/1189084566
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？
rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？
まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。
現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。
ttps://kkos.hatenadiary.org/entry/20070906/1189084566
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？
rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？
まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。
現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。
921デフォルトの名無しさん
2019/07/22(月) 01:27:11.95ID:dN38X5eV >>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氏の判断は妥当だ。
おおサンクス。
ただ、それって 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氏の判断は妥当だ。
922デフォルトの名無しさん
2019/08/01(木) 15:57:12.21ID:BVNOJ7mG >>789やってくれる人はいないか〜
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな
onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな
onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ
923デフォルトの名無しさん
2019/08/24(土) 12:41:17.80ID:fR0bFJ1E perlで
(?<=(aa|bb))c
ならokだが
(?<=(aa|bbb))c
だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん
秀丸のHmJre.dllだと通るようだ
(?<=(aa|bb))c
ならokだが
(?<=(aa|bbb))c
だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん
秀丸のHmJre.dllだと通るようだ
924デフォルトの名無しさん
2019/08/24(土) 13:46:10.60ID:6nD2xE5w (?<=(aa.*|bbb))c
925デフォルトの名無しさん
2019/08/25(日) 15:17:23.04ID:GRZE+Rz9 (?<=aa|bbb)c
926デフォルトの名無しさん
2019/09/01(日) 12:33:19.59ID:fodjUzDJ JS（ES2017）です
「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい この場合は「貫」だけ残して「樣」は消したい）
のですが
CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？
「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい この場合は「貫」だけ残して「樣」は消したい）
のですが
CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？
927926
2019/09/01(日) 12:38:35.03ID:fodjUzDJ 「樣」は一応日本語でも使うみたいですね…
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？
928デフォルトの名無しさん
2019/09/01(日) 13:31:25.10ID:kCJZVLuH929デフォルトの名無しさん
2019/09/01(日) 13:35:35.35ID:kCJZVLuH ねむい
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK/gb2312-80.gif
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK/gb2312-80.gif
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html
930デフォルトの名無しさん
2019/09/01(日) 18:46:39.31ID:VXfAHt8z >>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で保存したら他は
疑問符になるだろうからそれをまとめて削除したらおしまいだろうが
繁体字の樣は残る。簡体字の[木羊]は消える。
樣は様の旧字で現在でも許容字体扱いだから「常用漢字表」にも
出て来る。
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で保存したら他は
疑問符になるだろうからそれをまとめて削除したらおしまいだろうが
繁体字の樣は残る。簡体字の[木羊]は消える。
931デフォルトの名無しさん
2019/09/01(日) 21:04:09.80ID:fO6VcsLE Google謹製の正規表現ライブリ「re2」でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？
932デフォルトの名無しさん
2019/09/01(日) 22:01:25.54ID:Zrnas7uJ >>931
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/
933デフォルトの名無しさん
2019/09/01(日) 22:50:02.12ID:8GDP8quV RE2 regex とか RE2 正規表現 とかでググれば
934デフォルトの名無しさん
2019/09/10(火) 22:48:57.92ID:CokwQGf+ 直前の文字が1回以上出現することが確実なケースで、仮に0回の出現として考慮しても問題がないという場合に、
+ではなく*で正規表現を記述する理由はありますか？
例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう
+ではなく*で正規表現を記述する理由はありますか？
例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう
935デフォルトの名無しさん
2019/09/10(火) 23:21:08.02ID:1dbF51qB 0回も許容するなら+ではなく*にする理由は0回も許容するからとしか
936デフォルトの名無しさん
2019/09/10(火) 23:26:41.78ID:L5QX1JAH 具体例で示してくれんとなんか曖昧でよくわからんね
937デフォルトの名無しさん
2019/09/11(水) 12:05:55.89ID:zFEVPQj4 >1回以上出現することが確実なケース
>仮に0回の出現として考慮しても問題がない
矛盾してるな
>仮に0回の出現として考慮しても問題がない
矛盾してるな
938デフォルトの名無しさん
2019/09/11(水) 15:12:05.49ID:wb8QVF41939デフォルトの名無しさん
2019/09/11(水) 16:12:55.15ID:h8Pfy2ne940デフォルトの名無しさん
2019/09/12(木) 02:26:26.53ID:xpiKRNxb やっぱ質問して放置か、教える側も学習すべきだな
まともな質問じゃないと思ったらスルーでいい
まともな質問じゃないと思ったらスルーでいい
941デフォルトの名無しさん
2019/09/12(木) 04:33:29.68ID:+6m2JHnd 別におかしな質問じゃないだろ
942デフォルトの名無しさん
2019/09/12(木) 06:58:37.97ID:1ik9S0iw いや普通におかしいだろ
なんか無理矢理の条件考えて論争させようとしてるような気がする
なんか無理矢理の条件考えて論争させようとしてるような気がする
943デフォルトの名無しさん
2019/09/12(木) 08:21:20.40ID:xpiKRNxb 自分なら人にこういう質問レスを書くかなって考えてみて絶対書かないと
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも
944デフォルトの名無しさん
2019/09/12(木) 09:22:01.93ID:TOasMGF3 ●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,}"で検索は出来たのですが置換が思い浮かびません
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,}"で検索は出来たのですが置換が思い浮かびません
945デフォルトの名無しさん
2019/09/12(木) 10:00:21.41ID:bJPykHLq わかりやすいように、できるだけそのまま書くならこうかな
●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]
●置換文字列
\1\2
●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]
●置換文字列
\1\2
946デフォルトの名無しさん
2019/09/12(木) 10:04:35.65ID:bJPykHLq 置換に問題は無いけど()が二重になってたミス修正
(id="|\G )(\d+[A-Z]\d+)[a-z]
(id="|\G )(\d+[A-Z]\d+)[a-z]
947デフォルトの名無しさん
2019/09/12(木) 10:30:50.86ID:TOasMGF3 >946
出来ました！
ありがとうございます。
田中哲スペシャルっていうやり方なのでしょうか
出来ました！
ありがとうございます。
田中哲スペシャルっていうやり方なのでしょうか
948デフォルトの名無しさん
2019/09/12(木) 11:08:37.62ID:bJPykHLq \Gは照合開始位置と呼ばれる物で、マッチした箇所の後の境界にマッチしてくれるので
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番
田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番
田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな
949デフォルトの名無しさん
2019/09/12(木) 11:58:31.87ID:TOasMGF3 >948
勉強になります。
ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"
対応策ありますでしょうか？
勉強になります。
ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"
対応策ありますでしょうか？
950デフォルトの名無しさん
2019/09/12(木) 12:04:38.94ID:xpiKRNxb 自分ならこの時点でスルー
\Gは文頭にもマッチするから誤爆対策を忘れずに
\Gは文頭にもマッチするから誤爆対策を忘れずに
951デフォルトの名無しさん
2019/09/12(木) 15:04:33.55ID:bJPykHLq952デフォルトの名無しさん
2019/09/12(木) 18:04:49.29ID:TOasMGF3 >951
ヒントありがとうございます。
残りは自分でがんばってみます。
ヒントありがとうございます。
残りは自分でがんばってみます。
953デフォルトの名無しさん
2019/09/12(木) 18:08:37.95ID:EfYu2rO4 文字列 "プログラマー" を "プロクライマー" に書き換える正規表現を教えて下さい
954デフォルトの名無しさん
2019/09/12(木) 21:50:17.55ID:Jdu1U3XN そこにソースがあるから登るんだ。
955デフォルトの名無しさん
2019/09/12(木) 22:19:07.70ID:cqw0/uFd 正規表現の使い方じゃなく作り方、バックトラックなど理論から解説している書籍やそれに準ずるサイトなど知っていたらご教示ください。
こうやればこうなるよ、こういうときはこうすればいいんだよ的な学習では身に付かなくて…
こうやればこうなるよ、こういうときはこうすればいいんだよ的な学習では身に付かなくて…
956デフォルトの名無しさん
2019/09/12(木) 22:56:30.12ID:Yy9Clfy1 自分が参考にしたのはここだったかな
http://fussy.web.fc2.com/algo/search5_regex.htm
実装の仕方がある程度分かれば鬼車の作者さんのブログ(rubyの一件以前の記事)も参考になると思う
http://fussy.web.fc2.com/algo/search5_regex.htm
実装の仕方がある程度分かれば鬼車の作者さんのブログ(rubyの一件以前の記事)も参考になると思う
957デフォルトの名無しさん
2019/09/12(木) 23:14:33.93ID:Uy9QyXie ありがとうございます！
rubyの一件って何ですか？（何て検索したらいいですか？）
rubyの一件って何ですか？（何て検索したらいいですか？）
958デフォルトの名無しさん
2019/09/12(木) 23:43:24.49ID:Yy9Clfy1 Rubyの作者さんと何かあったようで嫌気が差したのかそれ以後ブログで正規表現のことを
取り上げる頻度がめっきり減っちゃったんですよ
取り上げる頻度がめっきり減っちゃったんですよ
959デフォルトの名無しさん
2019/09/13(金) 08:32:54.25ID:sQZEDK+j960デフォルトの名無しさん
2019/09/13(金) 10:47:34.78ID:wKEqF87n961デフォルトの名無しさん
2019/09/13(金) 11:54:40.09ID:X5DxpBbM 正規表現はどの言語でも共通で使えますか？それともちょっと違ったりしますか？
962デフォルトの名無しさん
2019/09/13(金) 12:02:22.73ID:KuW4wLhZ ちょっと違ったりします
963デフォルトの名無しさん
2019/09/13(金) 13:25:46.31ID:8XwQqyT8 Ruby で作った。
一旦、パターンで一致させてから、一致した行だけを変換した。
ただし、同じ行に、id="〜" が複数あると、バグる！
src = <<'EOT'
id="aAxy Xz"
あ
id=""
id="9"
id="9y"
EOT
# id=" で始まって、" 以外の文字が続いて、" で終わる
re = /id\=\"([^\"]+)\"/ # ( ) 内は、$1
dest = src.gsub( re ) do |line|
'id="' + $1.delete( "a-z" ) + '"'
end
print dest
出力
id="A X"
あ
id=""
id="9"
id="9"
一旦、パターンで一致させてから、一致した行だけを変換した。
ただし、同じ行に、id="〜" が複数あると、バグる！
src = <<'EOT'
id="aAxy Xz"
あ
id=""
id="9"
id="9y"
EOT
# id=" で始まって、" 以外の文字が続いて、" で終わる
re = /id\=\"([^\"]+)\"/ # ( ) 内は、$1
dest = src.gsub( re ) do |line|
'id="' + $1.delete( "a-z" ) + '"'
end
print dest
出力
id="A X"
あ
id=""
id="9"
id="9"
965デフォルトの名無しさん
2019/09/16(月) 02:45:59.31ID:dK4dr8mE JSで
101 dogs
7 little goats
30 8 year old humans
↑をそれぞれ
["101", "dogs"]
["7", "little goats"]
["30", "8 year old humans"]
と切り分けるにはどんな正規表現を使えばよいでしょうか？
["7", " ", "little goats"]のような形でもかまいません
.match(/^\d+\s|.+$/)
だと
["7 ", "little goats"]
になってしまい、数字のあとの余計な半角スペースをあとで取り除かなければならなくなるのがなんか嫌で…
101 dogs
7 little goats
30 8 year old humans
↑をそれぞれ
["101", "dogs"]
["7", "little goats"]
["30", "8 year old humans"]
と切り分けるにはどんな正規表現を使えばよいでしょうか？
["7", " ", "little goats"]のような形でもかまいません
.match(/^\d+\s|.+$/)
だと
["7 ", "little goats"]
になってしまい、数字のあとの余計な半角スペースをあとで取り除かなければならなくなるのがなんか嫌で…
966デフォルトの名無しさん
2019/09/16(月) 02:59:29.74ID:/xGIA7r1 正規表現を使えないなら文字列操作でやればいいだけ
正規表現を使いこなせてない人が使うとバグの温床になるからお勧めしない
正規表現を使いこなせてない人が使うとバグの温床になるからお勧めしない
967デフォルトの名無しさん
2019/09/16(月) 07:18:26.85ID:m2l8x1P1 >>965
.split(' ', 2)
.split(' ', 2)
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニュース
- 広末涼子容疑者 騒動を認め謝罪 芸能活動自粛を発表 看護師への暴行は「パニック状態に陥った結果」★8 [爆笑ゴリラ★]
- 広末涼子容疑者、薬物検査を今後実施する方針 [おっさん友の会★]
- 【静岡】自称・広末涼子容疑者(44)を逮捕 看護師にけがをさせた疑い 高速道路の事故で救急搬送され病院で暴行か ★3 [ぐれ★]
- トランプ大統領「日本は貿易で米国をひどく扱ってきた。彼らは米国の車を買わないのに我々は数百万台の日本車を買わされている」 ★2 [Hitzeschleier★]
- 日経平均株価､一時1000円超高 米株下落一服で買い戻し [蚤の市★]
- 古市憲寿氏、フジテレビ報告書内で中居正広氏の“空白の3日間”を指摘 「女性側の返事が載ってない、なぜ」 [冬月記者★]
- 【逮捕】広末涼子、薬物検査実施 [458340425]
- 【悲報】トランプ、関税の計算ミスで実際は1/4しか増えない模様wwwwwwwwww [834922174]
- 【失敗】農林水産省、全員の給料カットか？備蓄米を放出したのにお米の価格が上がってしまう [454313373]
- 【速報】中国「とことん戦う😤」トランプによる５０％追加関税に徹底抗戦の構え [583597859]
- 【悲報】日経平均、ぶっ壊れる [733893279]
- 万博の子供用トイレなんだけどさ、これって問題有ると思うんだけど? [605029151]