ロケールとは、特定の言語と国に対する言語上の条件と文化的条件に対処するための一連の情報です。従来より、ロケールに関するデータは、日付、時刻、数字、通貨などの書式や解析に対応しています。最新の正しいロケール・データを提供することは、これまで各プラットフォームの所有者またはベンダーの責任であったため、ロケール・データの不整合や誤りが発生していました。

Oracleソフトウェアに対するロケールの動作を指定するには、NLS_LANG環境パラメータを設定するのがもっとも簡単な方法です。このパラメータは、クライアントのアプリケーションとデータベース・サーバーで使用される言語と地域を設定します。また、クライアント・プログラムによって入力または表示されるデータのキャラクタ・セットに相当する、クライアント'のキャラクタ・セットも指定します。

NLS_LANGは、UNIXプラットフォームではローカル環境変数として設定されます。Windowsプラットフォームではレジストリ内に設定されます。

NLS_LANG パラメータは、言語、領域、文字セットの3つのコンポーネントから構成されます。句読点を含め、以下のフォーマットで指定します。
NLS_LANG = language_territory.charset

NLS_LANGパラメータの各コンポーネントは、次のとおり、グローバリゼーション・サポート機能のサブセットの処理を制御します。

language（言語）
Oracleメッセージ、ソート、曜日の名前、月の名前に使用される言語などの表記規則を指定します。サポートされる各言語には、一意の名前（AMERICAN、FRENCH、GERMANなど）が付いています。language引数は、territory引数およびcharset引数のデフォルト値を指定します。languageが指定されていない場合は、デフォルトでAMERICANに設定されます。

territory（地域）
デフォルトの日付、通貨、数値書式などの表記規則を指定します。サポートされる各地域には、一意の名前（AMERICA、FRANCE、CANADAなど）が付いています。territoryが指定されていない場合は、languageの値から導出されます。

charset（キャラクタ・セット）
クライアント・アプリケーションで使用されるキャラクタ・セット（通常は、ユーザー'の端末のキャラクタ・セットまたはOSのキャラクタ・セットに対応するOracleのキャラクタ・セット）を指定します。サポートされている各キャラクタ・セットには、一意の頭字語（US7ASCII、WE8ISO8859P1、WE8DEC、WE8MSWIN1252、JA16EUCなど）が付いています。各言語には、その言語に関連付けられたデフォルトのキャラクタ・セットがあります。

注：

NLS_LANGコンポーネントの定義はすべて任意です。指定されなかった項目にはデフォルト値が使用されます。地域またはキャラクタ・セットを指定する場合は、デリミタとして地域の直前にアンダースコア（_）を、キャラクタ・セットの直前にピリオド（.）を含める必要があります。デリミタを付けないと、その値は言語名と解釈されます。

たとえば、NLS_LANGの地域の部分のみを設定するには、次の形式を使用します。 NLS_LANG=_JAPAN

本書の残りの部分では、NLS_LANG設定のcharsetコンポーネントに焦点を当てています。charsetコンポーネントは正しく設定することが非常に重要であるにもかかわらず、正しく理解されていないためです。

• NLS_LANGをデータベースのキャラクタ・セットに設定することは、適切な場合もありますが、必ずしも適切であるとは限りません。NLS_LANGをデータベースのキャラクタ・セットと同じにする必要があるとは考えないようにしてください。多くの場合、これは正しくありません。
• NLS_LANGパラメータで定義したキャラクタ・セットは、クライアント'のキャラクタ・セットを変更しません。これは、どのキャラクタ・セットがクライアント側で使用されているかをOracleに知らせることによって、正しい変換が行われるようにするためのものです。異なるNLS_LANGを使用することで、クライアントのキャラクタ・セットを変更することはできません。
• クライアントでNLS_LANGを設定しない'場合はサーバーのNLS_LANGが使用されるという理解も間違いです。これもまた正しくありません。たとえば、OracleインストーラによってNLS_LANGに値が入力されなかった場合、またはNLS_LANGが設定されなかった場合、値はデフォルトでAMERICAN_AMERICA.US7ASCIIになります。言語はAMERICAN、地域はAMERICA、キャラクタ・セットはUS7ASCIIです。
• NLS_LANGのlanguageパラメータとterritoryパラメータの設定は、データベースに文字を格納できるかどうかには一切関係ありません。NLS_LANGをJAPANESE_JAPAN.WE8MSWIN1252に設定しても、日本語を格納できません。WE8MSWIN1252が日本語の文字をサポート'していないためです。ただし、NLS_LANGをAMERICAN_AMERICA.JA16SJISに設定すると、入力データが本当にJA16SJISであり、データベースが日本語を格納できるキャラクタ・セットの場合（UTF8、JA16SJISなど）、日本語を格納できます。

多くの場合、NLS_LANGはOracleのインストール時、またはそれ以降に手動で設定されます。値を確認するには、以下の方法を使用してSQL*PlusでNLS_LANG値を取得します。

UNIXの場合：

パラメータの値が返されます。

Windowsの場合:
Windowsでは2つの選択肢があります。NLS_LANGは通常はレジストリに設定されますが、まれに環境に設定される場合もあります。環境に設定された値は、レジストリに設定された値よりも優先され、サーバー上のすべてのOracle_Homesで使用されます。また、ユーザー環境変数が設定されている場合、すべてのシステム環境変数よりも優先されます（これはWindowsの動作であり、Oracleとは何ら関係がありません）。

NLS_LANGが環境で設定されているかどうかを'確認するには、以下を実行します。

%NLS_LANG%が返された場合、環境ではNLS_LANGは設定されていません。

設定されている場合は、次のような値が返されます。

ENGLISH_UNITED KINGDOM.WE8ISO8859P1
NLS_LANGが環境で設定されていない場合は、次のようにレジストリの値を確認します。

次のような値が返された場合：
Unable to open file.[ENGLISH_UNITED KINGDOM.WE8ISO8859P1]。
括弧内の"ファイル名"がレジストリ・パラメータの値です。

次のような値が返された場合：
Unable to open file ".[%NLS_LANG%]."、NLS_LANGパラメータはレジストリにも設定されていません。

@.[%NLS_LANG%].は、SQL*Plus実行可能ファイルが認識しているNLS_LANGを返します。レジストリそのものを読み取っているわけではありません。ただし、HOSTコマンドを最初に実行しており、NLS_LANGが環境に設定さていない場合、@.[%NLS_LANG%].が有効な値を返せば、この変数がレジストリに設定されていることを確認できます。

その他のNLSパラメータはすべて、以下の構文で取得できます。

注：

SELECT USERENV ('language') FROM DUAL; は、セッションの<Language>_<territory>を提供しますが、これはクライアントのキャラクタ・セットではなくデータベースのキャラクタ・セットであるため、返された値はクライアントの完全なNLS_LANG設定ではありません。

このセクションでは、NLSパラメータがデータベースのクライアント/サーバー・モデル内で考慮される順序について説明します（ここでは、Thin JDBC接続については取り扱いません）。

NLSパラメータは、データベース、インスタンス、セッションという3つのレベルで設定できます。パラメータが複数のレベルで定義されている場合、どのレベルが優先されるかは次のように非常に明瞭です。

1. 1. NLSインスタンス設定は、NLSデータベース設定よりも優先されます
2. 2. NLSセッション設定は、NLSデータベース設定とNLSインスタンス設定よりも優先されます

これは、現在のSQLセッションで使用される設定です。

以下が（この順序で）反映されます。

1. 1）"ALTER SESSION'によって設定されたNLSパラメータの値ALTER SESSION set NLS_DATE_FORMAT = 'DD/MM/YYYY"
   
2. 2）明示的な"ALTER SESSION"文が実行されていない場合、NLS_LANG変数から導出されたクライアントの該当NLSパラメータの設定が反映されます。
3. 3）NLS_LANGが一部のみ指定されている場合、AMERICANがデフォルトで使用されます。

   したがって、NLS_LANG=_BELGIUM.WE8MSWIN1252と設定すると、以下のように表示されます。

   パラメータ値

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY BELGIUM
   NLS_CURRENCY <ここにユーロのマーク>
   NLS_ISO_CURRENCY BELGIUM

   注：

   NLS_LANG=_BELGIUM.WE8MSWIN1252（正）と

   NLS_LANG=BELGIUM.WE8MSWIN1252（誤）の違いは、後者にはセパレータとして"_"を設定しなければならない点です。

4. 4）NLS_LANGが一部のみ指定されている場合、デフォルトで設定されます。

   したがって、NLS_LANG=ITALIAN_.WE8MSWIN1252と設定すると、以下のように表示されます。

   パラメータ値

   NLS_LANGUAGE ITALIAN
   NLS_TERRITORY ITALY
   NLS_CURRENCY <ここにユーロのマーク>>
   NLS_ISO_CURRENCY ITALY

   注：

   NLS_LANG=ITALIAN_.WE8MSWIN1252（正）と

   NLS_LANG=ITALIAN.WE8MSWIN1252（誤）の違いは、後者にはセパレータとして"_"を設定しなければならない点です。

5. 5）NLS_LANGが_の部分なしで指定されている場合、_の部分はデフォルトでAMERICAN_AMERICAになります。

   したがって、NLS_LANG=.WE8MSWIN1252と設定すると、以下のように表示されます。

   パラメータ値

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY AMERICA

   
   
   
   Note:
   
   The difference between NLS_LANG=.WE8MSWIN1252 (correct) and
   
   NLS_LANG=WE8MSWIN1252 (incorrect), you need to set the "." as separator.
   

6. 6）NLS_LANGが（3、4、または5のように）設定されている場合、

   NLS_SORT、NLS_DATE_FORMATなどのパラメータは、"スタンドアロン"設定として設定でき、NLS_LANGの_の部分から導出されたデフォルトよりも優先されます。

   したがって、NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252およびNLS_ISO_CURRENCY=FRANCEと設定すると、以下のように表示されます。

   パラメータ値

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY FRANCE

   デフォルト:
   * NLS_DATE_LANGUAGEまたはNLS_SORTが設定されていない場合は、
   NLS_LANGUAGEから導出されます。
   * NLS_CURRENCY、NLS_DUAL_CURRENCY、NLS_ISO_CURRENCY、NLS_DATE_FORMAT、NLS_TIMESTAMP_FORMAT、NLS_TIMESTAMP_TZ_FORMATが設定されていない場合、NLS_NUMERIC_CHARACTERSはNLS_TERRITORYから導出されます。

7. 7）NLS_LANGが全く設定されていない場合、デフォルトで

   <Language>_<Territory>.US7ASCIIとなります。
   <Language>_<Territoryの部分に使用される値は、

   NLS_INSTANCE_PARAMETERSで使用されている値です。クライアント側で"スタンドアロン"として定義されたNLS_SORTなどのパラメータは無効になります。

   
   
   Note:
   
   * If set, client parameters (NLS_SESSION_PARAMETERS) always take precedence over NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS.
   
   * This behavior cannot be disabled on/from the server, so a parameter set on the client always has precedence above an instance or database parameter.
   
   * NLS_LANG cannot be changed by ALTER SESSION, NLS_LANGUAGE and NLS_TERRITORY can. However NLS_LANGUAGE and /or NLS_TERRITORY cannot be set as "standalone" parameters in the environment or registry on the client.
   
   * NLS_SESSION_PARAMETERS is NOT visible for other sessions. If you need to trace this then you have to use a logon trigger to create your own logging table (based on session parameters)
   
   * The <clients characterset> part of NLS_LANG is NOT shown in any system table or view.
   
   * On Windows you have two possible options, normally the NLS_LANG is set in the registry, but it can also be set in the environment, however this is not often done and generally not recommended to do so. The value in the environment takes precedence over the value in the registry and is used for ALL Oracle_Homes on the server if defined as a system environment variable.
   
   * NLS_LANGUAGE in the session parameters also declares the language for the client error messages.
   
   * You cannot "set" a NLS parameter in an SQL script; you need to use ALTER SESSION.
   

これは、データベース起動時におけるデータベースのinit.ora内の設定、またはALTER SYSTEMによる設定です。

パラメータがinit.oraで明示的に指定されていない場合、またはALTER SYSTEMで定義されていない場合、その値は"上位の"パラメータからは導出されません（これは、NLS_SESSION_PARAMETERSのNLS_LANGUAGEからデフォルトが導出されるNLS_SORTなどのパラメータの場合であり、NLS_INSTANCE_PARAMETERSには当てはまりません）。

Note:

* NLS_LANG is not an init.ora parameter; NLS_LANGUAGE and NLS_TERRITORY are so you need to set NLS_LANGUAGE and NLS_TERRITORY separately.

* You cannot define the  or NLS_LANG in the init.ora

The client characterset is defined by the NLS_LANG on the client OS (see above).

* You cannot define the database characterset in the init.ora. The database characterset is defined by the "Create Database" command.

* These settings take precedence above the NLS_DATABASE_PARAMETERS.

* These values are used for the NLS_SESSION_PARAMETERS if the client the

NLS_LANG is NOT set.

* Oracle strongly recommends that you set the NLS_LANG on the client at least to

NLS_LANG=.<clients characterset>

* The NLS_LANGUAGE in the instance parameters also declares the language for the server error messages in alert.log and in trace files.

データベースの作成時に、init.oraでパラメータが明示的に設定されていない場合は、デフォルトでAMERICAN_AMERICAになります。データベースの作成時に、init.oraでパラメータが設定されている場合は、その値が表示されます。データベースの作成後にこれらを変更することはできません。これらの設定を無視するためにシステム表を更新しようとしないでください。これらの設定は、インスタンス・パラメータとセッション・パラメータが設定されていない場合に、データベースのデフォルト値を設定するために使用されます。

注：

* NLS_LANGはinit.oraのパラメータではありませんが、NLS_LANGUAGEとNLS_TERRITORYはinit.oraのパラメータです。

そのため、NLS_LANGUAGEとNLS_TERRITORYは別々に設定する必要があります。

* これらのパラメータは、NLS_INSTANCE_PARAMETERSおよびNLS_SESSION_PARAMETERSによってオーバーライドされます。

* init.oraで<クライアント・キャラクタ・セット>またはNLS_LANGを定義することはできません。クライアント・キャラクタ・セットは、クライアントOSのNLS_LANGによって定義します。

* データベースのキャラクタ・セットをinit.oraで定義することはできません。

データベースの（各国語）キャラクタ・セットNLS_(NCHAR)_CHARACTERSETは、"Create Database"コマンドで定義します。

* The NLS_CHARACTERSETパラメータとNLS_NCHAR_CHARACTERSETパラメータは、インスタンス・パラメータまたはセッション・パラメータによってオーバーライドすることはできません。

それらのパラメータは"CREATE DATABASE"コマンドで指定された値で定義されており、後で動的に変更することはできません。キャラクタ・セットを変更するためにシステム表を更新しないでください。データベースが破損し、データベースを再び開くことができなくなる可能性があります。

* データベース作成時に設定されたNLS_LANGは、NLS_DATABASE_PARAMETERSには影響を与えません。

* データベース作成時に設定されたNLS_LANGは、データベースの各国語キャラクタ・セットには影響を与えません。

その他のSELECT文:
A）SELECT name,value$ from sys.props$ where name like '%NLS%';
このSELECT文は、NLS_DATABASE_PARAMETERSと同じ情報を提供します。
props$の代わりにNLS_DATABASE_PARAMETERSを使用してください。
'%NLS%'は大文字になっています

B）SELECT * from v$nls_parameters;
このビューは、現在のセッション・パラメータと、NLS_DATABASE_PARAMETERSビューで表示される*DATABASE*キャラクタ・セットを表示します。

C）SELECT name,value from v$parameter where name like '%NLS%';
このビューは、NLS_INSTANCE_PARAMETERSと同じ情報を提供します。
'%NLS%'は小文字になっています

D）SELECT userenv ('language') from dual;
および
SELECT sys_context ('userenv','language') from dual;
これら両方のSELECT文は、セッションの_と'
DATABASEキャラクタ・セットを返します。データベースのキャラクタ・セットは、この接続を開始したNLS_LANGのキャラクタ・セットと同じではありません。この問合せの出力はNLS_LANG変数の値のように見えますが、実際は違います。

E）SELECT userenv ('lang') from dual;
このSELECT文は、このセッションのNLS_LANGUAGE設定で定義された言語に対してOracleが使用する短いコードを提供します。NLS_LANGUAGEがフランス語に設定されている場合は"F"を、NLS_LANGUAGEが英語に設定されている場合は"GB"を、NLS_LANGUAGEが米語に設定されている場合は"US"
を返します。

F）SHOW parameter NLS%
このSELECT文は、NLS_INSTANCE_PARAMETERSと同じ情報を提供します。

あるデータベースが、UNIXシステム上でUS7ASCIIキャラクタ・セットを使用して作成されています。データベースに接続されているWindowsクライアントは、WE8MSWIN1252キャラクタ・セット（regional settings -> Western Europe /ACP 1252）を使用して機能しており、DBAは、UNIXシェル（ROMAN8）を使用してデータベースを操作します。NLS_LANGは、クライアントとサーバーでamerican_america.US7ASCIIに設定されています。

Note:

This is an INCORRECT setup to explain character set conversion, don't use it in your environment!

（上記で触れた）非常に重要な点は以下のとおりです。

クライアントのNLS_LANGのキャラクタ・セットがデータベースのキャラクタ・セットと同じ値に設定されている場合、送信または受信されるデータは同じ（正しい）エンコードのデータであると見なされ、パフォーマンスの理由から変換や検証が行われない場合があります。データはクライアントから送信された状態のまま、ビット単位で格納されます。

Windowsから、（ラテン語の小文字eにアクセント記号が付いたもの）を、'char'型の列TESTが1つある表NLS_TESTに挿入するとします。

WE8MSWIN1252キャラクタ・セットを使用するWindowsの列に対してINSERT文とSELECT文を実行する限りは、すべてが円滑に処理されます。データベースのキャラクタ・セットが7ビットで定義されていても、変換は行われず、8ビットが挿入され、読み取られます。これは、1バイトは8ビットであり、Oracleでは7ビットのキャラクタ・セットの場合も常に8ビットを使用するためです。正しい設定では、最上位ビットは使用されず、7ビットのみが処理の対象となります。

何らかの理由により、UNIXサーバーから挿入する必要があるとします。Windowsクライアントからデータが挿入された表に対してSELECT文を発行すると、‘é’ではなく ‘Ò’（ラテン語の大文字のOにチルダが付いたもの）が返されます。

UNIXサーバーで‘é’を挿入し、Windowsクライアントで行を選択すると、‘Å’（ラテン語の大文字のAの上にリングが付いたもの）が返されます。

つまり、データベースには誤ったデータが格納されています。WE8MSWIN1252キャラクタ・セットの‘é’に対する数値をデータベースに格納したものの、Oracleには、これがUS7ASCIIデータであると通知されるため、変換は行われず、数値がそのまま格納されます（繰り返し: NLS_LANGがUS7ASCIIに設定されており、データベースのキャラクタ・セットもUS7ASCIIであることから、オラクルは、クライアントがUS7ASCIIコードを提供していると判断し、->変換を行いません）

UNIXサーバーで同じ列に対してSELECT文を発行すると、Oracleは同様に値が正しいと見込み、値を変換せずにUNIX端末に渡します。

問題は、WE8MSWIN1252キャラクタ・セットでは'é'の16進数値が'E9’であり、Roman8キャラクタ・セットでは、'é'の16進数値が'C5'であることです。Oracleはデータベースに格納されていた値（'E9'）をそのままUNIX端末に渡し、UNIX端末はこれが文字‘?’であると判断します。Roman8のキャラクタ・セットでは、16進数値'E9'は文字‘Ò’を表すためです。そのため、UNIX端末の画面には、‘é’ではなく‘Ò’が表示されます。

その逆（UNIXで挿入し、WindowsクライアントでSELECT文を発行）も同様です（ただし、別の文字が返されます）。

これを解決するには、‘é’が含まれるキャラクタ・セットを作成します

（WE8MSWIN1252、WE8ISO89859P1、UTF-8など）でデータベースを作成し、クライアントのNLS_LANGをWE8MSWIN1252に、サーバーのNLS_LANGをWE8ROMAN8に設定します。これにより、UNIXとWindowsのどちらで‘é’を挿入しても、どこでSELECT文を発行するかにかかわらず、‘é’が返されるようになります。Oracleは、UNIXから挿入された16進数値'C5’と、WE8MSWIN1252クライアントの'E9’は、どちらも‘é’であることを認識し、‘é’をデータベースに挿入します（データベース内のコードは、選択したキャラクタ・セットによって異なります）。

UNIXや、Windows、その他のOSクライアントに切り替えなくても、このような問題には遭遇します。別のキャラクタ・セットを使用し、かつNLS_LANGに誤った設定をしているWindowsクライアントを追加した場合も、同様の問題が発生します。

クライアントのOracleソフトウェアのロケール動作を指定するには、NLS_LANGパラメータを設定する必要があります。NLS_LANGでは、クライアントの言語、地域のほか、キャラクタ・セットも設定します。ロケール環境の設定を確認し、その設定に合わせてNLS_LANGの3番目のフィールド（キャラクタ・セット）を設定する必要があります。これを行うには、次のように"locale"コマンドを使用します。

$ locale

Example of output:

LANG=fr_FR 
LC_CTYPE="fr_FR.iso885915@euro" 
LC_COLLATE="fr_FR.iso885915@euro" 
LC_MONETARY="fr_FR.iso885915@euro" 
LC_NUMERIC="fr_FR.iso885915@euro" 
LC_TIME="fr_FR.iso885915@euro" 
LC_MESSAGES="fr_FR.iso885915@euro" 
LC_ALL=fr_FR.iso885915@euro

このコマンドの出力は、すべてのUNIX環境で同一というわけではありません。プラットフォームによっては、以下の構文を使用して、実際に使用されたコード・ページについての詳細を取得すると役立つ場合があります。

$ locale LC_CTYPE | head

         Example of output     
         in a HP-UX environment   
         :   

""
  

   


 
 
 
""
  

   


 
 
 
"iso885915"
  

   


 
 
 
""
  

   


 
 
 
          Example of output in a Linux environment:   
  

   


 
 
 
upper;lower;alpha;digit;xdigit;space;print;graph;blank;cntrl;
punct;alnum;
combining;combining_level3 
toupper;tolower;totitle 
16 
1 
ISO-8859-15 
70 
84 
1 
0 

この場合は、NLS_LANGの3番目のフィールドをWE8ISO8859P15に設定する必要があります。Solaris、AIX、TRU64では、この構文によって有用な補足情報を得ることはできません。これらの設定について詳しくは、以下を参照してください。

Solaris：/usr/lib/locale
AIX：/usr/lib/nls/README
TRU64：/usr/lib/nls
HP-UX：/usr/lib/nls/config
Linux：/usr/share/locale/locale.alias

これらの"ロケール"設定に選択した値を設定するには、どの値を使用できるかを把握する必要があります。それには、以下の構文を使用します。

値を選択したら（LinuxではUTF-8など）、次のように設定します。

または

 
Example of output after the setenv:

$ locale 

LANG=fr_FR 
LC_CTYPE="UTF-8" 
LC_NUMERIC="UTF-8" 
LC_TIME="UTF-8" 
LC_COLLATE="UTF-8" 
LC_MONETARY="UTF-8" 
LC_MESSAGES="UTF-8" 
LC_PAPER="UTF-8" 
LC_NAME="UTF-8" 
LC_ADDRESS="UTF-8" 
LC_TELEPHONE="UTF-8" 
LC_MEASUREMENT="UTF-8" 
LC_IDENTIFICATION="UTF-8" 
LC_ALL=UTF-8 

$ locale LC_CTYPE | head 
upper;lower;alpha;digit;xdigit;space;print;

graph;blank;cntrl;punct;alnum;combining;combining_level3 
toupper;tolower;totitle 
16 
6 
UTF-8 
70 
84 
1 
0 
1

この場合は、NLS_LANGの3番目のフィールド（キャラクタ・セット）をUTF8に設定する必要があります。

% setenv NLS_LANG American_America.UTF8

Windowsのシステムでは、コード体系（キャラクタ・セット）はコード・ページによって指定されます。コード・ページは、一般的な表記体系を共有する特定の言語や言語グループに対応するために定義されます。オラクルの見地からは、コード・ページとキャラクタ・セットという用語はどちらも同じ意味です。中国語、日本語、および韓国語以外の環境では、WindowsのGUIとDOSのコマンド・プロンプトでは同じコード・ページが使用されません。

そのため、WindowsではANSI（sqlplusw.exe）とOEM（DOS窓 - sqlplus.exe）環境に対して2つの異なるキャラクタ・セットが使用されます。

レジストリ:
Windowsシステムでは、それぞれのOracleホームに対して1つのNLS_LANGレジストリ・サブキーを必ず設定するようにしてください。
このサブキーは、以下のようにWindowsレジストリ・エディタを使用して容易に変更できます。
Start -> Run...
"regedit"と入力し、"OK"をクリックします
以下のレジストリエントリを編集します。

Oracleバージョン7の場合：

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

Oracle Databaseバージョン8、8i、および9iの場合：

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\

ここで、"x"はOracleホームを識別する一意の番号です。

HOME0は最初のインストールです。

Oracle Database 10gの場合：

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_

NLS_LANGという名前のエントリがあります。

SQL*PluswをはじめとするOracleツールは、起動時に同じディレクトリにあるoracle.keyファイルのコンテンツを読み取り、どのレジストリ・ツリー、ひいてはどのNLS_LANGサブキーを使用するかを決定します。

注：

バージョン7がインストールされていない場合に、HKEY_LOCAL_MACHINE\SOFTWARE\ORACLEで"NA"と設定されているNLS_LANGが見つかり混乱を招く場合がありますが、これは後方互換性のために使用されているものであり、無視してかまいません。

システム・プロパティでシステム環境変数またはユーザー環境変数として設定：

レジストリはWindowsにおける設定のプライマリ・リポジトリですが、パラメータはほかの場所でも設定できます。決して推奨はされませんが、NLS_LANGを、システム・プロパティでシステム環境変数またはユーザー環境変数として設定することもできます。

この設定は、すべてのOracleホームで使用されます。

設定を確認または変更するには以下を行います。

「'マイ・コンピューター>」アイコンを右クリックし、「'プロパティ'」を選択します

「'詳細設定>」タブを選択し、「'環境変数'」をクリックします

'ユーザー変数リストには、現在ログインしている特定のOSユーザーの設定が表示され'、システム変数リストには、すべてのユーザーに対するシステム全体の変数が表示されます。

これらの環境変数はレジストリですでに設定されているパラメータに優先するため、正当な理由がない限り、この場所でOracleパラメータを設定すべきではありません。

コマンド・プロンプトで環境変数として定義：

Oracleのコマンドライン・ツールを使用する前に、NLS_LANGパラメータを手動で設定しておく必要があります。MS-DOSコマンド・プロンプトで、以下の例のようにsetコマンドを使用します。

C:\> NLS_LANG=american_america.WE8PC850を設定します

NLS_LANGが現在どのように設定されているかが分かったら、現在のANSIコード・ページと一致しているかどうかを確認できます。ACP（ANSIコード・ページ）はWindowsの"既定のロケール"設定によって定義されるため、イギリスのWindows 2000クライアントがあり、キリル文字（ロシア語）を入力したい場合は、（"既定のロケール"を変更することで）ACPを変更して、ロシア語を入力できるようにする必要があります。

この値は次のようにレジストリで見つけることができます。

Start -> Run...

"regedit"と入力し、「"OK"」をクリックします

以下のレジストリ・エントリを参照します。

（下部に）ACPという名前のエントリがあります。ACPの値は、現在のGUIのコード・ページであり、Oracleの名前にマッピングするためのものです。類似の名前で多くのレジストリ・エントリがあるため、レジストリ内の正しい場所を見ていることを確認してください。

また、以下のURLには、Windowsの全バージョンに対するデフォルトのコード・ページ一覧が示されています。

http://www.microsoft.com/globaldev/reference/（ページ左側のREFERENCEタブの下）

OEMはコマンドラインのコード・ページ、ANSIはGUIのコード・ページです。

香港のHKSCSはここに記載されています。 http://www.microsoft.com/hk/hkscs/

以下のように、対応するOracleクライアントのキャラクタ・セットを見つけてください。

上記で見つけたACPに基づき、以下の表でOracleクライアントのキャラクタ・セットを見つけます。特定のACPに対する正しい値は1つのみです。

これは、Windowsのスタート・メニューから起動するGUI SQL*Plus（sqlplusW.exe / plus80W.exe / plus33W.exe）で使用されるキャラクタ・セットです。GUI SQL*Plusと"DOSモード"のSQL*Plusとの違いに注意してください。

Windows NT、2000、およびXPでは、Oracleクライアントのキャラクタ・セット（すなわちNLS_LANG）にUTF8を設定できますが、使用できるのは、この構成を明示的にサポートするクライアント・プログラムに限定されます。Win32のユーザー・インタフェースはUTF8ではなく、したがってクライアント・プログラムがUTF8（Oracle側で使用）とUTF16（Win32側で使用）との間で明示的な変換を行う必要があるためです。

レジストリに設定するには、以下を行います。

Windowsレジストリ・エディタを使用して、上記で見つけた値でOracleホームのNLS_LANGを設定します。

MS-DOSモードでは、CJK（日本語、韓国語、簡体字中国語、繁体字中国語）のような例外はいくつかありますが、Windows GUI（ANSIコード・ページ）とは異なるコード・ページ（OEMコード・ページ）が使用されます。つまり、コマンド・プロンプトでSQL*Plus（sqlplus.exe / plus80.exe / plus33.exe）やsvrmgrlといったOracleのコマンドライン・ツールを使用する前に、DOSのSETコマンドで、NLS_LANGパラメータを環境変数として手動で設定する必要があります。

日本語、韓国語、簡体字中国語、および繁体字中国語では、MS-DOSのOEMコード・ページ（CJK）はANSIコード・ページと同一です。つまり、この特殊な場合には、MS-DOSモードでNLS_LANGパラメータを設定する必要はありません。

その他のすべての場合は、NLS_LANGパラメータを設定し、ANSIコード・ページとすでに一致しているNLS_LANGレジストリ・キーを上書きする必要があります。"MS-DOS専用"の新しいNLS_LANGは、MS-DOSのOEMコード・ページと一致する必要があります。MS-DOSのOEMコード・ページは、以下のようにコマンド・プロンプトで「chcp」と入力して取得できます。

C:\> chcp

アクティブ・コード・ページ: 437

C:\> NLS_LANG=american_america.US8PC437を設定します

MS-DOSモードのセッションのNLS_LANGパラメータが正しく設定されていない場合、キャラクタ・セットの誤った変換によって、エラー・メッセージとデータが破損する可能性があります。

以下のリストを参照して、自身のロケール・システムで使用しているMS-DOSコード・ページに対応するOracleのキャラクタ・セットを見つけてください。

注: これは、SQL*PlusのGUIバージョン（sqlplusW.exe / plus80W.exe / plus33W.exe）の正しい設定です。

"特殊"文字を使用してテストしている場合は、GUIを使用し、"DOS窓"のsqlplus.exeは使用しないでください。

注: これは、SQL*PlusのDOS窓バージョン（sqlplus.exe / plus80.exe / plus33.exe）の正しい設定です。

NLS_LANGパラメータのlanguageコンポーネントは何を制御するのですか。

NLS_LANGパラメータのlanguageコンポーネントは、グローバリゼーション・サポート機能のサブセットの処理を制御します。このコンポーネントは、Oracleメッセージ、ソート、曜日の名前、月の名前に使用される言語などの表記規則を指定します。サポートされる各言語には、一意の名前（AMERICAN、FRENCH、GERMANなど）が付いています。language引数は、territory引数およびcharset引数のデフォルト値を指定します。languageが指定されていない場合は、デフォルトでAMERICANに設定されます。

NLS_LANGパラメータのterritoryコンポーネントは何を制御するのですか。

NLS_LANGパラメータのterritoryコンポーネントは、グローバリゼーション・サポート機能のサブセットの処理を制御します。このコンポーネントは、デフォルトの日付、通貨、数値書式などの表記規則を指定します。サポートされる各地域には、一意の名前（AMERICA、FRANCE、CANADAなど）が付いています。territoryが指定されていない場合は、languageの値から導出されます。

データベースに格納されている文字に対する実際の数値を見るには、dumpコマンドを使用します。

この関数を呼び出す構文は以下のとおりです。

コマンドの意味は次のとおりです。

valueは、表示される値です。

formatは、値のバイトが表示される書式を表す数値です。8は8進、10は10進、16は16進を表します。0から16までの他の値は10進を表します。16よりも大きい値の場合はやや込み入って、その数値が表示可能なASCIIコードに対応している場合はASCII文字として表示し、ASCII制御コードに対応している場合は"^x"と表示し、その他の場合は16進で表示することを意味します。書式の数値に1000を加えると、文字のデータタイプ値に対するキャラクタ・セット情報が戻り値に追加されます。offsetは、表示する値の最初のバイトのオフセットです。負の値は、終端からカウントしていることを意味します。lengthは、表示するバイト数です。以下に例を示します。

Typ=1 Len=39 CharacterSet=UTF8: 227,131,143,227,131,170

上記では、日本語3文字で構成される列の値がUTF8のエンコーディングで返されます。たとえば、最初の文字は227(*255)+131です。これをUCS2に変換し、Unicode Standardコード・ページでコード・ポイント値を検証する必要があるでしょう。

文字変換はどこで行われますか。

バージョン8.0.4以降は、パフォーマンス上の理由により、変換は通常クライアント側で行われます。クライアントが認識しないキャラクタ・セットがデータベースで使用されている場合は、変換はサーバー側で行われます。これはバージョン8.1.6以降で適用されます。

使用している拡張文字のうち、Windows SQL*Plusで表示されないものがあるのはなぜですか。

文字の代わりに黒い四角が表示される場合は、恐らくコード・ページに対する正しいフォントが定義されていません。フォントとは、書体や文字のサイズといった一般的な外観を共有する絵文字（"ヒエログリフ"）のコレクションです。フォントは、オペレーティング・システムが数値を画面上のグラフィック表現に変換するために使用されます。フォントには、使用しているコード・ページで定義されているすべての数値に対するグラフィック表現が含まれているとは限りません。そのため、フォントを変更する際に新しいフォントに特定の記号に対応するグラフィック表現がない場合、画面に黒い四角が表示されることがあります。

Windowsの"文字コード表"ユーティリティを使用して、特定のフォントがどの絵文字で構成されているかを確認できます。

Windows 2000およびXPの場合：

Start -> Run...

"charmap"と入力し、「"OK"」をクリックします。

挿入された文字を選択すると、疑問符または逆疑問符が表示されるのはなぜですか。

クライアントのキャラクタ・セットからデータベースのキャラクタ・セット（またはその逆）に文字を変換する場合、その文字はクライアントとデータベースの両方に存在していなければなりません。その文字が変換先のキャラクタ・セットに存在しない場合は、置換文字が使用されます。一部のキャラクタ・セットには、他の特定のキャラクタ・セットから変換される場合の具体的な置換文字が定義されています。定義されていない場合は、デフォルトの置換文字（「?」など）が使用されます。置換文字から元の文字に戻すことはできません。

サポートされるUTF8/Unicode対応のクライアントは、iSQL*Plusのみですか。

Windows OSではiSQL*Plusのみですが、UNIX OSではiSQL*Plusに限定されません。OSのロケールがUTF-8（Linuxではen_US.UTF-8など）であり、NLS_LANGのキャラクタ・セットがUTF8またはAL32UTF8に設定されている場合は、インポート、エクスポート、SQL*Loader、SQL*Plusなどのデータベース・ユーティリティはすべて、UTF-8クライアントとして機能します。

UNIXのオペレーティング・システムによって管理されるコード・ポイントを確認する方法を教えてください。

UNIX環境で、ある文字に対してどのようなコード・ポイントが生成されているかを確認するには、以下のように"od"コマンドを使用します

"echo"コマンドを次のように使用して、あるコード・ポイントに対応する文字を確認することもできます。

Solaris、AIX、HP-UX、TRU64の場合：

Linuxの場合：

Oracle Locale Builderまたは印字されたコード・ページ（以下のリンクを参照）を使用すれば、使用している本来のコード・ページとNLS_LANG設定が正しく対応していることを確認できます。不明な点がある場合は、前述のコマンドを使用して、複数の文字の値を取得してください。印字されたコード・ページについては、以下を参照してください。

http://www.unicode.org

http://www.iso.org

http://czyborra.com/charsets/iso8859.html

通常、NLS_LANGは、MS-DOSのOEMコード・ページと一致する必要があります。MS-DOSのOEMコード・ページは、以下のようにコマンド・プロンプトで「chcp」と入力して取得できます。

C:\> chcp

アクティブ・コード・ページ: 437

C:\> NLS_LANG=american_america.US8PC437を設定します

SQL*Loaderなどのツールでは、一時的にNLS_LANGを、ロードするファイルのキャラクタ・セットに変更できます。NLS_LANGを変更する別の方法として、.ctlファイルでcharactersetキーワードを使用して、データファイルのデータのキャラクタ・セットを指定する方法があります。この場合、SQL*Loaderは、クライアントのNLS_LANGで設定されているキャラクタ・セットに関係なく、データファイルのデータをそのキャラクタ・セットとして解釈します。ここで、utf16の場合の.ctlファイルの例を示します。この例は、デモ・エリアに提供されています。

-- Copyright (c) 2001 by Oracle Corporation
--   NAME
--     ulcase11.ctl - Load Data in the Unicode Character Set UTF-16
--   DESCRIPTION
--     Loads data in the Unicode character set UTF-16. The data is in little
--     Endean byte order. This means that depending on whether SQL*Loader is
--     running on a little Endean or a big Endean system, it will have to
--     byte swap the UTF-16 character data as necessary. This load uses
--     character length semantics, the default for the character set UTF-16.
-- 
--     This case study is modeled after case study 3 (ulcase3), which loads
--     variable length delimited (terminated and enclosed) data.
-- 
--   RETURNS
-- 
--   NOTES
--     None
--   MODIFIED   (MM/DD/YY)
--    rpfau     02/06/01  - Merged rpfau_sqlldr_add_case_study_11
--    rpfau     01/30/01 -  Creation
--

LOAD DATA
CHARACTERSET utf16
BYTEORDER little
INFILE ulcase11.dat
REPLACE

INTO TABLE EMP
FIELDS TERMINATED BY X'002c' OPTIONALLY ENCLOSED BY X'0022'
(empno integer external (5), ename, job, mgr,
 hiredate DATE(20) "DD-Month-YYYY",
 sal, comm,
 deptno   CHAR(5) TERMINATED BY ":",
 projno,
 loadseq  SEQUENCE(MAX,1) )
 

Oracle9iでは、エクスポート・ユーティリティは常に、Unicodeデータを含むユーザー・データをデータベースのキャラクタ・セットでエクスポートします。インポート・ユーティリティは、データをターゲット・データベースのキャラクタ・セットに自動的に変換します。

Oracle8iでは、エクスポート・ユーティリティは、ユーザー・データをエクスポートする際に、データベースのキャラクタ・セットからエクスポート・セッションのNLS_LANGのキャラクタ・セットに変換します。インポート・ユーティリティは、まずデータをインポート・セッションのNLS_LANGのキャラクタ・セットに変換し、次にそれらをターゲット・データベースのキャラクタ・セットに変換します。エクスポート・セッションとインポート・セッションのNLS_LANGのキャラクタ・セットに、移行するすべての文字が含まれるよう、注意する必要があります。このキャラクタ・セットは通常、ソース・データベースまたはターゲット・データベースのキャラクタ・セットのいずれかになるように選択され、エクスポート・セッションとインポート・セッションのどちらでも同じであるのが一般的です。この選択は、マルチバイト・キャラクタ・セットで特に推奨されますが、選択により、エクスポート・ファイルにいくつかの制限が課されます。Oracle8iで行われるNLS_LANGキャラクタ・セットからの変換、またはNLS_LANGキャラクタ・セットへの変換は、Oracle9iでは、エクスポート・ファイルに含まれるDDL文で行われます。

サーバー（またはクライアント）のNLS_LANGは、データベース・リンクを介したキャラクタ・セットの変換には影響しません。Oracleは、ソース・データベースのキャラクタ・セットからターゲット・データベースのキャラクタ・セット（またはその逆）に変換します。

Windows上にNLS_LANGと複数のホームがあるのは特別なことではありません。考慮に入れるパラメータは、実行可能ファイルで使用されるORACLE_HOMEレジストリ・キーで指定されるパラメータです。環境内でNLS_LANGが設定されている場合は、レジストリの値よりも優先され、サーバー/クライアント上のすべてのOracle_Homeで使用されます。

NLS_LANGは、次のレジストリ・キーで定義されています。

または

Windowsには、次の2種類のツール/アプリケーションがあります。

1. 1）Unicodeのコード・ポイントを承認し、それをレンダリングできる、Unicodeに完全に対応したアプリケーション。これは、Unicodeを処理する必要があるアプリケーションです。Windowsには、Unicode APIが用意されていますが、GUIシステム自体は「元来」Unicodeではありません。
   完全なUnicodeアプリケーションは、特定のUnicodeコード・ポイントに対して1つの絵文字のみを表示できます。したがって、このアプリケーションが完全なUnicodeフォントを使用しなければならないことは明白です。完全なUnicodeアプリケーションがある場合は、NLS_LANGをUTF8に設定する必要があります。
   現在は、このようなアプリケーションは稀少です。ベンダーが明示的に表記していないかぎり、ANSIアプリケーションである可能性が高いでしょう。したがって、確信がない場合は、NLS_LANGをUTF8に設定しないでください。

   Oracleデータベースに含まれるUnicode対応のクライアントは、iSQL*Plusのみです。

2. 2）標準のANSIアプリケーション（sqlplusw.exeなど）は、Unicodeのコード・ポイントを使用できません。したがって、データベースに格納されているUnicodeのコード・ポイントは、NLS_LANGの正しい設定に基づいて、ANSIコード・ポイントに変換する必要があります。そうすることで、OracleはUnicodeのコード・ポイントを、クライアントのキャラクタ・セットにマッピングできるようになります。Unicodeのコード・ポイントに、クライアントのキャラクタ・セットへのマッピングがない場合は、置換文字が使用されます。

キャラクタ・セットとは、各記号にどの数値が割り当てられているかという取り決めです。コンピュータは‘A’や‘B'を識別できません。識別できるのは、端末のオペレーティング・システム（OS）またはハードウェア（ファームウェア）で使用しているキャラクタ・セットで定義されている、その記号に対する（バイナリの）数値です。コンピュータが処理できるのは数値のみです。キャラクタ・セットが必要なのはそのためです。たとえば、'ASCII'は古い7ビット・キャラクタ・セット、'ROMAN8’はUNIXの8ビットのキャラクタ・セット、'UTF8’はマルチバイト・キャラクタ・セットです。

コード・ページは、Windows/DOSのコード体系の名前であり、Oracle NLSの場合は、キャラクタ・セットと同じものであると考えてください。フォントとキャラクタ・セット/コード・ページも区別する必要があります。フォントは、OSが数値を画面上のグラフィカルな'表示’に変換するために使用されます。WindowsのWingdingsフォントは、フォントの分かりやすい例です。Wingdingsフォントでは、‘A’は画面上では‘A’と表示されませんが、OSにとって、この数値は‘A’を意味します。つまり、これは‘A’には見えませんが、Windowsにとっては‘A’であり、‘A’として保存（または使用）されます。

この説明をさらにわかりやすくするために、MS Wordを開き、Wingdingsフォントを選択し、名前を入力してください（記号が表示されます）。これをhtmlで保存します。このhtmlファイルをメモ帳で開くと、<style>セクションでフォントが宣言されており、その下の<body>セクションに名前がプレーン・テキストで表示されていますが、属性はstyle='font-family: Wingdingsとなっています。このファイルをInternet ExplorerまたはNetscapeで開くと、再びWingdingsの記号が表示されます。これは、データそのものではなく、変換されたデータを表しています。

使用中のコード・ページで定義されているすべての記号が、特定のフォントでは表示されない場合があります。これは、フォントの作成者が、すべての記号に対するグラフィック表現をフォント内に含めなかったためです。そのため、フォントを変更したときに、画面に黒い四角が表示されることがあります。Windowsでは、'文字マップ’ツールを使用して、それぞれのフォントに定義されているすべての記号を見ることができます。

おもに次の2つの理由があります。

これまでは、ベンダーはそれぞれのハードウェアとソフトウェアに対して異なる'キャラクタ・セット’を定義してきました。公式の標準がなかったことがおもな理由です。

新しい言語をサポートするために、新しいキャラクタ・セットが定義されました。8ビットのキャラクタ・セットでは、サポートできる記号の数が制限されるため、記述する言語によってキャラクタ・セットが異なります。

7ビットのキャラクタ・セットは、128個（2の7乗）の記号しか認識しません。

8ビットのキャラクタ・セットは、256個（2の8乗）の記号を認識します。

Unicode（UTF-8）はマルチバイト・キャラクタ・セットです。Unicodeでは、100万以上の文字を定義できます。Unicodeについて詳しくは、ホワイトペーパーOracle Unicodeデータベース・サポート（PDF）を参照してください。

キャラクタ・セットを選択する際の基本的なポイントは、現時点および将来的にサポートする必要がある言語を処理できるようにすることです。見落とされているもう1つのポイントは、どのアプリケーションとテクノロジーを使用するか、またはどのアプリケーションとテクノロジーをデータベースとのやり取りに使用するかを検討することです。特定のOracleキャラクタ・セットに対して、どの文字が定義されているかを確認するには、（Oracle9i Database以降で提供されている）Locale Builderを使用します。

データベースのキャラクタ・セットにUnicodeを選択すると、データベース内、およびデータベース上に構築されるあらゆるものに対する強力な基盤となります。オラクルは、新しいシステムのデプロイメントには、常にUnicodeを使用することを推奨しています。レガシー・システムをUnicodeに移行することも推奨しています。現行のシステムをUnicodeでデプロイすると、使いやすさ、互換性、拡張性において多くの利点がもたらされます。Oracleの包括的なサポートにより、Unicodeの真の機能性を活用しながら、高性能なシステムを迅速かつ容易にデプロイできます。現在は多言語のデータをサポートする必要がない場合や、Unicodeが必要ない場合でも、長期的に見ると、Unicodeはシステムを新規に構築する際の最適な選択肢と言えます。Unicodeを選択することで、最終的に時間とコストを節約し、競争力を強化できます。