【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 >>351
下の?を使う書き方が苦手なんよね
頭がわるいからこう書かないと理解できない(´・ω・｀)
if(isset($_POST['foo'])){
$foo = $_POST['foo'];
}else{
$foo = false;
} >>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 ifとelseの中に書くのはあまりよくないのか(´・ω・｀)
全部こうやって書いてた。。。
理由が理解できないあほですまんけど次からはfilter_inputを使うから許して if (条件A) {
$foo = 'a';
} elseif (条件B) {
$foo = 'b';
}
var_dump($foo);
条件AもBも満たさなかった時にエラーになるわな
まずはvar_dumpが参照できるレベルで$fooを定義して必ず参照できることを保証しろってこと
phpしか書けないPHPerだとelseを書けばいいだろと思うかもしれんがそうじゃないそうじゃないんだ >>355
$test = "c";
if ($test == "a") {
$foo = 'a';
} elseif ($test == "b") {
$foo = 'b';
}
var_dump($foo);
エラーはでずにNULLと出るんだが。。何か間違ってる？ >>356
<?php
の次の行に
error_reporting(-1);
ini_set('display_errors', 1);
を書こう。大雑把にいうとエラーを全部出力するって意味になる
Notice: Undefined variable: foo（$fooっていう変数が定義されてない）
ってエラーが出力されるはず
あと条件式は
($test == "a") じゃなくて
($test === "a") と「=」3つ使って比較しよう
理由は「PHP 型 比較」とかで適当にググって >>356
エラーレベルってのがあってデフォの設定だとnoticeレベルのエラーとかは出ないようになってる
http://php.net/manual/ja/errorfunc.configuration.php#ini.error-reporting
undefineってのは未定義ってエラーなんで消したいなら最初に
$foo = null; なり $foo = ""; なりまずは$fooを定義(define)しろって事 エラーが出たし理由もなんとなく分かったよ サンクス
でも今まで書いたやつにもエラーが出まくり 本を写しただけなのに(´・ω・｀)
買う本を間違えたかな。。。初心者は何を買えばええんや。。。 >>359
エラーの設定ってのは学習時に一番最初にやるべき事で
本来はphp.ini（PHPの設定ファイル）の方へ設定すべき事なので
それについて書かれてないのならその本はハズレだろうねｗ
あと本を写したって書いてるけど
ソースコードを見たまままま打ち込む（写経と呼ばれる）作業は
何かしらの言語をもう少し書けるようになってからでいいと思う
（決して無駄ってわけじゃないけど）
今の段階だとソースが付録として付いてたり
ウェブからダウンロードできるようになってる方が良いんじゃないかな
具体的にこの本が良いと答えられたらいいんだけど
知らないんだ…すまない 最近はネットで動画を見ながら学習できるサービスが色々とあるからそういうのもいいんじゃね？
本は俺も知らん
phpのまともな本を探すのってウンコの山から金の塊を探すようなもんだ 未だにフレームワークを使う意味が分かんないとか言ってるのは中小零細の底辺ペチパーやろな
SQLとかを生で書いて文字列結合とかやってるんだぜきっと
LaravelあたりのモダンなFWを理解する頭もなさそう ウンコはすぐ分かる
まずそれを踏まないようにしよう 「サーバーを書く」っていうのはどういう意味？phpで書いたプログラムをサーバーに置いて動作するようにすることも含むの？まったく違う概念？ サーバーサイドプログラムを書くってことじゃないかな
基本的には動作するところまでも含むと思うが、
そんな表現使う人の気持ち次第ってところもあるかと サーバーサイドという言葉でくくってしまうとPHPはサーバーサイドで動くものなので語弊があるが
PHPは得意とするフロントを作る以外に例えばProxyサーバとして動作するものを短い行数で書いたりもできる
サーバーを書くってのはそういうものをPHPなり他の言語なりで書く時に使う表現かと >>367
例えばオンライン要素(マルチプレイ)のあるゲームを作る際に、サーバーにあるDBにアクセスしてデータを出し入れするプログラムをPHPで書いた場合は「サーバーを書く」と言っていいの？ >>368
そういう用途では使わないと思う
Proxyみたいにサーバ上でスタンドアローンで動作するアプリと言えばいいかな？そういうものを書くイメージ
例えばwebminはhttpサーバ機能をperlで書いてるがそういうものをサーバーを書いたと言うのはしっくりと来る >>369
完全に理解した！！(大嘘)
ありがとう ちょっとググるとguzzleでproxy書いてるのとかあったからやってみればいいんじゃないかな
そうすればサーバーを書くというのはどういうものなのか何となく分かるのでは サーバってのはsocket関数使ってポートlistenしたデーモンであること
>>368はたんにバックエンドなだけ >>373
今のところ使い道が浮かばないからやめておくよ。でもありがとう
>>374
これで完全に合点がいった。ありがとう VB/VBA（クラス無し）しか書かけないけど、PHP(5?)を触ることになった
入門書探してるんだけど、尼のカスタマーレビュー見るとどれも賛否両論でまともなのがない
「これ買え」ってのない？
内容全部が役に立つわけないのはわかってるから、本の特徴が知りたい リンクをクリックすると問い合わせに回答するメールの画面が開くという処理があるのですが、
EdgeとIEでは正常に動作するのですが、Chromeだと何も起こらない時があります。
$val = mb_convert_encoding($_POST['body'], "SJIS", "UTF-8");
body（本文）が短いとChromeでも正常に動作するのでbodyの内容が長い時に↑のエンコード時に何か異常が起きてると思うんですけどわかる方いますか？ input要素の入力の有無を確認する方法で一般的な方法を教えてください。
1. if($hoge == ''){･･･}
2. if($hoge === ''){･･･}
3. if(empty($hoge)){･･･}
4. if(!$hoge){･･･}
5. if(!strlen($hoge)){･･･}
6. 他の良い方法も教えてください。
PHPを初めて日が浅いので変な質問をすると思いますが、よろしくお願いします。 >>378
<form action="" method="post">
<input type="text" name="hoge">
のフォームから飛んでくる$_POST['hoge']の値が空かどうかは
if ((string) filter_input(INPUT_POST, 'hoge') === '')
と書くのが実用的（正しいというと語弊があるので「実用的」と表現しとく）
少なくとも3や4は使っちゃ駄目
hogeに'0'が入っていても空として判定されてしまう >>377
<a href="mailto:aaa@example.com?body={$val}">〜</a>
としてリンクをクリックした時に
メーラーの本文に$valが書かれた状態にしたいって話だろうか？
もしそうならbodyに何byteまで指定できるかは環境依存なので
その方法は止めて
ローカルのMTAやSMTP使ってメールを飛ばすようにした方がいい >>376
ちょっと上でも話が出てるがPHPには初心者ならこれ！という本が本当にない
強いていうならPHP公式サイトにあるPHPマニュアルが一番いい
何かを作りながら学びたいのであれば
ドットインストールみたいなサービスも選択肢になるかも プログラミング言語として学ぶだけならいざ知らず, PHPの場合はほぼ確実にサーバサイドプログラミングのお作法とセットだから難しい
構文だけは簡単だけど実用しようと思うと全く初心者向けじゃないと思うわ
(サーバサイドアプリケーション自体初心者向きじゃないとは思う) 本屋で色々見て一番読みやすそうなの買えばいいんだよ
何が読みやすいなんて人それぞれなんだから >>378です
>>379さん
アドバイスありがとうございます。
教えてくださったコードとPHPマニュアルを見て動作から学びたいと思います。
また、3と4の方法は、日本語のみの場合、使っても問題ないということでしょうか。
覚えることが多いですが、頑張ります。 >>381-383
やっぱなぁ
入るスキルがバラバラだからコレっつーのが難しいんだな
「PHPマニュアル」が一番ってのはわかるんだが、リファレンスであって教本じゃない感じ
XAMPP(MySQLでPHP5)環境だから、大きい本屋であさって、尼で中古買うわ 自分が始めた10年ぐらい前は赤マンモス本とかが流行ってたけどね
今はもう古いんじゃないかなあ
困ったときはとりあえずみんなオライリーって言うけど誰も言ってなかった >>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ではどう判定するのか
そもそも日本語をどう定義するのかって話はあるけど >>387さん
詳しいレスありがとうございます。
それぞれの関数の意味を理解するよう勉強します。
ありがとうございました。 >>380
ありがとうございます。mailtoじゃなくjavascriptですけどメーラー本文に問い合わせ内容が書かれた状態にしたいです。
私は専門はオフコンなのでほとんどPHP等の知識はないのですが、作った人がもういないので仕方なく探り探りやってる状態です。 >>389
今JavaScriptでやってるという方法も
結局は内部的にmailtoスキームを使ってるのではないかと思う
その方法はブラウザやブラウザから呼ばれるメールソフトに依存してしまう
しかも環境によってはそもそもメールソフトが起動しない
つまりPHPの処理の問題ではないって事ね
Googleフォームみたいに
問い合わせフォームを簡単に作れるサービスがたくさんあるので
そういうのを使ってみるのはどうだろう？
「問い合わせフォーム 作成」とかでググってみるとか >>389
試しに実験してみたけど
Chromeはやはり?body=に長過ぎる文字列を指定してると
mailtoが反応しなくなるっぽいね
適当に10,000byteのbodyを与えみたら
Chromeはmailtoをクリックしても何も起こらなくなる
Firefoxだと2046byte以降が削除される
これはもう仕様なので他の方法にするしかないだろうね
今までも環境によっては動いてなかったんだと思うよ >>389
GETじゃなく、POSTでやってみたら
PHPの知識というよりWebの動作についての知識 >>390-391
やはりそうですかありがとうございます。
問い合わせフォーム自体はあるのですが、返信する時にメーラーを使っています。
>>392 POST勉強してみます >>394
問い合わせ内容がメールで来るわけではなく画面に表示されて
画面内のリンクをクリックしたら返信用にメーラーが立ち上がるみたいな仕組みなのかな？
問い合わせ内容が何かしらのメールアドレス宛に届くようにしさえすれば
あとは運用で解決する問題なような気がするけど… >>395
まさにそう言うことです
VBAくらいは触ったことはあってもWebアプリはチンプンカンプンで一から勉強です・・・ 運用でカバーするなら今のままでIE使わせればいいって話でもあるわな。 $var = $_POST['var'];
よりも
$var = filter_input(INPUT_POST,'var');
が良いんですか !?
前者は危険だと聞いた(´・ω・`)
勉強中の身だけどﾑｽﾞｶｼｲ filter_inputで少しぐぐれば出てくるでしょ
分からない単語出てきたらまたぐぐるってやってけば分かるさ >>399
前者が危険な理由はキーワード知らないと filter_input でググってもでてこないと思うけど。 >>400
実際にググってみた？
キーワード知らなくても検索結果の上から5つくらい見ればそれなりには理由分かるよ filter_input だと便利な場面があるというだけで、$_POST はこれまでみんな使ってきたものだし留意点を押さえれば問題があるわけじゃない。
$_POST での参照は、そもそもそのパラメタが設定されているか、期待する型かとかを自分で判定する必要があるというだけで、fi-ter_input はそれを場合によって便利にするユーティリティ関数程度のもの。 $_POST が危険って言われるのは、変更可能なスーパーグローバルだから。
filter_input は HTTP で投げられた値を直接参照するので、$_POST とは全然別物。
ググってでてくる情報で、変数汚染に触れてる記事はないので、概要知らないとたどり着けないんだぜぃ！ >>405
行儀の悪いモジュールやライブラリとか使うと書き換えられるかも。ってぐらい。
実際にはそれほど気にしなくて良いレベルだけど、それを気にしなきゃいけないプログラムは多い。
読みやすく/使いやすく/再利用性の高いコード書くってことは、結合を疎に保つことが重要なんで、そのあたり理解してると $_POST はまず使わん。 >>404
＞$_POST が危険って言われるのは、変更可能なスーパーグローバルだから。
＞filter_input は は HTTP で投げられた値を直接参照するので、$_POST とは全然別物。
$_POST が危険って言うのは聞いたことがないんだが、
Webサーバーが受けとったリクエストをPHPが取得して変数に代入している訳だろう？
PHPスクリプトが変数の値を参照するのに誰かが割り込めるのかな
リクエスト内容を直接参照すれば他が割り込めなくなるとは思えないが
filter_input がやれるなら、他も出来ると言うことだろう $HTTP_POST_VARS って変数があり、
これはスーパーグローバルではないけれど
現在は非推奨となってる >>408
ここで言う「危険」は「セキュアじゃない」って意味ではなくて、「コードが意図した通り動かない可能性がある」とかの意味。
$_POST は「スーパーグローバル変数」なので、コード内のいたる箇所で書き換えることが可能。
で、書き換えちゃった場合、それを使用している他の箇所にも影響出るよね。ってことを危険っ言ってる。
普通は書き換え行うようなことはしないけど、何かの意図があって書き換えた場合、後に想定を超える影響を及ぼす可能性が大。
filter_input は読み取りのみが保証されるので、疎結合なコードを書くには filter_input を使用することが必須。
>> 407
GET も考え方は同じ。 >>410
そういうのはバグって行って、POSTスーパーグローバル変数の問題ではないなあ
使い方が間違えているか、ワザとそうしているかだろう
普通に推奨されている方法をあえてとらないって 意味が無いと思う
自分だけでやってシステムが終わるまでメンテするって言うなら良いけど >>411
バグの入る余地をなくして、読みやすく/使いやすく/再利用性の高い危険を回避したコードを書くには、結合を疎に保つことが重要
で、結合を疎に保つには filter_input を使用することが推奨されるって話なんだけど、通じてる？
普通に推奨されている方法をあえてとらないって 意味が無いと思う
自分だけでやってシステム終わるまでメンテするって言うなら良いけど あえて書き直すほどの事は無いと思う
開発する人間が注意すれば避けられること
そこまで拘るなら、Webサーバー使わずに
自前でリクエストを受けとってしまえば良いんじゃない？
普通に推奨されているとは思わないよ。そんな関数初めて聞いたし。
どこでそんな事で大騒ぎになっているの？サイト教えて 疎結合と filter_input がいまいち結び付かん。
HTTPリクエストから必要パラメタを取り出しオブジェクト化して、後はそのオブジェクトを使ってパラメタにアクセスしましょうってんならHTTPリクエストを隠蔽できて疎かなって気もするが。
$_POST の代わりに filter_input を使うと何と何が疎になるの？って感じ。 >>414
変数のスコープのの話なんて、適当に探せばいくらでも出てくるだろうに＾＾；
堅牢なコードを理解してないみたいなんで、これでも見て意識改善するといいよ。
https://youtu.be/17i1EL9pBwA >>415
> HTTPリクエストから必要パラメタを取り出しオブジェクト化して、後はそのオブジェクトを使ってパラメタにアクセスしましょうってんならHTTPリクエストを隠蔽できて疎かなって気もするが。
その認識で正しいと思うよ。
ただ、それはそれ。
取り出しの時に行儀の悪いモジュールやライブラリ使用したときに、邪魔される可能性は残る。
取り出しのときにでかいスコープを回避できる 読み取り専用の関数を使用すると、予防的にコードが書けるってことです。 PHPを扱うサイトでfilter_input が話題になっている所あるの？
見つからないんだけど
普通に推奨されている位だから、たくさんあってもおかしくはないよね？ Webサーバーからリクエストを受けとるのに隠蔽も何もないと思うけどね
グローバル変数だから書き換えられる可能性があるというのも変
書き換えているのは自分じゃないか。人のせいには出来ないでしょう
大勢で開発しているなら、その処理を行う担当以外は操作禁止にするだけだし >>418
filter_input じゃ、ググれないよ。
グローバル変数を使用しない理由を検索してみるといい。
キーワード知らないと、ググれないっていうのはそういうこと。 >>419
@t_wada の前でも同じこと言えんの？ 既存コードを修正すべきだとまでは言わないが, 新規コードにはfilter_inputを使うべきだという点に関しては疑う余地がない >>420
つまり、公開されているPHP関連のサイトではそのような話題が出ていないと言うことでOK？ >>419
んまあデバッグしたりコマンドラインでも実行できるようにしたりする可能性を考えると、HTTPリクエストの扱いは浮かせて置いた方がいいかなって気はするよ。
後は同意。
$_POST がダメで filter_input ならいいって話には繋がらないと思うし、$_POST をわざわざ書き換えるならあえてそういう設計なんだろうけど、それが甘いか明確になってないだけじゃねとしか思わん。
そういう設計はかくかく然々でお勧めしないよって話ならまだ聞ける。
ちなみに >>416 は見たよ。
話のうまいやつで面白かったよ。
PHP にも assert あったのね。しかも運用時にいないことにできるとか、なかなかいいじゃないか。 キーワードで検索出来ないってことがとても不自然に感じるんだけど
普通に推奨されていると言うなら、行う記事があってもおかしくはないよね
まさか、この関数が非公開関数で秘密にしないといけないものだったりして >>423 >>425
グローバルスコープな変数使うなよって話以上に何が聞きたいの？
グローバル使用しない代替手段使おうねって話でしか無いんだけど＾＾；
そろそろ理解しようよ。 >>426
それならそういえば良いでしょう
変な関数持ち出す必要もないし
普通に推奨されているなんて言いだすから
サイトを教えてくれと言う話になってるんだし >>426
よく言われるようなグローバル使うなって話は、自分で定義するのは極力避けましょうってことであり、用意されてるものを使うなって話ではないんじゃない？ そんな事実上の内部バグを問題にするよりも
リクエスト投げてくるのは、こちらが用意したフォームとは限らない、
想定外のリクエストに乗せられることが現実に発生するんだし、
そちらのチェックの方が重要だと思うよ
そういう実際的な話題を提供して議論する方が良いと思うな >>428
最初っから、そう言ってるんだぜぃｗ
> >>399
> 前者が危険な理由はキーワード知らないと filter_input でググってもでてこないと思うけど。 途中で投稿してしまった。
> $_POST が危険って言われるのは、変更可能なスーパーグローバルだから。
> filter_input は HTTP で投げられた値を直接参照するので、$_POST とは全然別物。
> ググってでてくる情報で、変数汚染に触れてる記事はないので、概要知らないとたどり着けないんだぜぃ！ >>429
改変されるリスクの有無は同じなので、限定した話ではない。 ググっても出てこない関数がどうして普通に推奨されていると言うのか、
その根拠を聞きたかったんですが
そんなに話題に上らない関数と言うことで良いんでしょうか？ しつこくて済みませんが、グローバル変数を使うなと言うのは、一種の宗教だと思うんです
信じる人はそうすれば良いけど、信じない人はそうしなくてもいいと言う程度で PHP The Right Wayくらいは必読だと思う
ttps://www.phptherightway.com/#data_filtering
理由もなくスーパーグローバルを直接叩くようなコードを新しく書いたならそれだけでrejectするに足る
それ以外のグローバル変数も納得出来る説明がコードやコメントに無いならreject エラーが起きない方法をとるのに越した事はないと思うけど、何をそんなにむきになってるのだろう >>436
そこからどこまで読めばお前さんの言いたいことが書いてあるのが分からんが、とりあえず外部データをサニタイズせずに使うことの危険性なんかを説明してるのかな？
それを解決するのに filter_input や filter_var を使えますよという話だよね？
グローバル使うな的な話は書いてないようだが、ただ実はもしやと思ってたんだけど、register_globals を使うなって話と混同してるんじゃない？
それは危ないから使わない方がいいよ。
そしてそれは $_POST を使うななんてこととは全く関係無い。 >>434
ずっと同じことのループやねぇ。。。
> ググっても出てこない関数がどうして普通に推奨されていると言うのか、
ググって出てこないのは、$_POST の危険な理由。
関数としては各所で便利だぜぃ。って紹介されている。
PHP The Right Way もその一つ。 >>435
> しつこくて済みませんが、グローバル変数を使うなと言うのは、一種の宗教だと思うんです
宗教じゃなくて、意識の話。読みやすく/使いやすく/再利用性の高いコード書くことを意識していれば、グローバル変数の使用はまず避けるように設計する。
避ける気がないのは、読みやすく/使いやすく/再利用性の高いコード書く意識が無いってだけ。 >>435
他言語しか知らないけど、グローバル変数なんてめったに使わない
>>440
PHP勉強中だけど、教本のサンプルって短いからグローバル使いまくり
いいコードの書き方ってなかなかないね
やっぱり実践のコード(（またはきれいな）が見たいよ filter_input 自体は $_POST使っているんでしょ？ >>440
だからさ、自分でわざわざグローバル変数作るなってことだろ、それは。
既に用意されてるものを使うなって理由としてグローバル変数だから（誰でも書き換えられるから）ってのは意味が分からんだろ。
わざわざ示されたもの読んで言ってるんだから >>438 にも答えてくれよ。 >>443
ずっと同じことのループやねぇ。。。
> 改変されるリスクの有無は同じなので、限定した話ではない。
改変されるリスクの有無は同じなので、限定した話ではない。
この辺が、結合を疎にする意味。
> わざわざ示されたもの読んで言ってるんだから >>438 にも答えてくれよ。
オレが示したわけじゃないんで解釈あってるか分からんけど、普通に読めば「ググっても出てこない関数がどうして普通に推奨されていると言うのか、その根拠を聞きたかったんですが」に対するコメントだと思うぞ。
filter_input 紹介している有名記事を教えてくれたんでしょ。 >>442
filter_input は HTTP で投げられた値を直接参照するので、$_POST とは全然別物。
試してみるといいよ。オレも最初試したｗ >>444
あ、ごめん
別の人と混同してたわ
それはそれとして結合を疎にする話、自分でグローバル変数を用意してそれを介して複数クラスやモジュールでコミュニケーションするって話ならそれは結合が密だと言えると思う。
でもただシステムが用意してるリソースを参照するからと言ってそれが密かと言えばそうじゃないし、密だったとしてそれを疎にするためにラップしなさいっていうならそれは分かる。
filter_input 使ったところで何が疎になってるの？って感じだけど、そこらへんどうなの？
若干繰り返しになるけど、PHP固有の関数である filter_input 自体を直接参照せずラップしましょうってところまで行ってるのであれば、そういう方法論もあるかと思うよ。
グローバル変数誰かが書き換えたら不具合が起こるって、スコープが狭いだけでクラスメンバ変数を誰かが書き換えちゃったらという話と同じような話でしょ。
早い話、選定してるものを仕様通りに使ってないという問題なんだかrさ。 個人的には $_POST をリードオンリーにして使ってるが、俺だけだろうな >>446
filter_input は HTTP で投げられた値を直接参照するので、$_POST とは全然別物
スーパグローバル変数は「参照」できるだけでなく、「書き込む」こともできるのでどう使っても密になる。
オブジェクトのプロパティに「POST内容を突っ込んでおく」場合でも、スーパーグローバル変数を使用して取り出すと行儀の悪いモジュールやライブラリに邪魔される可能性が残る。
取り出しのときに読み取り専用の関数を使用すると、そういった結合を疎にすることができ、予防的にコードが書ける。
で、ここで言う読み取り用の関数が filter_input
> グローバル変数誰かが書き換えたら不具合が起こるって、スコープが狭いだけでクラスメンバ変数を誰かが書き換えちゃったらという話と同じような話でしょ。
読みやすく/使いやすく/再利用性の高いコード書く場合は、発想が逆でそういった事をさせないように設計する。
堅牢なコードを理解してないみたいなんで、これでも見て意識改善するといいよ。
https://youtu.be/17i1EL9pBwA これ以上やっても信仰する宗教のようなのでやめますが
php.netで $_POST変数が非推奨になり、filter_input関数が推奨になったら
その時に考えることにします
今は、いくつかある対策方法の一つとして聞いておきます >>448
書き込めたら密だって？
なんかワケわからんが、お前さんの言う密って何？
ちなみにそれは見たよ。 >>450
複数クラスやモジュールでコミュニケーションしてしまう状態 ■ このスレッドは過去ログ倉庫に格納されています
