http://pop-club.hp.infoseek.co.jp/unix/postgres_utf.html
PostgreSQL & Utf-8
消えてしまう文字とは、UNICODEにはあるけどShiftJISにはない文字のことでしょう。便宜的にUNICODE依存文字とでも呼びましょう。
まずCSVの中で、ほんとうにUNICODE依存文字が使われているのかどうかです。Excelで保存したCSVデータは、バージョンによってはShiftJISでしか保存されませんから、CSVの段階で既にUNICODE依存文字が”?”に置換されている場合があります。
CSVの段階でもUNICODE依存文字が表示できているなら、PostgreSQLをUTF-8に対応させればよいのではないでしょうか?
外字は個々のPC環境に依存する話ですから、個別に対応しなくてはならないでしょう。
UNICODEとShiftJISの話がでていますが、
もとのCSVの文字コードがShiftJISと仮定してお話させて頂きます。
高島屋の高(はしご高)はShiftJIS環境でも扱われます。
ただし、IBM拡張文字として扱われていると思います。
このため、PostgreSQL及びDBへのデータプロバイダ(ODBCドライバとかOLEDBプロバイダとか)がIBM拡張文字に対応している必要があるのではないかと思います。
バージョン的にPostgreSQLが未対応ならどうにもなりませんが、ODBCドライバとかの問題なら、ドライバのバージョンアップで改善できるかもしれません。
何れにせよ、未対応の文字がある場合は何らかの規則を決めて、DBに渡す前に空白なら空白に変換してしまうほうがいいかもしれません。
IBM拡張文字を始め、ShiftJISの第二表領域にあるもの、第一表領域のものでも、JIS0208相当で未定義になっている区点に割り当てられた文字などは注意が必要です。
いずれにせよと言うことで、高島屋だけ取りあえず修正して一時的な対処であとで考えることにしました。
取りあえずはCSVでUTF-8(BOM要らないのに注意、秀丸とかMiFESはできるが、TERAPADはBOMのはずしかたが不明)で元データだけはなんとかですね。
ODBCドライバといっても、POSTGRESのコマンドの問題?なのかあれですね。
データもらうときの注意事項と言っても作ってくれる側が(既にあるDB)できなきゃどうしようもないかも、、、
> PGではmb_convert_encodeing($p,”UTF8”,”SJIS”)かけてます。
CSVが既にUTF-8でencoding されているなら、mb_convert_encodeingは不要だったりしませんか?そういう意味ではないのかな?
うみ、SJIS(でみせてるから変換なんですが、明日やってみますね。)社内の作りが悪いので、こちらがUTFでやると、他のサイトが化ける数が多いので、、、
ただ、DB作り直しは、Debug機でやってみます。明日から社内利用開始なもので、、、
5/11 13:00 に公開しましたが、 Debug環境の構築手間取り時間がかかるのでいったん終了します。
ありがとうございました。
UTF-8対応でCSVを作り直してその中では文字がなくなるのは消えましたが、DBをUTF-8形式のBOMをはずして保存しCOPYコマンドはできました。ただ、やっぱり、高島屋の高が出てきません。CSVのほうは残ってるんですが?
PGではmb_convert_encodeing($p,”UTF8”,”SJIS”)かけてます。