CPI等のレンタルサーバで2系をインストールする場合、
PostgreSQLの文字コードがEUC-JPだったりするので
そのままでは郵便番号DB登録機能が使えません。
（変換マップの都合上）

そこで0xe3809c等の特殊文字をEUC-JPで利用できる物に変換してやる必要があるのですが、
とりあえず2系付属の郵便番号データが動くだけのカスタマイズをしてみました。
念のために半角カナも全角カナに直します。

data/class/pages/admin/basis/LC_Page_Admin_Basis_ZipInstall.php

106 + $search = array('〜', '−');
107 + $replace = array('〜', '-');
108 while (!feof($fp)) {

116 - $sqlval['state_kana'] = mb_convert_kana($arrCSV[3], "KV");
116 + $sqlval['state_kana'] = mb_convert_kana($arrCSV[3], "KV");
117 - $sqlval['city_kana'] = mb_convert_kana($arrCSV[4], "KV");
117 + $sqlval['city_kana'] = mb_convert_kana($arrCSV[4], "KV");
118 - $sqlval['town_kana'] = mb_convert_kana($arrCSV[5], "KV");
118 + $sqlval['town_kana'] = mb_convert_kana($arrCSV[5], "KV");
119 - $sqlval['state'] = str_replace($search, $replace, $arrCSV[6]);
119 + $sqlval['state'] = str_replace($search, $replace, $arrCSV[6]);
120 - $sqlval['city'] = str_replace($search, $replace, $arrCSV[7]);
120 + $sqlval['city'] = str_replace($search, $replace, $arrCSV[7]);
121 - $sqlval['town'] = str_replace($search, $replace, $arrCSV[8]);
121 + $sqlval['town'] = str_replace($search, $replace, $arrCSV[8]);


PostgreSQLの場合、レンタルサーバで割り振られたデータベースの文字コードが変換できないのが悪いと言えば悪いのですが。

もうちょっとMySQL使用時のパフォーマンスが上がれば素敵ですね。


ちなみにSC_DbConn内のコンストラクタ内で下記の宣言をしてやると
2系＋EUC-JP環境のPostgreSQLを使用する際もインストール時のエラーを回避できたりします。

$this->conn = $objDbConn;
+ if ($this->conn instanceof DB_pgsql) {
+ $this->conn->query("SET NAMES 'utf8'");
+ }

元ソースの表記間違えてました。
失礼しました。
正しくは下記の変更です。

116 - $sqlval['state_kana'] = $arrCSV[3];
116 + $sqlval['state_kana'] = mb_convert_kana($arrCSV[3], "KV");
117 - $sqlval['city_kana'] = $arrCSV[4];
117 + $sqlval['city_kana'] = mb_convert_kana($arrCSV[4], "KV");
118 - $sqlval['town_kana'] = $arrCSV[5];
118 + $sqlval['town_kana'] = mb_convert_kana($arrCSV[5], "KV");
119 - $sqlval['state'] = $arrCSV[6];
119 + $sqlval['state'] = str_replace($search, $replace, $arrCSV[6]);
120 - $sqlval['city'] = $arrCSV[7];
120 + $sqlval['city'] = str_replace($search, $replace, $arrCSV[7]);
121 - $sqlval['town'] = $arrCSV[8];
121 + $sqlval['town'] = str_replace($search, $replace, $arrCSV[8]);

更に追記です。

106 + $search = array('〜', '−');
エディタ次第では上記部分が下記のように表示されるかもしれません。
106 + $search = array('?', '?');

その場合は特殊文字がしっかり表示できるエディタを使用してください。

SET NAMESの話がでていたのでお借りして。

・yohgaki's blog：SET NAMESは禁止
・OpenPNE Trac：SET NAME で常にエラーが発生している
・gihyo.jp：残り一年！ PHP4からPHP5への移行

EC-CUBEではそもそもSET NAMESを使っていませんが、MySQLで使用される方は私も含め、意外とSET NAMESでなんとかしちゃってる人も多いと思います。

詳細はわかりませんが、SQLインジェクションでまずいことがあるみたい。

gihyo.jpに掲載の対策で足りるのかどうかわかりませんが、一応情報提供ということで。


追記：投稿時、変になったので編集しようとしたらいつのまにかログアウトされてしまったようで、↓の同じ投稿（ゲスト）は私です（汗）。

SET NAMESの話がでていたのでお借りして。

・yohgaki's blog：SET NAMESは禁止
・OpenPNE Trac：SET NAME で常にエラーが発生している
・gihyo.jp：残り一年！ PHP4からPHP5への移行

EC-CUBEではそもそもSET NAMESを使っていませんが、MySQLで使用される方は私も含め、意外とSET NAMESでなんとかしちゃってる人も多いと思います。

詳細はわかりませんが、SQLインジェクションでまずいことがあるみたい。

gihyo.jpに掲載の対策で足りるのかどうかわかりませんが、一応情報提供ということで。

トピ主です。

SET NAMES危なかったのですね…。
勉強になりました。

ざっとPEAR::DB読んでみたのですが、
処理を加えるとしたら/DB/pgsql.phpの292行目辺りが妥当でしょうかね。
factoryからもconnectからも呼ばれますし。

pg_set_client_encoding(UNICODE);
もしくは
pg_set_client_encoding($this->connection, UNICODE);

動作未検証です。（SET NAMES部分は削除で）

/DB/mysql.phpでも同じような箇所に処理追加すればOKかな。


PEARライブラリはあんまり書き換えたくないですが、ExtendしてないしPEAR::DB使ってるのでしょうがないかな…と？