ここから本文です

EXPORT/IMPORT時のキャラクター設定について 初歩的な質問ですが宜しくおねがい...

bef********さん

2014/11/1711:07:18

EXPORT/IMPORT時のキャラクター設定について

初歩的な質問ですが宜しくおねがいします。

教えて頂きたいのは、同一サーバー上でEPORT/IMPORTをする時にOSのNLS_LANGと
DBインスタンスのNLS_CHARACTERSETを合わせないと文字化けするのか?

EXPORTしようとしているサーバーのOSはAIX。
NLS_LANGで確認したら

$ echo $NLS_LANG
Japanese_Japan.JA16SJIS

EXPORTしようとするORACLEのインスタンスのNLS_CHARACTERSETを確認すると
「AL32UTF8」となっています。
SQL>select * from nls_database_parameters where parameter='NLS_CHARACTERSET';


EXPORT/IMPORTをする時に、OS側のNLS_LANGを「Japanese_Japan.AL32UTF8」に変更する必要はあるのでしょうか?

やろうとしていることは、同じサーバー上でEXPORT→TRUNCATE→IMPORTをしようと思っています。


ご存知の方、どうか教えてください。

宜しくお願いします。

OS:AIX
DB:Oracle11gR2

閲覧数:
12,465
回答数:
2
お礼:
25枚

違反報告

ベストアンサーに選ばれた回答

sun********さん

2014/11/2501:17:03

文字化けは端末に対する文字化けと、データ自体の文字化けの2種類があることにご注意ください。

NLS_LANG環境変数は端末に対する環境設定です。
これは端末のキャラクターセットに合わないと、表示上文字化けします。
例えばTeratermがSJISに設定されている場合はNLS_LANGをSJISにしないと
メッセージが全て文字化けしますが、逆にTeratermの設定がUTF-8の設定に
なっている場合はNLS_LANGがUTF-8でないとメッセージが文字化けします。
(但しこれは主に表示上だけの問題です)

データベースのキャラクターセットとNLS_LANGのキャラクターセットが
異なる場合はキャラクターセットの変換が発生します。
同じであれば変換しません。

EXPORTでダンプされるデータ、及びログや標準出力されるメッセージは
NLS_LANG環境変数の影響を受けます。
端末がSJISで、NLS_LANGもSJISなら見た目上の文字化けは発生しませんが、
もしデータにSJISにはなくUTF-8にしかコードがない文字を含んでいる場合は
データの文字化けが発生してのデータ損失が発生します。
※よく問題になる"~"(Wave Dash文字)など

端末がSJISで、NLS_LANGがUTF-8ならログやメッセージは文字化けしますが、
データは文字コードが変換されないので、データの文字化けは発生しません。

よってUTF-8に対応した端末(UTF-8に端末設定したTeratermなど)から
NLS_LANGをJapanese_Japan.AL32UTF8 に設定して実行するのが
ベストな方法と言えるかと思います。

リモートアクセスができずDBサーバに直接ログインしないと作業できない、
かつ、AIXにUTF-8を表示できる機能がない場合はNLS_LANGをUTF-8に
設定して表示上の文字化けを無視し、正否はEXPORTのログをWindows機
等にダウンロードして確認する、という手もあります。

UTF-8←→SJISに相互変換可能な文字しかないことが確かなのであれば、
どちらでもOKです。
画面が文字化けしない方を設定すればよいと思います。

この回答は投票によってベストアンサーに選ばれました!

ベストアンサー以外の回答

1〜1件/1件中

kok********さん

編集あり2014/11/1722:01:04

オラクルでは、キャラクタセットは自動変換するとなっています。
しかし、実際、utfにデータ変換一度してから、キャラクタセットを変換するとなっています。例えば、eucのデータベース→クライアントのキャラクタセットもeuc→インポート先sjisという流れだと、実は、utfに一度変換しています。

なので、オラクルでは、データベースキャラクタセットはutfがいい(実際、世界標準)と言います。文字化けが起こりやすいのは、①など日本語特有文字です。これは、utfが対応していない。
なので、データベースキャラクタセットに日本語ではsjisを選択することが多くなるのです。
よく、exportする際、インポートするデータベースキャラクタセットに合わせる(クライアント文字コードを)。

また、全て同じ文字コードにする(オラクルはsjisからsjisにインポートする際は、utfに変換せず、無変換と言っています)。

上記を考慮しても、文字化けが出る場合、未熟だったとあきらめて、顧客に謝る等考えるしかありません。
文字コードは、データベース技術者は神経使って、システムの仕様を決める際、最もナーバスになるものの1つです。その段階の見落としは、致命的です。
僕は、そう思ってやっています。
これを機会に、あなたの失敗でなくても、文字コードにまつわる情報世界の歴史を紐解いて勉強するのをお勧めします。今後に、きっと、役立つでしょう。

質問に対してですが、データベースキャラクタセットutf→クライアントsjisなので、キャラクタセット変換が発生し、変換出来なかったものが、文字化けします(場合によっては、中のデータ次第では変換全てokもあるんですよ)。
なので、クライアント文字コードは、utfにすれば、無変換ですので、自分に入れ直すならば問題ありえません。

トラケートの問題ではありません。ですよね(トラケートしても文字化けします)。

あわせて知りたい

この質問につけられたタグ

みんなで作る知恵袋 悩みや疑問、なんでも気軽にきいちゃおう!

Q&Aをキーワードで検索:

Yahoo! JAPANは、回答に記載された内容の信ぴょう性、正確性を保証しておりません。
お客様自身の責任と判断で、ご利用ください。
本文はここまでです このページの先頭へ

「追加する」ボタンを押してください。

閉じる

※知恵コレクションに追加された質問は選択されたID/ニックネームのMy知恵袋で確認できます。

不適切な投稿でないことを報告しました。

閉じる