PEARが働かない?
最近PEARを使ったプログラムが時々働いていません。
API関係はすべてPEARを使っているので全滅です。
サーバーの負荷の問題?
原因は不明ですが、調子が悪いです。
対策として、PHP4でも使えそうな
http://keithdevens.com/software/phpxml
のPHP XML Libraryを使ってみようと思います。
最近PEARを使ったプログラムが時々働いていません。
API関係はすべてPEARを使っているので全滅です。
サーバーの負荷の問題?
原因は不明ですが、調子が悪いです。
対策として、PHP4でも使えそうな
http://keithdevens.com/software/phpxml
のPHP XML Libraryを使ってみようと思います。
PHPを利用してPDFファイルが作れるTCPDFを使ってみました。
他にもFPDFという無料のライブラリがあるそうですが、TCPDFはそれをさらに発展させた無料のライブラリです。
現在のバージョンは、4.0.030 です。特徴は、
などですが、CSVのようなデータファイルを元に動的にPDFを作成することが可能です。
日本語での情報は、チーターエンジニア(TCPDFドキュメント)が最新情報に適応しています。
チータ-エンジニアさんに感謝いたしま��。
CGIで作られた会員用プログラムはクッキーがセットしてあるのですが、そのクッキーを利用してPHPで追加のプログラムを作ってみようかと思いました。
そこで、クッキーを学んだことのない私には、CGIでセットしたクッキーがPHPで読める?ということがなかなか分からず苦労しました。
原因は、クッキーが作成されたディレクトリの配下でしか読めないという基本的なことに気づくのが遅れたためです。
Aというディレクトリで作成されたCGIのクッキー(名前を仮にcokkiename)をPHPのテストプログラムで上位のルートから読み込もうと無駄なことをしていました。Aディレクトリにテスト用のPHPのプログラム「echo $_COKKIE['cokkiename'];」をおいて実行。
結論は、CGIでセットしたクッキーがPHPで読めました。でももう少し基礎から勉強しておけばすぐ分かったことですね。
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');
//略
?>
他にもやり方はありそうですがとりあえず覚えとして。
岡山WEBネットの検索エンジンがCGI版のYomi-SearchからPHP版に移行しました。
動作確認にはもう少し時間がかかりそうなので、旧来のCGI版も今のところ残してあります。
但しCGI版からは新規登録はできません。
動作の最終確認後、ご登録してくださった方にお知らせしようかと思っております。
PHPを勉強しているのだから岡山WEBサーチのYomi-SearchもCGI版からPHPに変えようかと思いつき、インストールを試行。
実は、以前もPHP版に一時的に移行したことがあったのだけれど、バックアップが文字化けとなり断念したことがあったのです。今度は、それから年数もたっていることだし進化したに違いないと思い、テスト的にインストール。
しかし、不思議なことにインストールしたら英数字以外がすべて??という文字に。データベースの照会順序ががlaten1_swedish_ci になり、yomisearchの管理画面から見ても文字は????のまま。新規登録した文字も英数字以外の日本語は????に変換。おかしいと思いながら、インターネットで検索していると
XAMPP+Yomi-Search(PHP)modified で 文字化け(PHP+MySQL の文字化け) (masha.webTechLog)というところで
「データベースとテーブルの文字コード設定が原因 データベースの文字コード(MySQL 接続照会順序)が初期状態「latin1」のままだったことが直接の原因。phpMyAdmin 上で「ALTER DATABASE `DB名` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci」を実行し文字コードを utf8 へと変更。そして Yomi-Search(PHP)modified を再セットアップすると文字化けは解消した。(以上引用)」
を発見。
そして、phpMyAdminを見て見ると、「操作」という画面でテーブルごとに文字の照会順序が変更できることにやっと気がつきました。yomi_categoryのテーブルをlaten1_swedish_ci から utf8_unicode_ci に変更すると既に入っているデータは??のままですが新規に入力したり、データベースに修正でカタカナや漢字ををいれると文字化けも無くなりました。
私が借りているサーバーの問題と思いますが、自分としては、やっと解決したのでほっとしています。
つぎにインストールした後でいちいちテーブルごとに照会順序を変えたのでは面倒なので、データベースを作成した時に照会順序をutf8にしたらどうなるかと思い、Yomi-Search用にデータベースを作成し、phpMyAdminでそのデータベース名を確認し、操作ボタンで見ると、照会順序が laten1_swedish_ci になっているので をそれを utf8_unicode_ci 変更。そしてセットアップを実行するとすべてのテーブルがutf8_unicode_ciに。文字化けも無くセットアップ完了しました。
後は、既存データの移動とバックアップがうまくいけばPHP版に移行しようかと思います。
月 | 火 | 水 | 木 | 金 | 土 | 日 |
---|---|---|---|---|---|---|
« 6 月 | ||||||
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |