機種依存文字

ずっぽしはまる。あー、おそろしい。お兄ちゃんに教えてもらったら「はしごだか」問題やら「たつさき」問題とやらと教えてもらう。
外部からとってきているデータが問題なのか、EUCでの出力が問題なのか順を追って洗ってみる。
まずpostgres内部に正常にデータが取れているかのチェックをする。文字データをバイトコードでとってきてまともなデータになっているかを確認する。postgresの場合文字列を直接バイトで引っ張ることは出来ない。大家の石井様のソースを頂いて対象のDBにインストールする。
http://ml.postgresql.jp/pipermail/pgsql-jp/2004-January/015488.html
のstrtohexをインストールする。インストールの備忘録は
wget ftp://ftp.sra.co.jp/pub/cmd/postgres/strtohex/strtohex-1.0.tar.gz
chown postgres:postgres strtohex-1.0.tar.gz
tar zxvf strtohex-1.0.tar.gz
make
make install
psql -e -f /usr/local/pgsql/share/contrib/strtohex.sql target_database
(postgresでインストールしている場合がほとんどだと思うけど、違う場合は一部/usr/local/pgsql/share,docなどのパーミッションをpostgresに渡す必要あり。)
でインストールは完了。
SELECT strtohex('研磨剤製品');
なんかで
strtohex

                                          • -

b8a6cbe1badec0bdc9ca
(1 row)
とか出ていたら成功。
実データでやってみる。
ごにょごにょ、、、該当のカラムはEUC文字コードを正常にとってきているようだ。

該当の文字列は8fで始まっている。JISX0212(補助漢字) 制御文字SS3(0x8f)のようだ。
http://www.tim.hi-ho.ne.jp/hebiguchi/KanjiCode/euc-jp.htm
多分文字データのバイトコードは正常に取得できているが、その先の出力と考える。

出力の原因は、EUCJP-Openとeucjp-winとの問題、もしくはCP51932によるもののようだ。
http://questionbox.jp.msn.com/qa3274023.html?StatusCheck=ON
cp51932.phpで力業で変換するも良いかと考える、が、めんどくさいけど拡張を考えてソースをUTF8に変換する方法で考える。PeggyかなんかでUTF8で保存して、charsetをUTF-8に変更する。DBから持ってきたデータをPHP
$hoge_jp_utf = mb_convert_encoding($hoge,"UTF-8","eucjp-win");
なんかする。
($hoge_jp_utf = mb_convert_encoding($hoge,"UTF-8","EUC-JP"); でもいいのかも。)

おー、直った。なんてめんどくさいんだ、日本語。
大変勉強になったなあ。(直すまでにずいぶん時間がかかったなあ。_(x_x)_)