【PHP】下らねぇ質問はここに 9

2017/12/20(水) 18:00:20.28

PHPに関する質問スレです

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

次スレは>>980以降
本文の1行目に以下を追加すること
!extend:on:vvvvv:1000:512

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

2018/08/05(日) 11:27:52.65

まとめても数百行程度なら、性能上は変わらないと思うが
メンテナンスする上では、機能別に分けて置く方が楽かも

2018/08/05(日) 11:31:24.74

実体は別ファイルにしてエントリポイントからrouterで振り分ける

2018/08/05(日) 13:40:30.63

バラした方が各スクリプトのサイズが小さいなら、物理的な読み取りとパースの分速くはなるんじゃね。
でもそんな細かいことよりメンテ性のいい方を選んだ方がいいんじゃないかな。

2018/08/06(月) 10:30:49.64

>>328
よく100万回ループ回した時の実行速度の差を比較したりする人がいるけど
ハッキリいってやるだけ時間の無駄
そんな事を気にするならそもそもPHPなんか使わない方がいい

webアプリのボトルネックというのは
大抵はDB周りだったりするわけで
そのボトルネックを正確に計測し解決する手段を身につける事が遥かに大事

というかそんな事を気にしてるって時点で
何かしらのフレームワークは使ってないんだろうけど
なぜ使わないの？

2018/08/06(月) 11:23:57.83

>>332
フレームワークとか最近知ったばかりでよくわからん初心者です
DBじゃなくてテキストファイルで処理するphpをああだこうだ弄って遊んでいて
ふと思い付きで質問してみました

2018/08/06(月) 12:20:51.12

PHPに関してフレームワーク使って良かったと思える場面て正直ほとんど無いな。
PHP自体がごった煮状態にしてまでいろいろできるようにしてある中で、フレームワークで実現しようとしている目標がいまいちわからん。
生産性にも得してるように思えないどころか、フレームワーク自体のメンテがだるい。
まあそれほどフレームワーク使ったわけでもなく、古くはSmarty、ちょっと前はCakePHP使ったくらいで、それも他所のベンダが作ったのを引き継いだくらいだから偏見に満ちてる可能性はある。

2018/08/06(月) 12:22:54.58

>>333
そか
フレームワークに頼らずに作るのも
DBに頼らずテキストベースで読み書きするのも
とても良い経験にはなるから頑張って

ただ○万回ループした時の実行時間の差を気にするなんてのは
本当にただの無駄でしかないから
コードの見通しの良さとか管理のしやすさとか
そっちを最優先で

root.php?mode=aaa ⇒ mode/aaa.phpを読む
root.php?mode=bbb ⇒ mode/bbb.phpを読む
root.php?mode=ccc ⇒ mode/ccc.phpを読む

なんて作り方もある
今これがベストだと思って設計しても
どうせ1年後にはもっと良い設計が閃くさ
だから色々と試してみるといい

2018/08/06(月) 12:33:44.81

>>334
大規模開発をした経験がないとそうなるかもね

PHPはとてもいい加減な言語なんで
”正しく”書くにはかなりの知識と経験が必要
ネット上のPHPコードの多くが糞なのを見てもよく分かる

だから特定の規則さえ覚えれば”正しく”書ける
フレームワークってのは大規模開発では必須になる

あとは生産性の問題やね
スクリプト言語なんてものはいかに短時間で簡単にものを生産するかが鍵なので
個人開発であっても何かしらのフレームワークは使え
ってのが俺の意見

俺々マイクロフレームワークでもいいからさ

2018/08/06(月) 12:38:09.33

フレームワークの選択を誤ると、
数年後「まだそんなの使っているのか！」
ってエラーが頻発して苦労する

2018/08/06(月) 12:48:26.08

ネット上のソースのカオスさはPHPとJavaScriptが抜きん出てるよな
本ですら平気で間違った事を書いてるから
初心者ならこれを読めって本がなかなかない

if ($_POST['foo'] == 'var')
こんなコードを見ると目眩がする

>>337
それはあるな
ただ今はLaravel使っとけば間違いはないんじゃないかと

2018/08/06(月) 12:48:56.87

>>336
フレームワークを使うにしても、それをどう使うかは結局設計して周知しないといけないわけで、その手間ってフレームワーク使わない場合とそう変わらなくない？
むしろフレームワークが足かせになってそこから外れる部分をトリッキーに遠回りに書くことになったりのデメリットの方が目についてくる感じだ。
工数削減は俺々ライブラリでやれるし、それを周知する手間も前述の周知に比べて多大なわけでもなく、必要ならライブラリを好き勝手に育てられるから、むしろ身軽で早いと思うがな。
この辺はとりわけ既にいろいろお膳立てされてるPHPならではというか。
大規模開発だとどんなメリットが効いてくると考えてるかについては興味あるけどね。

2018/08/06(月) 13:00:50.54

>>338
フレームワークを使わずに
リクエストパラメータを変数に入れて比較してみましょう
って超初歩的な事でも

$foo = (string) filter_input(INPUT_POST, 'foo');
if ($foo === 'var') {}
と正しく書けてる本が何冊あることやら…

$foo = (isset($_POST['foo'])) ? $_POST['foo'] : NULL;
と書けてたらまだマシで酷いのになると

$foo = $_POST['foo'];
だからPHPはヤバすぎる…

2018/08/06(月) 13:13:28.36

PHPがヤバいのではなく、使う奴がいい加減なだけだろう
きちんと書ける奴は、何使っても大丈夫

2018/08/06(月) 13:19:55.19

フレームワークの重要性が理解できない内は３流以下と自覚すべき
php以外の言語を書けない人に多い

2018/08/06(月) 13:21:13.75

>>340
強制的に string でキャストして情報落とすのが正しいと言われてもなって感じだし、
$foo = $_POST['foo']; がダメというのもそんなの条件次第だろって気もするし、
大事なのは画一的な書き方じゃなくてやり方を適切に選べることなんじゃないの？

2018/08/06(月) 13:28:14.07

オレはこんな感じで書いてるな

$foo = "";
　if (array_key_exists('foo', $_POST)){
$foo = $_POST['foo'];
}

2018/08/06(月) 13:33:40.11

>>344
そのケースなら isset 使ってる。
100万回ループのパフォーマンスなんて気にするなという話の後で言うのもアレだけど、isset の方が速いし短いから。
多重配列の時もそのまま書けるし。

2018/08/06(月) 13:37:32.22

>>343
リクエストパラメータを(string)キャストしてるのは
PHPの仕様的に$_POST['foo']が配列になる事があるからだよ

だから>>344だけでは駄目で
少なくともis_string()を追加する必要がある

大垣さんとかPHP界隈のセキュリティで有名な人は言及してるけど
ここら辺まともに書けてる本を俺は見た記憶がない

で、フレームワークってのはこういうところもきちんとチェックしてる
だからフレームワークを使った方がいいよという話

>>341の言う通り使う側の問題なんだけど
知らなくても動いているように見えてしまうというのは罪な事だね

2018/08/06(月) 13:50:50.84

>>346も書いてるが
?foo[]=1&foo[][]=2&foo[][][]=3
の時の$_GETの中身を見れば$fooがスカラー型になると決めつけていたらだめだと分かるはず
頭の良い人がせっかくフレームワークってのを作ってくれてるんだから我々凡人はそっち使えばいい
だからPHPerって馬鹿にされんだよｗ

2018/08/06(月) 14:07:27.66

>>347
応用パターンとしては

<input type="checkbox" name="foo[]" value="1">
<input type="checkbox" name="foo[]" value="2">
<input type="checkbox" name="foo[]" value="3">

というフォームがあった時に
$_GET['foo']が一次元配列になると決めつけてしまってるケース
$_GET['foo']がスカラー型にも二次元にも三次元にもなる可能性を考慮してないから
バリデーションなんかでエラーをだす残念コードがネット上にはたくさん転がってる

そういうのを初心者が真似してしまうのが問題なんだよね

2018/08/06(月) 14:19:09.94

filter_inputというものをはじめて知った(´・ω・｀)
issetでチェックしなさいというのは最近覚えたけどこっちの方が短く書けるね
勉強になるなあ

2018/08/06(月) 14:21:43.09

>>346
最後については同意。

ただ細かい話、キャストの件は filter_input のオプション無しなら配列は取得されないんじゃないかと。
元々値があったのかどうかの判定が出来なくなるのもまた問題じゃないかね。
だからフレームワークにやってもらえばいいじゃんという立場だとは思うけどさ。

>>347
その程度のバリデーションライブラリも書けない凡人のために（ありものの）フレームワークがあるということであれば、やはりあまり縁の無い話かなと思えてくる。
隣のコンビニになら歩いて行けばいいのに、なぜ車を用意してナビまでセットする？みたいな。
フレームワークってのは、端的に言えば誰が書いても同じ書き方になる仕組みで細かいこと周知しなくてもそうなるから多人数で書いても認識が共有できる、という思想なのかと思ってたよ。
思想通りに実現されるならよさそうだが、現実はそうでもないなって感じてるけど。
PHPみたいにWebに特化してない他の言語なんかは、イチからやるよりはフレームワーク使うのが現実的だと思うし、
PHPでも俺々マイクロフレームワークの話であればその実態は必要ライブラリと雛型くらいのものだろうから、そういうのに異論は無いけどね。

2018/08/06(月) 14:46:52.11

>>349
Filter関数は意外と浸透してないっぽい

$foo = filter_input(INPUT_POST, 'foo');
は
$foo = (isset($_POST['foo']) && is_string($_POST['foo'])) ? $_POST['foo'] : false;
と書くのとほぼ同じ意味になる

上の方が楽だよね

2018/08/06(月) 15:06:29.57

>>351
下の?を使う書き方が苦手なんよね
頭がわるいからこう書かないと理解できない(´・ω・｀)
if(isset($_POST['foo'])){
$foo = $_POST['foo'];
}else{
$foo = false;
}

2018/08/06(月) 15:40:31.71

>>352
PHP7からはもっと短く
$foo = $_POST['foo'] ?? false;
と書けたりもする

三項演算子は別に無理して使わなくていいけど
他の言語を経験してると$fooを初期化せずに

if (isset($_POST['foo'])) {
　　$foo = $_POST['foo'];
} else {
　　$foo = false;
}

と$fooをif～elseの中に入れてしまうのはとても気持ち悪い
三項演算子を使わないなら自分はこう書くかな

$foo = false;
if (isset($_POST['foo'])) {
　　$foo = $_POST['foo'];
}

細かい話なのであまり気にしないくてOK

2018/08/06(月) 15:58:25.55

ifとelseの中に書くのはあまりよくないのか(´・ω・｀)
全部こうやって書いてた。。。
理由が理解できないあほですまんけど次からはfilter_inputを使うから許して

2018/08/06(月) 16:05:18.97

if (条件A) {
$foo = 'a';
} elseif (条件B) {
$foo = 'b';
}
var_dump($foo);

条件AもBも満たさなかった時にエラーになるわな
まずはvar_dumpが参照できるレベルで$fooを定義して必ず参照できることを保証しろってこと
phpしか書けないPHPerだとelseを書けばいいだろと思うかもしれんがそうじゃないそうじゃないんだ

2018/08/06(月) 16:29:32.52

>>355
$test = "c";
if ($test == "a") {
$foo = 'a';
} elseif ($test == "b") {
$foo = 'b';
}
var_dump($foo);

エラーはでずにNULLと出るんだが。。何か間違ってる？

2018/08/06(月) 16:39:22.00

>>356
<?php
の次の行に

error_reporting(-1);
ini_set('display_errors', 1);

を書こう。大雑把にいうとエラーを全部出力するって意味になる
Notice: Undefined variable: foo（$fooっていう変数が定義されてない）
ってエラーが出力されるはず

あと条件式は
($test == "a") じゃなくて
($test === "a") と「=」3つ使って比較しよう
理由は「PHP 型比較」とかで適当にググって

2018/08/06(月) 17:11:21.74

>>356
エラーレベルってのがあってデフォの設定だとnoticeレベルのエラーとかは出ないようになってる
http://php.net/manual/ja/errorfunc.configuration.php#ini.error-reporting

undefineってのは未定義ってエラーなんで消したいなら最初に
$foo = null; なり $foo = ""; なりまずは$fooを定義(define)しろって事

2018/08/06(月) 17:25:08.30

エラーが出たし理由もなんとなく分かったよ　サンクス
でも今まで書いたやつにもエラーが出まくり　本を写しただけなのに(´・ω・｀)
買う本を間違えたかな。。。初心者は何を買えばええんや。。。

2018/08/06(月) 17:36:11.38

>>359
エラーの設定ってのは学習時に一番最初にやるべき事で
本来はphp.ini（PHPの設定ファイル）の方へ設定すべき事なので
それについて書かれてないのならその本はハズレだろうねｗ

あと本を写したって書いてるけど
ソースコードを見たまままま打ち込む（写経と呼ばれる）作業は
何かしらの言語をもう少し書けるようになってからでいいと思う
（決して無駄ってわけじゃないけど）

今の段階だとソースが付録として付いてたり
ウェブからダウンロードできるようになってる方が良いんじゃないかな

具体的にこの本が良いと答えられたらいいんだけど
知らないんだ…すまない

2018/08/06(月) 17:42:18.16

最近はネットで動画を見ながら学習できるサービスが色々とあるからそういうのもいいんじゃね？
本は俺も知らん
phpのまともな本を探すのってウンコの山から金の塊を探すようなもんだ

2018/08/06(月) 20:26:24.27

未だにフレームワークを使う意味が分かんないとか言ってるのは中小零細の底辺ペチパーやろな
SQLとかを生で書いて文字列結合とかやってるんだぜきっと
LaravelあたりのモダンなFWを理解する頭もなさそう

2018/08/06(月) 21:01:33.08

ウンコはすぐ分かる
まずそれを踏まないようにしよう

2018/08/07(火) 06:40:30.60

「サーバーを書く」っていうのはどういう意味？phpで書いたプログラムをサーバーに置いて動作するようにすることも含むの？まったく違う概念？

2018/08/07(火) 07:57:29.50

サーバーサイドプログラムを書くってことじゃないかな
基本的には動作するところまでも含むと思うが、
そんな表現使う人の気持ち次第ってところもあるかと

2018/08/07(火) 08:28:33.60

>>365
ありがとう

2018/08/07(火) 10:42:59.89

サーバーサイドという言葉でくくってしまうとPHPはサーバーサイドで動くものなので語弊があるが
PHPは得意とするフロントを作る以外に例えばProxyサーバとして動作するものを短い行数で書いたりもできる

サーバーを書くってのはそういうものをPHPなり他の言語なりで書く時に使う表現かと

2018/08/07(火) 10:50:55.53

>>367
例えばオンライン要素(マルチプレイ)のあるゲームを作る際に、サーバーにあるDBにアクセスしてデータを出し入れするプログラムをPHPで書いた場合は「サーバーを書く」と言っていいの？

2018/08/07(火) 11:02:53.49

>>368
そういう用途では使わないと思う
Proxyみたいにサーバ上でスタンドアローンで動作するアプリと言えばいいかな？そういうものを書くイメージ
例えばwebminはhttpサーバ機能をperlで書いてるがそういうものをサーバーを書いたと言うのはしっくりと来る

2018/08/07(火) 11:04:40.27

>>369
完全に理解した！！(大嘘)
ありがとう

2018/08/07(火) 11:16:29.34

てか、こんなイミフ表現使うなよw

2018/08/07(火) 11:20:35.05

イミフか？知らないだけだろ

2018/08/07(火) 11:51:01.42

ちょっとググるとguzzleでproxy書いてるのとかあったからやってみればいいんじゃないかな
そうすればサーバーを書くというのはどういうものなのか何となく分かるのでは

2018/08/07(火) 13:53:06.05

サーバってのはsocket関数使ってポートlistenしたデーモンであること
>>368はたんにバックエンドなだけ

2018/08/07(火) 14:37:02.01

>>373
今のところ使い道が浮かばないからやめておくよ。でもありがとう

>>374
これで完全に合点がいった。ありがとう

2018/08/08(水) 16:21:48.35

VB/VBA（クラス無し）しか書かけないけど、PHP(5?)を触ることになった

入門書探してるんだけど、尼のカスタマーレビュー見るとどれも賛否両論でまともなのがない

「これ買え」ってのない？
内容全部が役に立つわけないのはわかってるから、本の特徴が知りたい

2018/08/08(水) 16:24:03.76

リンクをクリックすると問い合わせに回答するメールの画面が開くという処理があるのですが、
EdgeとIEでは正常に動作するのですが、Chromeだと何も起こらない時があります。

$val = mb_convert_encoding($_POST['body'], "SJIS", "UTF-8");
body（本文）が短いとChromeでも正常に動作するのでbodyの内容が長い時に↑のエンコード時に何か異常が起きてると思うんですけどわかる方いますか？

2018/08/08(水) 17:06:31.24

input要素の入力の有無を確認する方法で一般的な方法を教えてください。

1. if($hoge == ''){･･･}
2. if($hoge === ''){･･･}
3. if(empty($hoge)){･･･}
4. if(!$hoge){･･･}
5. if(!strlen($hoge)){･･･}
6. 他の良い方法も教えてください。

PHPを初めて日が浅いので変な質問をすると思いますが、よろしくお願いします。

2018/08/08(水) 17:18:00.31

>>378
<form action="" method="post">
<input type="text" name="hoge">

のフォームから飛んでくる$_POST['hoge']の値が空かどうかは

if ((string) filter_input(INPUT_POST, 'hoge') === '')

と書くのが実用的（正しいというと語弊があるので「実用的」と表現しとく）

少なくとも3や4は使っちゃ駄目
hogeに'0'が入っていても空として判定されてしまう

2018/08/08(水) 17:24:45.45

>>377
<a href="mailto:aaa@example.com?body={$val}">～</a>
としてリンクをクリックした時に
メーラーの本文に$valが書かれた状態にしたいって話だろうか？

もしそうならbodyに何byteまで指定できるかは環境依存なので
その方法は止めて
ローカルのMTAやSMTP使ってメールを飛ばすようにした方がいい

2018/08/08(水) 17:30:58.81

>>376
ちょっと上でも話が出てるがPHPには初心者ならこれ！という本が本当にない
強いていうならPHP公式サイトにあるPHPマニュアルが一番いい

何かを作りながら学びたいのであれば
ドットインストールみたいなサービスも選択肢になるかも

2018/08/08(水) 17:37:04.15

プログラミング言語として学ぶだけならいざ知らず, PHPの場合はほぼ確実にサーバサイドプログラミングのお作法とセットだから難しい
構文だけは簡単だけど実用しようと思うと全く初心者向けじゃないと思うわ
(サーバサイドアプリケーション自体初心者向きじゃないとは思う)

2018/08/08(水) 17:44:35.51

本屋で色々見て一番読みやすそうなの買えばいいんだよ
何が読みやすいなんて人それぞれなんだから

**378** (ﾜｯﾁｮｲ ffd0-10BI) · 2018/08/08(水) 18:05:55.26

>>378です

>>379さん
アドバイスありがとうございます。
教えてくださったコードとPHPマニュアルを見て動作から学びたいと思います。
また、3と4の方法は、日本語のみの場合、使っても問題ないということでしょうか。
覚えることが多いですが、頑張ります。

2018/08/08(水) 18:19:09.01

>>381-383

やっぱなぁ
入るスキルがバラバラだからコレっつーのが難しいんだな
「PHPマニュアル」が一番ってのはわかるんだが、リファレンスであって教本じゃない感じ

XAMPP(MySQLでPHP5)環境だから、大きい本屋であさって、尼で中古買うわ

2018/08/08(水) 18:29:33.84

自分が始めた10年ぐらい前は赤マンモス本とかが流行ってたけどね
今はもう古いんじゃないかなあ
困ったときはとりあえずみんなオライリーって言うけど誰も言ってなかった

2018/08/08(水) 18:37:52.38

>>384
＞ 3と4の方法は、日本語のみの場合、使っても問題ないということでしょうか

例えば if (empty($hoge)) は
1.$hogeが未定義(undefined)
2.$hoge = NULL
3.$hoge = (bool) false
4.$hoge = (int|float) 0
5.$hoge = (string) 0 or (string) ''
6.$hoge = (array) array() （空の配列）
なんかの時に真になる

意味を分かって使うのであれば別に絶対駄目だという訳じゃないよ

「日本語のみ」というのはPHPではどう判定するのか
そもそも日本語をどう定義するのかって話はあるけど

**378** (ﾜｯﾁｮｲ ffd0-10BI) · 2018/08/08(水) 19:16:28.90

>>387さん
詳しいレスありがとうございます。
それぞれの関数の意味を理解するよう勉強します。
ありがとうございました。

2018/08/09(木) 10:37:03.17

>>380
ありがとうございます。mailtoじゃなくjavascriptですけどメーラー本文に問い合わせ内容が書かれた状態にしたいです。
私は専門はオフコンなのでほとんどPHP等の知識はないのですが、作った人がもういないので仕方なく探り探りやってる状態です。

2018/08/09(木) 11:17:35.06

>>389
今JavaScriptでやってるという方法も
結局は内部的にmailtoスキームを使ってるのではないかと思う

その方法はブラウザやブラウザから呼ばれるメールソフトに依存してしまう
しかも環境によってはそもそもメールソフトが起動しない

つまりPHPの処理の問題ではないって事ね

Googleフォームみたいに
問い合わせフォームを簡単に作れるサービスがたくさんあるので
そういうのを使ってみるのはどうだろう？
「問い合わせフォーム作成」とかでググってみるとか

2018/08/09(木) 11:27:54.29

>>389
試しに実験してみたけど
Chromeはやはり?body=に長過ぎる文字列を指定してると
mailtoが反応しなくなるっぽいね

適当に10,000byteのbodyを与えみたら
Chromeはmailtoをクリックしても何も起こらなくなる
Firefoxだと2046byte以降が削除される

これはもう仕様なので他の方法にするしかないだろうね

今までも環境によっては動いてなかったんだと思うよ

2018/08/09(木) 11:39:44.99

>>389
GETじゃなく、POSTでやってみたら
PHPの知識というよりWebの動作についての知識

2018/08/09(木) 11:51:13.12

>>392
いやそういう問題じゃないだろ

2018/08/09(木) 13:07:46.86

>>390-391
やはりそうですかありがとうございます。
問い合わせフォーム自体はあるのですが、返信する時にメーラーを使っています。

>>392　POST勉強してみます

2018/08/09(木) 13:23:22.82

>>394
問い合わせ内容がメールで来るわけではなく画面に表示されて
画面内のリンクをクリックしたら返信用にメーラーが立ち上がるみたいな仕組みなのかな？

問い合わせ内容が何かしらのメールアドレス宛に届くようにしさえすれば
あとは運用で解決する問題なような気がするけど…

**394** (ﾜｯﾁｮｲ 4ad4-AlRe) · 2018/08/10(金) 10:53:33.88

>>395
まさにそう言うことです
VBAくらいは触ったことはあってもWebアプリはチンプンカンプンで一から勉強です・・・

2018/08/10(金) 12:02:22.10

運用でカバーするなら今のままでIE使わせればいいって話でもあるわな。

2018/08/11(土) 17:46:10.17

$var = $_POST['var'];
よりも
$var = filter_input(INPUT_POST,'var');
が良いんですか !?
前者は危険だと聞いた(´・ω・`)
勉強中の身だけどﾑｽﾞｶｼｲ　

2018/08/11(土) 17:51:08.49

filter_inputで少しぐぐれば出てくるでしょ
分からない単語出てきたらまたぐぐるってやってけば分かるさ

2018/08/11(土) 21:17:42.60

>>399
前者が危険な理由はキーワード知らないと filter_input でググってもでてこないと思うけど。

2018/08/12(日) 00:03:01.67

>>400
実際にググってみた？
キーワード知らなくても検索結果の上から5つくらい見ればそれなりには理由分かるよ

2018/08/12(日) 00:08:01.15

単刀直入にやらないと、無駄にスレを消費する

2018/08/12(日) 00:31:14.89

filter_input だと便利な場面があるというだけで、$_POST はこれまでみんな使ってきたものだし留意点を押さえれば問題があるわけじゃない。
$_POST での参照は、そもそもそのパラメタが設定されているか、期待する型かとかを自分で判定する必要があるというだけで、fi-ter_input はそれを場合によって便利にするユーティリティ関数程度のもの。

2018/08/12(日) 01:12:20.29

$_POST が危険って言われるのは、変更可能なスーパーグローバルだから。
filter_input は HTTP で投げられた値を直接参照するので、$_POST とは全然別物。
ググってでてくる情報で、変数汚染に触れてる記事はないので、概要知らないとたどり着けないんだぜぃ！

2018/08/12(日) 07:20:34.52

変更可能だとどんな危険が考えられるの？

2018/08/12(日) 09:08:50.60

>>405
行儀の悪いモジュールやライブラリとか使うと書き換えられるかも。ってぐらい。
実際にはそれほど気にしなくて良いレベルだけど、それを気にしなきゃいけないプログラムは多い。
読みやすく/使いやすく/再利用性の高いコード書くってことは、結合を疎に保つことが重要なんで、そのあたり理解してると $_POST はまず使わん。

2018/08/12(日) 15:04:58.70

GETも同じ？

2018/08/12(日) 15:27:03.70

>>404
＞$_POST が危険って言われるのは、変更可能なスーパーグローバルだから。
＞filter_input はは HTTP で投げられた値を直接参照するので、$_POST とは全然別物。

$_POST が危険って言うのは聞いたことがないんだが、
Webサーバーが受けとったリクエストをPHPが取得して変数に代入している訳だろう？
PHPスクリプトが変数の値を参照するのに誰かが割り込めるのかな
リクエスト内容を直接参照すれば他が割り込めなくなるとは思えないが
filter_input がやれるなら、他も出来ると言うことだろう

2018/08/12(日) 15:35:31.72

$HTTP_POST_VARS って変数があり、
これはスーパーグローバルではないけれど
現在は非推奨となってる

2018/08/12(日) 20:02:51.29

>>408
ここで言う「危険」は「セキュアじゃない」って意味ではなくて、「コードが意図した通り動かない可能性がある」とかの意味。

$_POST は「スーパーグローバル変数」なので、コード内のいたる箇所で書き換えることが可能。
で、書き換えちゃった場合、それを使用している他の箇所にも影響出るよね。ってことを危険っ言ってる。
普通は書き換え行うようなことはしないけど、何かの意図があって書き換えた場合、後に想定を超える影響を及ぼす可能性が大。
filter_input は読み取りのみが保証されるので、疎結合なコードを書くには filter_input を使用することが必須。

>> 407
GET も考え方は同じ。

2018/08/12(日) 20:18:35.31

>>410
そういうのはバグって行って、POSTスーパーグローバル変数の問題ではないなあ
使い方が間違えているか、ワザとそうしているかだろう

普通に推奨されている方法をあえてとらないって　意味が無いと思う
自分だけでやってシステムが終わるまでメンテするって言うなら良いけど

2018/08/12(日) 20:51:00.05

>>410
なるほど、ありがとう

2018/08/12(日) 20:56:57.73

>>411
バグの入る余地をなくして、読みやすく/使いやすく/再利用性の高い危険を回避したコードを書くには、結合を疎に保つことが重要
で、結合を疎に保つには filter_input を使用することが推奨されるって話なんだけど、通じてる？

普通に推奨されている方法をあえてとらないって　意味が無いと思う
自分だけでやってシステム終わるまでメンテするって言うなら良いけど

2018/08/12(日) 21:02:18.40

あえて書き直すほどの事は無いと思う
開発する人間が注意すれば避けられること

そこまで拘るなら、Webサーバー使わずに
自前でリクエストを受けとってしまえば良いんじゃない？

普通に推奨されているとは思わないよ。そんな関数初めて聞いたし。
どこでそんな事で大騒ぎになっているの？サイト教えて

2018/08/12(日) 21:24:00.23

疎結合と filter_input がいまいち結び付かん。
HTTPリクエストから必要パラメタを取り出しオブジェクト化して、後はそのオブジェクトを使ってパラメタにアクセスしましょうってんならHTTPリクエストを隠蔽できて疎かなって気もするが。
$_POST の代わりに filter_input を使うと何と何が疎になるの？って感じ。

2018/08/12(日) 21:37:43.85

>>414
変数のスコープのの話なんて、適当に探せばいくらでも出てくるだろうに＾＾；

堅牢なコードを理解してないみたいなんで、これでも見て意識改善するといいよ。
https://youtu.be/17i1EL9pBwA

2018/08/12(日) 21:44:39.30

>>415
> HTTPリクエストから必要パラメタを取り出しオブジェクト化して、後はそのオブジェクトを使ってパラメタにアクセスしましょうってんならHTTPリクエストを隠蔽できて疎かなって気もするが。
その認識で正しいと思うよ。
ただ、それはそれ。
取り出しの時に行儀の悪いモジュールやライブラリ使用したときに、邪魔される可能性は残る。
取り出しのときにでかいスコープを回避できる読み取り専用の関数を使用すると、予防的にコードが書けるってことです。

2018/08/12(日) 22:17:31.77

PHPを扱うサイトでfilter_input が話題になっている所あるの？
見つからないんだけど
普通に推奨されている位だから、たくさんあってもおかしくはないよね？

2018/08/12(日) 22:25:25.71

Webサーバーからリクエストを受けとるのに隠蔽も何もないと思うけどね
グローバル変数だから書き換えられる可能性があるというのも変
書き換えているのは自分じゃないか。人のせいには出来ないでしょう
大勢で開発しているなら、その処理を行う担当以外は操作禁止にするだけだし

2018/08/12(日) 22:26:50.06

>>418
filter_input じゃ、ググれないよ。
グローバル変数を使用しない理由を検索してみるといい。
キーワード知らないと、ググれないっていうのはそういうこと。

2018/08/12(日) 22:29:18.96

>>419
@t_wada の前でも同じこと言えんの？

2018/08/12(日) 22:31:31.01

既存コードを修正すべきだとまでは言わないが, 新規コードにはfilter_inputを使うべきだという点に関しては疑う余地がない

2018/08/12(日) 22:40:35.81

>>420
つまり、公開されているPHP関連のサイトではそのような話題が出ていないと言うことでOK？

2018/08/12(日) 22:49:31.76

>>419
んまあデバッグしたりコマンドラインでも実行できるようにしたりする可能性を考えると、HTTPリクエストの扱いは浮かせて置いた方がいいかなって気はするよ。
後は同意。
$_POST がダメで filter_input ならいいって話には繋がらないと思うし、$_POST をわざわざ書き換えるならあえてそういう設計なんだろうけど、それが甘いか明確になってないだけじゃねとしか思わん。
そういう設計はかくかく然々でお勧めしないよって話ならまだ聞ける。

ちなみに >>416 は見たよ。
話のうまいやつで面白かったよ。
PHP にも assert あったのね。しかも運用時にいないことにできるとか、なかなかいいじゃないか。

2018/08/12(日) 22:55:53.50

キーワードで検索出来ないってことがとても不自然に感じるんだけど
普通に推奨されていると言うなら、行う記事があってもおかしくはないよね

まさか、この関数が非公開関数で秘密にしないといけないものだったりして

2018/08/12(日) 22:59:03.40

>>423 >>425
グローバルスコープな変数使うなよって話以上に何が聞きたいの？
グローバル使用しない代替手段使おうねって話でしか無いんだけど＾＾；
そろそろ理解しようよ。

2018/08/12(日) 22:59:36.87

>>425
×　行う記事
○　推奨する記事

2018/08/12(日) 23:01:06.85

>>426
それならそういえば良いでしょう

変な関数持ち出す必要もないし
普通に推奨されているなんて言いだすから
サイトを教えてくれと言う話になってるんだし