XML_Unserializerについて
PHP5になったのでPEARのXML_Unserializerを使用しなくてもAPIに対応できそうですが、今までPHP4の時に使用していたので修正する時間もないので継続して使用しています。
ところであるAPIが文字コードshift_jisで出力されているようでXML_Unserializerで文字化けとなりました。
そこで以前、経験したようにXML_Unserializerのオプションを使用してコードをUTF-8に変換するとUTF-8でAPIを配列に出力してくれます。
require_once "XML/Unserializer.php";
$xml_data = file_get_contents(’リクエストURL’);
$parser = new XML_Unserializer(array('parseAttributes' => true,'targetEncoding' => 'UTF-8'));
$parser->unserialize($xml_data);
$XML = $parser->getUnserializedData();
これで後は配列＄XMLから取り出した変数をHTMLに書き出せばいいのです。
対象のHTMLはshift_jisなので配列$XMLの出力をUTF-8からshift_jisに変更しなくてはいけません。
mb_convert_encodingはひとつの文字列ごとの変換でのでコードが煩雑になるなと思って配列$XMLを一括してshift_jisに変更する方法はないかと探したら
mb_convert_variables
がありました。PHP関数リファレンスによると
「エンコーディング from_encoding の変数 vars をエンコーディング to_encoding に変換します。 」
「vars(3番目以降の引数)は、変換する変数への リファレンスです。文字列、配列、オブジェクトを指定することが可能です。 mb_convert_variables() は全てのパラメータが 同じエンコーディングを有することを仮定します。 」
ということで
mb_convert_variables("Shift_Jis", "UTF-8", $XML);
とすることで配列$XMLが一括でShift-Jisに変換。
PEARのアップグレイド
PEARをインストールしたのが2007年でしたがそれからヴァージョンアップされていました。
AmazonWEBサービスが2009年8月から変更になったのですが、対処のための時間がとれずそのままになっていました。調べるとPHPのバージョンがPHP5でないと難しいようで、PHP4だとPEARのServices/Amazon.phpをつかうとできる？ようなことが書かれてあったのでそれをPEARのHPからまず、ローカルな環境にてダウンロード（アップグレイド）しようと思い試してみました。
すると悲しいかなPEARのInstallerのバージョンが古すぎてダウンロードできない。PEAR自体をアップグレードしようにもやはりInstallerのバージョンがふるいようでできません。
—-
WARNING: channel “pear.php.net” has updated its protocols,use “channel-update p
ear.php.net” to update
pear/Archive_Tar requires PEAR Installer (version >= 1.5.4),installed version i
s 1.5.1
———
最初に出たWARNINGについては
pear channel-update pear.php.net
としてOKでしたがInstallerの方はどうもよく分かりませんでした。
そこで「PEAR 強制 アップグレード」などと検索して、–force か-f を加えてやるといいとあったので実行。
PEARはアップグレイドできました。その後Services/Amazon.phpもアップグレイドしてAmazonWEBサービスを試してみましたがPHP4ではやはり難しいようです。hashに関係するエラーメッセージがでてきてつながりません。
サーバーを変えなければ駄目か！
PEARが働かない？
最近PEARを使ったプログラムが時々働いていません。
API関係はすべてPEARを使っているので全滅です。
サーバーの負荷の問題？
原因は不明ですが、調子が悪いです。
対策として、PHP4でも使えそうな
http://keithdevens.com/software/phpxml
のPHP XML Libraryを使ってみようと思います。
PHPでPDFファイルを作れるTCPDF
PHPを利用してPDFファイルが作れるTCPDFを使ってみました。
他にもFPDFという無料のライブラリがあるそうですが、TCPDFはそれをさらに発展させた無料のライブラリです。
現在のバージョンは、4.0.030 です。特徴は、
などですが、ＣＳＶのようなデータファイルを元に動的にＰＤＦを作成することが可能です。
日本語での情報は、チーターエンジニア（ＴＣＰＤＦドキュメント）が最新情報に適応しています。
チータ－エンジニアさんに感謝いたします。
CGIでセットしたクッキーがPHPで読める？
CGIで作られた会員用プログラムはクッキーがセットしてあるのですが、そのクッキーを利用してPHPで追加のプログラムを作ってみようかと思いました。
そこで、クッキーを学んだことのない私には、CGIでセットしたクッキーがPHPで読める？ということがなかなか分からず苦労しました。
原因は、クッキーが作成されたディレクトリの配下でしか読めないという基本的なことに気づくのが遅れたためです。
Aというディレクトリで作成されたCGIのクッキー(名前を仮にcokkiename)をPHPのテストプログラムで上位のルートから読み込もうと無駄なことをしていました。Aディレクトリにテスト用のPHPのプログラム「echo $_COKKIE['cokkiename'];」をおいて実行。
結論は、CGIでセットしたクッキーがPHPで読めました。でももう少し基礎から勉強しておけばすぐ分かったことですね。
includeとパス ＜メモとして＞
PHPでプログラムを書く時、includeでファイルを読み込むことは欠かせません。しかし、相対パスで記入していると、あるカレントディレクトリのデータファイルを読み込んで処理するプログラムをそのカレントディレクターに作った場合、それを上位のディレクトリで実行すると、ファイルがありませんというPHPエラーとなります。
それを解消するには、データファイルをフルパスで読み込む必要があります。しかし、通常、ローカルの環境で試行してサーバーにアップするので、ローカルの場合は、「http://localhost/・・・」、サーバーの場合は「http://www.ドメイン名/・・・」というふうに切り替えなければなりません。
いちいちローカルで試した後、書き換えてアップしてもいいのですがこういう作業はミスを招きます。
そこで、PHPでは、実行するファイルの絶対パスを表示してくれる関数がありますのでそれを利用することにします。
使うのは、dirname()と__FILE__という関数と定数で、dirname(__FILE__)とすれば、現在のファイルの絶対パスが得られます。例えば、aaa.phpというファイルに、print dirname(__FILE__);という行を加えると、”var/HTML/abcdefg.com/web/aaa.phpのように絶対パスが表示されます。この文字のうち、ローカルのディレクトリ名に使っていない文字を抜き出してくる関数を使用します。strstrという関数は指定した部分文字があれば、その文字以降を抜き出しますが、なければFALSEを返します。したがって、if文でFALSEでなければ「http://www.abcdefg.com/ 」を、FALSEなら、「http://localhost/ 」をカレントデレクトリ/データファイルに加えれば
いいということになります。
ドメイン名：abcdefg.com
データファイル名：data.csv
データファイルのカレントディレクトリ：data
実行するファイル：ルートディレクトリのtest.php
と仮定。
test.phpに以下の記述を加えます。
$urlpath = dirname(__FILE__);
if(strstr($urlpath,"abcdefg")){
$root="http://www.abcdefg/";
}else{
$root="http://localhost/";
}
$Data=file($root.'data/data.csv');
//略
?>
他にもやり方はありそうですがとりあえず覚えとして。
Yomi-Search(PHP) modifiedへの移行完了
岡山WEBネットの検索エンジンがCGI版のYomi-SearchからPHP版に移行しました。
動作確認にはもう少し時間がかかりそうなので、旧来のCGI版も今のところ残してあります。
但しCGI版からは新規登録はできません。
動作の最終確認後、ご登録してくださった方にお知らせしようかと思っております。
Yomi-Search(PHP)modifiedのインストールで得られたもの
PHPを勉強しているのだから岡山WEBサーチのYomi-SearchもCGI版からPHPに変えようかと思いつき、インストールを試行。
実は、以前もPHP版に一時的に移行したことがあったのだけれど、バックアップが文字化けとなり断念したことがあったのです。今度は、それから年数もたっていることだし進化したに違いないと思い、テスト的にインストール。
しかし、不思議なことにインストールしたら英数字以外がすべて？？という文字に。データベースの照会順序ががlaten1_swedish_ｃi になり、yomisearchの管理画面から見ても文字は????のまま。新規登録した文字も英数字以外の日本語は????に変換。おかしいと思いながら、インターネットで検索していると
XAMPP＋Yomi-Search(PHP)modified で 文字化け（PHP+MySQL の文字化け） (masha.webTechLog）というところで
「データベースとテーブルの文字コード設定が原因 データベースの文字コード(MySQL 接続照会順序)が初期状態「latin1」のままだったことが直接の原因。phpMyAdmin 上で「ALTER DATABASE `ＤＢ名` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci」を実行し文字コードを utf8 へと変更。そして Yomi-Search(PHP)modified を再セットアップすると文字化けは解消した。（以上引用）」
を発見。
そして、phpMyAdminを見て見ると、「操作」という画面でテーブルごとに文字の照会順序が変更できることにやっと気がつきました。yomi_categoryのテーブルをlaten1_swedish_ｃi から utf8_unicode_ci に変更すると既に入っているデータは？？のままですが新規に入力したり、データベースに修正でカタカナや漢字ををいれると文字化けも無くなりました。
私が借りているサーバーの問題と思いますが、自分としては、やっと解決したのでほっとしています。
つぎにインストールした後でいちいちテーブルごとに照会順序を変えたのでは面倒なので、データベースを作成した時に照会順序をutf8にしたらどうなるかと思い、Yomi-Search用にデータベースを作成し、phpMyAdminでそのデータベース名を確認し、操作ボタンで見ると、照会順序が laten1_swedish_ｃi になっているので をそれを utf8_unicode_ci 変更。そしてセットアップを実行するとすべてのテーブルがutf8_unicode_ciに。文字化けも無くセットアップ完了しました。
後は、既存データの移動とバックアップがうまくいけばPHP版に移行しようかと思います。