PHP質問・雑談スレ5【初心者お断り(ROM歓迎)】
レス数が900を超えています。1000を超えると表示できなくなるよ。
PHPに関する質問や雑談をするスレです。
初心者お断り(ROM歓迎)と書いてますが、初心者用のスレが用意されているからで、
難しい質問や話題をしなければいけないわけではありません。
PHPマニュアルの読み方を概ね理解していて、関数リファレンスが正しく読める方用のスレです。
PHP未導入の方や、手取り足取りが必要な初心者の方はム板のくだスレへどうぞ。
https://mevius.5ch.net/tech/ (【PHP】で板内を検索)
前スレ
https://medaka.5ch.net/test/read.cgi/php/1498653249/
その他リンク
・PHPマニュアル
https://secure.php.net/manual/ja/index.php
・コードテスト・貼り付け用
https://ideone.com/
・プログラミングのお題スレ (求PHPer参戦)
https://mevius.5ch.net/test/read.cgi/tech/1538096947/
このスレで扱う話題
・PHPのコード,設定や設定値に関する質問
・常識的範囲内でのコードレビュー依頼・改良相談
・PECL,PEARに関する質問
・PHP新機能やPHP関連トレンドの話題
(FWや非公式ライブラリの話題や特徴比較は良いが使い方から先の話題は専スレへ)
・PHPのバグ発見報告・公式に報告する前の検証依頼
このスレで扱わない話題
・直接関係ない○○特有の質問(専スレへ)
(HH,エディタ,IDE,サーバ,OS,DB,SQL,FW,テンプレート,非公式ライブラリ・アプリケーション等)
・PHPの改造 PerlとPHPが共存してた時代にどっちやるか迷ってPHP始めたけど
まあ今からなら初心者でも絶対違う方法選ぶだろうね
環境構築に躓いてPHPに挫折的に入門してくる層を取り込めれば良いと思うわ >>818
Rubyには勝ってるのか
WebだとやっぱJavaかPythonにいくのかな新規の人は Pythonはphpより遅いだろ?
それとも速度上がった? 今や速度はマシン側の進化やチューニングが重要で
無駄な処理が多い言語でよほどそこで足引っ張ってない限り
言語の速度にはこだわらないってスタンスでいいと思うわ
それよりも扱いやすさと汎用性と安全性のバランスがとれてるもの
googleとか見てるとそんな感じだし
訪問者が読み込みを放棄して他所のサイトにいってしまいかねない
WordPressは例外中の例外
PHPの場合JIT実装にリソースさくならWordPressどうにかしたほうがいいわ 今は仮想化ばかりでマシン側なんか意識しないだろ
PHP 7.3とPython 3.7.2の速度比較じゃPHPの全勝
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/php.html
Pythonは遅すぎだし、DB接続には追加パッケージ必要だしで
WEBでは使わず、ローカルでなんかさせたいときの言語って感じがするね Wordpressは色々問題があるが
セキュリティとかどうでも良くて
基本的に何でもかんでも自由にアクセス出来るオープンビッチなのを先にどうにかした方が良い
自由にphpファイル作れるのがまずあり得ない
イミュータブル・インフラストラクチャー? GitOps?何それおいしいの?
みたいな感じ? >>825
まぁ自由度高すぎるのは考えものだわな
function.phpももう少しルール決めておいてほしかった >>823
WordpressはPHPで作られているというだけでPHP本体の開発とは何の関係もないのだが
JITはそんなに重要ではないがFFIみたいな割と未来があるものも開発されてるしな >>823、>>825-827
CMS用途でWordPressを選ばないならdrupalになるだろうが、
これもPHP必須。 >>827
そうはいってもPHPが存在する理由なんてWPがあるからみたいなもんだし
移植可能なWPのようなソフトウェアを
今からPythonでスクラッチから開発したら
いくら素の性能がまさるとはいえPythonで作ったWPモドキに軍配があがるだろう WPはプラグインとテーマの数が半端ない
それが使えればpythonだろうがCだろうがなんでも良いぞ PHPの存在理由がWPだけというなら
基本的にWeb開発はJava一択ってこと?
RubyやPythonがWeb開発でPHPより勝る理由はそうないだろうし フルスクラッチでなんでもかんでもやるならGoは悪く無い なんでJavaがだめかというと冗長でとにかくくどい長ったらしい。
環境構築もそれなりに大変、コードの保守も大変なのであえてJavaを選ぶのはドM。
その点Pythonは実にシンプルで、ドキュメントが多く初心者向けで覚えやすくPHP並に簡単。
ただしFW前提の開発になるので、FW含めて覚える感じになるが。
環境構築もPHPほどではないが比較的容易な方。
スマホ開発から入るエンジニアはJava触るもんだから、
馴染みのあるJavaでWebもやろうとなることはあるだろうけど。 PHP言語そのもののzend?よりもさらに前身のところの元開発者です。
ポインタを裏方化したくてオブジェクト指向(というかオブジェクト演算子の利用)ができること、
画像には基本的に書き込みしない、
文字列と数値以外は使わないこと、
変数型はソースを解析してそれっぽく扱うこと、
などwebも鑑みながらプログラミングを楽にできることを徹底したつもりです
一応他の言語に比べて予約語以外は覚えることに苦労する面をすくなくするように気をつけたつもりです 実際Railsも下火だしwebのバックエンド開発言語はベスト不在の混乱期に陥りつつあるね
フロントのトレンドサイクル馬鹿にしてる場合じゃないで
まぁワイはKotlinいったるやで >>837
こんばんは、トーマス
>>838
ワイはGroovy派 .Net Coreが来るだろ
Webサーバーも稼働率で言えばIISが一番多いし こういう転換期にPerlerたちはどこへ向かっていったのかな?
PHPerが向かうべき先はPHP8なのか、Pythonなのか、NodeJSなのか
はたまたLLからの脱却なのか webゆーてもクラウドソーシングで記事書かせてWPに上げとるのがほとんどやで。 MediaWikiっていうWikipediaを始めとするさまざまなwikiのエンジンでもPHPが使われてだな…
Wordpressだけじゃないんだよ・・・ Pukiwiki形式を取り込める今どきのCMSが出たら言語関係なく移るw wikiは記法が乱立しすぎ
もうちょっと統一するか変換するかしてほc wikiなんてwp利用者と比較すればミジンコみたいなもんだろ マークダウンはシンプル過ぎてメモにしか使えんw
アフィサイトに使えるくらい拡張したら一気に流行るだろ 今はリッチテキスト系の入力フォームが主流で構文直書きなんかしてないだろ みんなでやろうNode.js
みんなで移住すれば怖くない サーバーサイドとクライアントサイドが同じ言語だと幸せなんだよね
現実は難しいけど >>854
>SEOやアクセシビリティの点数も満点です。
頭悪すぎて読む気にならんわ >>853
それならブラウザでPHPを動かした方が良いよ すでにJavaScriptがあるのにPHP採用するなんてないだろ
そもそもサーバサイドの対応と違って難しいぞ
サーバサイドは開発者が選べばいいだけだが
ブラウザは結局ベンダー次第になるし
ユーザ任せのプラグインじゃまず普及しないだろう >>857
じゃあJavascript上でPHPを動かせば良いよ >>854 実際こういう記事が出てくるとWP導入するとこも減ってくるだろう >>854
これ静的ファイルを出力してるだけだろ
wpのプラグインにそんな機能持ってるのがあるのでフーンくらいにしか思わん Wordpressは環境を共有するのむずい
何でデータベースにドメイン名含む完全なURLが入ったりすんの? >>864
そりゃサブドメインとかでも同じDBで動かせるようにだろ
データベース一つで複数のサイトを運用できるようになってるんだから
ドメイン入ってないとどこのサイトのデータなのか判別できなくなるだろう WordPress3.0からマルチサイト対応だからな empty関数って何の役に立つ?
「empty($value)」と「$valueの真偽値」は丁度結果の真偽が正反対になるから
empty使わず変数の真偽値確認すれば良いのでは >>868
読みやすい
それを言い出すとほとんどの関数いらなくなるので・・・ >>869
可読性のための関数ということですか
たしかに!をつけるより読みやすいのかもしれませんな >>868
empty はnullか空白かゼロの時にtrueになる。それをor 条件で記述するのが面倒くさい
自分はデフォルト値を設定する時に使ってる >>868
https://php.net/manual/ja/function.empty.php
返り値
var が存在し、かつその値が空や0でなければ FALSE を返します。 それ以外の場合は TRUE を返します。
次のような値は空であるとみなされます。
"" (空文字列)
0 (整数 の 0)
0.0 (浮動小数点数の 0)
"0" (文字列 の 0)
NULL
FALSE
array() (空の配列)
文字列の"0"や数値の0までFALSE扱いされるんだから
表出力するとき、0やNULLをまとめて空白にしたり、-を入れたりしたいときは使えるんじゃね? empty issetは先にシンボルテーブルチェックされる
プロパティなら__issetがトリガされるが__getは呼ばれない >>868
Notice: Undefined variable: value エラーが出ないように使ってる
explodeした時にセットされてないかもしれない配列を判定する時なんかに使う
if(empty($arr[19]))continue;
とか >>873
>>868
それは結局empty使わなくても!$valueでも同じって話では。
!$valueでもnull、空白、0、"0"はtrueになる。
ただ>>877の言うとおり変数自体が未定義のときもemptyなら警告が出ないってのは
確かに使えるところかも。 web フォームでは数字項目でも空白で入力できて
しまうからempty で空か判断できるのは便利だよ エラーメッセージ
ご指定のファイル public://media/2019/04/20/無題.jpg はコピー先ディレクトリーが正しく設定されていないため、コピーされませんでした。
ディレクトリーパーミッションが原因かもしれません。詳しくはシステムログを参照してください。
publicプロトコルってなんでしょうか? プロトコルじゃなくてpublic_htmlとか公開されてるルートディレクトリじゃねーの? オレオレエラーメッセージの詳細聞かれても
作者に聞けとしか publicプロトコルなんて無いぞ
オレオレプロトコルが存在する可能性はあるが、まぁ無いだろう。多分。多分な。絶対とは言ってないぞ >>883が正解だろうな
かっこつけてpublic://とかやっちゃういたいたしい作者なのだろう mb_check_encodingについてですが
普通はmb_check_encoding($var)のようにチェックしたい値を指定して使いますよね
しかし公式マニュアルを読んでみると
> var
> 調べるバイトストリーム。省略した場合は、 リクエスト開始時からのすべての入力が対象となります。
とあります
このvarを省略したときに、すべての入力が対象になるという部分が漠然としているのですが
すべての入力とは何ですか?
GET、POST、Cookieですかね、さらにはファイルアップロードも関係あるんでしょうか
この文字コードチェックは完全でないのは知っていますが、気休め程度にGETやPOSTで送られてきた
パラメーターを1つ1つチェックしていました
しかし引数省略してコールすれば一括して文字エンコーディングのバリデーションできるなんてこと
あるんですかね http://git.php.net/?p=php-src.git;a=blob;f=ext/mbstring/mbstring.c >>887
まあ、省略することは考えないほうがいいでしょう。
$_GETや$_POSTは配列を含む可能性があるので、
そのへん考えて、それらの入力値はarray_walk_recursiveのような関数を使うのがいいらしい。
http://gihyo.jp/dev/serial/01/php-security/0020 >>889
レスありがとうございます
やはり1つ1つチェックした方が良いのですかね
たしかに配列の場合もありますし、そのときのmb_check_encodingの挙動が
わかりませんしね すべてのとは$_FILES以外
配列は再帰で処理されるよ
すぐ上のリンクに書いてある
あとストリームだけじゃなくシーケンスも検証すべき 不正な文字エンコーディングによる攻撃って、何を心配してんのだろう?
mb_check_encodingなんて使ったことないけどな…
想定した入力値かどうかをチェックすればいいだけちゃいますのん? 何でmb版があるとかよく分かんない仕組みなんだ?
phpの文字列って
全部UTF-8で良いじゃん >>894
新規サイトはもちろんそう
古いサイトがこれまたね・・・ >>894
うちはezwebにもimodeにも対応しているよ imodeって今でもあるの?
hdmlとかもうマヂ無理… どうせ統一されないから内部表現はバイナリで良いという発想のため
そもそもunicode勢でもstringがutf8の言語なくない? mb_check_encodingの引数省略callで
$_FILES以外の入力の文字コードチェックできて
しかも配列の入力も再帰的にチェックされるなら
引数省略でお手軽に入力チェックした方がいいと
思うのだが何か問題あるの? どうせバリデーションしてんだろ?
とりあえず全部やるって人もいるけど
本当に必要なのか考えたほうがいい $_POST['name'] = "\xad";
if(!mb_check_encoding())
die('invalid encoding');
とやっても何も反応しなかった
mb_check_encoding($_POST['name'])
にすれば反応があった
引数省略はインチキくさいな… _ _ /
もっと |稼| ぎたい!! お金 |超| 大好き!! ./ ∧ ∨
 ̄  ̄ / /\ \ \
>'´', ∨>、 .┌、 ┌┐ __ __ __ l / ⌒介トム`<∨
〈 .∨ ./ ̄',| ヽ| ├ ┤ | ! | / ',l l ,.ィ兮、 ,イ^兮∨
∨ / △∧ .| | |__| └ △ ', l ^ー‐'", `¬'''"∨
∨ / ,‐、 ∧_ヘ_」 |__|─‐ ,-、 ', ', `' ,, ∨
∧_/ ̄  ̄ └‐┘ '─' ⊂⊃ ゝ `', ̄/ /}
/7、ヘ¨ ⊂⊃ ⊂⌒7\>、 ‐' x< /
高収入求人情報 ム/ ヽゝ ⊂ニ⊃ ∠/ { //`´ / j }/ /
ゝ l/£`ーイ / /
ヽ ゝ'⌒>‐' /
`l \ >>889
この記事見て思ったんだが
$_SERVERもバリデーションする必要あるもん?
改竄される可能性あるのかな 例えばHTTP_USER_AGENTなんかは簡単に偽装できるからね
使わないならバリデーションの必要ないけど何かで使うなら普通にやる PHPerなんて、無意識にhtmlspecialcharsをencoding指定でちゃんと不正な文字か出力時にチェックしてるはず。 個人叩きはしたくないけど、
こんな共感出来ない記事書いてたっけなと不思議だったが、人違いだった。
あれは大垣さんじゃなくて徳丸さんだったな。
どっちもPHP界じゃメジャーな人だった気がするが。 HTTP_USER_AGENTやHTTP_REFERERに、クライアントが制御文字を仕込むことって
可能なんですか? Chromeの拡張機能にユーザーエージェントを偽装できる奴あるじゃん 偽装はできましょうが、Fiddler使ってUser-Agentに改行文字やらタブ文字を仕込んで
送信してみると、Bad Requestエラーが返ってきますね
Apacheがはじいてるんでしょうか
$_SERVER['HTTP_USER_AGENT']に制御文字を伝えるのは難しいってことですかね おっとTabはセーフでした
改行はBad Request行きですね ヘッダに制御文字をセットして送れるようなアドオンがあった気がするから
多分そのままやろうとしてもブラウザ側でなんかしてんじゃないかな オレオレWebサーバとWebブラウザで
制御文字受け付けるソフトウェアを作ることはもちろん出来るが
そもそもRFC違反なので
まともなWebサーバやWebブラウザであれば
そのへん対応はしてる じゃ結局$_SERVER['HTTP_USER_AGENT']のバリデーションは
mb_check_encodingかましておけば良いということで ファイルの重複登録をさけたいのですが
ファイルのハッシュ値計算ってどうやるんですか?
md5(file_get_contents('a.jpg'))
こんなんでいいんでしょうか?
jpgならまだいいんですけど
これが例えば動画とかだったらメモリとか大丈夫ですかね? レス数が900を超えています。1000を超えると表示できなくなるよ。