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

2022/09/20(火) 16:46:23.39

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

PHPに関する質問スレです

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

次スレは>>980以降
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

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

2024/06/23(日) 00:56:02.55

なんかわけあって形態素解析ライブラリを作ろうかと思うんだけど辞書はMecabの辞書を使うとしてどうやって解析しようかな
最長一致で比較してマッチしたら抜き出すって方法を考えてるけど皆ならどう作る？

2024/06/23(日) 11:04:07.30

作らない
断る

2024/06/23(日) 11:07:53.98

宿題か？自分でやる方が良いぞ

2024/08/31(土) 14:07:37.82

>>878
flight

2024/09/06(金) 14:19:31.11

PHP v8.0.30で
$LDC=0;
$LDC=ldap_connect($ldhost)
ldap_set_option($LDC,'LDAP_OPT_PROTOCOL_VERSION', 3);
のldap_set_option()行でmust be of type int,string given in~のエラーが出たんだけど3がint値として読めないって言われてるのかな

2024/09/06(金) 16:44:39.99

引数の、どれかだろ

2024/09/06(金) 16:50:09.62

LDAP_OPT_PROTOCOL_VERSIONは定数なんだからクォートで囲っちゃだめでしょ

2024/09/09(月) 18:23:38.31

>>886
言われた通りだったわ
ありがとー

2024/09/23(月) 08:24:39.70

連想配列のarray_merge全然うまくいかんやん
ほんとなんなのこの言語、まじイラつく

2024/09/23(月) 08:30:38.84

できてるけどvar_dumpで表示されてないだけか？
要素数23ってなってるのに15しか表示されん
まじでよーわからん

2024/09/23(月) 09:07:14.03

まず再現コード貼れよ、話はそれからだ

2024/09/23(月) 09:28:56.66

再現コード貼れしか言わない奴は大抵は
十分に与えられた情報を見ても解決できない
無能隠しの時間稼ぎなんだよね

2024/09/23(月) 09:40:34.39

>>891は超絶無能だとは断定出来るね

891がスーパーエスパーなら891の時点で答えを貼るべき
自分では出来ない癖に他人をやたら貶すのは超絶無能な奴の特徴
そもそも本件は、再現コードも数行で済み、それがあれば誰でも回答出来るレベルなので、
本件で「無能隠し」とか言い出す時点で、何が簡単で難しいか判断すら出来ない大馬鹿

2024/09/23(月) 10:16:17.79

十分に与えられているとは思わないけどな
エスパーならできるかもしれんが、普通の人には無理

2024/09/23(月) 11:44:05.43

まあそうこうしてる間に本人は解決してるだろうよ、こんくらいなら
コードなきゃ>>889もイミフだしな

2024/09/26(木) 20:00:35.39

>888-889
エスパーだから答えてあげる。恐らく下のうちのいずれかが原因。つまりPHPは間違えてなくて君が間違えている

1、null値が要素の中に入ってる。nullが入ってる場合は対象の要素を詰めてマージされるよ
2、配列のキーが文字列で指定されていて、配列Aと配列Bで同様の文字列キーを使用している。配列の文字列キーが同じ内容だと後列の文字列キーの配列要素で上書きされるよ。以下は例

$arr1 = ['key' => 'value1'];
$arr2 = ['key' => 'value2'];
$result = array_merge($arr1, $arr2);
// 結果: ['key' => 'value2']

3、配列ではない値を引数に入れてる。array_merge()に配列以外の引数を渡すと警告が発生して予期しない結果になる可能性があるよ。

1と2の合わせ技の可能性もあるな。なんにしてもドキュメント読む癖付けた方がいいぞ。

2024/09/26(木) 20:33:58.69

>>895
いやエスパーすべきは、
> var_dumpで
> 要素数23ってなってるのに15しか表示されん
の部分だと思うが。

そして俺がエスパーするなら、多分初心者用　『教材』　としてどこかの馬鹿が作った、
実用性皆無だが、PHPなりの型変換等で見た目奇妙な動作をする何かを与えられ、
動きを理解しなさい、或いはどうしてそうなるかを説明しなさい、みたいな　『練習問題』　をやらされてるのではないかと。
正直この手の　『クソ課題』　は無視でいいよ、他言語である程度組める実力があるのなら尚更。
array_mergeなんて普通に使ってる分には名前通りの直感的な仕様だし、ハマる所ではない。

PHPはクソだが、クソ糞言うのなら他言語使えばいい話であって、
PHP使うと決めた/決まっているのならクソであろうが使うしかないし、糞な所ばかり気にしてても始まらない。
そしてPHPが糞だと思うのはプログラミング言語と捉えるからであって、Web専用シェルと考えればすごく有用だと気づく。

2024/09/26(木) 22:38:14.36

>896へ
>895の私がエスパーなりの解釈させてもらうw

>できてるけどvar_dumpで表示されてないだけか？
>要素数23ってなってるのに15しか表示されん

「できてるけど」＝array_mergeは機能してるけど、
「var_dumpで表示されてないだけか？」＝var_dumpして23あった要素が15に減ってるのは表示されてないだけか？
「要素数23ってなってるのに」＝あ、ごめん主語無かったねぐへへへwつまり配列を直接var_dumpでデバッグした時は要素数23ってなってるのに
「15しか表示されん」＝array_merge の結果をvar_dumpすると15しか表示されん

繋げると

array_mergeは機能してるけど、var_dumpして23あった要素が15に減ってるのは表示されてないだけか？あ、ごめん主語無かったねぐへへへwつまり配列を直接var_dumpでデバッグした時は要素数23ってなってるのにarray_merge の結果をvar_dumpすると15しか表示されん

いずれにしても>888-889のように話し言葉と書き言葉を一緒くたにしてしまう人や、脳みそと口または手が直結してしまって伝える内容を並び替えできない人とは本気で仕事したくないw

2024/09/27(金) 00:37:53.28

こんなことに数分でも時間つかうのがもったいないw

2024/09/27(金) 01:03:15.09

そのコメント書くのに何分かかった？

2024/09/27(金) 10:54:14.55

エスパーしてる連中がキモすぎる

2024/09/27(金) 16:27:53.83

$a = ["a"=>0, "b"=>1];
$b = ["b"=>1, "c"=>2];
$c = array_merge($a,$b);
var_dump($c);

俺が>>889ならまず最初にこれを疑うかな

2024/10/03(木) 19:40:44.30

netbeans使ってるんですが、こいつが出す警告（モジュールは20行以内にしろ、$_POST使うなとか、クラスは１ファイル１クラスにして名前を揃えろとか）には従っておくほうがいいんでしょうか？
$_POSTなんて入門サイトとか入門書だと未だに主流だし、今の相場がどんなものか知りたいです

2024/10/03(木) 20:14:27.24

netbeansってのは使った事ないから分からないけど「$_POST使うな」は無茶だと思うけどね
あとモジュールも20行以上になる事なんか当たり前にあるよ
実際にソース貼って、その上でどんな警告出てるかも貼った方がより正確に回答出来る気がする
コードの文脈を考えた時に必要無い処理である可能性もあって警告出してくれてるかもしれんからね（知らんけど）

2024/10/03(木) 20:35:40.28

この辺ではなかろうか

「スーパーグローバル$_POST配列に直接アクセスしないでください」

**902** (ﾜｯﾁｮｲ 6f68-2Kaa) · 2024/10/03(木) 20:53:20.38

>>903
>>904
実際のとこ、filterinputを使ったりモジュールは分割したりで回避できてるのですが、もしかしてこんなことやってるの俺だけ？って不安になったので

2024/10/03(木) 20:59:42.10

>>904
netbeans使ってるけどそれだぞ
ちなみに表示は、以下

================================
スーパーグローバル$_POST配列に直接アクセスしないでください。

かわりにフィルタリング関数(例: filter_input()、is_*()関数を使用した条件など)を使用してください。
----
([Alt]+[Enter]キーを押すとヒントが表示されます)
================================

>>902
分からないのなら従うのが常道(＝自分で自信持って不要と判断出来ないのなら従え)
入門サイトとか入門書がゴミなだけ、マジで参考にするのは全部php,netとlaravelにしろ
掲示板なんて簡単ですよ！とか言いつつgetで書き込みとか、死ねな入門サイトはいくらでもある
Qiitaの方がまだだいぶマシ、あいつらは自分でやった事を書いてるだけなので

> モジュールは20行以内にしろ
普通に経験があれば自分で判断出来る、出来ないのなら従え

> $_POST使うな
上記の通り、filter_input使え馬鹿、と出るはず

> クラスは１ファイル１クラスにして
Javaの文化で、つまり慣れの問題

> 名前を揃えろとか
意味不明（必要ないのではなく、何が言いたいのか分からんので判断付かない)

2024/10/04(金) 08:58:20.60

>906
俺は>903だが$_POSTに関して、配列に直接アクセスしてゴニョゴニョすんなよってことね、理解した

>902
ちなみにfilter_inputをバリデーションとかサニタイズで使おうとすると期待してた動作通りに行かないこともままあるから気を付けてね。例としてhtmlタグ取り除きたい時とかは正規表現使って自分で関数作った方が良かったりする。いずれにしてもphpの組み込み関数使う時は必ずphpの公式リファレンス読むようにした方が良いよ

2024/10/04(金) 10:07:59.19

>>907
> 例としてhtmlタグ取り除きたい時とかは正規表現使って自分で関数作った方が良かったりする。
気持ちは分かるが特定のタグを除去したいときは公式DOM使った方がよいかと
単純な末端ノードならいいが、階層作られたらだいたい無理なので
なおボロカス言われてるDOMだが、俺はJSでもjQuery不要派なのでさほど不満はなかった

2024/10/04(金) 11:52:16.55

>908
フロント側でタグを取っちゃうって認識で合ってるかな？自分が基本バックエンドの人間なのでフロント殆ど触らんのよね…w でも提案有難う

2024/10/04(金) 12:00:04.09

ちゃんとしたものを作ろうとすると、本格的ブラウザ作る並に大変笑

2024/10/04(金) 12:14:58.84

phpの話なのにフロントでタグ取り除くとかバックエンドで正規表現使ってタグ取り除くとか意味わからん

フロントでやるならJSの仕事だしバックエンドのPHPなら自分でhtml組み立ててるんだから正規表現使ってhtmlタグを取り除く必要とかそもそもない

2024/10/04(金) 12:48:49.83

>>909
htmlタグを取り除く＝PHPでスクレイプ、或いは掲示板等で許可してないタグを投稿されたときに、PHPでタグを除去する場合を考えている

PHPのDOMはゴミ扱いされてるが、ほぼ生JSと同じなので個人的には問題なかった
正規表現は階層/入れ子を考慮されてないので、正規表現でhtmlをパースするのは死ねるし変な物を食わされたらだいたいバグる
とはいえDOM構築はそれなりに遅くなるので、スクレイプ先のhtml構造が単純かつ固定的なときは正規表現で除去するのもあり
フロント側に不要タグ含めて垂れ流すのもありだが、DBやネットワークの帯域を無駄に消費するだけなので、
可能であれば上流＝PHP側で除去した方がいいのは事実

2024/10/04(金) 13:33:27.23

filter_input使えって警告、PhpStormでは見たことないな
運良く推奨されるパターンでも踏んでるのかな

2024/10/04(金) 14:14:38.35

>>913
IDE内部のリンターなので、直接関係ないのと、
あったとしても普通に切れる

2024/10/04(金) 16:00:15.82

>>912
PHPでスクレイプ時に特定のhtmlタグを取り除くってレアリティ高いな

そっちはいいとしてユーザー入力に許可されてないタグがあるならエラー返した方がいいと思うが除去するにしてもstrip_tagsやHTMLPurifierみたいな出来上がったものを使った方がいいのでは？

あとフロントでタグ除去するのはユーザーアクションに応じてhtmlを変更するためで不要タグを垂れ流してるわけではない

2024/10/04(金) 19:01:50.57

>>915
> strip_tagsやHTMLPurifierみたいな出来上がったものを使った方がいいのでは？
これらはいいね
言及出来なかったのは俺が単に知らなかったからで、タグ単位の除去にはこれらを使うべきだろう

> レアリティ高いな
そうでもないから上記の関数/ライブラリが整備されてるわけだ
ただPHPはこの手の、あると便利だが的な関数が無駄に多く、把握しきれてなかったのは上記の通り

> ユーザー入力に許可されてないタグがあるならエラー返した方がいいと思うが
相手がまともな人間の場合はそうだが、
攻撃目的で掲示板にタグを書き込んでくる場合、晒しの意味でも黙って落としてそのまま表示させるのもあり
瞬時にエラーを返してしまうと、何がどこまで駄目なのかすぐばれてしまう
何だかんだで無駄に時間をかけさせるのは地味に有効

> あとフロントでタグ除去するのはユーザーアクションに応じてhtmlを変更するためで不要タグを垂れ流してるわけではない
それは俺に言わせれば、(使う可能性のあるタグなので)仕様上サーバー側では落とせない、となる
サーバー側で落としておくべきなのは、どうやっても不要なタグ、具体的に言うとscriptとか、
或いは公式strip_tagsの警告に書かれてるとおり、onXXXX属性
ただstyle属性まで落とすと、タグを許可した意味が無くなってくるので、判断は難しいところ
opacityとかだけは許可しない等、属性も精査する気だと、結局DOM使う事になるとは思うが…HTMLPurifierでも出来るらしい
まあこの辺は要調査だな

2024/10/04(金) 19:47:14.07

>911
どう言うこと？w
PHPでデータベース扱ってる現場ならバックエンドにデータ飛んでくる前にタグ取り除くでしょ
俺の場合はPHPのユーザー定義関数で正規表現使ってタグ取り除く関数を作ったらhtmlのフォーム内でバリデーションとサニタイズ行なってるけど

>自分でhtml組み立てるんだから
分業してる現場なのでJSはフロントの子がやってるのよ
だからフロントは殆ど触らないし関数作ったらフロントの子に渡してる

2024/10/04(金) 19:48:47.53

>917
× htmlのフォーム内でバリデーションとサニタイズ行なってるけど

⚪︎ htmlのフォーム内に適宜関数を挿してバリデーションとサニタイズ行なってるけど

2024/10/04(金) 20:30:24.85

>>917
俺宛ではないが、>>911の使い方はまあ普通、というか9割以上の局面ではそうなる

> バックエンドにデータ飛んでくる前にタグ取り除く
そもそもDBへのアップデータでタグを許可してない/する必要ないのがほぼ全部
例えばここ5ch、安価は最終的に<a>として表示されるが、ユーザーの投稿段階ではただのテキスト
それをDB登録段階で<a>にしてしまうか、JSで<a>にするかは実装によるが、PHPでタグ除去なんてする必要がない

> PHPのユーザー定義関数で正規表現使ってタグ取り除く関数を作ったら
> htmlのフォーム内に適宜関数を挿してバリデーションとサニタイズ行なってる
> だからフロントは殆ど触らないし関数作ったらフロントの子に渡してる
もしかしてEmscriptenかWebAssenbly使ってPHPのコードをクライアントサイドで動かしてる？
それはすさまじくレアだと思うのだけども

2024/10/04(金) 21:11:39.79

>919
>PHPでタグ除去なんてする必要がない
これは自分の言葉足らずでしたわ。謝ります
ユーザーからのhtmlタグの投稿を一切許可していない現場なのよ、だからタグはDB到達前に全部サニタイズしてる

>もしかしてEmscriptenかWebAssenbly使ってPHPのコードをクライアントサイドで動かしてる？
いや、素のPHP（Laravelとかのフレームワーク使わず）でコード書いてて、ライブラリ含めて全てフルスクラッチで作成してる現場だよ

2024/10/16(水) 16:44:48.13

先生！PHP独学したいのですが
独習PHP 第4版　山田祥寛 (著)
これでいいですか？

C#
Java
VBA
JavaScript
経験者です

2024/10/16(水) 22:44:42.10

>>921
php.netを頭から全部読めばそれで十分
多分SQLも必須、というかPHPは自身の変数等を保持する機構が言語にないのでどうせDBを使うことになる

2024/10/17(木) 00:25:58.27

>>922
本物のワルなのでセッション使っちゃうぜ

2024/10/17(木) 00:33:42.25

>>922
先生！ぼくおじさんなので本にｶｷｶｷメモしながらじゃないと勉強できません
後出しですがSQLも基本的なところはできます
独習PHP 第4版が古すぎるとかいうのでなければよいのですが

2024/10/17(木) 08:25:20.34

>>923
ユーザーまたげねえだろ
というか普通のサーバーのように、全体の変数を保持する事が出来ない
だから毎回初期値やデータを一からロードし直す必要があってウザかったが、
JSもクローム拡張V3では同様になってるから、サーバーとしては適切な構造なのだろうよ
PHPの場合、これにより毎回最初から行うのを強制され、結果的に毎回同じ動作となり、デバッグしやすくなってるのも事実
糞言語だが、何だかんだで結果的によく出来てるから使い続けられてる

でもやはりウザイのも事実で、Node他ならもうちょっとすっきり書けるのに、というのは多々ある
ちょっとした配列を保持出来てれば済むのに、一々DBにtry-catchになるから

>>924
持ってないから知らん

2024/10/17(木) 08:51:18.77

>>925
セッションIDを知っていればユーザーを跨げるので、本物のワルはこれを悪用しちゃうぜ

2024/10/17(木) 09:15:02.73

>>926
いやそれはアウトだろ
ただ、「絶対に誰にも使われないセッションID」を作れれば便利な倉庫に出来るのかな？
まあ俺はそこまでPHP知らんので止めとくが

しかしPHPは色々糞ったれなことが多い
今目に付いてるのはアップロードされたファイルが $_FILES["pictures"]["tmp_name"][$index] に入る点
逆じゃボケ！！！$_FILES["pictures"][$index]["tmp_name"] に入れろや！！！ってね
この辺一々糞コード化を余儀なくされてストレスが溜まる
まあlaravel導入すれば解決するんだろうけどさ

2024/10/17(木) 23:09:44.41

>921
私見で恐縮だけど、それだけ他言語を学習済みなら（経験年数にもよるけど）基礎的な事は理解してるはずだから書籍はあんまり意味を為さないと思うなー
①他の人も言ってるようにリファレンス読み込むのがいいと思う。どのページに何が書いてあるか理解把握するのが大事かな、と。あくまで重要なのはリファレンスの内容を覚えるんじゃなくて、必要な時に直ぐに取り出せるように「何処に何が書いてあるか」を理解把握すると良いと思うよ。例えばphp7系とphp8系で大幅に仕様変更があったんだけどその差異を見るにはどのページ見れば良いかとか、もっとシンプルに言うと関数のリファレンスは何処に纏まってるか、とか。
①の手順が終わったら、プログラム経験者でphp手っ取り早く学びたいならLaravelの環境を構築するかまたはWordPress作って弄り倒すのが良いと思う。
前者の理由は、ここ数年のphp開発現場はLaravelを基本としてるから。
後者の理由は、WordPressはphpで構成されているのでソースレベルで弄り倒せるようになれればclassや一通りの組み込み関数も理解出来ていると判断できるから（俺社比）

若干話変わって個人的に興味があるのは、何故phpを学習したいと思ったのかを知りたいな
聞きたい理由としては、phpって言語としても旬は過ぎたし、もしWordPressが使われなくなったらレガシーな環境を除けばphpを選択する意味が無くなってきてると個人的に感じてるのよね。（俺自身はphp好きだけどw）

例えば最近ならNode.js＋TypeScript＋.vueとかの方が需要高いから何故phpを学ぼうと思ったかその機会を知りたいと思いました。長文スマンでした

2024/10/17(木) 23:37:25.31

横レスおじさんだけどごめんね❤

>923 については、確かにセッション使えば自身の変数は保持できる

>925 に対しては、おっしゃる通りユーザ跨げない。後述（※参照）するけど、ユーザー跨ごうとすると変則的な運用のみ使えると思う（という知見しか自分には無い）から結論非常にオススメしない。

>926 マジでオススメしない。理由はセッションIDを対象ユーザー以外で使うのは大事故に繋がるから。
（※）一応例外も挙げておくけど、【そのサービスを1人しか利用しない】という前提ならもしかしたらありかな？とは思う。逆を言えばそれくらいのレベル感じゃ無いとセッションIDの使い回しは超御法度。
つまり非常に限定的で、ローカル環境で構築したサービスや外部非公開の環境というのが前提で、もし外部に公開するサービスならセッションIDは絶対に使い回しちゃダメよ、って事。

2024/10/18(金) 07:32:13.18

>>928
> レガシーな環境を除けばphpを選択する意味が無くなってきてる
商用ならその通り
ただしレンタルサーバーのような小口だと、プロセス2秒でぶった切る運用が出来るPHPの方が相性がいい
だからブログにはPHP+WPの方が相性がよく、
今のところ他言語では…そういえばHugoとかあったがあれどうなったんだろ？

ちなみにphp.net、読み物としては非常に優秀だが、リファレンスとして逆引きするにはイマイチだと分かった
だから一通り知って、しばらく使わずに忘れて、再確認したいときに
> 何処に何が書いてあるか
を覚えておかないと辿り着けない
(逆に他言語は逆引きするように書いているから、頭から読む読み物としてはイマイチ)

2024/10/18(金) 08:54:50.32

>930
うんうん、小口の場合は確かにphpですね。個人からの依頼や企業でも小規模なWEBページの依頼はphpが未だに多い印象。
php.netはそうなのよ、読み物としては立派なんだよね。phpの設定関連は読み込むと理解把握しやすい。一方で「この機能を実現する組み込み関数ってあるかな」と逆引きしたい時や、「ソース書いてて躓いた時、詰まった時」はあんまり役に立たない印象。
そこで次はどうするかというとネット記事（個人ブログ含）に行き着くんだけど、php関連のネット記事って有象無象入り混じってて特殊なアプローチ（裏技的な内容）やセキュリティガバガバのソース提示されてるから初学者はネット記事参考にしない方が良い、というね。
やっぱり実際の業務で学ぶか、WordPress作って理解するか、GitHubで学ぶとかがいいかなーと思う

2024/10/18(金) 14:05:17.56

>>931
内容については全文同意でいいが、>>924に戻ると、

php.netは読み物としてはMDN/MSDN/Oracleと比べて段違いにいいので、
紙好きであっても初手として通読する事を進める(他言語のリファレンスを想定しているのなら特に)
どうしてもというなら全文印刷して読め、それくらい良質だ

一方で
> php関連のネット記事って有象無象入り混じってて特殊なアプローチ（裏技的な内容）やセキュリティガバガバのソース提示されてるから初学者はネット記事参考にしない方が良い
これは本当にその通りで、理由はPHPが糞言語でろくなコードが書けないというのも多々あるが、(927参考)
JSも相当に酷いので、「主戦場がWebなので(技術的/気分的に)『初心者にも』情報発信しやすい」のが主な理由だろう
Web系は馬鹿しかいないというのも通説ではあるが、
実際の所Cなんて仕事化されない限り(例えば大学の準教授で講義内容を公開するとか)上級者でもWeb記事なんて書かないから、
記事書いてる時点で大半は教える事が仕事として成立する程度のフィルタがかかってるので全然違う

(すまんがNGワード規制に引っかかるようなのでバラバラに落とす)

2024/10/18(金) 14:06:19.93

ではどうすればいいかといえば、俺は「レビュー済み」のコードを参考にする事を勧める

2024/10/18(金) 14:07:10.73

俺は上記の通り、JSではMDNのコードしか信用しない事にしてるが、それは「MDNは多数に見られてる」からだ（＝酷いコードは修正済み)
StackOverflowが良質なのも、各回答がレビューされて上位順に並ぶからだ

2024/10/18(金) 14:07:41.36

この点、php.netは同様に、各ページの下にコードがずらずらと『上位順』に並び、
結果的に各ページにStackOverflow並の上質なコードが付随する事になってる

2024/10/18(金) 14:08:32.58

初学者であれを全部読むのは辛いだろうが、あのコードも読む価値があるので余裕があれば読むべき

2024/10/18(金) 14:09:03.23

大体において各ページの機能のハマりポイントをコードで解説してある

2024/10/18(金) 14:09:27.64

面倒なら、ハマったときにはググると同時にphp.netのその機能のコードも読む事だ

2024/10/18(金) 14:10:14.73

ちなみに引っかかったらだいたいググるとQiitaで何とかなる事が多いはず
Qiitaも勿論いいサイトではあるが、結局「上位順」ではないので、StackOverflowに成れなかった、というより成り損ねた感がある
これは10年ほど昔にJS界隈でKenOkabe、通称「毛の壁」が、
細かい間違いを修正するよう突っ込みまくってウザがられて荒らし扱いされ、結局コメント機能が削除された、という経緯があるらしいが
結果的に「よりよいコード、より正しい情報を発信する」(StackOverflow的価値観)より、
「僕が気持ちよく情報発信する」(ゆとり世代的価値観)を優先したので、そうなってる
まあ創始者がゆとり世代だし、この判断が間違ってるかどうかも微妙で、例えば商業的意味なら「成功」となるのだが、
とにかく現状ではQiitaは玉石混淆、というよりゴミの方が多いので要注意
それでもないよりは100万倍いいので、素晴らしいサイトではあるけども

2024/10/18(金) 14:11:06.01

これはQiitaのユーザーの問題というよりは、やはりレビューされてない事によるものだと思ってる
同様にGitHubでも個人レベルで公開してるのは、公開の場所が違うだけで、同様に糞コードの地雷原でしかない

2024/10/18(金) 14:11:36.87

ただ世界的に超有名なOSS(勿論GitHub上)でも超絶糞コードな事に遭遇した事があるので、（なおC言語)
OSSで多数に見られてればコードの質が上がる、ということでもないらしい

2024/10/18(金) 14:11:54.86

結局はレビュワーによるのだが、OSSでレビューで落としたら関係がそれなりに悪くなるらしいので、
長期戦略を考えたら糞コードもなかなかに落としづらいというのはあるのかもしれない

2024/10/18(金) 14:12:12.67

この点、PHP自体もOSSの産物だから、はっきり言って機能がデタラメで統一感もなく、
大手がガッツリ整備してる他言語(C#/Java等)と比べたら色々チグハグだが、
これもそういうものだと認識して諦めるしかない
文句があるならお前が直せ、のOSS文化そのままだ
とはいえPHP8には表面的には機能が揃ってる感はあるが

2024/10/18(金) 14:14:03.60

…多分「コード」がNGワードっぽい

2024/10/18(金) 18:47:58.42

ここは毛の壁の落書き帳です

2024/10/18(金) 20:59:29.50

実際の所俺は、毛の壁が超えた、ゆとり世代的レッドラインがどの程度なのかは知りたいんだけどね
Qiita上では綺麗さっぱり消されてるので確認出来ないし

まあ言いたい事は、
つべこべ言わずpnp.netを読め、そして各ページのコードも読め、だ
他言語の常識でpnp.netを忌避するのは、勿体なさ過ぎる

2024/10/21(月) 10:50:17.35

環境: PHP 8.3.6, ubuntu24.04 LTS, oniguruma 6.9.9

mb_ereg_replace() に使う正規表現の中で (*FAIL) が使えません
PHP側で (*hoge) の形の正規表現パーツを無効化しているようですが
もし使えるようにする方法があれば教えて下さい
最近 oniguruma に (*SKIP) が実装されたので正規表現の高速化のために使いたいです

mb_ereg_replace()
https://www.php.net/manual/ja/function.mb-ereg-replace.php

2024/10/21(月) 11:21:53.55

知らんが常識的にはdllを差し替えるだけでは？

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/21(月) 12:10:55.14

>>948
ありがとうございます、PHPで使われている正規表現ライブラリは最新のものでした

$ php -i | grep "onig"
Multibyte regex (oniguruma) version => 6.9.9

PHP側が古い可能性もあるので一応 PHP 8.4.0 RC2 を試してみます

2024/10/21(月) 12:46:44.10

>>949
6.9.9が最新ならお前は多分勘違いをしてるぞ

> Master branch
> Update Unicode version 16.0
> Add new operator (*SKIP)
>
> Version 6.9.9
> 以下略
> https://github.com/kkos/oniguruma
この書き方なら、『開発中の』Master branch(=6.9.10としてリリースされるであろう物)には入ってるが、まだリリースされてない
つまりどのPHPバージョンにも普通は入ってない
だから自分でonigurumaをコンパイルして差し替える必要がある

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/21(月) 13:48:46.27

>>950
onigurumaの差し替えはやる予定でした、そこに気付かれるとは..すごい

しかし (*FAIL) すら使えないのでonigurumaの差し替えをしても意味が無いんです
恐らくPHP側で無効にしていると思われるのですが有効にする方法をどなたか..

2024/10/21(月) 14:34:37.43

>>951
> やる予定
それは実際に試して言ってる？

一般的にdllは呼ぶだけで、その前の段階で前処理なんてしない
というかそれやったら、PHP側のコードをonigurumaのバージョン毎に変えないといけなくなるだろ
無駄に依存性が増えるだけになってしまう
他ライブラリなんていつどう更新されるかも分からないのに

だから普通は差し替えれば動くだけ
動かないのであり、かつその原因がそちらの予想通りPHP側にoniguruma特定バージョン用のパッチが当ててある場合は、
php.iniにそれを切る為の設定が(一般的には)あるはず

でも繰り返すけど、普通はそうはせず、差し替えたら動くだけ、差し替えなければ動かないだけ、だと思うよ
動かないなら、そちらの設定間違いで、うまくdllを掴めてない可能性の方が高い
実際その(*FAIL)がどういう機能か知らんが、 (* 自体は対応してないとエラーになるでしょ
普通はそのエラー自体もライブラリ、つまりonigurumaやpeclに判定させて、throwさせるものだから

2024/10/21(月) 15:05:17.60

>>952 訂正

× pecl
○ pcre

分かる範囲だがphpにはpeclもあるようなので…

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/21(月) 15:21:24.44

>>952
>それは実際に試して言ってる？
実は最初から最新の Master branch (3237 commits) しか入れていません
つまり oniguruma 6.9.9 のリリース版を使っていません
このことを忘れてました、リリース版でも確認してみます、すみません..

そういうものですか、なるほど
php.ini と oniguruma 側の確認もしてみます
お時間取らせてしまって申し訳ないです、ありがとうございました

2024/10/21(月) 15:30:29.11

>>954
> リリース版でも確認してみます
いいね、これで確認出来る。差が出ればdllは当たってる
あとは、サーバー側の設定は別のはずなので、コマンドでは動くがサーバー上では動かない場合はこれ

2024/10/21(月) 20:10:27.85

>947

preg_replaceで代替どうぞ

$pattern = '/foo(*SKIP)(*FAIL)|bar/u';
$replacement = 'baz';
$subject = 'foobár';

$result = preg_replace($pattern, $replacement, $subject);

echo $result; // foobaz

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/21(月) 20:30:30.28

>>955
リリース版でも試しましたが結果は変わりませんでした、 (*FAIL) は使えませんでした
リリース版でも Master branch の最新版でも oniguruma 単体では (*FAIL) を使えます

php.ini にも (*FAIL) などを無効化するような設定は見当たりませんでした
PHPをコンパイルする前のソースも見てみたのですが該当しそうな場所を見つけられていません

しかしまだまだ調査不足なのでもっと調べてみます
もしかしたら思いもよらない場所にある古い oniguruma ライブラリを参照している可能性もあります
何か分かりましたらまた来ます、今日は色々教えて頂きありがとうございました！

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/21(月) 21:31:17.66

>>956
すいません！レスに気付いてませんでした！
頂いたコードで (*SKIP)(*FAIL) が正しく動作しているのを確認出来ました

しかし私は mb_ereg のほうを使わなければなりません、正規表現で UTF-8 以外の
エンコードを使うためです、せっかく作って頂いたのに申し訳ない..

> á
おお、 /u はこんな挙動するんですね、勉強になります

2024/10/22(火) 07:31:12.59

>958
なるほどね理解しました。根本的な解決に向けての助力は他の方が回答してくれてるので、俺は一時的な回避策（w）を提示するよ。その場凌ぎなので悪しからず

$original_encoding = 'SJIS'; // 例: Shift-JIS など

// 文字列を一時的に UTF-8 に変換
$subject = mb_convert_encoding($subject, 'UTF-8', $original_encoding);

// preg_replace を利用して (*SKIP)(*FAIL) を使った正規表現を適用
$pattern = '/foo(*SKIP)(*FAIL)|bar/u';
$replacement = 'baz';
$result = preg_replace($pattern, $replacement, $subject);

// 結果を元のエンコーディングに戻す
$result = mb_convert_encoding($result, $original_encoding, 'UTF-8');

echo $result;

2024/10/22(火) 08:51:20.86

>>957
それだと、用意したdllは使われておらず、どこかにある古いonigurumaを掴んでいるように見えるな
なら、今掴まれているdllを特定して、そのファイルと差し替えるのが一番早いかと

windowsなら実行中の各プロセスがどのdllファイルを掴んでいるかはprocessExplororで簡単に分かるが、
Unixだと聞いたことない(…が、あるんだろうけど)
ググるとlddで静的解析は出来るらしい（使ったこと無いが)
ただこれは自分でコマンドとして起動する場合用だから、
apache/nginxを起動してるユーザーで実行すれば命中するが、ただのユーザーではいまいちだな
https://stackoverflow.com/questions/50159/how-to-show-all-shared-libraries-used-by-executables-in-linux
https://linux.die.net/man/1/ldd
(実際色々変わってるらしいので何ともだが、昔と同様の起動形態だと、
rc*.dを改変してapache起動直前にlddすれば確定する《はず》)

あと、xampp環境だと php_mbstring.dll というものがある
これがonigurumaかどうかは分からないが、そうだった場合、php_*となっているのは通常、
「そのものではなく、php側が用意したラッパをつけた状態でdllにした」ことを意味するので、
oniguruma単体ではなく、ラッパつけて再コンパイルする必要があるかも

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/22(火) 21:24:40.11

書き込み規制が出たので簡素化して書きます
mb_ereg_replace() で (*FAIL) が動かない原因は oniguruma のライブラリの
バージョンが古いという問題ではありませんでした
oniguruma 6.6.0 で追加された (?W) が使えない一方で 6.9.5 で追加された
\x{HHHH HHHH} が使えるなどバージョンの違いでは説明出来ない動作がたくさん確認出来ました

この問題は恐らく解決が困難だと思うので諦めます
お二方、お付き合い頂きありがとうございました、勉強になりました、感謝です

2024/10/22(火) 22:48:01.75

>>961
お疲れ
すんなり行かない場合はかなりハマる案件なので、判断は妥当だと思う
なおオープンソースの新機能周りってわりと普通にバグってるので、意味不明な場合はこれかも

2024/10/23(水) 06:42:46.86

>>961
そういえば書き込み規制の件、
もしまだ原稿が手元に残ってるなら、
多少読みにくくてもいいから、バラバラにするなり、他板のテストスレに落とすなりしてもらえないだろうか
情報が有るのと無いのでは全然違うので、俺は読むから

コピペ規制なら、例えばmango板は規制チェックの為の板なので、落とせるし
agree.5ch.net/test/read.cgi/mango/1715675838/

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/23(水) 14:05:07.85

現時点では php-mbstring の問題だと思っています
これはPHPに後から追加するPHPの拡張モジュールです、このモジュールが oniguruma の
ライブラリのファイルを参照します

oniguruma は各正規表現パーツごとに有効、無効を切り替えられる仕様になって
いるのですが、oniguruma を呼び出す php-mbstring 側で (?W) や (*FAIL) が
有効にされていない可能性が高いと考えています

以下のページは oniguruma の各パーツごとのオプション名を説明するページです
s://github.com/kkos/oniguruma/blob/master/doc/SYNTAX.md

このページを "Set in:" でページ内検索すると各パーツがどのプログラム言語用の
正規表現ルールに適用されるかが分かります

(?W) は 30番目の ONIG_SYN_OP2_OPTION_ONIGURUMA というオプションを
有効にすると使えるのですが、これが適用されるルールは「Set in: Oniguruma」と
書いてあるので正規表現ルールを "Oniguruma" と指定しないと使えません

しかし php-mbstring のソースを見てみると選べる正規表現ルールの中に "Oniguruma" は
ありませんでした、つまり正規表現ルールを "Oniguruma" に変更出来れば (*FAIL) なども
使えるようになる可能性があります(そう簡単に上手くいくとも思えませんが)

2024/10/23(水) 14:05:25.05

その辺まで行くとissue読み漁らないとたどり着かない領域かもね

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/23(水) 14:43:46.47

あと、話を簡素化するために嘘を書いてしまったので訂正します
php-mbstring ライブラリが参照している oniguruma ライブラリを教えて頂いた
ldd コマンドで調べたところ、以下のように別ファイルを参照していました

php-mbstring が参照していたパス
/usr/lib/x86_64-linux-gnu/libonig.so.5.4.0

私が入れた oniguruma ライブラリのパス
/usr/local/lib/libonig.so.5.4.0

php-mbstring が参照していたライブラリのファイルサイズは私が入れたライブラリの
半分ほどだったので恐らく古いライブラリだったのだと思います
そこで php-mbstring が参照しているライブラリを最新の Master branch のライブラリに
置き換えて (*FAIL) が使えるかを試してみましたが結果は変わらず、使えないままでした

>>948 でご指摘して頂いたことは的を射ていたということになります
お詫びして訂正致します、すみませんでした

2024/10/23(水) 22:17:15.79

>>966
いや全く謝る必要はない
その辺まで行ってる時点で大したもんだし、よく言われてる「報告」についても、君はよく出来てるよ

> oniguruma は各正規表現パーツごとに有効、無効を切り替えられる仕様になって
> いるのですが、oniguruma を呼び出す php-mbstring 側で (?W) や (*FAIL) が
> 有効にされていない可能性が高いと考えています
なるほど、これを知ってたから最初から無効化を疑ってたわけね
俺は知らなかったから、一般論で答えてしまったが
正規表現の場合は互換性が問題になるから一々細かくやらないと駄目なのかもね

> 正規表現ルールを "Oniguruma" と指定しないと使えません
これは微妙にちと違っていて、あの書き方だとただ単にフラグだから、C的にありがちなのは、以下α
(最近使ってないなら文法間違ってるかもだが)

多少行儀のいい場合：α
#define ONIG_SYN_OP2_OPTION_ONIGURUMA 0x04000000 // oniguruma内
onigSyntaxType.op2 |= ONIG_SYN_OP2_OPTION_ONIGURUMA; // php_mgstring内

あるいはドベタに：β
onigSyntaxType.op2 |= 0x40000000; // php_mbstring内

"Oniguruma"指定の場合は、多分：γ
OrigSyntaxType Oniguruma = {0xfff7d556, 0x47eb7bd2, 0x87a00bdb}; // oniguruma内
OrigSyntaxType origSyntaxType = Oniguruma; // php_mbstring内

要するにビットを立ててるだけなので、op2の[30]を立ててしまえば使えるようになる
Oniguruma指定は一番手抜きが出来て楽だが、
php_mbstringの機能追加タイミングがOnigurumaのバージョンアップと同期してしまう
だから互換性を重視しつつ、必要なタイミングで上位機能を取り込みたい場合は、普通はαにする
そして結果的にOniguruma指定と同じになる事を(長期的に)目指す

2024/10/23(水) 22:18:06.80

なので検索する場合は、Onigurumaが無ければ、
ONIG_SYN_OP2_OPTION_ONIGURUMA　を探し、それもなければ
0x を探す(一応0Xでもいいらしいのでそれも)

とまあ、ここまで書いてると、「そこまで言うならお前が見ろや！」なので見てみる
最新版とか知らんのでpnp.netのdownloadページの8.3.12をDLした(CurrentStable)
ああ俺は、他人のコードを読み足りない、と認識してるから、こういう機会があれば読む事にしているだけだ
今風に言えば、べっ別に、あんたの為に読んだ訳じゃないんだからね！！！(だが男だ)

さて上記検索試すが、空振る。そして後付ではあるが
php-8.3.12>grep -n -r -i OnigSyntaxType *
ext/mbstring/php_mbregex.c:62: OnigSyntaxType *regex_default_syntax;
ext/mbstring/php_mbregex.c:455:static php_mb_regex_t *php_mbregex_compile_pattern(const char *pattern, size_t patlen, OnigOptionType

options, OnigSyntaxType *syntax)
ext/mbstring/php_mbregex.c:489:static size_t _php_mb_regex_get_option_string(char *str, size_t len, OnigOptionType option,

OnigSyntaxType *syntax)
ext/mbstring/php_mbregex.c:595: OnigSyntaxType **syntax)
ext/mbstring/php_mbregex.c:997: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1268: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1332: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1463: OnigSyntaxType *syntax = NULL;
ext/mbstring/php_mbregex.c:1591:static void _php_mb_regex_set_options(OnigOptionType options, OnigSyntaxType *syntax, OnigOptionType

*prev_options, OnigSyntaxType **prev_syntax)
ext/mbstring/php_mbregex.c:1608: OnigSyntaxType *syntax, *prev_syntax;
当たり前だが、変化する値側ではなく、固定的な型名で検索するべきだった

2024/10/23(水) 22:19:18.35

そして順当なら php_mbregex.c:1591:static void _php_mb_regex_set_options なので見てみる
prevをデフォに戻して新しい値をセットするだけのようだ
そもそもprevが何故いるのか？はかなり疑問だが、まあいい
とにかくビットを立ててしまいたいだけなら、ここを改造して、上記βしてしまえば、ここを通る限り常にビット30が立つようになる
コンパイル通るかどうか知らんが、例えば具体的には、

MBREX(regex_default_options) = options;

MBREX(regex_default_syntax) = syntax;
(*syntax)->op2 |= 0x40000000; // これを最後に追加

MBREXはマクロ
#define MBREX(g) (MBSTRG(mb_regex_globals)->g)
MBSTRGもマクロ
mbstring.h:118:#define MBSTRG(v) ZEND_MODULE_GLOBALS_ACCESSOR(mbstring, v)
ZEND_MODULE_GLOBALS_ACCESSORもマクロ
Zend/zend_API.h:255:#define ZEND_MODULE_GLOBALS_ACCESSOR(module_name, v) ZEND_TSRMG(module_name##_globals_id,

zend_##module_name##_globals *, v)
Zend/zend_API.h:270:#define ZEND_MODULE_GLOBALS_ACCESSOR(module_name, v) (module_name##_globals.v)
2つ出るのは#ifdefと相場が決まっており、今回も#ifdef ZTS らしいが、ZTSってなんだっけ？
まあとにかくこの辺はここまででいい、とにかく更新してるだけっぽいし

2024/10/23(水) 22:21:26.39

その他、
ext/mbstring/php_mbregex.c:489:static size_t _php_mb_regex_get_option_string
ext/mbstring/php_mbregex.c:594:static bool _php_mb_regex_init_options
とか、いかにもなので君には分かるだろう
真面目に直すのならこの辺だね

ちなみに regex_default_syntax を修正してもいけるはず。これは
ext/mbstring/php_mbregex.c:84:pglobals->regex_default_syntax = ONIG_SYNTAX_RUBY;
とモロクソに書いてある
君の読み通りなら、そこを

pglobals->regex_default_syntax = ONIG_SYNTAX_ONIGURUMA; // RUBYからONIGURUMAに変更
ついでに
ext/mbstring/php_mbregex.c:601:*syntax = ONIG_SYNTAX_ONIGURMUA; // RUBYからONIGURUMAに変更

なのだろうね
grep -n -r ONIG_SYNTAX *
でONIG_SYNTAX_RUBYが引っかからないから、おそらくONIG_SYNTAX_RUBYはoniguruma側で定義されてる
だからoniguruma側で同様にgrepして ONIG_SYNTAX_ONIGURUMA が定義されてればいけるかも
てかこれ見る限り、毎回initしてるのか？(まあdllならそうかもだが)
そして _php_mb_regex_init_options内case '*' の部分をphp.iniかどこかで設定出来るようにしてるはずではあるが

ただ普通に考えて、prev_syntaxって何ぞ？ではある
regexで「今回の」文法を切り替えるのは分かるが、「前回の」は明らかに要らないので、
それがある＝何か無理矢理切り替えて動かしてる感あり、なので、単純にビット立てるだけでは駄目かもよ
ダラダラ書いたけどこんな感じ

とはいえ、君はほぼ辿り着いてるよね
php_mbstringのコンパイル環境の立ち上げがすんなり行くかはやってみないと分からないが

2024/10/23(水) 22:21:59.96

あとついでに言うと、推定だが、順当には、

当初：php->onigurumaを直接呼び出し

おそらくonigurumagaの更新でAPIが変わって、

現在：php->php_mbstring->oniguruma と呼び出し、
php->php_mbstring間のAPIは固定、
php_mbstring->onigurumaでonigurumaのAPI変更に対応、
つまりonigurumaが変更されてもphp_mbstringの変更のみで対応し、php 本体は一行も変更無しでいけるように分離した、
だと思うので、君の予想する「oniguruma用に何かしてるコード」はphp_mbstring側に全部突っ込まれてるはず
まあこれも一般論だが

2024/10/23(水) 22:31:46.47

>>967
分かる範囲だが一応訂正

× (最近使ってないなら文法間違ってるかもだが)
○ (最近使ってない　か　ら文法間違ってるかもだが)

2024/10/23(水) 22:52:29.22

さらについで
ONIG_SYNTAXは仕様としては任意のビットを立てたり落としたり出来るはずだが、
実際はこの手の奴は大体テストが甘くて、組み合わせによっては動作しなかったりする
ではどうするか？と言えば、テスト済みであろう組み合わせに出来るだけ近い物を使う
今回ならRUBYかONIGURUMAに一番近いものだが、まあ、両方とも似たり寄ったりだな

しかしよく見ると、RUBY 指定なら ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME は立ってるではないか
php_mbstringのソースだけ見るとデフォはRUBY指定だから動くはず
となると何らかの理由で _php_mb_regex_init_options で他指定に切り替えられてるのか？
ならば手抜きで直すなら、
ext/mbstring/php_mbregex.c:607-656を全部コメントアウトして case 文を無視、
何をどう指定されても ONIG_SYNTAX_RUBY(あるいはONIG_SYNTAX_ONIGURUMA) になるようにしてしまうとか、かな

2024/10/23(水) 23:37:30.51

>>964
てゆうかすいません、モロクソに書いてましたわ
dllだけ差し替えて'r'指定で行けるはずですわ
もうちょっと眺めて投稿すべきだった(これもかもだが)

（すまぬが引っかかるのでバラバラに落とす)

2024/10/23(水) 23:40:00.93

_php_mb_regex_init_options は各関数で毎回呼ばれてる
(_php_mb_regex_ereg_replace_execからも)

2024/10/23(水) 23:41:25.78

そしてこれをPHPから呼ぶのが mb_regex_set_options で、

2024/10/23(水) 23:42:52.32

> Regex 構文モード(ひとつだけ設定可能です)

2024/10/23(水) 23:43:08.35

> https://www.php.net/manual/ja/function.mb-regex-set-options.php
とモロクソ書いてますな
そして何故かそのphp.netページにはデフォが何か書いてないが、
'r'指定すればRUBY指定(=ONIG_SYN_OP2_ASTERISK_CALLOUT_NAMEがON)になる
'p'指定でもいけるかも？

そしてこのフラグは mb_ereg_replace でも使えるらしい。つまり、
mb_ereg_replace(
string $pattern,
string $replacement,
string $string,
?string $options = null <- ここに指定、例えば 'r' or 'p'
): string|false|null

これで使えるなら、dllだけ差し替えればC側の修正は不要(そして多分これで上手く行く)

2024/10/23(水) 23:43:51.89

それでも駄目、或いはRUBY指定やPERL指定では使えない機能も使いたいなら、
_php_mb_regex_init_optionsに

case 'o':
*syntax = ONIG_SYNTAX_ONIGURUMA
break;

を追加して、'o'指定してやるとかすればいけるはず
敗因は、oniguruma側で細かくregexを切り替えられる事を知らない人にとっては
> Regex 構文モード(ひとつだけ設定可能です)
とか意味不明だからだな
最初にそこを言ってくれてれば、ピンと来た人がいたかも？