【PHP】下らねぇ質問はここに書き込みやがれ 15

2024/10/29(火) 20:52:19.15

!extend::vvvvv:1000:512
!extend::vvvvv:1000:512
★スレ立て時 ↑ が3行以上になるようコピペ

PHPに関する質問スレです

前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 14
https://mevius.5ch.net/test/read.cgi/tech/1663659983/

次スレは>>980以降

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

49 (ﾜｯﾁｮｲ 7a74-rPai) · 2025/05/18(日) 21:38:45.86

>> 個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチを取り込むことをおすすめします。
>PHPは互換重視、というより、互換絶対、だ。だから厳しいだろう。

了解です。私は頓珍漢なことを言っていたようです、すみません。

> 昨日mergeしたのか？

いえ、これは私がOnigurumaをforkしたリポジトリでのmargeです。
このmargeは不適切ということでforkしたリポジトリは削除しました、ご指摘ありがとうございました。
(セキュリティ上の理由でforkしたリポジトリは非表示に出来ないようです)

> fix_351_349ブランチ

現時点ではこの動作の切り替えは以下のマクロでしているようです。

#ifdef USE_DIFFERENT_CHAR_LENGTH_MATCH_BY_IGNORECASE
https://github.com/kkos/oniguruma/blob/5d0506c66c4d3613912fa81d7d1b99f83dbea8e2/src/regcomp.c#L4767

>> 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" の選択肢が追加されるという意味だと思います。

49 (ﾜｯﾁｮｲ 7a74-rPai) · 2025/05/18(日) 21:43:53.82

> [r`(?i)^[^\W]$`, 'ss'], // ❌ ← むしろこれがアウトだろ、疑問マーク付いてないが

これはOnigurumaの最適化によって /(?i)^\w$/ として扱われていると思われます。

> // The negation rule is about negation of the outermost class, only 🤔 ←　この解釈が間違いで、
> [r`(?i)^[[^\W]]$`, 'ss'], // ✅ 🤯　←　これと
> [r`(?i)^[\w&&[^\W]]$`, 'ss'], // ✅ 🤯　←　これには俺は問題を感じない

これはおっしゃる通りだと思います、解釈の間違いですね。

> [r`(?i)^s{2}$`, 'ß'], // ❌　← これはヒットするべきでは？

確かにUnicodeの仕様上ではマッチが正しい気がしますね。ただ、こういうケースまで実装で対応するのは大変そうですね。

>「が(0x304c)」と「が(0x304b,0x3099)」... おそらくこの辺もonigurumaは対策されてるのではないかと思う。

テストしてみたところ、Oniguruma6.9.10 (UTF-8) では対応していないようです。
1. "\u304b\u3099" =~ /\x{304c}/ # マッチ失敗
2. "\u304c" =~ /\x{304b}\x{3099}/ # マッチ失敗

49 (ﾜｯﾁｮｲ 7a74-CB35) · 2025/05/20(火) 07:37:47.92

ROMってる方のために補足です。

> 1. 全部諦める ← kkos氏の選択
> 2. モードスイッチでコンパイル時に切り替える
> 3. \U フラグ等で動作時に切り替える
> 4. 現行通り、[\s\S]!==. (つまり現行は中途半端な仕様になってる)
> 5. [\s\S]===. となるように仕様をアップグレードする

これは大文字小文字を区別しない場合の話です。

次に、3. の "\U" について。
Issue 351の以下のコメントでは "\U" を "\w" や "\d" のような文字集合の一種として使っています。
github.com/kkos/oniguruma/issues/351#issuecomment-2816719627
このコメントでの "\U" は全ての1文字にマッチするだけでなく、"ss" や "st" などの特殊な複数文字にもマッチする、という仕様のメタ文字です。

5. の "[\s\S]===." は /[\s\S]/i と /./i が共に "ss" や "st" などの特殊な複数文字にもマッチする仕様にする、という意味です。
Oniguruma6.9.10 では /./i は "ss" や "st" にはマッチしませんが、/[\S]/i はこれらにマッチします。これについては以下のコメントをご覧ください。
github.com/kkos/oniguruma/issues/290#issuecomment-1807145668

Unicode: 特殊な複数文字の詳細
https://www.unicode.org/Public/UNIDATA/SpecialCasing.txt

補足おわり。

2025/05/21(水) 08:08:44.69

Onigurumaってそんなに関心もたれるものでもないんじゃ

2025/05/21(水) 21:44:51.62

>>78
すまん#349読んでなかった。
そして#264も読んだ。

まず全般的にだが、謝る必要は全くない。
君が不味いことをしたわけではない。
俺が偉いわけでもなく、正しいわけでもなく、決定権を持ってるわけでもない。
君は自由に、やりたいことを勝手にやればいいだけ。
俺は勝手にウダコダ言ってるだけ。正直、井戸端会議レベルだ。
GitHubは割とリアルなのである程度まともに振る舞うべきだが、5chでは死ね死ね言ってるくらいで丁度いい。

2025/05/21(水) 21:46:30.75

して#349、もう辞めます！ってか。なんか割と大事(おおごと)だが。
さすがに開発元が辞めてしまったら使用者側としてはどうにも動きづらいだろう。
一般的に、またPHP的に、ありがたいケースは順に、
・辞めるの止めます、で復帰してくれてそのまま開発継続
・主たるcontributorの誰かがforkして、大部分のcontributorがそこに集まって開発継続
・複数のforkでそれぞれ開発が行われ、その中で良さげなものを探して使う
・誰もforkしない、または使えそうなforkがないので、ひたすら現行バージョンを使う
　(バグがあってもそのまま、セキュリティ的に問題があれば落とされるかも？)
かな？
まあ今の採用バージョン知らんが、Version6.9.10を入れてからその先の話だから、だいぶ猶予はあるけども。

しかし唐突というか、なんだかねー。
大体文句しか言われないから、もう疲れたから止めます、あるいは本末転倒になって楽しめなくなったので止めます、は分かるけど、
実装できないので止めます、はねえだろオイ！と突っ込みたくなるよ。
実際のコードは見てないが、
if文によるハードコード(速いが分量が多い)だと多種エンコードに対応するのはほぼ無理ゲーなので、
関数ポインタを編み上げるタイプのソフトコード(という言い方はあまりされないが、最速ではないがあらゆる柔軟性が確保できる)であることはほぼ確実

なので、
いろいろ容赦なく突っ込まれて嫌になったか？とも思う。（どんな仕様でも実装自体は簡単のはず《ただし速度は遅くなるが》)
しかし、言っちゃ悪いが、 s と [s] の動作が違うのは実装が悪いとは思うし、突っ込まれてもそりゃお前のせいだわ、としか。
だからまあ、forkして勝手にしやがれ！俺はもう知らん！もありではあるが。

2025/05/21(水) 21:47:16.93

して、君はこれどうしたい？
普通に考えれば、最新リリースバージョンの Version6.9.10 まではPHPには入る。(いつになるかは不明だが)
だからPHPにVersion6.9.10が入れば満足なら放置でいい。
oniguruma単品で使ってて、あるいはVersion6.9.10でも不満があるのなら、
・まず仕様について積極的にcontributeしてるやつを探し、
・次にコードに対して同様にcontributeしまくってるやつを探し、
そいつらの動向を見て、みんなが集まりそうなforkに寄生して一緒に開発するのがまあ妥当。
何でもそうだが、開発には「仕様」と「コード」に詳しい奴が居ないと厳しい。
だから今の君だけで開発を牽引するのは無理ゲー。
ただし、一人でやる必要はない。
同様に宿り木を探してる連中はいるだろうし、
日本人のプロジェクトだったから日本人トップを望んでる日本人も多少は居るはずだから、
コードの良し悪しを判断できる奴を確保できれば、そいつと組んで、
君が「仕様」側のトップでツートップ/多頭体制で開発継続も可能ではあるだろう。
(すまんが俺はやる気ない。PCREで間に合ってるし、oniguruma使う予定もなく、あってもv6.9.10で十分だし)
まあ5chの正規表現スレ(どこだったかは忘れたが)にたむろしてた連中も大騒ぎしてるだろうし、
そいつらからもリクルートできるのではないかと。
(連中が仕様に詳しいのは確かだが、コードは書けない感じだし、
そもそも人格や報連相に問題があるかもだが、これら含めてOSSだしそんなもん。
開発者がいきなり交通事故で死ぬこともあるのだから、細かい文句を言ってても始まらん)

2025/05/21(水) 21:48:36.13

> 了解です。私は頓珍漢なことを言っていたようです、すみません。 (>>79)
いや謝る必要はまったくない。
ただ、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だからコンパイル時に切り替えだね。
ただコード見る限り、俺が想定してたのとはだいぶ違う。(いいか悪いかは別、というかそこまで読んでない)

> ただ、こういうケースまで実装で対応するのは大変そうですね。
実は動かすだけなら言うほど難しくはない。(現実的な速度が出るかは別問題だが)
ただし分量が死ぬほど多いので、仕様をよく知ってるやつがやらないと話にならない。
(バグ報告〜修正の往復の方が実装の手間を遥かに超えてしまう)

2025/05/21(水) 21:50:00.51

>>82
正規表現ライブラリの問題は、多分「仕様」側と「実装」側が乖離してる事。(これは他の非プログラマ向けソフトも同様だが)
正規表現の使用対象をざっくり二分すると
・ソースコード
・自然言語
で、「実装」側、つまりプログラマは前者なのでasciiが通ればほぼ問題ない。
PHPではユーザー入力やDB登録されてるテキストが後者になるので、多少は取り扱うけども、
基本はGUIのサポートなので、ハズレたらハズレたで問題ない程度でしかない。
それよりは、自動(正規表現はソースコード内)で使うので爆速な事が必要。
「仕様」側、例えば文献検索で小説本文から対象文字列を抜く、回数を数える、みたいな使い方だと、抜けがあったらそれなりに困る。
ßはssにヒットしないと、使い物にならない。
ただこちらは基本的に手動(正規表現は手打ち)なので、人間が我慢出来る速度なら問題ない。

だから、求められる正規表現ライブラリの仕様は、
プログラマ向け：ascii専用でいいから爆速
非プログラマ向け：unicode規約に則った、自然言語対応型。速度は遅くても構わない
で、おそらくonigurumaも基本は前者で、
ついでに後者向けにunicode規約満たしてみたら(多分だが他が全く対応してないので)
自然言語を取り扱う連中には重宝され、あちこちに採用されたはいいが、「これはバグですか？」的な報告が大量に来る事となり、
kkos氏自身はasciiだけで満足出来る側だったので「もう知らん」になったとか、かと(全部推測ですが)

だからプログラマはPCREで満足してて、mb_xxxのonigurumaにはあまり関心がない。
使ってなく、使う予定もないから。

2025/05/22(木) 02:35:12.36

>>78
ご説明ありがとうです。
ChatGPTに聞きながら読んでみたけど、結論正規表現的には日本語はクソって言ってました。
とにかく恐ろしいほどの苦労があることはわかりました。

49 (ﾜｯﾁｮｲ 7a74-CB35) · 2025/05/23(金) 20:54:03.48

>して、君はこれどうしたい？

正規表現についてはもう十分な知識を得られたと思うので次は教えて頂いた通りに
C言語を本格的に始めてみようと思います。以降スレ違いになるのでこちらでお願いします。

c言語教えてくれ
https://mevius.5ch.net/test/read.cgi/tech/1728823763/

PHPスレのみなさまありがとうございました。お邪魔しました。

2025/06/20(金) 15:02:33.00

配列について教えてくださいーーー
DBでSELECTして得た結果を$array1に受けて処理した後にMoveNext()の直前でその配列を$array2にコピーしています。
それによって前の行と内容が同じかどうかを判断したいのです。
しかしMoveNext()をするとコピー先の$array2の内容も$array1と同じように次のレコードに変わってしまいます。
（参照渡しはしてないのです。）
何故なのでしょう！？

$array1 = $db=>Execube (....);
while (!$array1->EOF) {
　if ($array1->fields['xxx'] == $array2->fields['xxx']) {
　　...
　}
　......
　......
　......
　$array2 = $array1;
　$array1->MoveNext();
}

2025/06/20(金) 15:46:56.39

＞（参照渡しはしてないのです。）

参照渡しをしているのによくもそんなことを言えたものだな

2025/06/21(土) 00:25:41.04

あぁ...オブジェクトを値渡しするにはcloneが必要なのですね