【PHP】下らねぇ質問はここに書き込みやがれ 15 (92ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
83: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:44:51.62 ID:/jwTY25H0(1/5) AAS
>>7878(2): 49 (ﾜｯﾁｮｲ 7a74-CB35) [sage] 2025/05/18(日) 12:03:54.19 ID:miJJONwf0(1/3) AAS
>>50
遅くなってすみません、やっと全部把握出来たので少しづつレスしていきます。
>>77
PHPのmbstringのmb_ereg()系の関数に使われている正規表現エンジンのOnigurumaが先月開発終了となりました。
その原因は /\w/i と /[\w]/i の動作が一致しない等の不整合があり、fixが手間的に難しいということでした。
Issue 349: 外部ﾘﾝｸ:github.com
また、この問題とは別に大文字小文字を区別しない時の [\w] などが "ss" や "st" などの複数文字に一致すると
いう仕様 (これはUnicodeの仕様通りの動作) が原因で [\w]+ のように繰り返しなどを使った場合に
バックトラックが大量発生するケースがあり、本来ならマッチすべきケースでもエラーを出して検索が
止まってしまう場合がある、という問題があります。
Issue 351: 外部ﾘﾝｸ:github.com
例えば検索される側のテキストデータに "sssssssss" などが入っていると [\w] に対して "s" 1文字が
マッチする場合と "ss" の2文字がマッチする場合の2種類を試すことになります。
この動作に繰り返し処理が加わることでバックトラックが発生した場合にものすごい試行回数になる場合があります。
50さん(超優秀な方)はこの２つの問題についての見解を書いて下さっています。
この件に関するPHPのてきとうなリンク
外部ﾘﾝｸ:tekitoh-memdhoi.info
外部ﾘﾝｸ:github.com
すまん#349読んでなかった。
そして#264も読んだ。
まず全般的にだが、謝る必要は全くない。
君が不味いことをしたわけではない。
俺が偉いわけでもなく、正しいわけでもなく、決定権を持ってるわけでもない。
君は自由に、やりたいことを勝手にやればいいだけ。
俺は勝手にウダコダ言ってるだけ。正直、井戸端会議レベルだ。
GitHubは割とリアルなのである程度まともに振る舞うべきだが、5chでは死ね死ね言ってるくらいで丁度いい。
84: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:46:30.75 ID:/jwTY25H0(2/5) AAS
して#349、もう辞めます！ってか。なんか割と大事(おおごと)だが。
さすがに開発元が辞めてしまったら使用者側としてはどうにも動きづらいだろう。
一般的に、またPHP的に、ありがたいケースは順に、
・辞めるの止めます、で復帰してくれてそのまま開発継続
・主たるcontributorの誰かがforkして、大部分のcontributorがそこに集まって開発継続
・複数のforkでそれぞれ開発が行われ、その中で良さげなものを探して使う
・誰もforkしない、または使えそうなforkがないので、ひたすら現行バージョンを使う
(バグがあってもそのまま、セキュリティ的に問題があれば落とされるかも？)
かな？
まあ今の採用バージョン知らんが、Version6.9.10を入れてからその先の話だから、だいぶ猶予はあるけども。
しかし唐突というか、なんだかねー。
大体文句しか言われないから、もう疲れたから止めます、あるいは本末転倒になって楽しめなくなったので止めます、は分かるけど、
実装できないので止めます、はねえだろオイ！と突っ込みたくなるよ。
実際のコードは見てないが、
if文によるハードコード(速いが分量が多い)だと多種エンコードに対応するのはほぼ無理ゲーなので、
関数ポインタを編み上げるタイプのソフトコード(という言い方はあまりされないが、最速ではないがあらゆる柔軟性が確保できる)であることはほぼ確実
なので、
いろいろ容赦なく突っ込まれて嫌になったか？とも思う。（どんな仕様でも実装自体は簡単のはず《ただし速度は遅くなるが》)
しかし、言っちゃ悪いが、 s と [s] の動作が違うのは実装が悪いとは思うし、突っ込まれてもそりゃお前のせいだわ、としか。
だからまあ、forkして勝手にしやがれ！俺はもう知らん！もありではあるが。
85: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:47:16.93 ID:/jwTY25H0(3/5) AAS
して、君はこれどうしたい？
普通に考えれば、最新リリースバージョンの Version6.9.10 まではPHPには入る。(いつになるかは不明だが)
だからPHPにVersion6.9.10が入れば満足なら放置でいい。
oniguruma単品で使ってて、あるいはVersion6.9.10でも不満があるのなら、
・まず仕様について積極的にcontributeしてるやつを探し、
・次にコードに対して同様にcontributeしまくってるやつを探し、
そいつらの動向を見て、みんなが集まりそうなforkに寄生して一緒に開発するのがまあ妥当。
何でもそうだが、開発には「仕様」と「コード」に詳しい奴が居ないと厳しい。
だから今の君だけで開発を牽引するのは無理ゲー。
ただし、一人でやる必要はない。
同様に宿り木を探してる連中はいるだろうし、
日本人のプロジェクトだったから日本人トップを望んでる日本人も多少は居るはずだから、
コードの良し悪しを判断できる奴を確保できれば、そいつと組んで、
君が「仕様」側のトップでツートップ/多頭体制で開発継続も可能ではあるだろう。
(すまんが俺はやる気ない。PCREで間に合ってるし、oniguruma使う予定もなく、あってもv6.9.10で十分だし)
まあ5chの正規表現スレ(どこだったかは忘れたが)にたむろしてた連中も大騒ぎしてるだろうし、
そいつらからもリクルートできるのではないかと。
(連中が仕様に詳しいのは確かだが、コードは書けない感じだし、
そもそも人格や報連相に問題があるかもだが、これら含めてOSSだしそんなもん。
開発者がいきなり交通事故で死ぬこともあるのだから、細かい文句を言ってても始まらん)
86: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:48:36.13 ID:/jwTY25H0(4/5) AAS
> 了解です。私は頓珍漢なことを言っていたようです、すみません。 (>>7979(1): 49 (ﾜｯﾁｮｲ 7a74-rPai) [sage] 2025/05/18(日) 21:38:45.86 ID:miJJONwf0(2/3) AAS
>> 個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
>PHPは互換重視、というより、互換絶対、だ。だから厳しいだろう。
了解です。私は頓珍漢なことを言っていたようです、すみません。
> 昨日mergeしたのか？
いえ、これは私がOnigurumaをforkしたリポジトリでのmargeです。
このmargeは不適切ということでforkしたリポジトリは削除しました、ご指摘ありがとうございました。
(セキュリティ上の理由でforkしたリポジトリは非表示に出来ないようです)
> fix_351_349ブランチ
現時点ではこの動作の切り替えは以下のマクロでしているようです。
#ifdef USE_DIFFERENT_CHAR_LENGTH_MATCH_BY_IGNORECASE
外部ﾘﾝｸ[c]:github.com
>> Therefore, choices for elements other than the character class are generated after the character class.
>ちなみにこの意味が分からない。
これは /(?i)[\S]/ を /(?-i)(?:s|t|st|ss)/ とみなす、だと思います。
"s|t" に続いて "st" と "ss" の選択肢が追加されるという意味だと思います。
)
いや謝る必要はまったくない。
ただ、PHP程の歴史があると、仕様変更は結局、
・これまでのコードをメンテしないといけなくなる連中がパニくるため、
・クソ仕様をさっさと更新して欲しい「ご新規さん」は少数派で、多数決的に勝つのは無理
・だからクソ仕様が周知されてて、界隈で「いい加減直そうぜ」とならないと仕様変更されない
(なのでPHP8で修正された事項も『皆さんご存知のクソ仕様』ばかりのはず。onigurumaはこれに程遠い)
> いえ、これは私がOnigurumaをforkしたリポジトリでのmargeです。
> このmargeは不適切ということでforkしたリポジトリは削除しました、ご指摘ありがとうございました。
> (セキュリティ上の理由でforkしたリポジトリは非表示に出来ないようです)
これもGitHubの仕様が全く意味不明だ。
forkはただのローカルコピーだからしていい、というかむしろやるべきだし、
そもそも好き勝手するためにforkするのだから、何やってもfork元には迷惑はかからないし、issueトラッカーに表示されるのもおかしい。
この辺全く知らないが、もしかすると、宿り木を探してる連中のために、
archive化されたリポジトリについては〇〇が引き継ぐみたいだぞ！と見えるようにしてるのかもしれんが、
仮にそうであっても、forkして自分にとって都合のいいmergeを行って何ら問題ない。
(というか、セキュリティ上の理由って何ぞそれ？ではある。垢無しで全世界公開なのにセキュリティもクソもねえ)
> #ifdef USE_DIFFERENT_CHAR_LENGTH_MATCH_BY_IGNORECASE
#ifdefだからコンパイル時に切り替えだね。
ただコード見る限り、俺が想定してたのとはだいぶ違う。(いいか悪いかは別、というかそこまで読んでない)
> ただ、こういうケースまで実装で対応するのは大変そうですね。
実は動かすだけなら言うほど難しくはない。(現実的な速度が出るかは別問題だが)
ただし分量が死ぬほど多いので、仕様をよく知ってるやつがやらないと話にならない。
(バグ報告〜修正の往復の方が実装の手間を遥かに超えてしまう)
87: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:50:00.51 ID:/jwTY25H0(5/5) AAS
>>82正規表現ライブラリの問題は、多分「仕様」側と「実装」側が乖離してる事。(これは他の非プログラマ向けソフトも同様だが)
正規表現の使用対象をざっくり二分すると
・ソースコード
・自然言語
で、「実装」側、つまりプログラマは前者なのでasciiが通ればほぼ問題ない。
PHPではユーザー入力やDB登録されてるテキストが後者になるので、多少は取り扱うけども、
基本はGUIのサポートなので、ハズレたらハズレたで問題ない程度でしかない。
それよりは、自動(正規表現はソースコード内)で使うので爆速な事が必要。
「仕様」側、例えば文献検索で小説本文から対象文字列を抜く、回数を数える、みたいな使い方だと、抜けがあったらそれなりに困る。
ßはssにヒットしないと、使い物にならない。
ただこちらは基本的に手動(正規表現は手打ち)なので、人間が我慢出来る速度なら問題ない。
だから、求められる正規表現ライブラリの仕様は、
プログラマ向け：ascii専用でいいから爆速
非プログラマ向け：unicode規約に則った、自然言語対応型。速度は遅くても構わない
で、おそらくonigurumaも基本は前者で、
ついでに後者向けにunicode規約満たしてみたら(多分だが他が全く対応してないので)
自然言語を取り扱う連中には重宝され、あちこちに採用されたはいいが、「これはバグですか？」的な報告が大量に来る事となり、
kkos氏自身はasciiだけで満足出来る側だったので「もう知らん」になったとか、かと(全部推測ですが)
だからプログラマはPCREで満足してて、mb_xxxのonigurumaにはあまり関心がない。
使ってなく、使う予定もないから。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s