[過去ﾛｸﾞ] Regular Expression(正規表現) Part14 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
866(1): 2019/07/14(日)08:17 ID:LdVrbIxu(1/6) AAS
>>865
> 正規表現には統一規格みたいなものは存在しないので環境によって動作が異なります
これは知ってますがBREの範囲だと当然間違いなく動くし、
ほぼPCREに向けて統一中、といったところなのでは？
まあやたら複雑になってバックトラッキング等の問題が発生し、
結果的に速いライブラリに収束して行っているのはいいことだと思いますが。
> このスレの住民なら2番目のマッチが t から始まる環境も想定します
> ["","time", ";prop1:style1", ";prop2:style2"]
これは一応アウトなのでは？正規表現自体はデリミタごと取り込もうとしており、それが出来ていません。
これを言うならJavaScriptもアウトですが。
個人的にはJavaScriptは面白いのですが仕様がイマイチなところが散見されるのが難点ですね。
それが初心者に無用な混乱を引き起こし、上達の妨げになっている。
今回私も数時間無駄にしましたが、これが初心者だと脱出出来なくて誤解したままになってしまう。
そして本人はそれを自覚出来ず、Web上に間違った情報を垂れ流し、馬鹿が再生産されるというループになっている。
この意味では正規表現の現在の状況も同じようなものですが、
正規表現は「実装の幅がものすごくある」と共有されているだけまだましです。
JavaScriptの連中はその間違った実装を「正しい」と思いこんでいたりするので、会話が成立しません。
といってもJavaScriptのString.matchの仕様バグを今更直すことも出来ず、未来永劫このままだと思いますが。
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"]
を返すべきだった。
RegExp.lastIndex だけで状態管理出来ると「間違えた」からそうなった。
本来は先頭マッチフラグ RegExp.canMatchHead みたいなのが必要で、それを実装すれば両方とも正しい結果を返せた。
それを実装せず、String.match に間違ったパッチを当てたからそうなった。
これは実装者（おそらくブレンダンアイク本人)の判断ミスだ。
正規表現はPerlが再定義したと言っていい状況だ。だからみんなPCREを見てる。
PHPはさっさと取り込んだ。これは正しい判断だ。
JavaScriptはPCREを見てる。というか本来は取り込みたいのだろうが、上記のように今更部分がありすぎる。
Pythonには歴史的経緯があるのだろう、状況は知らん。
Goは最初から既にゴミだ。確実に廃れるだろうし、俺もそれを願っている。
そもそもGoなんてPCREが覇権取ったあとに出てきたのにPCREを採用してない時点でゴミ。
それ以外にもあの言語は独自路線を行き過ぎていて、ユーザーに無駄な勉強時間を強いている。
結果、既に他言語で慣らした強者が近づかず、結果的に馬鹿の楽園になってWeb系の馬鹿共に大受けしてるだけ。
Goの正規表現については詳しくは知らんが、仮にそれが奇妙な振る舞いをしたとして、お前はGo側の怠慢だと思わないのか？
JavaScriptやPython等それなりの歴史があるのならともかく、Goの場合は確実に防げた問題でしかない。
連中はそれを「わざと」やらなかったんだぞ。俺はそんな言語は支持しないし、ゴミだと何度でも断言する。
いずれにしても、今からの初心者が学ぶべきはPCREだろ。
お前は何が言いたいんだ？
870: 2019/07/14(日)13:05 ID:LdVrbIxu(3/6) AAS
>>869
お前は実装と仕様の違いを理解出来てないタイプだな。
String.matchは「マッチ全部を配列で返す」メソッドだ。
当然、無限ループなんてしてはいけない。
(ただし無限ループしない為に空文字マッチだと一文字進めるパッチだから仕様バグになってるが）
RegExp.execは「gマッチを一つずつ実行し、ユーザーがそこで適宜処理を行う」為のメソッドだ。
当然、何もしなければ順に次のマッチをしていくのが正しく、今現在のように無限ループするようでは駄目だ。
結果、今はユーザーが本来不要なコードを毎回書く羽目になってる。
具体的に言えば、 if (match!=='') が毎回必要になる。これが無駄だ。
JavaScript界隈にはお前みたいな馬鹿が多い。
本来はどうあるべきか、或いは何故この無駄なコードが必要なのか分からず、
今の「実装」が正しいと思いこんでいるタイプだ。
動かさないと分からない、あるいは動いていればいい程度のコードしか書けないからだが。
とはいえ、今回のようなケースに遭遇するとそうなるのも分かる気はするが。
いずれにしても、これはJavaScript環境固有の問題で、ここでは割とどうでもいいと思うが。
お前が正規表現として /(^|[@;])[^@;]*/g を書いたとき、全ての環境で無限ループするべきだ！と思っているのならそれでいいが、
実際はそうではないだろ？なら無駄にいちゃもんつけるなよ。
873(1): 2019/07/14(日)14:15 ID:LdVrbIxu(4/6) AAS
>>871
ああなるほど、Perlも似たようなゴミ実装になってるな。
> そこで，Perl では空文字列に マッチするような場合には，初回は空文字列がマッチするがそれ以降は マッチせずに必ず 1文字分は進むようにマッチしようとする．
これも実装ミスだな。
正しくは、このフラグを「空文字以外のマッチごとにセット」すればいいだけで、修正は1行で済むのだが、こちらも今更なのだろう。
「初回は」というのが間違いで、「空文字にマッチした直後は」が正しい。
ついでにもっと具体的に言っておくと、「初回は」というのが正しければ、
今の実装は検索起動時にフラグをセットして空文字マッチ後にリセットしているはず。
このフラグを「空文字以外のマッチ後」に毎回セットし直すように1行入れる。これで直る。
君がPERL等のOSSか何かにcontributeする気があって修正案を出してくるのなら見てあげるけど。
(俺自身ではそこまでやる気はない)
まあしかし、JavaScriptだけがゴミじゃない、ってのは分かった。
というかもしかしてJavaScriptの実装ってPERL実装互換に敢えてしてる？
>>872
お前は何派なんだよ？
JavaScriptに関してはMDNでも前は「PCREで大体使えます」みたいな事書いてたぞ。
最近大幅リニューアルしてその記述はなくなったが。
(というより色々見にくくなってあまり確認してない）
鬼車派ならこの手の「実装ミス」をひたすら潰しておけばワンチャンあるかもしれんよ。
JavaScriptにしてもPerlにしてもこの辺のミスは確実に足枷になってる。
具体的に言うと遭遇した全プログラマが数時間ずつ無駄に検索その他をさせられる羽目になってる。
これは「新規プログラマ」からすると上達を妨げる障壁でしかない。
JavaScriptで言うと「IEデハー」な件を全部暗記してて今もそれにすがっている奴のウザさみたいなもんだ。
仕様バグがない、というのはそれなりに武器になる。
874(1): 2019/07/14(日)15:13 ID:LdVrbIxu(5/6) AAS
>>867
今更regex101で確認してみたが、PCREだけは（これに関しては）正しく通るじゃねえかよ。
Perlの「初回は」というのはつまり g の時だけおかしくなるということであり、今回は当たらないからだが。
だからJavaScriptも仮にPerl実装互換にしようとしたとしてもしくってるな。
>>871
ちなみに
> > と < は後読みと先読みにして外に出すことができるので
の意味分かる？
おそらくはバックトラックを小さくする為（つまり高速化）だと思うのだが、
実際 regex101で試す限り余計に遅くなる。
テストサンプルはそこの下の「XMLタグを加工する」の上側半分のxmlで、こちらだと
(?:^|>)(.*?)(?:$|<) の場合は 29matches, 1277steps だが
(?:^|(?<=>))(.*?)(?:$|(?=<)) の場合は 29matches, 1875stepsで、余計に遅くなってる。
格好良くはないが別に $1$2$3 で置換しても問題ないと思うのだが。
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は落ち着いたようだが)
外部ﾘﾝｸ:stackoverflow.blog
外部ﾘﾝｸ:news.mynavi.jp
もしかしてPerl6って徐々に使われだしてる？
> perl6では出来る限り最長文字数のマッチを目指す挙動になると聞いたような..
ん？
全てのプログラミング言語では最長マッチがデフォ、
というかそもそも下位の正規表現(BRE等）にはそれしかないが。(non-greedyがない）
XPATH等の文書検索側の人かな？だからって別に特に問題はないが。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s