スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Unicode

最近は、日本語(厳密には、SJISやEUC等のコード体系で定義されていない文字)以外の言語、例えば中国語や韓国語の文字を扱いたいという話が結構あるんじゃないでしょうか。

僕のところでも、DB(Oracle)に中国語や韓国語等の多言語データを格納する必要が出てきました。


ちなみに、DBキャラクタセットは、以下のようになっています。
・CHARACTER SET : JA16EUC
・NATIONAL CHARACTER SET : AL16UTF16

ざっくり言えば、「CHARACTER SET」はCHAR/VARCHAR2型の文字コード、
「NATIONAL CHARACTER SET」はNCHAR/NVARCHAR2型の文字コードですね。


多言語データを格納する場合、以下の2案が考えられます。
1. CHARACTER SETを『AL32UTF8』にして、DBを再作成する。
2. 多言語データを格納するカラムをNCHAR/NVARCHAR2型で定義する。

Javaや.Netのプログラム内では、Unicodeで処理されていますし、(古いバージョンでなければ)JDBCやODP.netでは、NCHAR/NVARCHAR2型を扱うメソッドがあります。

CHAR/VARCHAR2型で統一できる案1もアリかなと思いましたが、古いバージョンのドライバを利用しているアプリが存在する可能性もありますし、検証のために十分な時間を割くことができないので、DB側の既存の構成は変更しないという方針で、案2で行くことに決めました。

DBがそれなりに大きいと、再作成のための時間を確保しないといけないですし。。
それはつまり、DBを利用できない時間を許容してもらわないといけないわけですし。。
という事情もなくはないです。


UTF8(BOM付き・なし両方とも可)やUTF16(ビッグエンディアン・リトルエンディアン両方とも可)のファイルをロードしたい場合、SQL*Loaderの制御ファイルに
・CHARACTERSET AL32UTF8
・CHARACTERSET UTF16
と記述すればロードできます。

その際、DBが
・CHAR/VARCHAR2型 : DBの「CHARACTER SET」
・NCHAR/NVARCHAR2型 : DBの「NATIONAL CHARACTER SET」
へ自動的に変換してくれます。

もちろん、「CHARACTER SET」で定義されていない文字をCHAR/VARCHAR2型のカラムにロードすると、文字化けしちゃいます。


あと、UTL_FILEパッケージの「FOPEN_NCHAR」「PUT_LINE_NCHAR」プロシージャを利用すれば、UTF8でファイル出力が可能です。
アプリを介さず、PL/SQL等でテーブル上の多言語データを高速に出力したい場合には、利用できると思います。
関連記事
スポンサーサイト

この記事へのコメント

トラックバック

URL :

プロフィール

あんま覚えてへんわ


「あんま覚えてへんわ」です。

最新記事
最新コメント
月別アーカイブ
カテゴリ

openclose

カレンダー
06 | 2017/07 | 08
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 - - - - -
ブログ内検索

アクセス数
アクセスランキング
[ジャンルランキング]
日記
9237位
アクセスランキングを見る>>

[サブジャンルランキング]
会社員・OL
1737位
アクセスランキングを見る>>

天気予報
QRコード
QR
RSSリンクの表示
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。