Browsing the archives for the MySQL category
Browsing the archives for the MySQL category
PHP素人(僕みたいなやつ)のありがちな勘違い
①header関数
勘違い)用途は別ページにジャンプするためのもの。 どこにいれてもいい。
<?php
header('Location:path');
?>
よくこんな使い方でページのリダイレクトさせてますが、header関数の使い方の一つに過ぎません。
大前提はHTTP ヘッダの送信に必要な関数なので、別に第一引数にLocationとせずに
<?php
header('Content-type: image/png');
?>
とかしちゃうとそのページがpngファイルとかになっちゃうんですね。
まぁ後続にimagepng()とかで出力せんといけませんが。
まぁそんな感じでリダイレクトってのはヘッダ送信時の副産物で本当の用途はHTTPヘッダ送信のためのものです。
ヘッダ送信ってのはすべての出力の前にないといけないものなので当然前にechoとかの何かしらな出力があるとエラーがでます。
ありがちなミスはinclude と require_once とかでファイル引っ張ってくるときに引張先でエラーがあってheader関数に怒られるとかです。
②(MySQL) char型とvarchar型の違い
php素人(僕みたいなやつ)はとかくDBを扱う機会が多いくせにあまり定義を知らなかったりします。
特にcharとvarchar何が違うんやろ? 別にvarchar使っといたらええかな とか投げやりな理解をしてしまいがちです。
二つの違いは固定長であるか可変長であるか。
char : 固定長
varchar : 可変長
といってもとっつきにくい日本語ですよね
テーブル作成時にフィールドでそれぞれ長さを指定しますがcharで5の長さとvarcharで5の長さを指定した時の違いを例にとって考えます。
前者char型で “abc” というデータを放り込むと ”abc__” というデータが格納されます。(_はスペース)
これは5の長さをめいいっぱい使うっていう固定長の特徴です。
abcは三文字なので残りの2文字分をスペースで埋めます。
それに対しvarcharの方では “abc” というデータを放り込むと “abc” というそのままのデータが入ります。
可変長とは5文字以内という定義なのです。
PHPエンジニアはchar型を使うとデータをMySQLからとってきたあとに文字列操作とか必要になるので特にきまりがないかぎりvarcharを使う機会がほとんどでしょう。
③include()とrequire()の違い
両方ともファイルの読み込みに使う関数です。
基本的には同じですが両者の違いはエラーを出したときに明確になります。
includeの方はファイルが見つからないときに「Warning」を返します。
requireの方はファイルが見つからないときに「fatal error」を返します。
つまりincludeのほうはもしファイルがみつからなくても後続の処理が動きますがrequireの方はファイルがないとエラーで止まります。
include関数
<?php
include("aiueo.php");
echo "include関数";
?>
require関数
<?php
require("aiueo.php");
echo "require関数";
?>
前者のincludeは後続の処理(echo “include関数”;)が出力されてるのに対し、require側ではエラーのみで出力がありませんね。
読み込むファイルが存在することが不明確な場合はincludeを使うといった感じに使い分けましょう
ちなみに _once をつけると(include_once , require_once)そのファイルがすでに読み込まれてるかどうかを評価してくれます。
ファイルが見つからないときの評価はinclude関数とrequire関数のときの違いと同じです。
本日、就職先(現状:内定)の同期からWEBのことでたたき起こされた。
内容はMySQLからPHPに値引っ張ってきたときに文字化けが生じるとのこと。
過去に数100回ほど頭を悩まされていて解決策をしっていたので紹介
SQLのSELECT文で値を引っ張る前にデータベース側のエンコードをいじる。
SET NAMES utf8
これで解決
と思ったら
「Unknown system variable ‘NAMES’」って言われたらしい
んなばかなとおもってMySQLのバージョンを聞いてみると「mysql-4.0.20c-win」を利用しているとのこと。
調べてみるとMySQL4.0以前と4.1以降ではエンコードの仕様に断絶があるらしく4.0以前はサーバー全体での文字コード定義しかできないらしい。
というわけでSET NAMESは当然使えない。
ならばPHP側でmb_convert_encoding()を使ってSQLをEUC-JPに、返された値を同様に今度はUTF8に変換すればいい。
つまり
$sql = "SELECT `field1` from `Table`"; $sql = mb_convert_encoding($sql, 'EUC-JP'); $res = mysql_query($sql);
こんな感じでSQLを発行し、
while($data = mysql_fetch_array($res,MYSQL_ASSOC)){
$field1 = mb_convert_encoding($data['field1'], 'UTF8');
//処理
}
という風にする。
しかし、ここまでもまた問題が。
「Fatal error: Call to undefined function: mb_convert_encoding()」
mb_convert_encoding()が未定義の関数とかほざいてくるんですね。
そんなバカなことがあるかーっておもってPHPのバージョンを聞くとPHP4.3だとか。
なんでこうも古いのばっか使ってるのかと思ったら古い参考書についてた古いCDを使って開発環境を整えてしまったのが原因らしい。
まぁよくありそうな現象やなぁと思いながらも私、堪忍袋の緒がきれてしまいました。
Apache,MySQL,PHPをアンスコしてXAMPPで開発環境整えさせました。
強引ですいません。
アンスコウィザードのあるApacheと違ってMySQLの削除が曲者なので紹介しておきます。
まずCドライブ直下にMySQLフォルダがあると過程します。
MySQLは事前に停止しておいてください。
停止方法(cmd)
# net stop mysql
削除方法(cmd)
# CD C:\mysql\bin # mysqld –remove MySQL
これでサクシードほにゃららってのが出たら一応アンスコに成功してます。
ただ、my.iniというmysqlの設定ファイルがサーバー内に残ってる可能性があるから
スタート→検索→[my.ini]でWINDOWSファイルやSYSTEMファイル以外の場所でmy.iniが見つかったら削除しといてください。
これでアンスコ完了です。
PHPに関しては別に設置ディレクトリさえ違えば競合するものではないので適当に削除してくれていいです。