度々遭遇するもいつも躓いてしまうため、メモっておきます。

例えばプログラム（スクリプト）が、SJISでコーディングを行っていて、データベースの文字コードがUTF-8の場合、当然書き込み時に文字コードの変換を行って書き込むが、ここで、「�@」、「��」と云った特殊な文字が文字化けする。

当然、書き込み時のエンコードは　mb_convert_encoding($data,"UTF-8", "sjis")　のように変換して書き込むが、前記の特殊な文字は文字化けを起こして「？」と云った具合になってしまう。

サーバ環境にも影響を受けますが、こんな時は変換部分を　mb_convert_encoding($data,"UTF-8", "sjis-win")　としてみると改善される。

このようなWinの特有の文字には度々悩まされますが、ユーザがWinを使っている以上仕方ないですね　

当然SJISに戻す場合（読み込んで表示する場合）は、mb_convert_encoding($data,"sjis-win", "UTF-8")　としないとイケマセン。　

まず初めに、肝心なZend Frameworkをダウンロードし、インストールしなければなりません。

ダウンロード先
http://framework.zend.com/manual/ja/introduction.installation.html

適当なフォルダにこのライブラリをアップすれば、設置は完了です。
php.iniでそこのフォルダのパスを設定します。
　　　include_path = ".:/xxxxx/xxxxxxxxx/xxxxxx/ZendFramework/library"　←サーバ環境により異なり（相対パスではなく絶対パスであること）
　　　ここまでで、設定は完了です。

さて、Zend Frameworkを使ってデータベースに接続してみましょう
　今回は、今後の汎用性も考えて、ファクトリメソッドを使用してみた。
   $db_info = array(
    'host'     => 'localhost',
    'username' => '',
    'password' => '',
    'dbname'   => ’/xxxxxx/xxxxxxx/xxxxxxx/xxxxx/xxxxxxx/xxxxxxx/xxxxxxxxx.db’); ←Sqliteの為、データベーステーブルまでのパスとデータベース名を指定
   $db = Zend_Db::factory('Pdo_Sqlite', $db_info);
　※恐らくこれらのパスの設定で少し戸惑うかもしれませんが、詳細は本家のサイトか各解説ページがありますので、ここでは割愛しておきます。

上記設定にてデータベースに繋がれば、今度はこのファクトリメソッドの情報を書き換えるだけで各データベースにアクセス出来るように共通化が出来るはずです。

　とは云っても、そんなに簡単に行くわけも無く、共通化するにはクエリーの互換性の問題などが発生しますので、その当たりは後日書き込む事にします。

忘れてました・・・（最初に書き込んでおくべきでした）
Sqliteの文字コードはUTF-8です、文字化けなどが心配な場合は、スクリプト（プログラム）も全てUTF-8に統一した方が間違いが少ないと思います。

php.iniの　「magic_quotes_gpc=on」の場合、POSTやGETで送信したデータはクオートされ、、「" → ¥"」「¥ → ¥¥」などとなりますが、特定の文字（漢字）もエスケープ（クオート）されます。
このクオート文字を外すのは受信側で「stripslashes」で外せば良いのだが、今回Cookieの読み込み（書き込みかも？）でもクオートされている事に気付いた。
例えば『代表取締役』とか入力しCookieに保存し読み込むと見事に『代表\取締役』となって読み込む結果となる。
いろいろ調査してみたが、どうやら読み込み時にクオートされているよう気がする。

そこでいつものようにこの件に関して調べて見たら何とショッキングな事に「この機能は PHP 5.3.0 で 非推奨となり、PHP 6.0.0 で削除されます。この機能を使用しないことを強く推奨します。」と本家のPHPサイトに記述が・・・

確かにSQLインジェクション対策としての役目は終わったとは云っても、このmagic_quotesにはさんざん悩まされて来ただけに何だか複雑な気持ちになる。

とは云っても、現在は対策が必要であることに違いがないので取り合えず対策を討って読み込み時にstripslashesを使用して「￥」を削除する事にした。

サーバって様々なプログラムが動作中なのでうっかり「magic_quotes_gpc=off」ってな訳には行かないのですよ
勿論、この設定がどちらでも正常に動作するようにはプログラムしておりますが、細心の注意が必要です。

最近、WordやExcelファイルを開こうとすると開けないと云った問い合わせが多くあります。
原因の多くは「Office　2007」以降ファイル形式が異なるからです。

Office　2007以降をお使いでも旧（Office　2003以前）ファイル形式で保存は可能ですので保存する場合には「97-2003の互換ファイル形式」で保存する事をお勧めします。
Excelの場合、「名前を付けて保存（A）」→「Excel 97-2003ブック（9）」で保存して下さい。
Wordの場合、「名前を付けて保存（A）」→「Word 97-2003文書（9）」で保存して下さい。

Office　2007以降を使用していて何気なくファイルに保存してしまうと、Office　2003以前のソフトでは開けないので注意しましょう
尚、Office　2007以降で何気なくファイル保存するとファイル形式（拡張子）は次のようになります。

Word　→　○○○○○．docx
Excel　→　○○○○○．ｘｌｓx

特に他の方にメールなどで送る場合などは、相手が新しいOfficeをお使いかどうかが分かりませんので、出来る限り古い形式で保存して送信する事が良いと思います。

どうしてもOffice　2003以前のバージョンで新しいファイル形式を読み込みたいときは、マイクロソフトから書きのソフトが手に入りますのでそちらをインストールして下さい。

対策ソフトです↓
http://www.microsoft.com/downloads/details.aspx?FamilyId=941B3470-3AE9-4AEE-8F43-C6BB74CD1466&displaylang=ja

追記・・・
PowerPointも同じです。

PHPでコーディングしていてたまーに引っかかる部分なので、メモっておきます。
PHPなどではデータの受け渡しなどでPOSTやGETのメソッドは多用するのであるが、このデータの受け取りにはスーパーグローバル変数の$_POST[’key_name’]（$_GET[’key_name’]）で受け取る場合が多いと思うが、ここに大きな落とし穴があります
$_POST[’key_name’]（$_GET[’key_name’]）は文字通りスパーグローバル変数であるが、うっかりこの’key_name’と同じ名前のローカル変数（$key_name）を使ったりすると$key_nameの内容が不安定になります。
基本的に、プログラム上$_POST[’key_name’]と$key_nameは別の変数と捉えられると考えるが、PHPでは明確に区別が付かずに混同して解釈されてしまうことが多々発生します。
この事は$_SESSION['key_name’]などでも同じような現象が発生します。

以前からこのような現象は起きていましたが、今回少し調べて見ました

その結果、次のような事が判明・・・
この、スパーグローバル変数の取り扱いは、php.iniの中のregister_globals の設定で変わる事が判明。これはPHP 4.2.0以降にデフォルトがOffに設定されているようで、この設定をOnにすると、$_POST[’key_name’]が$key_nameとして扱うことが可能になるようである。
わざわざデフォルトをOffにしたのはやはりセキュリティ的な問題からのようで、個人的にはOffのままがお勧めかと思いますし、やはりスーパーグローバル変数とローカル変数は明示的（意識してプログラムする）に動作して欲しいのでOffの方がプログラム上良いような気がします。

セキュリティに関する参考記事・・・
http://itpro.nikkeibp.co.jp/article/NEWS/20051102/223939/?ST=security

Google（API）地図の機能を利用して、住所から緯度と経度を割り出して、その情報を元にQRコードの自動生成を試みた。

住所から、緯度・経度を割り出す部分は前に作ってあったのでそれを利用したら、難なく成功した。

これをこのデータ（緯度経度）を元にQRコードの自動生成・・・
　　※この部分も以前に制作して、ライブラリ化してあったので難なく成功したが・・・

このQRコードを携帯で読み取って、携帯用地図を出そうと企んだが、Google　mapではなかなか良い方法が見つからなかったので、Map Fanの携帯地図表示機能（サービス）を利用しようとしたら、何とMap Fanは60進法ではないか　（因みにGoogle　mapは10進法です）

仕方がないので、Google　mapで得られた10進法の緯度経度情報を60進法に変換した。
　　※変換は昔？、C言語の時代に経験していたので、少し思い出しながら変換プログラムを作成。

変換自体は成功したので、これを元にMap　Fan用のQRコードを自動生成し、早速読み込んで見ると、何だか微妙にずれて表示されてしまう。
　　※10進法から60進法の変換時の誤差を考えたが、それにしても演算誤差としては大きすぎるので、少し調べて見たところ・・・
　　
　　どうやら、地図の緯度経度には世界地図系と日本地図系があり、この両者のは大凡400ｍ程度のズレがあるらしい
　　※詳しくは調べませんでしたが、Map　Fanは日本地図系を使用しているような感じです。（勿論、Googleは世界地図系です）

このズレを、数値的に補正することも考えたが、今回はやはりGoogle　Mapで得た情報はGoogle　Mapで表示した方が、今後このような事で悩まされないと考え、今回がAPIを使用したGoogle Mapで表示した。

Map Fanの動的な地図も良いかな？と思い、試みましたが、結局Google　Mapに落ち着いてしまいました。（妥協した訳ではありませんヨ）