【PHP】下らねぇ質問はここに 9
■ このスレッドは過去ログ倉庫に格納されています
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 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 Q3682 参考書を1ページずつjpgに自炊スキャンしましたが 今あるjpgの奇数ページと偶数ページをくっつけて見開きページの画像にして保存したいと考えました、phpの画像処理ライブラリは GD DmImage ImageMagick 等があるみたいですが 手軽にできるのはどれですか? そんなのどれ使っても手軽だろw こんなところに書いて待ってる間に処理一つくらい書けるし、 まずは分かりやすそうなのどれか一つ使って書いてみればいい どれもベースがGD GDに皮をかぶせて使いやすくしたものだが皮の厚さが違う 初心者です。。 Class hoge { public static function aaa (){ echo __CLASS__; } public function __construct (){ static::aaa(); } } Class piyo extends hoge {} $var = new piyo(); //hoge みたいなコンストラクタの中でstaticつけて関数呼び出すのってどういう意味が有るのですか… static::hogehoge($this);みたいなのがコンストラクタのなかにあるのって どういうふうに動いてるのかわからないです。 >>216 遅延的束縛がわからんのです。 コンストラクタの中でやってるからpiyoにならないのかな static $piyo; public function __construct(){ static::hoge($this); } public static function hoge($this){ return static::piyo = $this; } みたいなのときとかもうわけわからん >>217 まんま>>216 のマニュアルに書いてあるんだけど読んだの? >>219 書いてある? あんまりインスタンス化して使ってるような例ないぽいけど >>217 はClass Hogeとして $aho = new Hoge()とするとインスタンス化した時にHogeの静的プロパティも初期化されるってことだよね。staticとparentがチェーンしてると訳わからんくなる Hogeを継承したpooクラスがあったらpooクラスのstaticプロパティも初期化されるけどselfとどう違うのかわからん。。 トランプゲームみたいな感じで写真の入ってるカードを並べ替えさせるゲームを作ろうと思っています。 カードはドラッグして移動可能。 所定の□の近くにくるとカードは□に収まる こういったことを簡単に実現できるおすすめの言語があったら教えてください。 使ったことのある言語はCとC#だけです。 なぜPHPのスレで聞くのか? てか、ハブリッシュするプラットフォームに依存する話しだから それを言わないとだれも答えられない ロジックだけ実装するならどんな言語でも作れる >>224 すいません。 スレタイ読み違えて誤爆しました・・・。 フォームで受け取ったデータをそのままディレクトリ名にしたいんですけど ディレクトリ名に使われて危険な文字をはじく関数みたいなのってないですか? . と / だけはじけば大丈夫なのかな 入力できる文字を絞った方がいいよ アルファベット数字のみとかにすれば一番無難 それ以外の文字が一文字でも入ってたらエラーで返す a.php が吐くHTMLに、b.php を差し込むSSIタグを埋めたところ、挙動がおかしい。 サーバは apache、PHPの出力に対してもSSIが効くように設定してある。 どうおかしいって、b.php 出力がSSIタグの位置からズレた場所に挿入され、しかもなんか断片化してる。 a.php と b.php の出力が混ざった感じというか、a.php と b.php が非同期に並行して動いてる感じというか。 a.php や b.php と同等の内容の a.html と b.html を用意し、a.html に b.php や b.html をSSIするケースや、a.php に b.html をSSIするケースでは問題無く、a.php に b.php をSSIするケースだけでおかしい。 原因の心当たりって無い? ツッコミどころだらけで笑うわ * SSIはWebサーバの機能(スレ違い) * その構成にする意味が分からない * というかSSIってマジ? SSIって10年以上ぶりに聞いた なんでそんなトリッキーなことしてんだw >>231 > * SSIはWebサーバの機能(スレ違い) あぁ、それもそうだ。おっしゃる通り。 残りについては、そういう都合があるとしか言えない。 SSI もまじ。<!--#include ... のやつな。 いろんなもの SSI してるのよ。 SSIの時点でもうアレだけど更にPHPを絡められて試す気がなぁ とりあえずApache側の設定か? 同期、非同期の問題ならpreforkとworkerで挙動変わるか試してみるとか まあ、どっちにせよ激しくスレ違いな気がする 更新履歴〜 みたいなページでSSI使ってたことはある これはこれで便利やしトリッキー言うほどじゃないだろ まあ今時としては、SSIみたいな挙動をするphpコード書くだけになるか public function Hoge($hoge) { return function () use ($hoge) { return $this->test_func($hoge); }; } こういうのって意味有りますか? クロージャのとこに$hogeを持ってきても実際には繋がりはないように見えるんすけど $var = Hoge($hoge) //$var = function($bar){ return $this->test_func($bar);} クロージャの$hogeと最初の引数の$hogeの繋がり クロージャになっても最初に渡された$hogeは生きてるんやな。。 知らなかった >>236 PHPを使ってるんだったら SSIの<!--#include...に該当する処理は 取り込み対象をPHPのコードとして評価したいならinclude、 文字列として評価したいならfile_get_contets()するだけの 1行で済む話 SSIはサーバー環境依存だし今どきSSIが有効になってる古いサーバーを これから先も使い続けるのか?という疑問もある SSIってJavaScriptもiframeタグもブラウザ標準ではなかったそれこそ10年以上前の遺物よな メンテしているperlのサイトで確か使ってたな phpで使おうと思うほど猛者じゃないので勘弁 PHPでerrnoを取得することはできますか? やりたいことは、ファイルまたはディレクトリの有無を確認しつつ、 falseだった場合は、ENOENTなのかEACCESなのか知りたいのです。 file_existsとis_readableを組み合わせるしかないですか? >>230 せっかくなので分かったことを報告。 SSI にせよ PHP の virtual にせよ apache のサブリクエストが発行される場合、元リクエストとサブリクエストのPHPのインスタンスは同一のものが使い回されるらしく、グローバル変数なんかは共通されるらしい。 恐らく define や include、出力バッファなんかも共有されてると思う。 それでいろいろ思いもよらない挙動を示すっぽい。 ということが分かったので、適当に回避した。 apacheの設定によるところもあるかもしれないけど、そこまで検証してない。 なんか普通の話だな グローバル変数なんて使ってたらそんなの当たり前だろ >>247 ユーザー定義のグローバル変数や名前空間をもたない定数なんかもう何年も使ったことないけど よく分かってないので、スマソ。 モジュール版PHP5.3環境で動かしていたのを、 @ モジュール版5.6環境に移行させる場合 A CGI版5.3環境に移行させる場合 @、Aともにソースコードの書き換えは必須なの? また、簡単なのはどっち? それだけじゃなんとも言えんよ… エスパーでも答えられんと思われ 上の話と同じでグローバル変数とか使ってるとかなら書き換える必要あるかもね 使われてるモジュールやライブラリが対応してるかどうかもあるし 同じ環境を用意して実際に動かしてテストするしかないと思う 5.6でサポートやめたり、推奨からは図したりしたものがあれば 良くて警告、悪くて動作せずとなる やってみないと分からないから、試験環境を作って試すのが最善 5.2.X⇒7.2.Xに以降した環境がいくつもあるけど PHPコンパイルで何度かこけた(コアに取り込まれて使えなくなってるオプションがあった)ぐらいで コードを手直しをした記憶が全くないなぁ 逆にどんな書き方をしてたら動かなくなるのやら… 開発を error_reporting=E_ALL(PHP5.4以前ならE_ALL|E_STRICT) でしてなかったりすると環境移行でエラー出まくったりするかもな 初心者はまずエラーを正しく出すところから学習しないとな >>248 同じインスタンスで動くならそりゃそうだろって話だけど、virtual はともかく SSI が同じインスタンスで動かすのが当たり前かと言われれば微妙じゃね? $_GET みたいなスーパーグローバルとかどうなっちゃうんだよって問題もあるし、実際出力バッファはまぜこぜになって使い物にならないわけだし。 わざわざ SSI でやるのなんて、他所の誰かが作った全く関係ないものを自分の処理と隔離してページ上に取り込みたいなんてケースだったりするわけで、隔離できないならあんまり意味が無いというか。 そういうものだということが分かってりゃやり方考えるからいいんだけど、なんでそうする?っていう仕様だと思う。 PHPそのものの問題じゃないであろうこと引っ張ってすまないけど。 前バージョンと同じように、必要なモジュール・ライブラリがロードされていて、 基本的な環境に差異がないのを前提とすれば、 あとは廃止変更された機能や関数が影響を受ける。 なので動かない場所が出てきて、書き換えが必要になる場合はあるが、 それはコードの1%にも満たないぐらいの量のはずだから、 大規模なアプリケーションでも書き換えに1日はかからないだろう。 >>256 > 他所の誰かが作った全く関係ないものを自分の処理と隔離してページ上に取り込みたい SSIを使う理由になってないしSSI以外の知識がないだけ サーバーの知識が多少ある人間なら今この時代にSSIを使うのがいかに馬鹿げているかすぐ分かる SSIもhtaccessも無駄にサーバーに負荷をかけわ、遅いわ、セキュリティリスクの管理もしにくわで何1つ良いことないから無効にしろと大昔に教わったな 結構最近でもSSIインジェクションで資生堂の小会社がが情報漏えい起こしてたけど資生堂みたいな大きなところが未だにSSI使ってることに驚いた includeしたいだけなら他にいくらでも代替案あるのにさ SSIインジェクションやらかすようなやつはSQLインジェクションだってやらかしかねないんだから、それはSSIを使わない理由としては弱いでしょ。 素人だからよく分かんないんだけど ssiでincludeするのとhtmlで<iframe> or phpでfile_get_contents するのは何が違うの? ssiを使う理由って何? >>261 旧来からのスタイルを踏襲しているとか、 SSIはPHP知らなくてもHTML(と言えるか微妙だが)分かれば使えるってのもあるかもね。 サイト全部がPHPじゃないし、みんながみんなPHP使えるわけじゃないからな。 PHP使うなら PHP の include しても file_get_contents しても、適用できるなら得られる結果は一緒でしょ。 >>261 使う理由は特にない 1.SSI/#include file|virtual="path"はpathの中身をそのまま取り込んだ結果を取り込んだ場所で出力する 2.<iframe src="url|local_path">は対象の出力をフレームとして取り込む 3.file_get_contents('url')はurlの出力を取り込む 4.file_get_contents('local_path')はlocal_pathの中身をそのまま取り込む 5.includeは対象を「PHPのコードとして評価する」 1 ≒ 2 ≒ 3 ≠ 4 ≠ 5 だと思っとけばいい includeとfile_get_contents()が等価なんてのは大嘘なので信じないよう SSIの#includeに該当する処理は、そのほとんどが<iframe>+αで片付く程度の低レベルの事しかしてないね 繰り返すけど今更使う必要性は全くない過去の遺物です include と file_get_contents が等価だなんて言ってないぞ。 別のコンテンツを差し込む方法として適用できるケースがあると言ってるだけで。 例えばページのヘッダやらフッタやらを別ファイルに浮かせたとして、それが include できるなら include で、file_get_contents できるなら file_get_contents で差し込めるだろ。 >>265 > PHP使うなら PHP の include しても file_get_contents しても、適用できるなら得られる結果は一緒 一緒じゃないでしょって話だと思う 実際全然違うし >>266 例えばただのHTMLファイルがあったとして、それを include した場合と file_get_contents 使って出力した場合とで得られる出力結果にどんな違いがあるの? もちろんただのHTMLじゃないものを扱おうとすれば、得たい出力を得るために適用できないこともあるよ。 >>263 の PHPのコードとして評価するというのも語弊があると思うよ。 パースはテキストとして始まるわけだから。 初心者も見てるだろうから実例を出しとく ・test.php ------------ test <?php echo $a; ------------ ・index.php ------------ <?php $a = 'hoge'; var_dump(file_get_contents('./test.php')); /* test <?php echo $a; */ var_dump(file_get_contents('http://localhost/test.php' )); /* test Notice: Undefined variable: a in...($aが定義されていないというエラー) */ include './test.php'; /* test hoge */ ------------ この違いを理解してるならこれ以上俺から言う事は何もない PHPを勉強している者ですが、 PHPを使ってお問い合わせフォームを作る際に気を付けるべきセキュリティ対策についてのアドバイスをください。 メールの送信までの流れは「入力」→「確認」→「送信」となりました。 入力・・・入力される文字の制限(メールアドレスの欄なら使用可能な文字以外でエラー) 確認・・・出力の前にhtmlspicialchars()を使い無害化 送信・・・? 参考になるサイトや書籍のアドバイスなどもいただけると嬉しいです。 よろしくお願いします。 >>270 とりあえず思い当たることをざっくり。 ・SQLインジェクション対策 ・セッションハイジャック対策 ・HTTPSの確認 ・管理者のうっかり対策 ・スパムメール基地化の防止 前2つはこの言葉と PHP で検索すれば出てくると思うけど、SQLインジェクション対策にはPDOのプリペアドステートメントとバインドを使うとか、セッションハイジャック対策は個人的には問い合わせフォーム程度ならセッションなんて使わずhiddenでたらい回しにするかな。 HTTPSの確認は、HTTPでアクセスされた場合に受け付けないとかHTTPSにリダイレクトするとかの施策だけど、シンプルなサーバ構成なら $_SERVER['HTTPS'] が 'on' かどうかを見ればいいものの、webサーバの前段に何か(AWS の ELBとか)入れてるとそれじゃダメなこともある。 開発前に HTTP と HTTPS でのアクセス時の違いを phpinfo を diff 取って確認しておくのがいいんじゃないかな。 管理者のうっかり対策ってのは、問い合わせ内容に悪意あるURLなんかが書かれていてもうっかり踏まないようにするとか。 悪意あるURLじゃなくても、管理画面なんかからリンクを直接踏めると referer とかで管理画面のURLが漏れることがある。 スパムメール基地ってのは、もし受け付け時にユーザーにメールを送信する場合、他人のメールアドレスを入力されるとそっちへメールが飛ぶことを悪用されること。 文面に悪意あるURLを書かれると、それを踏まされちゃうかもしれない。 対策はいろいろあると思うけど完璧な対策は難しく、どこかを妥協することになると思う(メール送るのやめるとか)。 >>270 です。 >>271 さん 詳細なレスをくださり、ありがとうございます。 今回いただいたアドバイスを元にセキュリティを強化していきます。 本当にありがとうございました。 >>272 こんなところで聞くだけじゃなく、本買ってちゃんと勉強した方がいいよ 得丸さんって有名な人が最近本出したから買って損はない >>270 です。 >>273 さん 書籍情報ありがとうございます。 独学なのでありがたいです。 >>274 ごめん、名前間違えてた 徳丸 浩 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践 PHPがサンプルで使われてるので参考になると思うよ >>270 です。 >>275 さん 徳丸 浩ですね 了解しました。 重ね重ねありがとうございました。 練習なら色々気を遣うトレーニングになるからいいけど, 実際に公開する場合にはよく使われてるメールライブラリを使うべきだろうな >>278 スパムメール基地化に対しての対策とってるライブラリなんて見たこと無い。 正直、自動返信は鬼門だと思う >>279 それはライブラリでどうこうできる問題じゃなさそうだよね。 個別にトレードオフ見て仕様化してる。 送信されることを緩和するならボットチェック(と言うのか知らんが)入れるとか、本文の悪用防止ならメールに入力本文は転記しないとか入力本文中のURLを伏せて転記するとか、 あるいはそもそもメール送らないとか、悪用元が分かってるならIPアドレスチェックして内部処理変えるとか。 本文転記のニーズは高いから難しいのよね。 自動投稿系のスパムはハニーポットしかけるのが楽 <input type="text" name="mail" value=""> みたいなよくあるname値をもたせたダミーの<input>タグをcssとかで非表示にして GETやPOSTメソッドでnameの値が飛んできたらスパム扱いにするだけ 初心者でも簡単に実装できるのがメリット クラスAを継承したクラスA1、クラスA2を作りました クラスA1ではB1、クラスA2ではB2クラスをuse Bx as Bとして読み込み クラスAにクラスBを操作する処理を書けばクラスA1、A2に共通の処理を書かなくて済むかと思ったのですが、名前空間的にnew BとするとクラスAを基準としたパスで読み込もうとしてnot foundになってしまいます 親クラス側から子クラスで読み込む前提のクラスに対しての操作を書く方法はありますでしょうか? >>282 コード無いからエスパーするとinterface使え 少しマニアックな可能性はありますが シーサーブログへの自作エディタを作成したいと思っています。 プルダウン方式で時刻を簡単に選んだり その他を大分楽にすすめる事ができるのが目的です。 PHPでライブドアへの投稿ツールを少し作成してみたり PHP、pythonあたりを少しだけ知っている、というのが 現状の自分かと分析していますが ネットで少し検索してもシーサーブログへの投稿のためのプログラムは PHPであまり引っかかりませんでした。 最終的には、タイトル変更、カテゴリ選択、時刻設定、定型文の挿入あたりの出来る ツールを目指しているのですが、 スレッドのPHPとは離れますが もし良いツールが出来るならPerl、Rubyなどもチャレンジしてみるしかないのか、 と思うのですが、 現状、攻めれそうな言語、もしくは方法を・・ 本当にすみませんが、大まかなアドバイスでもいただけたら有難いです・・ よろしくお願いします。 >>285 結局APIをAPIの仕様に沿って叩くだけなんだから 言語なんか別に何でもいい SeesaaのAPIはXML-RPC互換らしいが XML-RPCを採用しているPHP製CMSで有名なのはWordPress だから情報は豊富にあるかと >>286 有難うございます。なるほど、そういう事ですか…。 確かにWordPressのそういう解説はある程度あると思われますし、 まずそこを自分も作って、それをシーサー向きにカスタマイズ、 という方向にもっていってみるのが得策ですかね。 プログラム等々色々しっかり理解できていないので 例えば、テストのワードプレスに投稿がうまくいっても それをシーサーに対応させる、その箇所でいかにも自分はつまずきそうですが… やってみようと思います!ありがとうございました! formからfileタイプでファイルを送信するとき、一緒にカスタムデータも渡したいんですが phpでカスタムデータを取得するにはどうすればいいんでしょうか カスタムデータはバックエンドやのうてフロントエンドで使うもんや html5の属性にdata-がつくってやつ? submitを動作のない通常のbuttonにしてjsでsubmitするようにして submitの前にjsでdata-要素を探して中身を hiddenフィールドに追加する処理書けば渡せる onsubmit時にやってもいいけどjavascriptオフだと想定したデータを受け取れない buttonにしてjsでsubmitすればjavascriptオフだとsubmit自体ができなくなるが そっちのほうが開発者には都合がいい 質問内容がPHPに関してではないし 回答もjavascriptを使用してと言うことだし Web製作板なら全般に渡って質疑しても良いけど プログラム板に設置したPHPスレとしては ちょっと違う感じを否めない webprogのほうは手取り足取りしてほしけりゃこっちこいって 初心者こっちに丸投げしてんだよな だから多少ズレててもしょうがない 難民受け入れる? 嫌がる人がいないなら、自分は反対はしない 今どきレガシーIE使ってるのとJavaScript使えない環境なんて考慮する必要ある? そういう人たちの考えを改めさせるためにも甘やかしてはだめだ あと広告ブロッカーなど入れてる人間にはおかえりいただくのだ IE11は新機能も追加されないのに 2025年10月までサポート続く 頭の固い奴がいつまでも使い続けそう そのレベルまで言うならサーバサイド使う必要性あるか? >>301 現状まだIE11はいいんだけど このまま取り残されるつもりなら害悪だね ITリテラシーのないユーザーが悪いわけではないが >>302 サーバサイドとクライアントサイドでは出来ることが違う 質問者のフォーム設計がクソであろうことは疑いの余地はないが >>300 で言いたかったことは 閲覧者様ありがとう!1人でも多くの閲覧者様に奴隷のように対応します ではなくサイト開設者側が閲覧者を選んでもいいということだ cakePHP3を使ってます。 mysqlに保存する場合、メールアドレスも暗号化した上で保存したほうがいいの? CakePHPの名前を出す意味が分からんが 動かす環境や設計思想によるとしか ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる