for で変換 vs ダンプした文字列を変換して eval
ふと、for で回してパラメーターの個数分変換するのと、Data::Dumper でダンプして1回だけ変換して eval するのとどっちが速いのか気になってベンチマーク取ってみました。
コードと結果は以下。
Archive
Archive for the ‘info’ Category
ClearSilver の関数とフィルター (ドキュメント邦訳)
ClearSilver に関しては、tasukuchan さんが ClearSilverについて調べる にマニュアルの邦訳をされており、大変参考になります。
Template Toolkit から ClearSilver に乗り換え、TT のような URI エスケープや、HTML エンティティ 変換をしてくれるフィルター機能が欲しいと思っていましたが、ClearSilver には pod が用意されておらず、h2xs のデフォルトテンプレートと思われる記述しかないので、オフィシャルのドキュメントを調べてみたらありました。
発見ついでに、ググっても他に邦訳されている方がいらっしゃらないようですので、簡単に意訳しておきます。英語は得意ではないので、変な訳があったらコメントで突っ込んでください。
送信ドメイン認証（Sender ID/SPF）について
DoCoMo の SPF 対応も明後日からですね。それに伴い、ウチでも DNS を設定しなおしました。
関連資料をまとめておきました。
WILLCOMのCSS対応
WILLCOM の CSS 対応ですが、スモールスクリーンモードとフルスクリーンモードで対応しています。
<?xml version="1.0" encoding="Shift_JIS"?>
など、XML 宣言がなくても CSS は適用されますが、
<!DOCTYPE html PUBLIC “-//WAPFORUM//DTD XHTML Mobile 1.0//EN” “http://www.wapforum.org/DTD/xhtml-mobile10.dtd”>
と、XHTML Mobile Profile の DOCTYPE が無いと適用されません。i-mode と ezweb の DOCTYPE でも試しましたが、こちらでは適用されませんでした。（WX310K で確認）
WILLCOMの絵文字
WILLCOM も DoCoMo と同じように10進表記での絵文字入力に対応していますが、ページを Content-Type: application/xhtml+xml で送信すると絵文字が表示されません。（WX310K で確認）
ちょっとハマりました。
WILLCOM の絵文字仕様については、コンテンツ作成マニュアル -リファレンス編- の26ページで。
Alexa のグラフのパラメーター
Alexa のグラフをカスタマイズしたかったのでパラメーター内容を調べてみました。
グラフ取得用の基本 URL
http://traffic.alexa.com/graph?
u: グラフ作成したいドメイン
h: グラフ画像の高さ
w: グラフ画像の幅
y: グラフの種類（r: Reach, p: Pageviews, その他: Traffic ）
r: X軸の期間（数字 * 単位 d/m/y）2ヶ月や16日など指定可能
o: グラフの制御（b: 外枠なし, g: 補助線なし, l: ドメイン名表示なし, x: X軸の
表示なし, y: Y軸表示なし, ）同時に複数指定可能
f: メモリやテキストの文字色（#抜き16進指定）
z: スムージング指定（0～∞？）
c: 数値の見せ方の切り替え（0: Per Million, 1以上: Percent）
Google Sitemaps 日本語ドキュメント
いつのまにか google.co.jp にも Google Sitemaps の日本語ドキュメントが公開されていますね。
http://www.google.co.jp/webmasters/sitemaps/docs/ja/overview.html
以前は「絵文禄ことのは」さんにお世話になりました。
http://kotonoha.main.jp/2005/06/04google-sitemaps.html
変数の評価
これは気づかないとかなりハマるし、アプリにバグを埋め込むことになります。
フォームから来た変数で 0 を値に持つ変数を空文字列かどうか評価したら空として認識してる気がしたのでテストコードを書いてみました。
以下のコードを実行
$i = 0;
print_r(’$i: ‘ . $i . “\n”);
print_r(’$i == null: ‘ . ($i == null) . “\n”);
print_r(’$i == false: ‘ . ($i == false) . “\n”);
print_r(’$i == “”: ‘ . ($i == “”) . “\n”);
以下が結果
$i: 0
$i == null: 1
$i == false: 1
$i == “”: 1
null の評価については今更何も言うまい。
確かに空文字列か評価したら true を返しています。0 という値が入ってるのに。最初に $i を integer として定義してるので型変換が起きてるのだろうと思って、型キャストして評価してみました。
コード
print_r(’(string) $i == “”: ‘ . ((string) $i == “”) . “\n”);
結果
(string) $i == “”:
一応期待した動作になりましたが Perl に慣れていると気持ち悪いです。
慣れるべきなのかも知れませんが、明らかに文字列として評価を試みてるのだから、そこでも型の自動変換をして欲しいものです。
今回は、フォームから来た時点では string でしたが、-= で減算処理をしていたため、その時点で integer に自動変換され、文字列的には空でないのに、”" オペランドを integer として評価したために、0 == “” が true になったもののと思われます。
自動型変換の演算子とオペランドの関係については、下記参照。
http://jp.php.net/manual/ja/language.types.type-juggling.php
常に厳密比較を使った方が楽かも知れません。
http://jp.php.net/manual/ja/types.comparisons.php
post_max_size
POST されたデータが post_max_size を超えた場合に、フォームから送信されたパラメーターが上手く取れない現象にあいました。
それは至って当然な反応ですが、プロセス自体は死なないので、パラメーターに応じてヴァリデーションをかけてる場合はそれをすり抜けてしまいます。
その場合の $_REQUEST 変数の挙動を調べていないので、バッファオーバーフローのような攻撃を受けた場合に、中途半端に $_REQUEST に格納されてたりするとセキュリティホールになりえます。
最近のコメント