韓国サーバからExcelマクロでデータを取得し集計するシステムで
現状韓国OS,Officeの端末で正常に稼動しているものを
日本語OS、Office(Excel)の端末でも使用できるようにしたいのですが、
ハングル文字が文字化けしてしまいます。
韓国、日本両端末で同じように表示できるようにしたいのですが、
何か方法はないでしょうか。
ちなみに韓国サーバはORACLE8です。システム使用端末韓国日本ともOSはXPです。
マクロでのデータの取得はレコードセットで取得しています。
NLS環境における文字コードの整合性って、非常に厄介なんですよね。
Oracleのサポートに相談された方が良いと思いますよ。
(私自身も、それほど詳しいわけではありませんし…)
とりあえず、逆質問。
・現状のデータベース側のNLS_CHARACTERSETとNLS_NCHAR_CHARACTERSETは何ですか?
・クライアント側のNLS_LANGは、サーバの設定にあわせてありますか?
・文字列は、VARCHAR2に格納する予定ですか? それとも、NVARCHAR2ですか?
> 韓国、日本両端末で同じように表示できるようにしたいのですが、
> 何か方法はないでしょうか。
・Unicode対応フォント(Arial Unicode MS等)を用意する。
・Oracle側は、Unicode系の文字セットを選択する。
・クライアント側の文字コード設定を、サーバの設定に一致させる。
・SJIS変換を伴うような処理(StrConv関数のvbFromUnicodeなど)を使用しない。
などといった条件を整える必要があると思われます。
Oracle側の文字コード設定に付いては、AL32UTF8にする事が多いようですが、
AL32UTF8は9.0.1からですから…Oracel8/8iだと、UTF8でしょうか。
この場合、Unicodeのバージョンは2.1相当になるかと思います。
なお、UTF-8データベースを作成する場合、ミドルウェア側の対応も
必要になりますので、その点は注意が必要です。
たとえば、OS標準の文字セット(日本語なら、JA16SJISですかね)以外には
対応していないツールというのは少なくありませんし、また、最近のADOやODBCでは、
CHAR型列の扱いに制限が出てくるなどの弊害もあります。
http://support.microsoft.com/?kbid=415093
もし、Oracle側の文字コードの変更を行わずに済ませるなら、全ての文字列を、
個別にURIエンコードして格納しておく……という力技もあります。
(データ量は多くなりますし、デコードの手間もかかりますけれどね)
>(私自身も、それほど詳しいわけではありませんし…)
知っている範囲で教えていただければ幸いです。
色々聞いてしまいますが、すみません。
> とりあえず、逆質問。
> ・現状のデータベース側のNLS_CHARACTERSETとNLS_NCHAR_CHARACTERSETは何ですか?
実際のサーバーはNLS_CHARACTERSETがKO16KSC5601、NLS_NCHAR_CHARACTERSETが
KO16KSC5601です。
また、検証用にうちの8iでNLS_CHARACTERSETがUTF8、NLS_NCHAR_CHARACTERSETが
UTF8のデータベースで試してみたのですがうまくいっていません。
(この検証データベースではACCESSのリンク、インポートでちゃんとハングルの値がとれています)
> ・クライアント側のNLS_LANGは、サーバの設定にあわせてありますか?
会社(日本)で自端末(Windows2000)、上記検証用サーバ(Oracle8i)でテストしてみているのですが、
設定の方法があっているかわかりませんが、(そんなに詳しくないので思いつく方法で)
[コントロールパネル]-[システム]-[詳細]-[環境変数]-[システム環境変数]で、
NLS_LANG=JAPANESE_JAPAN_UTF8を設定したり
レジストリのHKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0のNLS_LANGに
直接JAPANESE_JAPAN_UTF8を入力したりしてみました。
また、[コントロールパネル]-[地域のオプション]-[全般]の“システムの言語設定”で
“韓国語”のチェックがオンにしました。
あと、[スタート]-[プログラム]-[Microsoft Office ツール]-[Microsoft Office 言語設定]にも
使用できる言語に韓国語を追加しています。
> ・文字列は、VARCHAR2に格納する予定ですか? それとも、NVARCHAR2ですか?
VARCHAR2もしくはCHARになっていると思います。
>> 韓国、日本両端末で同じように表示できるようにしたいのですが、
>> 何か方法はないでしょうか。
>・Unicode対応フォント(Arial Unicode MS等)を用意する。
>・Oracle側は、Unicode系の文字セットを選択する。
>・クライアント側の文字コード設定を、サーバの設定に一致させる。
>・SJIS変換を伴うような処理(StrConv関数のvbFromUnicodeなど)を使用しない。
>などといった条件を整える必要があると思われます。
一応テスト環境で前述しているフォントにArial Unicode MSを追加して、
実施してみたのですがうまくいっていません。(StrConvは使用していません)
>なお、UTF-8データベースを作成する場合、ミドルウェア側の対応も
>必要になりますので、その点は注意が必要です。
ミドルウェアはExcelにあたるのでしょうか…。例えばどんな設定が必要になりますか。
# 長文の割に、あまり回答になっていないかも。(;_;)
> 知っている範囲で教えていただければ幸いです。
私が経験した多言語対応は、クライアントサーバシステムではなく、
Webアプリケーションにおける物でしたから、お役に立てないかも知れません。
当方の場合は9iでしたので、Oracleのバージョンも違いますし。
今回の問題は、VB側のコーディングでどうにかできる内容ではなく、
Oracle側の環境設定等が重要になってくるでしょうから、VB系の
コミュニティよりも、OTN等のOracle系のコミュニティで質問された方が、
より専門的な回答を得られるのでは無いでしょうか。
(個人的には、サポートセンターに問い合わせる事をお奨めします)
なお、Oracle9iの場合は、マニュアルの一つに
『Oracle9i Database グローバリゼーション・サポート』
という物があり、そこに、多言語対応に関する資料がありました。
Oracle8にも、同等のマニュアルが無いか、探してみてください。
> 色々聞いてしまいますが、すみません。
私自身も、Oracleにおける多言語対応には非常に興味があるので、
この問題はとても気になります。(^^;)
まずは、「どうすれば文字化けしないか」を考える前に
「何故文字化けしているのか」を付き止めないといけませんね。
http://otn.oracle.co.jp/software/tech/java/jdbc/nlsalart/nlsalart.html
Oracleにおける文字化けと言うと、大きく分けて
・サーバ内で、DBへの格納時に化けている。
・クライアントとサーバ間の通信時に、文字コード変換に失敗している。
・通信は化けていないが、表示時に化けている。
などがあるようです。
正しくDBに格納されているかどうかは、SQL*PLUSから
SELECT DUMP(STAFF_NAME) FROM STAFFLIST
を実行する事で判定できると思います。
NLS_CHARACTERSET が KO16KSC5601 の時と UTF8 の時とで、それぞれ
正しいバイナリが格納されているかを確認してください。
通信時の問題は、少々厄介かと思います。NLS_LANGの設定が正しかったとしても、
開発言語やミドルウェアが未対応という事も多いですから…。
まずは、SQL文が、DB側の設定と同じキャラクタセット(またはUnicode)にて
送信可能かどうかの判断が必要になるかと思います。さしあたっては、
ハングルを含んだSQL文を送信可能か、また、正しく抽出/編集されるかどうかを
試してみてください。
で、最後の、表示時に化けるかどうかについてですが、これに関しては、
Excel 2000以上であれば、Unicode文字を表示できるはずですので、
フォントさえ用意しておけば、どうにかなると思います。
(VB6等だと、ほとんどのコントロールがUnicode非対応なので、大変ですけど)
> (この検証データベースではACCESSのリンク、インポートでちゃんとハングルの値がとれています)
あらま。AccessでOKだった、という話は良く聞くのですが、私の環境では
どうしても文字が化けてしまうので、ちょっと羨ましいです。(^^;)
# mdb自身の[照合順序設定]も変えないといけなかったのかな…?
参考までにお聞きしたいのですが、リンクテーブルという事は、
すなわち「ODBC接続」という事になりますよね。
そのODBCドライバというのは、何を使っておられるのでしょうか。
MERANT(INTERSOLV)の物ですか? Oracle標準? それともMicrosoft製?
> 一応テスト環境で前述しているフォントにArial Unicode MSを追加して、
> 実施してみたのですがうまくいっていません。(StrConvは使用していません)
Accessで表示できるという事は、Unicode対応フォントもインストール済みですね。
そうすると、別の部分に問題があるのでしょう。(何が原因かはわかりませんが…)
> NLS_LANG=JAPANESE_JAPAN_UTF8を設定したり
NLS_LANG変数は、「(クライアント言語)_(地域).(文字セット)」となります。
つまり、『JAPANESE_JAPAN_UTF8』ではなく、『Japanese_Japan.UTF8』かと思います。
ただし、これを設定すると、データがUTF8でやりとりされる事になりますので、
文字コード切り替えに対応していないツールだと、画面表示が化けてしまうかも知れません。
> レジストリのHKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0のNLS_LANGに
関係あるかどうかはわかりませんが、
http://www.magicsoftware.co.jp/mginfo/library/userlib/v8/o8reg100.htm
を見ると、8と8iでも、レジストリ位置に差があったりするのかも知れません。
> VARCHAR2もしくはCHARになっていると思います。
CHAR型があったとすると、ちょっと面倒ですね。先の回答にも少し書きましたが、
UTF8にすると、Recordset.Fields(x).Value による編集ができなくなる可能性が
あります。(なお、KO16KSC5601だった場合についてはわかりません…)
> ミドルウェアはExcelにあたるのでしょうか…。
ExcelとOracle間の接続ミドルウェアは何ですか?
レコードセットで取得しているとの事でしたから、oo4oやRDOでは無く、
ADOかDAOによる接続だと思いますが、それらに限ってみたとしても、
細かくみると、さらにいろいろな形態が存在しますよね。
・ODBCDirect + MS製Oracle ODBCドライバ
・DAO 3.6 + Jetリンクテーブル + MERANT製Oracle 8 ODBCドライバ
・ADO 2.8 + Jetリンクテーブル + Oracle製ODBCドライバ + Microsoft Jet 4.0 OLE DB Provider
・ADO 2.8 + Microsoft OLEDB Provider for Oracle
・ADO 2.8 + Oracle Provider for OLE DB
など…。
> 例えばどんな設定が必要になりますか。
ODBCドライバ(あるいはOLE DBプロバイダ)によって、設定も異なるようです。
文字コード設定ができるか部分については不明ですが、接続文字列等でパラメータを
指定する物もあれば、レジストリや環境変数の設定が必要がある物など、いろいろな設定が
個々の設定に付いての細かい事はわかりませんが、場合によっては、
TO_NCHAR関数を使うなどの対応が必要かも知れません。
連絡が遅くなってしまいすみません。
> Oracleにおける文字化けと言うと、大きく分けて
> ・サーバ内で、DBへの格納時に化けている。
> ・クライアントとサーバ間の通信時に、文字コード変換に失敗している。
> ・通信は化けていないが、表示時に化けている。
> などがあるようです。
クライアントとサーバ間の通信時に、文字コード変換に失敗しているのだと思います。
試しに、既出のハングル文字をメッセージボックスに表示するプログラムで、
取得したハングル文字(文字化けしているもの)をメッセージボックスで出せるか
やってみたのですが、「？？」となっていました。
> 通信時の問題は、少々厄介かと思います。NLS_LANGの設定が正しかったとしても、
> 開発言語やミドルウェアが未対応という事も多いですから…。
Accessで見れるあたり、NLS_LANGの設定は問題ないのかもしれませんね…。
> 参考までにお聞きしたいのですが、リンクテーブルという事は、
> すなわち「ODBC接続」という事になりますよね。
> そのODBCドライバというのは、何を使っておられるのでしょうか。
> MERANT(INTERSOLV)の物ですか? Oracle標準? それともMicrosoft製?
Oracle標準だと思います。「Oracle ODBC Driver」という方で、「Microsoft ODBC for Oracle」
だとやはり文字化けするようです。
> ExcelとOracle間の接続ミドルウェアは何ですか?
既存システムではoo4oです。Adoでもやってみたのですがだめでした。
RDO, DAOはやり方がわからなくて試していないのですが…。