で、今日の自分の中の結論としては、
・iPhone は iOS4(iOS3も対応出来るならやる)
・Andoroid は 2.1 以降
・アプリ開発は避け、要件をなるべくWebアプリへ寄せていく
・Andoroidだからと言って、Flashがちゃんと見れると思うなよ！！
・WindowsPhoneとBlackBerryは無視
・タブレットの場合はPCサイトを見せた方が良い
と、他にも色々あるけど、大きくはこんな感じで。

でわ。

2010-10-28

さくらインターネットの共用サーバでEC-CUBEのモバイル版を動かす

PHP EC-CUBE サーバとか DBとか

現在運用中のEC-CUBEのサイトがある。
さくらインターネットの共用サーバで動作している。

で、今まではPCサイトのみで動作していたのだが、モバイル版もカスタマイズして使えるようにして欲しいと。

専用サーバの場合、ゴリゴリとサーバ自体の設定をいじれるから問題無いのだが、さくらの共用サーバはそうもいかない。

インストールされた状態のままでもうまく動かない。

色々やって、うまく動くようになったので、備忘録。

1) SC_DbConn.phpの修正(data/class/SC_DbConn.php)
DB接続部分でなにやらエラーが出てうまく動かなかったので、コンストラクタのDB接続部分をこんな感じで修正。

// 既に接続されていないか、新規接続要望の場合は接続する。
if(!isset($objDbConn->connection) || $new) {
    if($dsn != "") {
        $objDbConn = DB::connect($dsn, $options);
        $this->dsn = $dsn;
        // ここから下3行を追加
        $buf = $objDbConn->prepare('SET NAMES utf8');
        $objDbConn->execute($buf);
        mysql_set_charset("utf8");
    } else {
        if(defined('DEFAULT_DSN')) {
            $objDbConn = DB::connect(DEFAULT_DSN, $options);
            $this->dsn = DEFAULT_DSN;
        } else {
            return;
        }
    }
}

2) php.iniをばらまく
さくらサーバの場合、html/mobile配下に設置されている.htaccessが効かないので、php.iniにして、その配下のディレクトリ全てにばらまく。

$ cd html/mobile
$ mv .htaccess .htaccess.bk
$ vi php.ini
mbstring.language=Japanese
output_handler=null
mbstring.encoding_translation=Off
magic_quotes_gpc=Off
mbstring.internal_encoding=UTF-8
variables_order=EGPS
session.auto_start=Off
session.use_trans_sid=On

$ cp ./php.ini ./cart/
$ cp ./php.ini ./contact/
$ cp ./php.ini ./entry/
$ cp ./php.ini ./forgot/
$ cp ./php.ini ./frontparts/bloc/
$ cp ./php.ini ./guide/
$ cp ./php.ini ./mypage/
$ cp ./php.ini ./products/
$ cp ./php.ini ./regist/
$ cp ./php.ini ./shopping/
$ cp ./php.ini ./unsupported/
$ cp ./php.ini ./user_data/

とりあえず、こんな感じでうまく動くようになりました。

でわ。

2010-09-17

PHP(PDO)＋Oracle＝too large for buffer and was truncated

サーバとか PHP Oracle

ハマったので。

PHP 5.1.6
Oracle 10.2.3
にて。

PDO_OCIでPHPとOracleとを繋いでる環境でエラーじゃないけど、Warningが出た。

Warning: PDOStatement::fetch(): column X data was too large for buffer and was truncated to fit it in test.php on line XXX

VARCHAR2のカラムからデータを取得すると出た。
正常にデータが取得出来てるっぽかったけど、おしりの何バイトかが切れてた。

おぉ、trancateされてる。

色々調べてみたところ、全角文字が入ってるとダメだった。

さらに調べてみると、原因が分かった。

Oracle：SJIS
PHP：UTF-8
これが原因だった。

OracleはSJISなので、全角文字は2バイト。
PHPはUTF-8なので、全角文字は3バイト。

PDO_OCIの場合、テーブルのカラムの型と長さを参照してバッファを決めるようで。

全角文字が入っていた場合、そのバッファが溢れる事があるのです。
なんせ、2バイトだと思っていた全角文字が3バイトだったので。

VARCHAR2(20)のカラムに、全角文字が10文字入っていた場合、SJISならば20バイトなので、OK。
しかし、UTF-8だと30バイトになってしまうので、受け取る側のバッファが溢れてしまう、という事。

対応どうしようか・・・
と考え、
/etc/sysconfig/httpd
をちょっと編集してみた。

# cd /etc/sysconfig/
# vi httpd
export NLS_LANG=Japanese_Japan.UTF8
↓に変更
export NLS_LANG=Japanese_Japan.JA16SJIS
# /etc/rc.d/init.d/httpd restart

Warnningは出なくなったけど、文字化けした。
DBから取得してる根っこの部分でSJIS→UTF-8の変換をかけようかと考えたのですが、symfony+doctorineという事もあり、断念。

だって、調べるの面倒だから・・・

テーブルのカラム長の定義を1.5倍すれば回避出来るけど、運用案件では無理なので断念。

結果、PDO_OCIのソースをちょっと直して対応する事に。

# cd /usr/local/src
# cd PDO_OCI-1.0
# vi oci_statement.c
510行目付近に有る記述
col->maxlen = data_size;
↓
col->maxlen = data_size*1.5;
# ./configure
# make
# make install

PDOがOracleのテーブルのカラムの長さを取得してる部分で、その長さを1.5倍してあげれば大丈夫。

この対応方法が良いかどうかは疑問が残るが、とりあえずはこれで回避しよう。

でわ。