Liner Note » プログラミング技術絡み

RDBが扱いづらい問題はO/Rマッパーで解決できる？

hash — Sat, 01 Nov 2008 19:03:17 +0000

この記事は書いている内に、問題解決の糸口が見えてきたけど、問題だと思っているところをはっきりさせるために、そのまま書いた記事です。

以下に、その思考ログを書いておきます。

RDBが使いづらい理由

最近、MySQLやSQLiteなどのリレーショナル・データベースを使い始めたのですが、XMLをどうにも使いづらいという感は抜けません。そんなこともあって先日は擬似XMLデータベースなんてへんてこなものを作ったりしたのですが、気がついてみればその理由をあんまり書いてなかったので、使いづらさに慣れちゃう前に理由を整理してみました。

スキーマを事前に定義しておかないといけない

開発中にはデータベースのデータ構造が変化すると言うことは良くあります。そのたびに、スキーマ定義をカリカリ書き換えているのは面倒ですから、データベースには速度だけでなく、柔軟性・拡張性が求められることになります（これはリレーショナルデータベースとXMLデータベースとの対比で良く言われます）

データ型として配列が使えない

簡単に言えば、一つのレコードに複数の値を設定できないということです。ブログのタイトルのようにキーと値が1:1で対応している場合は問題ないのですが、例えばこの記事のカテゴリのように、あるキーに複数の値が対応する（1:n）ということはよくあることです。しかし、どうもマニュアルを見る限りは、MySQLに複数の値を格納できる型、つまりは配列型はないようなのです。

この場合、一般的にはシリアル化（serialize関数）して文字列として処理→DBから取り出した後に復元（unserialize関数）（PC用語で言うと圧縮、解凍みたいなものですね、サイズは変わりませんが）という方法が採られているようですが、一手間かけさせられているというか、言語側の仕様に依存しているようでどうにも納得いきません。

この項、シリアライズが一般的と書きましたが、いくつかご指摘をいただきまして、標準的には第一正規化（つまり別テーブル化）するのが一般的だそうです。まぁ、どちらにしても一手間かけなければいけないことに代わりはないようなのですが、勉強になりました。

ちなみに、この手順をコードにしてみるとこんな感じ（例：商品の名前・価格・カテゴリについて書いてあるデータベース）

PHPソースコード


/** データを挿入するとき **/
$category = array(
  "音楽再生機器" => "MP3プレイヤー",
  "iPod" => "本体",
  "スマートフォン" => array("Apple","ソフトバンクモバイル")
);
$vars = array(":id"=> 10, ":name"=> "iPhone", ":price"=> 200000, ":category"=> serialize($category));
$sql = "INSERT INTO 'mytable' (id, name, price) VALUES (:id, :name, :price)";
$request = $db->prepare($sql);
$request->execute($vars);
 
// （中略） 
 
/** データを取り出すとき **/
 
// SELECT文の発行とかはすっとばします
$names = array("id", "name", "price", "category");
while ($row = $request->fetch(PDO::FETCH_ASSOC)){
  foreach ($names as $name){
    $v = $row[$name];
    // gettype関数先生は全部stringと仰るので
    // 泥臭く文字列としてシリアライズされているか判定
    $results[$i][$name] = (preg_match("/^a:[0-9]+:{/", $v)) ? unserialize($v) : $v;
  }
  $i++;
}
 
/*
  $results = array(
    [0] => array(
      "id"=>10,
      "name"=>"iPhone",
      "price"=> 200000,
      "category"=>array(
        "音楽再生機器" => "MP3プレイヤー",
        "iPod" => "本体",
        "スマートフォン" => array("Apple","ソフトバンクモバイル")
      )
    ),
    [1] => array(
    ...
    )
  );
*/
?>

ちなみに、SET型はユーザ定義型（あらかじめ入る内容を定義しておかないと行けない）なので、配列的に使うには無理がありますし、join関数を用いた単純結合は多次元配列を処理できません。

プログラミング言語との連携が弱い

データベースはプログラムとセットにして使うものなのに、その連携が弱いんじゃないかなと思うのです。

例えば、先の例で商品データベースを使いましたよね。再掲すると…

PHPソースコード


$category = array(**省略**);
$vars = array(":id"=> 10, ":name"=> "iPhone", ":price"=> 200000, ":category"=> serialize($category));
$sql = "INSERT INTO 'mytable' (id, name, price) VALUES (:id, :name, :price)";
$request = $db->prepare($sql);
$request->execute($vars);
?>

これ、個人的にはこう書きたいんですね（連想配列を投げる）

PHPソースコード


$vars = array("id"=> 10, "name" => "iPod nano", "price" => 200000, "category"=>$category);
$request = $db->insert("mytable", $vars);
?>

今回は後者を前者に置換するラッパ関数を書けば良い話ですが、さきほどの配列型の問題と絡めて、こういうのがデフォルトになってくれるといいなと。

まぁ、あと細かいことを挙げれば

データの挿入（INSERT）と更新（UPDATE）でクエリの書式が違う
SQLインジェクションが構造的に発生する
データがバイナリファイルである（これはちょっとイチャモンぽいですが）

とありますが、冗長になるので深くはつっこまないことにします。

O/Rマッパーがいいらしい?

検索していると、連携問題はどうやらオブジェクト関係マッパー（O/Rマッパー）と呼ばれるもので解決できそうな感じです。

このO/Rマッパーというのは、要するに人間がデータベースを触りやすくなるように、プログラミング言語のお作法で違和感なくデータベースがいじれるようにするような仕組みのようです。PHPのフレームワークの一つであるCakePHPでは、ActiveRecordという考え方（デザイン・パターンとか言うらしい）を基にしたO/Rマッパーが実装されている模様。

配列型問題はどうだろう…定義からして解決できるぽい感じはするのですが、具体的な記述が見つけられません。あと、最初にデータベース定義が必要なところはどうも解決してないっぽいですね。むー

O/Rマッパーは問題を解決する?

じゃあ、O/Rマッパーを使えばいいのかというとそれもちょっと疑問なんですよね。僕が抱えてる問題はちょっとは解決するんですが、別に思うこともありまして…。で、これには2つの理由があります。

初心者は結局、SQLを学ばないといけない
O/Rマッパは対処療法である

まず、「じゃあ初心者ってO/Rマッパ使うのか」という疑問です。PHPの入門書でも、だいたいPEAR::MDB2の使い方を解説するか、PDOの使い方を解説するくらいが現状なわけで、結局はSQLの書き方やお作法を学ぶことになるでしょう。

Wikipediaの「O/Rマッパー」の項にはオブジェクト関係マッピングは、オブジェクト指向と関係モデルのインピーダンス・ミスマッチ問題の対症療法にすぎないとも言われていると書かれていますが、これはその通りで、上記の問題が起こるのもこの問題があるからでしょう。

つまり、O/Rマッパーはプログラム言語とSQL言語の翻訳者でしかないわけで（断言してますけど、自信はないです）、SQL自身が関係モデルを取り、SQL言語を話している限りは、その問題の根本が解決したとは言えないのです。とはいえ、オブジェクトデータベースやXMLデータベースは、PerlやPHPなどプログラム初心者が手を出しやすい軽量言語では実質使えない状況です。

初心者にとって、プログラム言語とSQL言語のバイリンガルにならざるを得ない状況があって、それがプログラミングの壁を厚くしているような感じがします。まぁ、現状はO/Rマッパー（を搭載したフレームワーク）が最適解ぽいので、この問題は、「現状は初心者こそCakePHPを使うべき」が落としどころになりそうです。しかし、入門書にフレームワークの記述は難しいだろうなぁ。

言及されたURL

以下で言及されました（ありがとうございます）。
ORマッパーとか | 眠る開発屋blog

SQLのコストについて。確かにSQL学習上のコストはそれほど高く付くわけではないのですしこの先数年も流通している知識だとは思うのですが、それが本来必要なコストなのかどうかということをSQL初学者として書いておきたかったのでした（できるならデータベースのお作法を気にせずに＝透過的に、扱えるようになるべきでしょうし）。

9784839924317

PHPでのセキュリティ施策についてのメモ

hash — Sun, 26 Oct 2008 10:17:02 +0000

PHPでのセキュリティ施策については前々からいささかながら気を払っていました。ただ、本を読んで体系だって勉強したわけではないので、調べてまとめたことを晒しておいて、みなさんのご指摘をいただこうかと思います。

以下の内容が正しいとは限らないこと、かつ、対策を実行しても未知の事象で脆弱性が生じうる可能性があることをご了承の上、お読みください。より詳細な内容を得たい場合は参考リンク先の文書を辿ってみてください。

脆弱性と対策方法

まず、具体的に気をつけているのは以下の5つの脆弱性についてです。むろん、まだまだあるかと思いますが最善より次善の策ということで代表的そうな例を考えておきます。

これらは、いずれもユーザ入力に対して適切に対処できていなかった場合に起こる脆弱性です。が、だからといってユーザ入力値部分だけ対策しておこうという方法では対策漏れが生じる（User-Agent文字列をそのまま出力してしまうなど）可能性があるため、全ての変数出力箇所に対して検証を行うべきでしょう。

以下で一つずつ説明していきます。あ、その前にPHP自体の脆弱性を防ぐためにPHPは利用できる最新版を利用するということで。

SQLインジェクション

どんな脆弱性?

管理者側が実行する予定だったSQL文を終了させ、攻撃者側が用意したSQL文を挿入することで、例えばデータベースを破壊したりすることが出来る脆弱性

どう対策する?

SQL文を発行する際は準備済みのクエリ文 (prepared statement)を用いる¹ か、DBのAPI関数を用いて、全ての変数をエスケープする（例えばPHP::PDOならPDO::quoteを用いる。しかし、なぜ準備済みの文を使わないとエスケープが行われないんでしょうか?）
エスケープで防ぎきれないインジェクションについては全ての変数を文字列として処理するという方法もありますが、これだと数値が数値として評価されなくなるので、is_numeric関数などを用いて型を検証するか、許可した文字だけ通るようにするとよいでしょう。
壊れた文字エンコーディングによっても攻撃が可能なので、エスケープをするだけでは不十分。入力文字列の文字エンコーディングが正しいものかチェックを忘れないこと。なお、これは他の脆弱性でも同じ。

IPAによる解説

クロスサイトスクリプティング（略称：XSS）

どんな脆弱性?

入力された文字列がHTML中に出力され、かつ文字参照に変換されない場合はHTMLとして解釈されるので、結果として任意のタグが出力可能（=任意の javascript が実行可能）になる脆弱性

どう対策する?

全ての変数をエスケープする（htmlspecialchars関数）
HTMLタグ中の属性値を"（ダブルクオート）で適切に囲む（セキュリティ以前の問題ですが）
文字エンコーディングが正しいものかチェックする。またheader("Content-type:text/html; charset=utf-8");などとしてサーバ側で文字エンコーディングを確定させておく

IPAによる解説

クロスサイトリクエストフォージェリ（略称：CSRF）

どんな脆弱性?

あらかじめ特定のフォームにアクセスするように設定されたページをインラインフレームなどで読み込ませることで、掲示板に意図せず書き込ませることが出来るなど利用者の意図しないところでフォームが実行されてしまう脆弱性

どう対策する?

第三者が知り得ない文字列（安全な乱数、詳細はこちらのご返信を書いたページを参照のこと）をフォームに埋め込んでおき、サーバ側で照合することで、リクエストが利用者の意図した動作かどうかをチェックする
リファラをチェックし、空だったり、想定されうるページと違う場合エラーを返す（ただし、リファラは容易に偽装されうること、ファイアーウォールソフトなどでリファラが空になっている場合があることを考慮すること）

IPAによる解説

ディレクトリトラバーサル

どんな脆弱性?

ファイルの要求にユーザ入力値が混じっている場合、例えば ../などの入力値を混ぜることで、サーバ上の任意のファイル（パスワードファイルなど）を閲覧できてしまう脆弱性。なお、ユーザ入力値を元にファイルを読み込んでいる場合、外部の攻撃用コードを読み込まれるリモートファイル・インクルード脆弱性も起こりうる

どう対策する?

避けられる場合は、ファイルの読み込みにCGI入力値を含めることを避ける
そうでない場合は、まずパスを相対パスから絶対パスに変換 (realpath関数) し、そのパスが外部に公開してもよいフォルダかどうかを判定した上で、出力する（詳しくはウノウラボ Unoh Labs: いまさら、ディレクトリトラバーサルについて語ってみるを参照ください）

IPAによる解説

サーバリソースを浪費させてしまう脆弱性

どんな脆弱性?

異常な数値や異常に大きな外部データを読み込ませる（ループ回数を半無限に設定したり）ことで、処理を半無限に実行させることでサーバに大きな負荷をかける脆弱性（おさかなラボ – サニタイズ言うなキャンペーン参照のこと）

どう対策する?

入力値が一定の範囲内に収まっているか検証する
外部のデータ（URL）を読み込む場合、上限のファイルサイズを常識的な値に設定する

IPAによる解説

IPA – 知っていますか?脆弱性：サービス運用妨害 (DoS)

いつ対策するか

大きく、処理の最初期に値を処理する方法と問題が起こりうるとき（出力時やSQL文発行時）に値を処理する方法があると思います。

処理の最初期に処理する

出力時に値を処理するという方法では、検証忘れによって抜け漏れが生じる可能性があり、脆弱性が生じる可能性を否定しきれません。ですので、入力値を処理の最初期で全てエスケープ（文字参照に変換）し、HTMLとして出力する場合のみ文字参照を展開するという方法があり、具体的な方法はXSSの脆弱性を限りなくなくす方法：to-Rで紹介されています。

一方でこの方法に問題がないわけではありません。例えば、サニタイズ言うなキャンペーン：おさかなラボではHTML出力やSQL文発行など脆弱性が発生しうる環境には様々なものがあることが挙げられており、SQL文の扱いなど単に入力値をエスケープしただけでは脆弱性を防げない事例も存在します。この方法は、入力時に処理を行ったことにより、出力時はあまり手をかけなくてよいと思いこんでしまう危険があり、結果として別の対策漏れを生んでしまう可能性があります。よって、この方法を用いるときは、単に文字エスケープしたことで安全と思いこむのではなく、本当に用いる環境で安全になっているかどうか確認する必要があります² 。

また、リンク先でも言及されていますがscript要素やstyle要素内などのCDATA区間内に出力した場合は脆弱性につながりますし、$_REQUESTグローバル変数は変換されていないのでこちらも注意が必要です。

その他、「入力時に文字参照に変換するのがよろしくない理由」：水無月ばけらのえび日記では、エスケープされた文字は処理に手間取ることも指摘されており、結果として二重手間となるのであれば、問題が起こる場所で適宜処理する方法が良いのではないかと思います。

問題が起こりうる場所（出力時やクエリ発行時など）に処理する

ということで、次善の策としては、入力時にエスケープ処理を行うよりは、入力時に値の検証（ホワイトリスト方式を利用して必要な文字だけ許可するといったような）を行った上で、HTML出力時やSQLクエリ発行時など全ての問題が起こりうる箇所で対処するというのが次善の策となりそうです。もちろん、対処とはエスケープだけではなく（それでは防げない場合もあるので）環境に合わせた対策も併せて行っていく必要があります。

以下では、その方法について簡単なものではありますが具体的なコードを示しておこうと思います。

許可した文字のみを通過させる

以下は代表的な正規表現の例を示したものです。数字に関してはis_numeric関数を用いても良いと思います。

数字だけ許可する式

PHPソースコード

 if (preg_match("/^([0-9]+)$/", $user_input, $match)){
  $my_var = $match[1];
} else{
  die("入力値は数字だけで構成してくださるようお願いいたします");
} ?>

英数字だけ許可する式

PHPソースコード

 if (preg_match("/^([a-zA-Z0-9]+)$/", $user_input, $match)){
  $my_var = $match[1];
} else{
  die("入力値は英数字だけで構成してくださるようお願いいたします");
} ?>

英字だけ許可する式

PHPソースコード

 if (preg_match("/^([a-zA-Z]+)$/", $user_input, $match)){
  $my_var = $match[1];
} else{
  die("入力値は英字だけで構成してくださるようお願いいたします");
} ?>

緯度・経度だけ許可する式

PHPソースコード

 
// 百分率形式。できれば度分秒形式との変換も行っておくこと
if (preg_match("/^([0-9\.]+)$/", $user_input, $match)){
  $my_var = $match[1];
} else{
  die("緯度・経度の値がおかしいです");
} ?>

【実践例】 URLで指定された範囲の価格に収まる商品データを取り出す例

PHPソースコード


// PDOによるデータベース（price,dataの2カラム構成）の接続と
// インスタンスの生成ができていると仮定
 
// 価格の範囲を設定
foreach (array("low", "high") as $range){
  if (preg_match("/^([0-9+])$/", $_GET[$range], $match)){
    $prices[$range] = $match[1];
  }
}
 
// 数値かどうか検証
foreach ($prices as $price){
  if (is_numeric($price) === false){
     die("価格の設定がおかしいです");
  }
}
 
// クエリを設定
$sql = "SELECT * FROM '{$dbName}' WHERE ".
       "price > ".$db->quote($prices["low"])." AND ".
       "price < ".$db->quote($prices["high"]);
 
// クエリを実行
try{
  $request = $db->query($sql);
} catch(PDOException $exception){
  die("エラー（クエリ発行時）：".$exception->getMessage());
}
 
$i = 0;
 
// データを取得して配列に格納
while ($row = $request->fetch(PDO::FETCH_ASSOC)){
  $results[$i]["data"]  = $row["data"];
  $results[$i]["price"] = $row["price"];
  $i++;
}
 
return $results;
?>

エスケープ出力をデフォルトにする

特別な場所だけhtmlspecialchars関数を使い、そうでない場所にはecho や print_rなどの関数を使うという方法では抜け漏れが生じてしまうので、デフォルトでエスケープしたラッパー関数を使うとよいでしょう（エスケープする場合はshow関数、HTMLタグを出力したい場合はshow_tag関数を用いる）

つきつめるならば（どうしても使い慣れたechoを使ってしまうので）echoやprint_r関数を禁止できればいいのですが、どうもその方法が見つかりません。レンタルサーバでは難しいかもしれませんが、PHP組み込み関数を上書きする方法もありますので、こちらを用いてもよいかもしれません³ 。

いずれにしろ、うっかり抜け漏れることをどう減らすかが焦点になりそうです。

PHPソースコード


 
function encode($str=""){
  
  if (is_array($str)){
    return array_map("encode", $str);
  } elseif ($str){
    return htmlspecialchars($str, ENT_QUOTES, "UTF-8");
  } else{
    return false;
  }
  
}
 
function decode($str=""){
  
  if (is_array($str)){
    return array_map("decode", $str);
  } elseif ($str){
    return htmlspecialchars_decode($str, ENT_QUOTES, "UTF-8");
  } else{
    return false;
  }
  
}
 
function show_dump($str=""){
  
  if ($str){
    var_dump(encode($str));
  } else{
    return false;
  }
  
}
 
function show_tag($str=""){
  
  if ($str){
    print_r($str);
  } else{
    return false;
  }
  
}
 
function show($str=""){
  
  if ($str){
    print_r(encode($str));
  } else{
    return false;
  }
  
}
?>

設定の確認と入力時検証を行う

resiger_globalsの設定は有効になっている時に脆弱性になり得ますので、その場合はスクリプトを停止するように設定しておきます。また、magic_quotes_gpcはエスケープが不完全なので、これも同様に処置することにします。

加えて、壊れたShift_JISの文字によって起こる問題を防ぐため、文字エンコーディングが壊れたものになっていないかチェックします（出典：gihyo.jp：なぜPHPアプリにセキュリティホールが多いのか?：【スクリプトインジェクション対策06】入力文字列の文字エンコーディングを検証する）

PHPソースコード


/*** コンストラクタ ***/
function __construct(){
  
  $inis = array(
    "register_globals",
    "magic_quotes_gpc",
  );
  
  $user_inputs = array($_GET, $_POST, $_COOKIE, $_FILES, $_SERVER, $_SESSION, $_ENV);
  
  foreach ($inis as $ini){
    if (ini_get($ini)){
      trigger_error("このアプリケーションは".$ini."=onの環境では動作しません", E_USER_ERROR);
      exit;
    }
  }
  
  foreach ($user_inputs as $inputs){
    if ($inputs){
      parent::input_encoding_check($inputs);
    }
  }
  
}
 
/*** input_encoding_checkのコールバック関数 ***/
function input_encoding_check_cb($k, $v){
  
  if (!mb_check_encoding($k, "utf-8") || !mb_check_encoding($v, "utf-8")){
    trigger_error("不正な文字エンコーディングを検出しました");
    die("System detected some errors");
  }
  
}
 
/*** ユーザ入力値のチェック ***/
function input_encoding_check($v){
  
  array_walk_recursive($v, array($this, "input_encoding_check_cb"));
  
}
?>

allow_url_include,allow_url_fopenも脆弱性（リモートファイル・インクルード脆弱性）になりえますので無効にした方がよいのですが、こちらはユーザレベル（.htaccess）で無効に出来ないことも多いので、こちらは外しておきました。

なお、最初に挙げた2つの設定を無効にするには以下のような記述を.htaccessファイルに書いてください。

ソースコード

php_flag magic_quotes_gpc Off
php_flag register_globals Off

参考にしたURL

IPAのページ

コーディングやセキュリティ施策に対する認識を批判した一連の記事

なお、これについてはマイコミジャーナルの記事（の後半）や以下の記事を読む限り、高木さんは脆弱性対策以前に、安全に処理が進むために本来されるべき検証作業が、「サニタイズせよ」という言葉が大きくなることで認識されにくくなっていることを批判しているのだとおおまかに理解しています。

入力時エスケープ処理に対する方法と是非

その他セキュリティ施策関連の記事

読者のコメントとご返信

「というわけでHTML出力時やSQLクエリ発行時など全ての問題が起こりうる箇所で対処するというのが次善の策」< 逆。入力でも何かする策の方が「次善」。IPAの「安全なウェブサイトの作り方」を読んでないと思われる。

id:HiromitsuTakagiさんのブックマーク

はい、読んでないというか知らなかったので早速読ませていただきました。入力でも何かする策というのはこちらでは具体的に値が想定されうる物かチェックする（ホワイトリスト）くらいしか思い浮かばないのですが、ほかにやるべき検証方法がありましたら教えてください。

高木先生も仰っているが、XSS対策に関しては出力時に処理するのが最善の策。最初期にやるのが次善の策。手前味噌で恐縮ですが、こちらも参考にどうぞ → 「http://www.e-3lab.com/security_guideline/」

id:jukuin2000さんのブックマーク

ありがとうございます。IPAのもそうですが、私のより数段詳しくて信頼がおけますね。

「第三者が知り得ない文字列（ID・パスワードやワンタイムトークンなど）をフォームに埋め込んでおき」!? id/passをフォームに埋め込むってあんた!有害記事。

id:shinpei0213さんのブックマーク

うーん、確かになんでこんなこと書いちゃったのか。ありがとうございます、ハッシュ関数を用いて擬似乱数化するよう訂正しました。

文字エンコーディングの検証もいれておいたいいかもset names問題。

id:courantさんのブックマーク

PHPからSET NAMESを使わない方が良い理由と対策まとめ：twk @ ふらっとというページを見つけました。最初に行っている文字エンコーディングチェックで問題ないように思うのですが、不十分でしょうか。

入力時のエスケープはやめたほうがいいです。全てにおいて出力の直前にやるのが基本。

id:h_narazakiさんのブックマーク

それは皆さんご指摘いただくことなのですが、決まって理由は一緒に書かれていなかったりする（探した中では水無月ばけらさんのページくらいしかみつかりませんでした、結論だけ一人歩きしているような感じすらします）ので、理由が書かれたURLを示していただけると助かります。→だいたい、示した内容で理由として問題なさそうですね。

$_POST|GETだけじゃなくて、$_SESSION|COOKIEも組み合わせて話せばもっと良い鴨

id:at_yasuさんのブックマーク

ですね。追記しておきます。

第三者が知り得ない文字列（ユーザIDやワンタイムトークンなど）をハッシュ関数（md5関数やsha1関数）を複数回用いて擬似乱数化< 安全な乱数を理解していない。/ わからないことは「わからない」と書いた方が良い。

id:HiromitsuTakagiさんのブックマーク

お返事が長くなったので、はてなダイアリーに書きました。結論から言えばで、だいたい安全な乱数が生成できるのではないかと。

まだサニタイズ脳の呪縛から解かれていないもよう。たとえば http://note.openvista.jp/?s=%3Cs%3E で「この検索結果の続きを見る」のリンク先がおかしくなるのはなぜか。

id:HiromitsuTakagiさんのブックマーク

この記事を書いて勉強したので、これ以前に書いたコードのうちで正しくない箇所もありましょうが、それもまぁぼちぼち再点検していこうと思います。ありがとうございます。

更新履歴

この記事は、読者のフィードバックにより内容を大幅に加筆修正する可能性があるため、更新履歴を附記しておきます。

2008-10-28: CSRF対策としての乱数生成過程を修正; タイトルを修正
2008-10-27: CSRFに関するトークン埋め込み対策に追記; 問題が起こりうる場所での対策方法を修正; 文字エンコーディングのチェック方法を示したコードを修正; それぞれの脆弱性にIPAの解説ページを附記; 読者の反応とそれに対する返信を追記
2008-10-26: 初版公開

一般には「準備された文」と言われるみたいです。これを使う際は、DBのバインド機構を使うことになります（バインド機構はこちらで解説されてます。ただし、準備済みのクエリ文を用いてもクエリが安全でない環境があるので注意
念のため。リンク先ではXSSを限りなく無くすことに言及しているのであって、他の脆弱性については何も言ってないわけですから、XSS対策においてリンク先に誤りがあるわけではないことを強調しておきます
echoは関数ではなく言語構造なので、変更できないようですが

PDFをウェブページとしてチェックできるようにして離脱を減らそう

hash — Fri, 10 Oct 2008 20:44:56 +0000

4903065065, caption

PDFファイルは昔からブラウザ上の表示には難がありました。動作が重く、ブラウザを固まらせたり、ブラウザ側のコントロールGUIを全く別のものにすげ替えてしまったり…。詳しいところはニールセン氏のコラムに譲りますが、そのせいでPDFファイルにリンクを張るのをためらうこともあります。読み手としても「詳細はPDFで」なんて言われたら面倒くさくなってタブを閉じる人もいるでしょう。

これに対する対策として、ニールセン氏は要約を記したゲートウェイ・ページを用意しておこうと仰っているのですが、これでは不十分でしょう。というのは、これはあくまで「ショック」を和らげるだけでしかなく、先のリンク先で挙げたユーザビリティ問題が棚上げされているからです¹

彼の言うようにPDFが印刷物に合わせたテキストである以上、問題の完全な解決は難しいかと思いますが、一方で解決できる問題も結構あるんじゃないか、ということで今回試しに作ってみたのがオンラインPDFリーダです。

えっと、じゃデモとして試しに適当なPDFを表示してみましょう…。最近読んだ図書館蔵書検索の論文PDFにしましょうか。

ウェブページを普通に表示するときほど可読性は良くないのですが、それでもいくつかの問題は解決できてるんじゃないでしょうか。

ブラウザが固まってしまう問題: 変換に時間がかかることはあっても、固まることはないでしょう(巨大なファイルを一気に変換しようとしない限り)
ブラウザ側のコントロールをすげ替えられてしまう問題: 言うに及ばず。
検索できない問題: 内容からテキストを抜き出して掲載しているので、ブラウザ標準の検索機能で検索できるようになっています。試しに先のPDFで「とりすぎず」で検索してみてください。
コンテンツの単位が大きすぎて、部分部分にリンクを張れない問題: ページ指定が出来るので、ページの一部分だけをウェブページとして抽出することが出来ます。例えば、3ページ目だけとか3ページ目から10ページ目までという表示方法ができます。

大きさも3段階で変えることができます。「小さい」はざっと全体を眺める場合、「普通」は通常のプレビューとして、「大きい」はPDFをブラウザ上で全部読みたい場合に向いています。

本当はサムネイルを動的に生成するプログラムを併用して、このサイトで使っているスライダーコントロールのように画像の大きさを動的に変えるのが、一番直感的で望ましいかと思います(大きな画像を出力しておいてそのサイズを切り替える)。が、実際に試してみたところ以下のように文字がぼやけてしまって、可読性がさらに悪くなるみたいで本末転倒になりそうなのでやめておきました。

なお、動作としてページ指定が無い場合は最初の5ページ(PDFが5ページ未満の場合、そのページ数だけ)だけ表示しています。これは全ページを変換してしまうと処理時間がかかりすぎてしまうためです。これについては、今後ページを少し読み込んでおいて、後から動的に追加していくことで、体感速度を早くしていこうと思っています。

汎用PDFゲートウェイとしてオンラインPDFリーダを使う

と、ここまで書いてからPdfMeNot.comというほとんど同じサービスがあることに気づきましたorz(ただ、こちらはFlashを使っていて検索ができないほか、拡張子にPDFが付いていない場合はPDFとして認識されないようです)

さて、こちらのサービスではブックマークレットやブロガー向けのPDFリンク書き換えスクリプトなどサービスを汎用PDFゲートウェイとして使えるようなツールを提供しているようなのですが、私もそれに倣ってみることにします(コードが短いので、ある程度参考にさせていただきました)

ウェブ利用者向け

GreaseMonkeyスクリプト

FirefoxブラウザでGreasemonkeyアドオンがインストールされている場合、以下のスクリプトをインストールすることで、リンク先末尾に「.pdf」が付くリンクを自動的にオンラインPDFリーダーへのそれに変換します。

GreaseMonkeyスクリプト

ブックマークレット

リンク先末尾に「.pdf」が付くリンクをオンラインPDFリーダーへのそれに変換します。ご使用の際は、まず以下のリンクをブックマークに入れてください。その後は、そのブックマークをクリックするとご使用いただけます。

ブックマークレット

ウェブ制作者向け

以下のタグをタグ内に書き込むことで、リンク先末尾に「.pdf」が付くリンクをオンラインPDFリーダーへのそれに自動的に変換します。

HTMLソースコード

<script src="http://pdf.openvista.jp/pdfconvert.js" type="text/javascript" charset="utf-8">script>

その他の情報

URLの構成

オンラインPDFリーダのURLは以下のようなルールで出来ています。

http://pdf.openvista.jp/[サイズ]/[ページ指定]/[PDFのURL]

サイズ: 省略可。small(小さい), medium(普通), large(大きい)のいずれか
ページ指定: 省略可(その場合は最初の5ページを表示)。p1のような感じでページを表示ページを指定できる。p1-5といったように複数ページを指定することも出来る。
PDFのURL: 必須。PDFのURLを指定してください。

更新履歴

2009-01-20: 最新のPDFファイルを取得し直す機能を追加; キャッシュしたPDFを検索エンジンが取得しないように設定
2008-10-20: フォントをより美しいものに差し替えました; 表示サイズをより大きくしました
2008-10-18: 一部のPDFにおいて文字が表示できない問題を解消しました
2008-10-12: 使用するPDF表示ライブラリを変更の副作用で、一部のPDFファイルが検索できるようになりました
2008-10-11: 初リリース

実装予定の機能

Googleブック検索ライクな埋め込みプレーヤーの提供
ページの動的追加

参考にしたリンク

今回のサービスは~~Xpdf~~PopplerというオープンソースのPDFリーダライブラリを利用させていただきました。素晴らしいライブラリを作られた作者さんに感謝。

いいかも。ただpopplerじゃなくてxpdfなのは何故なんだぜまあxpdfも「終わった」わけじゃないのかもしらんが

id:ttamoさんのブックマーク

それは単に知らなかっただけですよ。試しに変えてみたら、コピー不可のPDFファイルも表示できるようになったのでこちらにしておきます。

謝辞

以下のサイトからアイコンをお借りしました

「最善は善の敵」という現場のコストを考えた彼の主張の一貫性には納得していますが

新しいGoogle Book Search（ブック検索） APIを試してみる

hash — Thu, 25 Sep 2008 21:05:20 +0000

Google ブック検索に検索結果や書評をサイト上に組み込めるAPIが新たに追加されました。まず、このAPIなんですが、以下のように3つのAPIから構成されています。

ISBN、OCLC番号、LC番号等で特定した書籍のGoogle Book Search内データを、自分のウェブサイトに取り込んで（embed）表示できる”Embedded Viewer API”

Google Book Search内のデータの全文検索、書誌データやユーザが付与したレビュー・レイティング・タグ等のデータの収集、自分が付与したデータの編集ができる”Data API”

従来は”Book Viewability API”と呼ばれていた、Google Book Searchのデータにリンクを貼ることができる”Dynamic Links”（E764参照）

Google Book Searchに新API－ウェブサイト内での表示や全文検索、データ収集・更新も可能に | カレントアウェアネス・ポータル

以前から書籍の公開レベルが取得できるAPIを公開していたようなんですが、今回埋め込みビューワのAPIが公開されたことで、格段に利用しやすくなったと思います（いずれもAPIキーが必要ないので、とても手軽に利用できます）

API利用ドキュメントは平易かつ簡潔に書かれているので、あえて解説する必要はないと思うのですが、学習がてらにちょっと書いてみましょうか。

動的リンク（”Dynamic Links”）

Google Codeでの仕様解説ページ

書籍のプレビューは著作権や出版社との交渉によりできたり、できなかったりします。

単にハイパーリンクを用いて書籍の詳細ページに（詳細の有無にかかわらず）リンクする静的リンク（”Static Links”）では、いざプレビュー出来なかったときに閲覧者をがっかりさせてしまいますが、動的リンク（”Dynamic Links”）ではその公開レベルなどの情報が入手できるので、例えば「全文公開されている書籍のみGoogle Booksにリンクする」など柔軟にリンクを生成できます。

公開レベルは以下の3つが設定されています。なお、アメリカでは見られるのに日本では見られないといったように、アクセス元の位置により別々の公開レベルが設定されることもあるようです。

全文公開（full）: パブリック・ドメインの書籍など全文が公開されている書籍を指します
部分プレビュー(partial): スキャンがされた書籍で、その一部分をプレビューすることが出来ます
スニペットビューあるいはプレビューなし(noview): “snippets”とは切り取られた断片という意味で、これはスキャンがなされていないか著作元からの許可が得られないなどの関係で、これらの書籍には解説くらいしか載せられていません

方法としてはJavascriptを使って、書籍の情報を以下のようにJSONオブジェクトで受け取ります。その際、コールバック関数を呼ぶことも出来ます。

JAVASCRIPTソースコード

JsonSearchResult {
    // ※書籍の識別子。大抵はISBNが設定されているようです
    string bib_key;
    // ※Google Books上の詳細ページのURL
    string info_url;
    // ※書籍がプレビューできるページのURL。無いときもあるようです
    string preview_url;
    // ※書籍カバー画像のURL
    string thumbnail_url;
    // ※公開レベル、full / partial / noview の三段階
    string preview;
    // ※ 書籍が外部に埋め込み可能であれば true となる
    boolean embeddable;
};

Javascriptは以下のようなURLで呼び出します。こちらが指定する部分はbibkeysパラメータとcallbackパラメータ（コールバック関数）くらいですね。

動的リンクはもちろん、Javascriptで処理するのが筋かと思いまし、ドキュメント中でもサーバサイドでの処理を考えてデザインしていないと書かれていますが、PHPでは json_decode という関数があるので、これを用いて結果のJSON形式をオブジェクトか連想配列で受け取ることが出来ます。

ちなみに、このAPIにはブランディングガイドラインがあり、指定された用語を使わないといけないようです。例えば、書籍のプレビューを「ダウンロード」や「立ち読み」などと言うのはNGのようです。

コード例

少し例を書いてみると以下のようになります。

PHPソースコード


$isbn = "4873112834";
$json = file_get_contents("http://books.google.com/books?bibkeys=ISBN:{$isbn}&jscmd=viewapi");
// json_decodeに仕事させるために必要な処理
$json = str_replace(array("\\x26", ";", "var _GBSBookInfo = "), array("&", "", ""), $json);
// オブジェクトに変換
$book = json_decode($json, true);
$book = $book["ISBN:".$isbn];
// サムネイルのサイズを大きくする
$book["thumbnail_url"] = preg_replace("/zoom=\d/", "zoom=1", $book["thumbnail_url"]);
// 書き出し
echo ''. $book["info_url"] .'">'. $book["thumbnail_url"] .'" alt="書影画像" style="border: 1px solid #333;" />';
if ($book["preview"] != "noview"){
echo ''. $book["preview_url"] .'">';
}
?>

実行例

ブックビューワ埋め込みAPI （”Embedded Viewer API”）

Google Codeでの仕様解説ページ

ブックビューワ埋め込みAPIは書籍のプレビューが可能な場合に、そのビューワを呼び出してウェブページ中に埋め込めるAPIです。ビューワではPDFビューワのようで、ページ内容を検索したり、ズームしたりといったコントロールが設けられています。触った印象や呼びだし方はGoogle Mapsに似ています。

コードが不得手な人は英語ですがコード作成フォームも用意してくれているので、利用してみてください。

コード例

HTMLソースコード

<!DOCTYPE html "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Google Book Search Embedded Viewer API Exampletitle>
<script type="text/javascript" src="http://www.google.com/jsapi">script>
<script type="text/javascript">
google.load("books", "0", {"language": "ja"});
google.setOnLoadCallback(initialize);
 
function initialize() {
  var viewer = new google.books.DefaultViewer(document.getElementById('viewerCanvas'));
  viewer.load('ISBN:4569635458', notFound, Found);
}
 
function Found(){
  // alert("指定された書籍がありました");
}
 
function notFound(){
  alert("指定された書籍は見つかりませんでした");
}
script>
head>
<body>
<div id="viewerCanvas" style="width: 600px; height: 500px">div>
body>
html>

では、主要な部分を見ていきましょう。

HTMLソースコード

<script type="text/javascript" src="http://www.google.com/jsapi">script>

ブックビューワ埋め込みAPIではGoogle Maps APIのように空のブロック要素の中に、javascriptで内容を挿入していく方法を採っています。そして、その基礎となるGoogle AJAX APIスクリプトをまず読み込んでいます。

HTMLソースコード

<script type="text/javascript">
google.load("books", "0", {"language": "ja"});
google.setOnLoadCallback(initialize);
 
function initialize() {
  var viewer = new google.books.DefaultViewer(document.getElementById('viewerCanvas'));
  viewer.load('ISBN:4873112834', notFound, Found);
}
// （略）
script>

次に、google.loadメソッドでブックビューワ埋め込みAPIを呼び出しています。3つめの引数は任意で表示言語を指定することができます。

最後に、google.setOnLoadCallbackメソッドを介してinitializeメソッドを呼び出します。google.setOnLoadCallbackメソッドはブラウザ上でスクリプトが確実に実行されるように、DOMツリーが構築されるのを待ってメソッドを実行する関数です。

そのinitializeメソッドですが、Google Mapsのようにまずgoogle.books.DefaultViewerメソッドでビューワを呼び出すブロック要素を指定して初期化し、次にloadメソッドで識別子（ISBNなど）を指定して、ビューワを呼び出します。2つ目の引数に指定したメソッドはビューワが利用できない場合に、3つ目の引数に指定したメソッドはビューワの呼び出しに成功した時にそれぞれ呼び出されます。

ちなみに、呼び出す前にプレビューがそもそも利用できるかどうか確認したい場合は動的リンクの embeddable の返り値を利用してください。

実行例

全文検索 & メタデータ編集API（”Data API”）

Google Codeでの仕様解説ページ

全文検索APIは文字通り書籍のタイトル、目次、説明、内容などから書籍の検索が出来るAPIで、認証無しで利用できます。一方、メタデータ編集APIは利用情報とのひも付けが必要なのでGoogleアカウントでの認証が必要で、認証後は利用者独自の本棚の内容を取得・編集したり、本のレビューやタグに変更を加えたり出来ます。後者を解説すると長くなるので今回は割愛しましょう。

全文検索APIはRESTでデータを渡せばATOMフォーマットでデータが返ってくるというものです。以下は、「オライリー」が含まれており、かつAsanoという方が書かれた本のフィードのURLです。

http://www.google.com/books/feeds/volumes?q=%E3%82%AA%E3%83%A9%E3%82%A4%E3%83%AA%E3%83%BC+inauthor%3AAsano

ベースURL

http://books.google.com/books/feeds/volumes

qパラメータ

検索クエリを指定します。検索対象はタイトル、キーワード、説明、著者名、主題です。&で複数のクエリをくっつけて、検索語の頭に – を付けると、その後を除いた検索が出来ます。また、同じく以下のように接頭辞をつけることで検索語の検索対象を絞ることが出来ます

inauthor:: 検索対象：著者名
intitle:: 検索対象：タイトル
inpublisher:: 検索対象：出版社
date:: 検索対象：出版年。date:1990-2001のように指定する
isbn:: 検索対象：ISBN

start-indexパラメータ

検索を開始する件数（＝オフセット数）。max-resultsパラメータと組み合わせて使う。

max-resultsパラメータ

1回の検索に含める件数。デフォルト値は10で最大値は20。

min-viewabilityパラメータ

検索結果を公開レベルに応じて絞り込みたいときに使用します。値にfullを指定すると全文公開のアイテムのみ、partialを指定すると一部公開と全文公開のアイテムのみ結果に出力されます。

コード例

コード例は「オライリー」を検索語にして得られた検索結果を書きだしてみたものです。Amazonと違ってモノそのものは売っていないので、価格を出したり入手できるようにしたい場合はAmazonアソシエイトと組み合わせる必要があります。

それにしても対象書籍の言語を指定する方法がどうにも見つかないのが気になりますね。検索オプションにはきちんとオプションが存在しますので、ないことはないのでしょうが…。

PHPソースコード


 
$url = "http://books.google.com/books/feeds/volumes?hl=ja&q=". urlencode("オライリー") ."&max-results=5";
$str = file_get_contents($url);
$str = str_replace("dc:", "", $str);
$xml = simplexml_load_string($str);
 
foreach ($xml->entry as $item){
  
  if (strpos($item->link[0]["type"], "image") !== false){
    $cover = preg_replace("/zoom=\d/", "zoom=1", h($item->link[0]["href"]));
    echo ''. h($item->link[1]["href"]) .'">'. $cover .'" alt="書影画像" style="border: 1px solid #333;" />';
  }
  
  echo ''. h($item->link[1]["href"]) .'">'. $item->title .'';
  if (strpos($item->link[2]["rel"], "preview") !== false){
    echo ''. h($item->link[2]["href"]) .'">';
  }
  echo ''. h($item->description) .'';
  echo '';  echo ($item->creator) ? '' : "";  echo ($item->publisher) ? '' : "";  echo ($item->date) ? '' : "";  echo '
著者 '. h($item->creator) .'
出版社 '. h($item->publisher) .'
出版年 '. h($item->date) .'年
';
  
}
 
function h($s){
  return htmlspecialchars($s);
}
 
?>

著者	'. h($item->creator) .'
出版社	'. h($item->publisher) .'
出版年	'. h($item->date) .'年

実行例

Satistics Hacks

上場はされてないが、本書の出版社であるオライリー・メディア社を例に考えてみよう。もちろん、ランダムにオライリー・メディア社を選んだわけではない。企業の存続期間については、その傾向を示す歴史的情報もいろいろと入手できるが、とにかくGottの …

出版社	O’Reilly Japan
出版年	2007-12年

Running Linux

八ひ 1 は 5 者、「 9 丁\ 1 し& X ョ丁? 4 し一 7116 00^011^6 0 ^ ( 16 』、( :ヒ化レ\ 111301300 ^ 8111 に 6110 おゲ共著、 0 , ! ^出) ^ &八お 0013 お 5 (「ョ丁! ^ し& X 9 丁^し第 5 版」、原隆文訳、オライリー"ジャパン)「II 丁\ 1 し?

出版社	O’Reilly Japan
出版年	2003-06年

Veronica Guerin

1996年、アイルランド共和国の首都ダブリン―大手新聞記者、ヴェロニカ・ゲリンは凶弾に倒れた。タブーを恐れず、麻薬犯罪の実態を暴く記事を書いたがために。やがて、その …

著者	エミリーオライリー
出版年	2004-06-30年

「老い」とアメリカ文化

著者	イヴリン・M・オライリー
出版年	2004-04年

sendmail Volume 2 設定編

オライリーの新刊请報や購読特典などを、いち早く统若の皆様へお知らせするオライリーブッククラブのメンバ一を募集しています。 … オライリー特製グッズのプレゼント情報.技術セミナ—など各種ィベント惰铕参加费:無料参加資格:電子メールァドレスをお …

著者	エリックオールマン
出版社	O’Reilly Japan
出版年	2004-04年

感想

現在の所、日本語での登録書籍数は約95,000件、うちプレビュー可能な書籍は16,800件（17.6%）とまだまだ心許ない状況¹ ですが、ビューワはうまく作られていますので、プレビューがある場合は本を買うかどうかの参考材料にできますね。

早速、OPACにも取り込もうと思います² が、一般的にはAmazonアソシエイトと動的リンクを組み合わせて、プレビューボタンを出すのが無難な使い方かと思います。

Amazonも黙ってみているわけはないでしょうから、Amazon側のAPIがより充実していくことも期待してます。

ちなみに、一見慈善事業のようなAPIですが、そこはGoogle Mapsと違って、こちらはビューワに広告が付くことでマネタイズしているようです。

参考までに、2007年の出版点数は約77,000件です
OPACの利用者は資料選定の際には、書籍の説明など参考材料を必ずチェック行動が見て取れますので

RDBMSが扱いづらいのでSQliteを簡易XMLデータベースぽく使えるようにしてみた

hash — Mon, 22 Sep 2008 20:43:18 +0000

最近大量の情報を扱うようになってから、MySQLやらSQLiteなどのRDBMSを触っているのですが、どうにも慣れません。

以前から小規模な設定は、SimpleXMLで書いたり読んだりしていまして、データベースなぞに触らなかったものですから、その直感的な操作性に味を占めてしまうと、前時代的なSQLのクエリをちくちく発行する気にはどうにもなりません¹ 。それにバイナリで中身が見られないというのは、全てがテキストエディタで覗けてなんとかなるというのに慣れた身にはどうにも不安すぎます。

何年か前からXMLでデータを管理するXMLデータベースというのも出ていて、Apache Xindiceなんかはオープンソースでの開発が進んでいるそうですが、一般的なレンタルサーバにおいてPHPで扱えるとなると、選択肢はどうもないようです。

そこで、SQLiteを使ってXMLデータベース的な事をやってみました² 。方法はまぁ誰もが思い
つくとは思いますが、BLOB型のレコードにXMLファイル文字列をそのまま突っ込んでIDつけてるだけです。それをクラスライブラリを介して、透過的に扱おうという案配です。

パフォーマンステスト

で、とりあえず、パフォーマンステストとして定番らしい郵便番号→住所変換で実行時間を測定してみます（元データは郵便事業会社で公開されています）

実験内容: Aにはデータを郵便番号、地名、番地名など細かい住所をそのままRDBの構造として格納、BにはこれらをXMLとして表現したものをそのまま挿入したものを挿入します。それぞれ郵便番号を指定して住所に変換する時間を測定します（レコード数は118,576件）
Aの方法: 実行時間：0.04671秒（5回実行平均）; メモリ最大使用量：約995KB
Bの方法: 実行時間：0.17422秒（5回実行平均）; メモリ最大使用量：約1009KB

標準的なRDBに比べ4倍遅いという結果になりましたが、個人的には許容量なので今後はこれで開発していこうかなと思います。今のところは10万件レベルのデータを扱うことはそんなにないですし、数千件程度の小規模な場合ならBの方法でも0.01秒程度で実行できます。

生のXMLファイルをずらっと並べた上で、ファイル読み込み→SimpleXMLを使って検索なんかすると、メモリをバンバン食う上にスケーラビリティが皆無に等しいのですが、この方法だとある程度は持ちこたえられます。パフォーマンスやスケーラビリティを気にする人は間違っても使ってはいけません。加えてテーブルを1個しか持てませんが、増やしたい場合はデータベースファイルを増やせば良いだけなので特に気にしてません。

取扱説明書

初期データ入力

コントローラ側で、データ元のXMLがあるフォルダとDBのファイル名を指定します。DBファイルは事前に空ファイルを”ファイル名.db”という名前で作っておき、XMLがあるフォルダと共に書き込み可能にしておきます。コントローラのURIに construct というクエリを付けて実行するとデータ入力が始まります。

データ取得

searchメソッドで検索結果を取得を取得できます。引数は3つあり、順に”検索語”, “検索方法”, “検索対象の要素がある場所”です。

検索方法が取る値はall（全文検索）, parts（部分一致）, full（完全一致）, prefix（前方一致）, suffix（後方一致）の4つです。検索対象の要素がある場所はSimpleXMLを使うときのようにノードのパスを指定します、全文検索の際はこの引数は無視されます。

正常にデータが取得できれば、XMLの配列でデータが帰ってきます（SimpleXMLElement Object型になってます）

サンプルコード（郵便番号→住所の変換）

PHPソースコード


$db = new XSQLiteManager;
 
// データベースのファイル名とXMLがあるフォルダを指定して読み込む
$db->simplexml_load_db("zipcode", "./data");
 
if ($_GET["zip"]){
  $zip = mb_convert_kana($_GET["zip"], "a");
  if (preg_match("/(\d{3})\-?(\d{4})/", $zip, $q)){
    // 検索を実行してXMLの配列形式で結果を受け取る
    $results = $db->search($q[1].$q[2], "full", "zip");
    if ($results){
      $address = $results[0]->name. $results[0]->local;
      echo "郵便番号（". htmlspecialchars($zip) ."）の住所は". $address ."です";
    } else{
      echo "検索語に当てはまる検索結果が見つかりません";
    }
  } else{
    echo "正しい郵便番号（数字7桁）を入力してください";
  }
}
 
 
?>

データ追加

XMLデータ文字列を引数にして insertXML メソッドを実行してください。データベースの最後尾に追加されます。

データ更新

IDとXMLデータ文字列を引数にして updateXML メソッドを実行してください。IDはデータベース上のレコード番号のことで search メソッドを実行したときに帰ってくる結果の配列のキーに書いてあります。

データ削除

IDを引数にして deleteXML メソッドを実行してください。

デモとダウンロード

郵便番号検索デモサイト

ダウンロード: データベース一式 (20MB)
ライセンス: GNU General Public License（郵便番号データの著作権は郵便事業会社にあると思うので除外）

なにしろPHP5だと simplexml_load_file で設定を読み込んで、目的の項目を選ぶという2行のコードですむわけですから。RDBMSもフレームワーク附属のライブラリを使えば楽になるのかもしれませんけどフレームワークを使わない場合もあるわけで
SQliteにしたのは必要なファイルが1つにまとめられていて環境移行がやりやすいためです

このサイト上で使っているWordPress用テーマ “cielo” を公開するよ

hash — Sat, 13 Sep 2008 18:28:18 +0000

前々からこのサイトのテーマの配布準備作業を進めていましたが、ようやく形になったので一般公開します。ちなみに “cielo” とはイタリア語で空という意味です。

デモサイト

ダウンロード: cieloテーマ(約1.2MB)
最終更新日: 2011年9月13日 08時05分
動作環境: PHP5.2.0以上、WordPress 2.5以上
ライセンス: ライセンスが設定されているリソースはそのライセンスに従ってください。その他は修正BSDライセンスとします

使い方

ファイルをダウンロードしたら解凍してください
中に入っている/module/config.phpファイルがテーマの設定ファイルですので、指示に従って設定してください
サーバの/wp-content/themes/フォルダに(2)をアップロードしてください
サーバの/wp-content/themes/cielo/cache/フォルダを書き込み可能な状態(パーミッションを0777)にしてください
必須プラグイン一式をダウンロードし、解凍します
サーバの/wp-content/plugins/フォルダに(4)をアップロードしてください
管理画面からプラグインを有効化します
管理画面からテーマを有効化します
記事一覧ページなど特殊なページを作成します。投稿 → ページから以下のページを作成してください。中身はテンプレートから自動的に読み込まれます
- ポストスラグ名:webmemoのページを作成。タイトルはご自由に、中身は空でOK
- ポストスラグ名:archivesのページを作成。タイトルはご自由に、中身は空でOK
- ポストスラグ名:allのページを作成。タイトルはご自由に、中身は空でOK
- ポストスラグ名:readmoreのページを作成。タイトルはご自由に、中身は空でOK

特徴

快適に読むための環境

ブログは読者あってこそ。できるだけ多くの人に快適にブログを見てもらえるよう、多すぎず、少なすぎず必要な機能を配置しました

1カラム: 本文のレイアウトが崩れにくく、本文を一番読んでもらえる1カラムを採用しました
本文検索機能: 並び替え機能、検索結果の自動継ぎ足しをサポート
次の記事へ: 関連記事、人気の記事(自動取得&手動設定)で次の記事へ読者を案内します

各種ウェブサービスとの連携

ブログサイトを運営する上で欠かせないネット上のサービスも簡単に利用できます。

Google Analytics: Googleのアクセス解析サービスも設定画面から認証キーを入力すれば利用できます
はてなブックマーク: エントリーページにはてなブックマークへのリンクを自動的に表示します; コメント欄には、はてなブックマークのコメントがシームレスに表示されるよう組み込みました
ウェブメモ機能: twitter, tumblr, はてなブックマーク上での最新の更新をウェブメモコーナーとして表示できます。表示した各記事には、はてなスターをつけることができます(はてなスターのトークンの発行が必要です)

ウェブアプリケーションを簡単に使える内蔵機能

便利なウェブアプリケーションが記事中で簡単に呼び出せます

Googleマップを1行で: 住所を指定するだけでその周辺の2D地図や風景を表示できます(Googleマップ APIの発行が必要です)
動画の貼り付けも1行で: 動画共有サイト(Youtube, Googleビデオ)上の動画や自作動画をコードを考えることなく簡単に公開できます

モバイルにも対応

もちろん、携帯電話やiPhoneなどのモバイル機器にも対応します

携帯電話にもプラグイン使用で対応: 餅は餅屋…ということで動きの速い携帯電話向けの最適化はKtai Styleを使うことで対応することにしました
iPhone / iPod touchに標準対応: ビジュアルデザインはiPhoneのSafariでも読みやすくなるよう最適化しています; 呼び出した動画や地図は、iPhone / iPod touch内蔵アプリでも再生できるように工夫しています

その他にも

XHTML1.1 + CSSで書いています: Web標準に準拠した、できるだけシンプルな文書構造を心がけました。現在使われているほとんどのウェブブラウザに対応しています。
SEOにも配慮: metaタグの自動生成、XHTMLでの構造化、わかりやすいページタイトルとテーマ側で出来ることはやっておきました。
間違ってると思ったらすぐ編集: ログインしている間は記事画面からワンクリックで編集画面に移動できます。
エフェクトでおめかし: あれこれポップアップ(リンク先・引用元のタイトルなどをちょっとリッチにポップアップするスクリプト)やjQuery lightbox プラグイン(写真のポップアップをエフェクトを付けて表示するスクリプト)を標準で導入しています
ページ毎のCSSデザインも簡単に: Sandbox テーマは主要な要素に現在の状態を示すクラス名をつける機能がありますが、cieloはこの機能を取り込んでいます
ダウンロードは高速に: 一部のファイルをGZIPという形式で圧縮しており、サーバとブラウザが対応していれば落とすファイルサイズが小さくなり、高速にページが表示できるようになります(方法)
続き物の記事はまとめよう: 記事は独立したものだけではなく、何回かに分けて書いた続き物の記事もあるでしょう。cieloテーマではそうした記事を半自動的にまとめあげ、シリーズのRSSフィードを発行することも出来ます(方法)

サポートしないもの

このテーマは次の機能をサポートしません

可変1カラムデザイン以外の表示方法
コメント欄でのアバターの表示
UTF-8以外の文字コードでの運用

導入を推奨するプラグイン

依存しているプラグイン

推奨というより、このプラグインを入れていないと動かないので必ず入れておいてください

ダウンロード: 必須プラグイン一式をダウンロード
ライセンス: GNU General Public License

runPHP: 記事中でPHPコードを使うプラグインです。内蔵の動画共有サイトのコード呼び出し機能などを使ったり、記事一覧ページ中で記述しているPHPコードを実行するのに必要です。「ビジュアルリッチエディタ」「XHTML 構文の自動修正」とは同時使用できないようですが、同種のプラグインは多くあるようなのでそちらを使っていただいても構いません。
Similar Posts: 関連記事を表示させるためのプラグイン
Post-Plugin Library: 上記プラグインを利用するために必要なプラグイン。これを利用したプラグインとして、上記意外にも人気記事を表示するPopular Postsなどがあるので、余裕があれば試してみては。

入れたら便利なプラグイン

入れなくても良いけど、実害はあまりないし便利なので入れておくことをオススメするプラグインです。

WP-Footnotes: 本文中に((脚注の内容))と書くだけで脚注を生成してくれるプラグインです、ちょっとした余談で話の腰を折らずにすみます
Table of Contents Generator: 本文中に