PHP質問・雑談スレ3【初心者お断り(ROM歓迎)】©2ch.net

PHPに関する質問や雑談をするスレです。
初心者お断り(ROM歓迎)と書いてますが、初心者用のスレが用意されているからで、
難しい質問や話題をしなければいけないわけではありません。
PHPマニュアルの読み方を概ね理解していて、関数リファレンスが正しく読める方用のスレです。

PHP未導入の方や、手取り足取りが必要な初心者の方はム板のくだスレへどうぞ。
http://echo.2ch.net/tech/　(【PHP】で板内を検索)

前スレ
http://tamae.2ch.net/test/read.cgi/php/1476708252/

その他リンク
・PHPマニュアル
　https://secure.php.net/manual/ja/index.php
・コードテスト・貼り付け用
　http://ideone.com/
・プログラミングのお題スレ　（求PHPer参戦）
　http://echo.2ch.net/test/read.cgi/tech/1480579110/

このスレで扱う話題
・PHPのコード，設定や設定値に関する質問
・常識的範囲内でのコードレビュー依頼・改良相談
・PECL，PEARに関する質問
・PHP新機能やPHP関連トレンドの話題
　（FWや非公式ライブラリの話題や特徴比較は良いが使い方から先の話題は専スレへ）
・PHPのバグ発見報告・公式に報告する前の検証依頼

このスレで扱わない話題
・直接関係ない○○特有の質問（専スレへ）
　（HH，エディタ，IDE，サーバ，OS，DB，SQL，FW，テンプレート，非公式ライブラリ・アプリケーション等）
・PHPの改造

ＰＨＰって言語は誰が最初に開発したの？

ggrks

open_basedirが有効になってると
curl_setopt()のオプション CURLOPT_FOLLOWLOCATION が使えないんだけど
CURLOPT_FOLLOWLOCATIONはディレクトリ関係ないように思える、なんでこうなってんのですか

safe_modeはわからなくもないんだけどopen_basedirはさっぱりわからん

1 <?php
2 function a($var)
3 {
4 ($var === 1) or trigger_error("error", E_USER_ERROR);
5 }
6 a(2);

このコードなんですが、エラー発生箇所はline4ではなくline6にしたいのですが、
どうしたらいいですか？

スタックトレース見ようとか

例えばsession_save_path()関数はsession.save_pathディレクティブを変更出来る関数ですが、
そもそもsession.save_pathディレクティブはPHP_INI_ALLなので、
ini_setでいいわけで、わざわざ関数いらないんじゃ？って感じるのですが、
ini_setを使わずに標準関数で変更可能なものって、
わざわざ関数用意してるってことはそっち使った方がいいってことですか？
標準関数でなら変更可能だがini_setでは変更不可能なものとか存在するんでしょうか？

固定的・静的なものは、設定ファイルで、
変更されるもの・動的なものは、関数で

ユーザーがデフォルトのパスでよいなら、設定ファイルで、
別の場所へ保存したいのなら、関数で変えれば？

ini_set()もsession_save_path()も両方とも関数なのだが

ありえるのはセキュリティ上の理由などから
disable_functionsで広範に設定できるini_set()が禁止されてる、とかかね
あと返り値が違う

PHP: rfc:deprecate_ini_set_get_aliases
https://wiki.php.net/rfc/deprecate_ini_set_get_aliases

ini_setに一本化しようという提案もあるんだけどね

>>8-10
レスありがとうございます。
特に関数用意されてるからといって何かメリットがあるわけじゃなさそうって感じですね。
ただのエイリアスのようなら一本化には賛成ですね。なんかわかりづらいし。
ただ自分がユーザー側から開発側にまわって考えた場合、
あるAPI、オブジェクトに関連のある設定をまとめたページを作るのもいいですが、
よく変更されるものに関しては、関連関数に出しておくってのも親切設計かなと思いました。
ていうかPHPに日本人コントリビューターがいるとは驚きでした。

mysqli_real_escape_string()

どうして第一引数にlinkが必要になったの？

mysqlと違ってオブジェクト指向サポートしてるからだろ
$link->mysqli_real_escape_string($str)
これを手続き型にマッピングすると
mysqli_real_escape_string($link, $str)
になる

>>13
それはそうなんだけど、なんでオブジェクトが必要なん？
エスケープするだけだし、静的メソッドでも十分機能するよね

どうして性的じゃなくて普通のメソッドとして設計したんだろ
裏でDBに使っちゃいけない文字の問い合わせでもしてるん？

>接続の現在の文字セットを考慮して、SQL 文で使用する文字列の特殊文字をエスケープする

>>15
ありがとう

＞接続の現在の文字セットを考慮
見落としていたわ〜 なるほど腑に落ちた これでなっとく森に帰れる

帰らないでもっと何かネタ持ってきて

静的メソッドっていつごろ実装されたんだっけ課

PHP4のときにはもうあった？

PHP認定とかあるじゃん
あれどれだけ有用なの？

7出たし5はいずれ下火になるかと

5.5や5.6で書いたソースが7で動かなくなるケースってある？
5系列当時でDEPRECATEDなのは使わずエラー抑制せずNOTICE出ないように書かれてると仮定で

>>21
http://php.net/manual/ja/migration70.incompatible.php

list()が結構大きい変更だろうな

listの変更って
格納先が配列、格納時に格納先に添字指定してる、格納先におけるこれら添字が未定義、
っていう条件のときに格納先をforeachしたりすると期待通りにならないかもってやつでしょ

限定的すぎないっつかこんなことしてるやついんの

・・・してた

>>24
申し訳ございません・・・ 申し訳・・・ございません・・・

listとか使いドコロがよーわからん

return array( $count, $data );
みたいな戻り値の関数からそれぞれ独立した変数で受け取れる
[0]とか['result']とか書くのだるいんじゃ

>>28
それだけの理由かYO

>>28
今はそのまま

$result = func()[0];

でいけるじゃろ

>>30
これがアウトになる時代がPHP7じゃなかったっけ？

>>30
それじゃだめだろ
$countと$dataそれぞれ2回分func()しなきゃいけない

>>31
そらどういった理由でアウトになるのか

>>32
2個ともいるならlistだけどそれよりもオブジェクトで返すわ

>>33
アウトにならないか
ごめん勘違いしてたわ

>>34
PHP5.3以前では一時変数必須, 5.4で可能になった構文だ
これが7, というか将来に渡って廃止されるならそれなりに理由が必要だわ

オブジェクトで返すってどう書いてんの
めんどくない？

>>36
そもそも>>28みたいな関数を書かないけど,

return new class ($count, $data) {
public $count;
public $data;
function __construct($count, $data)
{
$this->count = $count;
$this->data = $data;
}
}

で返すなり

$result = new class {
public $count;
public $data;
}

して値を操作してからreturn $result; するなり

元々classとしてまとまってるclassが自身を返すとかならわかる
元々持ってるプロパティも関数もひとまとまりで渡せてそのまま使えるし
チェインも使えるんだし

戻り値のためにobject作って返すとか__construct()だけのclass定義するのって
普通の関数が配列返すのに比べてメリットあるの

どうでもいいがechoは複数の引数を取れる
echo $hoge->a, "\n", $hoge->b, "\n" ;
とか

なので echo $hoge->a . "\n" とするよりも高速だという話がなくもない

>>39
オブジェクトで返すってどう書いてんのの答えであって
短いコード書いただけだから

まああの形式ならキャストするだけでいいんだけどな

$hoge = (object)["a"=>1,"b"=>2];
echo $hoge->a;
echo $hoge->b;

>>39
ない

連想配列で返すよりは健全だと思うという程度
というか最小例だろうけど>>28の設計が良くない

解散

明日は19時に集合ね

20時にしとけよ

20時だぞ

echoするとベンチ取りにくいから実証が難しい件

そんなechoしないし・・・・

echo するとベンチ取りにくいってどういう意味で言ってるんだろう

echo "111";とecho "1"."1"."1";がほぼ同じ

echo "1","1","1";とecho "1"; echo "1"; echo "1";がほぼ同じ

早いのは当然前者

アウトプットがボトルネックになってる疑いがあってそれを計りたいのかな

ﾌﾟﾚﾐｱ見れない
ﾌﾞﾝﾃﾞｽ見れない
CLEL見れない
週刊誌でヌケねえちきしょう
同和のクズ共死ねクソ共がざまあみろ気違い共
ほれ気違い共もっともっとドア閉めろ通れ
それしか能のない能無し共がざまあみろ地獄に落ちろ

フレームワークのソースとか見てると型宣言でarrayはよく使われてるけど
intやstringが使われていない理由ってあるの？

function (int $id, string $name)
function (array $ids)

arrayかどうかの違いが一番めんどくさいから縛っただけじゃないの

引数不定やarrayに関する処理だからでは？
int使うべき場所でarray使ってるなら見てみたい

使う使わない以前にスカラータイプヒンティングは7じゃないと使えないから

PHPのバージョンがたまーにアップグレードしますが
これって誰が言語を改造してるの？

PHPはオープンソースだから誰ってのはない
github上で開発されてて誰でもフォークできる

次期PHPに取り入れるかは
誰かが提案を持ってきて議論して取り入れるか投票して決めていく
提案は誰でもできるが投票はそれなりの実績がある人でないと出来ない

>>58
おまえはマトマな会話が出来るようになるまで最低3年ROMれ

>>58
はい
ttp://people.php.net/

google sha1攻撃に成功

$srcA = file_get_contents("https://shattered.it/static/shattered-1.pdf";);
$srcB = file_get_contents("https://shattered.it/static/shattered-2.pdf";);
echo sha1($srcA)."\n".sha1($srcB);

サーバ証明書みたいな固定で攻撃されやすいものは今はもうだいたいSHA256以上になってるし
パスワードのハッシュにsha1()を1回使うだけなシステムもそうそう無いんじゃない？

DBのパスワードsha1だよ
なるべく短いかつ強力なハッシュアルゴリズムってどれ？

password_hash()

password_hashって、より安全なアルゴリズムに変わる可能性があるから、
長めの領域とっておけみたいなこと書いてて、
アルゴリズム変わっても同じシステムで使うこと想定してるようだけど、
過去に使用してたアルゴリズムでパスワードの比較ができるの？
今のアルゴリズムで一致しなかったら前のバージョンで使用してたのと比較ってのを、
変更した回数だけ繰り返してるようなら、パスワード間違ってたら比較回数増えるし、
別のハッシュアルゴリズムと衝突することがあるのか知らないけど、
衝突することがあるならその危険性が増えそう。

>>66
ドキュメント読もうぜ

マニュアル読むのめんどくさければ変わりに解説するか
「うだうだ言わずにpassword_hash()使え」

なるほど
返り値に含まれてるのか

>>68
理由もなくとりあえず使っとけみたいな初心者脳のは半年ROMっとけ

>>70
理由？ほい
http://php.net/manual/ja/faq.passwords.php

良くわからんのだけど
googleが実験したってやつは要するにsha1()にかけたときに
正当なパスワードと同じ結果を生む文字列の探索でしょ
sha1()は160bitだからまだ同じ結果になるものを探索できたということ
正当なパスワードが漏れるんじゃなくて、不正ログインできちゃう別のパスワードが出てくるということ

この攻撃がWebサーバのphpを通して通用するなんてとても考え難い
正解のsha1()が漏れてる想定になるんだから他のデータも漏れてる想定が妥当
そのうえ、単純にパスワード文字列に1回sha1()かけただけの場合の別パスワードの解析ですら超長時間が必要

限定的過ぎてとても現実的な脅威に思えないんだが、こういう理解で合ってる？

むしろサーバ環境からアルゴリズムが推測されうるpassword_hash()よりも
sha1($password).sha1('foo'.$password.'bar') とか適当にやっとくほうが良いのでは

>>72
強衝突耐性突破の実証
直ちに問題となるのはファイルのダイジェストなど

しかしそもそもSHA-1にせよSHA-2にせよ1回実行するだけでは高速過ぎる
またレインボーテーブルがあれば逆算の計算量は対数オーダーに減少する
これらの理由からSHA-1やSHA-2を1回実施するだけという処理はパスワードハッシュに向かない

password_hashは計算コストを指定出来るから>>73みたいなことを考えるくらいなら素直に使っとけ

>>74
認証時の計算コストが上がれば耐久性は高まっても同時にサーバ負荷も高まる
そもそも何をもって高速過ぎると？
zdnetの記事(//japan.zdnet.com/article/35097102/)ではこう書かれているが

>この手法では、実際に同じハッシュ値を計算するのに要する計算量が、
>第1段階の攻撃に6500基のCPU、第2段階の攻撃に110基のGPUを使用して
>1 年間で実行できる量に相当するという。

総当りに比べ非常に高速化されたsha1()の1回計算ですら
こんなにリソースを要するということだが、これがそんなに危険なのか俺にはよくわからん

ニュースを見ればSHA-1が破られただのSHA-1は危険だのと書きたてられているが
実際に例えばphp.net/downloads.phpに一覧されてるファイルが書き換えられるとして（実際にはSHA256だが）
ファイル置き換え可能なら横のハッシュ表示も書き換え可能ではないか
ファイルサイズまで同一、md5まで同一、とやれば加速度的に処理時間は増えるだろうし

>>75
数年前にMD5で同じこと言ってそうだな

ファイルのダイジェストはすまん, それより公開鍵認証の証明書のフィンガープリントの方が問題だな
MITM攻撃

>>76
すまんけどmd5は知らん
サーバ証明書ならわかる。長けりゃ年単位だし
実は63でも書いたけど事実ほとんどはSHA256以上になってるしSHA1は取り扱い停止してるし

ただファイルについては「不正なファイルを正規のファイルとうんたらかんたら」って論調が
前述の通りニュースで散見される、正直意味わからん
パスワード管理についても現実性を考えると正直微妙すぎるとしか思えなくてなあ

>>77
ファイルとダイジェストが同じサーバで配信されるとは限らん
というか別の経路で(も)配信せにゃ無意味

>>75にももう少し言及しておくけど
> 認証時の計算コストが上がれば耐久性は高まっても同時にサーバ負荷も高まる
その通り, 反復試行出来る回数が激減する
レインボーテーブルの生成も困難になる
パスワードのハッシュ生成なんて反復実行しないんだから速くていいことなんて何もない

> そもそも何をもって高速過ぎると？
暗号論的ハッシュ関数は実行速度も重視して設計されてるけどパスワードハッシュの生成には必要ない

この手の話は最終的に早すぎる早すぎない・負荷問題になる負荷問題にならないの水掛け論になる運命

というか悩むヒマあるならsha1はそのままでいいから
SQLインジェクションやCSRFが成立しないか
信用できない値をそのまま使ってないかガリガリ調べるほうが有意義

$this->func(
$arg1,
$arg2,
$arg3
);

$this->func($arg1,
$arg2,
$arg3
);

引数を改行する場合はどっちがキレイだと思う？

どっちか選択しかないなら読み間違えがなく揃ってる前者

PSR-2だと上のほうだけど長くなるならそうしろって書いてるけどその書き方好きじゃねえ
自分は無名関数渡すまでは改行しない
file_get_contentsのreturnのような文字数的な意味で長くなるなら変数に入れてから渡すなり
数的な意味で長くなるなら配列使ってそっちで改行するかな
http://php.net/manual/ja/function.imagecopyresampled.php
この程度は許容範囲

引数では改行しないけど、大抵array()に入れてから渡すからなー
array()の引数では改行してるわ

改行してたわ！！！

array()の場合は最後の値直後にカンマ書けるから並べて書いた方がしっくりくる

引数は最後にカンマ書けないから、最後の値と同じ行に閉じカッコまで書く

あーたしかにそうだな
よく考えずに使い分けてたわ、ありがとう

>array()の場合は最後の値直後にカンマ書ける
そうだったっけ？syntaxエラーならなかったっけ？
俺の思い違いじゃなければPHPはだめだったような

>>86
今試したけどいけるよ。
array(1,2,3,);

ほんとだ出来るわ
json_encodeと勘違いしてたみたい

関数と言語構造の違いだな

ってか、ここ初心者ＲＯＭスレだが。。

コーディングスタイルなんてどうでもいい質問もよく出るなここ

>>80
どっちもアホみたい

そういう風に改行する可能性があるのは呼び出される関数定義側の話で
呼び出し側は基本的には1行で書くにきまってんだろ

>>83
石器人さん、ちーす
オブジェクト指向、いいかげん覚えような

連想配列渡しとオブジェクト渡し、決定的に違う事があるからさ
そろそろ、原人やめようぜ

> 76 : nobodyさん2017/02/24(金) 23:59:54.08 ID:???
> >>75
> 数年前にMD5で同じこと言ってそうだな


ぐぐれかす

> 79 : nobodyさん2017/02/25(土) 00:51:15.15 ID:???
> この手の話は最終的に早すぎる早すぎない・負荷問題になる負荷問題にならないの水掛け論になる運命

> というか悩むヒマあるならsha1はそのままでいいから
> SQLインジェクションやCSRFが成立しないか
> 信用できない値をそのまま使ってないかガリガリ調べるほうが有意義


どういう理屈で前後の文がつながるのかわからん
ノータリンはすげーな、相変わらず

理論が破綻しとる

>>91
完全に失念してたわ
呼び出す方か
ねーわｗｗｗ

>>92
具体的に何が違うん

>>97
構いませんって書いてるだけで別に推奨はしていない

>>98
複数行で書いて当然なんて誰も書いてないよｗ

>>94
それは程度問題と致命的欠陥の差ということだよ
内部データとしてのパスワードの保護はデータを盗まれた後の話なので
データを盗む手段となるSQLインジェクション等の脆弱性調査を優先すべきという意味もある

関数定義側で改行するのも別に推奨されることじゃないでしょ
むしろしないわ