PHPでの数値文字列の扱い 

PHPでの数値文字列の扱いはとっても微妙。便利だなと思うときもあれば、危険だなと思うときもある。

以下のようなスクリプトを使ってテストしてみると…

<?php

$test = $_POST["test"];

// データ型を文字列に指定
settype($test, "string");

// 数字として扱ってくれる？
if(is_numeric( $test )) $numeric = "数字でっせ！";
else $numeric = "数字じゃね〜よ！";

// 数字として扱ってくれる？
if(ctype_digit( $test )) $digit = "数字でっせ！";
else $digit = "数字じゃね〜よ！";

// 文字列に足してみる
$test_plus = $test + 3;

//テスト
echo <<<EOF
<html>
<head>
<title>テスト</title>
</head>
<body>
test = $test<br>
numeric = $numeric<br>
digit = $digit<br>
test_plus = $test_plus<br>

<form action="$_SERVER[PHP_SELF]" method="post">
<input type="text" name="test" size="20">
<input type="submit" value="送信">
</form>
</body>
</html>
EOF;

?>

//******** 結果 *********
入力：0　結果：test = 0, numeric = 数字でっせ！, digit = 数字でっせ！, test_plus = 3
入力：3　結果：test = 3, numeric = 数字でっせ！, digit = 数字でっせ！, test_plus = 6
入力：1.2　結果：test = 1.2, numeric = 数字でっせ！, digit = 数字じゃね〜よ！, test_plus = 4.2
入力：a　結果：test = a, numeric = 数字じゃね〜よ！, digit = 数字じゃね〜よ！, test_plus = 3

結果を見て分かるとおり、わざわざ「文字列」と指定しても数字の文字列なら「数字」と解釈されるし、計算もできてしまう。

携帯サイトでsession（セッション）を使う方法 

通常、session_start()するとクッキーにセッションIDが発行され、次回アクセスした時にクッキーの中にセッションIDがあれば、セッションを読み込んでデータを保持できる。しかしＰＣと違い、携帯ではcookie（クッキー）が使えない機種がある。通常の方法では携帯でセッションが使えないのだ。


これを解決する方法としてURLにセッションIDを埋め込むという方法がある。クッキーではなくGETやPOSTでセッションIDを持ちまわすのである。ただ、全てのリンクやフォームタグにセッションIDを埋め込むのは骨が折れるだろう。そういう時はphp.iniのsession.use_trans_sidをOnにすればいい。そうすると自動的に全ての相対リンクにセッションIDが埋め込まれる。


しかし、ＰＣと携帯と同じスクリプトで動かしている場合、ＰＣでもセッションIDが埋め込まれてしまうとセッションIDが丸見えになってしまう。（携帯でも見えてしまうけど、ＰＣほど問題にはならないと思う）そのような場合は以下のようなスクリプトで対応する。



続きを読む

オブジェクト指向 


プログラミングを行なう時、流れを追って作っていくと簡単に作れるが、後々修正する時に面倒になる。一日の動作に例えると、

起きる⇒飯を食う⇒働く⇒飯を食う⇒働く⇒飯を食う⇒寝る

ここで共通の「飯を食う」がバラバラに書いてあると、ご飯の食べ方を変える（修正する）場合に、３つあるから３つとも書き換えなきゃならない。でも、共通の作業を「関数」として作れば修正は１箇所で済むのだ。

起きる⇒飯を食う⇔働く⇒寝る

多くのプログラムはこういう関数の集合体でできている。



■オブジェクト指向


「飯を食う」時、レストランに行けばすぐに食べられる。ここで、自分で作る人もいるだろうが時間と手間がかかる。ましてや自分で食材を採りに行くなんてことは非効率的だ。レストランで飯を食うにしても、料理人がどこで食材を手に入れ、どうやって調理しているかを知らなくても、お金を出せば料理が出てきて食べられる。どんな人が来ても、お金さえ払えば飯は食えるのだ。社会は個人や団体が役割を分担し成り立っている。たった１人で１から10までやるサバイバル的な生活をしている人は少ないはずだ。
プログラミングも同じように、１から10まで順番に書いたプログラムは非効率的である。関数やクラスに役割を分担させ、どんなプログラムでも引数を出せば結果が出てくるようにし、それが集合していれば大きなことができる。関数やクラスに汎用性を持たせれば、新しくプログラムを作る時に、その関数やクラスについて考える必要がない。主プログラムは「あ〜して、こ〜して」と細かいことを書かなくて済むから、飯を食うときは「飯を食う」と書くだけ。非常にスッキリした分かりやすいプログラムになる。
このように１つの役割を１つの「もの・こと（オブジェクト）」としてとらえ、プログラミングしていく考え方をオブジェクト指向という。



■クラスとインスタンス


１つのラーメンを数人で食べると、人によって食べ方は違うので「勝手にニンニク入れるなよ！」とかケンカになるかもしれないが、１人につき１つのラーメンを出せばケンカにならない（当たり前だけど）。そのラーメンはどんな食べ方をしても個人の自由だ。だけど、作るたびに味が違ってはいけないのでレシピを作る。
プログラムも同じように、１つの関数をいろんなところから呼び出すと「勝手に$aに１足すなよ！」とケンカになるかもしれないが、同じ関数をその動作に応じて作成すればケンカにならない。それがクラスとインスタンスなのである。上の例で言えばレシピがクラス、できたラーメンがインスタンスとなる。
インスタンスはクラスのコピーだが、メモリ上でコピーするだけで、いちいち同じクラスを複数書くわけじゃない。レシピは１つあれば十分で、ラーメンは食べ終われば必要なくなるのだ。



■クラスの継承


料理人はやがてのれん分けされ、自分の店を持つ。自分の店では本店の味を継承しつつ、自分のアレンジを加えて別の味が作れる。クラスも同じようにもとのクラスを継承して別のクラスを作ることができるというメリットがある。

デザインも考慮したプログラミングを！ 

僕が初めてプログラムに携わったのは高校時代、もう15年以上前になる。（年をとるのは早いなぁ…）その時はBASICとアセンブラを使ってゲームを作って遊んでいた。プログラムの流れはとっても原始的で、今見直してみたら多分たくさん無駄があると思う。
それからしばらくしてインターネットが流行りだしたころ、自分でホームページが作りたくなって、そこらに転がっているできあいのPerlスクリプトを改造し始めた。そのまま使っても良かったのだが、機能は十分でもデザインが気にくわなかったり、自分のサイトに合わなかったりするのだ。その「デザインを改造する」というのが厄介で、プログラム中にHTMLがポツリポツリとあるものだから、全体を想像しながらHTML箇所を見つけては修正するといった面倒くさいことをしていた。
ある時、プログラムはプログラム、デザインはスキンを読み込んで書き換えるというスクリプトを発見し、衝撃を受けた覚えがある。「そうだよ。こうすればデザインも自由にできる！」その辺の個人が作ったできあいのスクリプトはほとんどそうなっていなかったから、自分で１からプログラムを作れるようになりたいと思うようになった。
その後は勉強してPerl、PHPを扱えるようになり、１からもスクリプトが作れるようになった。１から作る時は必ずデザインを自由に修正できるようなスクリプト作りを心がけている。スクリプトの機能ももちろんだが、販促にはデザインも必要不可欠だからね。

サイズが大きすぎるため、このページは表示できません。（T3040401） 

以前、無効なデータを受信しました。という記事を書いた時に、ヘッダーの Location を絶対パスにし、exit 文を削除するとエラーがなくなるという話をしたが、このままだと Vodafone（ボーダフォン）で「サイズが大きすぎるため、このページは表示できません。（T3040401）」というエラーが出てしまうことがわかった。
ページサイズは1kBでもエラーが出たので、ヘッダーかなと思ったが、ヘッダーも必要最小限しか吐き出していない。Location の先のURLを直接入力した場合に正常に表示されたので原因が分かった。exit 文を外したからだ。

ゆえに、ドコモでもボーダフォンでもエラーが出ないようにするには以下のようにする。

header( "Location: http://www.domain/hoge/" );
// ドコモ以外はexit
if( !ereg( 'DoCoMo', $_SERVER["HTTP_USER_AGENT"] ) ) exit;