PHP勉強（文法以上のところ） [プログラミング]
今回も下記のページを見て勉強していきます。
https://www.javadrive.jp/php/
やっと文法的なところは終わったので、後は実践的なWebアプリに近いところですね。これができるようになってくると少しは楽しくなってきそうな気はしますが、PHPは文法自体がそんなにでかくないので勉強しやすいのはありました。罠となる言語的な仕様というのもいくつか見られましたしね。
いきなり出来合いのシステムを見て勉強というのも手なんですが、最初から何書いてあるのかわかった方が勉強が捗りますしね。C++は文法を理解しながらMFCのソースを読み解いていったんですが、やっぱ基礎的なところの文法は一通り勉強しておいた方がいいと痛切に思いましたしね。
C++はC言語もひよっこの状態で突っ込んで行ったので、MFCというライブラリの癖と、Win32API自体の機能と、C++の文法がない交ぜになって正直効率は良くなかった。とはいえ、学校の授業もなく手探りでやってた頃で、インターネットもダイヤルアップでGoogleさえ一般的じゃなかった頃の時代。今はお金を対してかけなくても情報を得られたけど、昔は全然そうじゃなかった。まだ携帯とインターネットは隔てられていたし、スマホも存在しなかった。それを考えると楽になったもんだと思うのだけれど、それだけ覚えないといけない事も増えていたりする。
とおじいちゃん的な話はさておき。
ベーシック認証をisset( )でできるみたいですが、そのセットとなるユーザー名とパスワードをどこに用意するのかよくわからない。
https://qiita.com/mpyw/items/dc2cb3632370389d700e
ここはがっつりソース上に埋め込んでしまっていますが、実際のところどうなんでしょうね。PHPのソースが見えちゃうということは基本的にはないから大丈夫だとは思いますが、ちょっとね…。基本Basic認証なんて使わないなんて話もありますが、それはその場所の慣例という事で。ちょっときちんとやろうとすると大変みたいなので、あとで必要があったら詰めてやりたいと思います。
まぁみんなのIDとパスワードをDBに保管して、メールで認証ってのが普通のやり方なんだろうけど、そこまでやると結構しんどそうだな。そうなるとセッション管理もしなくてはいけないだろうし。
そもそもBasic認証はWebサーバの機能として実装されてもいるので、別にPHPでやらないといけない事ではないのだけれど、正式オープンさせるまでの足止めにしたりする程度のものが一般的らしい。
一応やってはおくけど、使うかどうかは別問題だと思っておこう。ただ単にHTMLの上段におまじないとして貼り付けておけば効く感じではあるが、効力あるのはそのページだけだしなぁ。他のページはセッションが切れていたら入れないようにしとくとか、全体は気にしないといけない気はする。
die()ってのがなんなのかなと気になってはいたけれど、
http://www.arubeh.com/archives/444
「メッセージを出力し、現在のスクリプトを終了する」
という事らしく、print_r()と一緒に使うとデバッグが捗るらしい。とにかく正常終了ではないことは確かだ。
ただBasic認証が一回通ってしまうと、ブラウザが覚えるらしくその後も普通に通れるので複数回やりたいときには困るかもしれん。時間制限とかできんのかな？ まぁよく考えたら普通はログイン処理とかはBasic認証でやったりは普通はないので、改めて独自のユーザー、パスワードのログイン画面とセッションの組み合わせでやるんだろうけどな。まぁおいおいで。
あと、
「header() は、生の HTTP ヘッダを送信するために使用されます。」
だそうです。
https://www.php.net/manual/ja/function.header.php
一次情報だから嘘はない。
今気づいたんだけど、Webサーバの何もファイル名を示していない場合は、index.htmlを出すという慣習があるけれども、index.phpもそれに習っているみたいだな。index.phpと書かなくても勝手に出てきた。ちょっとは気にしておこう。もしかしたらPHPじゃなくApacheの設定の問題かもしれない。
DBはポスグレを使いたいので、めんどうなのでその他のDBの説明は飛ばす。MAMP的にはMySQLなんだろうけど、MariaDBとかの兼ね合いもあるし、PostgreSQLは前にRoRで使っていたのもあって幾らかは馴染みがあるし。
https://www.javadrive.jp/php/postgresql/
データベースの用意って一つもSQL文が書いてないじゃんかよぅ。
PHPの関数は何を使うのかというと
で接続して、
で切断する。
そこいらはそんなに面倒なことはやっていない。まぁつないで切るだけだから。
クエリー投げるのも普通。
例ではシングルクォートでくくっていたけど、SQLでは文字列をダブルクォートでくくれないと思うので（それで変なエラーが出てハマった）、SQL文全体はダブルクォートでくくるべきなんじゃないかなぁ、しらんけど。
というか、他の文ならDBに変更を加えることができて受け取らなくてもいいけど、select文を発行しても受け取らないと意味ないので、結果からデータを受け取る。今度上の$resultをprint_r()とかで見てみようかな？
pg_query()で出した結果を配列で受け取るには、
連想配列で受け取るには、
でできるらしいが、いまいち連想配列の取り出し方がわからんな。配列で受け取るのは、select文で選んだレコードの列を返すのだろうし。あ〜一行ずつ出してくれるのね。もっとどかっといっぺんにもらえるものだと思っていた。まぁ1行ずつもらった方が処理しやすいけどね。
PGSQL_NUMはSQL文の選んだ順番で出してくれそうなので、その順番を覚えていないといけない。その分、PGSQL_ASSOCは列名で指定できるみたいなので、そういう順番による可読性の下がるようなことはなさそう。普通は連想配列で出すのがいいのだろうな。そこまで処理の速さが違うとも思えないし。
なんとなくやり方はわかった。あとはSQL文そのものをきちんと作ればいいということなんだろうな。SQL自体はそんなに難しくはないのだが、それはそれで面倒。というか、ポスグレにデータを入れてSQL文をゴリゴリ打ち込めればいいのだろうな。データをどこかから取ってきて入れるのが面倒なんだよなぁ。仕事だとそのところの積み重ねがあったりするので、地道な面倒さがないのがいいよな。
SQLインジェクション対策とかにpg_escape_string()を使うんだよ、みたいなことを書いてありますが、それはそれとして後で考えることにする。それよりもきちんと検索できたりすることの方が先ですからね。まぁ外向けのシステムを作らない限りは、それほど気にしなくてもいいのかもしれませんが、今はそうでもないらしいです。内側から壊すやつも少なからずいるらしいので。
そのうちブラックボックス的にもホワイトボックス的にも自分の作ったシステムを攻撃する事をするかもしれません。合法的にクラッカーができるというのはちょっといいかもしれません。とりあえずSQLインジェクションとかXSSとかは一通りできるようになっておきたいなぁ。
DBを扱うならPDOを扱っておいた方が後々問題がなくて済むかもしれない。
https://www.javadrive.jp/php/pdo/
だけど、DBを変えなくてはいけないほどの変更があった場合は、他にも全体も変えなくてはいけない改変もある事が考えられるので、必ずしも使うべきということでもないかもしれないなと思ったり。
ただMySQLみたいな事態も考えられなくはないので、できるだけのことはやっておいた方がいいのかもね。というか、特定依存の仕組みの方が簡潔に書けるというのは当然のことなので、それでも汎用性を持たせた方がいいという前提であればそうするべきだとは思う。特に仕事で使うんだったらなおさらのことだし、基本的にDBなんてお仕事でしか使わないわけだしね。お仕事じゃなくてもお仕事的な要素が入り込んできてしまうことは間違いないし。
あとは参照サイトではメールが扱われていたんだけど、長くなったのでまたの機会にします。というか今時ASCIIメールとか出したら、スパム認定されて見もされない気がするんだけどね。まぁ日本語にするにもエンコードしないといけないし面倒なのはわかるけどさ。それも追々ってことで。その前にLaravelとかやっているかもしれんけど。とりあえず、これで終わり。
https://www.javadrive.jp/php/
やっと文法的なところは終わったので、後は実践的なWebアプリに近いところですね。これができるようになってくると少しは楽しくなってきそうな気はしますが、PHPは文法自体がそんなにでかくないので勉強しやすいのはありました。罠となる言語的な仕様というのもいくつか見られましたしね。
いきなり出来合いのシステムを見て勉強というのも手なんですが、最初から何書いてあるのかわかった方が勉強が捗りますしね。C++は文法を理解しながらMFCのソースを読み解いていったんですが、やっぱ基礎的なところの文法は一通り勉強しておいた方がいいと痛切に思いましたしね。
C++はC言語もひよっこの状態で突っ込んで行ったので、MFCというライブラリの癖と、Win32API自体の機能と、C++の文法がない交ぜになって正直効率は良くなかった。とはいえ、学校の授業もなく手探りでやってた頃で、インターネットもダイヤルアップでGoogleさえ一般的じゃなかった頃の時代。今はお金を対してかけなくても情報を得られたけど、昔は全然そうじゃなかった。まだ携帯とインターネットは隔てられていたし、スマホも存在しなかった。それを考えると楽になったもんだと思うのだけれど、それだけ覚えないといけない事も増えていたりする。
とおじいちゃん的な話はさておき。
ベーシック認証をisset( )でできるみたいですが、そのセットとなるユーザー名とパスワードをどこに用意するのかよくわからない。
https://qiita.com/mpyw/items/dc2cb3632370389d700e
ここはがっつりソース上に埋め込んでしまっていますが、実際のところどうなんでしょうね。PHPのソースが見えちゃうということは基本的にはないから大丈夫だとは思いますが、ちょっとね…。基本Basic認証なんて使わないなんて話もありますが、それはその場所の慣例という事で。ちょっときちんとやろうとすると大変みたいなので、あとで必要があったら詰めてやりたいと思います。
まぁみんなのIDとパスワードをDBに保管して、メールで認証ってのが普通のやり方なんだろうけど、そこまでやると結構しんどそうだな。そうなるとセッション管理もしなくてはいけないだろうし。
そもそもBasic認証はWebサーバの機能として実装されてもいるので、別にPHPでやらないといけない事ではないのだけれど、正式オープンさせるまでの足止めにしたりする程度のものが一般的らしい。
一応やってはおくけど、使うかどうかは別問題だと思っておこう。ただ単にHTMLの上段におまじないとして貼り付けておけば効く感じではあるが、効力あるのはそのページだけだしなぁ。他のページはセッションが切れていたら入れないようにしとくとか、全体は気にしないといけない気はする。
die()ってのがなんなのかなと気になってはいたけれど、
http://www.arubeh.com/archives/444
「メッセージを出力し、現在のスクリプトを終了する」
という事らしく、print_r()と一緒に使うとデバッグが捗るらしい。とにかく正常終了ではないことは確かだ。
ただBasic認証が一回通ってしまうと、ブラウザが覚えるらしくその後も普通に通れるので複数回やりたいときには困るかもしれん。時間制限とかできんのかな？ まぁよく考えたら普通はログイン処理とかはBasic認証でやったりは普通はないので、改めて独自のユーザー、パスワードのログイン画面とセッションの組み合わせでやるんだろうけどな。まぁおいおいで。
あと、
「header() は、生の HTTP ヘッダを送信するために使用されます。」
だそうです。
https://www.php.net/manual/ja/function.header.php
一次情報だから嘘はない。
今気づいたんだけど、Webサーバの何もファイル名を示していない場合は、index.htmlを出すという慣習があるけれども、index.phpもそれに習っているみたいだな。index.phpと書かなくても勝手に出てきた。ちょっとは気にしておこう。もしかしたらPHPじゃなくApacheの設定の問題かもしれない。
DBはポスグレを使いたいので、めんどうなのでその他のDBの説明は飛ばす。MAMP的にはMySQLなんだろうけど、MariaDBとかの兼ね合いもあるし、PostgreSQLは前にRoRで使っていたのもあって幾らかは馴染みがあるし。
https://www.javadrive.jp/php/postgresql/
データベースの用意って一つもSQL文が書いてないじゃんかよぅ。
PHPの関数は何を使うのかというと
$conn = pg_connect("host=localhost dbname=db user=usr password=pass");
で接続して、
pg_close($conn);
で切断する。
そこいらはそんなに面倒なことはやっていない。まぁつないで切るだけだから。
クエリー投げるのも普通。
$result = pg_query('SELECT * FROM user');
例ではシングルクォートでくくっていたけど、SQLでは文字列をダブルクォートでくくれないと思うので（それで変なエラーが出てハマった）、SQL文全体はダブルクォートでくくるべきなんじゃないかなぁ、しらんけど。
というか、他の文ならDBに変更を加えることができて受け取らなくてもいいけど、select文を発行しても受け取らないと意味ないので、結果からデータを受け取る。今度上の$resultをprint_r()とかで見てみようかな？
pg_query()で出した結果を配列で受け取るには、
$rows = pg_fetch_array($result, NULL, PGSQL_NUM);
連想配列で受け取るには、
$rows = pg_fetch_array($result, NULL, PGSQL_ASSOC);
でできるらしいが、いまいち連想配列の取り出し方がわからんな。配列で受け取るのは、select文で選んだレコードの列を返すのだろうし。あ〜一行ずつ出してくれるのね。もっとどかっといっぺんにもらえるものだと思っていた。まぁ1行ずつもらった方が処理しやすいけどね。
PGSQL_NUMはSQL文の選んだ順番で出してくれそうなので、その順番を覚えていないといけない。その分、PGSQL_ASSOCは列名で指定できるみたいなので、そういう順番による可読性の下がるようなことはなさそう。普通は連想配列で出すのがいいのだろうな。そこまで処理の速さが違うとも思えないし。
なんとなくやり方はわかった。あとはSQL文そのものをきちんと作ればいいということなんだろうな。SQL自体はそんなに難しくはないのだが、それはそれで面倒。というか、ポスグレにデータを入れてSQL文をゴリゴリ打ち込めればいいのだろうな。データをどこかから取ってきて入れるのが面倒なんだよなぁ。仕事だとそのところの積み重ねがあったりするので、地道な面倒さがないのがいいよな。
SQLインジェクション対策とかにpg_escape_string()を使うんだよ、みたいなことを書いてありますが、それはそれとして後で考えることにする。それよりもきちんと検索できたりすることの方が先ですからね。まぁ外向けのシステムを作らない限りは、それほど気にしなくてもいいのかもしれませんが、今はそうでもないらしいです。内側から壊すやつも少なからずいるらしいので。
そのうちブラックボックス的にもホワイトボックス的にも自分の作ったシステムを攻撃する事をするかもしれません。合法的にクラッカーができるというのはちょっといいかもしれません。とりあえずSQLインジェクションとかXSSとかは一通りできるようになっておきたいなぁ。
DBを扱うならPDOを扱っておいた方が後々問題がなくて済むかもしれない。
https://www.javadrive.jp/php/pdo/
だけど、DBを変えなくてはいけないほどの変更があった場合は、他にも全体も変えなくてはいけない改変もある事が考えられるので、必ずしも使うべきということでもないかもしれないなと思ったり。
ただMySQLみたいな事態も考えられなくはないので、できるだけのことはやっておいた方がいいのかもね。というか、特定依存の仕組みの方が簡潔に書けるというのは当然のことなので、それでも汎用性を持たせた方がいいという前提であればそうするべきだとは思う。特に仕事で使うんだったらなおさらのことだし、基本的にDBなんてお仕事でしか使わないわけだしね。お仕事じゃなくてもお仕事的な要素が入り込んできてしまうことは間違いないし。
あとは参照サイトではメールが扱われていたんだけど、長くなったのでまたの機会にします。というか今時ASCIIメールとか出したら、スパム認定されて見もされない気がするんだけどね。まぁ日本語にするにもエンコードしないといけないし面倒なのはわかるけどさ。それも追々ってことで。その前にLaravelとかやっているかもしれんけど。とりあえず、これで終わり。
タグ：PHP
Twitterまとめ投稿 2019/12/08 [Twitter]
carbonhydrat日本人の給料がまるで上がらない決定的な要因 国際的に見ても､もはや競争力を失っている | 国内経済 - 東洋経済オンライン https://t.co/EgeqLXLgLZ #東洋経済オンライン @Toyokeizai 低能に金を払… https://t.co/xfszKT4paB12/07 10:13
2019-12-08 05:01
コメント(0)
