文字化けに関するトラブルに強くなる【基礎編】：Oracleトラブル対策の基礎知識（5）（1/3 ページ）

今回は、「文字化け」に関する問題について説明します。コンピュータが扱うデータの中で文字データは最も親しみやすいものですが、歴史的な経緯や内部処理の関係から、残念ながら文字化けトラブルなどが発生することがあります。文字化けが発生したとき、オープンシステムではさまざまなソフトウェア製品が処理に介在することから、問題の切り分けに非常に時間を要し、対処が困難な場合が多いです。本稿で説明するOracle内部の文字データと文字コードの処理の方法を理解し、問題の切り分けと、一般的な問題への対処方法を理解しましょう。

Oracleにおける文字コードの扱い

文字コードとは？

　コンピュータが扱うすべてのデータは、0、１のビット列で表現されます。文字データも同様で、コンピュータで扱われるすべての文字は、その文字に対応付けられたあるビット列で表現されます。この「どの文字にどのビット列を割り当てるか？」を定めたルールが「文字コード」と呼ばれる体系です^注1 。

　現在日本で使用される文字コードにはいくつかの種類があり、文字コードによって同じ文字に割り当てられるビット列が異なります。表 1に日本で使用されている文字コードの例と、その文字コードにおいて、文字「あ」がどのビット列に対応するかをまとめています。なお、表 1では、ビット列を0、1からなる2進数表記ではなく、0、1、2.……9、A……Fからなる16進数表記で記載しています。

　日本では複数の文字コードが存在し、OSによって、主に使用される文字コードが異なります。例えば、Windows系OSではシフトJISが主に使用され、UNIX系OSでは日本語EUCやUnicodeが主に使用されています。このため、文字データをOS間でやりとりする場合、文字コードの変換が必要となってくる場合があります。

　先に記載したとおり、同じ「あ」という文字であっても文字コードごとに対応するビット列が異なりますので、ここでの文字コードの変換とは、ある文字コードでのビット列から別の文字コードのビット列への変換に相当します。

　例えば、文字「あ」をシフトJISから日本語EUCに変換する場合、ビット列 0x82A0をビット列0xA4A2に変換します。このような変換は、あらかじめ定められた変換表に基づき実行されます注2。変換表には変換対象となるすべての文字について、変換前のビットと変換後のビットの対応関係が記載されています。

　しかしながら、文字によっては、「ある文字コードには存在するが、ある文字コードには存在しない」ものもあります。例えば、Windows環境で使われるシフトJISには「(1)」という文字が存在しますが、一般的な日本語EUCには「(1)」は存在しません。

Oracleにおける文字コードの扱い

　このように、さまざまなOS間で文字データをやり取りする際には、文字コードの変換が必要となります。Oracleが対象とするシステムにも、さまざまなOSが介在するため、システムの構成によっては文字コードの変換が必要となります。この際に、文字化けなどの問題が発生するわけですが、本セクションでは、文字コードの変換の前提となるOracleにおける文字コードの扱いについて説明しましょう。

　Oracleでは、データベースが文字データを保存する際の文字コードを示す「データベースキャラクタセット」と、クライアント環境に適した文字コードを指定する「NLS_LANG」と呼ばれる2つのパラメータで、主に文字コードの扱いを決定しています。

　データベースキャラクタセットとは、データベースに格納される文字データをある特定の文字コードで一元的に保管するような仕組みです。データベースキャラクタセットは、データベースの作成時に指定します。

　文字データはデータベースではデータベースキャラクタセットで一元的に格納されますが、クライアントについては、クライアントが動作するOSごとに適した文字コードが異なることが多いため、クライアントそれぞれの環境に応じて動作用の文字コードを指定するNLS_LANGと呼ばれるパラメータを用意しています。

図1　データベースキャラクタセットとNLS_LANG

データベースキャラクタセット

　データベースには、作成時に1つのデータベースキャラクタセットを指定します。典型的な日本語環境では、データベースキャラクタセットをデータベース作成後に変更することはできません。表2に日本語環境で使用される代表的なデータベースキャラクタセットを記載します。

　データベースに、CHARデータ型、VARCHAR2型、CLOB型、LONG型の文字データを格納した場合、文字データは、そのデータベースのデータベースキャラクタセットに対応する文字コードを用いて格納されます。例えば、文字「あ」をデータベースキャラクタセットJA16SJISのデータベースに格納した場合、0x82A0として格納され、また、データベースキャラクタセットJA16EUCのデータベースに格納した場合、0xA4A2として格納されます（図2）。

図2　データベースキャラクタセットと文字コード

　データベースキャラクタセットは、以下のSQLを実行することで確認できます。

SQL> SELECT * FROM V$NLS_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';
PARAMETER                VALUE
--------------------------------------------------------
NLS_CHARACTERSET         JA16SJIS                       

　クライアント側で一般的に用いられる文字コードはシフトJIS、日本語EUCなどさまざまですが、データベース内の文字データは、データベースキャラクタセットの文字コードで一元的に格納されます。これは、Oracleでは、クライアントのNLS_LANG環境変数が適切に設定されてさえいれば、OracleクライアントとOracle Databaseの処理の中で、自動的に文字コードが変換されるためです。文字コード変換の詳細については、「文字コード変換」にて説明します。