[pgsql-jp: 25387] Re: Access2000->ODBC->Postgres7.13 接続での不具合

Hiroshi Inoue Inoue @ tpf.co.jp
2002年 3月 23日 (土) 03:43:13 JST


井上です。

> 徳家です。
>
> それはいいとして、UnicodeのDBじゃないのですか?
> よくメールを読んでいなくてコメントしてました。ごめんなさい。(^^;)
>
> # 一つのDBに指定できるServerEncodingは一つです。
> # ClientEncodingもServerEncodingとの変換が対応している
> # エンコーディングでないと利用できません。
> # よって、多か国語のDBを作る場合create databaseでエンコーディング
> # をUNICODEかMULE_INTERNALでなくてはなりません。
> # ODBCやPHPはMULE_INTERNALは対応していないので、
> # 選択肢はUNICODE(UTF-8)しかありません。
> # 日本語ODBCをUNICODEのDBに対して使いたい場合は
> # SET CLIENT_ENCODING TO 'EUC_JP';
> # である程度使えなくもないのですが、ドライバとバックエンドの変換
> # マッピングか異なるので、多少不具合がおこると予測されます。
> # このように設定して利用しているのかなと思ってました。
>
> 本題に戻ります。
> そもそものこの「データの更新ができない」という原因は、EUC_JPと
> 欧米系エンコーディングの0x80以上のコードの文字を登録し、ODBC
> でSJISとして編集しているからです。

その通りのような気はするのですが、実際にUnicodeドライバで
試してみるとウムラウトもEUC_JPのDBに格納できてしまいます。
更新してもおかしなことは何もおこらないし、徳家さんがおかしい
といわれていた0x0600~0x0dffですがたとえば0x061f~0x0628
あたりを選んでみると、ちゃんと入力できるようにみえます(こち
らは当然utf-8のDBだけですが)。どうして私の所だけ何ともない
んだろう? とりあえずホームページの方は最新に更新しておき
ました。

> ODBCでUPDATEを発行する場合primary key以外の文字列もwhereで
> 抽出条件として扱われています。この条件が文字化けした文字列になっ

正確にいうと、ODBCでなくAccessがこのようなチェックをする
わけですね。

Hiroshi Inoue




pgsql-jp メーリングリストの案内