CodeIgniterの Scaffolding で日本語が使えない(訳ではないのだが

MySQL を利用しているので、どっかで ’SET NAMES ~’ を送りたいと思っていたら、そのものずばりが goungoun技術系雑記帳 にて紹介されていました。

system/database/DB_driver.php 内で、接続を行い、そのオブジェクトをチェックした直後に、以下のコードで OK なようです。

if ($this->dbdriver == ‘mysql’) {
    $this->simple_query(‘SET NAMES utf8′);
}

dbdriver 名が ‘mysql’ の場合にだけ、simple_query() メソッドを呼ぶわけですね。

これで簡単にテストデータを入力したりチェックしたりが出来るようになりました。

Scaffolding 使わないのであれば、自作の Model とか Controller の初期化時に simple_query() 呼び出せば良いのですけどね。

Windows Vistaのサービスを色々切ってみた

つまるところ、Vista は重いのです。

34個ほど自分の環境では必要ないサービスを停止、手動起動に変更して、1日ほど使ってみました。

ある程度使い込んだ環境なので、元の起動時のメモリは700MBほど消費。
変更後の起動時のメモリは660MBとなりました。

もちろんメモリが空いたことはうれしいことなのですが、それ以上に、実行中の負荷がかなり減っています。

常駐系で、ファイル監視(Defender とか)や Windows Firewall 、Search Indexer などのサービスがありますが、私の環境では他のアプリケーションを利用しているので邪魔であり、重複していて重たいわけです。

それらが動かないだけでも、ずいぶんと体感速度がアップしました。

元々持っている Microsoft のみのサービスのみで動かしているのならば、Vista もそんなに・・とは思わなかったのですが、使い込むにしたがって、色々バッティングしてしまいますね。

Aero はなんとなく切りたくなかったのでそのままですが、本当に体感速度を上げるのであれば、3D 機能が貧弱な(Panasonic CF-Y5を利用)わけですから、切るべきでしょう。

もう少し、問題が無いかを確認してみます。

HTMLファイルでも PHP ファイルとして見なす(php_flag short_open_tag off

先々日、.htaccess を利用することで、.html ファイルも PHP ファイルとして処理する方法を紹介しました。

しかし、そのとき足りなかったことがあるので追記します。

足りなかったのは、<?xml ~?> などのタグが入っている HTML ファイルの場合、<?~?> 部分を PHP として解釈しようとしてしまい、エラーを起こしてしまうのの、回避策です。

知ってしまえば簡単ですが、.htaccess に以下の1行を追加するだけです。

php_flag short_open_tag off

php.ini をいじれる環境であれば、この内容も設定できるのですが、ホスティングサービスなどで動かしたい場合には、今回の方法が有効ですね。

ただし、全ての .html ファイルを PHP として解析しますので、全体のパフォーマンスはわずかながら落ちますので、適用は考えてから行うようにしてください。

山本 悟

xajaxを使ってみた2(E_NOTICE

こんにちは、山本です。

昨日の続きです。

利用しているバージョンは、0.2.5 stable なのですが、問題が起きました。

error_reporting(E_ALL)

を入れていると、xajax.inc.php の747行目に書かれている $sResponse が、未定義なのでエラーしてしまうようです。

xajax.inc.php を直接書き換えるのはいやなので、E_NOTICE だけレポートから外すようにしました。

error_reporting(E_ALL ^ E_NOTICE);

変数未定義のエラーなどでアラートが出なくなりますが、検証済みのコードと言うことで逃げます。

0.5 が stable になる頃には解決して欲しいです。

山本 悟

xajaxを使ってみた

こんにちは、山本です。

標題の通り、xajax を使ってみました。

端的に言えば、JavaScript を(ほとんど)書かずに、PHP のプログラミングテクニックだけを使って Ajax の実装(表現がいまいち)できるクラス群です。

しかし、ちょっとつまずいたことがあるので、メモしておきます。

Smarty との連携を行う場合、私は1つの HTML を生成するのに複数のテンプレートを Smarty 内で include しています。

しかし、printJavascript() を呼ばなければならないのは(安全を考えれば) HEAD タグの内側です。

しかし、Smarty の display() では、その PHP オブジェクトの制御が出来ないため、JavaScript を生成できません。
当然オブジェクトの参照が渡されるわけではないので、{php}{/php} テンプレートタグ内で記述しても意味がありません。

呼び出し側の PHP 内で $Smarty->fetch() して、$xajax->getJavascript() を埋め込む方法も考えたのですが、テンプレートが大きいと単純置換でも無駄が多そうです。

結局、$xajax->getJavascript() を Smarty 変数として渡す方法をとりました。
大丈夫かな。

山本 悟

ZendFrameworkでメールを送ってみた(修正

こんにちは、山本です。

昨日作った ZendFramework のメール送信のサンプルですが、Willcom 端末で上手く表示されない場合がありました。

どうやら、文字コードが8bitエンコードなのが問題のようです。

$mail->setBodyText(mb_convert_encoding(‘テストだ’, ‘ISO-2022-jp’, ‘UTF-8′), ‘ISO-2022-jp’, Zend_Mime::ENCODING_7BIT);

解決する方法は、setBodyText() を呼び出す段階でエンコードを7bitに指定してあげることでした。

このサンプルは UTF-8 で保存しています。

山本 悟

ZendFrameworkでメールを送ってみた

こんにちは、山本です。

ZendFramework 1.0.1 を実験してみました。

なかなか柔軟性が高く、既存のプロジェクトに追加して使う場合でも、導入のハードルは低そうです。

さて、今回メールを送るプログラムを書いてみたのですが、日本語を送る場合には、文字コード指定がやはり必要でした。
備忘録として書いておきます。

$mail = new Zend_Mail(‘ISO-2022-JP’);
$mail->setBodyText(mb_convert_encoding(‘本文だ’, ‘ISO-2022-jp’, ‘UTF-8′));
$mail->setFrom(‘from@example.com’);
$mail->addTo(‘to@example.com’);
$mail->setSubject(mb_convert_encoding(‘見出しだ’, ‘ISO-2022-jp’, ‘UTF-8′));
$mail->send();

ポイントは、Zend_Mail のインスタンスを生成する際に、文字コードを文字列として渡してあげること、本文やサブジェクトをエンコードして渡してあげること、の2点のようです。

このサンプルは UTF-8 で保存したものです。

山本 悟

Delphi for PHPで MySQL を使う際の言語設定について

こんにちは、山本です。

CodeGear の製品である Delphi for PHP Update 1 を利用して、MySQL と連携したアプリケーションを作成する場合、問題となるのが文字コードです。

通常は次の様に接続すると思います。

Database1 の諸設定
Table1->Database = Database1
Datasource1->Dataset = Table1
DBGrid1->Datasource = Datasource1

しかし、この状態では、例え MySQL の言語設定が UTF-8 であったとしても、画面上の文字は化けてしまいます。デフォルトの文字コードが利用されてしまうからのようです。

これを解決するには、MySQL に対して利用する文字コードを指定すれば良いでしょう。
具体的には、Database1 の AfterConnect イベントで SQLを発行します。例を示します。

function Database1AfterConnect($sender, $params)
{
    $this->Database1->execute(‘SET NAMES utf8;’);
}

期待の大きい開発環境が故に、情報の少なさが残念です。
もっとメジャーになってもらいたいと本当に思います。

○確認した環境
Delphi for PHP Update 1
mysql  Ver 14.12 Distrib 5.0.41, for Win32 (ia32)

山本 悟

CGIでInternal Server Error、error.logにはPremature end of script headersが

こんにちは、山本です。 

つい先日、Perl を利用したシステムで、上記エラーが出ました。
さして古いサーバではなく、別サーバで動いているシステムを持ってきただけだったので、ある意味不思議でした。

とにかく原因を探るため、コンソール上で動くか(OK)、Perlへのパスは間違ってないか、改行コード・文字コードは問題ないか、アクセス権は問題ないか、同じディレクトリの他のCGIはどうか、などなど、一般的な問題探しを行ってみたのですが、全部問題ない動作です。

そもそも、別サーバでは動いているのですから、環境問題にある程度絞ってはみたものの、原因がわかりません。

その後Webで調べてみると、「#!/usr/bin/perl」の引数に「- -」を付ければ直ると書いてありました。
しかし、どうにも理由がハッキリしません。
ですが、動きます。

「- -」は Perl のスイッチをそれ以降オフにするオプションです。
ですので、後は想像になるのですが、Apache が CGI として Perl を呼び出す際、改行の認識の問題などで #! 以降までを引数として渡してしまい、Internal Server Error を起こしているのでは無いかと考えました。

ですので、「- -」を与えることで、最初の1行を本来の実行ファイルのパス指定のみになり、問題が解決されたと言えます。

しかし、実際のところはどうなんでしょうか。
知っている方がいらっしゃれば、是非お教えください。

 山本 悟

あなたの IT の疑問・不安をすべて解決するコンシェルジュ サービス