Oracle® Database

グローバリゼーション・サポート・ガイド

11gリリース2(11.2)

B56307-04(原本部品番号:E10729-08)

2013年7月

Oracle Databaseグローバリゼーション・サポート・ガイド, 11gリリース2(11.2)

B56307-04

Copyright © 1996, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者:  Paul Lane

原本協力者:   Dan Chiba, Winson Chu, Claire Ho, Gary Hua, Simon Law, Geoff Lee, Peter Linsley, Qianrong Ma, Keni Matsuda, Meghna Mehta, Valarie Moore, Cathy Shea, Shige Takeda, Linus Tanaka, Makoto Tozawa, Barry Trute, Ying Wu, Peter Wallack, Chao Wang, Huaqing Wang, Simon Wong, Michael Yau, Jianping Yang, Qin Yu, Tim Yu, Weiran Zhang, Yan Zhu

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

グローバリゼーション・サポートの新機能

- Oracle Database 11gリリース2(11.2)のグローバリゼーションに関する新機能

- Oracle Database 11gリリース1(11.1)のグローバリゼーションに関する新機能

1 グローバリゼーション・サポートの概要

- グローバリゼーション・サポートのアーキテクチャ

- オンデマンドのロケール・データ

- 多言語アプリケーションをサポートするアーキテクチャ

- 多言語データベースでのUnicodeの使用

- グローバリゼーション・サポートの機能

- 言語サポート

- 地域サポート

- 日付と時刻の書式

- 通貨と数値の書式

- 暦法

- 言語ソート

- キャラクタ・セット・サポート

- キャラクタ・セマンティクス

- ロケール・データとカレンダ・データのカスタマイズ

- Unicodeのサポート

2 キャラクタ・セットの選択

- キャラクタ・セット・エンコーディング

- エンコードされたキャラクタ・セットについて

- エンコードされる文字

- 表音的記述法

- 表意的記述法

- 句読点、制御文字、数字および記号

- 記述方向

- キャラクタ・セットでサポートされている文字

- ASCIIエンコーディング

- 文字のエンコード方法

- シングルバイト・コード体系

- マルチバイト・コード体系

- Oracle Databaseキャラクタ・セットのネーミング規則

- 長さセマンティクス

- Oracle Databaseキャラクタ・セットの選択

- 現在および将来の言語要件

- クライアントのオペレーティング・システムとアプリケーションの互換性

- クライアントとサーバーの間のキャラクタ・セット変換

- データベース・キャラクタ・セットの選択がパフォーマンスに与える影響

- データベース・キャラクタ・セットに関する制限事項

- 名前を表すために使用するキャラクタ・セットに関する制限事項

- データベース・キャラクタ・セットに関する指示書

- データベース・キャラクタ・セットとしてのUnicodeの選択

- 各国語キャラクタ・セットの選択

- サポート対象のデータ型の概要

- データベース作成後のキャラクタ・セットの変更

- 単一言語データベースの使用例

- 単一言語の使用例でのキャラクタ・セット変換

- 多言語データベースの使用例

- 制限付き多言語サポート

- 無制限多言語サポート

3 グローバリゼーション・サポート環境の設定

- NLSパラメータの設定

- 環境変数NLS_LANGを使用したロケールの選択

- NLS_LANGの値の指定

- 言語指定と地域指定のオーバーライド

- ロケールのバリアント

- NLS_LANG設定とデータベース・キャラクタ・セットを一致させる必要があるかどうか

- キャラクタ・セット・パラメータ

- NLS_OS_CHARSET環境変数

- NLSデータベース・パラメータ

- NLSデータ・ディクショナリ・ビュー

- NLS動的パフォーマンス・ビュー

- OCINlsGetInfo()関数

- 言語および地域のパラメータ

- NLS_LANGUAGE

- NLS_TERRITORY

- セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド

- 日付および時間を指定するパラメータ

- 日付書式

- NLS_DATE_FORMAT

- NLS_DATE_LANGUAGE

- 時刻書式

- NLS_TIMESTAMP_FORMAT

- NLS_TIMESTAMP_TZ_FORMAT

- カレンダ定義

- カレンダ書式

- 週の最初の曜日

- 年の最初の暦週

- 1年の日数と月数

- 紀元の年

- NLS_CALENDAR

- 数値パラメータとリスト・パラメータ

- 数値書式

- NLS_NUMERIC_CHARACTERS

- NLS_LIST_SEPARATOR

- 通貨パラメータ

- 通貨書式

- NLS_CURRENCY

- NLS_ISO_CURRENCY

- NLS_DUAL_CURRENCY

- Oracle Databaseのユーロ・サポート

- NLS_MONETARY_CHARACTERS

- NLS_CREDIT

- NLS_DEBIT

- 言語ソート・パラメータ

- NLS_SORT

- NLS_COMP

- キャラクタ・セット変換パラメータ

- NLS_NCHAR_CONV_EXCP

- 長さセマンティクス

- NLS_LENGTH_SEMANTICS

4 日時データ型とタイム・ゾーン・サポート

- 日時データ型、期間データ型およびタイム・ゾーン・サポートの概要

- 日時データ型と期間データ型

- 日時データ型

- DATEデータ型

- TIMESTAMPデータ型

- TIMESTAMP WITH TIME ZONEデータ型

- TIMESTAMP WITH LOCAL TIME ZONEデータ型

- 日時データ型への値の挿入

- TIMESTAMPデータ型の選択

- 期間データ型

- INTERVAL YEAR TO MONTHデータ型

- INTERVAL DAY TO SECONDデータ型

- 期間データ型への値の挿入

- 日時および時間隔の演算と比較

- 日時および時間隔の演算

- 日時の比較

- 日時データ型の明示的な変換

- 日時SQL関数

- 日時およびタイム・ゾーン・パラメータと環境変数

- 日時書式パラメータ

- タイム・ゾーン環境変数

- 夏時間セッション・パラメータ

- 夏時間アップグレード・パラメータ

- タイム・ゾーン・ファイルの選択

- タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード

- 夏時間(DST)移行ルールの変更

- タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレードの準備

- タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレードのステップ

- 夏時間動作の更新の例

- タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理

- 異なるバージョンのタイム・ゾーン・ファイルで動作するクライアントとサーバー

- データベースのタイム・ゾーンの設定

- セッションのタイム・ゾーンの設定

- AT TIME ZONE句を使用したタイム・ゾーンの変換

- 夏時間のサポート

- 例: 日時計算への夏時間の影響

5 言語ソートと文字列検索

- Oracleデータベースのソート機能の概要

- バイナリ・ソートの使用

- 言語ソートの使用

- 単一言語ソート

- 多言語ソート

- 多言語ソート・レベル

- 1次レベル・ソート

- 2次レベル・ソート

- 3次レベル・ソート

- 言語ソート機能

- ベース文字

- 無視可能文字

- 短縮文字

- 拡張文字

- 状況依存文字

- 標準的な同値化

- 逆2次ソート

- タイ語/ラオ語文字に対する文字の再配列

- 特殊文字

- 特殊組合せ文字

- 特殊な大文字

- 特殊な小文字

- 大/小文字区別およびアクセント区別なしの言語ソート

- 大/小文字およびアクセントを区別しないソートの例

- 大/小文字またはアクセントを区別しないソートの指定

- 言語ソートの例

- 言語比較の実行

- 照合キー

- 言語比較の精度の制限

- 言語比較の例

- 言語索引の使用

- 言語索引でサポートされるSQL操作および機能

- 複数言語の言語索引

- 言語索引の使用要件

- NLS_SORTを適切に設定

- 列がNOT NULLとして宣言されていない場合にWHERE句でNOT NULLを指定する方法

- 例: フランス語の言語索引の設定

- 言語の文字列検索

- 多言語環境でのSQL正規表現

- 正規表現での文字範囲'[x-y]'

- 正規表現での照合要素デリミタ'[. .]'

- 正規表現での文字クラス'[: :]'

- 正規表現での同値化クラス'[= =]'

- 例: 正規表現

6 Unicodeを使用した多言語データベースのサポート

- Unicodeの概要

- Unicodeの内容

- 補助文字

- Unicodeエンコーディング

- UTF-8エンコーディング

- UCS-2エンコーディング

- UTF-16エンコーディング

- 例: UTF-16、UTF-8およびUCS-2エンコーディング

- OracleデータベースによるUnicodeのサポート

- Unicodeソリューションのデータベースへの実装

- Unicodeデータベースを使用した多言語サポートの有効化

- Unicodeデータ型を使用した多言語サポートの有効化

- UnicodeデータベースとUnicodeデータ型のソリューションの選択方法

- Unicodeデータベースの使用が必要な状況

- Unicodeデータ型の使用が必要な状況

- データベースおよびデータ型ソリューションに関するUnicodeキャラクタ・セットの比較

- Unicodeの事例

- 複数言語サポートのためのデータベース・スキーマ設計

- 多言語データに使用する列の長さの指定

- 複数言語のデータの格納

- 言語情報をデータとともに格納

- ファイングレイン・アクセス・コントロールを使用した変換済データの選択

- LOBデータ型への複数言語によるドキュメントの格納

- 多言語ドキュメントの内容検索に使用する索引の作成

- マルチレクサーの作成

- CLOBデータ型で格納されたドキュメントに対する索引の作成

- BLOBデータ型で格納されたドキュメントに対する索引の作成

7 Unicodeを使用したプログラミング

- Unicodeを使用したプログラミングの概要

- データベース・アクセス製品のスタックおよびUnicode

- Unicodeを使用したSQLとPL/SQLのプログラミング

- SQL NCHARデータ型

- NCHARデータ型

- NVARCHAR2データ型

- NCLOBデータ型

- NCHARデータ型と他のデータ型の間の暗黙的な変換

- データ型変換中のデータ消失に対する例外処理

- 暗黙的なデータ型変換の規則

- Unicodeデータ型のSQL関数

- その他のSQL関数

- Unicode文字列リテラル

- NCHAR文字列リテラルの置換

- NCHARデータを使用したUTL_FILEパッケージの使用

- Unicodeを使用したOCIプログラミング

- Unicodeプログラミング用のOCIEnvNlsCreate()関数

- OCI Unicodeのコード変換

- データ整合性

- Unicode使用時のOCIパフォーマンスに与える影響

- OCI Unicodeのデータ拡張

- OCIでのUTF-8のNLS_LANGのキャラクタ・セットへの設定

- OCIでのSQL CHARデータ型のバインドと定義

- OCIでのSQL NCHARデータ型のバインドと定義

- OCIでのSQL NCHAR文字列リテラルの処理

- OCIでのCLOB UnicodeデータおよびNCLOB Unicodeデータのバインドと定義

- Unicodeを使用したPro*C/C++プログラミング

- UnicodeでのPro*C/C++データ変換

- Pro*C/C++でのVARCHARデータ型の使用

- Pro*C/C++でのNVARCHARデータ型の使用

- Pro*C/C++でのUVARCHARデータ型の使用

- Unicodeを使用したJDBCプログラミング

- SQL CHARデータ型へのJava文字列のバインドと定義

- SQL NCHARデータ型へのJava文字列のバインドと定義

- NCHARデータ型用の新しいJDBC4.0メソッド

- コード変更なしのSQL NCHARデータ型の使用方法

- JDBCでのSQL NCHAR文字列リテラルの使用

- JDBCドライバのデータ変換

- OCIドライバ用のデータ変換

- Thinドライバ用のデータ変換

- サーバー側内部ドライバ用のデータ変換

- Oracleオブジェクト型のoracle.sql.CHARの使用

- oracle.sql.CHAR

- oracle.sql.CHARを使用したSQL CHAR属性とNCHAR属性へのアクセス

- JDBCを使用した場合のSQL CHARデータへのアクセスの制限

- マルチバイト・データベース環境での文字整合性の問題

- Unicodeを使用したODBCとOLE DBのプログラミング

- ODBCとOLE DBのUnicode対応ドライバ

- UnicodeでのOCI依存性

- UnicodeでのODBCとOLE DBのコード変換

- OLE DBのコード変換

- ODBCのUnicodeデータ型

- OLE DBのUnicodeデータ型

- ADOアクセス

- Unicodeを使用したXMLプログラミング

- Javaを使用したUnicodeでのXMLファイルの作成

- Javaを使用したUnicodeでのXMLファイルの読取り

- Javaを使用したUnicodeでのXMLストリームの解析

8 Oracle Globalization Development Kit

- Oracle Globalization Development Kitの概要

- グローバルなインターネット・アプリケーションの設計

- 単一言語インターネット・アプリケーションのデプロイ

- 多言語インターネット・アプリケーションのデプロイ

- グローバルなインターネット・アプリケーションの開発

- ロケールの判別

- ロケール対応

- コンテンツのローカライズ

- Globalization Development Kitスタート・ガイド

- GDKクイック・スタート

- HelloWorldアプリケーションの変更

- J2EE用GDKアプリケーション・フレームワーク

- J2EEアプリケーションでGDKフレームワークを使用可能にする方法

- GDKフレームワークへのロケール・ソースの統合

- GDKフレームワークからのユーザー・ロケールの取得

- GDK Localizerを使用したロケール対応機能の実装

- GDKでサポートされているアプリケーション・ロケールの定義

- GDKフレームワークでのASCII以外の入出力の処理

- GDKでのローカライズされたコンテンツの管理

- JSPとJava Servletでのローカライズされたコンテンツの管理

- 静的ファイルでのローカライズされたコンテンツの管理

- GDKのJava API

- GDKでのOracleロケール情報

- GDKでのOracleロケール・マッピング

- GDKでのOracleキャラクタ・セットの変換

- GDKでのOracleの日付書式、数値書式および通貨書式

- GDKでのOracleのバイナリ・ソートと言語ソート

- GDKでのOracle言語およびキャラクタ・セット検出

- GDKでのOracleの翻訳済ロケール名とタイム・ゾーン名

- 電子メール・プログラムへのGDKの使用

- GDKアプリケーション構成ファイル

- locale-charset-maps

- page-charset

- application-locales

- locale-determine-rule

- locale-parameter-name

- message-bundles

- url-rewrite-rule

- 例: GDKアプリケーション構成ファイル

- Java用GDK提供のパッケージおよびクラス

- oracle.i18n.lcsd

- oracle.i18n.net

- oracle.i18n.servlet

- oracle.i18n.text

- oracle.i18n.util

- PL/SQL用GDK提供のパッケージ

- GDKエラー・メッセージ

9 グローバル環境でのSQLとPL/SQLのプログラミング

- オプションのNLSパラメータを伴うロケール依存のSQL関数

- SQL関数のNLSパラメータのデフォルト値

- SQL関数のNLSパラメータの指定

- SQL関数で受け入れられないNLSパラメータ

- ロケール依存のその他のSQL関数

- CONVERT関数

- 様々な長さセマンティクスに使用するSQL関数

- 様々な長さセマンティクスに使用するLIKE条件

- キャラクタ・セットのSQL関数

- キャラクタ・セット番号からキャラクタ・セット名への変換

- キャラクタ・セット名からキャラクタ・セット番号への変換

- NCHAR列の長さを戻す

- NLSSORT関数

- NLSSORTの構文

- WHERE句の文字列の比較

- NLS_COMPパラメータを使用したWHERE句での比較の簡素化

- ORDER BY句の制御

- グローバル環境でのSQLとPL/SQLのプログラミングに関するその他のトピック

- SQLの日付書式マスク

- 週番号の計算

- SQLの数値書式マスク

- LOB列への外部BFILEデータのロード

10 グローバル環境でのOCIプログラミング

- OCI NLS関数の使用

- OCIでのキャラクタ・セットの指定

- OCIでのロケール情報の取得

- Oracleと他の規格とのロケール情報のマッピング

- OCIでの文字列操作

- OCIでの文字の分類

- OCIでのキャラクタ・セットの変換

- OCIメッセージ関数

- lmsgenユーティリティ

11 キャラクタ・セットの移行

- キャラクタ・セットの移行の概要

- データの切捨て

- データの切捨てによって生じるその他の問題

- キャラクタ・セット変換の問題

- エクスポート・ユーティリティとインポート・ユーティリティの使用による置換文字

- クライアントのNLS_LANGパラメータ設定が不適切であるために生じる無効なデータ

- シングルバイトからマルチバイトへのキャラクタ・セット変換とOracle Data Pump

- 既存のデータベースのデータベース・キャラクタ・セットの変更

- 全体エクスポートおよび全体インポートを使用した文字データの移行

- CSALTERスクリプトを使用したキャラクタ・セットの移行

- Oracle Real Application Clusters環境でのCSALTERスクリプトの使用

- CSALTERスクリプトと選択式のインポートを使用した文字データの移行

- NCHARデータ型への移行

- バージョン8 NCHAR列のOracle9i以上への移行

- 各国語キャラクタ・セットの変更

- CHAR列からNCHAR列への移行

- ALTER TABLE MODIFY文を使用したCHAR列からNCHAR列への変更

- 表のオンライン再定義を使用した大きい表のUnicodeへの移行

- キャラクタ・セット移行後の変換に関する考慮事項

12 Character Set Scannerユーティリティ

- Language and Character Set File Scanner

- LCSSCANコマンドの構文

- 例: LCSSCANコマンドの使用

- Language and Character Set File Scannerのコマンドライン・ヘルプの利用

- サポート対象の言語とキャラクタ・セット

- LCSSCANエラー・メッセージ

- Database Character Set Scanner

- 文字データの変換テスト

- Database Character Set Scannerのスキャン・モード

- 全データベース・スキャン

- ユーザー・スキャン

- 表スキャン

- 列スキャン

- Database Character Set Scannerのインストールと起動

- Database Character Set Scanner用のアクセス権限

- Database Character Set Scannerのシステム表のインストール

- Database Character Set Scannerの起動

- Database Character Set Scannerパラメータ・ファイルの作成

- Database Character Set Scannerのコマンドライン・ヘルプの利用

- Database Character Set Scannerパラメータ

- Database Character Set Scannerセッション: 例

- 全データベース・スキャンの例

- Database Character Set Scannerメッセージ

- ユーザー・スキャンの例

- Database Character Set Scannerメッセージ

- 単一表のスキャンの例

- Database Character Set Scannerメッセージ

- Database Character Set Scannerメッセージ

- 列スキャンの例

- Database Character Set Scannerメッセージ

- Database Character Set Scannerレポート

- データベース・スキャンのサマリー・レポート

- データベース・サイズ

- データベース・スキャン・パラメータ

- スキャン・サマリー

- データ・ディクショナリの変換サマリー

- アプリケーション・データの変換サマリー

- 列サイズ境界ごとのアプリケーション・データの変換サマリー

- 表ごとの変換可能データの分散状態

- 列ごとの変換可能データの分散状態

- 再構築対象の索引

- キャラクタ・セマンティクスによる切捨て

- キャラクタ・セット検出結果

- 言語検出結果

- データベース・スキャンの個別例外レポート

- データベース・スキャン・パラメータ

- データ・ディクショナリの個別例外

- アプリケーション・データ個別例外

- データ・ディクショナリ内の変換可能データまたは不可逆データを処理する方法

- Database Character Set Scannerの記憶域とパフォーマンスに関する考慮事項

- Database Character Set Scannerの記憶域に関する考慮事項

- CSM$TABLES

- CSM$COLUMNS

- CSM$ERRORS

- Database Character Set Scannerのパフォーマンスに関する考慮事項

- マルチ・スキャン・プロセスの使用

- 配列フェッチ・バッファ・サイズの設定

- QUERY句の最適化

- 例外および変換可能ログの抑制

- Database Character Set Scannerに関する推奨事項と制限事項

- データベース・キャラクタ・セットにないデータを含むデータベースのスキャン

- 2つ以上のキャラクタ・セットからのデータを含むデータベースのスキャン

- Database Character Set ScannerのCSALTERスクリプト

- CSALTERスクリプトのチェック・フェーズ

- CSALTERスクリプトの更新フェーズ

- Database Character Set Scannerのビュー

- CSMV$COLUMNS

- CSMV$CONSTRAINTS

- CSMV$ERRORS

- CSMV$INDEXES

- CSMV$TABLES

- Database Character Set Scannerエラー・メッセージ

13 ロケール・データのカスタマイズ

- Oracle Locale Builderユーティリティの概要

- Oracle Locale Builder用のUnicodeフォントの構成

- Windowsでのフォント構成

- その他のプラットフォームでのフォント構成

- Oracle Locale Builderのユーザー・インタフェース

- Oracle Locale Builderのページとダイアログ・ボックス

- 「既存の定義」ダイアログ・ボックス

- 「セッション・ログ」ダイアログ・ボックス

- 「NLTのプレビュー」タブ・ページ

- ファイルを開くダイアログ・ボックス

- Oracle Locale Builderを使用した新規言語定義の作成

- Oracle Locale Builderを使用した新規地域定義の作成

- タイム・ゾーン・データのカスタマイズ

- NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ

- Oracle Locale Builderを使用したコード・チャートの表示

- Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

- ユーザー定義文字(UDC)とキャラクタ・セット

- Oracle Databaseのキャラクタ・セット変換アーキテクチャ

- Unicode 5.0のPrivate Use Area

- キャラクタ・セット間でのユーザー定義文字のクロス・リファレンス

- 既存のキャラクタ・セットから新規キャラクタ・セットを作成する際のガイドライン

- 例: Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

- Oracle Locale Builderを使用した新規言語ソートの作成

- 同じ発音区別記号を持つすべての文字のソート順序の変更

- 発音区別記号を持つ1文字のソート順序の変更

- NLBファイルの生成とインストール

- その他のプラットフォームにおけるカスタムNLBファイルのデプロイ

- 旧リリースOracle DatabaseからのカスタムNLBファイルのアップグレード

- NLBデータ・フォームの別のプラットフォームへの転送

- GINSTALLユーティリティを使用したJavaコンポーネントへのカスタムのロケール定義の追加

A ロケール・データ

- 言語

- 翻訳済メッセージ

- 地域

- キャラクタ・セット

- 推奨するデータベース・キャラクタ・セット

- その他のキャラクタ・セット

- ユーロ記号をサポートしているキャラクタ・セット

- クライアント専用のキャラクタ・セット

- ユニバーサル・キャラクタ・セット

- キャラクタ・セット変換のサポート

- サブセットとスーパーセット

- 言語およびキャラクタ・セット検出のサポート

- 言語ソート

- 暦法

- タイム・ゾーン・リージョン名

- 廃止されたロケール・データ

- 廃止になった言語ソート

- 廃止された地域

- 廃止された言語

- 廃止されたキャラクタ・セットおよび置換キャラクタ・セット

- AL24UTFFSSキャラクタ・セットの非サポート

- Oracleデータベースの言語および地域定義ファイルの更新

B Unicode文字コードの割当て

- Unicodeのコード範囲

- UTF-16エンコーディング

- UTF-8エンコーディング

用語集

索引

はじめに

このマニュアルでは、Oracle Databaseに対するOracleのグローバリゼーション・サポートについて説明します。また、グローバリゼーション・サポート環境の設定、キャラクタ・セットの選択と移行、ロケール・データのカスタマイズ、言語ソート、グローバル環境でのプログラムおよびUnicodeを使用したプログラムの実行の各操作を行う方法について説明します。

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、次のタスクを実行するデータベース管理者、システム管理者およびデータベース・アプリケーション開発者を対象にしています。

- グローバリゼーション・サポート環境の設定

- キャラクタ・セットの選択、分析または移行

- 言語に応じたデータのソート

- ロケール・データのカスタマイズ

- グローバル環境でのプログラムの作成

- Unicodeの使用

このマニュアルを使用するには、リレーショナル・データベースの概念、Oracleサーバーの基本概念、およびOracleを実行するオペレーティング・システム環境についての理解が必要です。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

このマニュアルに記載されている例の多くは、Oracleのインストール時にデフォルトでインストールされるシード・データベースのサンプル・スキーマを使用しています。これらのスキーマがどのように作成されているか、およびその使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

ドキュメント(印刷物)は次のURLのOracle Storeで入手できます。

http://oraclestore.oracle.com/

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN(Oracle Technology Network)から、無償でダウンロードできます。OTN-Jを使用するには、オンラインでの登録が必要です。登録は、次のWebサイトから無償で行えます。

http://www.oracle.com/technology/

OTNのユーザー名とパスワードをすでに持っている場合は、次のOTN Webサイトのドキュメント・セクションに直接移動できます。

http://www.oracle.com/technology/documentation/

表記規則

このセクションでは、このマニュアルの本文およびコード例で使用される表記規則について説明します。この項の内容は次のとおりです。

- 本文の表記規則

- コード例の表記規則

- Microsoft Windowsオペレーティング・システム環境での表記規則

本文の表記規則

本文では、特定の項目が一目でわかるように、次の表記規則を使用します。その規則と使用例を示します。

規則

意味

例

太字

太字は、本文中で定義されている用語または用語集に記載されている用語(あるいはその両方)を示します。

この句を指定すると、索引構成表が作成されます。

イタリック

イタリックは、ドキュメントのタイトルまたは強調を示します。

『Oracle Database概要』
リカバリ・カタログおよびターゲット・データベースが同じディスクに存在しないことを確認します。

固定幅フォントの大文字

固定幅フォントの大文字は、システム指定の要素を示します。このような要素には、パラメータ、権限、データ型、Recovery Managerキーワード、SQLキーワード、SQL*Plusまたはユーティリティ・コマンド、パッケージおよびメソッドがあります。また、システム指定の列名、データベース・オブジェクト、データベース構造、ユーザー名およびロールも含まれます。

NUMBER列に対してのみ、この句を指定できます。
BACKUPコマンドを使用して、データベースのバックアップを作成できます。

USER_TABLESデータ・ディクショナリ・ビュー内のTABLE_NAME列を問い合せます。

DBMS_STATS.GENERATE_STATSプロシージャを使用します。

固定幅フォントの小文字

固定幅フォントの小文字は、実行可能ファイル、ファイル名、ディレクトリ名およびユーザーが指定する要素のサンプルを示します。このような要素には、コンピュータ名およびデータベース名、ネット・サービス名および接続識別子があります。また、ユーザーが指定するデータベース・オブジェクトとデータベース構造、列名、パッケージとクラス、ユーザー名とロール、プログラム・ユニットおよびパラメータ値も含まれます。
注意: プログラム要素には、大文字と小文字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

sqlplusと入力して、SQL*Plusをオープンします。
パスワードは、orapwdファイルで指定します。

/disk1/oracle/dbsディレクトリ内のデータ・ファイルおよび制御ファイルのバックアップを作成します。

hr.departments表には、department_id、department_nameおよびlocation_id列があります。

QUERY_REWRITE_ENABLED初期化パラメータをtrueに設定します。

oeユーザーとして接続します。

JRepUtilクラスが次のメソッドを実装します。

固定幅フォントの小文字のイタリック

固定幅フォントの小文字のイタリックは、プレースホルダまたは変数を示します。

parallel_clauseを指定できます。
old_release.SQLを実行します。ここで、old_releaseとは、アップグレード前にインストールしたリリースを示します。

コード例の表記規則

コード例は、SQL、PL/SQL、SQL*Plusまたは他のコマンドライン文の例です。次の例のように固定幅フォントで表示され、通常のテキストと区別されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE';

次の表に、コード例で使用される表記規則とその使用例を示します。

規則

意味

例

[ ]

大カッコは、カッコ内の項目を任意に選択することを表します。大カッコは、入力しないでください。

DECIMAL (digits [ , precision ])

{ }

中カッコは、カッコ内の項目のうち、1つが必須であることを表します。中カッコは、入力しないでください。

{ENABLE | DISABLE}

|

縦線は、大カッコまたは中カッコ内の複数の選択項目の区切りに使用します。項目のうちの1つを入力します。縦線は、入力しないでください。

{ENABLE | DISABLE}
[COMPRESS | NOCOMPRESS]

...

水平の省略記号は、次のいずれかを示します。

- 例に直接関連しないコードの一部が省略されている。

- コードの一部を繰り返すことができる。

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM employees;

.
.
.

垂直の省略記号は、例に直接関連しない複数の行が省略されていることを示します。

SQL> SELECT NAME FROM V$DATAFILE;
NAME
------------------------------------
/fsl/dbs/tbs_01.dbf
/fs1/dbs/tbs_02.dbf
.
.
.
/fsl/dbs/tbs_09.dbf
9 rows selected.

その他の記号

大カッコ、中カッコ、縦線および省略記号以外の記号は、記載されているとおりに入力する必要があります。

acctbal NUMBER(11,2);
acct    CONSTANT NUMBER(4) := 3;

Italics

イタリック体は、特定の値を指定する必要があるプレースホルダや変数を示します。

CONNECT SYSTEM/system_password
DB_NAME = database_name

UPPERCASE

大文字は、システム指定の要素を示します。これらの要素は、ユーザー定義の要素と区別するために大文字で示されます。大カッコ内にないかぎり、表示されているとおりの順序および綴りで入力します。ただし、大/小文字が区別されないため、小文字でも入力できます。

SELECT last_name, employee_id FROM employees;
SELECT * FROM USER_TABLES;
DROP TABLE hr.employees;

lowercase

小文字は、ユーザー指定のプログラム要素を示します。たとえば、表名、列名またはファイル名などです。
注意: プログラム要素には、大文字と小文字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

SELECT last_name, employee_id FROM employees;
sqlplus hr/hr
CREATE USER mjones IDENTIFIED BY ty3MU9;

Microsoft Windowsオペレーティング・システム環境での表記規則

次の表に、Microsoft Windowsオペレーティング・システム環境での表記規則とその使用例を示します。

規則

意味

例

「スタート」>を選択

プログラムを起動する方法を示します。

Database Configuration Assistantを起動するには、「スタート」→「すべてのプログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Database Configuration Assistant」の順に選択します。

ファイル名およびディレクトリ名

ファイル名およびディレクトリ名は大/小文字が区別されません。特殊文字の左山カッコ(<)、右山カッコ(>)、コロン(:)、二重引用符(")、スラッシュ(/)、縦線(|)およびハイフン(-)は使用できません。特殊文字の円記号(￥)は、引用符で囲まれている場合でも、要素のセパレータとして処理されます。Windowsでは、ファイル名が￥￥で始まる場合、汎用命名規則が使用されていると解釈されます。

c:\winnt"\"system32 is the same as C:\WINNT\SYSTEM32

Windowsコマンド・プロンプト>

現在のハード・ディスク・ドライブのWindowsコマンド・プロンプトを表します。コマンド・プロンプトのエスケープ文字はカレット(^)です。プロンプトは作業中のサブディレクトリを表します。このマニュアルでは、コマンド・プロンプトと呼びます。

C:\oracle\oradata>

特殊文字

Windowsコマンド・プロンプトで二重引用符(")のエスケープ文字として円記号(￥)が必要な場合があります。丸カッコおよび一重引用符(')にはエスケープ文字は必要ありません。エスケープ文字および特殊文字の詳細は、Windowsオペレーティング・システムのドキュメントを参照してください。

C:\>exp scott/tiger TABLES=emp QUERY=\"WHERE job='SALESMAN' and sal<1600\"
C:\>imp SYSTEM/password FROMUSER=scott TABLES=(emp, dept)

HOME_NAME

Oracleホームの名前を表します。ホーム名には、英数字で16文字まで使用できます。ホーム名に使用可能な特殊文字は、アンダースコアのみです。

C:\> net start OracleHOME_NAMETNSListener

ORACLE_HOMEおよびORACLE_BASE

Oracle8iより前のリリースでは、Oracleコンポーネントをインストールすると、すべてのサブディレクトリが最上位のORACLE_HOMEの直下に置かれました。ディレクトリの名前は、デフォルトでは次のいずれかです。

- C:\orant(Windows NTの場合)

- C:\orawin98(Windows 98の場合)

このリリースは、Optimal Flexible Architecture(OFA)のガイドラインに準拠しています。ORACLE_HOMEディレクトリ下に配置されないサブディレクトリもあります。最上位のディレクトリはORACLE_BASEと呼ばれ、デフォルトではC:\oracleです。他のOracleソフトウェアがインストールされていないコンピュータに最新リリースのOracleをインストールした場合、Oracleホーム・ディレクトリはデフォルトでC:\oracle\orannに設定されます。nは最新リリースの番号です。Oracleホーム・ディレクトリは、ORACLE_BASEの直下に配置されます。

このマニュアルに示すディレクトリ・パスの例は、すべてOFAの表記規則に準拠しています。

OFAの準拠の詳細、および非OFA準拠ディレクトリ下でのOracle製品のインストールの詳細は、『Oracle Databaseプラットフォーム・ガイド for Microsoft Windows』を参照してください。

ORACLE_BASE\ORACLE_HOME\rdbms\adminディレクトリに移動します。

グローバリゼーション・サポートの新機能

この項では、グローバリゼーション・サポートの新機能と追加情報の参照先を次のような項目に分けて説明します。

- Oracle Database 11gリリース2(11.2)のグローバリゼーションに関する新機能

- Oracle Database 11gリリース1(11.1)のグローバリゼーションに関する新機能

Oracle Database 11gリリース2(11.2)のグローバリゼーションに関する新機能

- TIMESTAMP WITH TIMEZONEデータ型値の簡略化されたパッチ適用のサポート
Oracle Database 11gリリース2より前のリリースでは、タイム・ゾーン・ファイルが更新された後、データベースのTIMESTAMP WITH TIMEZONEデータ値に手動でパッチを適用するという煩雑な処理が行われていました。このパッチ適用が簡略化され、透過的になりました。

さらに、OCI、JDBC、Pro*CおよびSQL*Plusの各クライアントは、クライアント側のタイム・ゾーン・ファイルを更新しなくてもサーバーとの通信を続行できるようになりました。ただし、そのような混在モードで作業する場合の考慮事項があります。

関連項目:

- 第4章「日時データ型とタイム・ゾーン・サポート」

- タイム・ゾーン・ファイルのバージョンがクライアントとサーバーで異なる混在モードでの作業で発生する問題は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

Oracle Database 11gリリース1(11.1)のグローバリゼーションに関する新機能

- Unicode 5.0のサポート(Unicode 5.0は、過去のUnicode規格すべてに優先するUnicode規格の主要バージョンです。)

- 1,369個の文字が新しくUnicode規格になりました。この追加された文字の中には、キリル文字、ギリシャ文字、ヘブライ文字、カンナダ文字、ラテン文字、および数学記号、発音記号などの記号が含まれます。

- Unicode 5.0には次のスクリプトも新しく追加されました: N'Ko、Balinese、Phags-pa、Phoenician、Cuneiform

- プロパティや表示アルゴリズムなどの文字の使用方法が改善されました。

- 新しい文字すべてが分類されただけでなく、多くの東南アジア文字が再分類されました。

関連項目:

- 第1章「グローバリゼーション・サポートの概要」

- 第6章「Unicodeを使用した多言語データベースのサポート」

- 推奨するデータベース・キャラクタ・セットおよび指示書
データベース・キャラクタ・セットとして使用するためにオラクル社が推奨するキャラクタ・セットのリストがコンパイルされました。新しいシステムをデプロイする場合、データベースのキャラクタ・セットはこのリストに示す推奨キャラクタ・セットに制限されます。

関連項目:

- 第2章「キャラクタ・セットの選択」

- 付録A「ロケール・データ」

- キャラクタ・セット変換のパフォーマンス向上

- データ・ディクショナリの小型バイナリXML(CSX)データに関する情報を提供するDatabase Character Set Scannerの新しいレポート・セクション

関連項目:
第12章「Character Set Scannerユーティリティ」

- カスタマイズしたロケール・ファイルをJavaコンポーネントに追加するGINSTALLユーティリティ

関連項目:
第13章「ロケール・データのカスタマイズ」

- 3つの言語(アルバニア語、ベラルーシ語、アイルランド語)の新規追加および2つの地域(アルバニア、ベラルーシ)の新規追加

関連項目:
付録A「ロケール・データ」

- 照合依存のSQL LIKE条件の言語索引サポート

関連項目:
第5章「言語ソートと文字列検索」

1 グローバリゼーション・サポートの概要

この章では、Oracle Databaseのグローバリゼーション・サポートの概要を説明します。この章の内容は、次のとおりです。

- グローバリゼーション・サポートのアーキテクチャ

- グローバリゼーション・サポートの機能

グローバリゼーション・サポートのアーキテクチャ

Oracle Databaseのグローバリゼーション・サポートにより、データを各国語で格納、処理、取得できます。データベース・ユーティリティ、エラー・メッセージ、ソート順序、日付、時刻、通貨、数値、カレンダ規則が、各国の言語およびロケールに自動的に調整されます。

Oracleのグローバリゼーション・サポート機能は、以前はNational Language Support(NLS)機能と呼ばれていました。実際のところ、NLSはグローバリゼーション・サポートのサブセットです。NLSとは、各国語を選択してデータを特定のキャラクタ・セットで格納する機能です。グローバリゼーション・サポートを使用すると、世界中から同時にアクセスして実行できる多言語アプリケーションやソフトウェア製品の開発が可能になります。アプリケーションでは、ユーザー・インタフェースの内容表示とデータ処理に、ユーザーの母国語と選択したロケールを使用できます。

オンデマンドのロケール・データ

Oracleデータベースのグローバリゼーション・サポートは、Oracle NLS Runtime Library(NLSRTL)とともに実装されます。NLS RTLは、広範囲にわたる言語非依存の関数のパッケージを提供します。これによって、適切なテキストと文字の処理および言語規則に従った操作を行うことができます。特定の言語や地域に対応した関数の動作は、実行時に指定してロードされたロケール固有データ・セットによって制御されます。

ロケール固有データは、Oracle Databaseでサポートされるロケールごとに独立したデータ・セットとしての構造を持ちます。特定のロケールのデータを、他のロケール・データに依存せずにロードできます。

この設計の利点は、次のとおりです。

- 必要なロケール・セットを選択してメモリー消費を管理できます。

- 他のロケールに影響を与えずに、特定のロケールのロケール・データを追加してカスタマイズできます。

図1-1に、実行時のロケール固有データのロードを示します。この例では、フランス語データと日本語データが多言語データベースにロードされますが、ドイツ語データはロードされません。

図1-1 データベースへのロケール固有データのロード

ロケール固有のデータは、ORACLE_HOME/nls/dataディレクトリに格納されます。環境変数ORA_NLS10を定義する必要があるのは、ロケール固有のデータファイルの単一コピーがシステムの複数のOracleホームで共有される場合など、ロケール固有のデータファイルについてデフォルトのディレクトリ位置を変更する必要がある場合のみです。

ロードする有効なNLSオブジェクトは、ブート・ファイルを使用して指定します。Oracle Databaseでは、システムとユーザーの両方のブート・ファイルをサポートしています。ユーザーのブート・ファイルを使用すると、そのデータベースで使用可能なNLSロケール・オブジェクトを柔軟に調整できます。また、新しいロケール・データを追加したり、一部のロケール・データ・コンポーネントをカスタマイズすることができます。

関連項目:
第13章「ロケール・データのカスタマイズ」

多言語アプリケーションをサポートするアーキテクチャ

Oracle Databaseは、データベースの構成に使用される言語を複数層アプリケーションとクライアント/サーバー・アプリケーションでサポートできるようにしています。

ロケール依存操作は、クライアントとデータベース・サーバーの両方にある複数のパラメータと環境変数によって制御されます。データベース・サーバーでは、クライアント用に起動された各セッションが他のセッションと同じまたは異なるロケールで実行され、同じまたは異なる言語要件が指定されることがあります。

Oracle Databaseには、セッションに依存しないNLSパラメータのセットがデータベースの作成時に指定されます。その2つのパラメータによって、データベース・キャラクタ・セットと各国語キャラクタ・セット、つまりNCHAR、NVARCHAR2およびNCLOBデータに指定できる代替Unicodeキャラクタ・セットを指定します。このパラメータは、テキスト・データをデータベースに格納するために使用するキャラクタ・セットを指定します。他のパラメータ(言語や地域など)は、CHECK制約の評価で使用されます。

クライアント・セッションとデータベース・サーバーが異なるキャラクタ・セットを指定している場合、データベースではキャラクタ・セットの文字列を自動的に変換します。

グローバリゼーション・サポートの観点では、すべてのアプリケーションは、Oracle Databaseインスタンスと物理的に同じマシン上で実行している場合でも、クライアントとみなされます。たとえば、Oracleソフトウェア所有者であるUNIXユーザーが、SQL*PlusをRDBMSソフトウェアがインストールされているOracleホームから起動し、ORACLE_SIDパラメータを指定してアダプタ経由でデータベースに接続している場合、このSQL*Plusはクライアントとみなされます。その動作はクライアント側のNLSパラメータによって規定されます。

別の例をあげると、中間層がアプリケーション・サーバーの場合に、アプリケーションがクライアントとみなされます。そのアプリケーション・サーバーによって起動される様々なセッションは、個別のクライアント・セッションとみなされます。

クライアント・アプリケーションが起動されると、環境設定に従ってクライアントのNLS環境が初期化されます。ローカルで実行されるNLS操作は、すべてこの設定を使用して実行されます。ローカルNLS操作の例を次に示します。

- Oracle Developerアプリケーションの表示書式設定

- OCI環境ハンドルを使用してNLS OCI関数を実行するユーザーOCIコード

アプリケーションをデータベースに接続すると、サーバー上でセッションが作成されます。新しいセッションは、初期化パラメータ・ファイルで指定されたNLSインスタンス・パラメータからNLS環境を初期化します。これらの設定は、ALTER SESSION文によって後で変更できます。この文によって変更されるのは、そのセッションのNLS環境のみです。ローカル・クライアントのNLS環境は変更されません。セッションのNLS設定は、サーバー上で実行されるSQLおよびPL/SQL文の処理に使用されます。たとえば、ALTER SESSION文を使用して、NLS_LANGUAGE初期化パラメータをイタリア語に設定できます。

ALTER SESSION SET NLS_LANGUAGE=Italian;

SELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のようになります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30-SET-05      962.5
Urman                     07-MAR-06        975
Popp                      07-DIC-07      862.5
...

月名の略称にイタリア語が使用されていることに注意してください。

NLS_LANG環境設定がクライアント側で定義されている場合は、接続直後にALTER SESSION文が暗黙的にクライアントとセッションのNLS環境を同期させます。

関連項目:

- 第10章「グローバル環境でのOCIプログラミング」

- 第3章「グローバリゼーション・サポート環境の設定」

多言語データベースでのUnicodeの使用

Unicode(エンコードされたユニバーサル・キャラクタ・セット)では、1つのキャラクタ・セットを使用して任意の言語の情報を格納できます。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。

Unicodeには、次の利点があります。

- キャラクタ・セット変換機能と言語ソート機能が簡素化されます。

- ネイティブのマルチバイト・キャラクタ・セットに比べてパフォーマンスが改善されます。

- Unicode規格に基づくUnicodeデータ型がサポートされます。

関連項目:

- 第6章「Unicodeを使用した多言語データベースのサポート」

- 第7章「Unicodeを使用したプログラミング」

- 「Unicodeデータ型を使用した多言語サポートの有効化」

グローバリゼーション・サポートの機能

ここでは、Oracleデータベースの標準的なグローバリゼーション機能の概要を説明します。

- 言語サポート

- 地域サポート

- 日付と時刻の書式

- 通貨と数値の書式

- 暦法

- 言語ソート

- キャラクタ・セット・サポート

- キャラクタ・セマンティクス

- ロケール・データとカレンダ・データのカスタマイズ

- Unicodeのサポート

言語サポート

Oracle Databaseでは、データの格納、処理および取出しをネイティブ言語で行うことができます。データベースに格納できる言語は、Oracleがサポートしているキャラクタ・セットでエンコードされているスクリプトで記述されたすべての言語です。Unicodeデータベースとデータ型を使用することで、Oracle Databaseは、ほとんどの現代言語をサポートしています。

各国語のサブセットに対しては、追加サポートが用意されています。たとえば、データベースでは、翻訳された月の名前を使用して日付を表示し、文化的な慣習に従ってテキスト・データをソートできます。

このマニュアルで使用している言語サポートという用語は、言語依存の追加機能を指しており、特定の言語のテキストを格納できることを示すわけではありません。たとえば、言語サポートには、特定のロケールおよび文化的慣習に従った日付の表示やテキストのソートが含まれます。一部のサポート対象言語については、翻訳済エラー・メッセージやデータベース・ユーティリティに関する翻訳済ユーザー・インタフェースが用意されています。

関連項目:

- 第3章「グローバリゼーション・サポート環境の設定」

- Oracle Databaseがサポートする言語名とその略称リストは、「言語」を参照してください。

- Oracle Databaseのメッセージが翻訳されている言語のリストは、「翻訳済メッセージ」を参照してください。

地域サポート

Oracle Databaseでは、地域に固有な文化的慣習をサポートしています。デフォルトのローカル時刻書式、日付書式、数値および通貨単位に関する規則は、ローカル地域設定によって異なります。多様なNLSパラメータの設定によって、データベース・セッションでは様々な文化的設定を使用できます。たとえば、地域がAMERICAと定義されている場合でも、指定したデータベース・セッションに、第1通貨としてユーロ(EUR)を、第2通貨として日本円(JPY)を設定できます。

関連項目:

- 第3章「グローバリゼーション・サポート環境の設定」

- Oracle Databaseでサポートされている地域のリストは、「地域」を参照してください。

日付と時刻の書式

時間、日、月および年に関する多様な表記規則は、ローカル書式で処理されます。たとえば、日付の表示の場合、英国ではDD-MON-YYYY書式が使用され、日本では一般的にYYYY-MM-DD書式が使用されます。

タイム・ゾーンや夏時間もサポートされます。

関連項目:

- 第3章「グローバリゼーション・サポート環境の設定」

- 第4章「日時データ型とタイム・ゾーン・サポート」

- 『Oracle Database SQL言語リファレンス』

通貨と数値の書式

通貨、貸方および借方の記号は、ローカル書式で表すことができます。基数記号と3桁区切りは、ロケールで定義できます。たとえば、小数点は、米国ではドット(.)ですが、フランスではカンマ(,)です。したがって、金額1,234の持つ意味は、国によって異なります。

関連項目:
第3章「グローバリゼーション・サポート環境の設定」

暦法

世界中で様々な暦法が使用されています。Oracleデータベースでは7種類の暦法をサポートしています。

- Gregorian(グレゴリオ暦)

- Japanese Imperial(日本の元号暦)

- ROC Official(台湾暦)

- Thai Buddha(タイ仏教暦)

- Persian(ペルシャ暦)

- English Hijrah(英語版イスラム歴)

- Arabic Hijrah(イスラム歴)

関連項目:

- 第3章「グローバリゼーション・サポート環境の設定」

- サポートされているカレンダの詳細は、「暦法」を参照してください。

言語ソート

Oracle Databaseには、文化に応じた正確なソートおよび大/小文字の変換を行うために、言語の定義が用意されています。基本定義では、文字列を独立した文字の連続として扱います。拡張定義では、特殊な事例として扱う必要のある文字のペアを認識します。

基本定義を使用して大文字または小文字に変換された文字列は、常に同じ長さです。拡張定義を使用して変換された文字列は、長くなったり短くなったりすることがあります。

関連項目:
第5章「言語ソートと文字列検索」

キャラクタ・セット・サポート

Oracle Databaseでは、多数のシングルバイト、マルチバイトおよび固定幅のコード体系をサポートしています。これらのコード体系は、各国の規格、国際規格およびベンダー固有の規格に基づいています。

関連項目:

- 第2章「キャラクタ・セットの選択」

- サポートされるキャラクタ・セットのリストは、「キャラクタ・セット」を参照してください。

キャラクタ・セマンティクス

Oracle Databaseには、キャラクタ・セマンティクスが用意されています。キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の記憶要件をバイト数ではなく文字数で定義する場合に役立ちます。

関連項目:
「長さセマンティクス」

ロケール・データとカレンダ・データのカスタマイズ

Oracle Locale Builderを使用して、言語、キャラクタ・セット、地域または言語ソートなどのロケール・データをカスタマイズできます。

NLSカレンダ・ユーティリティを使用すると、カレンダをカスタマイズできます。

関連項目:

- 第13章「ロケール・データのカスタマイズ」

- 「NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ」

Unicodeのサポート

Unicodeはコンピュータによる一貫性のある表現および操作のために、すべての言語のテキストや記号を使用可能にする業界標準です。現時点でのUnicode規格の最新バージョンは5.0です。

Oracleデータベースは、Oracle 7からUnicode規格を採用しています。それ以降では、Oracle Database 10gリリース2がUnicode 4.0をサポートしています。Oracle Database 11gリリースでは、Unicode 5.0をサポートしています。

次の2つの方法でUnicode文字をOracle Databaseに格納できます。

- UTF-8エンコードされた文字をSQL CHARデータ型として格納できるように、Unicodeデータベースを作成できます。

- Unicodeデータ型を使用して、特定の列の多言語データをサポートできます。データベース・キャラクタ・セットの定義方法に関係なく、SQL NCHARデータ型の列にUnicode文字を格納できます。NCHARデータ型はUnicodeデータ型専用です。

関連項目:
第6章「Unicodeを使用した多言語データベースのサポート」

2 キャラクタ・セットの選択

この章では、キャラクタ・セットの選択方法について説明します。この章の内容は、次のとおりです。

- キャラクタ・セット・エンコーディング

- 長さセマンティクス

- Oracle Databaseキャラクタ・セットの選択

- データベース作成後のキャラクタ・セットの変更

- 単一言語データベースの使用例

- 多言語データベースの使用例

キャラクタ・セット・エンコーディング

文字を処理する場合、コンピュータ・システムは文字をグラフィカルな表現としてではなく数値コードとして処理します。たとえば、データベースに文字Aを格納すると、実際はコンピュータ・システムによって解析される数値コードが格納されます。特に、異なるキャラクタ・セット間のデータ変換を必要とする可能性があるグローバル環境では、この数値コードが重要になります。

この項の内容は、次のとおりです。

- エンコードされたキャラクタ・セットについて

- エンコードされる文字

- キャラクタ・セットでサポートされている文字

- 文字のエンコード方法

- Oracle Databaseキャラクタ・セットのネーミング規則

エンコードされたキャラクタ・セットについて

データベースの作成時に、エンコードされたキャラクタ・セットを指定します。キャラクタ・セットの選択によって、データベース内で表現できる言語が決定します。また、キャラクタ・セットの選択は次の方法にも影響します。

- データベース・スキーマの作成方法

- 文字データを処理するアプリケーションの開発方法

- オペレーティング・システムでのデータベースの動作

- データベースのパフォーマンス

- キャラクタ・データの格納に必要な記憶域

特定の文字グループ(アルファベット文字、表意文字、記号、句読点、制御文字など)をキャラクタ・セットとしてエンコードできます。エンコードされたキャラクタ・セットは、キャラクタ・セット内のそれぞれの文字を表す一意の数値コードに対応しています。数値コードはコード・ポイントまたはエンコーディング値と呼ばれます。表2-1に、ASCIIキャラクタ・セットの16進コード値が割り当てられている文字の例を示します。

表2-1 ASCIIキャラクタ・セットでエンコードされた文字

文字

説明

16進コード値

!

感嘆符

21

#

数値記号

23

$

ドル記号

24

1

数字の1

31

2

数字の2

32

3

数字の3

33

A

大文字のA

41

B

大文字のB

42

C

大文字のC

43

a

小文字のa

61

b

小文字のb

62

c

小文字のc

63

コンピュータ業界では、様々にエンコードされたキャラクタ・セットが使用されています。各キャラクタ・セットは、次の点で異なります。

- 使用可能な文字数

- 使用可能な文字(文字レパートリ)

- 書込み用スクリプトとそれによって表される言語

- それぞれの文字に割り当てられたコード・ポイント

- 特定の文字を表現するために使用するコード体系

Oracle Databaseでは、各国の規格、国際規格およびベンダー固有のエンコードされたキャラクタ・セット規格のほとんどすべてがサポートされています。

関連項目:
Oracle Databaseでサポートされているすべてのキャラクタ・セットのリストは、「キャラクタ・セット」を参照してください。

エンコードされる文字

キャラクタ・セットでエンコードされる文字は、表現する記述法によって異なります。記述法は、1つの言語または1つの言語グループを表現するために使用できます。記述法は次の2つに分類できます。

- 表音的記述法

- 表意的記述法

この項の内容は、次のとおりです。

- 句読点、制御文字、数字および記号

- 記述方向

表音的記述法

表音的記述法は、1つの言語に対応付けられた様々な音声を表現する、複数の記号で構成されています。たとえば、ギリシア語、ラテン語、キリル文字およびデーバナーガリ語はすべて、アルファベットに基づいた表音的記述法です。アルファベットは、複数の言語を表現できます。たとえば、ラテン・アルファベットでは、多くの西ヨーロッパ諸国の言語(フランス語、ドイツ語、英語など)を表現できます。

表音的記述法に対応付けられた文字は、文字レパートリが通常256文字より少ないため、一般的には1バイトでエンコードできます。

表意的記述法

表意的記述法は、言語の音声ではなく、単語の意味を表す表意文字または象形文字で構成されています。中国語と日本語は、何万という表意文字に基づいた表意的記述法の例です。表意的記述法を使用する言語では、表音文字セットを使用する場合もあります。表音文字セットでは、追加の表音的情報を伝達する方法が提供されます。たとえば、日本語には2つの表音文字セットがあり、通常、文法的な要素にはひらがなが、外来語や擬音語にはカタカナが使用されます。

表意的記述法に対応付けられた文字は、文字のレパートリが何万とあるため、一般的には複数バイトでエンコードします。

句読点、制御文字、数字および記号

言語スクリプトのエンコーディングに加えて、次のように他の特殊文字もエンコードする必要があります。

- カンマ、ピリオドおよびアポストロフィなどの句読点

- 数字

- 通貨記号や数学演算子などの特殊な記号

- キャリッジ・リターンやタブなどの制御文字

記述方向

ほとんどの欧米言語は、ページの上から下へ向かって左から右へ記述されます。東アジアの言語は、通常、ページの右から左に向かって上から下へ記述されますが、欧米言語から翻訳された技術文書ではしばしば例外が見られます。アラビア語とヘブライ語は、上から下へ向かって右から左へ記述されます。

アラビア語とヘブライ語では、数字の記述方向が逆になります。テキストが右から左に書かれている場合でも、文中の数字は左から右に向かって書かれます。たとえば、「I wrote 32 books」は「skoob 32 etorw I」と書かれます。書込み方向に関係なく、データは論理順序で格納されます。論理順序は、入力している言語の画面上での表示方法ではなく、その言語の入力で使用されている順序を意味します。

記述方向は、文字のエンコーディングには影響しません。

キャラクタ・セットでサポートされている文字

様々なキャラクタ・セットによって、様々な文字レパートリがサポートされています。一般的に、キャラクタ・セットは特定の書込みスクリプトに基づいているため、複数の言語をサポートできます。キャラクタ・セットが最初に開発されたとき、文字レパートリには制限がありました。今でも、特定の文字を複数のプラットフォームで使用すると、問題が発生する場合があります。次のCHAR文字およびVARCHAR文字は、すべてのOracleデータベース・キャラクタ・セットで表示可能で、どのプラットフォームにもトランスポートできます。

- 大文字と小文字の英文字: AからZおよびaからz

- アラビア数字: 0から9

- 句読点記号: % ' ' ( ) * + - , . / \ : ; < > = ! _ & ~ { } | ^ ? $ # @ " [ ]

- 制御文字: スペース、水平タブ、垂直タブ、改ページ

これ以外の文字を使用する場合は、選択したデータベース・キャラクタ・セットでデータがサポートされているかどうか注意する必要があります。

適切なデータ変換を行うには、NLS_LANGパラメータを適切に設定する必要があります。NLS_LANGパラメータでは、クライアント・オペレーティング・システムの設定を反映するキャラクタ・セットを指定してください。NLS_LANGを適切に設定すると、クライアント・オペレーティング・システムの文字コード体系からデータベース・キャラクタ・セットへと適切に変換できます。これらの設定が同じときは、Oracle Databaseによって、送受信されるデータはデータベース・キャラクタ・セットと同一のキャラクタ・セットでエンコードされているとみなされるため、キャラクタ・セットの妥当性チェックや変換が行われない場合があります。このため、変換が必要な場合は、データが破損する可能性があります。

キャラクタ・セット間での変換中に、Oracleはクライアント側のデータがNLS_LANGパラメータで指定されたキャラクタ・セットでエンコードされるものと想定します。文字列に(たとえば、CHRまたはCONVERT SQL関数を使用して)他の値を入力すると、その値は、データベースに送信されたときに、適切に変換されないため損われる可能性があります。環境を適切に構成しており、データベース・キャラクタ・セットでデータベースに入力される可能性のある文字データのレパートリ全体がサポートされていれば、現行のデータベース・キャラクタ・セットを変更する必要はありません。ただし、企業がよりグローバルになり、追加の文字や新規の言語のサポートが必要になった場合は、より大きな文字レパートリを持つキャラクタ・セットの選択が必要になる可能性があります。このような場合は、Unicodeデータベースとデータ型の使用をお薦めします。

関連項目:

- 第6章「Unicodeを使用した多言語データベースのサポート」

- CHRおよびCONVERT SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「Oracle Locale Builderを使用したコード・チャートの表示」

ASCIIエンコーディング

表2-2に、ASCIIキャラクタ・セットがどのようにエンコードされているかを示します。行および列のヘッダーは、16進数字を示しています。文字のコード値を調べるには、列の数字の次に行の数字を読みます。たとえば、文字Aのコード値は0x41です。

表2-2 7ビットASCIIキャラクタ・セット

-

0

1

2

3

4

5

6

7

0

NUL

DLE

SP

0

@

P

'

p

1

SOH

DC1

!

1

A

Q

a

q

2

STX

DC2

"

2

B

R

b

r

3

ETX

DC3

#

3

C

S

c

s

4

EOT

DC4

$

4

D

T

d

t

5

ENQ

NAK

%

5

E

U

e

u

6

ACK

SYN

&

6

F

V

f

v

7

BEL

ETB

'

7

G

W

g

w

8

BS

CAN

(

8

H

X

h

x

9

TAB

EM

)

9

I

Y

i

y

A

LF

SUB

*

:

J

Z

j

z

B

VT

ESC

+

;

K

[

k

{

C

FF

FS

,

<

L

\

l

|

D

CR

GS

-

=

M

]

m

}

E

SO

RS

.

>

N

^

n

~

F

SI

米国

/

?

O

_

o

DEL

世界中のユーザーの要求を満たすために言語は拡張されて、新規キャラクタ・セットが作成されました。一般的に、この新規キャラクタ・セットでは、同じスクリプトに基づいた関連のある言語グループがサポートされています。たとえば、ISO 8859キャラクタ・セット・シリーズは、多様なヨーロッパ諸国の言語をサポートするために作成されました。表2-3に、ISO 8859キャラクタ・セットでサポートされている言語を示します。

表2-3 lSO 8859キャラクタ・セット

規格

サポートしている言語

ISO 8859-1

西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、デンマーク語、オランダ語、英語、フェロー語、フィンランド語、フランス語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語)

ISO 8859-2

東ヨーロッパ諸国の言語(アルバニア語、クロアチア語、チェコ語、英語、ドイツ語、ハンガリー語、ラテン語、ポーランド語、ルーマニア語、スロバキア語、スロベニア語、セルビア語)

ISO 8859-3

南東ヨーロッパ諸国の言語(アフリカーンス語、カタロニア語、オランダ語、英語、エスペラント語、ドイツ語、イタリア語、マルタ語、スペイン語、トルコ語)

ISO 8859-4

北ヨーロッパ諸国の言語(デンマーク語、英語、エストニア語、フィンランド語、ドイツ語、グリーンランド語、ラテン語、ラトビア語、リトアニア語、ノルウェー語、サーミ語、スロベニア語、スウェーデン語)

ISO 8859-5

東ヨーロッパ諸国の言語(キリル文字ベース: ブルガリア語、ベラルーシ語、マケドニア語、ロシア語、セルビア語、ウクライナ語)

ISO 8859-6

アラビア語

ISO 8859-7

ギリシア語

ISO 8859-8

ヘブライ語

ISO 8859-9

西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、コーンウォール語、デンマーク語、オランダ語、英語、フィンランド語、フランス語、フリースランド語、ガリシア語、ドイツ語、グリーンランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語、トルコ語)

ISO 8859-10

北ヨーロッパ諸国の言語(デンマーク語、英語、エストニア語、フェロー語、フィンランド語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、ラテン語、リトアニア語、ノルウェー語、サーミ語、スロベニア語、スウェーデン語)

ISO 8859-13

バルト海沿岸諸国の言語(英語、エストニア語、フィンランド語、ラテン語、ラトビア語、ノルウェー語)

ISO 8859-14

ケルト系言語(アルバニア語、バスク語、ブルトン語、カタロニア語、コーンウォール語、デンマーク語、英語、ガリシア語、ドイツ語、グリーンランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、マン島のゲール語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語、ウェールズ語)

ISO 8859-15

西ヨーロッパ諸国の言語(アルバニア語、バスク語、ブルトン語、カタロニア語、デンマーク語、オランダ語、英語、エストニア語、フェロー語、フィンランド語、フランス語、フリースランド語、ガルシア語、ドイツ語、グリーンランド語、アイスランド語、アイルランドのゲール語、イタリア語、ラテン語、ルクセンブルク語、ノルウェー語、ポルトガル語、レートロマンス語、スコットランドのゲール語、スペイン語、スウェーデン語)

これまで、キャラクタ・セットは、多言語を制限付きでサポートしてきました。この制限とは、類似するスクリプトに基づく言語グループにかぎりサポートしてきたという意味です。最近では、ユニバーサル・キャラクタ・セットが、多言語サポートのための有効なソリューションになってきました。Unicodeは、このようなユニバーサル・キャラクタ・セットの1つで、現代の主要なスクリプトのほとんどを包含しています。バージョン5.0の時点で、Unicodeは99,000文字以上をサポートしています。

関連項目:
第6章「Unicodeを使用した多言語データベースのサポート」

文字のエンコード方法

コンピュータ業界では、様々なタイプのコード体系が作成されてきました。選択するキャラクタ・セットによって、使用するコード体系の種類が異なります。コード体系には様々なパフォーマンス特性があります。これらの特性は、データベース・スキーマやアプリケーションの開発に影響を及ぼす場合があります。選択したキャラクタ・セットは、次のコード体系のいずれかを使用します。

- シングルバイト・コード体系

- マルチバイト・コード体系

シングルバイト・コード体系

シングルバイト・コード体系は効率的です。シングルバイトの1文字は1バイトで表現されるため、文字を表現するのに必要な領域量が最も小さく、処理およびプログラミングでの使用が容易です。シングルバイト・コード体系は、次のいずれかのタイプとして分類されます。

- 7ビット・コード体系
シングルバイト7ビット・コード体系は、128文字までの文字を定義でき、通常、1つの言語のみをサポートします。最も一般的なシングルバイト・キャラクタ・セットは、ASCII(American Standard Code for Information Interchange)で、コンピュータ処理の初期から使用されています。

- 8ビット・コード体系

シングルバイト8ビット・コード体系は、256文字までの文字を定義でき、通常、1つの関連言語グループをサポートします。たとえば、ISO 8859-1は、西ヨーロッパ諸国の多数の言語をサポートしています。図2-1に、ISO 8859-1の8ビット・コード体系を示します。

図2-1 ISO 8859-1の8ビット・コード体系

マルチバイト・コード体系

マルチバイト・コード体系は、中国語や日本語のようなアジア言語の表意文字をサポートするために必要です。これは、中国語や日本語では何千という文字が使用されるためです。このコード体系では、各文字を表現するために固定または可変のバイト数を使用します。

- 固定幅マルチバイト・コード体系
固定幅マルチバイト・コード体系では、各文字が固定のバイト数で表現されます。マルチバイト・コード体系では、バイト数は2以上です。

- 可変幅マルチバイト・コード体系

可変幅コード体系は、1バイト以上を使用して1つの文字を表現します。一部のマルチバイト・コード体系は、特定のビットを使用して、1文字を表現するためのバイト数を示します。たとえば、1文字の表現に使用する最大のバイト数が2バイトの場合は、最上位ビットを使用して、そのバイトがシングルバイト文字であるか、ダブルバイト文字の1番目のバイトであるかを示します。

- シフト・センシティブ可変幅マルチバイト・コード体系
一部の可変幅コード体系では、制御コードを使用して、同じコード値を持つシングルバイト文字とマルチバイト文字が区別されます。シフトアウト・コードは後続の文字がマルチバイトであることを示します。シフトイン・コードは後続の文字がシングルバイトであることを示します。シフト・センシティブ・コード体系は、主にIBMプラットフォームで使用されます。ISO-2022キャラクタ・セットは、データベース・キャラクタ・セットとしては使用できませんが、メール・サーバーなどのアプリケーションには使用できることに注意してください。

Oracle Databaseキャラクタ・セットのネーミング規則

Oracleデータベースのキャラクタ・セット名には、次のネーミング規則が使用されます。

<region><number of bits used to represent a character><standard character set name>[S|C]

名前のうち山カッコで囲まれた各部は連結されます。オプションのSまたはCを使用して、サーバー(S)またはクライアント(C)でのみ使用できるキャラクタ・セットを区別します。

注意:
次の点に注意してください。

- Macintoshプラットフォームではサーバー・キャラクタ・セット(S)を使用する必要があります。Macintoshのクライアント・キャラクタ・セットは、現在使用されていません。EBCDICプラットフォームでは、サーバー上ではサーバー・キャラクタ・セット(S)、クライアント上ではクライアント・キャラクタ・セット(C)を使用します。

- UTF8およびUTFEは、このネーミング規則の例外です。

表2-4に、Oracle Databaseのキャラクタ・セット名の例を示します。

表2-4 Oracle Databaseのキャラクタ・セット名の例

Oracle Databaseのキャラクタ・セット名

説明

地域

1文字の表現に使用されるビット数

標準キャラクタ・セット名

US7ASCII

U.S. 7ビットASCII

米国

7

ASCII

WE8ISO8859P1

西ヨーロッパ8ビットISO 8859 Part1

WE(西ヨーロッパ)

8

ISO8859の第1部

JA16SJIS

日本語16ビットシフトJIS

JA

16

SJIS

長さセマンティクス

シングルバイト・キャラクタ・セットの場合、文字列のバイト数と文字数は同じです。マルチバイト・キャラクタ・セットの場合は、1文字または1つのコード・ポイントが1つ以上のバイトで構成されています。可変幅キャラクタ・セットの場合は、バイト長に基づく文字数の計算が困難な場合があります。列の長さをバイト数単位で計算することをバイト・セマンティクス、文字数単位で計算することをキャラクタ・セマンティクスと呼びます。

キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の記憶要件を定義する場合に役立ちます。たとえば、Unicodeデータベース(AL32UTF8)で、VARCHAR2列を英語の5文字とともに最大5文字の中国語文字を格納できるように定義する必要があるとします。バイト・セマンティクスを使用すると、この列には、長さ3バイトである中国語文字用に15バイトと、長さ1バイトである英語文字用に5バイト、合計20バイトが必要です。キャラクタ・セマンティクスを使用すると、この列に必要な文字数は10となります。

次の式では、バイト・セマンティクスが使用されています。

- VARCHAR2(20 BYTE)

- SUBSTRB(string, 1, 20)

VARCHAR2式のBYTE修飾子とSQL関数名のB接尾辞に注意してください。

次の式では、キャラクタ・セマンティクスが使用されています。

- VARCHAR2(10 CHAR)

- SUBSTR(string, 1, 10)

VARCHAR2式のCHAR修飾子に注意してください。

文字データ型の列、ユーザー定義タイプ属性、PL/SQL変数の長さセマンティックスは、それぞれの定義でBYTEまたはCHAR修飾子を使用して明示的に指定できます。DDL文の作成で必要なセマンティックスが正しく記述され、DDL文が実行環境に非依存になるため、この方法で長さセマンティックスを指定することをお薦めします。

列、ユーザー定義タイプ属性またはPL/SQL変数の定義にBYTE修飾子もCHAR修飾子も含まれない場合、列、属性または変数に関連する長さセマンティックスは、セッション・パラメータNLS_LENGTH_SEMANTICSの値によって決定されます。レガシー・スクリプトを使用してデータベース・オブジェクトを作成する際、そのスクリプトが非常に大きく複雑で明示的にBYTEまたはCHAR修飾子を含めて更新できない場合、必要なセマンティックスでオブジェクトが作成されるように、各スクリプトを実行する前に明示的にALTER SESSION SET NLS_LENGTH_SEMANTICS文を実行します。

NLS_LENGTH_SEMANTICS初期化パラメータは、新しいセッションのNLS_LENGTH_SEMANTICSセッション・パラメータのデフォルト値を決定します。デフォルト値はBYTEです。Oracle SQLにキャラクタ長さセマンティックスが導入される前に記述された可能性のある既存のアプリケーション・インストール手順と互換性を保つために、この初期化パラメータを未定義のままにするか、BYTEに設定することをお薦めします。そうでない場合、作成された列が予想よりも大きいために、アプリケーション障害が発生したり、場合によってはバッファ・オーバーフローが発生する可能性があります。

バイト・セマンティクスは、データベース・キャラクタ・セットのデフォルトです。文字長セマンティクスはNCHARデータ型のデフォルトであり、このデータ型に使用できる唯一の長さセマンティクスです。NCHARの定義には、CHARまたはBYTE修飾子を指定できません。

次の例を考えてみます。

CREATE TABLE employees

( employee_id NUMBER(4)
, last_name NVARCHAR2(10)
, job_id NVARCHAR2(9)
, manager_id NUMBER(4)
, hire_date DATE
, salary NUMBER(7,2)
, department_id NUMBER(2)
) ;

NCHARのキャラクタ・セットがAL16UTF16の場合、last_nameに保持できるのは最大10個のUnicodeコード・ポイントです。NCHARのキャラクタ・セットがAL16UTF16の場合、last_nameに保持できるのは最大20バイトです。

図2-2に、UTF-8キャラクタ・セットで各種文字を格納するために必要なバイト数を示します。ASCII文字には1バイト、ラテン語文字とギリシャ語文字には2バイト、アジア言語の文字には3バイト、補助文字には4バイトの記憶域が必要です。

図2-2 各種文字の格納バイト数

関連項目:

- SUBSTRおよびSUBSTRB関数の詳細は、「様々な長さセマンティクスに使用するSQL関数」を参照してください。

- NLS_LENGTH_SEMANTICS初期化パラメータの詳細は、「長さセマンティクス」を参照してください。

- UnicodeとNCHARデータ型の詳細は、第6章「Unicodeを使用した多言語データベースのサポート」を参照してください。

- SUBSTRBおよびSUBSTR関数と文字型データのBYTEおよびCHAR修飾子の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Databaseキャラクタ・セットの選択

Oracleデータベースでは、次の項目でデータベース・キャラクタ・セットを使用します。

- SQL CHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)で格納されるデータ

- 表名、列名およびPL/SQL変数などの識別子

- SQLとPL/SQLのソース・コードの入力と格納

データベースで使用される文字コード体系は、CREATE DATABASE文の一部として定義されます。データ・ディクショナリ内の列を含めて、すべてのSQL CHARデータ型列(CHAR、CLOB、VARCHAR2およびLONG)のデータは、データベース・キャラクタ・セットに格納されます。さらに、選択するデータベース・キャラクタ・セットによって、データベース内のオブジェクトに名前を指定できる文字が決定されます。SQL NCHARデータ型列(NCHAR、NCLOBおよびNVARCHAR2)では、各国語キャラクタ・セットが使用されます。

データベースの作成後は、一部の例外を除いて、データベースを再作成せずにキャラクタ・セットを変更することはできません。

データベース用のOracle Databaseキャラクタ・セットを選択する場合は、次の項目について考慮する必要があります。

- データベースでサポートする必要がある言語

- データベースで将来サポートが必要になる言語

- キャラクタ・セットがオペレーティング・システムで使用可能かどうか

- クライアントで使用するキャラクタ・セット

- そのキャラクタ・セットがアプリケーションで適切に処理されるかどうか

- キャラクタ・セットがパフォーマンスに与える影響

- キャラクタ・セットに関連付けられている制限

Oracle Databaseキャラクタ・セットのリストは、「キャラクタ・セット」を参照してください。Oracleキャラクタ・セット名は、言語とそれが使用される地域に基づいています。地域名が付いている一部のキャラクタ・セットは、リストに言語でも明示的に示されています。

あるキャラクタ・セットに含まれている文字を確認するには、次の方法があります。

- 各国製品、国際的製品またはベンダー製品のドキュメントあるいは規格ドキュメントをチェックします。

- Oracle Locale Builderを使用します。

この項の内容は、次のとおりです。

- 現在および将来の言語要件

- クライアントのオペレーティング・システムとアプリケーションの互換性

- クライアントとサーバーの間のキャラクタ・セット変換

- データベース・キャラクタ・セットの選択がパフォーマンスに与える影響

- データベース・キャラクタ・セットに関する制限事項

- 各国語キャラクタ・セットの選択

- サポート対象のデータ型の概要

関連項目:

- 「UCS-2エンコーディング」

- 「各国語キャラクタ・セットの選択」

- 「データベース作成後のキャラクタ・セットの変更」

- 付録A「ロケール・データ」

- 第13章「ロケール・データのカスタマイズ」

現在および将来の言語要件

複数のキャラクタ・セットを使用して現在の言語要件を満たすことができる可能性があります。データベース・キャラクタ・セットの選択時には、将来の言語要件を考慮してください。将来、追加の言語サポートが必要になると思われる場合は、後で異なるキャラクタ・セットへの移行が必要にならないように、その言語をサポートしているキャラクタ・セットを選択します。

クライアントのオペレーティング・システムとアプリケーションの互換性

Oracleデータベースには独自のグローバリゼーション・アーキテクチャがあるため、データベース・キャラクタ・セットはオペレーティング・システムに依存しません。たとえば、英語版Windowsオペレーティング・システムで、日本語キャラクタ・セットを使用してデータベースを作成し、稼働させることができます。ただし、クライアントのオペレーティング・システム上のアプリケーションがそのデータベースにアクセスするには、適切なフォントと入力メソッドでデータベース・キャラクタ・セットをサポートできる必要があります。たとえば、英語版Windowsオペレーティング・システムでは、先に日本語フォントと入力メソッドをインストールしなければ、日本語データの挿入や取出しができません。日本語のデータを挿入および取得するもう1つの方法として、リモートで日本語オペレーティング・システムを使用してデータベース・サーバーにアクセスする方法もあります。

クライアントとサーバーの間のキャラクタ・セット変換

クライアントのオペレーティング・システム上のキャラクタ・セットと異なるデータベース・キャラクタ・セットを選択した場合、Oracleデータベースでは、オペレーティング・システムのキャラクタ・セットをデータベース・キャラクタ・セットに変換できます。キャラクタ・セット変換には、次のデメリットがあります。

- データ消失の可能性

- オーバーヘッドの増加

キャラクタ・セット変換がデータ消失の原因になる場合があります。たとえば、キャラクタ・セットAをキャラクタ・セットBに変換する場合、変換先のキャラクタ・セットBには、Aと同じキャラクタ・セット・レパートリが含まれている必要があります。キャラクタ・セットBで使用できない文字は、置換文字に変換されます。この置換文字は、多くの場合、疑問符や言語的に関連する文字で指定されます。たとえば、ä(ウムラウト付きのa)は、aに変換できます。分散環境の場合には、類似した文字レパートリを持つキャラクタ・セットを使用してデータ消失を回避してください。

キャラクタ・セット変換では、データがクライアントに到達するまでに文字列が何度もバッファ間でコピーされる場合があります。データベース・キャラクタ・セットは、常に、クライアントのオペレーティング・システム固有のキャラクタ・セットと同等か、そのスーパーセットである必要があります。通常は、データベースにアクセスするクライアント・アプリケーションのキャラクタ・セットによって、最適なスーパーセットが決定します。

すべてのクライアント・アプリケーションが同じキャラクタ・セットを使用している場合は、そのキャラクタ・セットが、通常、データベース・キャラクタ・セットとして最善の選択肢です。複数のクライアント・アプリケーションが異なるキャラクタ・セットを使用している場合、データベース・キャラクタ・セットは、クライアントのすべてのキャラクタ・セットのスーパーセットである必要があります。これによって、クライアント・キャラクタ・セットからデータベース・キャラクタ・セットへの変換時に、すべての文字が確実に受け渡されます。

関連項目:
第11章「キャラクタ・セットの移行」

データベース・キャラクタ・セットの選択がパフォーマンスに与える影響

最適なパフォーマンスのためには、変換が不要なキャラクタ・セットを選択し、使用言語にとって最も効率的なエンコーディングを使用してください。シングルバイト・キャラクタ・セットは、パフォーマンスの点で、マルチバイト・キャラクタ・セットよりも優れており、領域要件に関しても、シングルバイト・キャラクタ・セットが最も効率的です。ただし、シングルバイト・キャラクタ・セットには、サポートできる言語の種類に制限があります。

データベース・キャラクタ・セットに関する制限事項

ASCIIベースのキャラクタ・セットがサポートされているのは、ASCIIベースのプラットフォーム上のみです。同様に、EBCDICベースのキャラクタ・セットが使用できるのは、EBCDICベースのプラットフォーム上のみです。

データベース・キャラクタ・セットは、SQLとPL/SQLソース・コードの識別に使用します。このためには、データベース・キャラクタ・セットに、プラットフォーム固有のEBCDICまたは7ビットASCIIのいずれかがサブセットとして含まれている必要があります。したがって、固定幅のマルチバイト・キャラクタ・セットをデータベース・キャラクタ・セットとして使用することはできません。現在、データベース・キャラクタ・セットとして使用できないのはAL16UTF16キャラクタ・セットのみです。

名前を表すために使用するキャラクタ・セットに関する制限事項

表2-5に、名前を表すために使用できるキャラクタ・セットに関する制限事項を示します。

表2-5 名前を表すために使用するキャラクタ・セットに関する制限事項

名前

シングルバイト

可変幅

コメント

列名

可能

可能

-

スキーマ・オブジェクト

可能

可能

-

コメント

可能

可能

-

データベース・リンク名

可能

不可

-

データベース名

可能

不可

-

ファイル名(データファイル、ログ・ファイル、制御ファイル、初期化パラメータ・ファイル)

可能

不可

-

インスタンス名

可能

不可

-

ディレクトリ名

可能

不可

-

キーワード

可能

不可

英語ASCIIまたはEBCDIC文字でのみ表現可能です。

Recovery Managerファイル名

可能

不可

-

ロールバック・セグメント名

可能

不可

ROLLBACK_SEGMENTSパラメータはNLSをサポートしていません。

ストアド・スクリプト名

可能

可能

-

表領域名

可能

不可

-

LOBデータ(LOB、BLOB、CLOBおよびNCLOB)などのサポート対象の文字列形式とキャラクタ・セットについては、表2-7を参照してください。

データベース・キャラクタ・セットに関する指示書

データベース・キャラクタ・セットとして使用するためにオラクル社が強く推奨するキャラクタ・セットのリストがコンパイルされました(表A-4「推奨するASCIIデータベース・キャラクタ・セット」および表A-5「推奨するEBCDICデータベース・キャラクタ・セット」)。このリストにない、Oracleでサポートされるその他のキャラクタ・セットは、引き続きOracle Database 11gリリース2で使用できますが、将来のリリースでサポートされなくなる可能性があります。Oracle Database 11gリリース1以降、Oracle Universal InstallerおよびOracle Database Configuration Assistantの共通インストール・パスでのデータベース・キャラクタ・セットの選択肢は、この推奨キャラクタ・セットのリストに制限されます。ただし、キャラクタ・セットが推奨リストに含まれていない場合でも、従来どおりカスタム・インストールのパスを使用して新規データベースを作成し、既存のデータベースを移行できます。ただし、できるだけ早く推奨キャラクタ・セットに移行することをお薦めします。すべての新規システム・デプロイメントについて推奨するキャラクタ・セット・リストの最上部には、Unicodeキャラクタ・セットAL32UTF8があります。

データベース・キャラクタ・セットとしてのUnicodeの選択

すべての新規システム・デプロイメントにUnicodeを使用することをお薦めします。レガシー・システムもUnicodeに移行することをお薦めします。現在システムをUnicodeでデプロイすると、利便性、互換性および拡張性の面で多くの利点があります。Oracleデータベースによって、Unicodeの利点を活かしながら高パフォーマンス・システムを高速かつ容易にデプロイできます。現時点で多言語データをサポートする必要がない場合、またはUnicodeが必要ない場合でも、長期的には新規システムに最適な選択となる可能性が高く、結局は時間を短縮してコストを節減し、競争上の優位性を得ることになります。Unicodeの詳細は、第6章「Unicodeを使用した多言語データベースのサポート」を参照してください。

各国語キャラクタ・セットの選択

各国語キャラクタ・セットとは、Unicodeデータベース・キャラクタ・セットがないデータベースにUnicodeの文字データを格納するための代替キャラクタ・セットです。その他、各国語キャラクタ・セットを選択するには次の理由があります。

- 大量の文字処理操作には、別の文字コード体系のプロパティのほうが適している場合

- 各国語キャラクタ・セットでのプログラミングのほうが容易な場合

SQL NCHAR、NVARCHAR2およびNCLOBデータ型は、Unicodeデータのみをサポートします。UTF8またはAL16UTF16キャラクタ・セットを使用できます。デフォルトはAL16UTF16です。

関連項目:
第6章「Unicodeを使用した多言語データベースのサポート」

サポート対象のデータ型の概要

表2-6に、様々なコード体系についてサポート対象のデータ型を示します。

表2-6 コード体系のサポート対象のSQLデータ型

データ型

シングルバイト

マルチバイトのUnicode以外

マルチバイトのUnicode

CHAR

可能

可能

可能

VARCHAR2

可能

可能

可能

NCHAR

不可

不可

可能

NVARCHAR2

不可

不可

可能

BLOB

可能

可能

可能

CLOB

可能

可能

可能

LONG

可能

可能

可能

NCLOB

不可

不可

可能

注意:
BLOBでは、文字は一連のバイト順序として処理されます。データは、NLSに関連した操作の対象にはなりません。

表2-7に、抽象データ型についてサポート対象のSQLデータ型を示します。

表2-7 SQLデータ型のサポート対象の抽象データ型

抽象データ型

CHAR

NCHAR

BLOB

CLOB

NCLOB

オブジェクト

可能

可能

可能

可能

可能

コレクション

可能

可能

可能

可能

可能

次のように、NCHAR属性を使用して抽象データ型を作成できます。

SQL> CREATE TYPE tp1 AS OBJECT (a NCHAR(10));
Type created.
SQL> CREATE TABLE t1 (a tp1);
Table created.

関連項目:
オブジェクトとコレクションの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

データベース作成後のキャラクタ・セットの変更

データベースの作成後に、データベース・キャラクタ・セットの変更が必要になる場合があります。たとえば、使用しているデータベースでサポートする必要がある言語数が増加する場合があります。ほとんどの場合は、全体エクスポートまたは全体インポートを行い、すべてのデータを新しいキャラクタ・セットに正しく変換する必要があります。ただし、新しいキャラクタ・セットがすべてのスキーマ・データの完全なスーパーセットである場合にかぎり、CSALTERスクリプトを使用して、データベース・キャラクタ・セット内の変更を効率よく処理できます。

関連項目:

- 第11章「キャラクタ・セットの移行」

- データのエクスポートとインポートの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

- データベースがオンラインの間に、Streamsを使用してデータベースのキャラクタ・セットを変更する方法は、『Oracle Streams概要および管理』を参照してください。

単一言語データベースの使用例

最も単純なデータベース構成の例は、クライアントとサーバーが同じ言語環境で稼働し、同じキャラクタ・セットを使用している場合です。この単一言語の使用例には、レスポンスが高速であるという利点があります。これは、キャラクタ・セット変換に関連するオーバーヘッドが回避されるためです。図2-3に、同じキャラクタ・セットを使用するデータベース・サーバーとクライアントを示します。日本語クライアントとサーバーの両方が、JA16EUCキャラクタ・セットを使用しています。

図2-3 単一言語データベースの使用例

また、複数層アーキテクチャも使用できます。図2-4に、データベース・サーバーとクライアントの間にあるアプリケーション・サーバーを示します。アプリケーション・サーバーとデータベース・サーバーは、単一言語の使用例と同じキャラクタ・セットを使用しています。サーバー、アプリケーション・サーバーおよびクライアントは、JA16EUCキャラクタ・セットを使用しています。

図2-4 複数層の単一言語データベースの使用例

単一言語の使用例でのキャラクタ・セット変換

クライアント/サーバー環境では、クライアント・アプリケーションがサーバーと異なるプラットフォームにある場合や、プラットフォームで同じ文字コード体系が使用されていない場合に、キャラクタ・セット変換が必要になります。クライアントとサーバーの間で受け渡される文字データは、2つのコード体系間で変換される必要があります。文字の変換は、Oracle Netを介して、ユーザーが意識することなく自動的に実行されます。

任意の2つのキャラクタ・セット間で変換を行うことができます。図2-5に、サーバーと日本語JA16EUCキャラクタ・セットを使用している1つのクライアントを示します。他方のクライアントは、日本語JA16SJISキャラクタ・セットを使用しています。

図2-5 キャラクタ・セットの変換

ターゲットのキャラクタ・セットにソース・データにあるすべての文字がない場合は、置換文字が使用されます。たとえば、サーバーではUS7ASCIIを、ドイツ語クライアントではWE8ISO8859P1を使用している場合、ドイツ語の文字ßは?に置換され、äはaに置換されます。

置換文字は、キャラクタ・セットの定義の一部として、特定の文字に対して定義できます。特定の置換文字を定義しないと、デフォルトの置換文字が使用されます。クライアント・キャラクタ・セットからデータベース・キャラクタ・セットへの変換時に置換文字を使用しないようにするには、サーバーのキャラクタ・セットが、クライアントのすべてのキャラクタ・セットのスーパーセットである必要があります。

図2-6に、データベース・キャラクタ・セットにクライアント・キャラクタ・セットのすべての文字が含まれていない場合に発生するデータ消失を示します。データベース・キャラクタ・セットはUS7ASCIIです。クライアントのキャラクタ・セットはWE8MSWIN1252で、クライアントの使用言語はドイツ語です。クライアントがßを含む文字列を挿入すると、データベースではßが?に置換され、データが消失します。

図2-6 文字変換中のデータ消失

ドイツ語データがサーバーに格納されると想定される場合は、データ消失と変換オーバーヘッドを回避するために、サーバーとクライアントの両方で、ドイツ語文字をサポートするデータベース・キャラクタ・セットを使用する必要があります。

キャラクタ・セットの一方が可変幅マルチバイト・キャラクタ・セットの場合は、変換によって著しいオーバーヘッドが生じる可能性があります。状況を慎重に評価した上でキャラクタ・セットを選択し、変換をできるかぎり回避する必要があります。

多言語データベースの使用例

多言語サポートには、制限付きと無制限があります。この項の内容は、次のとおりです。

- 制限付き多言語サポート

- 無制限多言語サポート

制限付き多言語サポート

一部のキャラクタ・セットでは、関連する記述法やスクリプトがあるため、多言語がサポートされます。たとえば、Oracleデータベースのキャラクタ・セットWE8ISO8859P1は、次の西ヨーロッパ諸国の言語をサポートしています。

カタロニア語

デンマーク語

オランダ語

英語

フィンランド語

フランス語

ドイツ語

アイスランド語

イタリア語

ノルウェー語

ポルトガル語

スペイン語

スウェーデン語

これらの言語は、いずれもラテン語ベースの記述文字を使用します。

言語グループをサポートするキャラクタ・セットを使用する場合、データベースは制限付き多言語サポート機能を持つことになります。

図2-7に、Oracleデータベース・キャラクタ・セットWE8ISO8850P1を使用する西ヨーロッパ言語のサーバー、サーバーと同じキャラクタ・セットを使用するフランス語クライアントおよびWE8DECキャラクタ・セットを使用するドイツ語クライアントします。ドイツ語クライアントは、サーバーと異なるキャラクタ・セットを使用しているため、文字変換が必要です。

図2-7 制限付き多言語サポート

無制限多言語サポート

無制限多言語サポートが必要な場合は、サーバーのデータベース・キャラクタ・セットにUnicodeなどのユニバーサル・キャラクタ・セットを使用します。Unicodeには、主に次の2つのコード体系があります。

- UTF-16: 各文字は長さ2バイトまたは4バイトです。

- UTF-8: 各文字の格納には1から4バイト必要です。

Oracle Databaseでは、データベース・キャラクタ・セットとしてUTF-8が、各国語キャラクタ・セットとしてUTF-8とUTF-16の両方がサポートされています。

UTF-8のデータベースとシングルバイト・キャラクタ・セットとの間でのキャラクタ・セット変換では、ごくわずかなオーバーヘッドが生じます。

UTF-8とマルチバイト・キャラクタ・セットとの間での変換では、多少のオーバーヘッドが生じます。変換によるデータ消失はありませんが、これには次の例外があります。

- 一部のマルチバイト・キャラクタ・セットは、UTF-8との間のキャラクタ・セット変換で、ユーザー定義文字をサポートしていません。

- 一部のUnicode文字は、他のキャラクタ・セットで複数文字にマップされます。たとえば、1つのUnicode文字はJA16SJISキャラクタ・セットの3文字にマップされます。これは、ラウンドトリップ変換でオリジナルのJA16SJIS文字に変換されない場合があることを意味します。

図2-8に、Unicode UTF-8キャラクタ・セットに基づくOracleデータベース・キャラクタ・セットAL32UTF8を使用するサーバーを示します。

図2-8 クライアント/サーバー構成での無制限多言語サポートの使用例

次の4つのクライアントがあるとします。

- Oracle Databaseのキャラクタ・セットWE8ISO8859P1を使用するフランス語クライアント

- WE8DECキャラクタ・セットを使用するドイツ語クライアント

- JA16EUCキャラクタ・セットを使用する日本語クライアント

- JA16SJISキャラクタ・セットを使用する日本語クライアント

各クライアントとサーバーの間で文字変換が発生しますが、AL32UTF8がユニバーサル・キャラクタ・セットであるためデータ消失は生じません。ドイツ語クライアントが日本語クライアントの1つからデータを取り出そうとすると、キャラクタ・セット変換中にデータに含まれる日本語文字がすべて消失します。

図2-9に、複数層構成でのUnicodeソリューションを示します。

図2-9 複数層構成での複数層の無制限多言語サポートの使用例

データベース、アプリケーション・サーバーおよび各クライアントは、AL32UTF8キャラクタ・セットを使用しています。このため、クライアントがフランス語、ドイツ語および日本語であっても、文字変換を行う必要はありません。

関連項目:
第6章「Unicodeを使用した多言語データベースのサポート」

3 グローバリゼーション・サポート環境の設定

この章では、グローバリゼーション・サポート環境の設定方法について説明します。内容は次のとおりです。

- NLSパラメータの設定

- 環境変数NLS_LANGを使用したロケールの選択

- キャラクタ・セット・パラメータ

- NLSデータベース・パラメータ

- 言語および地域のパラメータ

- 日付および時間を指定するパラメータ

- カレンダ定義

- 数値パラメータとリスト・パラメータ

- 通貨パラメータ

- 言語ソート・パラメータ

- キャラクタ・セット変換パラメータ

- 長さセマンティクス

NLSパラメータの設定

NLS(National Language Support)パラメータによって、クライアントとサーバーの両方でのロケール固有の動作が決定します。NLSパラメータは、次の4通りの方法で指定できます。

- サーバー上の初期化パラメータとして指定します。
パラメータを初期化パラメータ・ファイルに含めて、デフォルトのセッションNLS環境を指定できます。この設定は、クライアント側には影響を与えません。サーバーの動作のみを制御します。次に例を示します。

NLS_TERRITORY = "CZECH REPUBLIC"

- クライアントの環境変数として指定します。
NLS環境変数(プラットフォーム依存の場合があります)を使用して、クライアントに対してロケールに依存する動作を指定できます。また、初期化パラメータ・ファイルでセッションに設定されているデフォルト値をオーバーライドできます。UNIXシステムでの例を示します。

% setenv NLS_SORT FRENCH

- ALTER SESSION文を使用して指定します。
ALTER SESSION文に設定されているNLSパラメータを使用すると、初期化パラメータ・ファイルのセッションに設定されたデフォルト値や環境変数を使用してクライアントで設定したデフォルト値をオーバーライドできます。

ALTER SESSION SET NLS_SORT = FRENCH;

関連項目:
ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- SQL関数内で指定します。
NLSパラメータを明示的に使用すると、SQL関数内でのNLS動作をハードコード化できます。これによって、初期化パラメータ・ファイルのセッションに設定されたデフォルト値、環境変数を使用してクライアントで設定されたデフォルト値、またはALTER SESSIONによってセッションに設定されたデフォルト値がオーバーライドされます。次に例を示します。

TO_CHAR(hiredate, 'DD/MON/YYYY', 'nls_date_language = FRENCH')

関連項目:
TO_CHAR関数などのSQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表3-1に、NLSパラメータの各種設定方法の優先順位を示します。優先順位の低い設定は、優先順位の高い設定によってオーバーライドされます。たとえば、デフォルト値の優先順位が最も低く、他のすべての方法でオーバーライドされます。

表3-1 NLSパラメータの設定方法とその優先順位

優先順位

方法

1(最も高い優先順位)

SQL関数での明示的な設定

2

ALTER SESSION文による設定

3

環境変数としての設定

4

初期化パラメータ・ファイル内での指定

5

デフォルト

表3-2に、使用可能なNLSパラメータを示します。SQL関数のNLSパラメータを指定するには特定の関数を使用する必要があるため、この表にはSQL関数の有効範囲は示されていません。

表3-2 NLSパラメータ

パラメータ

説明

デフォルト

有効範囲: I = 初期化パラメータ・ファイル E = 環境変数 A = ALTER SESSION

NLS_CALENDAR

暦法

Gregorian(グレゴリオ暦)

I、E、A

NLS_COMP

SQL、PL/SQL演算子の比較

BINARY

I、E、A

NLS_CREDIT

貸方の会計記号

NLS_TERRITORYから導出

E

NLS_CURRENCY

各国通貨記号

NLS_TERRITORYから導出

I、E、A

NLS_DATE_FORMAT

日付書式

NLS_TERRITORYから導出

I、E、A

NLS_DATE_LANGUAGE

曜日名と月名に使用する言語

NLS_LANGUAGEから導出

I、E、A

NLS_DEBIT

借方の会計記号

NLS_TERRITORYから導出

E

NLS_ISO_CURRENCY

ISO国際通貨記号

NLS_TERRITORYから導出

I、E、A

NLS_LANG

関連項目: 「環境変数NLS_LANGを使用したロケールの選択」

言語、地域、キャラクタ・セット

AMERICAN_AMERICA. US7ASCII

E

NLS_LANGUAGE

言語

NLS_LANGから導出

I、A

NLS_LENGTH_SEMANTICS

文字列の処理方法

BYTE

I、E、A

NLS_LIST_SEPARATOR

リスト内項目の区切り文字

NLS_TERRITORYから導出

E

NLS_MONETARY_CHARACTERS

ドルとセント(または相当する通貨)に使用する通貨記号

NLS_TERRITORYから導出

E

NLS_NCHAR_CONV_EXCP

文字列型変換時のデータ消失のレポート

FALSE

I、A

NLS_NUMERIC_CHARACTERS

小数点文字とグループ・セパレータ

NLS_TERRITORYから導出

I、E、A

NLS_SORT

文字のソート基準

NLS_LANGUAGEから導出

I、E、A

NLS_TERRITORY

地域

NLS_LANGから導出

I、A

NLS_TIMESTAMP_FORMAT

タイムスタンプ

NLS_TERRITORYから導出

I、E、A

NLS_TIMESTAMP_TZ_FORMAT

タイム・ゾーン付きのタイムスタンプ

NLS_TERRITORYから導出

I、E、A

NLS_DUAL_CURRENCY

第2通貨記号

NLS_TERRITORYから導出

I、E、A

環境変数NLS_LANGを使用したロケールの選択

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

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

NLS_LANGパラメータには、3つのコンポーネント、language、territoryおよびcharsetがあります。このパラメータは、句読点を含めて次の書式で指定します。

NLS_LANG = language_territory.charset

たとえば、Oracle InstallerでNLS_LANGが移入されない場合、その値はデフォルトでAMERICAN_AMERICA.US7ASCIIとなります。この場合のlanguageはAMERICAN、territoryはAMERICA、charsetはUS7ASCIIです。NLS_LANGおよびその他のNLSパラメータの値は、大/小文字を区別しません。

NLS_LANGパラメータの各コンポーネントによって、グローバリゼーション・サポート機能のサブセットの操作が制御されます。

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

- territory
デフォルトの日付、通貨単位および数値書式などの規則を指定します。各サポート対象地域には、AMERICA、FRANCEまたはCANADAなどの一意の名前が付いています。territoryを指定しない場合、値はlanguageの値から導出されます。

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

注意:
NLS_LANG定義のコンポーネントはすべてオプションです。未指定の項目にはデフォルト値が使用されます。territoryまたはcharsetを指定する場合は、先行デリミタを付ける必要があります。先行デリミタは、territoryの場合はアンダースコア(_)で、charsetの場合はピリオド(.)です。先行デリミタを付けないと、値は言語名として解析されます。
たとえば、NLS_LANGの地域部分のみを設定するには、書式NLS_LANG=_JAPANを使用します。

NLS_LANGの3つのコンポーネントは、次の例のように、様々な組合せで指定できます。

NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252

NLS_LANG = FRENCH_CANADA.WE8ISO8859P1

NLS_LANG = JAPANESE_JAPAN.JA16EUC

非論理的な組合せも設定できますが、正しく動作しません。たとえば、次の指定では、西ヨーロッパ諸国のキャラクタ・セットを使用して日本語をサポートしようとしています。

NLS_LANG = JAPANESE_JAPAN.WE8ISO8859P1

WE8ISO8859P1キャラクタ・セットでは日本語文字がサポートされないため、この定義をNLS_LANGに使用すると日本語データを格納および表示できません。

これ以降の内容は、次のとおりです。

- NLS_LANGの値の指定

- 言語指定と地域指定のオーバーライド

- ロケールのバリアント

関連項目:

- サポート対象のすべての言語、地域およびキャラクタ・セットのリストは、付録A「ロケール・データ」を参照してください。

- プラットフォームに必要な追加のグローバリゼーション設定の詳細は、ご使用のオペレーティング・システムのマニュアルを参照してください。

NLS_LANGの値の指定

UNIXオペレーティング・システムのCシェル・セッション上では、次の例のような文を入力して、NLS_LANGの値を指定できます。

% setenv NLS_LANG FRENCH_FRANCE.WE8ISO8859P1

NLS_LANGは環境変数であるため、クライアント・アプリケーションによって起動時に読み込まれます。クライアントは、NLS_LANGによって定義された情報を、データベース・サーバーへの接続時にサーバーに送信します。

次の例では、日付および数値の書式がNLS_LANGパラメータによってどのように影響を受けるかを示します。

例3-1 NLS_LANGをAmerican_America.WE8ISO8859P1に設定する場合

言語がAMERICAN、地域がAMERICA、Oracleキャラクタ・セットがWE8ISO8859P1となるように、NLS_LANGを設定します。

% setenv NLS_LANG American_America.WE8ISO8859P1

SELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のような出力になります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30-SEP-05      962.5
Urman                     07-MAR-06        975
Popp                      07-DEC-07      862.5
...

例3-2 NLS_LANGをFrench_France.WE8ISO8859P1に設定する場合

言語がFRENCH、地域がFRANCE、Oracle Databaseキャラクタ・セットがWE8ISO8859P1となるように、NLS_LANGを設定します。

% setenv NLS_LANG French_France.WE8ISO8859P1

例3-1に示した問合せでは、次の出力が戻されます。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- ---------  ---------
...
Sciarra                   30/09/05       962,5
Urman                     07/03/06         975
Popp                      07/12/07       862,5
...

日付書式と数値書式が変更されていることに注意してください。基礎となるデータは同じであるため、数値に変更はありません。

言語指定と地域指定のオーバーライド

NLS_LANGパラメータは、サーバー・セッション(SQLコマンドの実行など)とクライアント・アプリケーション(Oracle Databaseのツール製品での書式設定表示など)の両方で使用する言語と地域の環境を設定します。このパラメータを使用することで、データベースとクライアント・アプリケーションの言語環境が自動的に同じになります。

NLS_LANGパラメータのlanguageコンポーネントとterritoryコンポーネントによって、他の詳細なNLSパラメータ(日付書式、数字および言語ソートなど)のデフォルト値が決定されます。NLS_LANGパラメータがすでに設定されている場合は、これらの詳細パラメータをそれぞれクライアント環境で設定してデフォルト値をオーバーライドできます。

NLS_LANGパラメータを設定しない場合、サーバー・セッション環境は、初期化パラメータ・ファイルのNLS_LANGUAGE、NLS_TERRITORYおよび他のNLSインスタンスのパラメータの値によって初期化された状態のままです。これらのパラメータを変更して、インスタンスを再起動すると、デフォルト値を変更できます。

セッション中にNLS環境の動的な変更が必要な場合があります。その場合は、ALTER SESSION文を使用してNLS_LANGUAGE、NLS_TERRITORYおよび他のNLSパラメータを変更できます。

注意:
クライアント・キャラクタ・セットの設定は、ALTER SESSION文では変更できません。

ALTER SESSION文が変更するのは、セッション環境のみです。ローカル・クライアントのNLS環境は、クライアントが新しい設定を明示的に取得してローカル環境を変更しないかぎり、変更されません。

関連項目:

- 「セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド」

- 『Oracle Database SQL言語リファレンス』

ロケールのバリアント

Oracle Database 10gまでのOracleでは、言語と地域が別々に定義されていました。このため、地域定義はユーザーの言語設定から独立していました。Oracle Database 10g以降、ユーザーの言語設定に基づいて一部の地域に異なる日付、時刻、数値および通貨書式を使用できます。この種の言語依存の地域定義をロケールのバリアントと呼びます。

バリアントを正常に動作させるには、NLS_TERRITORYおよびNLS_LANGUAGEの両方を指定する必要があります。

表3-3に、バリアントをサポートするように拡張されている地域を示します。

表3-3 Oracle Databaseのロケールのバリアント

Oracle Databaseの地域

Oracle Databaseの言語

BELGIUM

DUTCH

BELGIUM

FRENCH

BELGIUM

GERMAN

CANADA

FRENCH

CANADA

ENGLISH

DJIBOUTI

FRENCH

DJIBOUTI

ARABIC

FINLAND

FINLAND

FINLAND

SWEDISH

HONG KONG

TRADITIONAL CHINESE

HONG KONG

ENGLISH

INDIA

ENGLISH

INDIA

ASSAMESE

INDIA

BANGLA

INDIA

GUJARATI

INDIA

HINDI

INDIA

KANNADA

INDIA

MALAYALAM

INDIA

MARATHI

INDIA

ORIYA

INDIA

PUNJABI

INDIA

TAMIL

INDIA

TELUGU

LUXEMBOURG

GERMAN

LUXEMBOURG

FRENCH

SINGAPORE

ENGLISH

SINGAPORE

MALAY

SINGAPORE

SIMPLIFIED CHINESE

SINGAPORE

TAMIL

SWITZERLAND

GERMAN

SWITZERLAND

FRENCH

SWITZERLAND

ITALIAN

NLS_LANG設定とデータベース・キャラクタ・セットを一致させる必要があるかどうか

NLS_LANGのキャラクタ・セットには、クライアントのオペレーティング・システムのキャラクタ・セットの設定を反映させる必要があります。たとえば、データベース・キャラクタ・セットがAL32UTF8で、クライアントのオペレーティング・システムがWindowsの場合、UTF8 WIN32クライアントはないため、NLS_LANGパラメータではクライアント・キャラクタ・セットとしてAL32UTF8を設定しないでください。かわりに、NLS_LANG設定にクライアントのコード・ページを反映する必要があります。たとえば、英語版Windowsクライアントでは、コード・ページは1252です。NLS_LANGの適切な設定は、AMERICAN_AMERICA.WE8MSWIN1252です。

NLS_LANGを適切に設定すると、クライアント・オペレーティング・システムのキャラクタ・セットからデータベース・キャラクタ・セットへと適切に変換できます。これらの設定が同じときは、Oracle Databaseによって、送受信されるデータはデータベース・キャラクタ・セットと同一のキャラクタ・セットでエンコードされているとみなされるため、キャラクタ・セットの妥当性チェックや変換が行われない場合があります。このため、クライアントのコード・ページとデータベース・キャラクタ・セットが異なっていて、変換が必要な場合は、データが破損する可能性があります。

関連項目:
WindowsでNLS_LANGパラメータに一般に使用できる値の詳細は、『Oracle Databaseインストレーション・ガイド for Microsoft Windows』を参照してください。

キャラクタ・セット・パラメータ

Oracleには、クライアントのOSキャラクタ・セットがOracle NLSクライアントのキャラクタ・セットと異なる場合に対処するために、環境変数NLS_OS_CHARSETが用意されています。

NLS_OS_CHARSET環境変数

クライアントのOSキャラクタ・セットがNLS_LANG環境変数で指定されるOracle NLSクライアントのキャラクタ・セットと異なる場合は、Oracleクライアントのインストール環境でNLS_OS_CHARSET環境変数を設定する必要があります。クライアントのOSキャラクタ・セットは、マシン名、プログラムの実行ファイル名およびログインしているユーザー名などのOSフィールド内の文字を表すために使用されるキャラクタ・セットです。UNIXプラットフォームの場合、このキャラクタ・セットは通常LANG環境変数またはLC_ALL環境変数で指定されます。NLS_OS_CHARSETを設定する場合の一例をあげると、LinuxクライアントのLANGまたはLC_ALLで指定されるロケールのキャラクタ・セットがzh_CN(簡体字中国語)で、NLS_LANGで指定されるOracleクライアント・アプリケーションのキャラクタ・セットがUTF8の場合です。この場合、NLS_OS_CHARSET変数を、対応するOracleキャラクタ・セットZHT16GBKに設定する必要があります。

NLS_OS_CHARSET環境変数は、クライアントのOSキャラクタ・セットに対応するOracleのキャラクタ・セット名に設定する必要があります。

NLS_LANGがOSキャラクタ・セットに対応する場合、NLS_OS_CHARSETを設定する必要はありません。WindowsプラットフォームではNLS_OS_CHARSETの設定は不要であり、無視されます。

NLSデータベース・パラメータ

CREATE DATABASE文の実行中に新しいデータベースが作成されると、NLS関連のデータベース構成が設定されます。現行のNLSインスタンス・パラメータは、データベース・キャラクタ・セットおよび各国語キャラクタ・セットとともにデータ・ディクショナリに格納されます。NLSインスタンス・パラメータは、インスタンスの起動時に初期化パラメータ・ファイルから読み込まれます。

NLSパラメータの値は、次のいずれかを使用して検索できます。

- NLSデータ・ディクショナリ・ビュー

- NLS動的パフォーマンス・ビュー

- OCINlsGetInfo()関数

NLSデータ・ディクショナリ・ビュー

アプリケーションでは、次のデータ・ディクショナリ・ビューに問い合せて、セッション、インスタンスおよびデータベースのNLSパラメータをチェックできます。

- NLS_SESSION_PARAMETERSには、このビューに問合せ中のセッションのNLSパラメータとその値が表示されます。キャラクタ・セットに関する情報は表示されません。

- NLS_INSTANCE_PARAMETERSには、明示的に設定されている現行のNLSインスタンス・パラメータとその値が表示されます。

- NLS_DATABASE_PARAMETERSには、データベースのNLSパラメータの値が表示されます。これらの値はデータベースに格納されます。

NLS動的パフォーマンス・ビュー

アプリケーションでは、次のNLS動的パフォーマンス・ビューをチェックできます。

- V$NLS_VALID_VALUESには、NLSパラメータNLS_LANGUAGE、NLS_SORT、NLS_TERRITORYおよびNLS_CHARACTERSETの値が表示されます。

- V$NLS_PARAMETERSには、NLSパラメータNLS_CALENDAR、NLS_CHARACTERSET、NLS_CURRENCY、NLS_DATE_FORMAT、NLS_DATE_LANGUAGE、NLS_ISO_CURRENCY、NLS_LANGUAGE、NLS_NUMERIC_CHARACTERS、NLS_SORT、NLS_TERRITORY、NLS_NCHAR_CHARACTERSET、NLS_COMP、NLS_LENGTH_SEMANTICS、NLS_NCHAR_CONV_EXP、NLS_TIMESTAMP_FORMAT、NLS_TIMESTAMP_TZ_FORMAT、NLS_TIME_FORMATおよびNLS_TIME_TZ_FORMATの現行の値が表示されます。

関連項目:
『Oracle Databaseリファレンス』

OCINlsGetInfo()関数

ユーザー・アプリケーションでは、OCINlsGetInfo()関数を使用して、クライアントのNLS設定を問い合せることができます。

関連項目:
OCINlsGetInfo()関数の詳細は、「OCIでのロケール情報の取得」を参照してください。

言語および地域のパラメータ

この項では、次のパラメータについて説明します。

- NLS_LANGUAGE

- NLS_TERRITORY

NLS_LANGUAGE

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータおよびALTER SESSION

デフォルト値

NLS_LANGから導出

値の範囲

有効な任意の言語名

NLS_LANGUAGEは、次のセッション特性に対してデフォルトの規則を指定します。

- サーバー・メッセージの言語

- 曜日名と月名の言語およびその略称(SQL関数TO_CHARとTO_DATEで指定されます)

- AM、PM、ADおよびBCに相当する記号。(A.M.、P.M.、A.D.およびB.C.は、NLS_LANGUAGEがAMERICANに設定されている場合のみ有効です。)

- ORDER BYが指定されている場合の文字データのデフォルトのソート順序。(ORDER BYが指定されていないかぎり、GROUP BYでバイナリ・ソートが使用されます。)

- 書込み方向

- 肯定的および否定的な応答文字列(YESおよびNOなど)

初期化パラメータ・ファイルのNLS_LANGUAGEに指定されている値は、そのインスタンス内のすべてのセッションに対するデフォルト値になります。たとえば、デフォルトのセッション言語をフランス語に指定するには、パラメータを次のように設定する必要があります。

NLS_LANGUAGE = FRENCH

次のサーバー・メッセージを考えてみます。

ORA-00942: table or view does not exist

言語がフランス語の場合は、次のサーバー・メッセージが表示されます。

ORA-00942: table ou vue inexistante

サーバーが使用するメッセージは、ORACLE_HOME/product_name/mesgディレクトリにあるバイナリ形式ファイル、あるいはそれに相当するオペレーティング・システム用ファイルに格納されます。このファイルには、次のファイル名規則に従って、サポート対象言語ごとに1バージョンずつ、複数のバージョンが存在します。

<product_id><language_abbrev>.MSB

たとえば、ORAは製品ID(<product_id>)でFはフランス語の略称(<language_abbrev>)であるため、フランス語のサーバー・メッセージが含まれたファイルはoraf.msbと呼ばれます。product_nameはrdbmsであるため、$ORACLE_HOME/rdbms/mesgディレクトリにあります。

NLS_LANGがクライアント環境に指定されている場合、初期化パラメータ・ファイル内のNLS_LANGUAGEの値は接続時にオーバーライドされます。

メッセージは、言語とオペレーティング・システムに応じて、特定キャラクタ・セットごとにこれらのファイルに格納されます。このキャラクタ・セットがデータベース・キャラクタ・セットと異なる場合、メッセージ・テキストはデータベース・キャラクタ・セットに自動的に変換されます。クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと異なる場合、メッセージ・テキストは、必要に応じてクライアント・キャラクタ・セットに変換されます。このようにキャラクタ・セット変換の制限に従うことによって、メッセージはユーザーの端末に正しく表示されます。

実際にインストールされる言語固有のバイナリ・メッセージ・ファイルは、製品のインストール時に指定する言語によって決定されます。インストールされるのは、英語のバイナリ・メッセージ・ファイルとユーザーが指定した言語固有のバイナリ・メッセージ・ファイルのみです。

NLS_LANGUAGEのデフォルト値が、オペレーティング・システム固有の値の場合があります。初期化パラメータ・ファイルで値を変更してインスタンスを再起動すると、NLS_LANGUAGEパラメータを変更できます。

関連項目:
NLS_LANGUAGEのデフォルト値の詳細は、各オペレーティング・システムのマニュアルを参照してください。

メッセージとテキストはすべて同じ言語にする必要があります。たとえば、Oracle Developerアプリケーションの実行時にユーザーが参照するメッセージとボイラープレート・テキストは、次の3つのソースから導出されます。

- サーバーからのメッセージ

- Oracle Formsによって生成されたメッセージとボイラープレート・テキスト

- アプリケーションによって生成されたメッセージとボイラープレート・テキスト

最初の2種類のテキストに使用される言語は、NLS_LANGUAGEによって決定されます。アプリケーションは、そのメッセージとボイラープレート・テキストに使用する言語を受け持ちます。

次の例に、NLS_LANGUAGEを異なる値に設定した場合の動作を示します。

例3-3 NLS_LANGUAGE=ITALIAN

ALTER SESSION文を使用して、NLS_LANGUAGEをイタリア語に設定します。

ALTER SESSION SET NLS_LANGUAGE=Italian;

SELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のような出力になります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30-SET-05      962.5
Urman                     07-MAR-06        975
Popp                      07-DIC-07      862.5
...

月名の略称にイタリア語が使用されていることに注意してください。

関連項目:
ALTER SESSION文の使用方法の詳細は、「セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド」を参照してください。

例3-4 NLS_LANGUAGE=GERMAN

ALTER SESSION文を使用して、言語をドイツ語に変更します。

SQL> ALTER SESSION SET NLS_LANGUAGE=German;

前述と同じSELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のような出力になります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30-SEP-05      962.5
Urman                     07-MRZ-06        975
Popp                      07-DEZ-07      862.5
...

月名の略称の言語が変更されていることに注意してください。

NLS_TERRITORY

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータおよびALTER SESSION

デフォルト値

NLS_LANGから導出

値の範囲

有効な任意の地域名

NLS_TERRITORYは、次のデフォルトの日付および数値の書式特性に関する規則を指定します。

- 日付書式

- 小数点文字とグループ・セパレータ

- 各国通貨記号

- ISO通貨記号

- 第2通貨記号

- 週の最初の曜日

- 貸方および借方記号

- ISO週フラグ

- リスト・セパレータ

初期化パラメータ・ファイルのNLS_TERRITORYに指定されている値は、そのインスタンスに対するデフォルト値になります。たとえば、デフォルトをフランスに指定するには、パラメータを次のように設定する必要があります。

NLS_TERRITORY = FRANCE

地域がFRANCEの場合、数値は小数点文字にカンマを使用して書式設定されます。

初期化パラメータ・ファイルで値を変更してインスタンスを再起動すると、NLS_TERRITORYパラメータを変更できます。NLS_TERRITORYのデフォルト値が、オペレーティング・システム固有の値の場合があります。

NLS_LANGがクライアント環境に指定されている場合、初期化パラメータ・ファイル内のNLS_TERRITORYの値は接続時にオーバーライドされます。

地域は、ALTER SESSION文にNLS_TERRITORYの新しい値を指定することで、セッション中に動的に変更できます。NLS_TERRITORYを変更すると、すべての導出NLSセッション・パラメータは、新しい地域のデフォルト値に再設定されます。

セッション中に地域をフランスに変更するには、次のALTER SESSION文を発行します。

ALTER SESSION SET NLS_TERRITORY = France;

次の例に、NLS_TERRITORYとNLS_LANGUAGEを異なる値に設定した場合の動作を示します。

例3-5 NLS_LANGUAGE=AMERICAN、NLS_TERRITORY=AMERICA

次のSELECT文を入力します。

SQL> SELECT TO_CHAR(salary,'L99G999D99') salary FROM employees;

NLS_TERRITORYをAMERICAに設定し、NLS_LANGUAGEをAMERICANに設定すると、次のような結果が出力されます。

SALARY
--------------------
$24,000.00
$17,000.00
$17,000.00

例3-6 NLS_LANGUAGE=AMERICAN、NLS_TERRITORY=GERMANY

次のALTER SESSION文を使用して地域をドイツに変更します。

ALTER SESSION SET NLS_TERRITORY = Germany;
Session altered.

前述と同じSELECT文を入力します。

SQL> SELECT TO_CHAR(salary,'L99G999D99') salary FROM employees;

結果は次のような出力になります。

SALARY
--------------------
€24.000,00
€17.000,00
€17.000,00

通貨記号が$から€に変更されていることに注意してください。基礎となるデータは同じであるため、数値に変更はありません。

関連項目:
ALTER SESSION文の使用方法の詳細は、「セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド」を参照してください。

例3-7 NLS_LANGUAGE=GERMAN、NLS_TERRITORY=GERMANY

ALTER SESSION文を使用して言語をドイツ語に変更します。

ALTER SESSION SET NLS_LANGUAGE = German;
Sitzung wurde geändert.

サーバー・メッセージがドイツ語で表示されることに注意してください。

前述と同じSELECT文を入力します。

SQL> SELECT TO_CHAR(salary,'L99G999D99') salary FROM employees;

例3-6と同じ結果が表示されます。

SALARY
--------------------
€24.000,00
€17.000,00
€17.000,00

例3-8 NLS_LANGUAGE=GERMAN、NLS_TERRITORY=AMERICA

次のALTER SESSION文を使用して地域をアメリカに変更します。

ALTER SESSION SET NLS_TERRITORY = America;
Sitzung wurde geändert.

他の例と同じSELECT文を入力します。

SQL> SELECT TO_CHAR(salary,'L99G999D99') salary FROM employees;

結果は次のような出力になります。

SALARY
--------------------
$24,000.00
$17,000.00
$17,000.00

地域がドイツからアメリカに変更されたため、通貨記号が€から$に変更されていることに注意してください。

セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド

NLS_LANGUAGEとNLS_TERRITORYのデフォルト値および特定の書式設定パラメータのデフォルト値は、ALTER SESSION文を使用してセッション中にオーバーライドできます。

例3-9 NLS_LANG=ITALIAN_ITALY.WE8DEC

言語がイタリア語、地域がイタリア、キャラクタ・セットがWE8DECになるように、環境変数NLS_LANGを設定します。

% setenv NLS_LANG Italian_Italy.WE8DEC

SELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のような出力になります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30-SET-05      962,5
Urman                     07-MAR-06        975
Popp                      07-DIC-07      862,5
...

月の略称の言語と小数点文字に注意してください。

例3-10 言語、日付書式および小数点文字の変更

ALTER SESSION文を使用して、言語、日付書式および小数点文字を変更します。

SQL> ALTER SESSION SET NLS_LANGUAGE=german;

Session wurde geändert.

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD.MON.YY';

Session wurde geändert.

SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS='.,';

Session wurde geändert.

例3-9に示したSELECT文を入力します。

SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;

結果は次のような出力になります。

LAST_NAME                 HIRE_DATE     SALARY
------------------------- --------- ----------
...
Sciarra                   30.SEP.05      962.5
Urman                     07.MRZ.06        975
Popp                      07.DEZ.07      862.5
...

月の略称がドイツ語で、小数点文字がピリオドであることに注意してください。

環境変数NLS_LANGの動作によって、各セッションのデータベースの言語環境が暗黙的に決定されます。セッションでのデータベース接続時に、ALTER SESSION文が自動的に実行され、データベース・パラメータNLS_LANGUAGEおよびNLS_TERRITORYの値が、NLS_LANGのlanguageおよびterritory引数で指定された値に設定されます。NLS_LANGが定義されていない場合、ALTER SESSION文は暗黙的に実行されません。

NLS_LANGが定義されている場合は、セッションの接続先(直接接続と間接接続の両方)インスタンスすべてに対して、ALTER SESSION文が暗黙的に実行されます。NLSパラメータの値が、ALTER SESSIONによってセッション中に明示的に変更されると、その変更内容は、ユーザー・セッションの接続先のインスタンスすべてに反映されます。

日付および時間を指定するパラメータ

Oracle Databaseでは、日付と時刻の表示を制御できます。この項の内容は、次のとおりです。

- 日付書式

- 時刻書式

日付書式

表3-4に、様々な日付書式を示します。

表3-4 日付書式

国名

説明

例

エストニア

dd.mm.yyyy

28.02.2003

ドイツ

dd-mm-rr

28-02-03

日本

rr-mm-dd

03-02-28

英国

dd-mon-rr

28-Feb-03

米国

dd-mon-rr

28-Feb-03

この項では、次のパラメータについて説明します。

- NLS_DATE_FORMAT

- NLS_DATE_LANGUAGE

NLS_DATE_FORMAT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数およびALTER SESSION

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な日付書式マスク

NLS_DATE_FORMATパラメータは、TO_CHAR関数およびTO_DATE関数で使用するデフォルトの日付書式を定義します。NLS_TERRITORYパラメータは、NLS_DATE_FORMATのデフォルト値を決定します。NLS_DATE_FORMATの値には、有効な任意の日付書式マスクを指定できます。次に例を示します。

NLS_DATE_FORMAT = "MM/DD/YYYY"

日付書式に文字列リテラルを追加する場合は、その文字列リテラルを二重引用符で囲みます。日付書式に二重引用符を使用する場合は、値全体を一重引用符で囲む必要があることに注意してください。次に例を示します。

NLS_DATE_FORMAT = '"Date: "MM/DD/YYYY'

例3-11 ローマ数字を表示する日付書式の設定

デフォルトの日付書式を設定して、月をローマ数字で表示するには、初期化パラメータ・ファイルに次の行を加えます。

NLS_DATE_FORMAT = "DD RM YYYY"

次のSELECT文を入力します。

SELECT TO_CHAR(SYSDATE) currdate FROM DUAL;

今日の日付が1997年2月12日の場合は、次の出力が表示されます。

CURRDATE
---------
12 II 1997

NLS_DATE_FORMATの値は、内部日付書式で格納されます。各書式要素は2バイトを占め、各文字列は、文字列のバイト数に終了記号の1バイト数を加えたバイト数を占めます。また、書式マスク全体には2バイトの終了記号があります。たとえば、MM/DD/YYは、内部で14バイトを占めます。これは、書式マスクが3つの書式要素(月、日および年)、2つの3バイト文字列(2個のスラッシュ)および2バイトの終了記号で構成されるためです。NLS_DATE_FORMATの値の書式は、24バイト以内で設定する必要があります。

NLS_DATE_FORMATのデフォルト値は、次の方法で変更できます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION SET NLS_DATE_FORMAT文を使用します。

関連項目:
日付書式要素とALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表または索引が日付列でパーティション化されている場合や、NLS_DATE_FORMATで指定した日付書式では年の最初の2桁が指定されない場合は、年に4文字の書式マスクを指定してTO_DATE関数を使用する必要があります。

次に例を示します。

TO_DATE('11-jan-1997', 'dd-mon-yyyy')

関連項目:
表および索引をパーティション化する方法とTO_DATEの使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NLS_DATE_LANGUAGE

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

NLS_LANGUAGEから導出

値の範囲

有効な任意の言語名

NLS_DATE_LANGUAGEパラメータは、TO_CHARおよびTO_DATE 関数で生成される曜日と月名の言語を指定します。NLS_DATE_LANGUAGEによって、NLS_LANGUAGEで暗黙的に指定された言語がオーバーライドされます。NLS_DATE_LANGUAGEの構文は、NLS_LANGUAGEパラメータの構文と同じで、サポート対象言語がすべて有効値です。

また、NLS_DATE_LANGUAGE によって、次に表記に使用する言語が決定されます。

- TO_CHARおよびTO_DATE関数で戻される月名と曜日名の略称

- デフォルトの日付書式(NLS_DATE_FORMAT)で使用される月名と曜日名の略称

- AM、PM、ADおよびBCの略称

例3-12 NLS_DATE_LANGUAGE=FRENCH、月名および曜日名

NLS_DATE_LANGUAGEの使用方法の例として、日付の言語をフランス語に設定します。

ALTER SESSION SET NLS_DATE_LANGUAGE = FRENCH;

SELECT文を入力します。

SELECT TO_CHAR(SYSDATE, 'Day:Dd Month yyyy') FROM DUAL;

結果は次のような出力になります。

TO_CHAR(SYSDATE,'DAY:DDMONTHYYYY')
------------------------------------------------------------
Vendredi:07 Décembre  2001

TO_CHAR関数を使用して表記される数字には、常に英語表記が使用されます。たとえば、次のSELECT文を入力します。

SQL> SELECT TO_CHAR(TO_DATE('12-Oct.-2001'),'Day: ddspth Month') FROM DUAL;

結果は次のような出力になります。

TO_CHAR(TO_DATE('12-OCT.-2001'),'DAY:DDSPTHMONTH')
--------------------------------------------------------------------
Vendredi: twelfth Octobre

例3-13 NLS_DATE_LANGUAGE=FRENCH、月名および曜日名の略称

月名と曜日名の略称は、NLS_DATE_LANGUAGEによって決定されます。次のSELECT文を入力します。

SELECT TO_CHAR(SYSDATE, 'Dy:dd Mon yyyy') FROM DUAL;

結果は次のような出力になります。

TO_CHAR(SYSDATE,'DY:DDMO
------------------------
Ve:07 Déc. 2001

例3-14 NLS_DATE_LANGUAGE=FRENCH、デフォルトの日付書式

デフォルトの日付書式では、NLS_DATE_LANGUAGEによって決定された月名の略称が使用されます。たとえば、デフォルトの日付書式がDD-MON-YYYYの場合、日付は次のように挿入されます。

INSERT INTO tablename VALUES ('12-Févr.-1997');

関連項目:
『Oracle Database SQL言語リファレンス』

時刻書式

表3-5に、様々な時刻書式を示します。

表3-5 時刻書式

国名

説明

例

エストニア

hh24:mi:ss

13:50:23

ドイツ

hh24:mi:ss

13:50:23

日本

hh24:mi:ss

13:50:23

英国

hh24:mi:ss

13:50:23

米国

hh:mi:ssxff am

1:50:23.555 PM

この項では、次のパラメータについて説明します。

- NLS_TIMESTAMP_FORMAT

- NLS_TIMESTAMP_TZ_FORMAT

関連項目:
第4章「日時データ型とタイム・ゾーン・サポート」

NLS_TIMESTAMP_FORMAT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数およびALTER SESSION

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な日時書式マスク

NLS_TIMESTAMP_FORMATは、TIMESTAMPおよびTIMESTAMP WITH LOCAL TIME ZONE データ型のデフォルトの日付書式を定義します。次の例に、NLS_TIMESTAMP_FORMATの値を示します。

NLS_TIMESTAMP_FORMAT  = 'YYYY-MM-DD HH:MI:SS.FF'

例3-15 タイムスタンプ書式

SQL> SELECT TO_TIMESTAMP('11-nov-2000 01:00:00.336', 'dd-mon-yyyy hh:mi:ss.ff')

FROM DUAL;

結果は次のような出力になります。

TO_TIMESTAMP('11-NOV-200001:00:00.336','DD-MON-YYYYHH:MI:SS.FF')
---------------------------------------------------------------------------
2000-11-11 01:00:00.336000000

NLS_TIMESTAMP_FORMATの値を指定するには、その値を初期化パラメータ・ファイルに設定します。設定した値は、クライアントのクライアント環境変数として指定できます。

また、次の方法でNLS_TIMESTAMP_FORMATの値を変更することもできます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION SET NLS_TIMESTAMP_FORMAT文を使用します。

関連項目:
TO_TIMESTAMP関数とALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NLS_TIMESTAMP_TZ_FORMAT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数およびALTER SESSION

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な日時書式マスク

NLS_TIMESTAMP_TZ_FORMATは、TIMESTAMPおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型のデフォルトの日付書式を定義します。これにはTO_CHARおよびTO_TIMESTAMP_TZファンクションが使用されます。

NLS_TIMESTAMP_TZ_FORMATの値を指定するには、その値を初期化パラメータ・ファイルに設定します。設定した値は、クライアントのクライアント環境変数として指定できます。

例3-16 NLS_TIMESTAMP_TZ_FORMATの設定

書式の値は引用符で囲む必要があります。次に例を示します。

NLS_TIMESTAMP_TZ_FORMAT  = 'YYYY-MM-DD HH:MI:SS.FF TZH:TZM'

次のTO_TIMESTAMP_TZ関数の例では、NLS_TIMESTAMP_TZ_FORMATに指定された書式の値を使用しています。

SQL> SELECT TO_TIMESTAMP_TZ('2000-08-20, 05:00:00.55 America/Los_Angeles', 'yyyy-mm-dd hh:mi:ss.ff TZR') FROM DUAL;

結果は次のような出力になります。

TO_TIMESTAMP_TZ('2000-08-20,05:00:00.55AMERICA/LOS_ANGELES','YYYY-MM-DDHH:M
---------------------------------------------------------------------------
2000-08-20 05:00:00.550000000 -07:00

また、次の方法でNLS_TIMESTAMP_TZ_FORMATの値を変更することもできます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION文を使用します。

関連項目:

- TO_TIMESTAMP_TZ関数とALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- タイム・ゾーンの詳細は、「タイム・ゾーン・ファイルの選択」を参照してください。

カレンダ定義

この項の内容は、次のとおりです。

- カレンダ書式

- NLS_CALENDAR

カレンダ書式

次のカレンダ情報が地域別に格納されます。

- 週の最初の曜日

- 年の最初の暦週

- 1年の日数と月数

- 紀元の年

週の最初の曜日

一部の文化では、日曜日を最初の曜日とみなしています。また、月曜日を最初の曜日とみなす文化もあります。ドイツのカレンダは、表3-6に示すように月曜日から始まります。

表3-6 ドイツのカレンダの例: 1998年3月

月

火

水

木

金

土

日

-

-

-

-

-

-

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

-

-

-

-

-

週の最初の曜日は、NLS_TERRITORYパラメータによって決定されます。

関連項目:
「NLS_TERRITORY」

年の最初の暦週

一部の国では、週番号を使用してスケジューリング、計画および会計処理を行います。Oracle Databaseでは、この規則をサポートしています。ISO規格では、暦年の週番号とは異なる週番号を使用できます。たとえば、1988年1月1日は、1987年のISO週番号53になります。ISOの週は、常に月曜日に始まって日曜日に終わります。

- 1月1日が金曜日、土曜日または日曜日の場合、1月1日を含むISOの週は、その週の大半の日が前年に属するため、前年の最後の週になります。

- 1月1日が月曜日、火曜日、水曜日または木曜日の場合は、1月1日を含むISOの週は、その週の大半の日が新しい年に属するため、新しい年の最初の週になります。

ISO規格をサポートするために、Oracle DatabaseにはIW日付書式要素が用意されています。これによりISOの週番号が戻されます。

表3-7に、暦年の第1週に1月1日を含めて4日以上含まれている場合の例を示します。1月1日を含む週は、1998年のISOの第1週となります。

表3-7 年のISOの第1週: 例1、1998年1月

月

火

水

木

金

土

日

ISO週

-

-

-

1

2

3

4

1998年のISOの第1週

5

6

7

8

9

10

11

1998年のISOの第2週

12

13

14

15

16

17

18

1998年のISOの第3週

19

20

21

22

23

24

25

1998年のISOの第4週

26

27

28

29

30

31

-

1998年のISOの第5週

表3-8に、暦年の第1週に含まれる日付が1月1日を含めて3日以内の場合の例を示します。1月1日を含む週は1998年のISOの第53週となり、次の週は1999年のISOの第1週となります。

表3-8 年のISOの第1週: 例2、1999年1月

月

火

水

木

金

土

日

ISO週

-

-

-

-

1

2

3

1998年のISOの第53週

4

5

6

7

8

9

10

1999年のISOの第1週

11

12

13

14

15

16

17

1999年のISOの第2週

18

19

20

21

22

23

24

1999年のISOの第3週

25

26

27

28

29

30

31

1999年のISOの第4週

年の最初の暦週は、NLS_TERRITORYパラメータによって決定されます。

関連項目:
「NLS_TERRITORY」

1年の日数と月数

Oracle Databaseでは、デフォルトのグレゴリオ暦の他に、次の6つの暦法をサポートしています。

- Japanese Imperial(日本の元号暦): 月数と日数はグレゴリオ暦と同じですが、年は元号ごとに始まります。

- ROC Official(台湾暦): 月数と日数はグレゴリオ暦と同じですが、年は台湾の建国年から始まります。

- Persian(ペルシャ暦): 最初の6か月の日数はそれぞれ31日、次の5か月はそれぞれ30日、最後の月は29日または30日(うるう年)です。

- Thai Buddha(タイ仏教暦): 仏教のカレンダを使用します。

- Arabic Hijrah(イスラム歴): 月数は12で、日数は354または355です。

- English Hijrah(英語版イスラム歴): 月数は12で、日数は354または355です。

暦法は、NLS_CALENDARパラメータで指定します。

関連項目:
「NLS_CALENDAR」

紀元の年

イスラム暦は、ヒジュラ紀元の年から始まります。

日本の元号暦は天皇が即位した最初の年から始まります。たとえば、1998年は平成10年となります。ただし、日本では、グレゴリオ暦も広く理解されているので、1998年を表現するために98年と平成10年の両方が使用されます。

NLS_CALENDAR

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

Gregorian(グレゴリオ暦)

値の範囲

有効なカレンダ書式名

世界中で様々な暦法が使用されています。NLS_CALENDARによって、Oracle Databaseで使用する暦法が指定されます。

NLS_CALENDARパラメータには、次の値のいずれかを指定できます。

- Arabic Hijrah(イスラム歴)

- English Hijrah(英語版イスラム歴)

- Gregorian(グレゴリオ暦)

- Japanese Imperial(日本の元号暦)

- Persian(ペルシャ暦)

- ROC Official(台湾暦)

- Thai Buddha(タイ仏教暦)

関連項目:
暦法、そのデフォルトの日付書式および日付表示に使用されるキャラクタ・セットのリストは、付録A「ロケール・データ」を参照してください。

例3-17 NLS_CALENDAR='English Hijrah'

NLS_CALENDARをEnglish Hijrahに設定します。

SQL> ALTER SESSION SET NLS_CALENDAR='English Hijrah';

SELECT文を入力してSYSDATEを表示します。

SELECT SYSDATE FROM DUAL;

結果は次のような出力になります。

SYSDATE
--------------------
24 Ramadan     1422

数値パラメータとリスト・パラメータ

この項の内容は、次のとおりです。

- 数値書式

- NLS_NUMERIC_CHARACTERS

- NLS_LIST_SEPARATOR

数値書式

データベースでは、数字列を正確に解釈するために、各セッションで使用される数値書式設定の規則を認識している必要があります。たとえば、数値の入力時に小数点文字としてピリオドまたはカンマのどちらを使用するか(234.00または234,00)などを認識している必要があります。同じように、アプリケーションでは、数値情報をクライアント側の書式で表示できる必要があります。

表3-9に、数値書式の例を示します。

表3-9 数値書式の例

国名

数値書式

エストニア

1 234 567,89

ドイツ

1.234.567,89

日本

1,234,567.89

英国

1,234,567.89

米国

1,234,567.89

数値書式はNLS_TERRITORYパラメータの設定から導出されますが、NLS_NUMERIC_CHARACTERSパラメータでオーバーライドできます。

関連項目:
「NLS_TERRITORY」

NLS_NUMERIC_CHARACTERS

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

特定地域に対するデフォルトの小数点文字とグループ・セパレータ

値の範囲

2つの有効な数字

このパラメータでは、小数点文字とグループ・セパレータを指定します。グループ・セパレータとは、千や100万などを示すために整数グループを区切る文字です。この文字はG数値書式マスクで戻されます。小数点文字は、数値の整数部と小数部を区切ります。NLS_NUMERIC_CHARACTERSを設定するとNLS_TERRITORYの設定から導出される値がオーバーライドされます。

任意の文字を、小数点文字またはグループ・セパレータに指定できます。これらの2つの文字はシングルバイトで、互いに異なる文字である必要があります。これらの文字に、数字、プラス(+)、ハイフン(-)または不等号(<、>)は使用できません。どちらかの文字を空白にすることができます。

例3-18 NLS_NUMERIC_CHARACTERSの設定

小数点文字をカンマに、グループ・セパレータをピリオドに設定するには、NLS_NUMERIC_CHARACTERSを次のように定義します。

ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ",.";

SQL文には、数値リテラルまたはテキスト・リテラルを表す数値を組み込めます。数値リテラルは引用符で囲みません。数値リテラルはSQL言語構文の一部で、小数点文字として常にドットを使用し、グループ・セパレータは含まれません。テキスト・リテラルは引用符で囲みます。テキスト・リテラルは、必要に応じて、現行のNLS設定に従って、暗黙的または明示的に数値に変換されます。

次のSELECT文は、ALTER SESSION文で指定された小数点文字とグループ・セパレータを使用して数値4000の書式を設定します。

SELECT TO_CHAR(4000, '9G999D99') FROM DUAL;

結果は次のような出力になります。

TO_CHAR(4
---------
4.000,00

NLS_NUMERIC_CHARACTERSのデフォルト値は次の方法で変更できます。

- 初期化パラメータ・ファイルでNLS_NUMERIC_CHARACTERSの値を変更してから、インスタンスを再起動します。

- このパラメータの値をセッション中に変更するには、ALTER SESSION文を使用します。

関連項目:
ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NLS_LIST_SEPARATOR

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

環境変数

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な任意の文字

NLS_LIST_SEPARATORは、値リストの値を区切るために使用する文字を指定します(通常は,、.、;または:)。このパラメータのデフォルト値は、NLS_TERRITORYの値から導き出されます。たとえば、1から5の数値のリストは、1,2,3,4,5、1.2.3.4.5、1;2;3;4;5または1:2:3:4:5と表すことができます。

指定する文字はシングルバイトにする必要があります。数値の小数点文字、通貨の小数点文字、数字、プラス(+)、ハイフン(-)、不等号(<、>)またはピリオド(.)は、いずれも使用できません。

通貨パラメータ

この項の内容は、次のとおりです。

- 通貨書式

- NLS_CURRENCY

- NLS_ISO_CURRENCY

- NLS_DUAL_CURRENCY

- NLS_MONETARY_CHARACTERS

- NLS_CREDIT

- NLS_DEBIT

通貨書式

世界中で様々な通貨書式が使用されています。表3-10に、標準的な通貨書式の一部を示します。

表3-10 通貨書式の例

国名

例

エストニア

1 234,56 kr

ドイツ

1.234,56€

日本

¥1,234.56

英国

£1,234.56

米国

$1,234.56

NLS_CURRENCY

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な通貨記号文字列

NLS_CURRENCYでは、L数値書式マスクで戻される文字列の各国通貨記号を指定します。NLS_CURRENCYを設定すると、NLS_TERRITORYで暗黙的に定義された設定がオーバーライドされます。

例3-19 各国通貨記号の表示

サンプル・スキーマであるoeスキーマに接続します。

SQL> connect oe/oe
Connected.

次の例のようなSELECT文を入力します。

SQL> SELECT TO_CHAR(order_total, 'L099G999D99') "total" FROM orders

WHERE order_id > 2450;

結果は次のような出力になります。

total
---------------------
$078,279.60
$006,653.40
$014,087.50
$010,474.60
$012,589.00
$000,129.00
$003,878.40
$021,586.20

NLS_CURRENCYのデフォルト値は次の方法で変更できます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION文を使用します。

関連項目:
ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NLS_ISO_CURRENCY

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な任意の文字列

NLS_ISO_CURRENCYでは、C数値書式マスクで戻される文字列の各国通貨記号を指定します。NLS_ISO_CURRENCYを設定すると、NLS_TERRITORYで暗黙的に定義された設定がオーバーライドされます。

各国通貨記号は不明確な場合があります。たとえば、ドル記号($)は米国ドルを指すこともオーストラリア・ドルを指すこともあります。ISO仕様には、特定の地域または国に対して固有の通貨記号が定義されています。たとえば、米国ドルに対するISO通貨記号はUSDです。オーストラリア・ドルに対するISO通貨記号はAUDです。

表3-11に、その他のISO通貨記号を示します。

表3-11 ISO通貨の例

国名

例

エストニア

1 234 567,89 EEK

ドイツ

1.234.567,89 EUR

日本

1,234,567.89 JPY

英国

1,234,567.89 GBP

米国

1,234,567.89 USD

NLS_ISO_CURRENCYの構文はNLS_TERRITORYパラメータの構文と同じで、サポート対象地域すべてが有効値です。

例3-20 NLS_ISO_CURRENCYの設定

この例では、サンプル・スキーマ内でoe/oeとして接続しているとします。

フランス用のISO通貨記号を指定するには、NLS_ISO_CURRENCYを次のように設定します。

ALTER SESSION SET NLS_ISO_CURRENCY = FRANCE;

SELECT文を入力します。

SQL> SELECT TO_CHAR(order_total, 'C099G999D99') "TOTAL" FROM orders

WHERE customer_id = 146;

結果は次のような出力になります。

TOTAL
------------------
EUR017,848.20
EUR027,455.30
EUR029,249.10
EUR013,824.00
EUR000,086.00

NLS_ISO_CURRENCYのデフォルト値は次の方法で変更できます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION文を使用します。

関連項目:
ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

NLS_DUAL_CURRENCY

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な任意の記号

NLS_DUAL_CURRENCYを使用すると、NLS_TERRITORYで暗黙的に定義されたデフォルトの第2通貨記号がオーバーライドされます。

NLS_DUAL_CURRENCYは、ユーロ移行期間中にユーロ通貨記号をサポートするために導入されました。ユーロ記号をサポートしているキャラクタ・セットについては、表A-8「ユーロ記号をサポートしているキャラクタ・セット」を参照してください。

Oracle Databaseのユーロ・サポート

欧州通貨連合(European Monetary Union: EMU)の12の加盟国は、自国通貨としてユーロを使用しています。NLS_TERRITORYを対応するEMU加盟国(オーストリア、ベルギー、フィンランド、フランス、ドイツ、ギリシャ、アイルランド、イタリア、ルクセンブルグ、オランダ、ポルトガルおよびスペイン)に設定すると、NLS_CURRENCYおよびNLS_DUAL_CURRENCYのデフォルト値がEURに設定されます。

移行期間(1999から2001年)中は、Oracle Database 8i以上のOracle Databaseに次のユーロ・サポート機能が提供されていました。

- NLS_CURRENCYが各国の1次通貨として定義されていました。

- NLS_ISO_CURRENCYが、特定の地域のISO通貨コードとして定義されていました。

- NLS_DUAL_CURRENCYが、特定の地域の2次通貨記号(通常はユーロ)として定義されていました。

Oracle Database 9iリリース2からは、NLS_ISO_CURRENCYの値に従って、ユーロを使用するEMU加盟国用のISO通貨記号がEURに設定されます。たとえば、NLS_ISO_CURRENCYがFRANCEに設定されているとします。次のSELECT文を入力します。

SELECT TO_CHAR(order_total, 'C099G999D99') "TOTAL" FROM orders
WHERE customer_id=116;

結果は次のような出力になります。

TOTAL
-------
EUR006,394.80
EUR011,097.40
EUR014,685.80
EUR000,129.00

廃止になった各国通貨記号を引き続き使用する必要がある場合は、それをサーバー上では初期化ファイルのパラメータとして、クライアント上では環境変数として定義することで、NLS_DUAL_CURRENCYまたはNLS_CURRENCYのデフォルトをオーバーライドできます。

注意:
NLS_CURRENCYまたはNLS_DUAL_CURRENCYを有効にするには、クライアント上でNLS_LANGも設定する必要があります。

NLS_ISO_CURRENCYの値から導出されるISO通貨記号はオーバーライドできません。

NLS_MONETARY_CHARACTERS

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

環境変数

デフォルト値

NLS_TERRITORYから導出

値の範囲

有効な任意の文字

NLS_MONETARY_CHARACTERSでは、通貨式で数値グループを区切る文字を指定します。たとえば、地域が米国の場合、3桁のセパレータはカンマで、小数点セパレータはピリオドです。

NLS_CREDIT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

環境変数

デフォルト値

NLS_TERRITORYから導出

値の範囲

最大9バイト(NULLを含まない)の任意の文字列

NLS_CREDITは、財務レポートで貸方を表示する記号を設定します。このパラメータのデフォルト値は、NLS_TERRITORYによって決定されます。たとえば、空白はNLS_CREDITの有効な値です。

このパラメータが指定できるのは、クライアント環境のみです。

このパラメータは、OCIGetNlsInfo()関数を使用して取得できます。

NLS_DEBIT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

環境変数

デフォルト値

NLS_TERRITORYから導出

値の範囲

最大9バイト(NULLを含まない)の任意の文字列

NLS_DEBITは、財務レポートで貸方を表示する記号を設定します。このパラメータのデフォルト値は、NLS_TERRITORYによって決定されます。たとえば、マイナス符号(-)は、NLS_DEBITの有効な値です。

このパラメータが指定できるのは、クライアント環境のみです。

このパラメータは、OCIGetNlsInfo()関数を使用して取得できます。

言語ソート・パラメータ

言語ソート・パラメータを使用して、データのソート方法を選択できます。

この項の内容は、次のとおりです。

- NLS_SORT

- NLS_COMP

関連項目:
第5章「言語ソートと文字列検索」

NLS_SORT

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数、ALTER SESSIONおよびSQL関数

デフォルト値

NLS_LANGUAGEから導出

値の範囲

BINARYまたは有効な言語ソート名

NLS_SORTは、文字データのソート・タイプを指定します。NLS_LANGUAGEから導出されるデフォルト値をオーバーライドします。

NLS_SORTには、次の値のいずれかが含まれます。

NLS_SORT = BINARY | sort_name

BINARYはバイナリ・ソートを指定し、sort_nameは言語ソート基準を指定します。

例3-21 NLS_SORTの設定

Germanという言語ソート基準を指定するには、NLS_SORTを次のように設定します。

NLS_SORT = German

注意:
NLS_SORTパラメータをBINARYに設定すると、オプティマイザは、索引スキャンを選択することで、ソートを行わずにORDER BY句を実行する場合があります。
NLS_SORTを言語ソートに設定すると、NLS_SORTで指定された言語ソート用の言語索引が存在しない場合は、ORDER BY句を実行するためにソートが必要になります。

NLS_SORTで指定された言語ソートに対応する言語索引が存在する場合、オプティマイザは、索引スキャンを選択することで、ソートを行わずにORDER BY句を実行する場合があります。

NLS_SORTのデフォルト値は、次の方法で変更できます。

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- ALTER SESSION文を使用します。

関連項目:

- 第5章「言語ソートと文字列検索」

- ALTER SESSION文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 言語ソート名のリストは、「言語ソート」を参照してください。

NLS_COMP

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータ、環境変数およびALTER SESSION

デフォルト値

BINARY

値の範囲

BINARY、LINGUISTICまたはANSI

NLS_COMPの値は、SQL操作の比較動作に影響を与えます。

バイナリ比較ではなく言語比較を実行する場合は、NLS_COMPを使用することで、SQL文にNLSSORT関数を使用する複雑な処理を回避できます。NLS_COMPをLINGUISTICに設定すると、SQL操作ではNLS_SORTの値に基づいて言語比較が実行されます。ANSIは下位互換性を保つために設定します。通常、言語比較を実行する場合は、NLS_COMPをLINGUISTICに設定する必要があります。

次のようにNLS_COMPをLINGUISTICに設定します。

ALTER SESSION SET NLS_COMP = LINGUISTIC;

NLS_COMPをLINGUISTICに設定すると、言語索引によって、言語上の比較のパフォーマンスが向上します。言語索引を使用可能にするには、次の構文を使用します。

CREATE INDEX i ON t(NLSSORT(col, 'NLS_SORT=FRENCH'));

関連項目:

- 「言語ソートの使用」

- 「言語索引の使用」

キャラクタ・セット変換パラメータ

この項の内容は、次のとおりです。

- NLS_NCHAR_CONV_EXCP

NLS_NCHAR_CONV_EXCP

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

初期化パラメータおよびALTER SESSION

デフォルト値

FALSE

値の範囲

TRUEまたはFALSE

NLS_NCHAR_CONV_EXCPは、NCHAR/NVARCHARデータとCHAR/VARCHAR2データの間で暗黙的または明示的な文字列型の変換時にデータが消失した場合に、エラーをレポートするかどうかを決定します。デフォルト値の場合、エラーはレポートされません。

関連項目:
キャラクタ・セット変換中のデータ消失の詳細は、第11章「キャラクタ・セットの移行」を参照してください。

長さセマンティクス

この項の内容は、次のとおりです。

- NLS_LENGTH_SEMANTICS

NLS_LENGTH_SEMANTICS

プロパティ

説明

パラメータ・タイプ

文字列

パラメータの有効範囲

環境変数、初期化パラメータおよびALTER SESSION

デフォルト値

BYTE

値の範囲

BYTEまたはCHAR

デフォルトでは、文字データ型CHARおよびVARCHAR2は、文字単位ではなくバイト単位で指定します。したがって、表定義でCHAR(20)と指定すると、文字データを格納するために20バイトが割り当てられます。

データベース・キャラクタ・セットでシングルバイト文字コード体系が使用されている場合は、文字数がバイト数と同じであるため、このような指定は適切に処理されます。データベース・キャラクタ・セットでマルチバイト文字コード体系が使用されている場合は、1文字が1バイト以上で構成される場合があるため、バイト数は文字数とは異なります。したがって、特定の文字数に対して予測される最大バイト数を見込んで、列幅を慎重に選択する必要があります。この問題は、列サイズの定義時にキャラクタ・セマンティクスに切り替えることで回避できます。

NLS_LENGTH_SEMANTICSによって、CHAR、VARCHAR2およびLONGの各列を、バイト・セマンティクスまたは文字長セマンティクスのいずれかを使用して作成できます。NCHAR、NVARCHAR2、CLOBおよびNCLOBの各列は、常に文字ベースです。既存の列は、影響を受けません。

既存のアプリケーションとの互換性を維持するためには、バイト・セマンティクスを使用する必要があります。

NLS_LENGTH_SEMANTICSは、SYSスキーマで作成された表には適用されません。データ・ディクショナリでは、常にバイト・セマンティクスが使用されます。長さ修飾子BYTEまたはCHARが表作成DDLで指定されていない場合、SYSによって所有される表は常にバイト・セマンティックスを使用します。

クライアント上で環境変数NLS_LENGTH_SEMANTICSが設定されていない場合、クライアント・セッションはデフォルトでデータベース・サーバー上のNLS_LENGTH_SEMANTICSの値に設定されることに注意してください。これにより、ネットワーク上のすべてのクライアント・セッションは同じNLS_LENGTH_SEMANTICS動作となります。各クライアント上で個別に環境変数を設定すると、そのクライアントのサーバー初期化パラメータをオーバーライドできます。

クライアントまたはOracle JDBC Thinドライバ経由で接続されるクライアント上でNLS_LENGTH_SEMANTICS環境変数が設定されていない場合、クライアント・セッションにはクライアントの接続先インスタンスのNLS_LENGTH_SEMANTICS初期化パラメータの値がデフォルト設定されます。互換性を保つために、このパラメータを未定義のままにするかBYTEに設定することをお薦めします。

注意:
インスタンスまたはサーバー・パラメータ・ファイルで、NLS_LENGTH_SEMANTICSパラメータをCHARに設定しないことをお薦めします。これによって、多数の既存インストール・スクリプトに文字長さセマンティクスを持つ列が予期せず作成され、バッファ・オーバーフローなどのランタイム・エラーが発生する場合があります。

関連項目:

- 「長さセマンティクス」

- 長さセマンティクスの詳細は、『Oracle Database概要』を参照してください。

4 日時データ型とタイム・ゾーン・サポート

この章の内容は、次のとおりです。

- 日時データ型、期間データ型およびタイム・ゾーン・サポートの概要

- 日時データ型と期間データ型

- 日時および時間隔の演算と比較

- 日時SQL関数

- 日時およびタイム・ゾーン・パラメータと環境変数

- タイム・ゾーン・ファイルの選択

- タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード

- 異なるバージョンのタイム・ゾーン・ファイルで動作するクライアントとサーバー

- データベースのタイム・ゾーンの設定

- セッションのタイム・ゾーンの設定

- AT TIME ZONE句を使用したタイム・ゾーンの変換

- 夏時間のサポート

日時データ型、期間データ型およびタイム・ゾーン・サポートの概要

企業は様々なタイム・ゾーンにまたがってトランザクションを実行しています。Oracle Databaseの日時データ型、期間データ型およびタイム・ゾーン・サポートにより、イベントとトランザクションの時間に関して一貫性のある情報を格納できます。

注意:
この章では、Oracle Databaseの日時データ型と期間データ型について説明します。特に明記している場合を除き、ANSIデータ型や他の種類のデータ型については説明しません。

日時データ型と期間データ型

日時データ型は、DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEです。日時データ型の値をDatetimesと呼ぶこともあります。

期間データ型は、INTERVAL YEAR TO MONTHおよびINTERVAL DAY TO SECONDです。期間データ型の値をIntervalsと呼ぶこともあります。

DatatimesとIntervalsは、どちらも複数のフィールドで構成されます。これらのフィールドの値により、データ型の値が決定されます。Oracle Databaseのすべての日時および期間データ型に適用されるフィールドは、次のとおりです。

- YEAR

- MONTH

- DAY

- HOUR

- MINUTE

- SECOND

TIMESTAMP WITH TIME ZONEには、次のフィールドも含まれます。

- TIMEZONE_HOUR

- TIMEZONE_MINUTE

- TIMEZONE_REGION

- TIMEZONE_ABBR

TIMESTAMP WITH LOCAL TIME ZONEはタイム・ゾーン情報の内部格納には使用されませんが、TZH:TZMまたはTZR TZD書式要素が指定されている場合は、SQL出力にローカルのタイム・ゾーン情報を表示できます。

次の項では、日時データ型と期間データ型の詳細を説明します。

- 日時データ型

- 期間データ型

関連項目:

- 日時フィールドと時間隔フィールドの有効な値については、『Oracle Database SQL言語リファレンス』を参照してください。

- 書式要素の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

日時データ型

この項の内容は、次のとおりです。

- DATEデータ型

- TIMESTAMPデータ型

- TIMESTAMP WITH TIME ZONEデータ型

- TIMESTAMP WITH LOCAL TIME ZONEデータ型

- 日時データ型への値の挿入

- TIMESTAMPデータ型の選択

DATEデータ型

DATEデータ型を使用して、日付および時刻情報が格納されます。日付および時刻情報はCHARACTERおよびNUMBERデータ型の両方で表現できますが、DATEデータ型は特別に関連付けられているプロパティがあります。DATE値ごとに、次の世紀、年、月、日、時間、分および秒の情報が格納されます。

日付値は次の方法で指定できます。

- 日付値をリテラルとして指定

- TO_DATE関数を使用して文字値または数値を日付値に変換

日付は、ANSI日付リテラルまたはOracle Databaseの日付値として指定できます。

ANSI日付リテラルには時間部分がなく、次の書式で正確に指定する必要があります。

DATE 'YYYY-MM-DD'

次にANSI日付リテラルの例を示します。

DATE '1998-12-25'

または、次の例に示すようにOracle Databaseの日付値を指定することもできます。

TO_DATE('1998-DEC-25 17:30','YYYY-MON-DD HH24:MI','NLS_DATE_LANGUAGE=AMERICAN')

Oracleデータベースの日付値のデフォルト書式は、NLS_DATE_FORMATおよびNLS_DATE_LANGUAGE初期化パラメータから導出されます。この例の日付書式には、日を表す2桁の数値、月名の略称、年の最後の2桁および24時間指定が含まれています。NLS_DATE_LANGUAGEの指定が含まれていますが、これはどのロケールでも'DEC'はMONに有効な値ではないためです。

デフォルト日付書式の文字値が日付式に使用されている場合は、自動的に日付値に変換されます。

時刻要素を含めずに日付値を指定した場合、デフォルトの時刻として午前0時に設定されます。日付を含めずに日付値を指定した場合、デフォルトの日付として現在の月の第1日に設定されます。

Oracle DatabaseのDATE列には、常に日付と時刻の両方のフィールドが含まれます。時刻部分を指定せずに問合せに日付書式を使用する場合は、DATE列の時刻フィールドを午前0時に設定する必要があります。TRUNC(date)SQL関数を使用すると、時刻フィールドを確実に午前0時に設定できます。また、問合せを使用して等価性または非等価性(=または!=)のかわりに大小の関係(<、<=、>=または>)のテストもできます。そうでない場合、Oracle Databaseは、正しい結果を戻さない場合があります。

関連項目:

- DATEデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「NLS_DATE_FORMAT」

- 「NLS_DATE_LANGUAGE」

- リテラル、MMなどの書式要素およびTO_DATE関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

TIMESTAMPデータ型

TIMESTAMPデータ型は、DATEデータ型の拡張です。年、月、日、時間、分および秒の値が格納されます。DATEデータ型では格納されない小数秒も格納されます。

TIMESTAMPデータ型は次のように指定します。

TIMESTAMP [(fractional_seconds_precision)]

fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。範囲0から9の数値を指定できます。デフォルトは6です。

たとえば、'26-JUN-02 09:39:16.78'は16.78秒を示します。78は2桁のため、小数秒の精度は2です。

TIMESTAMPリテラルは、次のような書式で指定できます。

TIMESTAMP 'YYYY-MM-DD HH24:MI:SS.FF'

この例に示す書式を使用して、次のようにTIMESTAMPをリテラルとして指定します。

TIMESTAMP '1997-01-31 09:26:50.12'

NLS_TIMESTAMP_FORMAT初期化パラメータの値により、文字列からTIMESTAMPデータ型への変換時のタイムスタンプ書式が決定されます。NLS_DATE_LANGUAGEにより、MONなど、文字データの使用言語が決定されます。

関連項目:

- TIMESTAMPデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 「NLS_TIMESTAMP_FORMAT」

- 「NLS_DATE_LANGUAGE」

TIMESTAMP WITH TIME ZONEデータ型

TIMESTAMP WITH TIME ZONEはTIMESTAMPのバリアントで、値にはタイム・ゾーン・リージョン名またはタイム・ゾーン・オフセットが含まれます。タイム・ゾーン・オフセットは、ローカル時間とUTC(協定世界時、以前のグリニッジ標準時)との時差(時間および分単位)です。TIMESTAMP WITH TIME ZONEデータ型は次のように指定します。

TIMESTAMP [(fractional_seconds_precision)] WITH TIME ZONE

fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。

TIMESTAMP WITH TIME ZONEは、次のようにリテラルとして指定できます。

TIMESTAMP '1997-01-31 09:26:56.66 +02:00'

2つのTIMESTAMP WITH TIME ZONE値がUTCで同じ時刻を表している場合は、データに格納されているTIME ZONEのオフセットに関係なく同一とみなされます。たとえば、次の2つの式の値は同じです。

TIMESTAMP '1999-01-15 8:00:00 -8:00'
TIMESTAMP '1999-01-15 11:00:00 -5:00'

UTCオフセットはTZR(タイム・ゾーン・リージョン)書式要素で置き換えることができます。次の式は、タイム・ゾーン・リージョンにAmerica/Los_Angelesを指定しています。

TIMESTAMP '1999-01-15 8:00:00 America/Los_Angeles'

標準時間から夏時間への切替時に境界を明確にするには、TZR書式要素および対応するTZD書式要素の両方を使用します。TZD書式要素は、夏時間情報を含むタイム・ゾーン・リージョンの略称です。たとえば、米国太平洋標準時間の場合はPST、米国太平洋夏時間の場合はPDTです。次のように指定すると、確実に夏時間の値が戻されます。

TIMESTAMP '1999-10-29 01:30:00 America/Los_Angeles PDT'

ERROR_ON_OVERLAP_TIMEセッション・パラメータをTRUEに設定していて、TZD書式要素を追加しない場合、日時の値が不明確な場合はエラーが戻されます。ERROR_ON_OVERLAP_TIMEがFALSE(デフォルト値)に設定されている場合、あいまいな日時は標準時間として解析されます。

TIMESTAMP WITH TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_TZ_FORMAT初期化パラメータの値により決定されます。

関連項目:

- TIMESTAMP WITH TIME ZONEデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 小数秒の精度の詳細は、「TIMESTAMPデータ型」を参照してください。

- 「夏時間のサポート」

- 「NLS_TIMESTAMP_TZ_FORMAT」

- 書式要素の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- ERROR_ON_OVERLAP_TIMEセッション・パラメータの設定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

TIMESTAMP WITH LOCAL TIME ZONEデータ型

TIMESTAMP WITH LOCAL TIME ZONEはTIMESTAMPのもう1つのバリアントです。TIMESTAMP WITH TIME ZONEとは異なり、データベースに格納されるデータはデータベース・タイムゾーンに対して正規化され、タイムゾーン・オフセッは列データの一部として格納されません。ユーザーがデータを検索すると、そのユーザーのローカル・セッションのタイム・ゾーンで戻されます。タイム・ゾーン・オフセットは、ローカル時間とUTC(協定世界時、以前のグリニッジ標準時)との時差(時間および分単位)です。

TIMESTAMP WITH LOCAL TIME ZONEデータ型は次のように指定します。

TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE

fractional_seconds_precisionはオプションで、SECOND日時フィールドの小数部の桁数を指定します。

TIMESTAMP WITH LOCAL TIME ZONEのリテラルはありませんが、TIMESTAMP WITH LOCAL TIME ZONE列にTIMESTAMPリテラルとTIMESTAMP WITH TIME ZONEリテラルを挿入できます。

TIMESTAMP WITH LOCAL TIME ZONEデータ型のデフォルトの日付書式は、NLS_TIMESTAMP_FORMAT初期化パラメータの値により決定されます。

関連項目:

- TIMESTAMP WITH LOCAL TIME ZONEデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 小数秒の精度の詳細は、「TIMESTAMPデータ型」を参照してください。

- 「NLS_TIMESTAMP_FORMAT」

日時データ型への値の挿入

日時列には次の方法で値を挿入できます。

- 適切なNLS書式値に基づく書式を使用した文字列の挿入

- リテラルの挿入

- 暗黙的な変換の実行対象となるリテラルの挿入

- TO_TIMESTAMP、TO_TIMESTAMP_TZまたはTO_DATE SQL関数の使用

次の例に、日時データ型にデータを挿入する方法を示します。

例4-1 DATE列へのデータの挿入

日付書式を設定します。

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';

c_id列とc_dt列を含むtable_dt表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_dt列はDATEデータ型です。

SQL> CREATE TABLE table_dt (c_id NUMBER, c_dt DATE);

日付を文字列として挿入します。

SQL> INSERT INTO table_dt VALUES(1, '01-JAN-2003');

同じ日付をDATEリテラルとして挿入します。

SQL> INSERT INTO table_dt VALUES(2, DATE '2003-01-01');

同じ日付をTIMESTAMPリテラルとして挿入します。タイム・ゾーン情報は削除されます。

SQL> INSERT INTO table_dt VALUES(3, TIMESTAMP '2003-01-01 00:00:00 America/Los_Angeles');

TO_DATE関数を使用して同じ日付を挿入します。

SQL> INSERT INTO table_dt VALUES(4, TO_DATE('01-JAN-2003', 'DD-MON-YYYY'));

データを表示します。

SQL> SELECT * FROM table_dt;

C_ID       C_DT
---------- --------------------
1          01-JAN-2003 00:00:00
2          01-JAN-2003 00:00:00
3          01-JAN-2003 00:00:00
4          01-JAN-2003 00:00:00

例4-2 TIMESTAMP列へのデータの挿入

タイムスタンプ書式を設定します。

SQL> ALTER SESSION SET NLS_TIMESTAMP_FORMAT='DD-MON-YY HH:MI:SSXFF';

c_id列とc_ts列を含むtable_ts表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_ts列はTIMESTAMPデータ型です。

SQL> CREATE TABLE table_ts(c_id NUMBER, c_ts TIMESTAMP);

日付と時刻を文字列として挿入します。

SQL> INSERT INTO table_ts VALUES(1, '01-JAN-2003 2:00:00');

同じ日付および時刻をTIMESTAMPリテラルとして挿入します。

SQL> INSERT INTO table_ts VALUES(2, TIMESTAMP '2003-01-01 2:00:00');

同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。値はTIMESTAMP値に変換されます。つまり、タイム・ゾーン情報が削除されます。

SQL> INSERT INTO table_ts VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');

データを表示します。

SQL> SELECT * FROM table_ts;

C_ID        C_TS
----------  -----------------------------
1           01-JAN-03 02:00:00.000000 AM
2           01-JAN-03 02:00:00.000000 AM
3           01-JAN-03 02:00:00.000000 AM

この3つの方法では、いずれも同じ値が格納されることに注意してください。

例4-3 TIMESTAMP WITH TIME ZONEデータ型へのデータの挿入

タイムスタンプ書式を設定します。

SQL> ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT='DD-MON-RR HH:MI:SSXFF AM TZR';

タイム・ゾーンを'-07:00'に設定します。

SQL> ALTER SESSION SET TIME_ZONE='-7:00';

c_id列とc_tstz列を含むtable_tstz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tstz列はTIMESTAMP WITH TIME ZONEデータ型です。

SQL> CREATE TABLE table_tstz (c_id NUMBER, c_tstz TIMESTAMP WITH TIME ZONE);

日付と時刻を文字列として挿入します。

SQL> INSERT INTO table_tstz VALUES(1, '01-JAN-2003 2:00:00 AM -07:00');

同じ日付および時刻をTIMESTAMPリテラルとして挿入します。値はTIMESTAMP WITH TIME ZONEリテラルに変換されます。つまり、TIMESTAMP値にセッションのタイム・ゾーンが追加されます。

SQL> INSERT INTO table_tstz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');

同じ日付および時刻をTIMESTAMP WITH TIME ZONEリテラルとして挿入します。

SQL> INSERT INTO table_tstz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -8:00');

データを表示します。

SQL> SELECT * FROM table_tstz;

C_ID        C_TSTZ
----------  ------------------------------------
1           01-JAN-03 02:00.00:000000 AM -07:00
2           01-JAN-03 02:00:00.000000 AM -07:00
3           01-JAN-03 02:00:00.000000 AM -08:00

方法3の場合はタイム・ゾーンが異なることに注意してください。これは、TIMESTAMP WITH TIME ZONEリテラルの一部としてタイム・ゾーン情報が指定されているためです。

例4-4 TIMESTAMP WITH LOCAL TIME ZONEデータ型へのデータの挿入

タイム・ゾーンがUTC-7である米国コロラド州デンバーで入力されるデータを考えます。

SQL> ALTER SESSION SET TIME_ZONE='-07:00';

c_id列とc_tsltz列を含むtable_tsltz表を作成します。c_id列はNUMBERデータ型で、データの入力方法を識別できます。c_tsltz列はTIMESTAMP WITH LOCAL TIME ZONEデータ型です。

SQL> CREATE TABLE table_tsltz (c_id NUMBER, c_tsltz TIMESTAMP WITH LOCAL TIME ZONE);

日付と時刻を文字列として挿入します。

SQL> INSERT INTO table_tsltz VALUES(1, '01-JAN-2003 2:00:00');

同じデータをTIMESTAMP WITH LOCAL TIME ZONEリテラルとして挿入します。

SQL> INSERT INTO table_tsltz VALUES(2, TIMESTAMP '2003-01-01 2:00:00');

同じデータをTIMESTAMP WITH TIME ZONEリテラルとして挿入します。データはTIMESTAMP WITH LOCAL TIME ZONE値に変換されます。つまり、入力したタイム・ゾーン(-08:00)はセッションのタイム・ゾーン値(-07:00)に変換されます。

SQL> INSERT INTO table_tsltz VALUES(3, TIMESTAMP '2003-01-01 2:00:00 -08:00');

データを表示します。

SQL> SELECT * FROM table_tsltz;

C_ID        C_TSLTZ
----------  ------------------------------------
1           01-JAN-03 02.00.00.000000 AM
2           01-JAN-03 02.00.00.000000 AM
3           01-JAN-03 03.00.00.000000 AM

時間が2から3に変更され、UTC-8として入力した情報がローカル・タイム・ゾーンに変更されていることに注意してください。

関連項目:
TO_TIMESTAMPまたはTO_TIMESTAMP_TZSQL関数の詳細は、「日時SQL関数」を参照してください。

TIMESTAMPデータ型の選択

TIMESTAMPデータ型は、イベントの時間を記録する日時値(タイム・ゾーンなし)が必要な場合に使用します。たとえば、組立ラインの作業場にいる従業員がタイムカードに出社と退社を記録した時刻情報を格納できます。これは常にローカル時刻であるため、タイムゾーンの部分を保存する必要がありません。TIMESTAMPデータ型では、格納に7バイトまたは11バイトが使用されます。

TIMESTAMP WITH LOCAL TIME ZONEデータ型を使用するのは、日時値が指定されたローカル時刻を表す場合、またはタイム・ゾーン情報を値で記録する必要がある場合です。ローカル時間で設定された予定を考えます。夏時間ルールなどのタイム・ゾーン定義が変更された場合、指定ローカル日時を調整する必要があります。調整しないと、値が不正確になります。このデータ型は、そのような影響をほとんど受けません。

TIMESTAMP WITH TIME ZONEデータ型では、タイム・ゾーン情報が格納されるため、データの格納にTIMESTAMPおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型よりも2バイト多い13バイトが必要です。タイム・ゾーンは、タイム・ゾーン・リージョン名またはUTCからのオフセットとして格納されます。データはそのまま表示または計算に使用でき、追加の処理は必要ありません。TIMESTAMP WITH TIME ZONE列は主キーとして使用できません。TIMESTAMP WITH TIME ZONE列で索引が作成されると、ファンクション索引となります。

TIMESTAMP WITH LOCAL TIME ZONEデータ型は、タイム・ゾーン情報のないタイムスタンプの格納に使用されます。データは、クライアントとの間でやり取りされるたびにデータベースのタイム・ゾーンに対して正規化されます。格納には11バイトが必要です。

TIMESTAMP WITH LOCAL TIME ZONEデータ型は、元のタイム・ゾーンは重要ではないが、イベントの相対時刻が重要で、夏時間を正確に調製する必要がない場合に適しています。データベースのタイム・ゾーン間でこのデータ型が実行するタイム・ゾーン変換は、夏時間調整により非対称です。このデータ型はタイム・ゾーン情報を維持しないため、夏時間と標準時間のいずれであるか、秋の調整で近接する値を区別しません。個別のインスタンス間の混合により、ユーザーの通常の作業時間内に調整が発生する場合は特に、アプリケーションが予期しない動作をします。

夏時間への移行日が頻繁に更新され期間も変則的なブラジルやイスラエルなどは、特にタイム・ゾーン調整の問題の影響を受けやすいリージョンです。これらの地域からの時間情報がキーとなるアプリケーションの場合は、別の日時データ型の利用を考慮できます。

期間データ型

期間データ型は、期間の格納に使用されます。主な用途は分析関数です。たとえば、株価の移動平均の計算に使用できます。特定のパーセンタイルに対応する値を判別するには、期間データ型を使用する必要があります。また、期間データ型は履歴表の更新にも使用できます。

この項の内容は、次のとおりです。

- INTERVAL YEAR TO MONTHデータ型

- INTERVAL DAY TO SECONDデータ型

- 期間データ型への値の挿入

関連項目:
移動平均や逆パーセンタイルなどの分析関数の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

INTERVAL YEAR TO MONTHデータ型

INTERVAL YEAR TO MONTHでは、YEARおよびMONTH日時フィールドを使用して期間が格納されます。INTERVAL YEAR TO MONTHは次のように指定します。

INTERVAL YEAR [(year_precision)] TO MONTH

year_precisionは、YEAR日時フィールドの桁数です。有効範囲は0から9です。year_precisionのデフォルト値は2です。

時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。次に、123年と2か月という時間隔を指定する例を示します。年の精度は3です。

INTERVAL '123-2' YEAR(3) TO MONTH

関連項目:
INTERVAL YEAR TO MONTHデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

INTERVAL DAY TO SECONDデータ型

INTERVAL DAY TO SECONDでは、期間が日、時間、分および秒単位で格納されます。このデータ型は次のように指定します。

INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds_precision)]

day_precisionは、DAY日時フィールドの桁数です。有効範囲は0から9です。デフォルト値は2です。

fractional_seconds_precisionは、SECOND日時フィールドの小数部の桁数です。有効範囲は0から9です。デフォルトは6です。

次に、4日、5時間、12分、10秒および0.222秒の時間隔を指定する一例を示します。小数秒の精度は3です。

INTERVAL '4 5:12:10.222' DAY TO SECOND(3)

時間隔値は、リテラルとして指定できます。時間隔リテラルを指定するには様々な方法があります。

関連項目:
INTERVAL DAY TO SECONDデータ型を使用して時間隔リテラルを指定する方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

期間データ型への値の挿入

時間隔列には次の方法で値を挿入できます。

- 時間隔をリテラルとして挿入します。次に例を示します。

INSERT INTO table1 VALUES (INTERVAL '4-2' YEAR TO MONTH);

この文では、4年と2か月という期間が挿入されます。

Oracle Databaseでは、他のANSI期間型のリテラルが認識され、Oracle Databaseの時間隔値に変換されます。

- NUMTODSINTERVAL、NUMTOYMINTERVAL, TO_DSINTERVALおよびTO_YMINTERVAL SQL関数を使用します。

関連項目:
「日時SQL関数」

日時および時間隔の演算と比較

この項の内容は、次のとおりです。

- 日時および時間隔の演算

- 日時の比較

- 日時データ型の明示的な変換

日時および時間隔の演算

日付(DATE)、タイムスタンプ(TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE)および時間隔(INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH)の各データに対する演算操作を実行できます。タイムスタンプ・データ型を期間データ型と併用すると、演算操作で最大精度を維持できます。

日付値とタイムスタンプ値に対する演算操作には、NUMBER定数を使用できます。タイムスタンプ値はOracleで内部的に日付値に変換されてから、NUMBER定数を使用して演算操作が実行されます。これは、日付値とタイムスタンプ値の両方を含む操作中には、小数秒に関する情報が失われることを意味します。日時式および時間隔式では、NUMBER定数が日数として解析されます。

各DATE値には、時間要素が含まれます。多くの日付操作の結果には、小数部があります。この小数部は、1日の一部分を表します。たとえば、1.5日は36時間です。DATEデータに対する一般的な操作では、これらの小数部もOracle Databaseの組込みSQL関数により戻されます。たとえば、組込みMONTHS_BETWEEN SQL関数は、2つの日付間の月数を戻します。結果の小数部は、大の月である1か月のうちの該当部分を表します。

Oracleデータベースでは、すべてのタイムスタンプ演算がUTC時間で実行されます。TIMESTAMP WITH LOCAL TIME ZONEデータの場合は、日時値がデータベースのタイム・ゾーンからUTCに変換され、演算の実行後にデータベースのタイム・ゾーンに逆変換されます。TIMESTAMP WITH TIME ZONEデータの場合、日時値には常にUTCが使用されるため、変換は必要ありません。

関連項目:

- 日時および時間隔の演算操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- DATEへの暗黙的な変換を実行する関数については、「日時SQL関数」を参照してください。

日時の比較

日付値とタイムスタンプ値を比較する場合、Oracleデータベースではデータが高精度のデータ型に変換されてから比較されます。たとえば、TIMESTAMP WITH TIME ZONEデータ型のデータをTIMESTAMPデータ型のデータと比較する場合は、セッションのタイム・ゾーンを使用してTIMESTAMPデータがTIMESTAMP WITH TIME ZONEに変換されます。

日付およびタイムスタンプ・データの変換の優先順位は次のとおりです。

1. DATE

2. TIMESTAMP

3. TIMESTAMPWITHLOCALTIMEZONE

4. TIMESTAMPWITHTIMEZONE

どのデータ型のペアの場合も、優先順位リストで小さい番号を持つデータ型が、大きい番号を持つデータ型に変換されます。

日時データ型の明示的な変換

日時データ型を明示的に変換する場合は、CAST SQL関数を使用します。DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEを、前述のリストに示した他のデータ型に明示的に変換できます。

関連項目:
『Oracle Database SQL言語リファレンス』

日時SQL関数

日時関数は、日付(DATE)、タイムスタンプ(TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE)および時間隔(INTERVAL DAY TO SECOND、INTERVAL YEAR TO MONTH)の値を処理します。

日時関数の一部は、Oracle DatabaseのDATEデータ型用に設計されています。引数としてタイムスタンプ値を指定すると、Oracle Databaseでは内部的に入力の型がDATE値に変換されます。ROUNDおよびTRUNC関数の場合、内部変換は実行されません。

表4-1に、OracleのDATEデータ型用に設計されている日時関数を示します。この表には、各関数の詳細へのクロス・リファレンスが含まれます。

表4-1 DATEデータ型用に設計された日時関数

関数

説明

ADD_MONTHS

日付dおよびnか月を戻します。

LAST_DAY

dateを含む月の最終日を戻します。

MONTHS_BETWEEN

date1からdate2の月数を戻します。

NEW_TIME

zone1タイム・ゾーンの日時がdateの場合は、zone2タイム・ゾーンの日時を戻します。

注意: この関数への入力として使用できるタイム・ゾーンの数は限定されています。FROM_TZ関数と日時式を組み合せるほうが、はるかに多数のタイム・ゾーンにアクセスできます。

NEXT_DAY

名前にcharを含む最初の平日のうち、dateよりも後の日付を戻します。

ROUND(date)

fmt書式モデルで指定された単位に丸めたdateを戻します。

TRUNC(date)

日の時刻部分をfmt書式モデルで指定された単位に切り捨ててdateを戻します。

表4-2に、その他の日時関数と詳細説明へのクロス・リファレンスを示します。

表4-2 その他の日時関数

日時関数

説明

CURRENT_DATE

グレゴリオ暦による値のうちセッションのタイム・ゾーンの現在の日付をDATEデータ型で戻します。

CURRENT_TIMESTAMP

セッションのタイム・ゾーンの現在の日時をTIMESTAMP WITH TIME ZONE値として戻します。

DBTIMEZONE

データベースのタイム・ゾーンの値を戻します。この値は、タイム・ゾーン・オフセットまたはタイム・ゾーン・リージョン名です。

EXTRACT (datetime)

日時値または時間隔値の式から、指定された日時フィールドの値を抽出して戻します。

FROM_TZ

タイム・ゾーンのTIMESTAMP値をTIMESTAMP WITH TIME ZONE値に変換します。

LOCALTIMESTAMP

セッションのタイム・ゾーンの現在の日時をTIMESTAMPデータ型の値として戻します。

NUMTODSINTERVAL

数値nをINTERVAL DAY TO SECONDリテラルに変換します。

NUMTOYMINTERVAL

数値nをINTERVAL YEAR TO MONTHリテラルに変換します。

SESSIONTIMEZONE

現行セッションのタイム・ゾーンの値を戻します。

SYS_EXTRACT_UTC

タイム・ゾーン・オフセットを使用して日時からUTCを抽出します。

SYSDATE

データベースの起動時に有効だったデータベース・サーバーのオペレーティング・システムのタイム・ゾーンを考慮して、データベースが常駐するオペレーティング・システムの日時を戻します。

SYSTIMESTAMP

データベースが常駐するシステムの小数秒とタイム・ゾーンを含めてシステム日付を戻します。

TO_CHAR (datetime)

DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEまたはTIMESTAMP WITH LOCAL TIME ZONEデータ型の日時値または時間隔値を、fmt日付書式で指定された書式によるVARCHAR2データ型の値に変換します。

TO_DSINTERVAL

CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型の文字列を、INTERVAL DAY TO SECONDデータ型の値に変換します。

TO_NCHAR (datetime)

DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE、INTERVAL MONTH TO YEARまたはINTERVAL DAY TO SECONDデータ型の日時値または時間隔値を、データベース・キャラクタ・セットから各国語キャラクタ・セットに変換します。

TO_TIMESTAMP

CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型の文字列を、TIMESTAMPデータ型の値に変換します。

TO_TIMESTAMP_TZ

CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型の文字列を、TIMESTAMP WITH TIME ZONEデータ型の値に変換します。

TO_YMINTERVAL

CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型の文字列を、INTERVAL YEAR TO MONTHデータ型の値に変換します。

TZ_OFFSET

文が実行される日付に基づいて、入力値に対応するタイム・ゾーン・オフセットを戻します。

表4-3に、夏時間(DST)アップグレード・プロセスで使用する関数を示します。これらの関数は、準備ウィンドウまたは更新ウィンドウでのみ使用できます。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表4-3 タイム・ゾーン変換関数

タイム・ゾーン関数

説明

ORA_DST_AFFECTED

DSTルールのバージョンを別のバージョンにアップグレードすると、列内のデータが影響を受けるかどうかを検証できます。

ORA_DST_CONVERT

TSTZ列データのバージョンを別のバージョンにアップグレードできます。

ORA_DST_ERROR

日時値のアップグレードの際にエラーが発生していないかどうかを検証できます。

関連項目:
『Oracle Database SQL言語リファレンス』

日時およびタイム・ゾーン・パラメータと環境変数

この項の内容は、次のとおりです。

- 日時書式パラメータ

- タイム・ゾーン環境変数

- 夏時間セッション・パラメータ

- 夏時間アップグレード・パラメータ

日時書式パラメータ

表4-4に、日時書式パラメータの名前と説明を示します。

表4-4 日時書式パラメータ

パラメータ

説明

NLS_DATE_FORMAT

TO_CHAR関数およびTO_DATE関数で使用するデフォルトの日付書式を定義します。

NLS_TIMESTAMP_FORMAT

TO_CHAR関数およびTO_TIMESTAMP関数で使用するデフォルトのタイムスタンプ書式を定義します。

NLS_TIMESTAMP_TZ_FORMAT

TO_CHAR関数およびTO_TIMESTAMP_TZ関数で使用するデフォルトのタイムスタンプをタイム・ゾーン書式で定義します。

デフォルト値はNLS_TERRITORYから導出されます。

値は、初期化パラメータ・ファイル内で設定することで指定できます。初期化パラメータ・ファイル内の値を変更する場合、インスタンスを再起動して変更を有効にする必要があります。クライアントの場合は、値をクライアント環境変数として指定することもできます。Javaクライアントの場合、NLS_TERRITORYの値はJREのデフォルト・ロケールから導出されます。初期化パラメータ・ファイルに指定されている値は、JDBCセッションで使用されません。

セッション中に値を変更するには、ALTER SESSION文を使用します。

関連項目:

- 詳細は、例も含めて「日付および時間を指定するパラメータ」を参照してください。

- 「NLS_DATE_FORMAT」

- 「NLS_TIMESTAMP_FORMAT」

- 「NLS_TIMESTAMP_TZ_FORMAT」

タイム・ゾーン環境変数

タイム・ゾーン環境変数は次のとおりです。

- ORA_TZFILE。クライアントおよびOracle Databaseサーバー上でタイム・ゾーンを指定できます。Oracle DatabaseサーバーでORA_TZFILEを指定した場合、この環境変数が有効になるのはデータベースの作成時のみです。

- ORA_SDTZ。デフォルトのセッション・タイム・ゾーンを指定します。

関連項目:

- 「タイム・ゾーン・ファイルの選択」

- 「セッションのタイム・ゾーンの設定」

夏時間セッション・パラメータ

ERROR_ON_OVERLAP_TIMEは、Oracle Databaseによる不明確な日時境界値の処理方法を決定するセッション・パラメータです。不明確な日時値は、夏時間と標準時間の間の切替時に発生することがあります。

可能な値はTRUEとFALSEです。ERROR_ON_OVERLAP_TIMEがTRUEの場合は、不明確な日時値が検出されるとエラーが戻されます。ERROR_ON_OVERLAP_TIMEがFALSEの場合、不明確な日時値は標準時間とみなされます。デフォルト値はFALSEです。

関連項目:

- 「夏時間のサポート」

- 『Oracle Database SQL言語リファレンス』

夏時間アップグレード・パラメータ

DST_UPGRADE_INSERT_CONVは、夏時間(DST)アップグレード・プロセスのアップグレード・ウィンドウでのみ使用する初期化パラメータです。これは、DSTのアップグレードで変更されるTIMESTAMP WITH TIME ZONE列のある表にのみ適用されます。

(DBMS_DSTパッケージで説明されている)DSTパッチ適用プロセスのアップグレード・ウィンドウでは、TIMESTAMP WITH TIMEZONEデータを含む表に対する新規タイム・ゾーン・バージョンへの変換が行われます。まだ変換されていない表の列には、前のタイム・ゾーン・バージョンを反映するTIMESTAMP WITH TIMEZONEが残っています。SELECT文の発行時に、これらの列のデータを新規タイム・ゾーン・バージョンに変換済であるかのように表すために、新規バージョンに変換するための変換演算子がこれらの列にデフォルトで追加されます。ただし、変換演算子を追加すると、問合せ速度が低下してTIMESTAMP WITH TIMEZONE列で索引が使用できなくなることがあります。そのため、OracleにはパラメータDST_UPGRADE_INSERT_CONVが用意されています。このパラメータは、まだアップグレードされていない表のTIMESTAMP WITH TIMEZONE列の上に内部演算子を割り当てるかどうかを指定します。デフォルト値はTRUEです。この変換プロセスがTIMESTAMP WITH TIMEZONE列に影響しないことが明らかな場合は、このパラメータをFALSEに設定してかまいません。

DSTパッチ適用プロセス全体で、このパラメータをTRUEに設定することをお薦めします。デフォルトではTRUEに設定されています。ただし、TRUEに設定すると、未変換の表に対する問合せのパフォーマンスが低下する可能性があります。これは、アップグレード・ウィンドウについてのみ該当することに注意してください。

関連項目:

- 『Oracle Databaseリファレンス』

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

タイム・ゾーン・ファイルの選択

Oracle Databaseタイム・ゾーン・ファイルには、有効なタイム・ゾーン名が含まれています。タイム・ゾーンごとに次の情報も含まれています。

- 協定世界時(UTC)からのオフセット。

- 夏時間への移行時間。

- 標準時間と夏時間の略称。

Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_<version_number>.dat、小さいバージョンはtimezone_<version_number>.datと指定されます。ファイルはOracle Databaseホーム・ディレクトリのoracore/zoneinfoサブディレクトリにあるため、たとえば、デフォルトのタイム・ゾーン・ファイルはこのサブディレクトリの最上位バージョンのタイム・ゾーンになります。たとえば、Oracle Database 11gリリース2では、デフォルト・ファイルは$ORACLE_HOME/oracore/zoneinfo/timezlrg_14.datで、このファイルにデータベースで定義されているすべてのタイム・ゾーンが含まれます。

タイム・ゾーン・ファイルの例を次に示します。

$ORACLE_HOME/oracore/zoneinfo/timezlrg_4.dat   -- large version 4
$ORACLE_HOME/oracore/zoneinfo/timezone_4.dat   -- small version 4
$ORACLE_HOME/oracore/zoneinfo/timezlrg_5.dat   -- large version 5
$ORACLE_HOME/oracore/zoneinfo/timezone_5.dat   -- small version 5

データベース作成プロセスでは、サーバーのタイム・ゾーン・バージョンを選択します。このバージョンは固定ですが、アップグレード・プロセスを実行してより新しいバージョンにすることは可能です。異なるバージョンのタイム・ゾーン・ファイルをクライアントとサーバーで使用できますが、これは行わないことをお薦めします。あるバージョンのクライアントと別のバージョンのサーバー間の通信には、パフォーマンス・ペナルティがあるためです。TIMESTAMP WITH TIME ZONE(TSTZ)データがUTCではなくローカル・タイムスタンプを使用して転送されるため、パフォーマンス・ペナルティが発生します。

サーバー側では、Oracle Databaseには常に大きいファイルが使用されます。クライアント側では、大きいファイルまたは小さいファイルのいずれかを使用できます。クライアントで大きいタイム・ゾーン・ファイルを使用している場合は、小さいファイルに切り替えたときに情報が失われないことが確実である場合を除き、引き続き大きいファイルを使用する必要があります。小さいファイルを使用する場合、クライアントで小さいタイム・ゾーン・ファイルに存在しないデータを問い合せることがないことを確認してください。問い合せた場合、エラーが発生します。

クライアントまたはサーバーの特定のタイム・ゾーン・ファイルを有効にして使用できます。2つの状況で、サーバーのタイム・ゾーン・ファイルを有効にする場合があります。1つは、ターゲット・バージョンへのタイム・ゾーンのアップグレードを実行する場合です。詳細は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード」を参照してください。もう1つは、新しいデータベースを作成する際に、選択したタイム・ゾーン・ファイルを指すようにORA_TZFILE環境変数を設定する場合です。

クライアント上の特定のタイム・ゾーン・ファイルを有効にするには、ORA_TZFILEを、必要なタイム・ゾーン・ファイルに設定します。ORA_TZFILEを設定しない場合、Oracle Databaseでは、最新バージョンのタイム・ゾーン・ファイルが自動的に選択されて使用されます。クライアントで夏時間をアップグレードする方法の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

Oracleデータベースのタイム・ゾーン・データは、ftp://elsie.nci.nih.gov/pub/で使用可能な公開情報から導出されます。Oracleデータベースのタイム・ゾーン・データには、このサイトから入手可能な最新データが反映されていない場合があります。

次の文を入力すると、データベースとともにインストールされるタイム・ゾーン・ファイルからタイム・ゾーンの名前と略称のリストを取得できます。

SELECT TZNAME, TZABBREV
FROM V$TIMEZONE_NAMES
ORDER BY TZNAME, TZABBREV;

デフォルトのタイム・ゾーン・ファイルの場合、この文の出力は次のようになります。

TZNAME               TZABBREV
-------------------- ----------
Africa/Abidjan       GMT
Africa/Abidjan       LMT
...
Africa/Algiers       CEST
Africa/Algiers       CET
Africa/Algiers       LMT
Africa/Algiers       PMT
Africa/Algiers       WET
Africa/Algiers       WEST
...
WET                  LMT
WET                  WEST
WET                  WET

2137 rows selected.

上の出力では、Africa/Abidjanタイム・ゾーンには2つのタイム・ゾーン略称が、またAfrica/Algiersタイム・ゾーンには6つの略称が関連付けられています。次の表に、タイム・ゾーン略称の一部とその意味を示します。

タイム・ゾーン略称

意味

LMT

ローカル標準時間

PMT

パリ標準時間

WET

西ヨーロッパ時間

WEST

西ヨーロッパ夏時間

CET

中央ヨーロッパ時間

CEST

中央ヨーロッパ夏時間

EET

東ヨーロッパ時間

EEST

東ヨーロッパ夏時間

1つの略称が複数のタイム・ゾーンに関連付けられている場合があるため注意してください。たとえば、CETは、ヨーロッパのタイム・ゾーンに加えてAfrica/AlgiersとAfrica/Casablancaの両方に関連付けられています。

略称ごとにタイム・ゾーン名が繰り返されないタイム・ゾーン・リストが必要な場合は、次の問合せを使用します。

SELECT UNIQUE TZNAME
FROM V$TIMEZONE_NAMES;

たとえば、バージョン11には次のような出力が含まれます。

TZNAME
--------------------
Africa/Addis_Ababa
Africa/Bissau
Africa/Ceuta
...
Turkey
US/East-Indiana
US/Samoa

デフォルトのタイム・ゾーン・ファイルには、350を超える一意のタイム・ゾーン名が含まれています。小さいタイム・ゾーン・ファイルには、180を超える一意のタイム・ゾーン名が含まれています。

関連項目:

- 「タイム・ゾーン・データのカスタマイズ」

- 有効なOracle Databaseのタイム・ゾーン名のリストは、「タイム・ゾーン・リージョン名」を参照してください。

- Oracle Databaseソフトウェア・インストールで提供される$ORACLE_HOME/oracore/zoneinfo/timezdif.csvには、Oracle9i以上で変更されたタイム・ゾーンがすべてリストされています。

- アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード

Oracle Databaseによって提供されるタイム・ゾーン・ファイルを定期的に更新して、様々なタイム・ゾーン・リージョンに対する変更を反映します。データベースで現在使用しているタイム・ゾーン・ファイルを特定するには、V$TIMEZONE_FILEを問い合せます。

注意:
Oracle Database 9iには、タイム・ゾーン・ファイルのバージョン1が、Oracle Database 10gにはバージョン2が含まれています。Oracle Database 11gリリース2には、バージョン1から14のすべてのタイム・ゾーン・ファイルが含まれています。これらのリリースでそれぞれ提供されている各種のパッチおよびパッチ・セットにより、タイム・ゾーン・ファイルのバージョンも更新できます。

夏時間(DST)移行ルールの変更

夏時間の実施の時期や方法に関する規則の変更は、政府が行います。政府による変更が行われると、Oracleでは、タイム・ゾーン・データ付きタイムスタンプを処理するための、一連の新規移行ルールを提供します。

夏時間が開始または終了する移行期には、タイム・ゾーン・データ付きタイムスタンプを処理する際に、問題(データ消失など)が発生する可能性があります。そのため、移行の処理には一定のルールがあり、このリリースではこれらの移行ルールが変更されています。さらに、DBMS_DSTという新しいパッケージを提供することで、この移行の処理方法が大幅に改善されました。

Oracle DatabaseはTIMESTAMP WITH TIME ZONEデータ型のデータを内部的に格納するため、DST移行ルールに対する変更は、このデータ型の既存データに影響を与える可能性があります。ユーザーがタイム・ゾーン付きのタイムスタンプを入力すると、Oracle Databaseは、そのタイム・ゾーンの移行ルールに基づいて、そのデータをUTCに変換し、元のタイム・ゾーンIDとともに、そのデータをディスクに格納します。データを取り出すときは、UTCからの逆変換が起こります。たとえば、バージョン2の移行ルールを適用した場合、TIMESTAMP '2007-11-02 12:00:00 America/Los_Angeles'は、UTCの値'2007-11-02 20:00:00'と'America/Los_Angeles'のタイム・ゾーンIDとして格納されます。ロサンゼルス時間は、UTC-8時間(PST)です。バージョン3の移行ルールの場合、同じ日のオフセットは-7時間(PDT)です。2007年から、DSTの有効期間は今までよりも長くなりました(11月の第1日曜日、つまり2007年は11月4日まで)。先ほどのタイムスタンプをユーザーが取り出すと、格納されていたUTC時間に新しいオフセットが適応され、TIMESTAMP '2007-11-02 13:00:00 America/Los_Angeles'になります。以前のデータとバージョン3が適用されたデータの間には1時間の差があります。

DBMS_DSTパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

注意:
移行ルールが更新されているタイム・ゾーン・リージョンの場合、この「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード」全体で説明したアップグレード・プロセスは、該当するDSTルール変更の有効日よりも未来を示すタイムスタンプに対してのみ影響します。たとえば、2007年よりも前のタイムスタンプには、'America/Los_Angeles'タイム・ゾーン・リージョンのバージョン3による影響はありません。

タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレードの準備

データを実際にアップグレードする前に、アップグレードの影響がどの程度であるか確認する必要があります。一般に、アップグレード・プロセスでは、2つの個別のサブプロセスを考慮できます。1つ目は準備ウィンドウの作成、2つ目はアップグレード・ウィンドウの作成です。準備ウィンドウはデータベースで更新が必要なデータの量を確認する時間、アップグレード・ウィンドウは実際にアップグレードが発生する時間です。

必須でなければ、準備ウィンドウ・ステップを実行することをお薦めします。アップグレードの際に変更するデータ量の確認に加えて、アップグレードに必要な時間を見積ることができ、発生する可能性のあるセマンティック・エラーも発見できます。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。

準備ウィンドウを作成し、次のステップを実行して影響を受けるデータを確認できます。

1. 後で$ORACLE_HOME/oracore/zoneinfoへ移行する必要な(最新の)タイム・ゾーン・ファイルをインストールします。必要な(最新の)バージョンのtimezlrg_<version_number>.datは必須であり、timezone_<version_number>.datも必要に応じて追加できます。これらのファイルは、My Oracle Supportで入手できます。

2. オプションで、DBMS_DST.CREATE_ERROR_TABLEおよびDBMS_DST.CREATE_AFFECTED_TABLEをそれぞれ使用して、エラー表、および影響を受けるタイムスタンプとタイム・ゾーン情報の表を作成できます。作成しない場合、Oracle Databaseでは事前作成済のsys.dst$affected_tablesおよびsys.dst$error_tableが使用されます。これらの表は、ステップ4で使用します。

EXEC DBMS_DST.CREATE_AFFECTED_TABLE('my_affected_tables');
EXEC DBMS_DST.CREATE_ERROR_TABLE('my_error_table');

3. DBMS_DST.BEGIN_PREPARE(<new_version)を起動します。これは、ステップ1で選択したバージョンです。DBMS_DST権限情報の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

4. DBMS_DST.FIND_AFFECTED_TABLESを起動して影響を受けるデータをチェックし、sys.dst$affected_tablesを問い合せて影響を受ける列を検証します。また、sys.dst$affected_tables.error_countで可能性のあるエラーをチェックすることが特に重要です。エラー件数が1以上の場合、sys.dst$error_tableをチェックして、アップグレードで発生する可能性のあるエラーの種類を確認できます。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。

5. DBMS_DST.END_PREPAREを起動して、準備ウィンドウを終了します。

注意:
準備ウィンドウで一度に実行できるDBAは、1つのみです。また、アップグレードを実行する前に、すべてのエラーを修正する必要があります。

注意:
タイム・ゾーン・ファイルを更新するために使用可能なパッチのマトリクスは、My Oracle Support(http://support.oracle.com)のDocument ID 412160.1を参照してください。

タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレードのステップ

タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプをアップグレードする手順は、次のとおりです。

1. timezlrg_<version_number>.datの必要な(最新の)バージョンをダウンロードしていない場合はダウンロードし、$ORACLE_HOME/oracore/zoneinfoにインストールします。また、オプションで、timezone_<version_number>.datをMy Oracle Supportからダウンロードし、同じ場所に置きます。

2. データベースを停止します。Oracle RACでは、すべてのインスタンスを停止します。

3. UPGRADEモードで、データベースを起動します。Oracle RACでは、1つのインスタンスのみを起動してください。UPGRADEモードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

4. DBMS_DST.BEGIN_UPGRADE(<new_version>)を実行します。タイム・ゾーン・データ付きタイムスタンプを含むディクショナリ表のアップグレードで、セマンティック・エラーが無視されないようにする場合は、TRUEに指定できる他の2つのパラメータをオプションで使用できます。パラメータのいずれか、または両方にTRUEを指定すると、デフォルトで、エラーはsys.dst$error_tableに移入されます。この場合、BEGIN_UPGRADEプロシージャを開始する前に、エラー表を切り捨てることがあります。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

5. BEGIN_UPGRADEの実行が失敗すると、ORA-56927エラー(アップグレード・ウィンドウの起動に失敗しました)が発生します。
BEGIN_UPGRADEの実行がエラーで終了した後、sys.dst$error_tableをチェックして、ディクショナリ変換が成功しているかどうかを判別します。成功した場合、表内に行はありません。エラーが発生した場合、手動でエラーを修正し、DBMS_DST.BEGIN_UPGRADE(<new_version>)を再実行します。「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。

6. データベースを通常のモードで再起動します。

7. エラーおよびトリガー表(デフォルトでは、sys.dst$error_tableおよびsys.dst$trigger_table)を切り捨てます。
トリガー表では、アップグレード・プロセス中に無効化されたTSTZ表トリガーが記録されます。これは、DBMS_DST.UPGRADE_*プロシージャのパラメータとして渡されます。DBMS_DST.CREATE_TRIGGER_TABLEをコールして、オプションで独自のトリガー表を作成できます。DBMS_DST.UPGRADE_*の際、Oracle Databaseでは、影響を受けるTSTZデータのアップグレードを実行する前に、まずTSTZ表上のトリガーが無効になります。Oracle Databaseでは、sys.dst$trigger_table内の無効にされたトリガーの情報も保存されます。表内の影響を受けるTSTZデータのアップグレードの終了後、これらの無効化されたトリガーは、sys.dst$trigger_tableから読み込まれて有効になり、sys.dst$trigger_tableから削除されます。アップグレード・プロセス中にインスタンスが予期せず停止するなどの致命的エラーが発生した場合、sys.dst$trigger_tableをチェックして、アップグレードする前のアクティブな以前の状態に戻っていないトリガーがないかを確認します。

8. DBMS_DST.UPGRADE_DATABASEを起動して、すべての表内のTSTZデータをアップグレードします。

9. 「夏時間動作の更新の例」で示されるDBA_TSTZ_TABLESビューを問い合せ、すべての表でアップグレードが終了しているかどうか確認します。次に、dst$error_tableでエラーがないかどうか確認します。エラーが発生した場合、エラーを修正し、関係する表でDBMS_DST.UPGRADE_TABLEを再実行します。発生したエラーが重要でない場合は、エラーが無視されるようにパラメータを設定して、再実行します。

10. DBMS_DST.END_UPGRADEを起動して、アップグレード・ウィンドウを終了します。

注意:
タイム・ゾーン列付きのタイムスタンプを含む表は、更新可能な状態であることが必要です。たとえば、列に検証済および無効なCHECK制約があると更新の妨げになるため、このようなCHECK制約を列に含めることはできません。
表のサイズが2GBを超える場合は、パラレル・オプションを使用することをお薦めします。また、発生するすべてのセマンティック・エラーをOracleで処理することをお薦めします。

エラー表、トリガー表または影響を受ける表のCREATE文を発行する際は、スキーマ名ではなく表名のみを渡す必要があります。これは、現行の呼出し元のスキーマで表が作成されるためです。

夏時間動作の更新の例

この例では、Oracle Database 11gリリース2へのDST動作の更新を示します。まず、現在のデータベースでタイム・ゾーンのバージョン3が使用され、タイム・ゾーン・データ付きタイムスタンプを含む既存の表tがあるとします。

CONNECT scott/tiger
DROP TABLE t;
CREATE TABLE t (c NUMBER, mark VARCHAR(25), ts TIMESTAMP WITH TIME ZONE);

INSERT INTO t VALUES(1, 'not_affected',
to_timestamp_tz('22-sep-2006 13:00:00 america/los_angeles',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(4, 'affected_err_exist',
to_timestamp_tz('11-mar-2007 00:30:00 america/st_johns',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(6, 'affected_no_err',
to_timestamp_tz('11-mar-2007 01:30:00 america/st_johns',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
INSERT INTO t VALUES(14, 'affected_err_dup',
to_timestamp_tz('21-sep-2006 23:30:00 egypt',
'dd-mon-yyyy hh24:mi:ss tzr tzd'));
COMMIT;

次に、オプションで、準備ウィンドウを起動して、影響を受けるデータおよびオーバーラップや存在しない時間などの潜在的なセマンティック・エラーをチェックできます。それには、バージョン4に移行する準備のためのウィンドウを起動する必要があります。必要な権限は付与されていることを前提とします。これらの権限は、DBMS_DSTパッケージで制御されます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

例として、最初にウィンドウを準備します。

conn / AS SYSDBA
set serveroutput on
EXEC DBMS_DST.BEGIN_PREPARE(4);

A prepare window has been successfully started.

PL/SQL procedure successfully completed.

引数4を使用すると、この文でバージョン4が使用されます。このウィンドウが正常に起動された後、次のようにしてDATABASE_PROPERTIES内のDSTのステータスをチェックできます。

SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;

次のような出力が表示されます。

PROPERTY_NAME                  VALUE
---------------------------    ---------
DST_PRIMARY_TT_VERSION         3
DST_SECONDARY_TT_VERSION       4
DST_UPGRADE_STATE              PREPARE

次に、DBMS_DST.FIND_AFFECTED_TABLESを起動して、バージョン3からバージョン4へのアップグレードにより影響を受けるデータベース内のすべての表を検索できます。この表には、表所有者、表名、列名、行数およびエラー件数が含まれます。ここで、デフォルトのエラー表(sys.dst$error_table)および影響を受ける表(sys.dst$affected_table)を使用するか、独自の表を作成するかを選択できます。この例では、DBMS_DST.CREATE_ERROR_TABLEおよびDBMS_DST.CREATE_AFFECTED_TABLEを使用して独自の表を作成し、次のようにして、FIND_AFFECTED_TABLESに渡します。

EXEC DBMS_DST.CREATE_AFFECTED_TABLE('scott.my_affected_tables');
EXEC DBMS_DST.CREATE_ERROR_TABLE('scott.my_error_table');

これらの表内に行がないことを確認してください。これを行うには、次のようにして表を切り捨てます。

TRUNCATE TABLE scott.my_affected_tables;
TRUNCATE TABLE scott.my_error_table;

次に、FIND_AFFECTED_TABLESを起動して、アップグレードで影響を受ける表を確認します。

EXEC DBMS_DST.FIND_AFFECTED_TABLES(affected_tables  => 'scott.my_affected_tables',
log_errors       => TRUE,
log_errors_table => 'scott.my_error_table');

次に、影響を受ける表をチェックします。

SELECT * FROM scott.my_affected_tables;

TABLE_OWNER   TABLE_NAME   COLUMN_NAM   ROW_COUNT  ERROR_COUNT
-----------   ----------   ----------   ---------  -----------
SCOTT         T            TS                   3            2

次に、エラー表をチェックします。

SELECT * FROM scott.my_error_table;

TABLE_OWNER   TABLE_NAME  COLUMN_NAME   ROWID                ERROR_NUMBER
-----------   ----------  -----------   ------------------   ------------
SCOTT         T           TS            AAAPW3AABAAANzoAAB           1878
SCOTT         T           TS            AAAPW3AABAAANzoAAE           1883

これらのエラーを修正する方法は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。その後、次の文に示すように準備ウィンドウを終了します。

EXEC DBMS_DST.END_PREPARE;

A prepare window has been successfully ended.

PL/SQL procedure successfully completed.

これが終了したら、DATABASE_PROPERTIES内のDSTステータスをチェックできます。

SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;

PROPERTY_NAME                 VALUE
------------------------      --------
DST_PRIMARY_TT_VERSION        3
DST_SECONDARY_TT_VERSION      0
DST_UPGRADE_STATE             NONE

次に、アップグレード・ウィンドウを使用して、影響を受けるデータをアップグレードできます。これを行うには、最初にアップグレード・ウィンドウを起動します。DBMS_DST.BEGIN_UPGRADEを実行する前に、データベースをUPGRADEモードでオープンする必要があります。Oracle RACでは、1つのインスタンスのみを起動できます。BEGIN_UPGRADEにより、すべてのディクショナリ表が1つのトランザクションでアップグレードされるため、起動は全体として成功または失敗します。プロシージャの実行中、TSTZデータのあるすべてのユーザー表は、アップグレード進行中としてマークされます。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

また、アップグレード・ウィンドウを起動できるのは、SYSDBAのみです。データベースをUPGRADEモードでオープンせずにBEGIN_UPGRADEを起動すると、次のエラーが発生します。

EXEC DBMS_DST.BEGIN_UPGRADE(4);
BEGIN DBMS_DST.BEGIN_UPGRADE(4); END;

*
ERROR at line 1:
ORA-56926: database must be in UPGRADE mode in order to start an upgrade window
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.DBMS_DST", line 1021
ORA-06512: at line 1

したがって、BEGIN_UPGRADEでは、TSTZデータを含むシステム表がアップグレードされ、(TSTZデータを含む)ユーザー表がUPGRADE_IN_PROGRESSプロパティでマーク付けされます。これは、この例で後述するALL_TSTZ_TABLESでチェックできます。

BEGIN_UPGRADEには、セマンティック・エラーを処理する2つのパラメータがあります。1つはerror_on_overlap_time(エラー番号ORA-1883)で、もう1つはerror_on_nonexisting_time(エラー番号ORA-1878)です。パラメータでデフォルト設定のFALSEが使用されると、Oracleではデフォルトの変換を使用してデータが変換され、エラーは表示されません。これらの意味およびエラー処理の方法の詳細は、「タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理」を参照してください。

ディクショナリ表のアップグレードの際、次のコールにより、いくつかのデフォルト値に基づいてセマンティック・エラーが自動的に修正されます。セマンティック・エラーを無視せず、ディクショナリ表でこのようなエラーが発生する場合、BEGIN_UPGRADEは失敗します。これらのセマンティック・エラーは、sys.dst$error_tableに移入されます。

EXEC DBMS_DST.BEGIN_UPGRADE(4);
An upgrade window has been successfully started.

PL/SQL procedure successfully completed.

これが終了した後、次のようにしてDATABASE_PROPERTIES内のDSTステータスをチェックできます。

SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE 'DST_%'
ORDER BY PROPERTY_NAME;

PROPERTY_NAME               VALUE
------------------------    --------
DST_PRIMARY_TT_VERSION             4
DST_SECONDARY_TT_VERSION           3
DST_UPGRADE_STATE            UPGRADE

次に、どのユーザー表にUPGRADE_IN_PROGRESSのマークが付いているかチェックします。

SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES;

OWNER   TABLE_NAME                      UPGRADE_IN_PROGRESS
-----   -------------------------       -------------------
SYS     WRI$_OPTSTAT_AUX_HISTORY        NO
SYS     WRI$_OPTSTAT_OPR                NO
SYS     OPTSTAT_HIST_CONTROL$           NO
SYS     SCHEDULER$_JOB                  NO
SYS     KET$_AUTOTASK_STATUS            NO
SYS     AQ$_ALERT_QT_S                  NO
SYS     AQ$_KUPC$DATAPUMP_QUETAB_S      NO
DBSNMP  MGMT_DB_FEATURE_LOG             NO
WMSYS   WM$VERSIONED_TABLES             NO
SYS     WRI$_OPTSTAT_IND_HISTORY        NO
SYS     OPTSTAT_USER_PREFS$             NO
SYS     FGR$_FILE_GROUP_FILES           NO
SYS     SCHEDULER$_WINDOW               NO
SYS     WRR$_REPLAY_DIVERGENCE          NO
SCOTT   T                               YES
IX      AQ$_ORDERS_QUEUETABLE_S         YES
...

この出力では、ディクショナリ表(SYSスキーマ内)はBEGIN_UPGRADEでアップグレードされています。SCOTT.Tなどのユーザー表はアップグレードされていず、進行中です。

ここで、DBMS_DST.UPGRADE_DATABASEを使用してユーザー表のアップグレードを実行できます。すべての表をアップグレードする必要があります。そうしないと、END_UPGRADEプロシージャを使用してアップグレード・ウィンドウを終了できません。この手順を行う前に、データベースをnormalモードで再起動する必要があります。次に構文の例を示します。

VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel                  => TRUE,
log_errors                => TRUE,
log_errors_table          => 'SYS.DST$ERROR_TABLE',
log_triggers_table        => 'SYS.DST$TRIGGER_TABLE',
error_on_overlap_time     => TRUE,
error_on_nonexisting_time => TRUE);
DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/

エラーが発生した場合、エラーを修正し、個々の表でUPGRADE_TABLEを使用します。その場合、マテリアライズド・ビュー・ベース表、マテリアライズド・ビュー・ログ表およびマテリアライズド・ビュー・コンテナ表などのマテリアライズド・ビューに関連する表の処理が必要になることがあります。これらの表のアップグレードの際に、考慮が必要ないくつかの事項があります。まず、ベース表およびそのマテリアライズド・ビュー・ログ表を、アトミックにアップグレードする必要があります。次に、すべてのベース表およびマテリアライズド・ビュー・ログ表のアップグレードが終了してから、マテリアライズド・ビュー・コンテナ表をアップグレードする必要があります。一般に、Oracle Databaseでデフォルト処理を実行して、セマンティック・エラーを処理することをお薦めします。

この例では、UPGRADE_DATABASEを実行後、SCOTT.Tでエラーがいくつか発生したとします。この場合、次を発行してこれらのエラーをチェックできます。

SELECT * FROM scott.error_table;

TABLE_OWNER   TABLE_NAME  COLUMN_NAME   ROWID                ERROR_NUMBER
-----------   ----------  -----------   ------------------   ------------
SCOTT         T           TS            AAAO2XAABAAANrgAAD           1878
SCOTT         T           TS            AAAO2XAABAAANrgAAE           1878

この出力では、エラー番号1878が発生しているのがわかります。このエラーは、存在しない時間に対してエラーがスローされたことを示します。

SCOTT.Tにマテリアライズド・ビュー・ログscott.mlog$_tがあり、SCOTT.Tに単一のマテリアライズド・ビューがあると想定して、この例を続けます。ここで、この1878エラーが修正されているとします。

最後に、表、マテリアライズド・ビュー・ログおよびマテリアライズド・ビューを次のようにしてアップグレードできます。

BEGIN
DBMS_DST.UPGRADE_TABLE(:numfail,
table_list                => 'SCOTT.t, SCOTT.mlog$_T',
parallel                  => TRUE,
continue_after_errors     => FALSE,
log_errors                => TRUE,
log_errors_table          => 'SYS.DST$ERROR_TABLE',
error_on_overlap_time     => FALSE,
error_on_nonexisting_time => TRUE,
log_triggers_table        => 'SYS.DST$TRIGGER_TABLE',
atomic_upgrade            => TRUE);

DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/

BEGIN
DBMS_DST.UPGRADE_TABLE(:numfail,
table_list                => 'SCOTT.MYMV_T',
parallel                  => TRUE,
continue_after_errors     => FALSE,
log_errors                => TRUE,
log_errors_table          => 'SYS.DST$ERROR_TABLE',
error_on_overlap_time     => FALSE,
error_on_nonexisting_time => TRUE,
log_triggers_table        => 'SYS.DST$TRIGGER_TABLE',
atomic_upgrade            => TRUE);

DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail);
END;
/

atomic_upgradeパラメータを使用すると、表とそのマテリアライズド・ビュー・ログのアップグレードを組み合せることができます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

すべての表のアップグレード後、次のようにしてEND_UPGRADEを起動して、次に示すようにアップグレード・ウィンドウを終了します。

BEGIN
DBMS_DST.END_UPGRADE(:numfail OUT BINARY_INTEGER);
END;
/

他の表が正しくアップグレードされていない場合、END_UPGRADE文は失敗します。

DBMS_DSTパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

タイム・ゾーン・ファイルおよびタイム・ゾーン・データ付きタイムスタンプのアップグレード時のエラー処理

アップグレードの際、発生する可能性があるセマンティック・エラーは主に3つあります。1つ目は存在する時間が存在しない時間になる場合、2つ目は時間が重複する場合、3つ目は重複する時間が重複しない時間になる場合です。

1つ目のエラーの例として、2007年に太平洋標準時間(PST)が太平洋夏時間(PDT)に変更される場合を考えます。この変更は、バージョン4に基づいて2007年3月11日午前2時に行われ、時計が午前3時まで1時間進められると、午前2時と午前3時の間にギャップが発生します。バージョン2では、この時間の変更は、2007年4月1日に発生します。タイム・ゾーン・ファイルをバージョン2からバージョン4にアップグレードすると、2007年3月11日の午前2時と午前3時の間の時間は無効であり、ERROR_ON_NONEXISTING_TIMEがTRUEに設定されている場合、エラー(ORA-1878)が発生します。したがって、存在しない時間の問題が起こります。ERROR_ON_NONEXISTING_TIMEが、このパラメータのデフォルトであるFALSEに設定されている場合、このエラーはレポートされず、OracleではUTC時間が保持されます。バージョン2とバージョン4のどちらも同じUTCタイムスタンプに変換されるため、たとえば、バージョン2の"Mar-11-2007 02:30 PST"は、バージョン4では"Mar-11-2007 03:30 PDT"になります。

2つ目のエラーでは、PDTからPSTに変更する場合を例に考えます。たとえば、2007年のバージョン4では、2007年11月4日の午前2時から午前1時に時間が戻る際に、変更が発生します。これは、2007年11月4日の<午前1時、午前2時>内の時間が、PSTとPDTで1回ずつ、2回存在することを意味します。バージョン2では、この移行は、2007年10月28日午前2時に発生します。したがって、バージョン2では一意に識別される2007年11月4日の<午前1時、午前2時>内のタイムスタンプは、ERROR_ON_OVERLAP_TIMEがTRUEに設定されている場合、バージョン4ではエラー(ORA-1883)になります。このパラメータをデフォルト設定のFALSEのままにすると、UTCタイムスタンプ値が保持され、エラーは発生しません。この状況では、バージョン2からバージョン4に変更すると、バージョン2の"Nov-04-2007 01:30 PST"は、バージョン4では"Nov-04-2007 01:30 PST"になります。

3つ目のエラーは、重複する時間が重複しない時間になる場合に発生します。2007年のPDTからPSTへの移行を例にすると、バージョン2の2007年10月28日の<午前1時、午前2時>は重なっている期間です。したがって、バージョン2では"Oct-28-2007 01:30 PDT"と"Oct-28-2007 01:30 PST"はどちらも有効なタイムスタンプです。ERROR_ON_OVERLAP_TIMEがTRUEに設定されている場合、バージョン2からバージョン4へのアップグレード時にORA-1883エラーが発生します。ただし、ERROR_ON_OVERLAP_TIMEがFALSE(このパラメータのデフォルト値)に設定されている場合は、ローカル時間が保持されるため、エラーはレポートされません。この場合、バージョン2の"Oct-28-2007 01:30 PDT"と"Oct-28-2007 01:30 PST"は、いずれもバージョン4では同じ"Oct-28-2007 01:30 PDT"に変換されます。ERROR_ON_OVERLAP_TIMEをFALSEに設定した場合は、一部の時間の順序が逆になる可能性があることに注意してください。たとえば、バージョン2で"Oct-28-2007 01:45 PDT"にスケジュールされているジョブ(ジョブA)は、"Oct-28-2007 01:30 PST"にスケジュールされているジョブ(ジョブB)より先に実行されると考えられます。バージョン4へのアップグレード後、ジョブAは"Oct-28-2007 01:45 PDT"にスケジュールされ、ジョブBはそのまま"Oct-28-2007 01:30 PDT"にスケジュールされるため、ジョブBがジョブAより先に実行されます。連鎖していないスケジュール済ジョブは特定の順序で実行されるよう保証されていませんが、スケジュール済ジョブを設定する際には、この問題を考慮する必要があります。

これらのパラメータの使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

異なるバージョンのタイム・ゾーン・ファイルで動作するクライアントとサーバー

Oracle Database 11gリリース11.2以上では、クライアントとサーバーで異なるバージョンのタイム・ゾーン・ファイルを使用できます。この動作モードは11.2より前のリリースではサポートされていませんでした。このような混在モードで作業するには、クライアントとサーバーの両方が11.2以上であることが必要です。このようなモードでの作業で発生する問題は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

OCI、JDBC、Pro*CおよびSQL*Plusの各クライアントは、クライアント側タイム・ゾーン・ファイルを更新しなくてもデータベース・サーバーとの通信を続行できるようになりました。その他の製品では、製品固有のドキュメントに明記されていないかぎり、このようなクライアントは、クライアントと異なるタイム・ゾーン・ファイルを使用するデータベース・サーバーでは運用できないと考える必要があります。そうでない場合、クライアントでのリージョンIDベースのTIMESTAMP WITH TIMEZONE値の計算結果に一貫性がなくなる可能性があります。これは、クライアントとサーバーの異なるバージョンのタイム・ゾーン・ファイル間で影響を受けるタイム・ゾーン・リージョンに対して、異なる夏時間(DST)ルールが有効であるためです。

アプリケーションが異なるデータベースに直接またはデータベース・リンクを介して接続する場合は、すべてのデータベースに同じバージョンのタイム・ゾーン・ファイルを使用することをお薦めします。そうでない場合、これらのデータベースのTIMESTAMP WITH TIMEZONE値の計算結果に一貫性がなくなる可能性があります。これは、様々なデータベース・サーバーの異なるバージョンのタイム・ゾーン・ファイル間で影響を受けるタイム・ゾーン・リージョンに対して、異なるDSTルールが有効であるためです。

データベースのタイム・ゾーンの設定

データベースのタイム・ゾーンは、データベースの作成時に、CREATE DATABASE文のSET TIME_ZONE句を使用して設定します。データベースのタイム・ゾーンを設定しなければ、デフォルトでサーバーのオペレーティング・システムのタイム・ゾーンに設定されます。

タイム・ゾーンは、指定のリージョンまたはUTCからの絶対オフセットに設定できます。タイム・ゾーンを指定のリージョンに設定するには、次のような文を使用します。

CREATE DATABASE db01
...
SET TIME_ZONE='Europe/London';

たとえば、タイム・ゾーンをUTCからのオフセットに設定するには、次のような文を使用します。

CREATE DATABASE db01
...
SET TIME_ZONE='-05:00';

有効なオフセットの範囲は-12:00から+14:00です。

注意:
データベースのタイム・ゾーンが関連するのは、TIMESTAMP WITH LOCAL TIME ZONE列のみです。データベース間でのデータ転送時にデータ変換を回避してパフォーマンスを改善するために、データベースのタイム・ゾーンはUTC(0:00)に設定することをお薦めします。これは、分散データベース、レプリケーションおよびエクスポートとインポートには特に重要です。

データベースのタイム・ゾーンは、ALTER DATABASE文のSET TIME_ZONE句を使用して変更できます。次に例を示します。

ALTER DATABASE SET TIME_ZONE='Europe/London';
ALTER DATABASE SET TIME_ZONE='-05:00';

データベースにTIMESTAMP WITH LOCAL TIME ZONE列を含む表があり、その列にデータがあると、ALTER DATABASE SET TIME_ZONE文はエラーを返します。

変更は、データベースを停止して再起動するまで有効になりません。

次の問合せを入力すると、データベースのタイム・ゾーンを確認できます。

SELECT dbtimezone FROM DUAL;

セッションのタイム・ゾーンの設定

デフォルトのセッション・タイム・ゾーンは、ORA_SDTZ環境変数を使用して設定できます。ユーザーがTIMESTAMP WITH LOCAL TIME ZONEデータを検索すると、そのユーザー・セッションのタイム・ゾーンで戻されます。セッションのタイム・ゾーンは、TIMESTAMP値がTIMESTAMP WITH TIME ZONEまたはTIMESTAMP WITH LOCAL TIME ZONEデータ型に変換される場合にも有効です。

注意:
セッションのタイム・ゾーンを設定しても、SYSDATEおよびSYSTIMESTAMP SQL関数から戻される値には影響しません。SYSDATEは、データベースの起動時に有効だったデータベース・サーバーのオペレーティング・システムのタイム・ゾーンを考慮して、データベースが常駐するオペレーティング・システムの日時を戻します。

ORA_SDTZ環境変数は次の値に設定できます。

- オペレーティング・システムのローカルのタイム・ゾーン('OS_TZ')

- データベースのタイム・ゾーン('DB_TZ')

- UTCからの絶対オフセット('-05:00'など)

- タイム・ゾーン・リージョン名('Europe/London'など)

UNIX環境(Cシェル)でORA_SDTZを設定するには、次のような文を使用します。

% setenv ORA_SDTZ 'OS_TZ'
% setenv ORA_SDTZ 'DB_TZ'
% setenv ORA_SDTZ 'Europe/London'
% setenv ORA_SDTZ '-05:00'

ALTER SESSION文のSET TIME_ZONE句を使用して、特定のSQLセッションに対するタイム・ゾーンを変更できます。

TIME_ZONEは次の値に設定できます。

- セッション開始時のデフォルトのローカル・タイム・ゾーン(local)

- データベースのタイム・ゾーン(dbtimezone)

- UTCからの絶対オフセット('+10:00'など)

- タイム・ゾーン・リージョン名('Asia/Hong_Kong'など)

次のようなALTER SESSION文を使用します。

ALTER SESSION SET TIME_ZONE=local;
ALTER SESSION SET TIME_ZONE=dbtimezone;
ALTER SESSION SET TIME_ZONE='Asia/Hong_Kong';
ALTER SESSION SET TIME_ZONE='+10:00';

次の問合せを入力すると、現行のセッションのタイム・ゾーンを確認できます。

SELECT sessiontimezone FROM DUAL;

AT TIME ZONE句を使用したタイム・ゾーンの変換

日時SQL式には、次のいずれかを使用できます。

- 日時列

- 日時値となる複合式

日時式には、AT LOCAL句またはAT TIME ZONE句を含めることができます。AT LOCAL句を含めると、結果は現在のセッションのタイム・ゾーンで戻されます。AT TIME ZONE句を含める場合は、その句で次のいずれかの設定を使用します。

- タイム・ゾーン・オフセット: 文字列'(+|-)HH:MM'で、タイム・ゾーンをUTCからのオフセットとして指定します。たとえば、'-07:00'はUTCから7時間遅れのタイム・ゾーンを指定します。UTC時間が午前11時の場合、'-07:00'タイム・ゾーンの時間は午前4時です。

- DBTIMEZONE: Oracle Databaseでは、データベース作成時に(明示的またはデフォルトで)設定されたデータベースのタイム・ゾーンを使用します。

- SESSIONTIMEZONE: Oracleでは、デフォルトまたは最新のALTER SESSION文で設定されたセッションのタイム・ゾーンが使用されます。

- タイム・ゾーン・リージョン名: Oracle Databaseでは、タイム・ゾーン・リージョン名が示すタイム・ゾーンの値を返します。たとえば、Asia/Hong_Kongを指定できます。

- 式: 式で有効なタイム・ゾーン書式の文字列が戻されると、Oracle Databaseはそのタイム・ゾーンの入力を返します。それ以外の場合、Oracle Databaseはエラーを返します。

次の例では、America/New_Yorkタイム・ゾーンの日時値をAmerica/Los_Angelesタイム・ゾーンの日時値に変換しています。

例4-5 他のタイム・ゾーンへの日時値の変換

SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00',
'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York')
AT TIME ZONE 'America/Los_Angeles' "West Coast Time"
FROM DUAL;

West Coast Time
----------------------------------------------------------
01-DEC-99 08.00.00.000000 AM AMERICA/LOS_ANGELES

関連項目:
『Oracle Database SQL言語リファレンス』

夏時間のサポート

Oracle Databaseは、指定のタイム・ゾーンで夏時間が有効かどうかを自動的に判別し、対応するローカル時間を返します。Oracle Databaseで夏時間が特定のタイム・ゾーンで有効かどうかを判別するには、通常、日時値で十分です。夏時間の開始期間または終了期間は境界事例です。たとえば、米国東部では、夏時間が有効になる時点で、時刻が午前1時59分59秒から午前3時0分0秒に変わります。午前2時0分0秒～午前2時59分59秒の時間隔は存在しません。その時間隔に該当する値は無効です。夏時間の終了時には、時刻が午前2時0分0秒から午前1時0分1秒に変わります。午前1時0分1秒～午前2時0分0秒の時間隔が繰り返されます。この時間隔に含まれる値は、2回発生するため不明確となります。

このような境界事例を解決するために、Oracle DatabaseではTZRおよびTZD書式要素を使用します。TZRは、日時入力文字列でのタイム・ゾーン・リージョンを表します。たとえば、'Australia/North'、'UTC'および'Singapore'などです。TZDは、夏時間情報を含むタイム・ゾーン・リージョンの略称を表します。たとえば、米国太平洋標準時間の場合は'PST'、米国太平洋夏時間の場合は'PDT'です。TZRおよびTZD書式要素に対して有効な値のリストを表示するには、V$TIMEZONE_NAMES動的パフォーマンス・ビューのTZNAME列とTZABBREV列を問い合せます。

関連項目:

- ERROR_ON_OVERLAP_TIMEセッション・パラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 有効なタイム・ゾーン名のリストは、「タイム・ゾーン・リージョン名」を参照してください。

例: 日時計算への夏時間の影響

TIMESTAMPデータ型はタイム・ゾーン値を受け入れず、夏時間は計算されません。

TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型は、次のように動作します。

- タイム・ゾーン・リージョンが日時値に関連付けられている場合、データベース・サーバーではリージョンの夏時間規則が認識され、その規則が計算に使用されます。

- 夏時間を使用しないリージョンについては、夏時間は計算されません。

これ以降は、日時データ型を使用する例について説明します。例ではglobal_orders表を使用します。この表には、TIMESTAMPデータ型のorderdate1列とTIMESTAMP WITH TIME ZONEデータ型のorderdate2列が含まれます。global_orders表は次のように作成されます。

CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH TIME ZONE);
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM America/New_York');

例4-6 TIMESTAMP WITH TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較

SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR
FROM global_orders;

出力は次のようになります。

ORDERDATE1+INTERVAL'8'HOUR      ORDERDATE2+INTERVAL'8'HOUR
--------------------------      --------------------------
29-OCT-00 07.24.54.000000 AM    29-OCT-00 06.24.54.000000 AM AMERICA/NEW_YORK

この例は、各列に8時間追加した場合の影響を示しています。この期間には、夏時間の境界(夏時間から標準時間への切替え)が含まれています。orderdate1列はTIMESTAMPデータ型で、夏時間情報は使用されないため、8時間内に発生する切替えにあわせた調整は実行されません。TIMESTAMP WITH TIME ZONEデータ型では切替えにあわせて調整されるため、orderdate2列はorderdate1列より1時間早い時刻を示します。

注意:
上の例のglobal_orders表を作成した場合は、例4-7から例4-8を試す前にglobal_orders表を削除してください。

例4-7 TIMESTAMP WITH LOCAL TIME ZONEおよびTIMESTAMPを使用した夏時間計算の比較

TIMESTAMP WITH LOCAL TIME ZONEデータ型では、セッション環境にあわせて設定されたTIME_ZONEの値が使用されます。次の文は、TIME_ZONEセッション・パラメータの値を設定してglobal_orders表を作成します。global_orders表には、TIMESTAMPデータ型の1列とTIMESTAMP WITH LOCAL TIME ZONEデータ型の1列があります。

ALTER SESSION SET TIME_ZONE='America/New_York';
CREATE TABLE global_orders ( orderdate1 TIMESTAMP(0),
orderdate2 TIMESTAMP(0) WITH LOCAL TIME ZONE );
INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
'28-OCT-00 11:24:54 PM' );

両方の列に8時間を追加します。

SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR
FROM global_orders;

orderdate2の日時値にはタイム・ゾーン・リージョンが関連付けられているため、Oracle Databaseサーバーではそのリージョンに夏時間規則が使用されます。そのため、出力は例4-6と同じになります。TIMESTAMPデータ型の場合は夏時間が計算されないため、2つの計算には1時間の時差があり、計算は夏時間境界にまたがっています。

例4-8 夏時間を使用しないリージョンについては計算されない夏時間

タイム・ゾーン・リージョンをUTCに設定します。UTCでは、夏時間は使用されません。

ALTER SESSION SET TIME_ZONE='UTC';

global_orders表を切り捨てます。

TRUNCATE TABLE global_orders;

global_orders表に値を挿入します。

INSERT INTO global_orders VALUES ( '28-OCT-00 11:24:54 PM',
TIMESTAMP '2000-10-28 23:24:54 ' );

各列に8時間を追加します。

SELECT orderdate1 + INTERVAL '8' HOUR, orderdate2 + INTERVAL '8' HOUR
FROM global_orders;

出力は次のようになります。

ORDERDATE1+INTERVAL'8'HOUR                 ORDERDATE2+INTERVAL'8'HOUR
--------------------------                 ---------------------------
29-OCT-00 07.24.54.000000000 AM            29-OCT-00 07.24.54.000000000 AM UTC

UTCタイム・ゾーン・リージョンの場合は夏時間が計算されないため、時刻は同じです。

5 言語ソートと文字列検索

この章では、Oracleデータベース環境での文字列のソートと検索について説明します。

この章の内容は、次のとおりです。

- Oracleデータベースのソート機能の概要

- バイナリ・ソートの使用

- 言語ソートの使用

- 言語ソート機能

- 大/小文字区別およびアクセント区別なしの言語ソート

- 言語比較の実行

- 言語索引の使用

- 言語の文字列検索

- 多言語環境でのSQL正規表現

Oracleデータベースのソート機能の概要

ソート順序は言語によって異なります。さらに、同じアルファベットを使用している文化または国の間でも、文字のソート方法が異なる場合があります。たとえば、デンマークのÆは、Zの後にきます。また、YとÜは同じ文字の変形とみなされます。

ソート順序には、大/小文字区別の有無を指定できます。ケースは、大文字であるか小文字であるかの条件を指します。たとえばラテン・アルファベットの場合、Aが大文字で、それに対する小文字がaです。

ソート順序では、発音区別記号を無視するか考慮するかを指定できます。発音区別記号は、文字または文字列の上または下にある記号で、それが付いていない場合の文字とは発音が異なることを示します。たとえば、façadeの場合、セディラ(,)は発音区別記号です。セディラが付いている場合は、cの発音が変化します。

表音的なソート順序や、文字の外観に基づいたソート順序も指定できます。たとえば、東南アジアの表意文字の場合は、画数に基づいたソート順序を指定できます。ソート上の一般的な問題となるものに、結合文字があります。たとえば、伝統的なスペイン語のchは1つの独立した文字であり、ソート順序ではcの後にきます。つまり、正しいソート順序は、cerveza、colorado、cheremoyaのようになります。したがって、文字cは、次にくる文字がhであるかどうかが確認されるまで、ソートされません。

Oracleデータベースには、次のタイプのソートが用意されています。

- バイナリ・ソート

- 単一言語ソート

- 多言語ソート

これらのソートにより、単一言語に応じた正確なソート順序に加えて、多言語ISO規格(ISO 14651)に準拠したソートが実現できます。この規格は、複数言語を同時に処理するように設計されています。

バイナリ・ソートの使用

文字データをソートする方法の1つは、文字コード体系によって定義された文字の数値に基づいています。このようなソートをバイナリ・ソートと呼びます。バイナリ・ソートは最も高速なソート・タイプです。ASCIIやEBCDICの規格では、文字AからZを昇順の数値で定義しているため、英語のアルファベットについてはこのタイプで正しいソート結果が得られます。

注意:
ASCII規格では、大文字はすべて小文字の前にきます。逆に、EBCDIC規格では、小文字はすべて大文字の前にきます。

他の言語で使用されている文字が存在すると、通常、バイナリ・ソートでは正しい結果が得られません。たとえば、文字コード体系で、Äの数値がBの数値より高い場合、昇順のORDER BY問合せでは、ABC、ABZ、BCD、ÄBCの順で文字列が戻ります。表意文字を使用するアジア言語の場合、通常、バイナリ・ソートに言語的な意味はありません。

言語ソートの使用

文字のアルファベット順に一致するソート基準を得るには、文字コード体系内の数値に依存せずに文字をソートする別のソート方法を使用する必要があります。この方法を言語ソートと呼びます。言語ソートでは、各文字を、言語的に適切な文字順序を反映した数値に置換することによって、ソート操作を行います。

Oracleデータベースでは、単一言語ソートと多言語ソートの2種類の言語ソートを提供しています。

この項の内容は、次のとおりです。

- 単一言語ソート

- 多言語ソート

- 多言語ソート・レベル

- 言語ソートの例

単一言語ソート

Oracleデータベースでは、単一言語ソートの場合、文字列は2つの手順で比較されます。最初の手順では、メジャー値テーブルにある文字列全体のメジャー値が比較されます。通常、同じ外観の文字には、同じメジャー値があります。第2の手順では、マイナー値テーブルにあるマイナー値が比較されます。メジャー値とマイナー値はOracleデータベースによって定義されます。Oracleデータベースでは、マイナー値が異なる同じメジャー値を使用して、発音区別記号を持つ文字と大/小文字区別を定義します。

各メジャー・テーブル・エントリには、1文字のUnicodeコード・ポイントとメジャー値が含まれています。Unicodeコード・ポイントは、1文字を表す16ビットのバイナリ値です。

表5-1に、a、A、ä、Äおよびbのソートに使用するサンプルの値を示します。

表5-1 絵文字のサンプルとそのソートのメジャー値とマイナー値

絵文字

メジャー値

マイナー値

a

15

5

A

15

10

ä

15

15

Ä

15

20

b

20

5

注意:
単一言語ソートは、Unicode以外のマルチバイト・データベース・キャラクタ・セットには使用できません。データベース・キャラクタ・セットがUnicode以外のマルチバイトである場合に単一言語ソートが指定されている場合、デフォルトのソート順序はデータベース・キャラクタ・セットのバイナリ・ソート順序です。例外の1つに、UNICODE_BINARYがあります。このソートは、すべてのキャラクタ・セットに使用できます。

関連項目:
「Unicodeの概要」

多言語ソート

Oracleデータベースには多言語ソートが用意されているため、複数言語のデータを1つのソートとしてソートできます。この機能は、複雑なソート・ルールや多言語データベースを持つ地域または言語に有効です。さらに、Oracle Database 11gでは、従来のリリースで定義されたすべてのソート順序をサポートしています。

アジア諸国の言語データや多言語データに対しては、ISO 14651規格とUnicode 5.0規格に基づいたソート・メカニズムが用意されています。漢字は、画数、ピンイン(中国語の発音記号)または部首で順序付けされます。

また、多言語ソートでは、標準的な同値化および補助文字を処理できます。標準的な同値化は、文字間または文字列間での基本的な同値化です。たとえば、çは、cと,の組合せと同じです。補助文字はUnicodeでのユーザー定義文字または事前定義済の文字であり、特定のコード範囲内の2つのコード・ポイントを必要とします。1つの多言語ソートに最大110万のコード・ポイントを定義できます。

たとえば、Oracleデータベースではフランス語の単一言語ソート(FRENCH)がサポートされていますが、フランス語の多言語ソート(FRENCH_M)を指定できます。_Mは、多言語ソートに対するISO 14651規格を表します。このソート順では、GENERIC_Mソート順に基づき、発音区別記号を右から左へとソートできます。表に多言語データが格納されている場合は、多言語ソートの使用をお薦めします。表にフランス語のみが含まれている場合は、フランス語の単一言語ソートを使用する方がメモリー使用量が少ないため、パフォーマンスは向上します。メモリー使用量が少ないのは、フランス語の単一言語ソートの方が、フランス語の多言語ソートよりも定義されている文字が少ないためです。ソートの有効範囲とパフォーマンスの間には、トレードオフがあります。

関連項目:

- 「標準的な同値化」

- 「補助文字」

多言語ソート・レベル

Oracleデータベースでは、多言語ソートを次の3つの精度レベルで評価します。

- 1次レベル・ソート

- 2次レベル・ソート

- 3次レベル・ソート

1次レベル・ソート

1次レベル・ソートでは、文字aと文字bの相違など、ベース文字間の相違を識別します。aがbの前にくるか、bがaの前にくるか、あるいは同等かの定義は、個々のロケールに準じます。文字をバイナリで表現することは、意味のないことです。無視可能な文字には、0(ゼロ)の1次レベルの順序(重み)を割り当てます。その結果、その文字は1次レベルで無視されます。他のレベルでの無視可能文字には、そのレベルで順序0(ゼロ)が割り当てられます。

たとえば、1次レベルでは、batのすべてのバリエーションが、betのすべてのバリエーションより前にきます。どちらの場合も、それぞれのバリエーションは次のように様々な順序で表示されます。

Bat
bat
BAT
BET
Bet
bet

関連項目:
「無視可能文字」

2次レベル・ソート

2次レベル・ソートでは、ベース文字(1次レベル・ソート)を識別してから、特定のベース文字に付いている様々な発音区別記号を識別します。たとえば、文字Äと文字Aの相違は、発音区別記号の有無のみです。したがって、ÄとAはベース文字(A)が同じであるため1次レベルでは同じ文字になりますが、2次レベルでは異なる文字になります。

次のリストは、1次レベル(resumeがresumesの前)と2次レベル(発音区別記号なしの文字列が発音区別記号付きの文字列の前)でソートされています。

resume
résumé
Résumé
Resumes
resumes
résumés

3次レベル・ソート

3次レベル・ソートでは、ベース文字(1次レベル・ソート)、発音区別記号(2次レベル・ソート)およびケース(大文字と小文字)が識別されます。さらに、+、-および*などの特殊文字も識別できます。

次に3次レベル・ソートの例を示します。

- 文字aとAは、1次レベルと2次レベルでは同じ文字ですが、3次レベルでは異なる文字です。これは、ケースが異なるためです。

- 文字äとAは、1次レベルでは同じ文字ですが、2次レベルと3次レベルでは異なる文字です。

- ダッシュ文字-の1次レベルと2次レベルでの順序は、0(ゼロ)です。つまり、この文字は、1次と2次のレベルでは無視されます。ダッシュを1次レベルの順序が0(ゼロ)以外の別の文字、たとえば、uと比較しても、1次レベルでの結果は取得できません。これは、uと比較する対象の文字がないためです。この場合は、3次レベルでのみ-とuの相違が検索されます。

次のリストは、1次レベル(resumeがresumesの前)、2次レベル(発音区別記号なしの文字列が発音区別記号付きの文字列の前)および3次レベル(小文字が大文字の前)でソートされています。

resume
Resume
résumé
Résumé
resumes
Resumes
résumés
Résumés

言語ソート機能

この項では、次の言語ソート機能の違いについて説明します。

- ベース文字

- 無視可能文字

- 短縮文字

- 拡張文字

- 状況依存文字

- 標準的な同値化

- 逆2次ソート

- タイ語/ラオ語文字に対する文字の再配列

- 特殊文字

- 特殊組合せ文字

- 特殊な大文字

- 特殊な小文字

言語ソートは、必要な特性を含むようにカスタマイズできます。

関連項目:
第13章「ロケール・データのカスタマイズ」

ベース文字

ベース文字はベース文字表に定義されています。この表によって、各文字がベース文字にマップされます。たとえば、a、A、äおよびÄはすべて、ベース文字であるaにマップされます。この概念は、Oracle Textで作業する場合に特に重要です。

関連項目:
『Oracle Textリファレンス』

無視可能文字

多言語ソートでは、特定の文字を無視可能文字として処理できます。ソート操作または照合操作で無視可能文字を含む2つの値(文字列)を比較する際、無視可能文字はスキップされ、存在しないものとして処理されます。多言語ソートでは、1次無視可能文字と2次無視可能文字の2種類の無視可能文字を定義できます。1次無視可能文字は、任意の比較に適用される多言語ソート定義にアクセントを区別しない修飾子_AIがある場合(GENERIC_M_AIなど)に無視されます。2次無視可能文字は、適用される定義にアクセントを区別しない修飾子_AIまたは大/小文字を区別しない修飾子_CIがある場合に無視されます。

Oracle Locale Builderユーティリティの多言語ソート定義では、1次無視可能文字は分音文字と呼ばれます。1次無視可能文字は各種アルファベット(ラテン、キリル、ギリシャ、デーバナーガリー、カタカナなど)の発音区別記号(アクセント)から成りますが、Enclosing CircleやEnclosing Squareなどの装飾修飾子も含まれます。これらの文字は分音結合文字で、前の文字と結合して1つのアクセント付き文字または装飾付き文字になります。(分音とは、画面上または紙面上で、その文字が前の文字と同じ位置にあることを示します。)たとえば、英小文字eの後ろにCombining Grave Accentを付けると1文字のèになり、英大文字Aの後ろにCombining Enclosing Circleを付けると1文字の(A)になります。分音文字がアクセントを区別しないソートで無視可能と定義されているおかげで、このソートでは、たとえばrôleとrole、naïveとnaive、および(A)(B)(C)とABCを同値として処理できます。

Oracle Locale Builderユーティリティの多言語ソート定義では、2次無視可能文字は句読点と呼ばれます。2次無視可能文字は、スペース、改行制御コード、ダッシュ、各種の引用符、数値演算子、ドット、カンマ、感嘆符、各種のカッコなどで構成されます。アクセントを区別しない(_AI)ソートおよび大/小文字を区別しない(_CI)ソートでは、これらの句読点は無視されるため、multi-lingualとmultilingual、e-mailとemailを同値として処理できます。

標準の大/小文字およびアクセントを区別するソートが使用されている場合、無視可能文字は無視されません。ただし、文字列の順序を決定する際、無視可能文字は優先順位が低くなります。たとえば、GENERIC_Mソートではmulti-lingualはmultilingualの後にソートされますが、依然としてmultidimensionalとmultinational間にソートされます。順序を決定する際、ベース文字の比較d < l < nの方が、2次無視可能文字であるハイフンの有無よりも高い優先順位が付けられます。

多言語ソート定義における分音文字、句読点の完全なリストは、Oracle Locale Builderで定義を表示すると示されます。

一般に、単一言語ソート定義には句読点も分音文字も含まれません。一部の単一言語ソート定義には、空白文字とタブ文字が含まれることがあります。比較アルゴリズムでは、マイナー値が各未定義文字に自動的に割り当てられます。これにより、句読点は無視できなくなりますが、多言語ソートの場合と同様に、比較する文字列の順序を決定する際の優先順位は低くなります。単一言語ソートでの句読点間の順序はUnicodeコード・ポイントに基づいているため、ユーザーの予想とは一致しないことがあります。

関連項目:
「大/小文字区別およびアクセント区別なしの言語ソート」

短縮文字

ソート要素は、通常、単一文字で構成されていますが、一部のロケールでは、1つの文字列に2つ以上の文字がある場合があります。その場合、その文字列はソート時にも単一のソート要素とみなす必要があります。たとえば、伝統的なスペイン語の文字列chは、2つの文字で構成されています。これらの文字は、多言語ソートでは短縮文字と呼ばれ、単一言語ソートでは、特殊組合せ文字と呼ばれます。

合成文字を短縮文字と混同しないでください。áなどの合成文字は、それぞれ独自のエンコーディングを持つaと'に分解できます。合成文字と短縮文字の違いは、合成文字が端末に1文字として表示できるのに対して、短縮文字はソートにのみ使用され、それを構成する文字はそれぞれ個別に表示される必要があることです。

拡張文字

一部のロケールでは、特定の文字を文字列であるかのようにソートする必要があります。ドイツ語の文字ß(強調のs)がその例です。この文字は、文字列SSと同じようにソートされます。別の例では、öは、odの後、ofの前にoeのようにソートされます。これらの文字は、多言語ソートでは拡張文字と呼ばれ、単一言語ソートでは、特殊文字と呼ばれます。短縮文字の場合と同様、拡張文字に対する置換文字列は、ソート目的の場合のみ意味があります。

状況依存文字

日本語では、全角のダッシュ—に似た長母音記号は、先行する文字の母音を長く伸ばすことを示す長音記号を表しています。ソート順序は、長音記号の前にある母音に応じて異なります。この方法は、状況依存ソートと呼ばれます。たとえば、文字kaの後にくる長音記号—は、aを長く伸ばすことを示し、aと同じように処理されます。一方、文字kiの後にくる長音記号—は、iを長く伸ばすことを示し、iと同じように処理されます。これをラテン文字に変換すると、ソートは次のようになります。

kaa
ka—   -- kaa and ka— are the same
kai   -- kai follows ka- because i is after a
kia   -- kia follows kai because i is after a
kii   -- kii follows kia because i is after a
ki—   -- kii and ki— are the same

標準的な同値化

標準的な同値化は多言語ソートの属性であり、同値のコード・ポイント順序のソート方法を記述したものです。標準的な同値化が特定の言語ソートに適用される場合、標準的に同値の文字列は同等とみなされます。

1つのUnicodeのコード・ポイントが、一連のベース文字のコード・ポイントに発音区別記号のコード・ポイントを加えたものと同じ値である場合があります。これは、Unicodeの標準的な同値化と呼ばれます。たとえば、äはウムラウト付きのベース文字aと同じです。言語フラグCANONICAL_EQUIVALENCE = TRUEは、特定の言語ソートにUnicodeに定義されている標準的な同値化規則をすべて適用する必要があることを示します。Oracleデータベース定義の言語ソートには、標準的な同値化フラグ用の適切な設定が含まれています。すべてのデータが合成された形式の場合は、このフラグをFALSEに設定すると、比較と順序付け機能が高速になります。

たとえば、次の文字列を考えてみます。

- äa(aウムラウトの後にa)

- a¨b(aの後にウムラウトとb)

- äc(aウムラウトの後にc)

CANONICAL_EQUIVALENCE=FALSEの場合、文字列のソート順序は次のようになります。

a¨b
äa
äc

これは、標準的な同値化が適用されない場合は、aがäの前にくるためです。

CANONICAL_EQUIVALENCE=TRUEの場合、文字列のソート順序は次のようになります。

äa
a¨b
äc

これは、äとa¨が標準的に同値として処理されるためです。

Oracle Locale Builderを使用すると、既存の多言語ソートで標準的な同値化フラグの設定を表示できます。Oracle Locale Builderを使用してカスタマイズした多言語ソートを作成する場合は、標準的な同値化フラグを必要に応じて設定できます。

関連項目:
標準的な同値化フラグの設定の詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください。

逆2次ソート

フランス語では、発音区別記号付き文字を含む文字列をソートする場合、最初にベース文字が左から右の順に比較されますが、発音区別記号付き文字自体は右から左の順に比較されます。たとえば、デフォルトでは、発音区別記号付き文字は、発音区別記号が付かない文字の後に置かれます。そのため、フランス語ソートでは、ÈditはEdítの前にきます。この2つの文字列は1次レベルでは同値です。2次レベルの順序は、発音区別記号付き文字を右から左へ調べてから決定されます。個別のロケールでは、発音区別記号付き文字を右から左のルールでソートするように要求できます。逆2次ソートを使用可能にするには、REVERSE_SECONDARY言語フラグをTRUEに設定します。

関連項目:
逆2次フラグの設定の詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください。

タイ語/ラオ語文字に対する文字の再配列

タイ語とラオ語の場合は、ソート前に一部の文字を後続の文字と最初に入れ替える必要があります。通常、この種の文字は、母音を表す記号であるため、次にくる文字は子音になります。子音と母音は、ソート前に入れ替える必要があります。ソート前に入れ替える必要があるすべての文字について、SWAP_WITH_NEXT語フラグを設定してください。

関連項目:
SWAP_WITH_NEXTの詳細は、「Oracle Locale Builderを使用した新規言語ソートの作成」を参照してください。

特殊文字

特殊文字とは、単一言語ソートで使用する用語です。この文字は、多言語ソートでは、拡張文字と呼ばれます。

関連項目:
「拡張文字」

特殊組合せ文字

特殊組合せ文字とは、単一言語ソートで使用する用語です。この文字は、多言語ソートでは、短縮文字と呼ばれます。

関連項目:
「短縮文字」

特殊な大文字

1つの小文字が複数の大文字にマップされる場合があります。たとえば、伝統的なドイツ語では、ßの大文字は、SSです。

このような大/小文字の変換は、NLS_UPPER、NLS_LOWERおよびNLS_INITCAPのSQL関数によって、言語ソート基準で設定された規則に従って処理されます。SQL関数UPPER、LOWERおよびINITCAPでは、これらの特殊文字を処理できません。これは、大/小文字区別の操作が、言語に依存しない基礎となるキャラクタ・セットに定義されたバイナリ・マッピングに基づいているためです。

NLS_UPPER SQL関数は、小文字の文字列と同じキャラクタ・セットからの大文字をすべて戻します。次の例に、NLS_SORTがXGERMANに設定されている場合のNLS_UPPER関数の結果を示します。

SELECT NLS_UPPER ('große') "Uppercase" FROM DUAL;

Upper
-----
GROSSE

関連項目:
『Oracle Database SQL言語リファレンス』

特殊な小文字

Oracleデータベースは、特殊な小文字をサポートしています。1つの大文字が複数の小文字にマップされる場合があります。たとえば、トルコ語の大文字Iは、小文字のiのドットなしになります。

大/小文字区別およびアクセント区別なしの言語ソート

Oracleデータベース内の操作では、常に大/小文字およびアクセント(発音区別記号)が区別されます。大/小文字およびアクセントを区別しない比較とソートの実行が必要になる場合があります。

以前のバージョンのデータベースでは、NLS_UPPERおよびNLS_LOWERSQL関数を使用して大/小文字区別なしの問合せを実行できました。この2つの関数は、特定の言語ソート定義に基づいて文字列の大/小文字を変更します。これにより、使用言語に関係なく大/小文字を区別しない検索を実行できます。たとえば、次のようにtest1表を作成します。

SQL> CREATE TABLE test1(word VARCHAR2(12));
SQL> INSERT INTO test1 VALUES('GROSSE');
SQL> INSERT INTO test1 VALUES('Große');
SQL> INSERT INTO test1 VALUES('große');
SQL> SELECT * FROM test1;

WORD
------------
GROSSE
Große
große

GROSSEに対して、次のように大/小文字を区別した検索を実行します。

SQL> SELECT word FROM test1 WHERE word='GROSSE';

WORD
------------
GROSSE

NLS_UPPER関数を使用し、GROSSEに対して大/小文字を区別しない検索を実行します。

SELECT word FROM test1
WHERE NLS_UPPER(word, 'NLS_SORT = XGERMAN') = 'GROSSE';

WORD
------------
GROSSE
Große
große

Oracle Database 10g以降、Oracleデータベースには、言語ソートに大/小文字を区別しないオプションとアクセントを区別しないオプションが用意されています。次のタイプの単一言語ソートおよび多言語ソートがあります。

- ベース文字、発音区別記号、句読点およびケースに関する情報を使用する言語ソート。これらは、「言語ソートの使用」で説明した標準的な単一言語ソートと多言語ソートです。

- ベース文字、発音区別記号および句読点に関する情報を使用するがケースに関する情報は使用しない単一言語ソート、およびベース文字と発音区別記号に関する情報を使用するがケースと句読点に関する情報は使用しない多言語ソート。このタイプのソートを、大/小文字を区別しないソートと呼びます。

- ベース文字と句読点に関する情報のみを使用する単一言語ソート、およびベース文字に関する情報のみを使用する多言語ソート。このタイプのソートを、アクセントを区別しないソートと呼びます。(アクセントは発音区別記号と同義です。)大/小文字を区別しないソートと同様、アクセントを区別しないソートでもケースに関する情報は使用しません。

アクセントおよび大/小文字を区別しない多言語ソートでは、「無視可能文字」に記載されているように、句読点は無視されます。

これ以降の内容は、次のとおりです。

- 大/小文字およびアクセントを区別しないソートの例

- 大/小文字またはアクセントを区別しないソートの指定

関連項目:

- 「NLS_SORT」

- 「NLS_COMP」

大/小文字およびアクセントを区別しないソートの例

後述の例は、次のソートを示しています。

- ベース文字、発音区別記号、句読点およびケースに関する情報を使用するソート

- 大/小文字を区別しないソート

- アクセントを区別しないソート

例5-1 ベース文字、発音区別記号、句読点およびケース情報を使用した言語ソート

次のリストは、ベース文字、発音区別記号、句読点およびケース情報を使用してソートされています。

blackbird
black bird
black-bird
Blackbird
Black-bird
blackbîrd
bläckbird

例5-2 大/小文字を区別しない言語ソート

次のリストは、ベース文字、発音区別記号および句読点情報を使用し、ケースを無視してソートされています。

black bird
black-bird
Black-bird
blackbird
Blackbird
blackbîrd
bläckbird

black-birdとBlack-birdの違いはケースのみのため、ソートでは同じ値となります。この2つの値は、リストでどちらが前にきてもかまいません。Blackbirdとblackbirdの値もソートでは同じ値となり、リストでどちらが前にきてもかまいません。

例5-3 アクセントを区別しない言語ソート

次のリストは、ベース文字情報のみを使用してソートされています。発音区別記号、句読点およびケース情報は使用されていません。

blackbird
bläckbird
blackbîrd
Blackbird
BlackBird
Black-bird
Black bird

大/小文字またはアクセントを区別しないソートの指定

NLS_SORTセッション・パラメータを使用して、大/小文字またはアクセントを区別しないソートを指定します。

- 大/小文字を区別しないソートの場合は、Oracleソート名に_CIを追加します。

- アクセントも大/小文字も区別しないソートの場合は、Oracleソート名に_AIを追加します。

たとえば、NLS_SORTを次のタイプの値に設定できます。

FRENCH_M_AI
XGERMAN_CI

バイナリ・ソートでも、大/小文字またはアクセントを区別しないように指定できます。NLS_SORTの値としてBINARY_CIを指定すると、アクセントを区別するが大/小文字は区別しないソートを指定したことになります。BINARY_AIは、アクセントも大/小文字も区別しないバイナリ・ソートを指定します。キャラクタ・セットのバイナリ・ソート順序が使用中のキャラクタ・セットに適している場合は、バイナリ・ソートを使用します。

たとえば、NLS_LANG環境変数をAMERICAN_AMERICA.WE8ISO8859P1に設定し、次のようにtest2という表を作成して移入します。

SQL> CREATE TABLE test2 (letter VARCHAR2(10));
SQL> INSERT INTO test2 VALUES('ä');
SQL> INSERT INTO test2 VALUES('a');
SQL> INSERT INTO test2 VALUES('A');
SQL> INSERT INTO test2 VALUES('Z');
SQL> SELECT * FROM test2;

LETTER
-----------
ä
a
A
Z

NLS_SORTのデフォルト値はBINARYです。次の文を使用して、test2表内の文字のバイナリ・ソートを実行します。

SELECT * FROM test2 ORDER BY letter;

NLS_SORTの値を変更するには、次のような文を入力します。

ALTER SESSION SET NLS_SORT=BINARY_CI;

次の表に、NLS_SORTをBINARY、BINARY_CIおよびBINARY_AIに設定した結果得られるソート順を示します。

BINARY

BINARY_CI

BINARY_AI

A

a

ä

Z

A

a

a

Z

A

ä

ä

Z

NLS_SORT=BINARYの場合は、大文字が小文字の前にきます。発音区別記号付きの文字は最後に表示されます。

ソートで発音区別記号は考慮されるが大/小文字は区別されない場合(BINARY_CI)は、発音区別記号付きの文字が最後に表示されます。

大/小文字区別と発音区別記号がどちらも無視される場合(BINARY_AI)、äはベース文字aを持つ他の文字でソートされます。ベース文字aを持つ文字はすべて、zの前にきます。

キャラクタ・セットがUS7ASCIIまたはバイナリ・ソートと同じソート順序を持つキャラクタ・セットの場合は、パフォーマンスを改善するためにバイナリ・ソートを使用できます。

次の表に、表のドイツ語ソートの結果得られるソート順序を示します。

GERMAN

GERMAN_CI

GERMAN_AI

a

a

ä

A

A

a

ä

ä

A

Z

Z

Z

ドイツ語ソートでは、小文字が大文字の前にきて、äがZの前にきます。このソートで大/小文字区別と発音区別記号の両方が無視される場合(GERMAN_AI)、äはベース文字aを持つ他の文字を使用して表示されます。

言語ソートの例

この項の例は、バイナリ・ソート、単一言語ソートおよび多言語ソートを示しています。例を使用する準備として、表test3を作成して移入します。次の文を入力します。

SQL> CREATE TABLE test3 (name VARCHAR2(20));
SQL> INSERT INTO test3 VALUES('Diet');
SQL> INSERT INTO test3 VALUES('À voir');
SQL> INSERT INTO test3 VALUES('Freizeit');

例5-4 バイナリ・ソート

ORDER BY句でバイナリ・ソートを使用します。

SQL> SELECT * FROM test3 ORDER BY name;

次の出力が表示されます。

Diet
Freizeit
À voir

バイナリ・ソートの結果、À voirがリストの最後に表示されることに注意してください。

例5-5 ドイツ語の単一言語ソート

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語ソートを取得します。

SQL> SELECT * FROM test3 ORDER BY NLSSORT(name, 'NLS_SORT=german');

次の出力が表示されます。

À voir
Diet
Freizeit

ドイツ語ソートでは、À voirがリストの先頭になることに注意してください。

例5-6 ドイツ語の単一言語ソートと多言語ソートの比較

図5-1に示した文字列をtestに挿入します。この場合、横棒付きのDの後にñがきます。

図5-1 文字列

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語の単一言語ソートを実行します。

SQL> SELECT * FROM test2 ORDER BY NLSSORT(name, 'NLS_SORT=german');

ドイツ語ソートからの出力では、新しい文字列がエントリ・リストの最後に表示されます。これは、その文字がドイツ語ソートでは認識されないためです。

次の文を入力して多言語ソートを実行します。

SQL> SELECT * FROM test2 ORDER BY NLSSORT(name, 'NLS_SORT=generic_m');

出力では、ISOソート・ルールに従って新しい文字列がDietの後に表示されます。

関連項目:

- 「NLSSORT関数」

- NLS_SORTパラメータの設定と変更の詳細は、「NLS_SORT」を参照してください。

言語比較の実行

SQL比較操作を実行すると、文字はそのバイナリ値に基づいて比較されます。バイナリ値が大きい文字は、他の文字より後になります。ほとんどの言語で、バイナリの順序と言語上の順序が一致していないため、一般ユーザーにとってこのような比較は無意味です。意味のある比較をするためには、セッション・パラメータのNLS_COMPおよびNLS_SORTを使用して、動作を指定できます。この2つのパラメータの設定方法によって、文字のソートと比較に使用するルールが決定されます。

NLS_COMPの設定によって、SQL操作でNLS_SORTを処理する方法が決定されます。NLS_COMPの有効値は次の3つです。

- BINARY
SQLソートと比較はすべて、NLS_SORTに設定された値に関係なく、文字列の文字のバイナリ値に基づいて実行されます。これは、デフォルトの設定です。

- LINGUISTIC
SQLソートと比較はすべて、NLS_SORTで指定された言語ルールに従って実行されます。たとえば、NLS_COMP=LINGUISTICおよびNLS_SORT=BINARY_CIの場合、照合依存のSQL操作では、ソートと比較にバイナリ値が使用され、文字の大/小文字は無視されることを意味します。

- ANSI
NLS_SORT設定に従うのは、一連の限られたSQL関数です。ANSIは下位互換性を保つ場合のみ使用できます。通常、言語比較を実行する場合は、NLS_COMPをLINGUISTICに設定する必要があります。

表5-2に、これらの異なる設定を使用した場合のSQL操作の動作の違いを示します。

表5-2 NLS_COMP設定を使用した言語比較の動作

BINARY

LINGUISTIC

ANSI

SQL 演算子

UNION、INTERSECT、MINUS

バイナリ

NLS_SORTに従います。

バイナリ

SQL 関数

DECODE

バイナリ

NLS_SORTに従います。

バイナリ

INSTRx

バイナリ

NLS_SORTに従います。

バイナリ

LEAST、GREATEST

バイナリ

NLS_SORTに従います。

バイナリ

MAX、MIN

バイナリ

NLS_SORTに従います。

バイナリ

NLS_INITCAP

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

NLS_LOWER

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

NLS_UPPER

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

NLSSORT

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

NULLIF

バイナリ

NLS_SORTに従います。

バイナリ

REGEXP_COUNT

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REGEXP_INSTR

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REGEXP_LIKE

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REGEXP_REPLACE

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REGEXP_SUBSTR

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REPLACE

バイナリ

NLS_SORTに従います。

バイナリ

RTRIM、TRIM、LTRIM

バイナリ

NLS_SORTに従います。

バイナリ

TRANSLATE、TRANSLATE USING

バイナリ

NLS_SORTに従います。

バイナリ

SQL 式

=, !=, >, <, >=, <=

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

BETWEEN、NOT BETWEEN

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

CASE

バイナリ

NLS_SORTに従います。

バイナリ

DISTINCT

バイナリ

NLS_SORTに従います。

バイナリ

GROUP

バイナリ

NLS_SORTに従います。

バイナリ

GROUP BY

バイナリ

NLS_SORTに従います。

バイナリ

HAVING

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

IN、NOT IN

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

LIKE

バイナリ

NLS_SORTに従います。

バイナリ

ORDER BY

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

START WITH

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

UNIQUE

バイナリ

NLS_SORTに従います。

バイナリ

各パラメータの詳細は、「NLS_COMP」および「NLS_SORT」を参照してください。

照合キー

比較条件が=、!=、>、<、>=、<=、BETWEEN、NOT BETWEEN、IN、NOT INの場合、問合せ句ORDER BYまたはGROUP BY、または集計関数COUNT(DISTINCT)は、NLS_SORTで指定された言語ルールに従って評価され、比較引数値が照合キーと呼ばれるバイナリ値に最初に変換され、RAW値のようにバイト単位で比較されます。単一言語ソートが適用されると、照合キーには、ソース値の文字のメジャー値とこれらの文字のマイナー値が連結して格納されます。多言語ソートが適用されると、照合キーには、1次、2次および3次値が連結されて格納されます。

照合キーは、NLSSORT関数で戻される値と同じ値になります。つまり、これらのSQL操作の言語動作を有効にすることは、それらの引数をNLSSORT関数のコールに含めるのと同じです。

言語比較の精度の制限

照合キーはデータ型がRAWの値で、RAW値の最大長は200バイトのため、照合キーの最大長は2000バイトに制限されます。全ソースの文字の値で2000バイトを超える照合キーが生成されると、この値で生成された照合キーで値の最大接頭辞(先頭の部分文字列)が計算され、計算結果が2000バイトを超えることはなくなります。単一言語ソートでは、接頭辞の長さは一般的に1000文字になります。複数言語ソートでは、接頭辞は一般的に500文字になります。正確な長さは、特定の照合およびソース値に含まれる特定の文字によって増減する場合があります。

照合キーの生成でこの方法を使用すると、照合キーを使用して言語動作を実行するSQL操作で、長い引数の終了部分が無視される場合があります。たとえば、先頭の1000文字が同じで、それ以降の任意の位置の値が異なる2つの文字の値は、GROUP BY句で一緒にグループ化されます。

言語比較の例

次に、異なるNLS_COMP設定を使用した動作の例を示します。

例5-7 バイナリ比較のバイナリ・ソート

次に、バイナリ設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT ename FROM emp1;

ENAME
----------------------
Mc Calla
MCAfee
McCoye
Mccathye
McCafeé

5 rows selected

SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye

1 row selected

例5-8 言語比較の大/小文字区別なしのバイナリ・ソート

次に、大/小文字を区別しない設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_CI;
SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye
Mccathye

2 rows selected

例5-9 言語比較のアクセント区別なしのバイナリ・ソート

次に、アクセントを区別しない設定を使用した動作を示します。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_AI;
SQL> SELECT ename FROM emp1 WHERE ename LIKE 'McC%e';

ENAME
----------------------
McCoye
Mccathye
McCafeé

3 rows selected

例5-10 戻す行が少なくなる言語比較

一部の操作では、言語ルールを適用すると、戻される行が少なくなる場合があります。たとえば、バイナリ設定の場合、次のようにMcAfeeとMcafeeは異なります。

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT DISTINCT ename FROM emp2;

ENAME
----------------------
McAfee
Mcafee
McCoy

3 rows selected

ただし、大/小文字の区別なし設定の場合、McAfeeとMcafeeは同じです。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=BINARY_CI;
SQL> SELECT DISTINCT ename FROM emp2;

ENAME
----------------------
McAfee
McCoy

2 rows selected

この例では、McAfeeまたはMcafeeのいずれかがDISTINCT操作で戻される可能性があります。どちらが選択されるかを正確に保証することはできません。

例5-11 XSPANISHを使用した言語比較

バイナリ比較を使用した場合は文字が同じで、言語比較を使用した場合は文字が異なるケースがあります。たとえば、バイナリ設定では、Cindy、ChadおよびClaraの文字Cは、次のように、同じ文字Cを表します。

SQL> ALTER SESSION SET NLS_COMP=BINARY;
SQL> ALTER SESSION SET NLS_SORT=BINARY;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
----------------------
Cindy
Chad
Clara

3 rows selected

言語ルールが伝統的なスペイン語のXSPANISHに設定されているデータベース・セッションでは、chは、1文字として処理されます。この場合、Chadの文字cは、CindyやClaraの文字Cとは異なります。

SQL> ALTER SESSION SET NLS_COMP=LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT=XSPANISH;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
----------------------
Cindy
Clara

2 rows selected

またchという組合せの場合の文字cは、単独の文字cとは異なります。

SQL> SELECT REPLACE ('character', 'c', 't') "Changes" FROM DUAL;

Changes
---------------------
charatter

言語索引の使用

言語ソートは言語固有であるため、バイナリ・ソートよりもデータ処理が増えます。ASCII文字のバイナリ・コードには文字の順序が反映されているため、言語ASCIIのバイナリ・ソートを使用すると正確で高速です。複数言語のデータがデータベースに格納されている場合、アプリケーションでは、言語に応じて異なるソート基準に従い、SELECT...ORDER BY文から戻されたデータをソートできます。このようなソートは、言語索引を使用すると、パフォーマンスを低下させずに実現できます。列の言語索引によって、挿入と更新の操作速度が低下しますが、ORDER BY句およびWHEREを使用した言語ソートのパフォーマンスは大幅に向上します。

英語以外の言語を使用する関数索引を作成できます。この索引は、NLS_SORTで決められている言語ソート順序を変更しません。言語索引は単にパフォーマンスを向上させるためのものです。

次の文では、ドイツ語のソートに基づく索引が作成されます。

CREATE TABLE my_table(name VARCHAR(20) NOT NULL);
CREATE INDEX nls_index ON my_table (NLSSORT(name, 'NLS_SORT = German'));

/*The NOT NULL in the CREATE TABLE statement ensures that the index is used*/

索引の作成後に、次の例ようなSELECT文を入力します。

SELECT * FROM my_table ORDER BY name
WHERE name LIKE 'Hein%';

この文は、言語索引を使用しない場合の同じSELECT文より速く結果が戻されます。

これ以降の内容は、次のとおりです。

- 言語索引でサポートされるSQL操作および機能

- 複数言語の言語索引

- 言語索引の使用要件

関連項目:

- 『Oracle Database概要』

- ファンクション索引の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

言語索引でサポートされるSQL操作および機能

言語索引サポートは、次の照合依存のSQL操作およびSQL機能で使用できます。

- 比較条件: =、!=、>、<、>=、<=

- 範囲条件: BETWEEN | NOT BETWEEN

- IN | NOT IN

- ORDER BY

- GROUP BY

- LIKE(LIKE、LIKE2、LIKE4、LIKEC)

- DISTINCT

- UNIQUE

- UNION

- INTERSECT

- MINUS

次のリストのSQL関数では、言語索引を使用できません。

- INSTR(INSTR、INSTRB、INSTR2、INSTR4、INSTRC)

- MAX

- MIN

- REPLACE

- TRIM

- LTRIM

- RTRIM

- TRANSLATE

複数言語の言語索引

複数言語のデータに言語索引を作成する方法には、次の3通りがあります。

- アプリケーションでサポートされている各言語の言語索引を作成します。このアプローチは単純ですが、大量のディスク領域が必要になります。索引ごとに、その索引が作成されている言語以外の言語の複数行が、順番の最後にまとめて照合されます。次の例では、フランス語とドイツ語の言語索引を作成しています。

CREATE INDEX french_index ON employees (NLSSORT(employee_id, 'NLS_SORT=FRENCH'));
CREATE INDEX german_index ON employees (NLSSORT(employee_id, 'NLS_SORT=GERMAN'));

使用する索引は、ORDER BY句で指定したNLS_SORTセッション・パラメータまたはNLSSORT関数の引数によって決定されます。たとえば、NLS_SORTセッション・パラメータがFRENCHに設定されている場合、Oracle Databaseではfrench_indexが使用されます。GERMANに設定されている場合は、german_indexが使用されます。

- すべての言語に対して単一言語索引を作成します。そのためには、NLSSORT関数のパラメータとして言語列(「例: フランス語の言語索引の設定」のLANG_COL)を使用する必要があります。この言語列には、索引の作成対象となる列のデータのNLS_LANGUAGE値が含まれます。次の例では、複数言語に対する単一言語索引を作成しています。の索引では、NLS_LANGUAGEに対して同じ値を持つ行がまとめてソートされます。

CREATE INDEX i ON t (NLSSORT(col, 'NLS_SORT=' || LANG_COL));

問合せでは、ORDER BY句で指定したNLSSORT関数の引数に基づいて索引が選択されます。

- GENERIC_MやFRENCH_Mなどの多言語ソートのいずれかを使用して、すべての言語に単一言語索引を作成します。この索引は、ISO 14651に定義されている規則に従って文字をソートします。次に例を示します。

CREATE INDEX i on t (NLSSORT(col, 'NLS_SORT=GENERIC_M');

関連項目:
Unicodeソートの詳細は、「多言語ソート」を参照してください。

言語索引の使用要件

言語索引を使用するための要件は、次のとおりです。

- NLS_SORTを適切に設定

- 列がNOT NULLとして宣言されていない場合にWHERE句でNOT NULLを指定する方法

この項では、次の例についても説明します。

- 例: フランス語の言語索引の設定

NLS_SORTを適切に設定

NLS_SORTパラメータで、言語ソートに使用する言語定義を指定する必要があります。たとえば、フランス語の言語ソート順序を使用する場合は、NLS_SORTをFRENCHに設定する必要があります。たとえば、フランス語の言語ソート順序を使用する場合は、NLS_SORTをGERMANに設定する必要があります。

NLS_SORTを設定するには、複数の方法があります。すべての言語に同じSQL文を使用できるように、NLS_SORTをクライアントの環境変数として設定する必要があります。クライアント環境でNLS_SORTを設定すると、様々な言語索引を使用できます。

関連項目:
「NLS_SORT」

列がNOT NULLとして宣言されていない場合にWHERE句でNOT NULLを指定する方法

言語索引を持つ列でORDER BY column_name句を使用する必要がある場合は、次の例のようにWHERE句を含めます。

WHERE NLSSORT(column_name) IS NOT NULL

列がスキーマ内でNOT NULL列として定義されていれば、このWHERE句は必要ありません。

例: フランス語の言語索引の設定

次の例では、フランス語の言語索引の設定方法を示します。ALTER SESSION文を使用するかわりに、NLS_SORTをクライアントの環境変数として設定することもできます。

ALTER SESSION SET NLS_SORT='FRENCH';
CREATE INDEX test_idx ON test4(NLSSORT(name, 'NLS_SORT=FRENCH'));
SELECT * FROM test4 ORDER BY col;
ALTER SESSION SET NLS_COMP=LINGUISTIC;
SELECT * FROM test4 WHERE name > 'Henri';

注意:
NLS_COMPがLINGUISTICに設定されている場合、SQL関数MAX()およびMIN()では、言語索引を使用できません。

言語の文字列検索

検索とソートは関連するタスクです。業務を適切に行うには、言語的に意味のある順序でデータを編成して処理する必要があります。言語的に意味のある方法によるデータの検索と照合は、適用されるソート順序に依存します。たとえば、cより後でfより前の文字列すべてを検索すると、NLS_SORTの値に応じて異なる結果が生成されます。ASCIIバイナリ・ソートでは、dまたはeで始まる文字列が検出されますが、大文字のDまたはEまたはêのような発音区別記号付きeなどで始まる項目は除外されます。アクセントを区別しないバイナリ・ソートを適用すると、d、DおよびÊやêなどのアクセント付きeで始まる文字列がすべて戻されます。NLS_SORTをXSPANISHに設定して同じ検索を適用した場合は、chで始まる文字列も戻されます。これは、従来のスペイン語ではchがcとdの間をソートする複合文字として扱われるためです。この章では、Oracleデータベースのソートの種類と、各ソートがSQLおよびSQL正規表現による文字列検索に与える影響について説明します。

関連項目:

- 「言語ソート機能」

- 「多言語環境でのSQL正規表現」

多言語環境でのSQL正規表現

正規表現は、テキスト本体に含まれる文字列のパターンを識別する強力な方法を提供します。正規表現の用途には、San Franciscoのような文字列の単純検索や、すべてのURLを抽出する複雑なタスク、さらに2文字目に母音を含むすべての単語の検索などのタスクがあります。SQLとPL/SQLは、Oracleデータベースの正規表現をサポートしています。

従来の正規表現エンジンは、英語のテキストのみを処理するように設計されていました。ただし、正規表現の実装には、西欧のテキストとはまったく異なる特性を持った多様な言語を含めることができます。Oracleデータベースの正規表現の実装は、Unicode正規表現ガイドラインに基づいています。REGEXP SQL関数は、データベース・キャラクタ・セットおよび各国語キャラクタ・セットとしてサポートされるキャラクタ・セットをすべて処理します。さらに、Oracleデータベースでは、多言語データの照合に関する固有の言語要件を処理するために、POSIXの正規表現構成メンバーの照合機能が拡張されます。

次の項では、言語依存演算子のOracle拡張について説明します。

- 正規表現での文字範囲'[x-y]'

- 正規表現での照合要素デリミタ'[. .]'

- 正規表現での文字クラス'[: :]'

- 正規表現での同値化クラス'[= =]'

- 例: 正規表現

関連項目:

- 正規表現の構文の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- REGEX SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

正規表現での文字範囲'[x-y]'

POSIX規格では、正規表現での範囲には、現行ロケールの言語定義による範囲の始点から終点までの照合要素がすべて含まれます。したがって、正規表現の範囲はバイト値の範囲ではなく言語上の範囲を意味します。これは、バイト値の範囲はプラットフォームに依存し、エンド・ユーザーが文字のバイト値の順序を知っているとは思われないためです。範囲式のセマンティクスは、キャラクタ・セットから独立させる必要があります。これは、[a-d]などの範囲には、aからdのすべての文字、これらの文字に発音区別記号が付いたもの、伝統的なスペイン語におけるchのように1文字としてソートされる特殊ケースの照合要素が含まれることを意味します。

Oracle Databaseでは、NLS_SORTパラメータで指定された範囲式が解析され、指定の範囲に含まれる照合要素が判別されます。次に例を示します。

Expression:     [a-d]e
NLS_SORT:       BINARY
Does not match: cheremoya
NLS_SORT:       XSPANISH
Matches:        >>che<<remoya

正規表現での照合要素デリミタ'[. .]'

この構成メンバーは、照合要素を区切るためにPOSIX規格により導入されています。照合要素とは照合単位であり、ほとんどの場合は1文字に相当します。ただし、言語によっては、照合順序により2文字以上が1つの照合要素として定義される場合があります。従来の正規表現構文では、ユーザーは複数文字による照合要素が関係する範囲を定義できません。たとえば、chは2つの異なる文字として解析されるため、aからchは範囲として定義できません。

照合要素デリミタ[. .]を使用すると、複数文字による照合要素と他の要素を区切ることができます。たとえば、範囲aからchは、[a-[.ch.]]として記述できます。また、1文字の照合要素を区切る場合にも使用できます。定義済の照合要素でない複数言語による順序を[. .]で囲むと、正規表現ではセマンティック・エラーとみなされます。たとえば、abが定義済の複数文字による照合要素でない場合、[.ab.]は無効とみなされます。

正規表現での文字クラス'[: :]'

英語の正規表現では、範囲式を使用して文字クラスを示すことができます。たとえば、[a-z]を使用すると任意の小文字を指定できます。ただし、英語以外の正規表現では、その言語の照合順序でaが最初の小文字でzが最後の小文字でなければ、このアプローチを使用すると不正確になります。

POSIX規格では、明示的な文字クラスを移植性のある方法で指定できるように、新しい構文要素が導入されています。[: :]構文は、特定の文字クラスに属しているキャラクタ・セットを示します。文字クラス定義は、キャラクタ・セットの分類データに基づきます。

正規表現での同値化クラス'[= =]'

Oracle Databaseは、POSIX規格で推奨される[= =]構文を介して同値化クラスもサポートしています。同値化クラスは、ベース文字とそのすべてのアクセント付きバージョンで構成されます。たとえば、同値化クラス[=a=]は、âおよびäと一致します。パフォーマンス上の理由で、現行の実装ではUnicodeの複合形式と分解形式の照合はサポートされません。たとえば、ä(aウムラウト)は、ウムラウトが続くaとは一致しません。

例: 正規表現

次の例に、正規表現の一致を示します。

例5-12 NLS_SORT値を使用した大/小文字を区別しない一致

Oracleデータベースの正規表現の一致では、大/小文字区別の有無は、NLS_SORT初期化パラメータとランタイム照合オプションの2つのレベルで決定されます。REGEXP関数は、デフォルトでNLS_SORTの値から大/小文字区別の動作を継承します。この値は、ランタイム照合オプション'c'(大小文字区別あり)または'i'(大/小文字区別なし)で明示的に上書きすることもできます。

Expression: catalog(ue)?
NLS_SORT: GENERIC_M_CI
Matches:

>>Catalog<<
>>catalogue<<
>>CATALOG<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> ALTER SESSION SET NLS_SORT='GENERIC_M_CI';
SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'catalog(ue)?');

例5-13 ランタイム照合オプションで上書きされた大/小文字区別の有無

Expression: catalog(ue)?
NLS_SORT: GENERIC_M_CI
Match option: 'c'
Matches:

>>catalogue<<

Does not match:

Catalog
CATALOG

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> ALTER SESSION SET NLS_SORT='GENERIC_M_CI';
SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'catalog(ue)?','c');

例5-14 照合要素演算子[..]を使用した照合

Expression: [^-a-[.ch.]]+  /*with NLS_SORT set to xspanish*/
Matches:

>>driver<<

Does not match:

cab

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'[^-a-[.ch.]]+');

例5-15 文字クラス演算子[::]を使用した照合

この式では、小文字6文字からなる文字列が検索されます。アクセント付き文字は、小文字として一致することに注意してください。

Expression: [[:lower:]]{6}
Database character set: WE8ISO8859P1
Matches:

>>maître<<
>>mòbile<<
>>pájaro<<
>>zurück<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'[[:lower:]]{6}');

例5-16 ベース文字演算子[==]を使用した照合

Expression: r[[=e=]]sum[[=e=]]
Matches:

>>resume<<
>>résumé<<
>>résume<<
>>resumé<<

Oracle DatabaseのSQL構文は、次のとおりです。

SQL> SELECT col FROM test WHERE REGEXP_LIKE(col,'r[[=e=]]sum[[=e=]]');

関連項目:

- 正規表現の構文の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- REGEX SQL関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

6 Unicodeを使用した多言語データベースのサポート

この章では、Oracleデータベース環境でのUnicodeの使用方法について説明します。この章の内容は、次のとおりです。

- Unicodeの概要

- Unicodeの内容

- Unicodeソリューションのデータベースへの実装

- Unicodeの事例

- 複数言語サポートのためのデータベース・スキーマ設計

Unicodeの概要

Unicodeは、世界中で話されているほとんどの言語のあらゆる文字を定義する文字コード・システムです。

既存の文字エンコーディングの制約を克服するために、1980年代の後半、複数の組織がグローバル・キャラクタ・セットの作成に着手しました。グローバル・キャラクタ・セットの必要性は、1990年代中頃に入り、World Wide Webの発展とともにますます大きくなりました。インターネットの普及によってビジネスの形態が変化し、グローバル・マーケットに重点が置かれるようになったため、ユニバーサル・キャラクタ・セットが重要な必要条件になってきました。

このグローバル・キャラクタ・セットは、次の条件を満たす必要があります。

- 現在使用されているすべての主要文字を網羅していること。

- レガシー・データや実装をサポートしていること。

- 1つのアプリケーションの1つの実装で、世界中で使用できるような単純なキャラクタ・セットであること。

また、グローバル・キャラクタ・セットには次の機能も必要です。

- 多言語ユーザーや組織のサポート

- 国際規格への準拠

- 世界規模でのデータ交換

現在、Unicodeは広く使用され、グローバル・キャラクタ・セットに対するあらゆる要求と機能に満たします。

Unicodeの内容

Unicodeは、任意の言語の情報を単一のキャラクタ・セットを使用して格納できる全世界共通のエンコード・キャラクタ・セットです。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。

多くのソフトウェアおよびハードウェア・ベンダーがUnicode規格を採用しており、多くのオペレーティング・システムやブラウザがUnicodeをサポートしています。Unicodeは、XML、Java、JavaScript、LDAPおよびWMLなどの規格には必須です。ISO/IEC 10646規格とも同期化されています。

Oracle Database 7で、データベース・キャラクタ・セットとしてUnicodeが導入されました。Oracle Database 11gではUnicodeのサポートが拡張され、Unicode 5.0がサポートされています。

関連項目:
Unicode規格の詳細は、http://www.unicode.orgを参照してください。

この項の内容は、次のとおりです。

- 補助文字

- Unicodeエンコーディング

- OracleデータベースによるUnicodeのサポート

補助文字

Unicodeの最初のバージョンは16ビットの固定幅エンコーディングで、各文字のエンコーディングに2バイトを使用していました。このため、65,536文字を表現できました。しかし、サポートを必要とする文字数が増え、特に中国語、日本語および韓国語市場では、追加のCJK表意文字のサポートが必要となりました。

Unicodeでは、このニーズを満たすために補助文字が定義されています。2つの16ビット・コード・ポイント(補助文字とも呼ばれる)を使用して、1つの文字が表現されます。補助文字を実装すると、さらに100万以上の文字を定義できます。

補助文字の追加によってUnicodeは複雑度を増しましたが、同じ構成で複数の異なるエンコーディングを管理するよりは単純です。

Unicodeエンコーディング

Unicode規格では、文字はUTF-8、UCS-2およびUTF-16という方法でエンコードされます。Unicodeエンコーディング間の変換は、Unicode規格に定義されている単純なビット単位操作です。

この項の内容は、次のとおりです。

- UTF-8エンコーディング

- UCS-2エンコーディング

- UTF-16エンコーディング

- 例: UTF-16、UTF-8およびUCS-2エンコーディング

UTF-8エンコーディング

UTF-8とは、Unicodeの8ビット・エンコーディングのことです。これは可変幅エンコーディングであり、ASCIIの完全なスーパーセットです。これは、ASCIIキャラクタ・セットの各文字を、UTF-8で同じコード・ポイント値とともに使用できることを意味します。UTF-8エンコーディングでは、1つのUnicode文字を、1バイト、2バイト、3バイトまたは4バイトで表すことができます。ヨーロッパ言語の文字は、1バイトまたは2バイトで表します。ほとんどのアジア言語の文字は、3バイトで表します。補助文字は、4バイトで表します。

UTF-8は、HTMLやほとんどのインターネット・ブラウザで使用されるUnicodeエンコーディングです。

UTF-8の利点は、次のとおりです。

- ASCIIの完全なスーパーセットであるため、ヨーロッパ言語の記憶要件が小規模です。

- ASCIIベースのキャラクタ・セットとUTF-8の間の移行が容易です。

関連項目:

- 「補助文字」

- 表B-2「UTF-8文字コード用のUnicode文字コード範囲」

UCS-2エンコーディング

UCS-2は固定幅の16ビット・エンコーディングで、各文字は2バイトです。UCS-2は、バージョンJ2SE 5.0より前のJavaおよびMicrosoft Windows NTで内部処理に使用されているUnicodeエンコーディングです。UCS-2ではUnicode 3.0に定義されている文字がサポートされるため、補助文字のサポート機能はありません。

UTF-8と比較したUCS-2の利点は、次のとおりです。

- すべての文字が2バイトであるため、アジア言語の場合は記憶要件がさらに小規模です。

- 文字が固定幅であるため、文字列の処理が高速です。

- JavaおよびMicrosoftクライアントとの優れた互換性があります。

関連項目:
「補助文字」

UTF-16エンコーディング

UTF-16エンコーディングとは、Unicodeの16ビット・エンコーディングのことです。UTF-16は、UCS-2の拡張です。これは、各補助文字に2つのUCS-2コード・ポイントを使用することで補助文字をサポートするためです。UTF-16は、UCS-2の完全なスーパーセットです。

UTF-16では、1文字を2バイトか4バイトで表すことができます。ヨーロッパ言語とほとんどのアジア言語の文字は、ともに2バイトで表します。補助文字は、4バイトで表します。UTF-16は、バージョンJ2SE 5.0以降のJavaおよびバージョン2000以降のMicrosoft Windowsで内部処理に使用されているメインのUnicodeエンコーディングです。

UTF-8と比較したUTF-16の利点は、次のとおりです。

- 一般に使用されるアジア言語の文字のほとんどは2バイトで表されるため、アジア言語の場合は記憶要件がさらに小規模です。

- JavaおよびMicrosoftクライアントとの優れた互換性があります。

関連項目:

- 「補助文字」

- 表B-1「UTF-16文字コード用のUnicode文字コード範囲」

例: UTF-16、UTF-8およびUCS-2エンコーディング

図6-1に、UTF-16、UTF-8およびUCS-2の各エンコーディングの文字とその文字コードを示します。最後の文字はト音記号(音楽記号)で、補助文字です。

図6-1 UTF-16、UTF-8およびUCS-2エンコーディングの例

OracleデータベースによるUnicodeのサポート

Oracleデータベースのキャラクタ・セットとして、リリース7のときにUnicodeのサポートを開始しました。表6-1に、OracleデータベースでサポートされているUnicodeキャラクタ・セットを示します。

表6-1 Oracle DatabaseでサポートされているUnicodeキャラクタ・セット

キャラクタ・セット

サポートしているRDBMSのリリース

Unicodeエンコーディング

Unicodeのバージョン

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

各国語キャラクタ・セット

AL24UTFFSS

7.2 - 8i

UTF-8

1.1

可能

不可

UTF8

8.0 - 11g

UTF-8

Oracle Databaseリリース8.0からOracle8iリリース8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

可能

可能(Oracle9i Database以上のみ)

UTFE

8.0 - 11g

UTF-EBCDIC

Oracle8i Databaseリリース8.0から8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

可能

不可

AL32UTF8

9i - 11g

UTF-8

Oracle9i Databaseリリース1の場合: 3.0

Oracle9i Databaseリリース2の場合: 3.1

Oracle Database 10gリリース1の場合: 3.2

Oracle Database 10gリリース2の場合: 4.0

Oracle Database 11gの場合: 5.0

可能

不可

AL16UTF16

9i - 11g

UTF-16

Oracle9i Databaseリリース1の場合: 3.0

Oracle9i Databaseリリース2の場合: 3.1

Oracle Database 10gリリース1の場合: 3.2

Oracle Database 10gリリース2の場合: 4.0

Oracle Database 11gの場合: 5.0

不可

可能

Unicodeソリューションのデータベースへの実装

次の2つの方法でUnicode文字をOracle Databaseに格納できます。

- Unicodeデータベースを作成すると、UTF-8エンコードされた文字をSQL CHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)として格納できます。

- Unicodeサポートを段階的に実装する場合、または特定の列の多言語データのみをサポートする必要がある場合、UnicodeデータはSQL NCHARデータ型(NCHAR、NVARCHAR2およびNCLOB)のUTF-16またはUTF-8エンコーディング方式のいずれかで格納できます。SQL NCHARデータ型は、Unicodeデータの格納専用に使用されるため、Unicodeデータ型と呼ばれます。

注意:
Unicodeデータベース・ソリューションは、Unicodeデータ型ソリューションと組み合せることができます。

次の項で、2つのUnicodeソリューションの使用方法とその選択方法を説明します。

- Unicodeデータベースを使用した多言語サポートの有効化

- Unicodeデータ型を使用した多言語サポートの有効化

- UnicodeデータベースとUnicodeデータ型のソリューションの選択方法

- データベースおよびデータ型ソリューションに関するUnicodeキャラクタ・セットの比較

Unicodeデータベースを使用した多言語サポートの有効化

データベース・キャラクタ・セットでは、SQL CHARデータ型の他に、表名、列名およびSQL文などのメタデータに使用するエンコーディングが指定されます。Unicodeデータベースとは、UTF-8をデータベース・キャラクタ・セットとして持つデータベースのことです。UTF-8エンコーディングを実装しているOracleキャラクタ・セットは3つあります。最初の2つは、ASCIIベースのプラットフォーム用に設計されており、3つ目は、EBCDICプラットフォーム上で使用する必要があります。

- AL32UTF8
AL32UTF8 キャラクタ・セットは、最新バージョンのUnicode規格をサポートしています。このキャラクタ・セットは、各文字を1バイト、2バイトまたは3バイトでエンコードします。このキャラクタ・セットでは、各文字は1バイト、2バイトまたは3バイトでエンコードされ、 補助文字には4バイトが必要です。ASCIIベースのプラットフォーム用です。

- UTF8
UTF8キャラクタ・セットは、各文字を1バイト、2バイトまたは3バイトでエンコードします。ASCIIベースのプラットフォーム用です。

UTF8データベースに補助文字が挿入されても、データベース内のデータは破損しません。補助文字は、6バイトを占める2つの別個のユーザー定義文字として処理されます。データベース・キャラクタ・セット内の補助文字を全面的にサポートするために、AL32UTF8に切り替えることをお薦めします。

- UTFE
UTFEキャラクタ・セットはEBCDICプラットフォーム用です。このキャラクタ・セットはASCIIプラットフォーム上でのUTF8に似ていますが、各文字を1バイト、2バイト、3バイトおよび4バイトでエンコードします。補助文字は2つの4バイト文字として変換されます。

例6-1 Unicodeキャラクタ・セットを使用したデータベースの作成

AL32UTF8キャラクタ・セットを使用してデータベースを作成するには、CREATE DATABASE文にCHARACTER SET AL32UTF8句を使用します。次に例を示します。

CREATE DATABASE sample

CONTROLFILE REUSE
LOGFILE

GROUP 1 ('diskx:log1.log', 'disky:log1.log') SIZE 50K,
GROUP 2 ('diskx:log2.log', 'disky:log2.log') SIZE 50K

MAXLOGFILES 5
MAXLOGHISTORY 100
MAXDATAFILES 10
MAXINSTANCES 2
ARCHIVELOG
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
DATAFILE

'disk1:df1.dbf' AUTOEXTEND ON,
'disk2:df2.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED

DEFAULT TEMPORARY TABLESPACE temp_ts
UNDO TABLESPACE undo_ts
SET TIME_ZONE = '+02:00';

注意:
データベース・キャラクタ・セットは、データベースの作成時に指定します。

Unicodeデータ型を使用した多言語サポートの有効化

データベースにUnicodeデータを格納する代替方法は、SQL NCHARデータ型(NCHAR、NVARCHAR、NCLOB)を使用することです。データベース・キャラクタ・セットの定義方法に関係なく、これらのデータ型の列にUnicode文字を格納できます。NCHARデータ型はUnicodeデータ型専用です。つまり、このデータ型は、Unicodeとしてエンコードされたデータを格納します。

NVARCHAR2とNCHARのデータ型を使用すると、表を作成できます。NCHAR列とNVARCHAR2列に指定する列の長さは、次のように常にバイト数ではなく文字数です。

CREATE TABLE product_information
( product_id          NUMBER(6)
, product_name        NVARCHAR2(100)
, product_description VARCHAR2(1000));

SQL NCHARデータ型で使用するエンコーディングは、データベース用に指定される各国語キャラクタ・セットです。次のOracleキャラクタ・セットのいずれかを、各国語キャラクタ・セットとして指定できます。

- AL16UTF16
これは、SQL NCHARデータ型のデフォルトのキャラクタ・セットです。このキャラクタ・セットは、UnicodeデータをUTF-16エンコーディングでエンコードします。また、4バイトとして格納される補助文字をサポートします。

- UTF8
SQL NCHARデータ型にUTF8を指定すると、SQLデータ型で格納されているデータは、UTF-8エンコーディングになります。

NATIONAL CHARACTER SET句を指定したCREATE DATABASE文を使用してデータベースを作成する場合は、SQL NCHARデータ型に各国語キャラクタ・セットを指定できます。次の文では、データベース・キャラクタ・セットとしてWE8ISO8859P1を持ち、各国語キャラクタ・セットとしてAL16UTF16を持つデータベースを作成します。

例6-2 各国語キャラクタ・セットを使用したデータベースの作成

CREATE DATABASE sample

CONTROLFILE REUSE
LOGFILE

GROUP 1 ('diskx:log1.log', 'disky:log1.log') SIZE 50K,
GROUP 2 ('diskx:log2.log', 'disky:log2.log') SIZE 50K

MAXLOGFILES 5
MAXLOGHISTORY 100
MAXDATAFILES 10
MAXINSTANCES 2
ARCHIVELOG
CHARACTER SET WE8ISO8859P1
NATIONAL CHARACTER SET AL16UTF16
DATAFILE

'disk1:df1.dbf' AUTOEXTEND ON,
'disk2:df2.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED

DEFAULT TEMPORARY TABLESPACE temp_ts
UNDO TABLESPACE undo_ts
SET TIME_ZONE = '+02:00';

UnicodeデータベースとUnicodeデータ型のソリューションの選択方法

データベースに対する適切なUnicodeソリューションを選択するには、次の問題を考慮してください。

- プログラミング環境: アプリケーションで使用されている主要なプログラミング言語は何か。これらのプログラミング言語は、どのようにUnicodeをサポートしているか。

- 移行の容易さ: Unicodeソリューションを利用するために、データとアプリケーションを移行することに問題はないか。

- データの種類: データの大部分は、アジア言語、あるいはヨーロッパ言語か。多言語ドキュメントをLOB列に格納する必要があるか。

- アプリケーションの種類: 実装しているアプリケーションの種類は何か。パッケージ・アプリケーションか、あるいはカスタマイズしたエンド・ユーザー・アプリケーションか。

この項では、Unicodeデータベース・ソリューションまたはUnicodeデータ型ソリューションを選択する場合の一般的なガイドラインを説明します。最終的な決定は、主として各自の正確な環境と要件に基づいて行います。この項の内容は、次のとおりです。

- Unicodeデータベースの使用が必要な状況

- Unicodeデータ型の使用が必要な状況

Unicodeデータベースの使用が必要な状況

表6-2に、Unicodeデータベースを使用する状況を示します。

表6-2 Unicodeデータベースの使用

状況

説明

JavaまたはPL/SQLに対する簡単なコード移行が必要な場合

既存のアプリケーションが主としてJavaとPL/SQLで作成されており、複数言語のサポートに必要なコード変更を最小限にすることが最優先の課題である場合は、Unicodeデータベース・ソリューションを使用できます。データの格納に使用するデータ型がSQL CHARデータ型のままである場合は、これらの列にアクセスするJavaとPL/SQLのコードを変更する必要はありません。

多言語データを均等に分散した場合

多言語データが既存のスキーマ表に均等に分散されていて、多言語データが格納されている表が確認できない場合には、Unicodeデータベースを使用する必要があります。これは、このUnicodeデータベースでは、各列に格納されているデータの種類を識別する必要がないためです。

SQL文とPL/SQLコードにUnicodeデータが含まれている場合

Unicodeデータベースを使用する必要があります。SQL文とPL/SQLコードは、処理前にデータベース・キャラクタ・セットに変換されます。SQL文とPL/SQLコードにデータベース・キャラクタ・セットに変換できない文字が含まれている場合、その文字は失われます。SQL文でUnicodeデータを使用する一般的な場所は、文字列リテラルにあります。

多言語ドキュメントをBLOB形式で格納し、Oracle Textを内容検索に使用する場合

Unicodeデータベースを使用する必要があります。BLOBデータは、Oracle Textによる索引付けが行われる前に、データベース・キャラクタ・セットに変換されます。データベース・キャラクタ・セットがUTF8でない場合は、ドキュメントにデータベース・キャラクタ・セットに変換できない文字が含まれていると、データが失われます。

Unicodeデータ型の使用が必要な状況

表6-3に、Unicodeデータ型を使用する状況を示します。

表6-3 Unicodeデータ型の使用

状況

説明

多言語サポートを段階的に追加する場合

キャラクタ・セットを移行せずに、Unicodeサポートを既存のデータベースに追加する場合は、Unicodeデータの格納にUnicodeデータ型を使用することを考慮してください。SQL NCHARデータ型の列を既存の表または新しい表に追加すると、複数言語を段階的にサポートできます。

パッケージ・アプリケーションを作成する場合

顧客に販売するパッケージ・アプリケーションを作成している場合は、SQL NCHARデータ型を使用してアプリケーションを作成できます。SQL NCHARデータ型は信頼性のあるUnicodeデータ型であり、データは常にUnicodeで格納され、データ長は常にUTF-16コードの単位で指定されています。その結果、アプリケーションのテストは1回のみですみます。アプリケーションは、任意のデータベース・キャラクタ・セットを持つ顧客のデータベースで稼働します。

シングルバイトのデータベース・キャラクタ・セットを使用してパフォーマンスを改善する場合

パフォーマンスの向上が主な優先事項である場合は、シングルバイトのデータベース・キャラクタ・セットを使用して、UnicodeデータをSQL NCHARデータ型で格納することを考慮してください。

WindowsクライアントでUTF-16のサポートが必要な場合

アプリケーションが、Windows上で稼働するVisual C/C++やVisual Basicで作成されている場合は、SQL NCHARデータ型を使用できます。SQL NCHARデータ型のUTF-16データは、Visual C/C++のwchar_tバッファおよびVisual Basicのstringバッファに格納する方法と同じ方法で格納できます。クライアント・アプリケーションでのバッファのオーバーフローを回避できます。これは、wchar_tデータ型とstringデータ型の長さは、データベースのSQL NCHARデータ型の長さと一致しているためです。

注意:
UnicodeデータベースとUnicodeデータ型は併用できます。

データベースおよびデータ型ソリューションに関するUnicodeキャラクタ・セットの比較

Oracleには、データベースにUnicode文字を格納するためのソリューションが2つ用意されています。Unicodeデータベース・ソリューションとUnicodeデータ型ソリューションです。Unicodeデータベース・ソリューション、Unicodeデータ型ソリューションまたはその組合せを選択した後は、UnicodeデータベースまたはUnicodeデータ型で使用するキャラクタ・セットを決定します。

表6-4に、Unicodeデータベース・ソリューションの様々なキャラクタ・セットのメリットとデメリットを示します。Unicodeデータベース・キャラクタ・セットを使用できるOracleキャラクタ・セットは、AL32UTF8、UTF8およびUTFEです。

表6-4 Unicodeデータベース・ソリューション用キャラクタ・セットのメリットとデメリット

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

メリット

デメリット

AL32UTF8

- 補助文字は4バイトで格納されるため、クライアント設定がUTF-8の場合は、補助文字の取得時と挿入時にデータ変換は行われません。

- AL32UTF8では、補助文字の格納に必要なディスク領域がUTF8の場合に比較して少なくなります。

- SQL CHAR型の長さは、補助文字のUCS-2コード・ポイント数で指定できません。補助文字は、この規格の2コード・ポイントではなく、1コード・ポイントとして処理されます。

- データが補助文字で構成されている場合、SQL CHAR列のバイナリ順序は、SQL NCHAR列のバイナリ順序と同じではありません。その結果、CHAR列とNCHAR列では、同じ文字列に対して常に同じようにソートされるとはかぎりません。

UTF8

- SQL CHAR型の長さは、UCS-2コード・ポイント数で指定できます。

- データが同じ補助文字で構成されている場合、SQL CHAR列のバイナリ順序は、SQL NCHAR列のバイナリ順序と常に同じです。その結果、CHAR列とNCHAR列には、同じ文字列に対して同じソートがあります。

- 補助文字は、Unicode 4.0で定義された4バイトではなく、6バイトとして格納されます。その結果、クライアント設定がUTF-8の場合は、補助文字のデータ変換が必要になります。

UTFE

- これは、EBCDICプラットフォーム用の唯一のUnicodeキャラクタ・セットです。

- SQL CHAR型の長さは、UCS-2コード・ポイント数で指定できます。

- データが同じ補助文字で構成されている場合、SQL CHAR列のバイナリ順序は、SQL NCHAR列のバイナリ順序と常に同じです。その結果、CHAR列とNCHAR列には、同じ文字列に対して同じソートがあります。

- 補助文字は、Unicode規格で定義された5バイトではなく、8バイト(2つの4バイト順序)として格納されます。その結果、この補助文字にはデータ変換が必要になります。

- UTFEは、Unicode規格の標準エンコーディングではありません。その結果、標準UTF-8エンコーディングが必要なクライアントは、データの取得時と挿入時にUTFEから標準エンコーディングへのデータ変換を実行する必要があります。

表6-5に、Unicodeデータ型ソリューションの様々なキャラクタ・セットのメリットとデメリットを示します。各国語キャラクタ・セットに使用できるOracleキャラクタ・セットは、AL16UTF16およびUTF8です。デフォルトはAL16UTF16です。

表6-5 Unicodeデータ型ソリューション用キャラクタ・セットのメリットとデメリット

各国語キャラクタ・セット

メリット

デメリット

AL16UTF16

- AL16UTF16でのアジア言語データは通常、UTF8のデータに比較して小型です。その結果、データベースに格納されている多言語データの大部分がアジア言語データである場合は、ディスク領域が節減され、ディスクのI/Oが削減されます。

- 一般的に、AL16UTF16キャラクタ・セットでエンコードされた文字列の処理は、UTF8でエンコードされた文字列より高速です。これは、Oracleでは、AL16UTF16でエンコードされた文字列のほとんどの文字が固定幅文字として処理されるためです。

- NCHAR列とNVARCHAR2列の最大長は、それぞれ1000文字と2000文字に制限されています。データは固定幅であるため、長さが保証されています。

- ヨーロッパ言語のASCIIデータでは、UTF8に比較して、AL16UTF16での格納に大きなディスク領域が必要です。データのほとんどがヨーロッパ言語の場合は、UTF8データの場合に比較してディスク領域の使用量が多くなります。

- NCHAR列とNVARCHAR2列の最大長は、それぞれ1000文字と2000文字です。これは、UTF8の場合のNCHAR(2000文字)とNVARCHAR2(4000文字)に比較して少なくなります。

UTF8

- UTF8でのヨーロッパ言語データは通常、AL16UTF16でのデータに比較して小型です。その結果、データベースに格納されている多言語データの大部分がヨーロッパ言語データである場合、ディスク領域が節減され、応答時間が短縮されます。

- NCHAR列とNVARCHAR2列の最大長は、それぞれ2000文字と4000文字です。これは、AL16UTF16の場合のNCHAR(1000文字)とNVARCHAR2(2000文字)に比較して多くなります。UTF8では、NCHAR列とNVARCHAR2列の最大長は大きくなりますが、実際の格納サイズは、それぞれ2000バイトと4000バイトというバイト制限で拘束されています。たとえば、すべての文字がシングルバイトの場合は、NVARCHAR2列には4000 UTF8文字を格納できますが、すべての文字が3バイトの場合は、格納できる文字は4000/3文字のみになります。

- アジア言語データでは、AL16UTF16に比較して、UTF8での格納に大きなディスク領域が必要になります。データの大部分がアジア言語データの場合、ディスク領域の使用は、キャラクタ・セットがAL16UTF16の場合より低効率ではありません。

- NCHARとNVARCHARに対して長さ制限の拡大を指定できますが、その制限の拡大によって指定した文字数を挿入できる保証はありません。これは、UTF8では可変幅の文字を使用できるためです。

- 通常、UTF8でエンコードされた文字列の処理は、AL16UTF16でエンコードされた文字列より低速です。これは、UTF8でエンコードされた文字列が可変幅の文字で構成されているためです。

Unicodeの事例

この項では、Unicode文字をOracle Databaseに格納する場合の代表的な使用例を説明します。

- 例6-3「Unicodeデータベースを使用したUnicodeソリューション」

- 例6-4「Unicodeデータ型を使用したUnicodeソリューション」

- 例6-5「UnicodeデータベースとUnicodeデータ型を使用したUnicodeソリューション」

例6-3 Unicodeデータベースを使用したUnicodeソリューション

Javaアプリケーションを実行しているある米国の企業では、アプリケーションの次のリリースでドイツ語とフランス語のサポートを追加しようとしています。その後、日本語のサポートを追加する予定です。この会社には、現在次のようなシステム構成があります。

- 既存のデータベースは、US7ASCIIのデータベース・キャラクタ・セットです。

- 既存のデータベースの全文字データは、ASCII文字で構成されています。

- データベースでは、PL/SQLストアド・プロシージャが使用されています。

- データベースは、およそ300 GBです。

- 夜間の停止時間は4時間です。

この場合、代表的なソリューションは、データベース・キャラクタ・セットにUTF8を選択します。その理由は、次のとおりです。

- データベースが非常に大規模で、予定されている停止時間が短いこと。Unicodeへのデータベースの移行の高速化が不可欠です。データベースがUS7ASCIIであるため、データベースのUnicodeサポートを有効化する最も簡単で迅速な方法は、CSALTER文を実行して、データベース・キャラクタ・セットをUTF8に切り替えることです。US7ASCIIは、UTF-8のサブセットであるため、データ変換は不要です。

- コードの大部分がJavaとPL/SQLで記述されているため、データベース・キャラクタ・セットのUTF8への変更によって、既存のコードが無駄になることはないこと。Unicodeサポートはアプリケーションで自動的に有効化されます。

- アプリケーションがフランス語、ドイツ語および日本語をサポートするため、補助文字はほとんどないこと。AL32UTF8とUTF8の両方が適しています。

例6-4 Unicodeデータ型を使用したUnicodeソリューション

主としてWindowsプラットフォームでアプリケーションを実行しているあるヨーロッパの企業では、Visual C/C++で作成された新しいWindowsアプリケーションを追加する必要があります。このアプリケーションでは、日本語と中国語の顧客名をサポートするために、既存のデータベースが使用されます。この会社には、現在次のようなシステム構成があります。

- 既存のデータベースには、WE8ISO8859P1のデータベース・キャラクタ・セットがあります。

- 既存のデータベースの全文字データは、西ヨーロッパの文字で構成されています。

- データベースは、およそ50 GBです。

代表的なソリューションでは、次のアクションが実行されます。

- NCHARおよびNVARCHAR2データ型を使用してUnicode文字が格納されます。

- WE8ISO8859P1がデータベース・キャラクタ・セットとして維持されます。

- AL16UTF16が各国語キャラクタ・セットとして使用されます。

このソリューションを選択する理由は、次のとおりです。

- データベース・キャラクタ・セットのWE8ISO8859P1(Latin-1キャラクタ・セット)はUTF8のサブセットでないため、既存のデータベースをUnicodeデータベースに移行するには、データ変換が必要になること。その結果、データをUTF8に変換するときにオーバーヘッドが発生します。

- 追加した言語は、新しいアプリケーションでのみサポートされること。既存のアプリケーションまたはスキーマに依存しません。Unicodeデータ型は新しいスキーマで使用し、既存のスキーマは変更しないままのほうが簡単です。

- Unicodeのサポートが必要なのは、顧客名の列のみであること。1つのNCHAR列のみを使用することで、データベース全体を移行せずに顧客の要件を満たすことができます。

- サポート対象言語がほとんどアジア言語であるため、AL16UTF16を各国語キャラクタ・セットとして使用する必要があり、結果として、ディスク領域をより効率的に使用できること。

- SQL NCHARデータ型の長さは文字数として定義されること。この処理方法は、Windows C/C++プログラムでwchar_t文字列を使用する場合と同じです。この方法は、プログラミングの複雑さを軽減します。

- 既存のスキーマを使用している既存のアプリケーションに対する影響はないこと。

例6-5 UnicodeデータベースとUnicodeデータ型を使用したUnicodeソリューション

ある日本の企業では、新しいJavaアプリケーションを開発する必要があります。会社では、このアプリケーションによって、できるだけ多数の言語を長期にわたってサポートする予定です。

- そこで、ドキュメントを現状のまま格納するために、BLOBデータ型を使用して複数言語のドキュメントを格納することに決定しました。

- また、B2Bでのデータ交換のためにリレーショナル・データからUTF-8 XMLドキュメントを生成する必要もあります。

- バックエンドには、C/C++で作成したWindowsアプリケーションがあり、OracleデータベースにアクセスするためにODBCを使用しています。

この場合、代表的なソリューションは、データベース・キャラクタ・セットにAL32UTF8を使用してUnicodeデータベースを作成し、SQL NCHARデータ型を使用して多言語データを格納します。各国語キャラクタ・セットは、AL16UTF16に設定する必要があります。このソリューションを選択する理由は、次のとおりです。

- 異なる言語のドキュメントがBLOB形式で格納されている場合、Oracle Textでは、データベース・キャラクタ・セットがUTF-8キャラクタ・セットの1つである必要があること。アプリケーションでは、リレーショナル・データをUTF-8 XMLフォーマットとして取得する可能性があるため(補助文字が4バイトで格納されている場合)、AL32UTF8をデータベース・キャラクタ・セットとして使用し、UTF-8データの取得時または挿入時のデータ変換を回避する必要があります。

- アプリケーションが新規で、JavaとWindows C/C++の両方で作成されているため、この会社ではリレーショナル・データに対してSQL NCHARデータ型を使用する必要があること。JavaとWindowsの両方がUTF-16文字のデータ型をサポートしていて、文字列の長さは常に文字数で測定されます。

- データの大部分がアジア言語の場合は、AL16UTF16をSQL NCHARデータ型と併用する必要があること。これは、AL16UTF16によって、格納の効率が向上するためです。

複数言語サポートのためのデータベース・スキーマ設計

複数言語をサポートするようにデータベース・スキーマを設計する場合は、Unicodeソリューションの選択に加えて、次の問題も考慮する必要があります。

- 多言語データに使用する列の長さの指定

- 複数言語のデータの格納

- LOBデータ型への複数言語によるドキュメントの格納

- 多言語ドキュメントの内容検索に使用する索引の作成

多言語データに使用する列の長さの指定

多言語データの格納にNCHARおよびNVARCHAR2データ型を使用する場合、列に指定するサイズは文字数で定義します。(文字数はUnicodeのコード数を意味します。)表6-6に、AL16UTF16およびUTF8の各国語キャラクタ・セットに対するNCHARおよびNVARCHAR2データ型の最大サイズを示します。

表6-6 データ型の最大サイズ

各国語キャラクタ・セット

NCHARデータ型の最大列サイズ

NVARCHAR2データ型の最大列サイズ

AL16UTF16

1000文字

2000文字

UTF8

2000バイト

4000バイト

多言語データの格納にCHARおよびVARCHAR2のデータ型を使用する場合、各列に指定する最大長は、デフォルトではバイト数で指定します。データベースで、タイ語、アラビア語、あるいは中国語や日本語などのマルチバイトの言語をサポートする必要がある場合は、CHAR、VARCHARおよびVARCHAR2の各列の最大サイズを拡張する必要があります。これは、これらの言語をUTF8またはAL32UTF8でエンコードするためのバイト数が、英語や西ヨーロッパの言語に比較してかなり多いためです。たとえば、タイ語キャラクタ・セットの1つのタイ文字は、UTF8またはAL32UTF8で3バイト必要です。さらに、CHAR、VARCHARおよびVARCHAR2の各データ型の最大列長は、それぞれ2000バイト、4000バイトおよび4000バイトとなります。アプリケーションで4000バイトを超えるバイト数を格納する必要がある場合は、そのデータに対してCLOBデータ型を使用する必要があります。

複数言語のデータの格納

Unicodeキャラクタ・セットには、世界中で使用されているほとんどの記述言語の文字が含まれます。ただし、特定の文字が所属している言語に関する情報は含まれません。たとえば、äという文字には、それがフランス語の文字なのかドイツ語の文字なのかに関する情報は含まれません。情報をユーザーが望む言語で表示するには、Unicodeデータベースに格納されているデータに、そのデータが所属している言語の情報を含める必要があります。

データベース・スキーマがデータを言語に関連付ける方法は多数あります。次の各項では、様々なアプローチについて説明します。

- 言語情報をデータとともに格納

- ファイングレイン・アクセス・コントロールを使用した変換済データの選択

言語情報をデータとともに格納

製品説明や製品名などのデータの場合は、CHARまたはVARCHAR2のデータ型の言語列(language_id)を製品表に追加して、対応する製品情報の言語を識別できます。これによって、アプリケーションは、必要な言語による情報を取り出すことができます。この言語列に可能な値は、データベースの有効なNLS_LANGUAGE値の3文字の略称です。

関連項目:
NLS_LANGUAGE値とその略称のリストは、付録A「ロケール・データ」を参照してください。

ビューを作成して、現在の言語のデータを選択することもできます。次に例を示します。

ALTER TABLE scott.product_information ADD (language_id VARCHAR2(50)):

CREATE OR REPLACE VIEW product AS
SELECT product_id, product_name
FROM   product_information
WHERE  language_id = SYS_CONTEXT('USERENV','LANG');

ファイングレイン・アクセス・コントロールを使用した変換済データの選択

ファイングレイン・アクセス・コントロールを使用すると、表またはビューでユーザーが参照できる情報の程度を制限できます。これは一般に、WHERE句を追加して行います。WHERE句をファイングレイン・アクセス・ポリシーとして表またはビューに追加すると、表にあるすべてのSQL文にそのWHERE句が実行時に自動的に追加されます。その結果、WHERE句を満たす行のみがアクセス可能になります。

この機能を使用すると、アプリケーションのSELECT文ごとに、ユーザーの必要な言語をWHERE句で指定しなくてすみます。次のWHERE句は、表のビューをユーザーが必要な言語に対応している行に制限しています。

WHERE language_id = SYS_CONTEXT('userenv', 'LANG')

このWHERE句をファイングレイン・アクセス・ポリシーとしてproduct_informationに対して次のように指定します。

CREATE FUNCTION func1 (sch VARCHAR2 , obj VARCHAR2 )
RETURN VARCHAR2(100);
BEGIN
RETURN 'language_id = SYS_CONTEXT(''userenv'', ''LANG'')';
END
/

DBMS_RLS.ADD_POLICY ('scott', 'product_information', 'lang_policy', 'scott', 'func1', 'select');

その結果、product_information表にあるすべてのSELECT文は自動的にWHERE句を追加します。

関連項目:
ファイングレイン・アクセス・コントロールの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

LOBデータ型への複数言語によるドキュメントの格納

複数言語によるドキュメントをCLOB、NCLOBまたはBLOBデータ型に格納してOracle Textを設定すると、そのドキュメントの内容検索を使用できます。

データベース・キャラクタ・セットがUTF8やAL32UTF8などのマルチバイトである場合、CLOB列のデータはUCS-2互換形式で格納されます。つまり、データの変換時には、英語のドキュメントに必要な記憶領域は2倍になります。アジア言語のドキュメントをCLOB列に格納する場合は、同じドキュメントをUTF8を使用してLONG列に格納する場合に比較して、必要な記憶領域が少なくなります。ドキュメントの内容にもよりますが、通常およそ30%少なくなります。

NCLOB形式のドキュメントも、データベース・キャラクタ・セットや各国語キャラクタ・セットに関係なく、UCS-2互換の独自形式で格納されます。記憶領域の必要量は、CLOBデータの場合と同じです。ドキュメントの内容は、NCLOB列への挿入時に、UTF-16に変換されます。非Unicodeデータベースに多言語ドキュメントを格納する場合は、NCLOBを選択してください。ただし、NCLOB上での内容検索は、現段階ではサポートされていません。

BLOB書式のドキュメントは、そのまま格納されます。挿入時および取得時にデータ変換は発生しません。ただし、SQL文字列操作関数(LENGTHやSUBSTRなど)と照合関数(NLS_SORTやORDER BYなど)は、BLOBデータ型に適用できません。

表6-7に、ドキュメント格納時のCLOB、NCLOBおよびBLOBデータ型のメリットとデメリットを示します。

表6-7 ドキュメント格納に関するLOBデータ型の比較

データ型

メリット

デメリット

CLOB

- 内容検索がサポートされています。

- 文字列操作がサポートされています。

- データベース・キャラクタ・セットに依存します。

- 挿入時にデータ変換が必要です。

- バイナリ・ドキュメントは格納できません。

NCLOB

- データベース・キャラクタ・セットに依存していません。

- 文字列操作がサポートされています。

- 内容検索がサポートされていません。

- 挿入時にデータ変換が必要です。

- バイナリ・ドキュメントは格納できません。

BLOB

- データベース・キャラクタ・セットに依存していません。

- 内容検索がサポートされています。

- データ変換がなく、データをそのまま格納できます。

- Microsoft WordやMicrosoft Excelなどのバイナリ・ドキュメントを格納できます。

- 文字列操作がサポートされていません。

多言語ドキュメントの内容検索に使用する索引の作成

Oracle Textでは、索引を作成して、CLOB形式およびBLOB形式で格納されている多言語ドキュメントの内容を検索できます。言語固有のレクサーを使用して、CLOBやBLOBのデータを解析し、検索可能なキーワードのリストを生成します。

多言語ドキュメントを検索するには、マルチレクサーを作成します。マルチレクサーは、言語列に基づいて、行ごとに言語固有のレクサーを選択します。この項では、複数言語のドキュメントに対して索引を作成するための高度な手順を説明します。内容は次のとおりです。

- マルチレクサーの作成

- CLOBデータ型で格納されたドキュメントに対する索引の作成

- BLOBデータ型で格納されたドキュメントに対する索引の作成

関連項目:
『Oracle Textリファレンス』

マルチレクサーの作成

マルチレクサーを作成する最初の手順は、サポート対象言語ごとに言語固有のレクサー・プリファレンスを作成することです。次の例では、英語、ドイツ語および日本語のレクサーをPL/SQLプロシージャで作成しています。

ctx_ddl.create_preference('english_lexer', 'basic_lexer');
ctx_ddl.set_attribute('english_lexer','index_themes','yes');
ctx_ddl.create_preference('german_lexer', 'basic_lexer');
ctx_ddl.set_attribute('german_lexer','composite','german');
ctx_ddl.set_attribute('german_lexer','alternate_spelling','german');
ctx_ddl.set_attribute('german_lexer','mixed_case','yes');
ctx_ddl.create_preference('japanese_lexer', 'JAPANESE_VGRAM_LEXER');

作成された言語固有のレクサー・プリファレンスは、単一のマルチレクサー・プリファレンスの下に集める必要があります。最初に、MULTI_LEXERオブジェクトを使用して、次のようにマルチレクサー・プリファレンスを作成します。

ctx_ddl.create_preference('global_lexer','multi_lexer');

ここで、add_sub_lexerコールを使用して、言語固有のレクサーをマルチレクサー・プリファレンスに追加します。

ctx_ddl.add_sub_lexer('global_lexer', 'german', 'german_lexer');
ctx_ddl.add_sub_lexer('global_lexer', 'japanese', 'japanese_lexer');
ctx_ddl.add_sub_lexer('global_lexer', 'default','english_lexer');

これによって、german_lexerプリファレンスはドイツ語ドキュメントを処理し、japanese_lexerプリファレンスは日本語ドキュメントを処理し、english_lexerプリファレンスは、言語にDEFAULTを使用して、それ以外のすべてのドキュメントを処理するように指名されます。

CLOBデータ型で格納されたドキュメントに対する索引の作成

マルチレクサーによって、表の言語列に基づいて、行ごとに使用するレクサーが決定されます。これは、テキスト列内のドキュメントの言語が格納されているキャラクタ列です。Oracleの言語名を使用して、この列にあるドキュメントの言語を識別します。たとえば、CLOBデータ型を使用してドキュメントを格納する場合は、言語列をそのドキュメントが格納されている表に追加します。

CREATE TABLE globaldoc
(doc_id    NUMBER       PRIMARY KEY,
language  VARCHAR2(30),
text      CLOB);

この表に索引を作成するには、次のようにマルチレクサー・プリファレンスを使用して言語列名を指定します。

CREATE INDEX globalx ON globaldoc(text)
indextype IS ctxsys.context
parameters ('lexer
global_lexer
language
column
language');

BLOBデータ型で格納されたドキュメントに対する索引の作成

言語列の他に、キャラクタ・セットと書式列を、ドキュメントが格納されている表に追加する必要があります。キャラクタ・セット列には、Oracleキャラクタ・セット名を使用してドキュメントのキャラクタ・セットを格納します。書式列には、ドキュメントがテキスト・ドキュメントであるかバイナリ・ドキュメントであるかを指定します。たとえば、CREATE TABLE文では、次のように列charactersetおよびformatを指定できます。

CREATE TABLE globaldoc (
doc_id       NUMBER       PRIMARY KEY,
language     VARCHAR2(30),
characterset VARCHAR2(30),
format       VARCHAR2(10),
text         BLOB
);

ワードプロセッシングまたはスプレッドシートのドキュメントを表に入力し、format列にbinaryを指定できます。HTML、XMLおよびテキスト・フォーマットのドキュメントの場合は、表にドキュメントを入力して、format列にtextを指定します。

キャラクタ・セットを指定する列があるため、様々なキャラクタ・セットによるテキスト・ドキュメントを格納できます。

索引の作成時に、書式列とキャラクタ・セット列の名前を指定します。

CREATE INDEX globalx ON globaldoc(text)
indextype is ctxsys.context
parameters ('filter inso_filter
lexer global_lexer
language column language
format  column format
charset column characterset');

全ドキュメントがテキスト・フォーマットの場合は、charset_filterを使用できます。このcharset_filterによって、データはcharset列で指定されたキャラクタ・セットからデータベース・キャラクタ・セットに変換されます。

7 Unicodeを使用したプログラミング

この章では、Oracleのデータベースのプログラミングおよびアクセス製品とUnicodeを併用する方法について説明します。この章の内容は、次のとおりです。

- Unicodeを使用したプログラミングの概要

- Unicodeを使用したSQLとPL/SQLのプログラミング

- Unicodeを使用したOCIプログラミング

- Unicodeを使用したPro*C/C++プログラミング

- Unicodeを使用したJDBCプログラミング

- Unicodeを使用したODBCとOLE DBのプログラミング

- Unicodeを使用したXMLプログラミング

Unicodeを使用したプログラミングの概要

Oracleには、Unicodeデータの挿入と取出しを行うためのデータベース・アクセス製品がいくつか用意されています。Oracleでは、JavaやC/C++などの一般的に使用されているプログラミング環境に対応したデータベース・アクセス製品を提供しています。データはデータベースとクライアント・プログラム間で透過的に変換されるため、クライアント・プログラムがデータベース・キャラクタ・セットと各国語キャラクタ・セットの影響を受けないことが保証されます。さらに、クライアント・プログラムは、データベースで使用されるNCHARやCHARなどの文字データ型の影響も受けない場合があります。

データ変換操作によってデータベース・サーバーに負荷をかけないように、Oracleは常に、これらの操作をクライアント側のデータベース・アクセス製品に移動しようとします。データベースでデータ変換が必要な場合があり、この操作はパフォーマンスに影響します。この章では、データ変換の流れの詳細を説明します。

データベース・アクセス製品のスタックおよびUnicode

Oracleは総合的なデータベース・アクセス製品を提供しています。これらの製品によって、データベースに格納されているUnicodeデータに異なる開発環境のプログラムでアクセスできます。表7-1に、これらの製品を示します。

表7-1 Oracleのデータベース・アクセス製品

プログラミング環境

Oracleのデータベース・アクセス製品

C/C++

Oracle Call Interface (OCI)、Oracle Pro*C/C++、Oracle ODBCドライバ、Oracle Provider for OLE DB、Oracle Data Provider for .NET

Java

Oracle JDBC OCIまたはThinドライバ、Oracleサーバー側Thinドライバ、Oracleサーバー側内部ドライバ

PL/SQL

Oracle PL/SQLおよびSQL

Visual Basic/C#

Oracle ODBCドライバ、Oracle Provider for OLE DB

図7-1は、データベース・アクセス製品によるデータベースへのアクセス方法を示しています。

図7-1 Oracleのデータベース・アクセス製品

Oracle Call Interface(OCI)は、残りのクライアント側データベース・アクセス製品で使用される最下位レベルのAPIです。SQL CHARデータ型およびNCHARデータ型で格納されているUnicodeデータにC/C++プログラムでアクセスするための、柔軟な方法を提供します。OCIを使用して、データの挿入または取出しに使用するキャラクタ・セット(UTF-8やUTF-16など)をプログラムで指定できます。データベースには、Oracle Netを介してアクセスします。

Oracle Pro*C/C++を使用すると、プログラム内にSQLおよびPL/SQLを埋め込むことができます。OCIのUnicode機能を使用して、SQL CHARデータ型およびNCHARデータ型のUTF-16およびUTF-8データへのアクセスを提供します。

Oracle ODBCドライバを使用すると、Windowsプラットフォームで実行されているC/C++、Visual BasicおよびVBScriptプログラムで、データベースにSQL CHARデータ型およびNCHARデータ型で格納されているUnicodeデータにアクセスできます。ODBC標準仕様で指定されているSQLWCHARインタフェースを実装することで、UTF-16データへのアクセスを提供します。

Oracle Provider for OLE DBを使用すると、Windowsプラットフォームで実行されているC/C++、Visual BasicおよびVBScriptプログラムで、SQL CHARデータ型およびNCHARデータ型で格納されているUnicodeデータにアクセスできます。ワイド文字列のOLE DBデータ型を介してUTF-16データへのアクセスを提供します。

Oracle Data Provider for .NETを使用すると、Windowsプラットフォーム上の任意の.NETプログラミング環境で実行されているプログラムで、SQL CHARデータ型およびNCHARデータ型で格納されているUnicodeデータにアクセスできます。Unicodeのデータ型を介してUTF-16データへのアクセスを提供します。

Oracle JDBCドライバは、Oracle Databaseにアクセスするための主要なJavaプログラム・インタフェースです。Oracleには次のJDBCドライバが用意されています。

- Javaアプリケーションで使用され、OCIライブラリを必要とするJDBC OCIドライバ

- 純粋なJavaドライバで、Javaアプレットで主に使用され、TCP/IPを介したOracle NetプロトコルをサポートするJDBC Thinドライバ

- 純粋なJavaドライバで、Javaストアド・プロシージャ内で他のOracleサーバーへの接続に使用されるサーバー側JDBC Thinドライバ

- Oracleサーバー内部でデータベース内のデータへのアクセスに使用されるサーバー側JDBC内部ドライバ

ドライバはすべて、データベースに格納されているSQL CHARデータ型およびNCHARデータ型へのUnicodeデータ・アクセスをサポートします。

PL/SQLとSQLのエンジンは、OCIなどのクライアント側プログラムやサーバー側のPL/SQLストアド・プロシージャのかわりに、PL/SQLプログラムとSQL文を処理します。これらのエンジンを使用すると、PL/SQLプログラムでCHAR、VARCHAR2、NCHARおよびNVARCHAR2の各変数を宣言し、データベースのSQL CHARおよびNCHARデータ型にアクセスできます。

次の項では、各データベース・アクセス製品が、Oracle DatabaseへのUnicodeデータ・アクセスをどのようにサポートしているかを説明し、これらの製品の使用例を示します。

- Unicodeを使用したSQLとPL/SQLのプログラミング

- Unicodeを使用したOCIプログラミング

- Unicodeを使用したPro*C/C++プログラミング

- Unicodeを使用したJDBCプログラミング

- Unicodeを使用したODBCとOLE DBのプログラミング

Unicodeを使用したSQLとPL/SQLのプログラミング

SQLは、すべてのプログラムとユーザーが、Oracle Databaseのデータに直接的または間接的にアクセスするときに使用する基本言語です。PL/SQLは、SQLのデータ操作能力と手続き型言語のデータ処理能力を結合した手続き型言語です。SQLとPL/SQLは両方とも、他のプログラム言語に埋め込むことができます。この項では、多言語アプリケーションにデプロイ可能なSQLとPL/SQLのUnicode関連機能について説明します。

この項の内容は、次のとおりです。

- SQL NCHARデータ型

- NCHARデータ型と他のデータ型の間の暗黙的な変換

- データ型変換中のデータ消失に対する例外処理

- 暗黙的なデータ型変換の規則

- Unicodeデータ型のSQL関数

- その他のSQL関数

- Unicode文字列リテラル

- NCHARデータを使用したUTL_FILEパッケージの使用

関連項目:

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Database PL/SQL言語リファレンス』

SQL NCHARデータ型

SQL NCHARデータ型は次の3つです。

- NCHARデータ型

- NVARCHAR2データ型

- NCLOBデータ型

NCHARデータ型

表の列またはPL/SQL変数をNCHARデータ型として定義する場合、長さは常に文字数として指定します。たとえば次の文では、最大文字長が30の列が1つ作成されます。

CREATE TABLE table1 (column1 NCHAR(30));

この列の最大バイト数は、次のように決定されます。

maximum number of bytes = (maximum number of characters) x (maximum number of bytes for each character)

たとえば、各国語キャラクタ・セットがUTF8の場合、最大バイト長は30文字に1文字当たり3バイトを乗算した値、つまり90バイトとなります。

すべてのNCHARデータ型に使用する各国語キャラクタ・セットは、データベースの作成時に定義します。各国語キャラクタ・セットはUTF8またはAL16UTF16のいずれかです。デフォルトはAL16UTF16です。

使用可能な最大列サイズは、各国語キャラクタ・セットがUTF8の場合は2000文字、AL16UTF16の場合は1000文字です。実際のデータが最大バイト制限の2000の対象となります。2つのサイズ制限は同時に満たす必要があります。PL/SQLでは、NCHARデータの最大長は32767バイトです。NCHAR変数は32767文字まで定義できますが、実際のデータは32767バイトを超えることはできません。列の長さより短い値を挿入すると、最大文字長と最大バイト長のいずれか小さいほうの値まで空白で埋められます。

注意:
UTF8は可変幅キャラクタ・セットであるため、パフォーマンスに影響する場合があります。NCHARフィールドの空白埋めが過剰に行われると、パフォーマンスが低下します。NVARCHARデータ型を使用するか、NCHARデータ型のキャラクタ・セットをAL16UTF16に変更することを考慮してください。

NVARCHAR2データ型

NVARCHAR2データ型は、各国語キャラクタ・セットを使用する可変長文字列を指定します。NVARCHAR2列を使用して表を作成するときは、列の最大文字数を指定します。NVARCHAR2の長さは、NCHARの場合と同様に常に文字単位です。続いて、値が列の最大長を超えないかぎり、ユーザーが指定したとおりに各値が列内に格納されます。文字列の値が最大長まで埋め込まれることはありません。

使用可能な最大列サイズは、各国語キャラクタ・セットがUTF8の場合は4000文字、AL16UTF16の場合は2000文字です。バイト単位では、NVARCHAR2列の最大長は4000バイトです。バイト数の上限と文字数の上限の両方を満たす必要があるため、実際にNVARCHAR2列に使用できる最大文字数は、4000バイトに書込み可能な文字数となります。

PL/SQLでは、NVARCHAR2変数の最大長は32767バイトです。NVARCHAR2変数は32767文字まで定義できますが、実際のデータは32767バイトを超えることはできません。

次の文では、最大文字長が2000で最大バイト長が4000のNVARCHAR2列を1つ含む表が作成されます。

CREATE TABLE table2 (column2 NVARCHAR2(2000));

NCLOBデータ型

NCLOBは、最大4GBのUnicode文字を格納する、キャラクタ・ラージ・オブジェクトです。BLOBデータ型とは異なり、NCLOBデータ型では完全なトランザクション・サポートがあるため、SQL、DBMS_LOBパッケージまたはOCIを使用して行われた変更は、完全にトランザクションに組み込まれます。NCLOB値の操作は、コミットおよびロールバックできます。ただし、あるトランザクションでPL/SQLまたはOCI変数に保存したNCLOBロケータを別のトランザクションまたはセッションで使用することはできません。

NCLOB値は、各国語キャラクタ・セットに関係なく、UCS-2互換形式でデータベースに格納されます。格納されたUnicode値は、クライアントまたはサーバーで要求された固定幅または可変幅のキャラクタ・セットに変換されます。可変幅のキャラクタ・セットを使用してNCLOB列に挿入したデータは、データベースに格納される前にUCS-2互換形式に変換されます。

関連項目:
NCLOBデータ型の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

NCHARデータ型と他のデータ型の間の暗黙的な変換

Oracleでは、SQL NCHARデータ型と、他のOracleデータ型(CHAR、VARCHAR2、NUMBER、DATE、ROWIDおよびCLOBなど)の間の暗黙的な変換がサポートされています。SQL NCHARデータ型については、CHARおよびVARCHAR2データ型に関する暗黙的な変換もサポートされています。SQL NCHARデータ型は、SQL CHARデータ型と同様に使用できます。

SQL CHARデータ型とSQL NCHARデータ型の間の型変換では、データベース・キャラクタ・セットと各国語キャラクタ・セットが異なるときに、キャラクタ・セットの変換が行われる場合があります。ターゲット・データがCHARまたはNCHARの場合は、空白埋めが発生することがあります。

関連項目:
『Oracle Database SQL言語リファレンス』

データ型変換中のデータ消失に対する例外処理

キャラクタ・セット変換が必要なときは、データ型変換時にデータを消失する可能性があります。ソース・キャラクタ・セット内の文字がターゲットのキャラクタ・セット内で定義されていない場合、その場所には置換文字が使用されます。たとえば、NCHARデータを通常のCHAR列に挿入しようとしたときに、NCHAR(Unicode)フォーム内の文字データがデータベース・キャラクタ・セットに変換できない場合、その文字はデータベース・キャラクタ・セットで定義されている置換文字に置き換えられます。文字列型変換時のデータ消失に関する対処方法は、NLS_NCHAR_CONV_EXCP初期化パラメータによって制御されます。このパラメータがTRUEに設定されているときは、データ消失が発生するSQL文はORA-12713エラーを戻し、対応する操作は停止します。このパラメータがFALSEに設定されているときは、データ消失はレポートされず、変換不可能な文字は置換文字で置き換えられます。デフォルト値はFALSEです。このパラメータは、暗黙的な変換と明示的な変換の両方に対して機能します。

PL/SQLの場合は、SQL CHARデータ型とNCHARデータ型の変換時にデータ消失が発生すると、暗黙的な変換の場合も明示的な変換の場合もLOSSY_CHARSET_CONVERSION例外が発生します。

暗黙的なデータ型変換の規則

状況によって、一方向のデータ型変換のみが可能な場合と、両方向のデータ型変換が可能な場合があります。Oracleでは、データ型間の変換に関して一連の規則が定義されています。表7-2に、データ型間の変換に関する規則を示します。

表7-2 データ型間の変換に関する規則

文

規則

INSERT/UPDATE文

値は、ターゲット・データベース列のデータ型に変換されます。

SELECT INTO文

データベースのデータは、ターゲット変数のデータ型に変換されます。

変数の代入

等号の右辺の値は、等号の左辺のターゲット変数のデータ型に変換されます。

SQL関数とPL/SQL関数のパラメータ

CHAR、VARCHAR2、NCHARおよびNVARCHAR2は同じ方法でロードされます。CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型の引数は、CHAR、VARCHAR2、NCHARまたはNVARCHAR2データ型のいずれかの仮パラメータと比較されます。引数と仮パラメータのデータ型が正確に一致していない場合は、データが関数の入口でパラメータにコピーされるとき、および関数の出口で引数にコピーアウトされるときに、暗黙的な変換が行われます。

連結(||)操作またはCONCAT関数

あるオペランドがSQL CHARデータ型またはNCHARデータ型で、他のオペランドがNUMBERまたはその他の非文字データ型の場合、他のデータ型はVARCHAR2またはNVARCHAR2に変換されます。文字データ型間の連結については、「SQL NCHARデータ型とSQL CHARデータ型」を参照してください。

SQL CHARまたはNCHARデータ型とNUMBERデータ型

文字の値はNUMBERデータ型に変換されます。

SQL CHARまたはNCHARデータ型とDATEデータ型

文字の値はDATEデータ型に変換されます。

SQL CHARまたはNCHARデータ型とROWIDデータ型

文字の値はROWIDデータ型に変換されます。

SQL NCHARデータ型とSQL CHARデータ型

SQL NCHARデータ型とSQL CHARデータ型との比較はさらに複雑です。これは、これらのデータ型が異なるキャラクタ・セットでエンコードされている場合があるためです。

CHAR値とVARCHAR2値が比較される場合は、CHAR値がVARCHAR2値に変換されます。

NCHAR値とNVARCHAR2値が比較される場合は、NCHAR値がNVARCHAR2値に変換されます。

SQL NCHARデータ型とSQL CHARデータ型との間で比較が行われるとき、これらのデータ型が異なるキャラクタ・セットでエンコードされている場合は、キャラクタ・セット変換が行われます。SQL NCHARデータ型のキャラクタ・セットは常にUnicodeで、UTF8エンコーディングまたはAL16UTF16エンコーディングのいずれかです。これらの文字レパートリは同じですが、Unicode規格では異なるエンコーディングです。SQL CHARデータ型は、データベース・キャラクタ・セットを使用します。このデータベース・キャラクタ・セットは、Oracleがサポートするいずれかのキャラクタ・セットです。UnicodeはOracleでサポートされているキャラクタ・セットのスーパーセットであるため、SQL CHARデータ型からSQL NCHARデータ型への変換は、いつでもデータ消失なしに行うことができます。

Unicodeデータ型のSQL関数

SQL NCHARデータ型は、明示的な変換関数を使用して、SQL CHARデータ型や他のデータ型と相互に変換できます。この項の例では、次の文で作成された表を使用します。

CREATE TABLE customers
(id NUMBER, name NVARCHAR2(50), address NVARCHAR2(200), birthdate DATE);

例7-1 TO_NCHAR関数を使用したcustomers表の移入

TO_NCHAR関数は実行時にデータを変換しますが、N関数はコンパイル時にデータを変換します。

INSERT INTO customers VALUES (1000,
TO_NCHAR('John Smith'),N'500 Oracle Parkway',sysdate);

例7-2 TO_CHAR関数を使用したcustomers表からの選択

次の文では、nameの値が各国語キャラクタ・セットの文字からデータベース・キャラクタ・セットの文字に変換され、その後でLIKE句に従って選択されます。

SELECT name FROM customers WHERE TO_CHAR(name) LIKE '%Sm%';

次の出力が表示されます。

NAME
--------------------------------------
John Smith

例7-3 TO_DATE関数を使用したcustomers表からの選択

N関数を使用すると、NCHARまたはCHARデータ型のデータをTO_DATE関数のパラメータとして渡すことができます。データ型変換は実行時に行われるため、データ型を混在させることができます。

DECLARE
ndatestring NVARCHAR2(20) := N'12-SEP-1975';
ndstr NVARCHAR2(50);
BEGIN
SELECT name INTO ndstr FROM customers
WHERE (birthdate)> TO_DATE(ndatestring, 'DD-MON-YYYY', N'NLS_DATE_LANGUAGE =
AMERICAN');
END;

例7-3に示したように、SQL NCHARデータ型のデータを明示的な変換関数に渡すことができます。複数の文字列パラメータを使用すると、SQL CHARおよびNCHARデータ型のデータを混在させることができます。

関連項目:
SQL NCHARデータ型の明示的な変換関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

その他のSQL関数

大部分のSQL関数は、SQL NCHARデータ型および混合した文字データ型の引数を取ることができます。戻されるデータ型は、最初の引数の型に基づきます。これらの関数に渡されたNUMBERやDATEなどの非文字列データ型は、VARCHAR2に変換されます。次の例では、「Unicodeデータ型のSQL関数」で作成したcustomers表を使用します。

例7-4 INSTR関数

この例では、文字列リテラル'Sm'がNVARCHAR2に変換されてから、INSTRによってスキャンされ、nameで最初に出現するこの文字列の位置が検出されます。

SELECT INSTR(name, N'Sm', 1, 1) FROM customers;

例7-5 CONCAT関数

SELECT CONCAT(name,id) FROM customers;

idはNVARCHAR2に変換された後、nameと連結されます。

例7-6 RPAD関数

SELECT RPAD(name,100,' ') FROM customers;

出力は次のようになります。

RPAD(NAME,100,'')
------------------------------------------
John Smith

スペース文字' 'がNCHARキャラクタ・セットの対応する文字に変換された後、表示の全長が100になるようにnameの右側に埋め込まれます。

関連項目:
『Oracle Database SQL言語リファレンス』

Unicode文字列リテラル

Unicode文字列リテラルは、次の方法でSQLおよびPL/SQLに入力できます。

- 引用符で囲まれた文字列リテラルの前に接頭辞Nを付加します。この接頭辞によって、その後に続く文字列リテラルがNCHAR文字列リテラルであることが明示的に示されます。たとえば、N'résumé'はNCHAR文字列リテラルです。このメソッドの制限事項の詳細は、「NCHAR文字列リテラルの置換」を参照してください。

- NCHR(n)SQL関数を使用します。この関数は、各国語キャラクタ・セット(AL16UTF16またはUTF8)内の文字コードの数を戻します。複数のNCHR(n)ファンクションを連結した結果は、NVARCHAR2データになります。このように、クライアントとサーバーのキャラクタ・セット変換を行わずに、NVARCHAR2文字列を直接作成できます。たとえば、NCHR(32)は空白文字を表します。
NCHR(n)は同じ各国語キャラクタ・セットに関連付けられているため、結果値の移植性はその各国語キャラクタ・セットで実行されるアプリケーションに限定されます。この移植性が重要な場合は、UNISTR関数を使用して移植性の制限を解除します。

- UNISTR('string')SQL関数を使用します。UNISTR('string')は、文字列を各国語キャラクタ・セットに変換します。移植性を確保してデータを保持するには、ASCII文字と\xxxx形式のUnicodeエンコーディングのみを含めます。xxxxは、UTF-16エンコーディング形式で文字コード値を表す16進値です。たとえば、UNISTR('G\0061ry')は'Gary'を表します。ASCII文字は、データベース・キャラクタ・セットに変換されてから、各国語キャラクタ・セットに変換されます。Unicodeエンコーディングは、各国語キャラクタ・セットに直接変換されます。

最後の2つの方法を使用すると、すべてのUnicode文字列リテラルをエンコードできます。

NCHAR文字列リテラルの置換

この項では、NCHAR文字列リテラル置換の実行時にデータの損失を防ぐ方法を説明します。

リテラルのテキストがSQLまたはPL/SQL文の一部になると、接頭辞Nの有無にかかわらず、残りの文と同じキャラクタ・セットでエンコードされます。クライアント側では、文にクライアント・キャラクタ・セットが使用されます。これは、NLS_LANGで定義されているクライアント・キャラクタ・セットにより決定されるか、OCIEnvNlsCreate()コールで指定されるか、またはJDBCでUTF-16として事前定義されます。サーバー側では、文はデータベース・キャラクタ・セットです。

- SQLまたはPL/SQL文がクライアントからデータベース・サーバーに送信されると、それに応じてキャラクタ・セットが変換されます。データベース・キャラクタ・セットに、テキスト・リテラルで使用されるキャラクタの一部が含まれない場合、変換時にデータが失われるので、注意が必要です。この問題は、CHARテキスト・リテラルよりもNCHAR文字列リテラルにより大きな影響を及ぼします。これは、N'リテラルがデータベース・キャラクタ・セットに依存しないよう設計されており、クライアント・キャラクタ・セットがサポートするデータを提供できる必要があるためです。
互換性のないデータベース・キャラクタ・セットへの変換時にデータの損失を防ぐため、NCHARリテラル置換機能をアクティブにできます。この機能では、クライアント側でN'リテラルが内部書式により透過的に置換されます。データベース・サーバーは、文の実行時にこのリテラルをUnicodeにデコードします。

- 「OCIでのSQL NCHAR文字列リテラルの処理」および「JDBCでのSQL NCHAR文字列リテラルの使用」の項では、OCIおよびJDBCのそれぞれで置換機能を有効にする方法を示しています。SQL*Plusなどの多くのアプリケーションでは、データベースへの接続にOCIを使用し、NCHARリテラル置換を明示的に制御しないため、クライアント環境変数ORA_NCHAR_LITERAL_REPLACEをTRUEに設定してこの機能を制御できます。デフォルトでは、この機能は、下位互換性を維持するために無効になっています。

NCHARデータを使用したUTL_FILEパッケージの使用

UTL_FILEパッケージは、NVARCHAR2データ型のUnicode各国語キャラクタ・セットのデータを処理します。NCHARおよびNCLOBは、暗黙的な変換でサポートされています。次の関数とプロシージャがあります。

- FOPEN_NCHAR
この関数は、最大行サイズを指定して、入力用または出力用のファイルを各国語キャラクタ・セット・モードでオープンします。NVARCHAR2バッファのコンテンツが(データベースの各国語キャラクタ・セットに応じて)AL16UTF16またはUTF8の場合でも、ファイルのコンテンツは、常に、UTF8で読取りおよび書込みされます。詳細は、「OracleデータベースによるUnicodeのサポート」を参照してください。必要に応じて、UTL_FILEはUTF8とAL16UTF16間の変換を行います。

- GET_LINE_NCHAR
このプロシージャは、ファイル・ハンドルで識別されたオープン・ファイルからテキストを読み込み、そのテキストを出力バッファ・パラメータに入れます。ファイルは、各国語キャラクタ・セット・モードでオープンし、UTF8キャラクタ・セットでエンコードする必要があります。必要なバッファ・データ型は、NVARCHAR2です。NCHAR、NCLOBまたはVARCHAR2など、その他のデータ型の変数が指定された場合、テキストの読取りの後で、PL/SQLでNVARCHAR2からの標準の暗黙的な変換が実行されます。

- PUT_NCHAR
このプロシージャは、バッファ・パラメータに格納されているテキスト文字列を、ファイル・ハンドルで識別されたオープン・ファイルに書き込みます。このファイルは、各国語キャラクタ・セットでオープンする必要があります。テキスト文字列は、UTF8キャラクタ・セットで書き込まれます。必要なバッファ・データ型は、NVARCHAR2です。その他のデータ型の変数が指定された場合、テキストの書込みの前に、PL/SQLでNVARCHAR2への暗黙的な変換が実行されます。

- PUT_LINE_NCHAR
このプロシージャは、行セパレータが書き込まれたテキストに追加される以外は、PUT_NCHARと同じです。

- PUTF_NCHAR
このプロシージャは、PUT_NCHARプロシージャの書式設定されたバージョンです。このプロシージャは、書式要素\nおよび%sを含む書式文字列を受け入れ、書式文字列内の%sの連続インスタンスを最大で5つの引数に置き換えることができます。書式文字列および引数に想定されるデータ・タイプは、NVARCHAR2です。別のデータ型の変数が指定されていると、テキストの書式設定前に、PL/SQLでNVARCHAR2への暗黙的な変換が実行されます。書式化されたテキストは、ファイル・ハンドルが示すファイルにUTF8キャラクタ・セットで書き込まれます。このファイルは、各国語キャラクタ・セットでオープンする必要があります。

前述の関数およびプロシージャでは、UTF8キャラクタ・セット、つまりUnicode CESU-8エンコーディングでエンコードされたテキスト・ファイルを処理します。CESU-8の詳細は、「ユニバーサル・キャラクタ・セット」を参照してください。関数およびプロシージャは、必要に応じてUTF8とデータベースの各国語キャラクタ・セット(UTF8またはAL16UTF16)間の変換を行います。

関連項目:
UTL_FILEパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

Unicodeを使用したOCIプログラミング

OCIはデータベースにアクセスするための最下位レベルのAPIであるため、可能な最大のパフォーマンスを提供します。OCIでUnicodeを使用するときは、次の内容を考慮してください。

- Unicodeプログラミング用のOCIEnvNlsCreate()関数

- OCI Unicodeのコード変換

- OCIでのUTF-8のNLS_LANGのキャラクタ・セットへの設定

- OCIでのSQL CHARデータ型のバインドと定義

- OCIでのSQL NCHARデータ型のバインドと定義

- OCIでのCLOB UnicodeデータおよびNCLOB Unicodeデータのバインドと定義

関連項目:
第10章「グローバル環境でのOCIプログラミング」

Unicodeプログラミング用のOCIEnvNlsCreate()関数

OCIEnvNlsCreate()関数を使用して、OCI環境の作成時にSQL CHARのキャラクタ・セットとSQL NCHARのキャラクタ・セットを指定します。これはOCIEnvCreate()関数の拡張バージョンであり、2つのキャラクタ・セットIDを指定できるように拡張された引数を取ります。OCI_UTF16ID UTF-16キャラクタ・セットIDによって、Oracle9iリリース1(9.0.1)で導入されたUnicodeモードが置き換えられています。次に例を示します。

OCIEnv *envhp;
status = OCIEnvNlsCreate((OCIEnv **)&envhp,
(ub4)0,
(void *)0,
(void *(*) ()) 0,
(void *(*) ()) 0,
(void(*) ()) 0,
(size_t) 0,
(void **)0,
(ub2)OCI_UTF16ID, /* Metadata and SQL CHAR character set */
(ub2)OCI_UTF16ID /* SQL NCHAR character set */);

Unicodeモードでは、OCIEnvCreate()関数とともにOCI_UTF16フラグが使用されますが、このモードは非推奨です。

SQL CHARのキャラクタ・セットとSQL NCHARのキャラクタ・セットの両方にOCI_UTF16IDを指定すると、すべてのメタデータのバインドされた定義済データは、UTF-16でエンコードされます。メタデータには、SQL文、ユーザー名、エラー・メッセージおよび列名が含まれます。そのため、継承される操作はいずれもNLS_LANGの設定に依存せず、すべてのメタテキスト・データ・パラメータ(text*)は、UTF-16エンコーディングではUnicodeテキスト・データ型(utext*)とみなされます。

OCI_UTF16IDキャラクタ・セットIDを使用してOCIEnv()関数を初期化するときにSQL文を準備するには、(utext*)文字列を指定してOCIStmtPrepare()関数をコールします。次の例は、Windowsプラットフォームでのみ動作します。他のプラットフォームの場合は、wchar_tデータ型を変更する必要があります。

const wchar_t sqlstr[] = L"SELECT * FROM ENAME=:ename";
...
OCIStmt* stmthp;
sts = OCIHandleAlloc(envh, (void **)&stmthp, OCI_HTYPE_STMT, 0,
NULL);
status = OCIStmtPrepare(stmthp, errhp,(const text*)sqlstr,
wcslen(sqlstr), OCI_NTV_SYNTAX, OCI_DEFAULT);

OCIEnv()関数はすでにUTF-16のキャラクタ・セットIDを使用して初期化されているため、データをバインドして定義するためにOCI_ATTR_CHARSET_ID属性を設定する必要はありません。バインド変数名もUTF-16文字列であることが必要です。

/* Inserting Unicode data */
OCIBindByName(stmthp1, &bnd1p, errhp, (const text*)L":ename",
(sb4)wcslen(L":ename"),
(void *) ename, sizeof(ename), SQLT_STR, (void
*)&insname_ind,
(ub2 *) 0, (ub2 *) 0, (ub4) 0, (ub4 *)0,
OCI_DEFAULT);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *)
&ename_col_len,
(ub4) 0, (ub4)OCI_ATTR_MAXDATA_SIZE, errhp);
...
/* Retrieving Unicode data */
OCIDefineByPos (stmthp2, &dfn1p, errhp, (ub4)1, (void *)ename,
(sb4)sizeof(ename), SQLT_STR, (void *)0, (ub2 *)0,
(ub2*)0, (ub4)OCI_DEFAULT);

この操作はOCIExecute()関数で実行されます。

関連項目:
「OCIでのキャラクタ・セットの指定」

OCI Unicodeのコード変換

クライアントとサーバーのキャラクタ・セットが異なる場合は、OCIクライアントとデータベース・サーバーの間でUnicodeキャラクタ・セット変換が行われます。この変換は、環境によってクライアントまたはサーバーのいずれの側でも行われますが、通常はクライアント側で行われます。

データ整合性

OCI APIを適切にコールしないと、変換時にデータが消失する可能性があります。サーバーとクライアントのキャラクタ・セットが異なる場合は、変換先キャラクタ・セットが変換元キャラクタ・セットより小さいセットであると、データが消失する可能性があります。両方のキャラクタ・セットがUnicodeキャラクタ・セット(UTF8やAL16UTF16など)の場合、この潜在的な問題は回避できます。

SQL NCHARデータ型をバインドまたは定義するときは、OCI_ATTR_CHARSET_FORM属性をSQLCS_NCHARに設定する必要があります。この設定を行わないと、データはデータベース・キャラクタ・セットに変換されてから、各国語キャラクタ・セットとの間で変換されるため、データが消失する可能性があります。データが消失するのは、データベース・キャラクタ・セットがUnicodeでない場合のみです。

Unicode使用時のOCIパフォーマンスに与える影響

冗長なデータ変換は、OCIアプリケーションのパフォーマンス低下の原因となる場合があります。このような冗長な変換は、次の2つの場合に発生します。

- SQL CHARデータ型をバインドまたは定義して、OCI_ATTR_CHARSET_FORM属性をSQLCS_NCHARに設定すると、クライアントのキャラクタ・セットから各国語キャラクタ・セットへのデータ変換と、各国語キャラクタ・セットからデータベース・キャラクタ・セットへのデータ変換が行われます。データ消失はないと思われますが、必要な変換が1回の場合でも変換が2回行われます。

- SQL NCHARデータ型をバインドまたは定義して、OCI_ATTR_CHARSET_FORMを設定しないと、クライアントのキャラクタ・セットからデータベース・キャラクタ・セットへの変換と、データベース・キャラクタ・セットから各国語データベース・キャラクタ・セットへのデータ変換が行われます。最悪の場合、データベース・キャラクタ・セットがクライアントのキャラクタ・セットより小さいと、データが消失する可能性があります。

パフォーマンス上の問題を回避するために、ターゲット列のデータ型に基づいてOCI_ATTR_CHARSET_FORMを常に適切に設定する必要があります。ターゲットのデータ型が不明の場合に、バインドおよび定義を行うときは、OCI_ATTR_CHARSET_FORM属性をSQLCS_NCHARに設定してください。

表7-3に、OCIのキャラクタ・セット変換を示します。

表7-3 OCIのキャラクタ・セットの変換

OCIクライアント・バッファのデータ型

OCI_ATTR_CHARSET_FORM

データベース内のターゲット列のデータ型

変換元と変換先

コメント

utext

SQLCS_IMPLICIT

CHAR、VARCHAR2、CLOB

OCIでの、UTF-16とデータベース・キャラクタ・セット

予期しないデータ消失はありません。

utext

SQLCS_NCHAR

NCHAR、NVARCHAR2、NCLOB

OCIでの、UTF-16と各国語キャラクタ・セット

予期しないデータ消失はありません。

utext

SQLCS_NCHAR

CHAR、VARCHAR2、CLOB

OCIでの、UTF-16と各国語キャラクタ・セット

データベース・サーバーでの、各国語キャラクタ・セットとデータベース・キャラクタ・セット

予期しないデータ消失はありませんが、各国語キャラクタ・セットを経由して変換が行われるため、パフォーマンスが低下する可能性があります。

utext

SQLCS_IMPLICIT

NCHAR、NVARCHAR2、NCLOB

OCIでの、UTF-16とデータベース・キャラクタ・セット

データベース・サーバーでの、データベース・キャラクタ・セットと各国語キャラクタ・セット

データベース・キャラクタ・セットがUnicodeでない場合は、データが消失する可能性があります。

text

SQLCS_IMPLICIT

CHAR、VARCHAR2、CLOB

OCIでの、NLS_LANGキャラクタ・セットとデータベース・キャラクタ・セット

予期しないデータ消失はありません。

text

SQLCS_NCHAR

NCHAR、NVARCHAR2、NCLOB

OCIでの、NLS_LANGキャラクタ・セットと各国語キャラクタ・セット

予期しないデータ消失はありません。

text

SQLCS_NCHAR

CHAR、VARCHAR2、CLOB

OCIでの、NLS_LANGキャラクタ・セットと各国語キャラクタ・セット

データベース・サーバーでの、各国語キャラクタ・セットとデータベース・キャラクタ・セット

予期しないデータ消失はありませんが、各国語キャラクタ・セットを経由して変換が行われるため、パフォーマンスが低下する可能性があります。

text

SQLCS_IMPLICIT

NCHAR、NVARCHAR2、NCLOB

OCIでの、NLS_LANGキャラクタ・セットとデータベース・キャラクタ・セット

データベース・サーバーでの、データベース・キャラクタ・セットと各国語キャラクタ・セット

データベース・キャラクタ・セットを経由して変換が行われるため、データが消失する可能性があります。

OCI Unicodeのデータ拡張

データ変換によってデータが拡張し、バッファがオーバーフローする原因となる場合があります。バインド操作では、OCI_ATTR_MAXDATA_SIZE属性をサーバー上に拡張後のデータを格納するのに十分なサイズに設定する必要があります。この設定が困難な場合は、表スキーマの変更を考慮する必要があります。定義操作では、拡張後のデータに対して十分なバッファ領域をクライアント・アプリケーションで割り当てる必要があります。バッファのサイズは、拡張後のデータの最大長に設定してください。次の計算で最大バッファ長を見積もることができます。

1. 列データのバイト・サイズを取得します。

2. 取得したサイズに、クライアント・キャラクタ・セットの1文字当たりの最大バイト数を乗算します。

この方法は最も簡単で速い方法ですが、正確ではないためメモリーを浪費する可能性があります。この方法は、キャラクタ・セットのすべての組合せに適用できます。たとえば、UTF-16データのバインドと定義の場合は、次の例でクライアント・バッファを計算します。

ub2 csid = OCI_UTF16ID;
oratext *selstmt = "SELECT ename FROM emp";
counter = 1;
...
OCIStmtPrepare(stmthp, errhp, selstmt, (ub4)strlen((char*)selstmt),
OCI_NTV_SYNTAX, OCI_DEFAULT);
OCIStmtExecute ( svchp, stmthp, errhp, (ub4)0, (ub4)0,
(CONST OCISnapshot*)0, (OCISnapshot*)0,
OCI_DESCRIBE_ONLY);
OCIParamGet(stmthp, OCI_HTYPE_STMT, errhp, &myparam, (ub4)counter);
OCIAttrGet((void*)myparam, (ub4)OCI_DTYPE_PARAM, (void*)&col_width,
(ub4*)0, (ub4)OCI_ATTR_DATA_SIZE, errhp);
...
maxenamelen = (col_width + 1) * sizeof(utext);
cbuf = (utext*)malloc(maxenamelen);
...
OCIDefineByPos(stmthp, &dfnp, errhp, (ub4)1, (void *)cbuf,
(sb4)maxenamelen, SQLT_STR, (void *)0, (ub2 *)0,
(ub2*)0, (ub4)OCI_DEFAULT);
OCIAttrSet((void *) dfnp, (ub4) OCI_HTYPE_DEFINE, (void *) &csid,
(ub4) 0, (ub4)OCI_ATTR_CHARSET_ID, errhp);
OCIStmtFetch(stmthp, errhp, 1, OCI_FETCH_NEXT, OCI_DEFAULT);
...

OCIでのUTF-8のNLS_LANGのキャラクタ・セットへの設定

Unicode UTF-8エンコーディングをサポートするOCIクライアント・アプリケーションの場合、データベース・キャラクタ・セットがUTF8でないかぎり、AL32UTF8を使用してNLS_LANGキャラクタ・セットを指定します。データベース・キャラクタ・セットがUTF8である場合は、UTF8を使用します。

AL16UTF16はサーバー用の各国語キャラクタ・セットであるため、NLS_LANGをAL16UTF16に設定しないでください。UTF-16を使用する必要がある場合は、データをバインドまたは定義するときに、OCIAttrSet()関数を使用してクライアント・キャラクタ・セットをOCI_UTF16IDに指定してください。

OCIでのSQL CHARデータ型のバインドと定義

SQL CHARデータ型を使用してデータをバインドおよび定義するためのUnicodeキャラクタ・セットを指定するには、OCIBind()またはOCIDefine() API後に、OCIAttrSet()関数をコールして、適切なキャラクタ・セットIDを設定する必要があります。次に一般的な2つの例を示します。

- OCIBind()またはOCIDefine()の後にOCIAttrSet()をコールして、UTF-16 Unicodeキャラクタ・セット・エンコーディングを指定します。次に例を示します。

...
ub2 csid = OCI_UTF16ID;
utext ename[100]; /* enough buffer for ENAME */
...
/* Inserting Unicode data */
OCIBindByName(stmthp1, &bnd1p, errhp, (oratext*)":ENAME",
(sb4)strlen((char *)":ENAME"), (void *) ename, sizeof(ename),
SQLT_STR, (void *)&insname_ind, (ub2 *) 0, (ub2 *) 0, (ub4) 0,
(ub4 *)0, OCI_DEFAULT);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &csid,
(ub4) 0, (ub4)OCI_ATTR_CHARSET_ID, errhp);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &ename_col_len,
(ub4) 0, (ub4)OCI_ATTR_MAXDATA_SIZE, errhp);
...
/* Retrieving Unicode data */
OCIDefineByPos (stmthp2, &dfn1p, errhp, (ub4)1, (void *)ename,
(sb4)sizeof(ename), SQLT_STR, (void *)0, (ub2 *)0,
(ub2*)0, (ub4)OCI_DEFAULT);
OCIAttrSet((void *) dfn1p, (ub4) OCI_HTYPE_DEFINE, (void *) &csid,
(ub4) 0, (ub4)OCI_ATTR_CHARSET_ID, errhp);
...

バインドされたバッファがutextデータ型の場合は、OCIBind()またはOCIDefine()のコール時にキャスト(text*)を追加する必要があります。OCI_ATTR_MAXDATA_SIZE属性の値は通常、サーバーのキャラクタ・セットの列サイズによって決まります。これは、このサイズが、バインド操作の際に変換用の一時的なバッファ領域をサーバーに割り当てるためにのみ使用されているためです。

- NLS_LANGキャラクタ・セットをUTF8またはAL32UTF8として指定して、OCIBind()またはOCIDefine()をコールします。
環境変数NLS_LANGにUTF8またはAL32UTF8を設定できます。Unicodeを使用していない場合と同様に、OCIBind()およびOCIDefine()をコールします。環境変数NLS_LANGをUTF8またはAL32UTF8に設定し、次のOCIプログラムを実行します。

...
oratext ename[100]; /* enough buffer size for ENAME */
...
/* Inserting Unicode data */
OCIBindByName(stmthp1, &bnd1p, errhp, (oratext*)":ENAME",
(sb4)strlen((char *)":ENAME"), (void *) ename, sizeof(ename),
SQLT_STR, (void *)&insname_ind, (ub2 *) 0, (ub2 *) 0,
(ub4) 0, (ub4 *)0, OCI_DEFAULT);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &ename_col_len,
(ub4) 0, (ub4)OCI_ATTR_MAXDATA_SIZE, errhp);
...
/* Retrieving Unicode data */
OCIDefineByPos (stmthp2, &dfn1p, errhp, (ub4)1, (void *)ename,
(sb4)sizeof(ename), SQLT_STR, (void *)0, (ub2 *)0, (ub2*)0,
(ub4)OCI_DEFAULT);
...

OCIでのSQL NCHARデータ型のバインドと定義

OCI使用時は、UTF-16のバインドまたは定義を使用してSQL NCHARデータ型にアクセスすることをお薦めします。Oracle9i から、SQL NCHARデータ型は、UTF8またはAL16UTF16のいずれかのエンコーディングを使用したUnicodeデータ型になっています。SQL NCHARデータ型のデータにアクセスするには、データ消失が発生しない適切なデータ変換が実行されるように、バインドまたは定義してから実行するまでにOCI_ATTR_CHARSET_FORM属性をSQLCS_NCHARに設定します。SQL NCHARデータ型のデータ長は常に、Unicodeコード単位の数で表されます。

次のプログラムは、NCHARデータ列に対するデータの挿入とフェッチの一般的な例です。

...
ub2 csid = OCI_UTF16ID;
ub1 cform = SQLCS_NCHAR;
utext ename[100]; /* enough buffer for ENAME */
...
/* Inserting Unicode data */
OCIBindByName(stmthp1, &bnd1p, errhp, (oratext*)":ENAME",
(sb4)strlen((char *)":ENAME"), (void *) ename,
sizeof(ename), SQLT_STR, (void *)&insname_ind, (ub2 *) 0,
(ub2 *) 0, (ub4) 0, (ub4 *)0, OCI_DEFAULT);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &cform, (ub4) 0,
(ub4)OCI_ATTR_CHARSET_FORM, errhp);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &csid, (ub4) 0,
(ub4)OCI_ATTR_CHARSET_ID, errhp);
OCIAttrSet((void *) bnd1p, (ub4) OCI_HTYPE_BIND, (void *) &ename_col_len,
(ub4) 0, (ub4)OCI_ATTR_MAXDATA_SIZE, errhp);
...
/* Retrieving Unicode data */
OCIDefineByPos (stmthp2, &dfn1p, errhp, (ub4)1, (void *)ename,
(sb4)sizeof(ename), SQLT_STR, (void *)0, (ub2 *)0, (ub2*)0,
(ub4)OCI_DEFAULT);
OCIAttrSet((void *) dfn1p, (ub4) OCI_HTYPE_DEFINE, (void *) &csid, (ub4) 0,
(ub4)OCI_ATTR_CHARSET_ID, errhp);
OCIAttrSet((void *) dfn1p, (ub4) OCI_HTYPE_DEFINE, (void *) &cform, (ub4) 0,
(ub4)OCI_ATTR_CHARSET_FORM, errhp);
...

OCIでのSQL NCHAR文字列リテラルの処理

デフォルトでは、NCHARのリテラル置換はOCIでは実行されません。(「NCHAR文字列リテラルの置換」を参照してください。)

リテラル置換を有効にするには、環境変数ORA_NCHAR_LITERAL_REPLACEをTRUEに設定します。また、OCIEnvCreate()およびOCIEnvNlsCreate()でOCI_NCHAR_LITERAL_REPLACE_ONモードとOCI_NCHAR_LITERAL_REPLACE_OFFモードを使用すると、この動作をプログラムで制御できます。たとえば、OCIEnvCreate(OCI_NCHAR_LITERAL_REPLACE_ON)と記述するとNCHARのリテラル置換がオンになり、OCIEnvCreate(OCI_NCHAR_LITERAL_REPLACE_OFF)と記述すると置換はオフになります。

例として、次の文を考えてみます。

int main(argc, argv)
{
OCIEnv *envhp;
if (OCIEnvCreate((OCIEnv **) &envhp,
(ub4)OCI_THREADED|OCI_NCHAR_LITERAL_REPLACE_ON,
(dvoid *)0, (dvoid * (*)(dvoid *, size_t)) 0,
(dvoid * (*)(dvoid *, dvoid *, size_t))0,
(void (*)(dvoid *, dvoid *)) 0,
(size_t) 0, (dvoid **) 0))
{
printf("FAILED: OCIEnvCreate()\n";
return 1;
}
...
}

NCHARのリテラル置換がオンの場合、OCIStmtPrepareおよびOCIStmtPrepare2は、SQLテキスト内のN'リテラルをU'リテラルに変換し、結果のSQLテキストを文ハンドルに格納します。この結果、アプリケーションがOCI_ATTR_STATEMENTを使用してOCI文ハンドルからSQLテキストを取り出す場合、SQLテキストは元のテキストで指定されたN'ではなくU'を戻します。

関連項目:
環境変数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

OCIでのCLOB UnicodeデータおよびNCLOB Unicodeデータのバインドと定義

CLOBまたはNCLOBの列に対してUTF-16データの書込み(バインド)および読込み(定義)を行うには、UTF-16キャラクタ・セットIDをOCILobWrite()およびOCILobRead()として指定する必要があります。UTF-16データをCLOB列に書き込むときは、OCILobWrite()を次のようにコールしてください。

...
ub2 csid = OCI_UTF16ID;
err = OCILobWrite (ctx->svchp, ctx->errhp, lobp, &amtp, offset, (void *) buf,
(ub4) BUFSIZE, OCI_ONE_PIECE, (void *)0,
(sb4 (*)()) 0, (ub2) csid, (ub1) SQLCS_IMPLICIT);

amtpパラメータは、Unicodeコード単位でのデータ長です。offsetパラメータは、データ列の開始からのデータのオフセットを示しています。csidパラメータは、UTF-16データ用に設定する必要があります。

CLOB列からUTF-16データを読み込むには、OCILobRead()を次のようにコールします。

...
ub2 csid = OCI_UTF16ID;
err = OCILobRead(ctx->svchp, ctx->errhp, lobp, &amtp, offset, (void *) buf,
(ub4)BUFSIZE , (void *) 0, (sb4 (*)()) 0, (ub2)csid,
(ub1) SQLCS_IMPLICIT);

データ長は常に、Unicodeコード単位の数で表されます。エンコーディングがUTF-16であるため、1つのUnicode補助文字は2コード単位としてカウントされます。LOB列のバインドまたは定義後、OCILobGetLength()を使用してLOB列に格納されているデータ長を測定できます。UTF-16としてデータをバインドまたは定義している場合、戻り値はコード単位によるデータ長です。

err = OCILobGetLength(ctx->svchp, ctx->errhp, lobp, &lenp);

NCLOBを使用している場合は、OCI_ATTR_CHARSET_FORMをSQLCS_NCHARに設定する必要があります。

Unicodeを使用したPro*C/C++プログラミング

Pro*C/C++には、データベースとの間でUnicodeデータの挿入や取出しを行う方法が3通り用意されています。

- Pro*C/C++のVARCHARデータ型またはネイティブなC/C++のtextデータ型を使用すると、UTF8またはAL32UTF8データベースのSQL CHARデータ型で格納されているUnicodeデータにプログラムでアクセスできます。C/C++ のネイティブなtext型をプログラムで使用することもできます。

- Pro*C/C++のUVARCHARデータ型またはネイティブなC/C++のutextデータ型を使用すると、データベースのNCHARデータ型で格納されているUnicodeデータにプログラムでアクセスできます。

- Pro*C/C++ のNVARCHARデータ型を使用すると、NCHARデータ型で格納されているUnicodeデータにプログラムでアクセスできます。Pro*C/C++プログラムでのUVARCHARとNVARCHARの相違は、UVARCHARデータ型のデータはutextバッファに格納されているのに対して、NVARCHARデータ型のデータはtextデータ型で格納されている点です。

Pro*C/C++では、SQLテキストに対してUnicode OCI APIを使用しません。そのため、埋込みSQLテキストは、環境変数NLS_LANGに指定されているキャラクタ・セットでエンコードする必要があります。

この項の内容は、次のとおりです。

- UnicodeでのPro*C/C++データ変換

- Pro*C/C++でのVARCHARデータ型の使用

- Pro*C/C++でのNVARCHARデータ型の使用

- Pro*C/C++でのUVARCHARデータ型の使用

UnicodeでのPro*C/C++データ変換

データ変換はOCIレイヤーで行われますが、Pro*C/C++プログラムで使用されているデータ型に基づいて、どの変換手順を使用するかをOCIに対して指示するのは、Pro*C/C++プリプロセッサです。表7-4に、変換手順を示します。

表7-4 Pro*C/C++のバインドと定義でのデータ変換

Pro*C/C++データ型

SQLデータ型

変換手順

VARCHARまたはtext

CHAR

OCIで発生する、NLS_LANGキャラクタ・セットとデータベース・キャラクタ・セットの間の変換

VARCHARまたはtext

NCHAR

OCIで発生する、NLS_LANGキャラクタ・セットとデータベース・キャラクタ・セットの間の変換

データベース・サーバーで発生する、データベース・キャラクタ・セットと各国語キャラクタ・セットの間の変換

NVARCHAR

NCHAR

OCIで発生する、NLS_LANGキャラクタ・セットと各国語キャラクタ・セットの間の変換

NVARCHAR

CHAR

OCIで発生する、NLS_LANGキャラクタ・セットと各国語キャラクタ・セットの間の変換

データベース・サーバーでの、各国語キャラクタ・セットとデータベース・キャラクタ・セットの間の変換

UVARCHARまたはutext

NCHAR

OCIで発生する、UTF-16と各国語キャラクタ・セットの間の変換

UVARCHARまたはutext

CHAR

OCIで発生する、UTF-16と各国語キャラクタ・セットの間の変換

データベース・サーバーで発生する、各国語キャラクタ・セットからデータベース・キャラクタ・セットへの変換

Pro*C/C++でのVARCHARデータ型の使用

Pro*C/C++のVARCHARデータ型は、lengthフィールドとtextバッファ・フィールド付きの構造体に事前処理されます。次の例では、C/C++のシステム固有のデータ型textとPro*C/C++のVARCHARデータ型を使用して、表の列をバインドおよび定義します。

#include <sqlca.h>
main()
{
...
/* Change to STRING datatype:    */
EXEC ORACLE OPTION (CHAR_MAP=STRING) ;
text ename[20] ;                  /* unsigned short type */
varchar address[50] ;             /* Pro*C/C++ varchar type */

EXEC SQL SELECT ename, address INTO :ename, :address FROM emp;
/* ename is NULL-terminated */
printf(L"ENAME = %s, ADDRESS = %.*s\n", ename, address.len, address.arr);
...
}

Pro*C/C++プログラムでVARCHARデータ型またはシステム固有のtextデータ型を使用すると、プリプロセッサでは、そのプログラムがデータベースのSQL NCHARデータ型ではなく、SQL CHARデータ型の列にアクセスしているとみなします。次に、プリプロセッサは、OCI_ATTR_CHARSET_FORM属性に対するSQLCS_IMPLICIT値を使用してバインドまたは定義することで、この動きを反映するためのC/C++コードを生成します。その結果、バインド変数または定義変数がデータベースのSQL NCHARデータ型の列にバインドされると、データベース・サーバーでの暗黙的な変換によって、データベース・キャラクタ・セットと各国語データベース・キャラクタ・セットの間でデータの変換が行われます。データベース・キャラクタ・セットが各国語キャラクタ・セットより小さい場合は、変換時にデータが消失します。

Pro*C/C++でのNVARCHARデータ型の使用

Pro*C/C++のNVARCHARデータ型は、Pro*C/C++のVARCHARデータ型と類似しています。データベースのSQL NCHARデータ型にアクセスするために使用する必要があります。このデータ型は、SQL NCHARデータ型の列にテキスト・バッファをバインドまたは定義するようにPro*C/C++プリプロセッサに通知します。プリプロセッサは、バインド変数または定義変数のOCI_ATTR_CHARSET_FORM属性にSQLCS_NCHAR値を指定します。この結果、データベースで暗黙的な変換は行われません。

SQL CHARデータ型の列に対してNVARCHARバッファがバインドされると、(NLS_LANGキャラクタ・セットでエンコードされている)NVARCHARバッファのデータは、OCIで各国語キャラクタ・セットとの変換が行われ、次に、データベース・サーバーでデータベース・キャラクタ・セットに変換されます。NLS_LANGキャラクタ・セットがデータベース・キャラクタ・セットより大きい場合は、データが消失する可能性があります。

Pro*C/C++でのUVARCHARデータ型の使用

UVARCHARデータ型は、lengthフィールドとutextバッファ・フィールド付きの構造体に事前処理されます。次のコード例には、2つのホスト変数enameとaddressが含まれています。enameホスト変数は、Unicode文字を20文字格納するutextバッファとして宣言されています。addressホスト変数は、Unicode文字を50文字格納するuvarcharバッファとして宣言されています。lenフィールドとarrフィールドは、構造体のフィールドとしてアクセス可能です。

#include <sqlca.h>
#include <sqlucs2.h>

main()
{
...
/* Change to STRING datatype:    */
EXEC ORACLE OPTION (CHAR_MAP=STRING) ;
utext ename[20] ;                  /* unsigned short type */
uvarchar address[50] ;               /* Pro*C/C++ uvarchar type */

EXEC SQL SELECT ename, address INTO :ename, :address FROM emp;
/* ename is NULL-terminated */
wprintf(L"ENAME = %s, ADDRESS = %.*s\n", ename, address.len,
address.arr);
...
}

Pro*C/C++プログラムでUVARCHARデータ型またはシステム固有のutextデータ型を使用すると、プリプロセッサでは、プログラムがSQL NCHARデータ型にアクセスしているとみなします。次に、プリプロセッサは、OCI_ATTR_CHARSET_FORM属性に対するSQLCS_NCHAR値を使用してバインドまたは定義することで、C/C++コードを生成します。この結果、バインド変数または定義変数がSQL NCHARデータ型の列にバインドされると、データベース・サーバーでは各国語キャラクタ・セットからのデータの暗黙的な変換が行われます。ただし、各国語キャラクタ・セットは常にデータベース・キャラクタ・セットより大きいため、この状況でデータが消失することはありません。

Unicodeを使用したJDBCプログラミング

Oracleには、Oracleデータベースの文字データにJavaプログラムでアクセスするために次のJDBCドライバが用意されています。

- JDBC OCIドライバ

- JDBC Thinドライバ

- サーバー側JDBC内部ドライバ

- サーバー側JDBC Thinドライバ

Javaプログラムでは、SQL CHARデータ型およびNCHARデータ型の列との間で文字データの挿入や取出しを行うことができます。特に、JDBCを使用すると、JavaプログラムでJava文字列をSQL CHARデータ型およびNCHARデータ型にバインドしたり定義できます。Javaのstringデータ型はUTF-16でエンコードされているため、データベースとの間で取り出したり挿入するデータは、UTF-16とデータベース・キャラクタ・セットまたは各国語キャラクタ・セット間で変換する必要があります。また、JDBCを使用すると、PL/SQL文とSQL文をJava文字列に指定できるため、非ASCIIスキーマ・オブジェクト名と文字列リテラルを参照できます。

データベースの接続時、JDBCは、サーバーのNLS_LANGUAGEおよびNLS_TERRITORYパラメータを、JDBCドライバを実行するJava VMのロケールに対応する値に設定します。この操作により、サーバーとJavaクライアントが確実に同じ言語で通信できるようになります。その結果、サーバーから戻されるOracleエラー・メッセージは、クライアントのロケールと同じ言語になります。

この項の内容は、次のとおりです。

- SQL CHARデータ型へのJava文字列のバインドと定義

- SQL NCHARデータ型へのJava文字列のバインドと定義

- コード変更なしのSQL NCHARデータ型の使用方法

- JDBCでのSQL NCHAR文字列リテラルの使用

- JDBCドライバのデータ変換

- Oracleオブジェクト型のoracle.sql.CHARの使用

- JDBCを使用した場合のSQL CHARデータへのアクセスの制限

SQL CHARデータ型へのJava文字列のバインドと定義

Oracle JDBCドライバを使用すると、Java文字列のバインド変数または定義変数を使用して、データベースのSQL CHARデータ型にアクセスできます。次のコードは、Java文字列をCHAR列にバインドする方法を示しています。

int employee_id = 12345;
String last_name = "Joe";
PreparedStatement pstmt = conn.prepareStatement("INSERT INTO" +
"employees (last_name, employee_id) VALUES (?, ?)");
pstmt.setString(1, last_name);
pstmt.setInt(2, employee_id);
pstmt.execute();                 /* execute to insert into first row */
employee_id += 1;                      /* next employee number */
last_name = "\uFF2A\uFF4F\uFF45";    /* Unicode characters in name */
pstmt.setString(1, last_name);
pstmt.setInt(2, employee_id);
pstmt.execute();                 /* execute to insert into second row */

ターゲットSQL列は、そのデータ型と長さを指定することで定義できます。データ型と長さを指定してSQL CHAR列を定義すると、JDBCではこの情報を使用してSQL CHAR列からデータをフェッチする操作のパフォーマンスが最適化されます。次に、SQL CHAR列の定義例を示します。

OraclePreparedStatement pstmt = (OraclePreparedStatement)
conn.prepareStatement("SELECT ename, empno from emp");
pstmt.defineColumnType(1,Types.VARCHAR, 3);
pstmt.defineColumnType(2,Types.INTEGER);
ResultSet rest = pstmt.executeQuery();
String name = rset.getString(1);
int id = reset.getInt(2);

PreparedStatementをOraclePreparedStatementにキャストして、defineColumnType()をコールする必要があります。defineColumnType()の2番目のパラメータは、ターゲットSQL列のデータ型です。3番目のパラメータは、文字数による長さです。

SQL NCHARデータ型へのJava文字列のバインドと定義

Java文字列の変数をSQL NCHARデータ型にバインドまたは定義するために、OracleにはsetFormOfUse()メソッドを含む拡張PreparedStatementが用意されています。このメソッドを使用して、バインド変数のターゲット列がSQL NCHARデータ型であることを明示的に指定できます。次のコードは、Java文字列をNCHAR列にバインドする方法を示しています。

int employee_id = 12345;
String last_name = "Joe"
oracle.jdbc.OraclePreparedStatement pstmt =
(oracle.jdbc.OraclePreparedStatement)
conn.prepareStatement("INSERT INTO employees (last_name, employee_id)
VALUES    (?, ?)");
pstmt.setFormOfUse(1, oracle.jdbc.OraclePreparedStatement.FORM_NCHAR);
pstmt.setString(1, last_name);
pstmt.setInt(2, employee_id);
pstmt.execute();                 /* execute to insert into first row */
employee_id += 1;                      /* next employee number */
last_name = "\uFF2A\uFF4F\uFF45";    /* Unicode characters in name */
pstmt.setString(1, last_name);
pstmt.setInt(2, employee_id);
pstmt.execute();                 /* execute to insert into second row */

ターゲットのSQL NCHAR列は、そのデータ型、使用フォームおよび長さを指定することで定義できます。JDBCでは、この情報を使用して、これらの列からSQL NCHARデータをフェッチする操作のパフォーマンスが最適化されます。次に、SQL NCHAR列の定義例を示します。

OraclePreparedStatement pstmt = (OraclePreparedStatement)
conn.prepareStatement("SELECT ename, empno from emp");
pstmt.defineColumnType(1,Types.VARCHAR, 3,
OraclePreparedStatement.FORM_NCHAR);
pstmt.defineColumnType(2,Types.INTEGER);
ResultSet rest = pstmt.executeQuery();
String name = rset.getString(1);
int id = reset.getInt(2);

SQL NCHAR列を定義するには、defineColumnType()の最初の引数にSQL CHAR列と等価のデータ型を指定し、第2の引数に文字数による長さを指定し、第4の引数に使用フォームを指定する必要があります。

使用フォームの引数を明示的に指定しなくても、NCHAR列にJava文字列をバインドまたは定義できます。その場合は、次のことに注意してください。

- setString()メソッドに引数を指定しないと、JDBCはバインド変数または定義変数がSQL CHAR列用であるとみなします。その結果、JDBCはこれらの変数をデータベース・キャラクタ・セットに変換しようとします。データがデータベースに到着すると、そのデータベースはデータベース・キャラクタ・セットのデータを各国語キャラクタ・セットに暗黙的に変換します。データベース・キャラクタ・セットが各国語キャラクタ・セットのサブセットの場合は、この変換時にデータが消失する可能性があります。各国語キャラクタ・セットはUTF8またはAL16UTF16であるため、データベース・キャラクタ・セットがUTF8またはAL32UTF8以外の場合、データは消失します。

- SQL CHARデータ型からSQL NCHARデータ型への暗黙的な変換はデータベースで行われるため、データベースのパフォーマンスが低下します。

また、SQL CHARデータ型の列にJava文字列をバインドまたは定義しても、使用フォームの引数を指定すると、データベースのパフォーマンスが低下します。ただし、各国語キャラクタ・セットは常にデータベース・キャラクタ・セットより大きいため、データが消失することはありません。

NCHARデータ型用の新しいJDBC4.0メソッド

JDBC 11.1では、新しいJDBC 4.0 (JDK6) SQLデータ型NCHAR、NVARCHAR、LONGNVARCHARおよびNCLOBに対するサポートが追加されています。各国語の文字値を取得するために、アプリケーションから次のいずれかのメソッドをコールできます。

- getNString

- getNClob

- getNCharacterStream

getNClobメソッドは、取り出した値が確かにNCLOBかどうかを検証します。他の点では、これらのメソッドは文字Nのない対応するメソッドと同等です。

各国語キャラクタ・タイプのパラメータ・マーカーの値を指定するために、アプリケーションから次のいずれかのメソッドをコールできます。

- setNString

- setNCharacterStream

- setNClob

これらのメソッドは、setFormOfUse(..., OraclePreparedStatement.FORM_NCHAR)のコールが先行する文字Nのない対応するメソッドと同等です。

関連項目:
『Oracle Database JDBC開発者ガイドおよびリファレンス』のJDK 1.6での各国語キャラクタ・セット用の新しいメソッドに関する項

コード変更なしのSQL NCHARデータ型の使用方法

Javaアプリケーションで使用フォームの引数をデフォルトで指定するかどうかを指示できるように、Oracle JDBCドライバにはJavaシステム・プロパティが導入されています。このプロパティの用途は次のとおりです。

- SQL CHARデータ型にアクセスする既存のアプリケーションは、SQL NCHARデータ型をサポートするように移行できます。これにより、コード行を変更せずに世界中にデプロイできるようになります。

- アプリケーションでは、SQL NCHAR列をバインドおよび定義するときに、setFormOfUse()メソッドをコールする必要はありません。アプリケーション・コードは、バックエンド・データベースで使用中のデータ型に依存せずにそのまま使用できます。このプロパティ・セットを使用すると、アプリケーションをSQL CHARまたはSQL NCHARの使用から簡単に移行できます。

Javaシステム・プロパティは、Javaアプリケーションを起動するコマンドラインで指定します。このフラグを指定する構文は、次のとおりです。

java -Doracle.jdbc.defaultNChar=true <application class>

このプロパティを指定すると、Oracle JDBCドライバでは、アプリケーションのすべてのバインドおよび定義操作に使用フォームの引数が存在するものとみなされます。

データベース・スキーマがSQL CHAR列とSQL NCHAR列の両方で構成されている場合は、このフラグを使用すると、データベース・サーバーで暗黙的な変換が実行されるため、SQL CHAR列へのアクセス時にパフォーマンスが低下することがあります。

関連項目:
暗黙的な変換によるパフォーマンス低下の詳細は、「JDBCドライバのデータ変換」を参照してください。

JDBCでのSQL NCHAR文字列リテラルの使用

JDBCでNCHAR文字列リテラルを使用する場合は、処理前に文字がデータベース・キャラクタ・セットに変換されるため、データ消失の可能性があります。詳細は、「NCHAR文字列リテラルの置換」を参照してください。

NCHAR文字列リテラルを保持する処理を適切に実行するには、プロパティ・セットoracle.jdbc.convertNcharLiteralsを有効にします。値がtrueの場合、このオプションは有効化され、それ以外の場合は無効化されます。デフォルトでは「False」に設定されています。オプションを有効化する方法は2通りあり、a)Javaシステム・プロパティとしてまたはb)接続プロパティとして設定できます。有効化すると、VM(システム・プロパティ)または接続(接続プロパティ)のすべてのSQLで変換が実行されます。たとえば、次のように、Javaシステム・プロパティとしてプロパティを設定できます。

java -Doracle.jdbc.convertNcharLiterals="true" ...

または、次のように接続プロパティとして設定できます。

Properties props = new Properties();
...
props.setProperty("oracle.jdbc.convertNcharLiterals", "true");
Connection conn = DriverManager.getConnection(url, props);

接続プロパティとして設定した場合は、システム・プロパティの設定が上書きされます。

JDBCドライバのデータ変換

Java文字列は常にUTF-16でエンコードされているため、JDBCドライバは、データベース・キャラクタ・セットからUTF-16または各国語キャラクタ・セットにデータを透過的に変換します。変換手順は、JDBCドライバごとにそれぞれ異なります。

- OCIドライバ用のデータ変換

- Thinドライバ用のデータ変換

- サーバー側内部ドライバ用のデータ変換

OCIドライバ用のデータ変換

OCIドライバの場合、SQL文はデータベースに送信され処理される前に、ドライバによって常にデータベース・キャラクタ・セットに変換されます。データベース・キャラクタ・セットがUS7ASCIIでもWE8ISO8859P1でもない場合、ドライバはまずSQL文をJavaでUTF-8に変換し、その後Cでデータベース・キャラクタ・セットに変換します。それ以外の場合は、SQL文をデータベース・キャラクタ・セットに直接変換します。Java文字列のバインド変数については、表7-5に様々な状況に対応する変換手順が要約されています。Java文字列の定義変数については、同じ変換手順が逆方向に行われます。

表7-5 OCIドライバの変換手順

使用フォーム

SQLデータ型

変換手順

FORM_CHAR (Default)

CHAR

JDBCドライバで行われる、UTF-16エンコーディングのJava文字列とデータベース・キャラクタ・セットの間の変換。

FORM_CHAR (Default)

NCHAR

JDBCドライバで行われる、UTF-16エンコーディングのJava文字列とデータベース・キャラクタ・セットの間の変換。さらに、データベース・サーバーで行われる、データベース・キャラクタ・セットと各国語キャラクタ・セットの間の変換。

FORM_NCHAR

NCHAR

JDBCドライバで行われる、UTF-16エンコーディングのJava文字列と各国語キャラクタ・セットの間の変換。

FORM_NCHAR

CHAR

JDBCドライバで行われる、UTF-16エンコーディングのJava文字列と各国語キャラクタ・セットの間の変換。さらに、データベース・サーバーで行われる、各国語キャラクタ・セットとデータベース・キャラクタ・セットの間の変換。

Thinドライバ用のデータ変換

SQL文は、データベースに送信され処理される前に、ドライバによって常にデータベース・キャラクタ・セットまたはUTF-8のいずれかに変換されます。データベース・キャラクタ・セットが次のいずれかのキャラクタ・セットの場合、ドライバはSQL文をデータベース・キャラクタ・セットに変換します。

- US7ASCII

- WE8ISO8859P1

- WE8DEC

- WE8MSWIN1252

それ以外の場合、ドライバはSQL文をUTF-8に変換し、データベースに対してSQL文を処理するにはさらに変換が必要であることを通知します。その場合、データベースはSQL文をデータベース・キャラクタ・セットに変換します。Java文字列のバインド変数の場合、Thinドライバに対しては、表7-6に示されている変換手順が使用されます。Java文字列の定義変数については、同じ変換手順が逆方向に行われます。前述の4つのキャラクタ・セットは、表では選択されたキャラクタ・セットと表示されています。

表7-6 Thinドライバの変換手順

使用フォーム

SQLデータ型

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

変換手順

FORM_CHAR (Default)

CHAR

選択されたキャラクタ・セットの1つ

thinドライバで行われる、UTF-16エンコーディングのJava文字列とデータベース・キャラクタ・セットの間の変換。

FORM_CHAR (Default)

NCHAR

選択されたキャラクタ・セットの1つ

thinドライバで行われる、UTF-16エンコーディングのJava文字列とデータベース・キャラクタ・セットの間の変換。さらに、データベース・サーバーで行われる、データベース・キャラクタ・セットと各国語キャラクタ・セットの間の変換。

FORM_CHAR (Default)

CHAR

選択されたキャラクタ・セット以外

thinドライバで行われる、UTF-16エンコーディングのJava文字列とUTF-8の間の変換。さらに、データベース・サーバーで行われる、UTF-8とデータベース・キャラクタ・セットの間の変換。

FORM_CHAR (Default)

NCHAR

選択されたキャラクタ・セット以外

thinドライバで行われる、UTF-16エンコーディングのJava文字列とUTF-8の間の変換。さらに、データベース・サーバーで行われる、UTF-8からデータベース・キャラクタ・セット、さらに各国語キャラクタ・セットへの変換。

FORM_NCHAR

CHAR

任意

thinドライバで行われる、UTF-16エンコーディングのJava文字列と各国語キャラクタ・セットの間の変換。さらに、データベース・サーバーで行われる、各国語キャラクタ・セットとデータベース・キャラクタ・セットの間の変換。

FORM_NCHAR

NCHAR

任意

thinドライバで行われる、UTF-16エンコーディングのJava文字列と各国語キャラクタ・セットの間の変換。

サーバー側内部ドライバ用のデータ変換

サーバー側内部ドライバはデータベース内部で動作するため、すべてのデータ変換はデータベース・サーバーで行われます。

Oracleオブジェクト型のoracle.sql.CHARの使用

JDBCドライバはOracleオブジェクト型をサポートしています。Oracleオブジェクトは、データベース・キャラクタ・セットまたは各国語キャラクタ・セットで表現したオブジェクトとして、常にデータベースからクライアントに送信されます。つまり、「JDBCドライバのデータ変換」に示したデータ変換の流れは、Oracleオブジェクトのアクセスには適用されないことを意味します。かわりに、データベースからクライアントにオブジェクト型のSQL CHARおよびSQL NCHARデータを送信するために、oracle.sql.CHARクラスが使用されます。

この項の内容は、次のとおりです。

- oracle.sql.CHAR

- oracle.sql.CHARを使用したSQL CHAR属性とNCHAR属性へのアクセス

oracle.sql.CHAR

oracle.sql.CHARクラスには、文字データを変換するための特別な機能があります。Oracleキャラクタ・セットは、oracle.sql.CHARクラスの主な属性です。oracle.sql.CHARオブジェクトの構成時には、常にOracleキャラクタ・セットが渡されます。既知のキャラクタ・セットがない場合、oracle.sql.CHARオブジェクトのデータのバイトには意味がありません。

oracle.sql.CHARクラスは、文字データを文字列に変換するために、次のメソッドを提供します。

- getString()
oracle.sql.CHARオブジェクトが表現する一連の文字を文字列に変換し、Java文字列オブジェクトを戻します。キャラクタ・セットが認識されない場合、getString()はSQLExceptionを戻します。

- toString()
getString()に類似していますが、キャラクタ・セットが認識されない場合、toString()はoracle.sql.CHARデータを16進表現で戻し、SQLExceptionは戻しません。

- getStringWithReplacement()
getString()に類似していますが、このoracle.sql.CHARオブジェクトのキャラクタ・セットにUnicode表現のない文字は、デフォルトの置換文字で置き換えられます。デフォルトの置換文字は、キャラクタ・セットによって異なりますが、通常は疑問符(?)です。

oracle.sql.CHARオブジェクトを(プリコンパイルされたSQL文に渡すなどの目的で)手動で構成できます。oracle.sql.CHARオブジェクトを構成する場合は、oracle.sql.CharacterSetクラスのインスタンスを使用して、oracle.sql.CHARオブジェクトにキャラクタ・セット情報を提供する必要があります。oracle.sql.CharacterSetクラスの各インスタンスは、Oracleでサポートしているキャラクタ・セットの1つを表します。

次のタスクを実行してoracle.sql.CHARオブジェクトを構成します。

1. 静的CharacterSet.makeメソッドをコールして、CharacterSetインスタンスを作成します。これは、キャラクタ・セットのクラスを作成するメソッドです。入力として有効なOracleキャラクタ・セット(OracleId)が必要です。次に例を示します。

int OracleId = CharacterSet.JA16SJIS_CHARSET; // this is character set 832
...
CharacterSet mycharset = CharacterSet.make(OracleId);

Oracleでサポートされている各キャラクタ・セットには、一意の事前定義済OracleIdがあります。OracleIdは、Oracle_character_set_name_CHARSETとして指定したキャラクタ・セットとしていつでも参照できます。Oracle_character_set_nameは、Oracleキャラクタ・セットです。

2. oracle.sql.CHARオブジェクトを構成します。コンストラクタに、文字列(または文字列を表現するバイト)と、キャラクタ・セットに基づくバイトの解析方法を示すCharacterSetオブジェクトを渡します。次に例を示します。

String mystring = "teststring";
...
oracle.sql.CHAR mychar = new oracle.sql.CHAR(teststring, mycharset);

oracle.sql.CHARクラスには複数のコンストラクタがあり、CharacterSetオブジェクトとともに文字列、バイト配列またはオブジェクトを入力としてとることができます。文字列の場合は、oracle.sql.CHARオブジェクトに置かれる前に、CharacterSetオブジェクトが示すキャラクタ・セットに変換されます。

サーバー(データベース)とクライアント(またはクライアントで実行中のアプリケーション)は、異なるキャラクタ・セットを使用できます。このクラスのメソッドを使用してサーバーとクライアントの間でデータを転送する場合、JDBCドライバはサーバー・キャラクタ・セットとクライアント・キャラクタ・セットの間でデータを変換する必要があります。

oracle.sql.CHARを使用したSQL CHAR属性とNCHAR属性へのアクセス

次に、SQLでオブジェクト型を作成する例を示します。

CREATE TYPE person_type AS OBJECT (
name VARCHAR2(30), address NVARCHAR2(256), age NUMBER);
CREATE TABLE employees (id NUMBER, person PERSON_TYPE);

このオブジェクト型に対応するJavaクラスは、次のように構成できます。

public class person implement SqlData
{
oracle.sql.CHAR name;
oracle.sql.CHAR address;
oracle.sql.NUMBER age;
// SqlData interfaces
getSqlType() {...}
writeSql(SqlOutput stream) {...}
readSql(SqlInput stream, String sqltype) {...}
}

ここでは、oracle.sql.CHARクラスは、Oracleオブジェクト型のNAME属性(VARCHAR2データ型)にマップするために使用されています。JDBCは、このクラスに、データベースのVARCHAR2データのバイト表現およびデータベース・キャラクタ・セットに対応するCharacterSetオブジェクトを導入します。次のコードでは、employees表からpersonオブジェクトを取り出しています。

TypeMap map = ((OracleConnection)conn).getTypeMap();
map.put("PERSON_TYPE", Class.forName("person"));
conn.setTypeMap(map);
.       .        .
.       .        .
ResultSet rs = stmt.executeQuery("SELECT PERSON FROM EMPLOYEES");
rs.next();
person p = (person) rs.getObject(1);
oracle.sql.CHAR sql_name = p.name;
oracle.sql.CHAR sql_address=p.address;
String java_name = sql_name.getString();
String java_address = sql_address.getString();

oracle.sql.CHARクラスのgetString()メソッドは、OracleのJavaデータ変換クラスをコールしてJava文字列を戻すことで、データベース・キャラクタ・セットまたは各国語キャラクタ・セットのバイト配列をUTF-16に変換します。rs.getObject(1)コールが動作するように、SqlDataインタフェースをクラスpersonに実装し、オブジェクト型PERSON_TYPEのJavaクラスへのマッピングを示すようにTypemap mapを設定する必要があります。

JDBCを使用した場合のSQL CHARデータへのアクセスの制限

この項の内容は、次のとおりです。

- マルチバイト・データベース環境での文字整合性の問題

マルチバイト・データベース環境での文字整合性の問題

Oracle JDBCドライバは、文字データがデータベースに挿入されるときまたはデータベースから取り出されるときに、適切にキャラクタ・セット変換を実行します。このドライバは、Javaクライアントが使用するUnicode文字とOracleデータベース・キャラクタ・セットの間の変換を行います。Java Unicodeキャラクタ・セットとデータベース・キャラクタ・セットの間のラウンドトリップ変換で、Javaに戻された文字データは、情報の一部が消失している場合があります。これは、複数のUnicode文字が、データベース・キャラクタ・セットの1つの文字にマップされた場合に発生します。たとえば、Unicodeの全角のチルド付き文字(0xFF5E)が、OracleのJA16SJISキャラクタ・セットにマップされている場合があります。Unicode文字のラウンドトリップ変換で、このUnicode文字は0x301Cとなります。これは波形のダッシュ(日本語で、一般的に範囲を示す場合に使用されます)で、チルドではありません。

図7-2に、チルド文字のラウンドトリップ変換を示します。

図7-2 文字整合性

この問題は、OracleのJDBCの不具合ではありません。異なるオペレーティング・システムでの文字マッピング仕様が不確定であるために発生する問題です。この問題は、一部のOracleキャラクタ・セット(JA16SJIS、JA16EUC、ZHT16BIG5およびKO16KS5601)の、わずかな文字についてのみ発生します。問題を回避するために、これらの文字に対する完全なラウンドトリップ変換は避けてください。

Unicodeを使用したODBCとOLE DBのプログラミング

Windowsプラットフォームを使用している場合は、OracleサーバーへのアクセスにOracle ODBCドライバまたはOracle Provider for OLE DBを使用する必要があります。この項では、これらのドライバによるUnicodeのサポート方法を説明します。内容は次のとおりです。

- ODBCとOLE DBのUnicode対応ドライバ

- UnicodeでのOCI依存性

- UnicodeでのODBCとOLE DBのコード変換

- ODBCのUnicodeデータ型

- OLE DBのUnicodeデータ型

- ADOアクセス

ODBCとOLE DBのUnicode対応ドライバ

OracleのODBCドライバとOracle Provider for OLE DBは、データを消失することなく、Unicodeデータを正しく処理できます。たとえば、日本語フォントと日本語文字を入力するためのIMEをインストールしている場合は日本語データが含まれたUnicode ODBCアプリケーションを英語版Windowsで実行できます。

Oracleが提供しているODBCおよびOLE DB製品は、Windowsプラットフォーム専用です。UNIXプラットフォームについては、ベンダーにお問い合せください。

UnicodeでのOCI依存性

Unicodeデータを処理するために、ODBCドライバとOLE DBドライバは、OCI Unicodeのバインド機能と定義機能を使用します。OCI Unicodeデータのバインド機能と定義機能はNLS_LANGの影響を受けません。つまり、プラットフォームのNLS_LANG設定に関係なく、Unicodeデータは正しく処理されます。

関連項目:
「Unicodeを使用したOCIプログラミング」

UnicodeでのODBCとOLE DBのコード変換

通常は、サーバーと異なるデータ型をクライアントのデータ型に指定しないかぎり、冗長なデータ変換は発生しません。たとえば、UnicodeバッファSQL_C_WCHARをNCHARなどのUnicodeデータ列にバインドすると、ODBCドライバとOLE DBドライバは、アプリケーションとOCIレイヤー間の変換を行いません。

フェッチする前にデータ型を指定せずに、クライアントのデータ型でSQLGetDataをコールすると、表7-7の変換が行われます。

表7-7 ODBCの暗黙的なバインド・コード変換

ODBCクライアント・バッファのデータ型

データベース内のターゲット列のデータ型

フェッチ時の変換

コメント

SQL_C_WCHAR

CHAR、VARCHAR2、CLOB

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットである場合、変換は次の順序で行われます。

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

- NLS_LANG

- OCIでのUTF-16

- ODBCでのUTF-16

予期しないデータ消失はありません。

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットである場合は、パフォーマンスが低下する可能性があります。

SQL_C_CHAR

CHAR、VARCHAR2、CLOB

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットの場合:

OCIでの、データベース・キャラクタ・セットからNLS_LANGへの変換

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットでない場合:

OCIとODBCでの、データベース・キャラクタ・セット、UTF-16からNLS_LANGキャラクタ・セットへの変換

予期しないデータ消失はありません。

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットでない場合は、パフォーマンスが低下する可能性があります。

挿入操作と更新操作のためには、データ型を指定する必要があります。

ODBCクライアント・バッファのデータ型は、SQLGetDataのコール時に提供されますが、即時ではありません。このため、SQLFetchには情報はありません。

ODBCドライバではデータ整合性が保証されるため、暗黙的なバインドを実行すると、冗長な変換が行われ、パフォーマンスが低下する場合があります。明示的なバインドでパフォーマンスを優先するか、暗黙的なバインドで利便性を優先するかのいずれかを選択します。

OLE DBのコード変換

ODBCとは異なり、OLE DBでは、データの挿入、更新およびフェッチに対する暗黙的なバインドのみ実行できます。中間のキャラクタ・セットを決定するための変換アルゴリズムは、ODBCの暗黙的なバインドの場合と同じです。

表7-8 OLE DBの暗黙的なバインド

OLE_DBクライアント・バッファのデータ型

データベース内のターゲット列のデータ型

インバインドとアウトバインドの変換

コメント

DBTYPE_WCHAR

CHAR、VARCHAR2、CLOB

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットの場合:

OCIでの、データベース・キャラクタ・セットとNLS_LANGキャラクタ・セットの間の変換。OLE DBでの、NLS_LANGキャラクタ・セットからUTF-16への変換

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットでない場合:

OCIでの、データベース・キャラクタ・セットとUTF-16の間の変換

予期しないデータ消失はありません。

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットである場合は、パフォーマンスが低下する可能性があります。

DBTYPE_CHAR

CHAR、VARCHAR2、CLOB

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットの場合:

OCIでの、データベース・キャラクタ・セットからNLS_LANGへの変換

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットでない場合:

OCIでの、データベース・キャラクタ・セットとUTF-16の間の変換。OLE DBでの、UTF-16からNLS_LANGキャラクタ・セットへの変換

予期しないデータ消失はありません。

データベース・キャラクタ・セットがNLS_LANGキャラクタ・セットのサブセットでない場合は、パフォーマンスが低下する可能性があります。

ODBCのUnicodeデータ型

ODBCのUnicodeアプリケーションでは、SQLWCHARを使用してUnicodeデータを格納します。SQLWCHARのデータ操作には、すべての標準的なWindows Unicode関数を使用できます。たとえば、wcslenはSQLWCHARデータの文字数をカウントします。

SQLWCHAR sqlStmt[] = L"select ename from emp";
len = wcslen(sqlStmt);

Microsoft社のODBC 3.5仕様には、クライアントのSQL_C_WCHAR、SQL_C_WVARCHARおよびSQL_WLONGVARCHARに対して3つのUnicodeデータ型識別子が定義され、サーバーのSQL_WCHAR、SQL_WVARCHARおよびSQL_WLONGVARCHARに対して3つのUnicodeデータ型識別子が定義されています。

バインド操作の場合は、SQLBindParameterを使用して、クライアントとサーバーの両方にデータ型を指定します。次に、Unicodeバインドの例を示します。クライアント・バッファNameは、Unicodeデータ(SQL_C_WCHAR)がUnicode列(SQL_WCHAR)に関連付けられている最初のバインド変数にバインドされていることを示しています。

SQLBindParameter(StatementHandle, 1, SQL_PARAM_INPUT, SQL_C_WCHAR,
SQL_WCHAR, NameLen, 0, (SQLPOINTER)Name, 0, &Name);

表7-9に、SQL NCHARデータ型に対するサーバーのODBC Unicodeデータ型のデータ型マッピングを示します。

表7-9 サーバーのODBC Unicodeデータ型マッピング

ODBCデータ型

Oracleデータ型

SQL_WCHAR

NCHAR

SQL_WVARCHAR

NVARCHAR2

SQL_WLONGVARCHAR

NCLOB

SQL_WCHAR、SQL_WVARCHARおよびSQL_WLONGVARCHARは、ODBC仕様に従ってUnicodeデータとして処理されます。したがって、これらのデータ型はバイト数ではなく文字数で測定されます。

OLE DBのUnicodeデータ型

OLE DBでは、UnicodeのCクライアントに対してwchar_t、BSTRおよびOLESTRデータ型が用意されています。実際には、wchar_tが最も一般的なデータ型で、他のデータ型は特定の目的に使用されます。次の例では、静的なSQL文が割り当てられます。

wchar_t *sqlStmt = OLESTR("SELECT ename FROM emp");

OLESTRマクロは、"L"修飾子と同様に機能してUnicode文字列を示します。OLESTRを使用してUnicodeデータ・バッファを動的に割り当てる必要がある場合は、IMallocアロケート関数(例: CoTaskMemAlloc)を使用します。ただし、OLESTRの使用は、可変長データに対する通常の方法ではありません。一般的な文字列型には、かわりにwchar_t*を使用してください。BSTRも機能は同様です。BSTRは、文字列の前のメモリー位置に長さの接頭辞が付いている文字列です。一部の関数とメソッドでは、BSTR Unicodeデータ型のみが受け入れられます。したがって、割当てを行うSysAllocStringやメモリーを解放するSysFreeStringなどの特別な関数では、BSTR Unicode文字列を操作する必要があります。

ODBCとは異なり、OLE DBではサーバーのデータ型を明示的に指定することはできません。クライアントのデータ型を設定すると、OLE DBドライバは、必要に応じて自動的にデータ変換を実行します。

表7-10に、OLE DBのデータ型マッピングを示します。

表7-10 OLE DBのデータ型マッピング

OLE DBデータ型

Oracleデータ型

DBTYPE_WCHAR

NCHARまたはNVARCHAR2

DBTYPE_BSTRが指定されていると、DBTYPE_WCHARであるとみなされます。これは、両方ともUnicode文字列であるためです。

ADOアクセス

ADOは、OLE DBドライバとODBCドライバを使用してデータベースにアクセスするための高水準APIです。ほとんどのデータベース・アプリケーション開発者が、Windows上でADOインタフェースを使用しています。これは、このインタフェースが、Internet Information Server(IIS)用のActive Server Pages(ASP)に対する主要なスクリプト言語であるVisual Basicから簡単にアクセスできるためです。OLE DBおよびODBCドライバに対しては、ADOは単なるOLE DBコンシューマまたはODBCアプリケーションです。ADOは、OLE DBおよびODBCドライバがUnicode認識コンポーネントであることを前提としているため、常にUnicodeデータを操作しようとします。

Unicodeを使用したXMLプログラミング

グローバル市場向けのソフトウェア開発では、テキスト情報をあらゆる言語でやり取りできるように、UnicodeのXMLサポートが不可欠です。Unicodeでは、ほぼすべての文字と言語が一様にサポートされているため、XMLによる複数言語のサポートがはるかに容易になります。Oracle Database内のXMLでUnicodeを使用可能にするには、データベースのキャラクタ・セットがUTF-8である必要があります。アプリケーションでUnicodeテキスト処理を使用可能にすることが、あらゆる言語をサポートするための基礎となります。各XML文書は、Unicode文字の既知のサブセットのみの使用が保証されないかぎり、Unicodeテキストであり、多言語が使用されている場合もあります。そのため、XMLにUnicodeを使用可能にすることをお薦めします。Unicodeサポートは、Javaおよび他の多数の最新プログラミング環境に用意されています。

この項の内容は、次のとおりです。

- Javaを使用したUnicodeでのXMLファイルの作成

- Javaを使用したUnicodeでのXMLファイルの読取り

- Javaを使用したUnicodeでのXMLストリームの解析

Javaを使用したUnicodeでのXMLファイルの作成

XMLファイルを読み書きする際の一般的な誤りは、文字の入出力にReaderおよびWriterクラスを使用することです。XMLファイルにReaderおよびWriterを使用すると、ランタイム環境のデフォルトの文字コード体系に基づくキャラクタ・セット変換が必要になるため、この方法は使用しないでください。

たとえば、FileWriterクラスを使用すると、文書がデフォルトの文字コード体系に変換されるため、問題が生じることがあります。文書にデフォルトの文字コード体系で使用できない文字が含まれていると、出力ファイルの解析エラーやデータ消失が発生する可能性があります。

XML文書にはUTF-8が一般的ですが、通常、UTF-8はJavaのデフォルトのファイル・エンコーディングではありません。そのため、デフォルトのファイル・エンコーディングを想定するJavaクラスを使用すると、問題が発生する可能性があります。

次の例に、これらの問題を回避する方法を示します。

import java.io.*;
import oracle.xml.parser.v2.*;

public class I18nSafeXMLFileWritingSample
{
public static void main(String[] args) throws Exception
{
// create a test document
XMLDocument         doc  = new XMLDocument();
doc.setVersion( "1.0" );
doc.appendChild(doc.createComment( "This is a test empty document." ));
doc.appendChild(doc.createElement( "root" ));

// create a file
File                file = new File( "myfile.xml" );

// create a binary output stream to write to the file just created
FileOutputStream    fos  = new FileOutputStream( file );

// create a Writer that converts Java character stream to UTF-8 stream
OutputStreamWriter  osw  = new OutputStreamWriter( fos, "UTF8" );

// buffering for efficiency
Writer              w    = new BufferedWriter( osw );

// create a PrintWriter to adapt to the printing method
PrintWriter         out  = new PrintWriter( w );

// print the document to the file through the connected objects
doc.print( out );
}
}

Javaを使用したUnicodeでのXMLファイルの読取り

XMLファイルをテキスト入力として読み取らないでください。ファイル・システムに格納されているXML文書の読取り時には、Parserを使用して文書の文字コード体系を自動的に検出します。Readerクラスの使用や、入力ストリームでの文字コード体系の指定は避けてください。外部エンコーディング情報のないバイナリ入力ストリームの場合、ParserはXML文書のバイト順マークとエンコーディング宣言に基づいて文字コード体系を自動的に検出します。サポート対象のエンコーディングによる整形式の文書は、次のサンプル・コードを使用して正常に解析できます。

import java.io.*;
import oracle.xml.parser.v2.*;

public class I18nSafeXMLFileReadingSample
{
public static void main(String[] args) throws Exception
{
// create an instance of the xml file
File                 file = new File( "myfile.xml" );

// create a binary input stream
FileInputStream      fis  = new FileInputStream( file );

// buffering for efficiency
BufferedInputStream  in = new BufferedInputStream( fis );

// get an instance of the parser
DOMParser  parser = new DOMParser();

// parse the xml file
parser.parse( in );
}
}

Javaを使用したUnicodeでのXMLストリームの解析

XML文書のソースがファイル・システム以外の場合、通常、エンコーディング情報は文書の読取り前に使用可能です。たとえば、入力文書がJava文字ストリームまたはReaderの形式で提供される場合、そのエンコーディングは明らかであり、検出する必要はありません。Parserは、文字コード体系に関係なくUnicodeでReaderの解析を開始できます。

次に、外部エンコーディング情報を使用した文書の解析例を示します。

import java.io.*;
import java.net.*;
import org.xml.sax.*;
import oracle.xml.parser.v2.*;

public class I18nSafeXMLStreamReadingSample
{
public static void main(String[] args) throws Exception
{
// create an instance of the xml file
URL  url = new URL( "http://myhost/mydocument.xml" );

// create a connection to the xml document
URLConnection  conn = url.openConnection();

// get an input stream
InputStream  is = conn.getInputStream();

// buffering for efficiency
BufferedInputStream  bis = new BufferedInputStream( is );

/* figure out the character encoding here                              */
/* a typical source of encoding information is the content-type header */
/* we assume it is found to be utf-8 in this example                   */
String  charset = "utf-8";

// create an InputSource for UTF-8 stream
InputSource  in = new InputSource( bis );
in.setEncoding( charset );

// get an instance of the parser
DOMParser  parser = new DOMParser();

// parse the xml stream
parser.parse( in );
}
}

8 Oracle Globalization Development Kit

この章の内容は、次のとおりです。

- Oracle Globalization Development Kitの概要

- グローバルなインターネット・アプリケーションの設計

- グローバルなインターネット・アプリケーションの開発

- Globalization Development Kitスタート・ガイド

- GDKクイック・スタート

- J2EE用GDKアプリケーション・フレームワーク

- GDKのJava API

- GDKアプリケーション構成ファイル

- Java用GDK提供のパッケージおよびクラス

- PL/SQL用GDK提供のパッケージ

- GDKエラー・メッセージ

Oracle Globalization Development Kitの概要

国際化されたアプリケーションの設計および開発は、最も経験豊富な開発者にとってさえ困難な作業になる場合があります。これは通常、知識不足やグローバリゼーションの概念とAPIが複雑であるために起こります。Oracle Databaseを使用してアプリケーションを記述するアプリケーション開発者は、様々なキャラクタ・セット、地域、言語および言語ソート定義のプロパティなど、データベースのグローバリゼーション・サポートのアーキテクチャを理解する必要があります。また、中間層のプログラミング環境のグローバリゼーション機能を理解し、データベースのロケール・モデルとどのように相互作用し、同期化するかを調べる必要もあります。さらに、国際化されたインターネット・アプリケーションを開発するには、キャラクタ・セットおよびロケール要件の異なる様々なオペレーティング・システム上で実行中の複数のクライアントを同時にサポートする機能を持ったコードを設計し、記述することが必要です。

Oracle Globalization Development Kit(GDK)を使用すると、開発プロセスが簡素化され、グローバル環境のサポートに使用されるインターネット・アプリケーションの開発コストが削減されます。GDKには、JavaおよびPL/SQL用の包括的なプログラミングAPI、サンプル・コード、グローバル・アプリケーションの作成中に発生する設計、開発およびデプロイメント上の様々な問題に対処するドキュメントが含まれています。

GDKは、主としてJava用GDKおよびPL/SQL用GDKという2つの部分で構成されています。Java用GDKは、Javaアプリケーションにグローバリゼーション・サポートを提供します。PL/SQL用GDKは、PL/SQLプログラミング環境にグローバリゼーション・サポートを提供します。Java用GDKとPL/SQL用GDKでは、提供される機能が異なります。

グローバルなインターネット・アプリケーションの設計

グローバルなWebサイトやグローバルなインターネット・アプリケーションのデプロイには、グローバリゼーション要件とビジネス要件に応じて2つのアーキテクチャ・モデルがあります。どちらのモデルをデプロイするかは、インターネット・アプリケーションの開発方法と、中間層におけるアプリケーション・サーバーの構成方法に影響します。この2つのモデルは次のとおりです。

- 単一言語インターネット・アプリケーションの複数インスタンス
単一バイナリでロケールを1つのみサポートするインターネット・アプリケーションは、単一言語アプリケーションとして分類されます。ロケールは、各国語とその言語が使用されている地域を指します。たとえば、米国と英国の主要言語は英語です。ただし、この2つの地域の通貨と日付書式の表記規則は異なります。そのため、米国と英国は2つの異なるロケールとみなされます。

このレベルのグローバリゼーション・サポートは、アプリケーション・インスタンスごとに1つのロケールをサポートする場合に適しています。様々なロケールのアプリケーションにアクセスするには、異なるエントリ・ポイントが必要になります。このモデルが管理可能なのは、サポート対象のロケールが少ない場合のみです。

- 多言語アプリケーションの単一インスタンス
単一バイナリで同時に複数のロケールをサポートするインターネット・アプリケーションは、多言語アプリケーションとして分類されます。このレベルのグローバリゼーション・サポートは、1つのインターネット・アプリケーションで同時に複数のロケールをサポートする必要がある場合に適しています。異なるロケール環境のユーザーは、同じエントリ・ポイントを使用してアプリケーションにアクセスします。

単一言語モデルを使用したアプリケーション開発は、多言語モデルを使用したアプリケーション開発とはまったく異なります。Globalization Development Kitは、どちらのアーキテクチャ・モデルを使用したグローバル・アプリケーション開発も支援できるように複数のライブラリで構成されています。

これ以降の内容は、次のとおりです。

- 単一言語インターネット・アプリケーションのデプロイ

- 多言語インターネット・アプリケーションのデプロイ

単一言語インターネット・アプリケーションのデプロイ

図8-1に、単一言語インターネット・アプリケーションの複数インスタンスを使用した、グローバル・インターネット・アプリケーションのデプロイを示します。

図8-1 単一言語インターネット・アプリケーションのアーキテクチャ

各アプリケーション・サーバーは、処理を受け持つロケール用に構成されます。このデプロイメント・モデルは、インターネット・アプリケーションの1つのインスタンスが中間層のアプリケーションと同じロケールで実行されることを想定しています。

インターネット・アプリケーションは、ロケールに使用されるネイティブ・エンコーディングを使用してバックエンド・データベースにアクセスします。単一言語インターネット・アプリケーションをデプロイするメリットは、次のとおりです。

- 個々のロケールのサポートが異なるサーバーに分離されるため、複数のロケールを異なる場所で独立してサポートでき、それに応じてワークロードを分散できます。たとえば、最初は西欧ロケールをサポートし、その後日本語などのアジア・ロケールをサポートできます。

- 同時に複数のロケールをサポートする作業に伴う複雑さが回避されます。多言語インターネット・アプリケーションに比べると、単一言語インターネット・アプリケーションの場合はコードの記述量が大幅に少なくなります。

単一言語インターネット・アプリケーションをデプロイするデメリットは、次のとおりです。

- 異なるロケールについて複数のサーバーをメンテナンスおよび管理するために、余分な作業が必要です。また、様々なアプリケーション・サーバーに異なる構成が必要です。

- アプリケーション・サーバーの最小必要数は、サイトの通信量がアプリケーション・サーバーの能力に到達するかどうかに関係なく、アプリケーションでサポートされるロケールの数に応じて異なります。

- アプリケーション・サーバーのロード・バランシングは、同じロケールのアプリケーション・サーバーのグループに限定されます。

- アプリケーション・サーバーの複数構成には、より多くのQAリソース(ユーザーおよびマシン)が必要です。様々なロケールで実行されるインターネット・アプリケーションは、対応するアプリケーション・サーバー構成で保証される必要があります。

- 多言語によるコンテンツをサポートするようには設計されていません。たとえば、このモデルでは、日本語とアラビア語のデータを含むWebページをサポートするのは容易ではありません。

サポート対象のロケール数が増えるほど、デメリットがメリットを上回ることになります。単一言語デプロイメント・モデルに伴う制限とメンテナンスのオーバーヘッドを考慮すると、このデプロイメント・アーキテクチャは1つまたは2つのロケールのみをサポートするアプリケーションに適しています。

多言語インターネット・アプリケーションのデプロイ

多言語インターネット・アプリケーションは、すべてのロケールを処理する単一アプリケーション・サーバー構成を持つアプリケーション・サーバーにデプロイされます。図8-2に、多言語インターネット・アプリケーションのアーキテクチャを示します。

図8-2 多言語インターネット・アプリケーションのアーキテクチャ

単一のアプリケーション・インスタンスで複数のロケールをサポートするには、アプリケーションで次の操作が必要になる場合があります。

- ユーザーのロケールを動的に検出し、そのロケールの言語および文化的な慣習に従ってHTMLページを構成することで調整します。

- どの言語のデータでもサポートできるように、文字データをUnicodeで処理します。文字データは、ユーザーが入力してもバックエンド・データベースから取り出してもかまいません。

- HTMLページに使用するHTMLページ・エンコーディング(キャラクタ・セット)を動的に判別し、Unicodeとページ・エンコーディングの間でコンテンツを変換します。

多言語インターネット・アプリケーションをデプロイする主なメリットは、次のとおりです。

- すべてのアプリケーション・サーバーに1つのアプリケーション・サーバー構成を使用することで、デプロイメント構成が単純化され、メンテナンス・コストが削減されます。

- パフォーマンス・チューニングと処理能力計画は、Webサイトでサポートされるロケールの数に依存しません。

- ロケールの追加導入が比較的容易です。新規ロケール用にマシンを追加する必要はありません。

- 1つのテスト環境で様々なロケールにまたがってアプリケーションをテストできます。

- このモデルでは、同じアプリケーション・インスタンス内で多言語によるコンテンツをサポートできます。たとえば、このモデルでは、日本語、中国語、英語およびアラビア語のデータを含むWebページを容易にサポートできます。

多言語インターネット・アプリケーションをデプロイするデメリットは、アプリケーション開発時に動的なロケール検出とUnicodeを処理するために余分なコーディングが必要になることです。1つまたは2つの言語のみをサポートすればよい場合、この作業は多額のコストを伴います。

Webサイトで複数のロケールがサポートされている場合には、単一言語アプリケーションをデプロイするよりも多言語インターネット・アプリケーションをデプロイするほうが適しています。

グローバルなインターネット・アプリケーションの開発

異なるロケールをサポートするインターネット・アプリケーションを構築するには、優れた開発力が必要です。

多言語インターネット・アプリケーションの場合は、アプリケーション自体がユーザーのロケールを認識し、ロケールに適したコンテンツを表示できる必要があります。クライアントは、そのロケールに関係なくアプリケーション・サーバーと通信できる必要があります。これにより、アプリケーション・サーバーはデータベース・サーバーと通信し、様々なロケール設定およびキャラクタ・セット設定の作業環境を維持しながらデータを交換します。多言語インターネット・アプリケーションを開発する際に重要な考慮事項の1つは、ユーザーの優先ロケールに従って適切なコンテンツを動的に検出、キャッシュして提供できるようにすることです。

単一言語インターネット・アプリケーションの場合、ユーザーのロケールは常に固定であり、通常はランタイム環境のデフォルト・ロケールに従います。そのため、ロケール構成ははるかに単純です。

次の項では、グローバルなインターネット・アプリケーションの開発時に開発者が直面する最も一般的な問題について説明します。

- ロケールの判別

- ロケール対応

- コンテンツのローカライズ

ロケールの判別

ロケール対応またはロケール依存にするには、インターネット・アプリケーションでユーザーの優先ロケールを判別できる必要があります。

単一言語アプリケーションでは、常にユーザーに同じロケールが提供され、そのロケールは対応するプログラミング環境のデフォルトのランタイム・ロケールと等価である必要があります。

多言語アプリケーションでは、ユーザー・ロケールを次の3つの方法で動的に判別できます。どの方法にもそれぞれメリットとデメリットがありますが、アプリケーションで併用して相互に補完できます。ユーザー・ロケールは、次の方法で判別できます。

- Oracle Internet DirectoryなどのLDAPディレクトリ・サーバーからのユーザー・プロファイル情報、またはデータベースに格納されている他のユーザー・プロファイル表に基づく方法
ユーザー・プロファイルのスキーマには、ユーザーのロケールを示す優先ロケール属性を含める必要があります。ユーザーが前にログオンしたことがない場合、このロケール・ユーザーの判別方法は動作しません。

- ブラウザのデフォルト・ロケールに基づく方法
ブラウザからデフォルトのISOロケール設定を取得します。ブラウザのデフォルトのISOロケールは、すべてのHTTPリクエストでAccept-Language HTTPヘッダーを介して送信されます。Accept-LanguageヘッダーがNULLの場合は、デフォルトで必要なロケールを英語に設定する必要があります。このアプリケーションの短所は、Accept-Languageヘッダーがユーザーのロケール情報に関して信頼できるソースでない場合があることです。

- ユーザーの選択に基づく方法
ユーザーがリスト・ボックスまたはメニューからロケールを選択し、アプリケーションのロケールを選択したロケールに切り替えられるようにします。

Globalization Development Kitは、これらのロケール判別方法を宣言的に使用できるアプリケーション・フレームワークを提供します。

関連項目:
「Globalization Development Kitスタート・ガイド」

ロケール対応

ロケール対応またはロケール依存にするには、インターネット・アプリケーションでユーザーのロケールを判別する必要があります。ユーザー・ロケールの判別後に、アプリケーションで次の操作を実行する必要があります。

- ロケールの言語によるHTMLコンテンツの構成

- ロケールが示す文化的な慣習の使用

日付、時刻および通貨の書式など、ロケール依存の機能は、JavaやPL/SQLなどの各種プログラミング環境に組み込まれています。アプリケーションでは、これらの機能を使用し、ユーザーのロケールの文化的な慣習に従ってHTMLページをフォーマットできます。ロケールの表現は、プログラミング環境ごとに異なります。たとえば、フランス語(カナダ)ロケールは、様々な環境で次のように表現されます。

- ISO規格では、fr-CAで表されます。frはISO 639規格で定義されている言語コードで、CAはISO 3166規格で定義されている国コードです。

- Javaでは、Javaロケール・オブジェクトで表現されます。言語はフランス語を表すISO言語コードのfrとして、国はカナダを表すISO国コードのCAで示されます。Javaロケール名は、fr_CAとなります。

- PL/SQLとSQLでは、主としてNLS_LANGUAGEおよびNLS_TERRITORYセッション・パラメータで表現されます。NLS_LANGUAGEパラメータの値はCANADIAN FRENCHで、NLS_TERRITORYパラメータの値はCANADAです。

複数のプログラミング環境向けのアプリケーションを記述する場合は、環境間でロケールを同期化する必要があります。たとえば、PL/SQLプロシージャをコールするJavaアプリケーションでは、Javaロケールを対応するNLS_LANGUAGE値とNLS_TERRITORY値にマップし、各パラメータ値をユーザーのロケールにあわせて変更してから、PL/SQLプロシージャをコールする必要があります。

Java用のGlobalization Development Kitには、Oracle Databaseでのロケール依存動作の一貫性を保証するために、Javaクラスのセットが用意されています。

コンテンツのローカライズ

アプリケーションで多言語環境をサポートするには、コンテンツを使用言語とユーザーのロケールの表記規則で表示できる必要があります。ハードコード化されたユーザー・インタフェースのテキストは、アプリケーションでサポートされる様々な言語に翻訳できるように、イメージ・ファイルとともにアプリケーションから外部化する必要があります。その後、翻訳ファイルを個別のディレクトリにステージングし、アプリケーションでユーザー・ロケール設定に従って関連コンテンツを検索できるようにします。また、代替メカニズムをサポートするために、特殊なアプリケーション処理が必要になることもあります。これにより、ユーザーの優先ロケールが使用できない場合に、2番目に適切なコンテンツが表示されます。たとえば、カナダ系フランス語のコンテンツが使用できない場合は、かわりにアプリケーションをフランス語ファイルに切り替えることが適切である可能性があります。

Globalization Development Kitスタート・ガイド

Java用Globalization Development Kit(GDK)は、Oracleが設計した最適なグローバリゼーションの手法と機能を使用してグローバルなインターネット・アプリケーションを開発するための、J2EEアプリケーション・フレームワークとJava APIを提供します。Java用GDKより、グローバルなJavaアプリケーションを開発する際の複雑さが軽減され、コードが簡素化されます。

Java用GDKは、J2EEの従来のグローバリゼーション機能を補完する製品です。J2EEプラットフォームにはすでに、国際化されたアプリケーション構築用の強力な基盤がありますが、そのグローバリゼーション機能と動作はOracleの機能とはまったく異なる場合があります。Java用GDKは、中間層のJavaアプリケーションとデータベース・サーバー間でロケール依存動作を同期化します。

PL/SQL用GDKには、PL/SQLで記述されたアプリケーション用にグローバリゼーション機能を追加提供するPL/SQLパッケージのスイートが含まれています。

図8-3に、GDKの主要コンポーネントと、コンポーネント相互の関係を示します。ユーザー・アプリケーションは、中間層のOracle Application ServerのJ2EEコンテナで実行されます。GDKは、J2EEアプリケーションでグローバリゼーション・サポート用のコーディングを簡素化するためのアプリケーション・フレームワークを提供します。フレームワークとアプリケーションは、どちらもGDKのJava APIをコールしてロケール依存タスクを実行します。PL/SQL用GDKには、PL/SQL環境に固有のグローバリゼーションの問題を解決する上で役立つPL/SQLパッケージが用意されています。

図8-3 GDKのコンポーネント

Java用GDKが提供する機能は、次の2つのカテゴリにわかれています。

- J2EE用GDKアプリケーション・フレームワークは、J2EEベースのインターネット・アプリケーションを構築するためのグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。このフレームワークは、フレームワークへのアクセスをアプリケーションに提供する一連のJavaクラスで構成されます。これらの関連Javaクラスを使用すると、グローバリゼーション動作を宣言的に拡張できるようにアプリケーションをフレームワークに対してコード化できます。

- GDKのJava APIは、Javaアプリケーションでの開発サポートを提供し、Oracle Databaseサーバーで提供される一貫したグローバリゼーション操作を提供します。APIはアクセス可能であり、GDKフレームワークから独立しているため、スタンドアロンのJavaアプリケーションとGDKフレームワークに基づかないJ2EEアプリケーションは、Java APIの機能に個別にアクセスできます。Java APIが提供する機能には、Oracle Databaseと同じ方法によるキャラクタ・セットのデータと数値の書式設定、ソートおよび処理が含まれます。

注意:
GDK Java APIは、バージョン1.4以上のJDKでサポートされています。

Java用GDKは、9つの.jarファイルに含まれています。すべてのファイルがorai18n*jarの形式です。これらのファイルはOracle Databaseに付属しており、$ORACLE_HOME/jlibディレクトリにあります。GDKを使用するアプリケーションがデータベースと同じマシンで管理されていない場合、そのアプリケーションを実行するには、GDKファイルをアプリケーション・サーバーにコピーしてCLASSPATHに組み込む必要があります。Javaアプリケーション内では、Oracle Databaseをアプリケーション・サーバーにインストールしなくてもGDKを実行できます。GDKは、あらゆるプラットフォーム上で動作するPure Javaライブラリです。Oracleクライアント・パラメータのNLS_LANGとORACLE_HOMEは必要ありません。

GDKクイック・スタート

この項では、GDKを使用して、単一言語アプリケーションをグローバルな多言語アプリケーションに変更する方法を説明します。この章の以降の各項では、GDKの使用方法に関する詳細を説明します。

図8-4に、単一言語Webアプリケーションのスクリーンショットを示します。

図8-4 元の「HelloWorld」Webページ

GDKを使用していない初期のHelloWorld Webアプリケーションは、「HelloWorld」メッセージが出力され、ページの右上に現在の日時が表示されているだけです。例8-1「HelloWorld JSPページ・コード」は、前のイメージに対する元のHelloWorld JSPソース・コードを示しています。

例8-1 HelloWorld JSPページ・コード

<%@ page contentType="text/html;charset=windows-1252"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Hello World Demo</title>
</head>
<body>
<div style="color: blue;" align="right">
<%= new java.util.Date(System.currentTimeMillis()) %>
</div>
<hr/>
<h1>Hello World!</h1>
</body>
</html>

例8-2 「HelloWorld web.xmlコード」は、HelloWorldメッセージに対応するWebアプリケーション・ディスクリプタ・ファイルを示しています。

例8-2 HelloWorld web.xmlコード

<?xml version = '1.0' encoding = 'windows-1252'?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<description>web.xml file for the monolingual Hello World</description>
<session-config>
<session-timeout>35</session-timeout>
</session-config>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

例8-1のHelloWorld JSPコードは、英語圏のユーザーのみを対象としています。このコードに関する問題の一部を次に示します。

- ユーザー設定項目またはブラウザ設定に基づくロケールの判別が行われません。

- タイトルおよびヘッダーがコードに含まれています。

- ロケール設定項目に基づいて日時の値がローカライズされません。

- コードに含まれる文字エンコーディングはLatin-1に対応しています。

GDKフレームワークをHelloWorldコードに統合し、グローバルな多言語アプリケーションにすることができます。前述のコードを変更して次の機能を含めることができます。

- ユーザーのブラウザ・ロケールを検出し、クライアントにローカライズされたHTMLページを提供する、自動ロケール・ネゴシエーション。サポートされるアプリケーション・ロケールは、GDK構成ファイルで構成されています。

- サポートされるアプリケーション・ロケールをマップするロケール選択リスト。このリストには、ロケールを表す国名であるアプリケーション・ロケール表示名を含めることができます。このリストはWebページに含まれるため、ユーザーは別のロケールを選択できます。

- HelloWorld JSPのグローバリゼーション・サポート用のGDKフレームワークおよびAPI。この機能には、ロケールに依存した方法での表示文字列の選択および日時の値の書式設定が含まれます。

HelloWorldアプリケーションの変更

この項では、HelloWorldアプリケーションを変更してグローバリゼーションをサポートする方法を説明します。このアプリケーションは、簡体字中国語(zh-CN)、スイス系ドイツ語(de-CH)およびアメリカ英語(en-US)という3つのロケールをサポートするよう変更されます。言語に対して次のルールが使用されます。

- クライアント・ロケールでこれらの言語のいずれかがサポートされている場合、その言語がアプリケーションに使用されます。

- クライアント・ロケールでこれらの言語のいずれかがサポートされていない場合、アメリカ英語がアプリケーションに使用されます。

さらに、ユーザーはロケール選択リストからサポートされるロケールを選択することで、言語を変更できます。次の各タスクは、アプリケーションの変更方法を説明しています。

- タスク1: Hello WorldアプリケーションでのGDKフレームワーク使用の有効化

- タスク2: Hello World用のGDKフレームワークの構成

- タスク3: JSPまたはJavaサーブレットの有効化

- タスク4: ロケール選択リストの作成

- タスク5: アプリケーションの作成

タスク1: Hello WorldアプリケーションでのGDKフレームワーク使用の有効化

このタスクでは、Webアプリケーション・デプロイメント・ディスクリプタ・ファイル(web.xml)でGDKフィルタおよびリスナーが構成されます。これによって、GDKフレームワークをHelloWorldアプリケーションに使用できるようになります。例8-3に、GDK対応のweb.xmlファイルを示します。

例8-3 GDK対応のweb.xmlファイル

<?xml version = '1.0' encoding = 'windows-1252'?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<description>web.xml file for Hello World</description>
<!-- Enable the application to use the GDK Application Framework.-->
<filter>
<filter-name>GDKFilter</filter-name>
<filter-class>oracle.i18n.servlet.filter.ServletFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>GDKFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

<listener>
<listener-class>oracle.i18n.servlet.listener.ContextListener</listener-class>
</listener>

<session-config>
<session-timeout>35</session-timeout>
</session-config>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

次のタグがファイルに追加されています。

- <filter>
フィルタ名はGDKFilterであり、フィルタ・クラスはoracle.i18n.servlet.filter.ServletFilterです。

- <filter-mapping>
GDKFilterがURLパターンとともにタグ内に指定されています。

- <listener>
リスナー・クラスはoracle.i18n.servlet.listener.ContextListenerです。デフォルトのGDKリスナーは、フレームワークのアプリケーション・スコープ操作を制御するGDK ApplicationContextをインスタンス化するよう構成されています。

タスク2: Hello World用のGDKフレームワークの構成

GDKアプリケーション・フレームワークは、アプリケーション構成ファイルgdkapp.xmlで構成されています。この構成ファイルは、web.xmlファイルと同じディレクトリに置かれています。例8-4に、gdkapp.xmlファイルを示します。

例8-4 GDK構成ファイルgdkapp.xml

<?xml version="1.0" encoding="UTF-8"?>
<gdkapp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="gdkapp.xsd">

<!-- The Hello World GDK Configuration -->
<page-charset default="yes">UTF-8</page-charset>

<!-- The supported application locales for the Hello World Application -->

<application-locales>
<locale>de-CH</locale>
<locale default="yes">en-US</locale>
<locale>zh-CN</locale>
</application-locales>

<locale-determine-rule>
<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage</locale-source>
</locale-determine-rule>

<message-bundles>
<resource-bundle name="default">com.oracle.demo.Messages</resource-bundle>
</message-bundles>
</gdkapp>

このファイルは、J2EEアプリケーション用に構成する必要があります。このファイルでは次のタグが使用されています。

- <page-charset>
ページのエンコーディング・タグにより、HTTPリクエストおよびレスポンスに使用されるキャラクタ・セットが指定されます。UTF-8エンコーディングにより多くの言語を表現できるため、このエンコーディングがデフォルトで使用されます。

- <application-locales>
gdkapp.xmlファイルでアプリケーション・ロケールを構成すると、ロケールを定義するための中心的な場所が作成されます。これによって、ソース・コードを変更せずにロケールを簡単に追加および削除できるようになります。ロケール・リストは、GDK APIコールApplicationContext.getSupportedLocalesを使用して取得できます。

- <locale-determine-rule>
初期ページの言語は、ブラウザの言語設定により決定されます。ユーザーは、リストから言語を選択してこの言語を上書きできます。Accept-Language HTTPヘッダーをロケールのソースとして最初に使用するために、locale-determine-ruleがGDKにより使用されます。ユーザーがリストからロケールを選択した場合、JSPにより、選択したロケールが含まれるロケール・パラメータ値がポストされます。続いて、GDKにより、コンテンツを含むレスポンスが選択した言語で送信されます。

- <message-bundles>
メッセージ・リソース・バンドルにより、Webページに表示されるローカライズされた静的コンテンツへのアプリケーション・アクセスが可能になります。GDKフレームワークの構成ファイルにより、アプリケーションで、様々な言語の翻訳済テキストに対するデフォルトのリソース・バンドルを定義できます。HelloWorldの例では、ローカライズされた文字列メッセージが、MessagesというJavaのListResourceBundleバンドルに格納されます。Messagesバンドルは、デフォルト・ロケールにおけるアプリケーションのベース・リソースで構成されます。他の2つのリソース・バンドルは、中国語およびドイツ語翻訳を提供します。これらのリソース・バンドルは、それぞれMessages_zh_CN.javaおよびMessages_de.javaと呼ばれます。HelloWorldアプリケーションでは、GDKフレームワークにより決定されたロケールに基づき、リソース・バンドルから「Hello World!」に適した翻訳が選択されます。<message-bundles>タグは、アプリケーションで使用されるリソース・バンドルを構成するために使用されます。

タスク3: JSPまたはJavaサーブレットの有効化

GDK APIを使用するには、JSPおよびJavaサーブレットを有効化する必要があります。例8-5に、GDK APIおよびサービスを使用できるよう変更されたJSPを示します。このJSPは、任意の言語およびロケールに対応できます。

例8-5 有効化されたHelloWorld JSP

. . .
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title><%= localizer.getMessage("helloWorldTitle") %></title>
</head>

<body>
<div style="color: blue;" align="right">
<% Date currDate= new Date(System.currentTimeMillis()); %>
<%=localizer.formatDateTime(currDate, OraDateFormat.LONG)%>
</div>
<hr/>

<div align="left">
<form>
<select name="locale" size="1">
<%= getCountryDropDown(request)%>
</select>
<input  type="submit" value="<%= localizer.getMessage("changeLocale") %>">
</input>
</form>
</div>
<h1><%= localizer.getMessage("helloWorld") %></h1>
</body>
</html>

図8-5に、ブラウザ設定項目の主要ロケールであるzh-CNロケールにより構成されたHelloWorldアプリケーションを示します。HelloWorldの文字列およびページ・タイトルは、簡体字中国語で表示されています。さらに、日付はロケール表記規則zh-CNで書式設定されています。この例では、ユーザーはロケール選択リストからロケールを上書きできます。

図8-5 zh-CNロケールにあわせてローカライズされたHelloWorld

ロケールが変更された場合、またはHTTPリクエストのAccept-Languageヘッダーまたはロケール選択リストを使用して初期化された場合、GUIの動作はそのロケールに適したものとなります。つまり、右上の日時の値は正しくローカライズされます。さらに、「HelloWorld」ページに文字列がローカライズされて表示されます。

GDK Java Localizerクラスは、GDKフレームワークによるロケールの自動検出に基づいてWebページのコンテンツをローカライズする機能を提供します。

次のコードでは、現在のHTTPServletRequestオブジェクトに基づくローカライザのインスタンスが取得されます。さらに、JSPページ内でGDK APIを使用するための複数のインポートが宣言されます。ローカライザにより、代替動作を含むロケールに依存した方法でローカライズされた文字列が取得され、日時が書式設定されます。

<%@page contentType="text/html;charset=UTF-8"%>
<%@page import="java.util.*, oracle.i18n.servlet.*" %>
<%@page import="oracle.i18n.util.*, oracle.i18n.text.*" %>

<%
Localizer localizer = ServletHelper.getLocalizerInstance(request);
%>

次のコードでは、currDate変数に格納された現在日時値が取得されます。この値は、ローカライザのformatDateTimeメソッドにより書式設定されます。formatDateTimeメソッドのOraDateFormat.LONGパラメータは、ローカライザに対し、ロケールの長い書式設定スタイルを使用して日付を書式設定するよう指示します。受信リクエストのロケールがロケール選択リストにより別のロケールに変更された場合、日時の値は、新規ロケールの表記規則に従って書式設定されます。新しく導入されたロケールをサポートするためにコード変更を加える必要はありません。

div style="color: blue;" align="right">

<% Date currDate= new Date(System.currentTimeMillis()); %>
<%=localizer.formatDateTime(currDate, OraDateFormat.LONG)%>
</div>

HelloWorldの文字列およびタイトルはロケール依存の方法で選択されるため、HelloWorld JSPを任意のロケールに再利用できます。翻訳済文字列はリソース・バンドルから選択されます。

GDKでは、リソース・バンドルの代替動作の実装にOraResourceBundleクラスが使用されます。次のコードは、ローカライザがリソース・バンドルからHelloWorldメッセージを選択する方法を示しています。

デフォルトのアプリケーション・リソース・バンドルであるMessagesは、gdkapp.xmlファイルで宣言されます。ローカライザは、メッセージ・リソース・バンドルを使用してメッセージを選択し、ロケール固有のロジックを適用します。たとえば、受信リクエストの現在のロケールが「de-CH」である場合、メッセージはまずmessages_de_CHバンドル内で検索されます。メッセージが存在しない場合、Messages_deリソース・バンドル内で検索されます。

<h1><%= localizer.getMessage("helloWorld") %></h1>

タスク4: ロケール選択リストの作成

ロケール選択リストは、HTTPリクエストのAccept-Languageヘッダーに基づいて選択されたロケールを上書きするために使用されます。GDKフレームワークにより、HTTP POSTリクエストの一部として渡された、新規ロケールの値を示すロケール・パラメータがチェックされます。ロケール選択リストで選択されたロケールは、ロケール・パラメータ値としてポストされます。GDKでは、リクエスト・ロケールにこの値が使用されます。この処理はすべて、GDKコード内で暗黙的に実行されます。

次のサンプル・コードは、ロケール選択リストをHTML selectタグの形式で同じロケールにより表示します。submitタグにより、新しい値がサーバーにポストされます。GDKフレームワークにより適切な選択結果が取得されます。

<form>
<select name="locale" size="1">
<%= getCountryDropDown(request)%>
</select>
<input type="submit" value="<%= localizer.getMessage("changeLocale") %>">
</input>
</form>

ロケール選択リストは、getCountryDropDownメソッドにより生成されるHTMLコードから構成されます。このメソッドにより、構成済のアプリケーション・ロケールがローカライズされた国名に変換されます。

現在のリクエストに関連付けられたApplicationContextオブジェクトを取得するため、ServletHelperクラスがコールされます。このオブジェクトは、アプリケーションに対し、サポートされるロケールおよび構成情報などの情報が含まれるグローバリゼーション・コンテキストを提供します。getSupportedLocalesコールにより、gdkapp.xmlファイル内のロケール・リストが取得されます。構成済アプリケーション・ロケール・リストは、HTML selectのオプションとして表示されます。OraDisplayLocaleInfoクラスは、国名および言語名などのロケール固有要素のローカライゼーション・メソッドを提供します。

このクラスのインスタンスは、GDKフレームワークにより自動的に決定された現在のロケールを渡すことによって作成されます。GDKにより、HTTPリクエストおよびレスポンス用のリクエスト・ラッパーおよびレスポンス・ラッパーが作成されます。request.getLocale()メソッドは、ロケール判別ルールに基づいて、GDKにより決定されたロケールを戻します。

OraDsiplayLocaleInfo.getDisplayCountryメソッドにより、アプリケーション・ロケールのローカライズされた国名が取得されます。ddOptBuffer文字列バッファに、HTMLオプション・リストが作成されます。getCountryDropDownコールは、次のHTML値が含まれる文字列を戻します。

<option value="en_US" selected>United States [en_US]</option>
<option value="zh_CN">China [zh_CN]</option>
<option value="de_CH">Switzerland [de_CH]</option>

前述の値では、ロケールに対してen-USロケールが選択されています。国名は、現在のロケールに基づいて生成されています。

例8-6に、ロケール選択リストを構成するコードを示します。

例8-6 ロケール選択リストの構成

<%!
public String getCountryDropDown(HttpServletRequest request)
{
StringBuffer ddOptBuffer=new StringBuffer();
ApplicationContext ctx = ServletHelper.getApplicationContextInstance(request);
Locale[] appLocales = ctx.getSupportedLocales();
Locale currentLocale = request.getLocale();

if (currentLocale.getCountry().equals(""))
{
// Since the Country was not specified get the Default Locale
// (with Country) from the GDK
OraLocaleInfo oli = OraLocaleInfo.getInstance(currentLocale);
currentLocale = oli.getLocale();
}

OraDisplayLocaleInfo odli = OraDisplayLocaleInfo.getInstance(currentLocale);
for (int i=0;i<appLocales.length; i++)
{
ddOptBuffer.append("<option value=\"" + appLocales[i] + "\"" +
(appLocales[i].getLanguage().equals(currentLocale.getLanguage()) ? " selected" : "") +
">" + odli.getDisplayCountry(appLocales[i]) +
" [" +  appLocales[i] + "]</option>\n");
}

return ddOptBuffer.toString();
}
%>

タスク5: アプリケーションの作成

アプリケーションを作成するには、クラスパスに次の各ファイルを指定する必要があります。

- orai18n.jar

- regexp.jar

orai18n.jarファイルには、GDKフレームワークおよびAPIが含まれます。regexp.jarファイルには、正規表現ライブラリが含まれます。GDK APIには、ロケール判別機能も含まれます。ora18n-lcsd.jarファイルによりクラスが指定されます。

J2EE用GDKアプリケーション・フレームワーク

Java用GDKは、中間層のJ2EEアプリケーション用のグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。また、インターネット・アプリケーションをグローバル対応にするために必要な労力が最小限に抑えられます。図8-6に、GDKアプリケーション・フレームワークを示します。

図8-6 J2EE用GDKアプリケーション・フレームワーク

フレームワークを構成するメインのJavaクラスは次のとおりです。

- ApplicationContextは、アプリケーションのグローバリゼーション・コンテキストを提供します。コンテキスト情報には、サポート対象ロケールのリストと、ユーザーの優先ロケールを判別するための規則が含まれます。このコンテキスト情報は、アプリケーション用のGDKアプリケーション構成ファイルから取得されます。

- LocaleSourceクラスのセットをフレームワークにプラグインできます。各LocaleSourceクラスでは、対応するソースからロケールを取得するためのLocaleSourceインタフェースが実装されます。GDKには、複数のLocaleSourceクラスがバンドルされています。たとえば、DBLocaleSourceクラスは、データベース・スキーマから現行のユーザーのロケール情報を取得します。また、同じLocaleSourceインタフェースを実装してフレームワークにプラグインすると、カスタマイズされたLocaleSourceクラスを記述できます。

- ServletRequestWrapperおよびServletResponseWrapperは、HTTPリクエストとHTTPレスポンスを変換するGDKサーブレット・フィルタのメイン・クラスです。ServletRequestWrapperは、ApplicationContextおよびLocaleSourceオブジェクトから収集した情報に基づいて、HTTPリクエストごとにLocalizerオブジェクトをインスタンス化し、フォーム・パラメータが正しく処理されることを確認します。ServletResponseWrapperは、HTTPレスポンスの構成方法を制御します。

- Localizerは、現行のユーザー・ロケールとアプリケーション・コンテキストに依存する重要な関数を公開するオールインワン・オブジェクトです。集中化されたメソッド・セットを提供し、それらをコールすることで、現行のユーザー・ロケールとアプリケーション・コンテキストに基づくアプリケーションの適切な動作を可能にします。

- GDKのJava APIは、常にアプリケーションで使用してグローバリゼーション動作を詳細に制御できます。

GDKアプリケーション・フレームワークは、アプリケーションで複数のロケールをサポートするために必要なコーディングを簡略化します。このアプリケーション・フレームワークに従ってJ2EEアプリケーションを記述すると、アプリケーション・コードがアプリケーションがサポートするロケールから独立し、GDKアプリケーション構成ファイルにグローバリゼーション・サポートを定義することで、アプリケーションのグローバリゼーション・サポートを制御できます。サポートされるアプリケーション・ロケールのリストにロケールを追加したり、リストからロケールを削除しても、コードの変更は必要ありません。

次のリストに、GDKアプリケーション構成ファイル内でグローバリゼーション・サポートを定義できる範囲について参考情報を示します。

- サポートされているロケールのリストからロケールを追加または削除できます。

- ユーザー・ロケールの判別方法を変更できます。

- アプリケーションのHTMLページ・エンコーディングを変更できます。

- 翻訳済リソースの検索方法を指定できます。

- 新しいLocaleSourceオブジェクトをフレームワークにプラグインし、それを使用してユーザー・ロケールを検出できます。

この項の内容は、次のとおりです。

- J2EEアプリケーションでGDKフレームワークを使用可能にする方法

- GDKフレームワークへのロケール・ソースの統合

- GDKフレームワークからのユーザー・ロケールの取得

- GDK Localizerを使用したロケール対応機能の実装

- GDKでサポートされているアプリケーション・ロケールの定義

- GDKフレームワークでのASCII以外の入出力の処理

- GDKでのローカライズされたコンテンツの管理

J2EEアプリケーションでGDKフレームワークを使用可能にする方法

J2EE用のGDKアプリケーション・フレームワークの動作は、GDKアプリケーション構成ファイルgdkapp.xmlにより制御されます。アプリケーション構成ファイルを使用することで、開発者はグローバル・アプリケーションの動作を1箇所で指定できます。GDKを使用するJ2EEアプリケーションごとに、1つのアプリケーション構成ファイルが必要です。gdkapp.xmlファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリに置く必要があります。このファイルでは、GDKフレームワークの動作およびプロパティと、それを使用するアプリケーションを指定します。このファイルには、ロケール・マッピング表、コンテンツ・ファイルのキャラクタ・セットおよびアプリケーションの構成用グローバリゼーション・パラメータが含まれます。アプリケーション管理者はアプリケーション構成ファイルを変更することで、プログラムを変更したり再コンパイルしなくても、アプリケーションのグローバリゼーション動作を変更できます。

関連項目:
「GDKアプリケーション構成ファイル」

J2EEアプリケーションで、対応するGDKアプリケーション構成ファイルにより定義されたGDKアプリケーション・フレームワークを使用するには、アプリケーションのweb.xmlファイル内でGDKサーブレット・フィルタとGDKコンテキスト・リスナーを定義する必要があります。web.xmlファイルを変更し、ファイルの先頭に次の行を挿入してください。

<web-app>
<!-- Add GDK filter that is called after the authentication -->

<filter>
<filter-name>gdkfilter</filter-name>
<filter-class>oracle.i18n.servlet.filter.ServletFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>gdkfilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

<!-- Include the GDK context listener -->

<listener>
<listener-class>oracle.i18n.servlet.listener.ContextListener</listener-class>
</listener>
</web-app>

gdkapp.xmlファイルとweb.xmlファイルの例は、$ORACLE_HOME/nls/gdk/demoディレクトリにあります。

GDKアプリケーション・フレームワークは、バージョン2.3以降のサーブレット・コンテナをサポートしています。GDKアプリケーション・フレームワークでは、サーブレット・フィルタ機能を使用して、ユーザー・ロケールの判別やコンテンツ・ファイルのキャラクタ・セットの指定などの、透過的なグローバリゼーション操作が実行されます。ContextListenerは、GDKアプリケーション構成ファイルに記述されているGDKアプリケーション・パラメータをインスタンス化します。ServletFilterは、リクエスト・オブジェクトとレスポンス・オブジェクトを、それぞれGDKリクエスト(ServletRequestWrapper)およびGDKレスポンス(ServletResponseWrapper)オブジェクトでオーバーライドします。

アプリケーションで他のアプリケーション・フィルタが使用され、同じメソッドのオーバーライドもする場合は、GDKフレームワーク内のフィルタが不正な結果を戻すことがあります。たとえば、getLocaleがen_USを戻しても、その結果が他のフィルタによりオーバーライドされると、GDKロケール検出メカニズムの結果が影響を受けます。GDKフレームワークのフィルタでオーバーライドされるすべてのメソッドについては、『Oracle Globalization Development Kit Java API Reference』を参照してください。GDKフレームワークとともに他のフィルタを使用する場合は、競合の可能性に注意してください。

GDKフレームワークへのロケール・ソースの統合

ユーザーの優先ロケールの決定は、アプリケーションをグローバル対応にする作業の最初のステップです。J2EEアプリケーション・フレームワークのロケール検出機能はプリミティブなものです。ロケール・ソースの中から最適なユーザー・ロケールを透過的に取得する方法が備わっていません。HTTP言語プリファレンスによるロケール検出のみが可能で、マルチレベルのロケール代替メカニズムはサポートされません。GDKアプリケーション・フレームワークは、事前定義されたロケール・ソースをサポートすることで、J2EEを補完します。Webアプリケーションでは、複数のロケール・ソースを使用できます。表8-1に、GDKが提供するロケール・ソースを示します。

表8-1 GDK提供のロケール・リソース

ロケール

説明

HTTP言語作業環境

HTTPプロトコルにAccept-Languageの値として含まれるロケール。この値はWebブラウザ・レベルで設定されます。ブラウザのロケールがアプリケーションでサポートされない場合は、ロケール代替操作が必要です。

ユーザー入力ロケール

ユーザーがメニューまたはHTTPプロトコルのパラメータで指定するロケール。

データベースからのユーザー・プロファイルのロケール設定項目

ユーザー・プロファイルの一部としてデータベースに格納されているロケール設定項目。

アプリケーションのデフォルト・ロケール

GDKアプリケーション構成ファイルで定義されているロケール。このロケールは、アプリケーションのデフォルト・ロケールとして定義されます。通常は、他のロケール・ソースが使用できない場合に代替ロケールとして使用されます。

関連項目:
GDKのマルチレベル・ロケール代替メカニズムについては、「GDKアプリケーション構成ファイル」を参照してください。

GDKアプリケーション・フレームワークは、ユーザー入力ロケール、HTTP言語作業環境、データベース内のユーザー・プロファイルのロケール設定項目およびアプリケーションのデフォルト・ロケールなど、事前定義済のロケール・ソースに対してシームレスなサポートを提供します。GDKアプリケーション構成ファイルの<locale-determine-rule>タグの下に次のように定義することで、ロケール・ソースをフレームワークに取り込むことができます。

<locale-determine-rule>
<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HTTPAcceptLanguage</locale-source>
</locale-determine-rule>

GDKフレームワークでは、ロケール・ソースの宣言順に、特定のロケール・ソースが使用可能かどうかが判別されます。使用可能な場合はそのロケール・ソースがソースとして使用され、使用可能でない場合は、リストで次に使用可能なロケール・ソースを探します。前述の例では、UserInputロケール・ソースが使用可能な場合は、最初にそのロケール・ソースが使用され、使用可能でない場合は、HTTPAcceptLanguageロケール・ソースが使用されます。

LDAPサーバーからのロケール設定項目など、カスタムのロケール・ソースは、簡単に実装してGDKフレームワークに統合できます。LocaleSourceインタフェースを実装し、事前定義済のロケール・ソースを指定したのと同じ方法で、対応する実装クラスを<locale-determine-rule>タグの下に指定する必要があります。

LocaleSource実装は、対応するソースからフレームワークにロケール情報を取り出すのみでなく、フレームワークから指示があった場合はロケール情報を対応するソースに対して更新します。ロケール・ソースは読取り専用でも読取り/書込みでもよく、キャッシュ可能でもキャッシュ不可能でもかまいません。GDKフレームワークは読取り/書込みモードのロケール・ソースに対する更新のみを開始し、キャッシュ可能なロケール・ソースからのロケール情報をキャッシュします。カスタム・ロケール・ソースの例は、$ORACLE_HOME/nls/gdk/demoディレクトリにあります。

関連項目:
LocaleSourceの実装の詳細は、『Oracle Globalization Development Kit Java API Reference』を参照してください。

GDKフレームワークからのユーザー・ロケールの取得

GDKでは、自動的なロケール検出の機能によって、ユーザーの現行ロケールが決定されます。たとえば、次のコードでは、現行のユーザー・ロケールがJavaで取り出されます。Localeオブジェクトが明示的に使用されています。

Locale loc = request.getLocale();

getLocale()メソッドは、現行のロケールを表すLocaleを戻します。これは、JSPまたはJava ServletコードでHttpServletRequest.getLocale()メソッドを起動する操作に似ています。ただし、GDKフレームワークでは複数のロケール・ソースが考慮されるため、ユーザー・ロケールの判別ロジックは異なります。

または、GDKフレームワークにより判別されたLocaleオブジェクトをカプセル化するLocalizerオブジェクトを取得することもできます。Localizerオブジェクトを使用するメリットについては、「GDK Localizerを使用したロケール対応機能の実装」を参照してください。

Localizer localizer = ServletHelper.getLocalizerInstance(request);
Locale loc = localizer.getLocale();

GDKフレームワークのロケール検出ロジックは、GDKアプリケーション構成ファイルに定義されているロケール・ソースに依存します。ロケール・ソース名は、アプリケーション構成ファイルに登録されています。次の例に、アプリケーション構成ファイルのlocale-determination-ruleセクションを示します。このセクションは、ユーザーの優先ロケールがLDAPサーバーまたはHTTP Accept-Languageヘッダーによって決定されることを示しています。LDAPUserSchemaロケール・ソース・クラスは、アプリケーションが提供する必要があります。すべてのロケール・ソース・クラスは、LocaleSource抽象クラスから拡張する必要があることに注意してください。

<locale-determine-rule>
<locale-source>LDAPUserSchema</locale-source>
<locale-source>oracle.i18n.localesource.HTTPAcceptLanguage</locale-source>
</locale-determine-rule>

たとえば、ユーザーがアプリケーションで認証を受け、ユーザーのロケール設定項目がLDAPサーバーに格納されている場合、LDAPUserSchemaクラスはLDAPサーバーに接続してユーザー・ロケール設定項目を取り出します。匿名ユーザーの場合、HttpAcceptLanguageクラスはWebブラウザの言語作業環境を戻します。

キャッシュは、HTTPセッションの存続期間のみ維持されます。HTTP言語作業環境からロケール・ソースが取得されると、ロケール情報はHTTP Accept-Languageヘッダーでアプリケーションに渡され、キャッシュされません。これにより、ロケール設定項目をリクエスト間で柔軟に変更できます。HTTPセッション中はキャッシュが使用可能です。

GDKフレームワークで公開されるメソッドを使用すると、アプリケーションでは、LDAPサーバーやデータベース内のユーザー・プロファイル表などのロケール・ソースに永続的に格納されているロケール設定項目情報を上書きできます。また、このメソッドは、現行のHTTPセッション用のキャッシュに格納されている現行のロケール情報をリセットします。次の例に、storeコマンドを使用して優先ロケールを上書きする方法を示します。

<input type="hidden"
name="<%=appctx.getParameterName(LocaleSource.Parameter.COMMAND)%>"
value="store">

キャッシュに格納されている現行のロケール情報を破棄するには、入力パラメータとしてcleanコマンドを指定できます。次の表に、GDKでサポートされているコマンドを示します。

コマンド

機能

store

使用可能なロケール・ソース内のユーザー・ロケール設定項目を、指定のロケール情報で更新します。このコマンドは、読取り専用のロケール・ソースでは無視されます。

clean

キャッシュ内の現行のロケール情報を破棄します。

アプリケーションで使用される他のパラメータ名との競合を回避するために、GDKパラメータ名をアプリケーション構成ファイル内でカスタマイズできることに注意してください。

GDK Localizerを使用したロケール対応機能の実装

GDKアプリケーション・フレームワークから取得されるLocalizerオブジェクトは、オールインワンのグローバリゼーション・オブジェクトであり、アプリケーションでロケール対応機能を構築するときに一般に使用される機能へのアクセスを提供します。また、サポートされているロケールのリストなど、アプリケーション・コンテキストに関する情報を取得するための機能も提供します。Localizerオブジェクトにより、アプリケーションで一貫したロケール対応動作を構築するために必要なコードが簡素化され、集中化されます。

oracle.i18n.servletパッケージには、Localizerクラスが含まれています。Localizerインスタンスは次のようにして取得できます。

Localizer lc = ServletHelper.getLocalizerInstance(request);

Localizerオブジェクトは、GDKフレームワークにより判別される最も一般的なロケール依存情報をカプセル化し、ロケール依存メソッドとして公開します。このオブジェクトには、ユーザー・ロケールに関する次の機能があります。

- 長い書式と短い書式による日付の書式指定

- 数値と通貨の書式指定

- 文字列の照合キー値の取得

- 言語名、国名および通貨名などのロケール・データの取得

- ユーザー・インタフェースの構成に使用するロケール・データの取得

- リソース・バンドルからの翻訳済メッセージの取得

- 書込み方向などの書式指定情報の取得

- URLのエンコードとデコード

- タイム・ゾーンおよび言語ソートの一般リストの取得

たとえば、アプリケーションで日付を表示する場合は、Localizer.formatDate()またはLocalizer.formateDateTime()メソッドをコールします。現行のロケールの書込み方向を判別する場合は、Localizer.getWritingDirection()およびLocalizer.getAlignment()をコールして、それぞれ<DIR>タグと<ALIGN>タグに使用される値を判別できます。

Localizerオブジェクトは、アプリケーションでサポートされているロケールおよび対応する言語と国のリストを列挙するメソッドも公開します。

Localizerオブジェクトは、実際には、GDKのJava API内のクラスを使用可能にしてタスクを実行します。これらのクラスには、OraDateFormat、OraNumberFormat、OraCollator、OraLocaleInfo、oracle.i18n.util.LocaleMapper、oracle.i18n.net.URLEncoderおよびoracle.i18n.net.URLDecoderなどがあります。

Localizerオブジェクトは、ロケール認識のために記述する必要があるコードを簡略化します。このオブジェクトは、GDK Java APIによって作成された対応オブジェクトのキャッシュを保持するため、コール側アプリケーションがその後同一オブジェクトをコールする場合に、これらのオブジェクトを保持する必要がなくなります。Localizerオブジェクトが提供できる以上の機能が必要な場合は、いつでもGDK Java APIの該当するメソッドを直接コールできます。

注意:
書式設定された日付やロケール固有の通貨記号など、多くのLocalizerメソッドで返される文字列は、URLやフォームの入力によってユーザーが提供するロケール・データに基づきます。たとえば、ロケール・ソース・クラスoracle.i18n.servlet.localesource.UserInputにより、ページURLから取得される様々な日時の書式パターンやISO通貨略名が提供されます。日時書式のパターンには、任意のコンテンツを二重引用符で囲んだリテラル文字列が含まれる場合があります。クロスサイト・スクリプト・インジェクション攻撃を防ぐため、Localizerメソッドで返される文字列は、HTMLページの一部として表示される前に適切にエスケープする必要があります。たとえば、クラスoracle.i18n.net.CharEntityReferenceのメソッドencodeを適用します。

関連項目:
Localizerオブジェクトの詳細は、『Oracle Globalization Development Kit Java API Reference』を参照してください。

GDKでサポートされているアプリケーション・ロケールの定義

アプリケーションでサポートする必要のあるロケールの数と名前は、アプリケーションのビジネス要件に基づきます。アプリケーションでサポートされるロケールの名前は、アプリケーション構成ファイルに登録されます。次の例に、アプリケーション構成ファイルのapplication-localesセクションを示します。このセクションは、アプリケーションでドイツ語(de)、日本語(ja)および米英語(en-US)がサポートされ、デフォルトの代替アプリケーション・ロケールとして英語が定義されていることを示しています。ロケール名はIANA規則に基づいていることに注意してください。

<application-locales>
<locale>de</locale>
<locale>ja</locale>
<locale default="yes">en-US</locale>
</application-locales>

GDKフレームワークでユーザー・ロケールが検出されると、戻されるロケールがアプリケーション構成ファイル内のサポート対象ロケールの1つであるかどうかが検証されます。検証アルゴリズムは次のとおりです。

1. アプリケーション構成ファイルからサポート対象アプリケーション・ロケールのリストを取り出します。

2. 検出されたロケールがリストに含まれているかどうかを調べます。リストに含まれている場合は、このロケールを現行のクライアントのロケールとして使用します。

3. 検出されたロケールにバリアントがある場合は、そのバリアントを削除して、削除後のロケールがリストに含まれているかどうかを調べます。たとえば、Javaロケールde_DE_EUROにはEUROバリアントがあります。削除後のロケールがde_DEとなるようにバリアントを削除します。

4. ロケールに国コードが含まれている場合は、国コードを削除し、削除後のロケールがリストに含まれているかどうかを調べます。たとえば、Javaロケールde_DEには国コードDEがあります。削除後のロケールがdeとなるように国コードを削除します。

5. 検出されたロケールがリストにあるどのロケールとも一致しない場合は、アプリケーション構成ファイルに定義されているデフォルト・ロケールをクライアントのロケールとして使用します。

手順3および4を実行することで、アプリケーションでは、言語要件は同じでもアプリケーション構成ファイルでの定義とは異なるロケール設定を使用するユーザーをサポートできます。たとえば、GDKでは、de-AT(ドイツ語のオーストリア系バリアント)、de-CH(ドイツ語のスイス系バリアント)およびde-LU(ドイツ語のルクセンブルグ系バリアント)をサポートできます。

GDKフレームワークの代替ロケール検出機能は、Java Resource Bundleの機能に似ていますが、Java VMのデフォルト・ロケールの影響を受けません。この例外が発生するのは、GDKロケール代替操作では、アプリケーションのデフォルト・ロケールを使用できるためです。

アプリケーション構成ファイルからapplication-localesセクションを省略すると、GDKはアプリケーションで共通ロケールがサポートされるものと想定します。この共通ロケールは、OraLocaleInfo.getCommonLocalesメソッドから戻されることがあります。

GDKフレームワークでのASCII以外の入出力の処理

HTMLページのキャラクタ・セット(または文字コード体系)は、ブラウザやインターネット・アプリケーションにとって重要な情報です。ブラウザは、正しいフォントとキャラクタ・セットのマッピング表をページ表示に使用できるように、この情報を解析する必要があります。インターネット・アプリケーションは、HTMLフォームからの入力データを指定のエンコーディングに基づいて安全に処理できるように、この情報を知る必要があります。

ページ・エンコーディングは、インターネット・アプリケーションで提供されるロケール用のキャラクタ・セットとして変換できます。

インターネット・アプリケーションで、GDKフレームワークを使用せずにHTMLページ用のページ・エンコーディングを正しく指定するには、次の操作を実行する必要があります。

1. 指定のロケールについて、必要なページ入力データのキャラクタ・セット・エンコーディングを判別します。

2. HTTPリクエストとHTTPレスポンスごとに、対応するエンコーディング名を指定します。

GDKフレームワークを使用するアプリケーションは、これらの手順を無視できます。アプリケーション・コードを変更する必要はありません。キャラクタ・セット情報は、GDKアプリケーション構成ファイル内で指定されます。実行時に、GDKはリクエスト・オブジェクトとレスポンス・オブジェクトのキャラクタ・セットを自動的に設定します。GDKフレームワークでは、入力キャラクタ・セットが出力キャラクタ・セットと異なる使用例はサポートされません。

GDKアプリケーション・フレームワークでは、HTMLページのキャラクタ・セット設定に関して次の使用例がサポートされます。

- 1つのローカル・キャラクタ・セットがアプリケーション全体の専用となる場合。この使用例は、単一言語インターネット・アプリケーションに適しています。キャラクタ・セットのプロパティによっては、複数の言語をサポートできる場合があります。たとえば、ほとんどの西欧言語はISO-8859-1で提供できます。

- すべてのコンテンツに、言語に関係なくUnicode UTF-8が使用される場合。この使用例は、デプロイメントにUnicodeを使用する多言語アプリケーションに適しています。

- 各言語のネイティブ・キャラクタ・セットが使用される場合。たとえば、英語のコンテンツはISO-8859-1で表され、日本語のコンテンツはShift_JISで表されます。この使用例は、各ロケールのデフォルトのキャラクタ・セット・マッピングを使用する多言語インターネット・アプリケーションに適しています。アプリケーションでユーザー・ロケールに基づいて様々なキャラクタ・セットをサポートする必要がある場合は、この使用例が役立ちます。たとえば、Unicodeフォントがないモバイル・アプリケーションや、Unicodeを完全にサポートできないインターネット・ブラウザの場合は、リクエストごとにキャラクタ・セットを判別する必要があります。

キャラクタ・セット情報は、GDKアプリケーション構成ファイル内で指定されます。次の例に、すべてのアプリケーション・ページのキャラクタ・セットとしてUTF-8を設定する方法を示します。

<page-charset>UTF-8</page-charset>

ページのキャラクタ・セット情報はServletRequestWrapperクラスによって使用され、リクエスト・オブジェクトの正しいキャラクタ・セットが設定されます。また、インスタンス化時に、出力用のServletResponseWrapperクラスで指定されるContentType HTTPヘッダーによっても使用されます。page-charsetがAUTO-CHARSETに設定されている場合、キャラクタ・セットに現行のユーザー・ロケールのデフォルト・キャラクタ・セットが指定されていると判断されます。page-charsetは次のようにAUTO-CHARSETに設定してください。

<page-charset>AUTO-CHARSET</page-charset>

デフォルト・マッピングは、LocaleMapperクラスから導出されます。このクラスは、GDKのJava APIでロケール名のデフォルトのIANAキャラクタ・セットを提供します。

表8-2に、一般的なISOロケールおよび対応するIANAキャラクタ・セットのマッピングを示します。

表8-2 一般的なISOロケールとIANAキャラクタ・セットのマッピング

ISOロケール

NLS_LANGUAGE値

NLS_TERRITORY値

IANAキャラクタ・セット

ar-SA

ARABIC

SAUDI ARABIA

WINDOWS-1256

de-DE

GERMAN

GERMANY

WINDOWS-1252

en-US

AMERICAN

AMERICA

WINDOWS-1252

en-GB

ENGLISH

UNITED KINGDOM

WINDOWS-1252

el

GREEK

GREECE

WINDOWS-1253

es-ES

SPANISH

SPAIN

WINDOWS-1252

fr

FRENCH

FRANCE

WINDOWS-1252

fr-CA

CANADIAN FRENCH

CANADA

WINDOWS-1252

iw

HEBREW

ISRAEL

WINDOWS-1255

ko

KOREAN

KOREA

EUC-KR

ja

JAPANESE

JAPAN

SHIFT_JIS

it

ITALIAN

ITALY

WINDOWS-1252

pt

PORTUGUESE

PORTUGAL

WINDOWS-1252

pt-BR

BRAZILIAN PORTUGUESE

BRAZIL

WINDOWS-1252

tr

TURKISH

TURKEY

WINDOWS-1254

nl

DUTCH

THE NETHERLANDS

WINDOWS-1252

zh

SIMPLIFIED CHINESE

CHINA

GBK

zh-TW

TRADITIONAL CHINESE

TAIWAN

BIG5

GDKでは、ロケールからキャラクタ・セットへのマッピングもカスタマイズできます。GDKのJava APIで定義されているデフォルトのマッピングをオーバーライドするには、アプリケーション構成ファイル内でロケールからキャラクタ・セットへのマッピング表を指定できます。

<locale-charset-maps>
<locale-charset>
<locale>ja</locale><charset>EUC-JP</charset>
</locale-charset>
</locale-charset-maps>

この例は、GDKによりロケールJapanese(ja)のデフォルト・キャラクタ・セットがSHIFT_JISからEUC-JPに変更されることを示しています。

関連項目:
「GDKでのOracleロケール情報」

GDKでのローカライズされたコンテンツの管理

この項の内容は、次のとおりです。

- JSPとJava Servletでのローカライズされたコンテンツの管理

- 静的ファイルでのローカライズされたコンテンツの管理

JSPとJava Servletでのローカライズされたコンテンツの管理

リソース・バンドルを使用すると、J2SEで実行時にローカライズされたコンテンツにアクセスできます。Java ServletおよびJavaServer Pages(JSP)内の翻訳可能な文字列は、Javaリソース・バンドルに外部化されるため、これらのリソース・バンドルを独立した状態で異なる言語に翻訳できます。翻訳済リソース・バンドルのベース・クラス名は英語バンドルと同じで、接尾辞としてJavaロケール名が使用されます。

リソース・バンドルから翻訳済データを取り出すには、リクエストごとにgetBundle()メソッドを起動する必要があります。

<% Locale user_locale=request.getLocale();
ResourceBundle rb=ResourceBundle.getBundle("resource",user_locale); %>
<%= rb.getString("Welcome") %>

GDKフレームワークにより、リソース・バンドルからテキスト文字列を取り出す操作が簡素化されます。Localizer.getMessage()はリソース・バンドルのラッパーです。

<% Localizer.getMessage ("Welcome") %>

アプリケーションでベース・クラス名としてgetBundle()を指定するかわりに、アプリケーション構成ファイルでリソース・バンドルを指定できます。これにより、GDKでは、翻訳済テキスト文字列がリクエストされた場合に、ResourceBundleオブジェクトが自動的にインスタンス化されます。

<message-bundles>
<resource-bundle name="default">resource</resource-bundle>
</message-bundles>

この構成ファイルの一部では、翻訳後の内容が"resource" Javaバンドル・クラスに格納されている、デフォルトのリソース・バンドルが宣言されています。構成ファイルでは、複数のリソース・バンドルを指定できます。デフォルト以外のバンドルにアクセスするには、getMessageメソッドのnameパラメータを指定します。メッセージ・バンドル・メカニズムでは、実装にOraResourceBundle GDKクラスが使用されます。このクラスでは、Java動作の上で特別なロケール代替動作が提供されます。この規則は次のとおりです。

- 特定のロケールが、使用可能なリソース・バンドル内のロケールと正確に一致する場合は、そのロケールが使用されます。

- シンガポールの中国語(zh_SG)に対するリソース・バンドルが見つからない場合は、簡体字中国語翻訳用の中国の中国語(zh_CN)に対するリソース・バンドルが代替として使用されます。

- 香港の中国語(zh_HK)に対するリソース・バンドルが見つからない場合は、繁体字中国語翻訳用の台湾の中国語(zh_TW)に対するリソース・バンドルが代替として使用されます。

- マカオの中国語(zh_MO)に対するリソース・バンドルが見つからない場合は、繁体字中国語翻訳用の台湾の中国語(zh_TW)に対するリソース・バンドルが代替として使用されます。

- その他の中国語(zh_およびzh)に対するリソース・バンドルが見つからない場合は、簡体字中国語翻訳用の中国の中国語(zh_CN)に対するリソース・バンドルが代替として使用されます。

- Locale.getDefault()メソッドで取得可能なデフォルト・ロケールは、代替操作では考慮されません。

たとえば、デフォルト・ロケールがja_JPで、そのリソース・バンドルが使用可能であるとします。es_MXに対するリソース・バンドルが要求されたときに、esまたはes_MXに対するいずれのリソース・バンドルも提供されていない場合は、ロケール接尾辞が付いていないベース・リソース・バンドル・オブジェクトが戻されます。

OraResourceBundleクラスの使用方法は、java.util.ResourceBundleクラスと同じですが、OraResearchBundleクラス自体はインスタンス化されません。かわりに、getBundleメソッドの戻り値が、java.util.ResourceBundleクラスのサブクラスのインスタンスです。

静的ファイルでのローカライズされたコンテンツの管理

ロケールを1つのみサポートするアプリケーションの場合、通常は、接尾辞/index.htmlが付いたURLによりアプリケーションの初期ページが表示されます。

国際化されたアプリケーションでは、通常、異なる言語のコンテンツは別々に格納され、言語または国名に基づいて異なるディレクトリ内で、または異なるファイル名を使用してステージングされます。この情報は、アプリケーションでローカライズされたコンテンツを取り出すためのURLの構成に使用されます。

次の例に、索引ページのフランス語バージョンと日本語バージョンを取り出す方法を示します。それぞれの接尾辞は次のとおりです。

/fr/index.html
/ja/index.html

GDKフレームワークは、ServletHelperクラスのrewriteURL()メソッドを使用して、翻訳済ファイルを対応する言語ディレクトリで検索する論理を処理します。ServletHelper.rewriteURL()メソッドは、アプリケーション構成ファイルに指定されている規則に基づいてURLを書き換えます。このメソッドを使用して、ローカライズされたコンテンツがステージングされる正しい場所が判別されます。

JSPコードの例を次に示します。

<img src="<%="ServletHelper.rewriteURL("image/welcome.jpg", request)%>">
<a href="<%="ServletHelper.rewriteURL("html/welcome.html", request)%>">

URLの書換え定義は、GDKアプリケーション構成ファイル内で定義されます。

<url-rewrite-rule fallback="yes">
<pattern>(.*)/(a-zA-Z0-9_\]+.)$</pattern>
<result>$1/$A/$2</result>
</url-rewrite-rule>

書換え規則で定義されているpatternセクションは、正規表現の表記規則に従います。resultセクションでは、置換用に次の特殊変数がサポートされます。

- $Lは、現行のユーザー・ロケールのISO 639言語コード部分を表すために使用されます。

- $Cは、ISO 3166の国コードを表します。

- Aはロケール文字列全体を表します。ISO 639の言語コードとISO 3166の国コードが、アンダースコア(_)で連結されます。

- $1から$9は一致した部分文字列を表します。

たとえば、現行のユーザー・ロケールがjaの場合、welcome.jpgイメージ・ファイルのURLはimage/ja/welcome.jpgとして書き換えられ、welcome.htmlはhtml/ja/welcome.htmlに変更されます。

ServletHelper.rewriteURL()メソッドとLocalizer.getMessage()メソッドはどちらも、ユーザー・ロケールの翻訳ファイルが使用できない場合に一貫したロケール代替操作を実行します。たとえば、es_MXロケール(メキシコのスペイン語)のオンライン・ヘルプ・ファイルが使用できなくても、es(スペインのスペイン語)ファイルが使用可能であれば、各メソッドはかわりにスペイン語の翻訳済ファイルを選択します。

GDKのJava API

Javaのグローバリゼーション機能および動作は、Oracle Databaseで提供されるものとは異なります。たとえば、J2SEでは、Oracle Databaseのロケールおよびキャラクタ・セットとは異なるロケールとキャラクタ・セットのセットがサポートされます。この非一貫性のために、アプリケーションに2つの異なる表記規則に基づいて書式指定されたデータが含まれていると、ユーザーが混乱する可能性があります。たとえば、データベースから取り出された日付は、数値と日付の書式指定や言語ソートの順序などのOracleの表記規則を使用して書式指定されます。ただし、静的なアプリケーション・データは、通常はJavaロケールの表記規則を使用して書式設定されます。Javaのグローバリゼーション機能は、アプリケーションが実行されるJDKのバージョンによっても異なる場合があります。

Oracle Database 10gより前のリリースでは、アプリケーションにOracleグローバリゼーション機能を取り込む必要がある場合は、データベースに接続してSQL文を発行する必要がありました。この種の操作があると、アプリケーションは複雑になり、データベースへのネットワーク接続数が増加します。

Oracle Database 10g以上では、GDKのJava APIはグローバリゼーション機能を中間層に拡張します。GDKのJava APIを使用すると、開発者はアプリケーションでOracleの日付および数値の書式指定や言語ソートなどのグローバリゼーション・ロジックを中間層で実行できるようにすることで、データベース内の高コストのプログラミング・ロジックを排除できます。また、GDKのJava APIはXQueryに標準準拠しています。これにより、データベース処理の負荷やアプリケーション層とバックエンドとの不要なネットワーク通信量が減少し、アプリケーション全体のパフォーマンスが向上します。

また、GDKのJava APIは、言語とキャラクタ・セットの検出や、地域または言語に関する共通ロケール・データ(たとえば、カナダでサポートされている全タイム・ゾーン)の列挙など、拡張グローバリゼーション機能も提供します。これらは、ほとんどのプログラミング・プラットフォームでは使用できない機能です。GDKのJava APIを使用しない場合、開発者はこのプロセスをアプリケーション内で処理するためのビジネス・ロジックを記述する必要があります。

GDKのJava APIの主な機能は、次のとおりです。

- GDKでのOracleロケール情報

- GDKでのOracleロケール・マッピング

- GDKでのOracleキャラクタ・セットの変換

- GDKでのOracleの日付書式、数値書式および通貨書式

- GDKでのOracleのバイナリ・ソートと言語ソート

- GDKでのOracle言語およびキャラクタ・セット検出

- GDKでのOracleの翻訳済ロケール名とタイム・ゾーン名

- 電子メール・プログラムへのGDKの使用

GDKでのOracleロケール情報

言語、地域、言語ソートおよびキャラクタ・セットなど、Oracleロケール定義はGDKのJava APIで公開されます。Oracleで使用されるネーミング規則は、他のベンダーとは異なる場合があります。これらの名前と定義の多くは業界標準に従っていますが、特別なユーザー要件にあわせて調整されたOracle固有の名前や定義もあります。

OraLocaleInfoは、言語、地域およびCollatorオブジェクトを含むOracleロケール・クラスです。このクラスは、指定されたロケールのロケール関連オブジェクトのコレクションを取得するメソッドをアプリケーションに提供します。たとえば、GDKで使用可能なOracle言語ソートの完全リスト、特定の地域に対して定義されているローカル・タイム・ゾーン、特定の地域で使用される共通言語などを取得できます。

OraLocaleInfoクラスの使用例を次に示します。

// All Territories supported by GDK
String[] avterr = OraLocaleInfo.getAvailableTerritories();

// Local TimeZones for a given Territory

OraLocaleInfo oloc = OraLocaleInfo.getInstance("English", "Canada");
TimeZone[] loctz = oloc.getLocalTimeZones();

GDKでのOracleロケール・マッピング

GDKのJava APIはLocaleMapperクラスを提供します。Java、IANA、ISO、Oracle間で、等価のロケールおよびキャラクタ・セットがマッピングされます。Javaアプリケーションは、Oracleデータベースのロケール名またはIANAキャラクタ・セット名で指定されたクライアントから、ロケール情報を受信できます。Javaアプリケーションでこの情報を正しく処理するには、同等のJavaロケールやJavaエンコーディングにマッピングできる必要があります。

LocaleMapperクラスの使用例を次に示します。

// Mapping from Java locale to Oracle language and Oracle territory

Locale locale = new Locale("it", "IT");
String oraLang = LocaleMapper.getOraLanguage(locale);
String oraTerr = LocaleMapper.getOraTerritory(locale);

// From Oracle language and Oracle territory to Java Locale

locale = LocaleMapper.getJavaLocale("AMERICAN","AMERICA");
locale = LocaleMapper.getJavaLocale("TRADITONAL CHINESE", "");

// From IANA & Java to Oracle Character set

String ocs1     = LocaleMapper.getOraCharacterSet(
LocaleMapper.IANA, "ISO-8859-1");
String ocs2     = LocaleMapper.getOraCharacterSet(
LocaleMapper.JAVA, "ISO8859_1");

LocaleMapperクラスは、WindowsおよびUNIXプラットフォームの両方で特定のロケールに最も一般的に使用されている、電子メール・キャラクタ・セットを戻すこともできます。これは、電子メール・メッセージを処理する必要のあるJavaアプリケーションの開発時に役立ちます。

関連項目:
「電子メール・プログラムへのGDKの使用」

GDKでのOracleキャラクタ・セットの変換

GDKのJava APIには、ユーザーがOracleキャラクタ・セット変換を実行できるように、一連のキャラクタ・セット変換クラスAPIが含まれています。Java JDKには多数の標準キャラクタ・セットの変換を実行できるクラスがすでに付属していますが、Oracle固有のキャラクタ・セットとOracleのユーザー定義キャラクタ・セットはサポートしていません。

JDK 1.4では、J2SEに開発者がJavaキャラクタ・セットの拡張に使用するインタフェースが導入されています。GDKのJava APIは、このプラグイン機能を使用してOracleのキャラクタ・セットに対する暗黙的なサポートを提供します。J2SE APIにアクセスして、Oracle固有の動作を取得できます。

図8-7に、GDKキャラクタ・セット変換表がJavaキャラクタ・セット表と同じ方法でJ2SEにプラグインされる状況を示します。このJ2SEの交換可能フレームワークにより、Oracleキャラクタ・セット変換を他のJavaキャラクタ・セット変換と同じ方法で使用できます。

図8-7 Oracleキャラクタ・セット・プラグイン

バージョン1.4より前のJDKではjava.nio.charset Javaパッケージを使用できないため、Oracleのキャラクタ・セット・プラグイン機能を使用するにはJDK 1.4以上をインストールする必要があります。

GDKキャラクタ変換クラスは、ユーザー定義のキャラクタ・セットを含むすべてのOracleキャラクタ・セットをサポートします。Javaアプリケーションでは、このクラスを使用して、Javaの内部キャラクタ・セットであるUTF-16との間で正しく変換できます。

Oracleのキャラクタ・セット名はオラクル社独自の名前です。Java独自のキャラクタ・セットとの競合の可能性を回避するために、すべてのOracleキャラクタ・セット名には、JavaのAPIを介してすべてを暗黙的に使用するためのX-ORACLE-接頭辞が付いています。

Oracleキャラクタ・セット変換の使用例を次に示します。

// Converts the Chinese character "three" from UCS2 to JA16SJIS

String str = "\u4e09";
byte[] barr = str.getBytes("x-oracle-JA16SJIS");

他のJavaキャラクタ・セットと同様に、java.nio.charset.Charsetのキャラクタ・セット機能はすべてのOracleキャラクタ・セットに適用されます。たとえば、指定したキャラクタ・セットが他のキャラクタ・セットのスーパーセットかどうかを調べる場合は、次のようにCharset.containsメソッドを使用できます。

Charset cs1 = Charset.forName("x-oracle-US7ASCII");
Charset cs2 = Charset.forName("x-oracle-WE8WINDOWS1252");
// true if WE8WINDOWS1252 is the superset of US7ASCII, otherwise false.
boolean osc = cs2.contains(cs1);

JDBCドライバを使用してデータベースと通信するJavaアプリケーションの場合は、JDBCドライバがアプリケーションとデータベース間で必要なキャラクタ・セット変換を提供します。アプリケーション内でGDKキャラクタ・セット変換メソッドを明示的にコールする必要はありません。Oracleのキャラクタ・セット・エンコーディング形式に基づいてテキスト・ファイルを解析および生成するJavaアプリケーションは、Oracleキャラクタ・セット変換クラスの使用例の1つです。

GDKでのOracleの日付書式、数値書式および通貨書式

GDKのJava APIには書式クラスが用意されており、このクラスではoracle.i18n.textパッケージ内のJavaアプリケーション用Oracle表記規則を使用して日付、数値および通貨の各書式がサポートされます。

日付、数値および通貨の長い書式と短い書式など、Oracle Database 10gで新しく導入されたロケールの書式も、これらの書式クラスで公開されます。

Oracleの日付書式、数値書式および通貨書式の例を次に示します。

// Obtain the current date and time in the default Oracle LONG format for
// the locale de_DE (German_Germany)

Locale locale = new Locale("de", "DE");
OraDateFormat odf =
OraDateFormat.getDateTimeInstance(OraDateFormat.LONG, locale);

// Obtain the numeric value 1234567.89 using the default number format
// for the Locale en_IN (English_India)

locale = new Locale("en", "IN");
OraNumberFormat onf = OraNumberFormat.getNumberInstance(locale);
String nm = onf.format(new Double(1234567.89));

// Obtain the monetary value 1234567.89 using the default currency
// format for the Locale en_US (American_America)

locale = new Locale("en", "US");

onf = OraNumberFormat.getCurrencyInstance(locale);
nm = onf.format(new Double(1234567.89));

GDKでのOracleのバイナリ・ソートと言語ソート

Oracleでは、データベースでのバイナリ・ソート、単一言語ソートおよび多言語ソートがサポートされています。Oracleデータベースでは、これらのソートが拡張されており、データベース内で大/小文字を区別しないソートおよび検索機能とアクセントを区別しないソートおよび検索機能が提供されます。GDKのJava APIのOraCollatorクラスを使用すると、Javaアプリケーションでは、大/小文字区別なしのオプションやアクセント区別なしのオプションなど、最新のOracleのバイナリ・ソート機能と言語ソート機能に基づいて情報をソートしたり検索できます。

正規化がソートの重要部分になることがあります。文字の複合と分解はUnicode規格に基づくため、ソートもUnicode規格に依存します。GDKには、複合を実行するメソッドがあります。

注意:
JDKのバージョンごとにサポートするUnicode規格のバージョンが異なる可能性があるので、GDKではUnicode規格の最新バージョン(現時点ではUnicode 5.0)に基づくOraNormalizerクラスを提供しています。

バイナリ・ソートのソート順は、使用中のOracleキャラクタ・セットに基づきます。GDKのJava APIでは、UTFEキャラクタ・セットを除き、すべてのOracleキャラクタ・セットのバイナリ・ソートがサポートされます。GDKのJava APIでサポートされない言語ソートはJAPANESEのみですが、JAPANESE_Mを使用すると、同様でより正確なソート結果を得ることができます。

文字列比較と文字列ソートの例を次に示します。

8-7 文字列の比較および文字列の格納

// compares strings using XGERMAN

private static String s1 = "abcSS";
private static String s2 = "abc\u00DF";

String cname = "XGERMAN";
OraCollator ocol = OraCollator.getInstance(cname);
int c = ocol.compare(s1, s2);

// sorts strings using GENERIC_M

private static String[] source =
new String[]
{
"Hochgeschwindigkeitsdrucker",
"Bildschirmfu\u00DF",
"Skjermhengsel",
"DIMM de Mem\u00F3ria",
"M\u00F3dulo SDRAM com ECC",
};

cname = "GENERIC_M";
ocol = OraCollator.getInstance(cname);
List result = getCollationKeys(source, ocol);

private static List getCollationKeys(String[] source, OraCollator ocol)
{
List karr = new ArrayList(source.length);
for (int i = 0; i < source.length; ++i)
{
karr.add(ocol.getCollationKey(source[i]));
}
Collections.sort(karr); // sorting operation
return karr;
}

GDKでのOracle言語およびキャラクタ・セット検出

GDKのJava APIのOracle言語およびキャラクタ・セット検出Javaクラスは、未指定のテキストのキャラクタ・セットと言語を決定するための、統計に基づく高パフォーマンスのエンジンを提供します。このエンジンは、世界中の言語とキャラクタ・セットのペアを自動的に特定できます。言語およびキャラクタ・セット検出エンジンでは、各テキストを使用して一連の確率が設定され、各確率は1つの言語およびキャラクタ・セットのペアに対応します。統計的に最も可能性の高いペアにより、主要な言語とキャラクタ・セットが特定されます。

発行されたテキストの純粋性は、言語およびキャラクタ・セット検出の正確さに影響します。受け入れられるのはプレーン・テキストの文字列のみのため、タグは事前に削除する必要があります。理想的なケースは、外国語や文法上の誤りがほとんどない文学の教科書です。テキスト文字列に複数の言語やキャラクタ・セット、または住所、電話番号およびプログラミング言語コードのように自然でない言語によるテキストが含まれていると、適切な結果が得られない可能性があります。

LCSDetectorクラスは、バイト配列、文字配列、文字列およびInputStreamクラスの言語とキャラクタ・セットを検出できます。プレーン・テキスト・ファイル検出とHTMLファイル検出の両方がサポートされます。このクラスは、長さまたはオフセットと長さの両方が指定されている場合、入力全体またはその一部のみをサンプル用に取得できます。LCSDetectorクラスは、入力ごとに可能性のある言語とキャラクタ・セットのペアを最大3つまで戻すことができます。これらの候補は常に順番にランク付けされ、最も確率の高いペアが最初に戻されます。

関連項目:
サポートされている言語とキャラクタ・セットのペアのリストは、「言語およびキャラクタ・セット検出のサポート」を参照してください。

次の例に、LCSDetectorクラスを使用して言語およびキャラクタ・セット検出機能を使用可能にする方法を示します。

// This example detects the character set of a plain text file "foo.txt" and
// then appends the detected ISO character set name to the name of the text file

LCSDetector         lcsd = new LCSDetector();
File             oldfile = new File("foo.txt");
FileInputStream      in = new FileInputStream(oldfile);
lcsd.detect(in);
String          charset = lcsd.getResult().getIANACharacterSet();
File            newfile = new File("foo."+charset+".txt");
oldfile.renameTo(newfile);

// This example shows how to use the LCSDector class to detect the language and
// character set of a byte array

int          offset = 0;
LCSDetector     led = new LCSDetector();
/* loop through the entire byte array */
while ( true )
{
bytes_read = led.detect(byte_input, offset, 1024);
if ( bytes_read == -1 )
break;
offset += bytes_read;
}
LCSDResultSet    res = led.getResult();

/* print the detection results with close ratios */
System.out.println("the best guess "  );
System.out.println("Langauge " + res.getOraLanguage() );
System.out.println("CharacterSet " + res.getOraCharacterSet() );
int     high_hit = res.getHiHitPairs();
if ( high_hit >= 2 )
{
System.out.println("the second best guess  " );
System.out.println("Langauge " + res.getOraLanguage(2) );
System.out.println("CharacterSet " +res.getOraCharacterSet(2) );
}
if ( high_hit >= 3 )
{
System.out.println("the third best guess  ");
System.out.println("Langauge " + res.getOraLanguage(3) );
System.out.println("CharacterSet " +res.getOraCharacterSet(3) );
}

GDKでのOracleの翻訳済ロケール名とタイム・ゾーン名

Oracleの言語名、地域名、キャラクタ・セット名、言語ソート名およびタイム・ゾーン名はすべて、英語を含む27の言語に翻訳されています。これらはそのままユーザー・アプリケーションに組み込むことができ、異なる言語を使用するユーザー・アプリケーション間で表示名に一貫性をもたらします。OraDisplayLocaleInfoは、ロケールと属性の翻訳を提供するユーティリティ・クラスです。翻訳済の名前は、ユーザー・インタフェースのテキストやドロップダウン選択ボックスに表示する場合に役立ちます。たとえば、ネイティブのフランス語ユーザーは、英語よりもフランス語で表示されたタイム・ゾーン・リストから選択するほうを好みます。

次の例に、OraDisplayLocaleInfoを使用して、カナダでサポートされているタイム・ゾーン・リストをフランス語の翻訳名を使用して戻す方法を示します。

例8-8 OraDisplayLocaleInfoの使用によるタイム・ゾーンの固有リストの取得

OraLocaleInfo oloc = OraLocaleInfo.getInstance("CANADIAN FRENCH", "CANADA");
OraDisplayLocaleInfo odloc = OraDisplayLocaleInfo.getInstance(oloc);
TimeZone[] loctzs = oloc.getLocaleTimeZones();
String []  disptz = new string [loctzs.length];
for (int i=0; i<loctzs.length; ++i)
{
disptz [i]= odloc.getDisplayTimeZone(loctzs[i]);
...
}

電子メール・プログラムへのGDKの使用

GDKのLocaleMapperクラスを使用すると、最も一般的に使用されている電子メール・キャラクタ・セットを取り出すことができます。LocaleMapper.getIANACharSetFromLocaleをロケール・オブジェクト内で渡してコールします。戻り値は、キャラクタ・セット名の配列です。最初に戻されるキャラクタ・セットが、最も一般的に使用されている電子メール・キャラクタ・セットです。

次に、GBKキャラクタ・セット・エンコーディングで簡体字中国語のデータを含む電子メール・メッセージを送信する例を示します。

例8-9 GBKキャラクタ・セット・コードの簡体字中国語で書かれた電子メールの送信

import oracle.i18n.util.LocaleMapper;
import java.util.Date;
import java.util.Locale;
import java.util.Properties;
import javax.mail.Message;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeUtility;
/**
* Email send operation sample
*
* javac -classpath orai18n.jar:j2ee.jar EmailSampleText.java
* java  -classpath .:orai18n.jar:j2ee.jar EmailSampleText
*/
public class EmailSampleText
{
public static void main(String[] args)
{
send("localhost",                    // smtp host name
"your.address@your-company.com",        // from email address
"You",                            // from display email
"somebody@some-company.com",           // to email address
"Subject test zh CN",             // subject
"Content ˘4E02 from Text email", // body
new Locale("zh", "CN")            // user locale
);
}
public static void send(String smtp, String fromEmail, String fromDispName,
String toEmail, String subject, String content, Locale locale
)
{
// get the list of common email character sets
final String[] charset = LocaleMapper.getIANACharSetFromLocale(LocaleMapper.
EMAIL_WINDOWS,
locale
);
// pick the first one for the email encoding
final String contentType = "text/plain; charset=" + charset[0];
try
{
Properties props = System.getProperties();
props.put("mail.smtp.host", smtp);
//  here, set username / password if necessary
Session session = Session.getDefaultInstance(props, null);
MimeMessage mimeMessage = new MimeMessage(session);
mimeMessage.setFrom(new InternetAddress(fromEmail, fromDispName,
charset[0]
)
);
mimeMessage.setRecipients(Message.RecipientType.TO, toEmail);
mimeMessage.setSubject(MimeUtility.encodeText(subject, charset[0], "Q"));
// body
mimeMessage.setContent(content, contentType);
mimeMessage.setHeader("Content-Type", contentType);
mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
mimeMessage.setSentDate(new Date());
Transport.send(mimeMessage);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}

GDKアプリケーション構成ファイル

GDKアプリケーション構成ファイルでは、GDKアプリケーション・フレームワークの動作およびプロパティと、それを使用するアプリケーションを指定します。このファイルには、アプリケーション構成に関するロケール・マッピング表およびパラメータが含まれます。アプリケーションごとに1つの構成ファイルが必要です。

gdkapp.xmlアプリケーション構成ファイルはXML文書です。このファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリにあります。

次の項では、アプリケーション構成ファイルの内容とプロパティの詳細を説明します。

- locale-charset-maps

- page-charset

- application-locales

- locale-determine-rule

- locale-parameter-name

- message-bundles

- url-rewrite-rule

- 例: GDKアプリケーション構成ファイル

locale-charset-maps

このセクションを使用すると、アプリケーションで言語からGDKが提供するデフォルト・キャラクタ・セットへのマッピングをオーバーライドできます。このマッピングは、page-charsetがAUTO-CHARSETに設定されている場合に使用されます。

たとえば、enロケールの場合、デフォルトのGDKキャラクタ・セットはwindows-1252です。ただし、アプリケーションでISO-8859-1が必要な場合は、次のように指定できます。

<locale-charset-maps>
<locale-charset>
<locale>en</locale>
<charset>ISO_8859-1</charset>
</locale-charset>
</locale-charset-maps>

ロケール名は言語コードと国コードからなり、それぞれISO 639およびISO 3166で定義されているISOネーミング規則に従う必要があります。キャラクタ・セット名はIANA表記規則に従います。

オプションで、マッピング表でuser-agentパラメータを指定して、次のような様々なクライアントを区別できます。

<locale-charset>
<locale>en,de</locale>
<user-agent>^Mozilla⁄4.0</user-agent>
<charset>ISO-8859-1</charset>
</locale-charset>

この例は、HTTPヘッダーのuser-agent値が英語(en)およびドイツ語(de)ロケールについてMozilla/4.0(Webクライアントの旧バージョンを指定)から始まる場合、GDKではキャラクタ・セットがISO-8859-1に設定されることを示しています。

カンマ区切りのリストを使用して、複数のロケールを指定できます。

関連項目:
「page-charset」

page-charset

このセクションでは、アプリケーション・ページのキャラクタ・セットを定義します。このセクションが特定のキャラクタ・セットに明示的に設定されている場合は、すべてのページでこのキャラクタ・セットが使用されます。キャラクタ・セット名は、IANAキャラクタ・セットの表記規則に従う必要があります。

<page-charset>UTF-8</page-charset>

ただし、page-charsetがAUTO-CHARSETに設定されている場合、キャラクタ・セットは現行のユーザー・ロケールのデフォルト・キャラクタ・セットに基づきます。デフォルトのキャラクタ・セットは、アプリケーション構成ファイルで指定されているロケールからキャラクタ・セットへのマッピング表から導出されます。

アプリケーション構成ファイル内のキャラクタ・セット・マッピング表が使用できない場合、キャラクタ・セットはGDK内のデフォルト・ロケール名からIANAキャラクタ・セットへのマッピング表に基づきます。デフォルト・マッピングは、OraLocaleInfoクラスから導出されます。

関連項目:

- 「locale-charset-maps」

- 「GDKフレームワークでのASCII以外の入出力の処理」

application-locales

このタグ・セクションでは、アプリケーションでサポートされているロケールのリストを定義します。次に例を示します。

<application-locales>
<locale default="yes">en-US</locale>
<locale>de</locale>
<locale>zh-CN</locale>
</application-locales>

言語要素が*国コードで指定されている場合は、この言語コードを持つすべてのロケール名が適格となります。たとえば、アプリケーション・ロケールの1つとしてde-*(ドイツ語の言語コード)が定義されている場合は、de-AT (ドイツ語 - オーストリア)、de(ドイツ語 - ドイツ)、de-LU(ドイツ語 - ルクセンブルグ)、de-CH(ドイツ語 - スイス)のみでなく、de-CN(ドイツ語 - 中国)のように例外的なロケールの組合せもサポートされます。ただし、アプリケーションは事前定義済のロケール・セットをサポートするように制限できます。

サポートされていないロケールを使用してアプリケーションに接続するユーザー用の代替ロケールとして使用できるように、アプリケーション・ロケールの1つをデフォルトのアプリケーション・ロケールとして設定(default="yes"を指定)することをお薦めします。

locale-determine-rule

このセクションでは、優先ユーザー・ロケールの判別順序を定義します。ロケール・ソースは、アプリケーションでの使用例に基づいて指定する必要があります。このセクションでの使用例は、次のとおりです。

- 使用例1: GDKフレームワークは常に許容言語を使用します。

<locale-source>oracle.i18n.servlet.localesource.HTTPAcceptLanguage</locale-source>

- 使用例2: デフォルトでは、GDKフレームワークは許容言語を使用します。ユーザーがロケールを指定すると、そのロケールが以降の操作に使用されます。

<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HTTPAcceptLanguage</locale-source>

- 使用例3: デフォルトでは、GDKフレームワークは許容言語を使用します。ユーザーの認証後、GDKフレームワークはデータベースのロケール・ソースを使用します。データベースのロケール・ソースは、ユーザーがログアウトするまでキャッシュに残ります。ユーザーがログアウトした後は、再び許容言語が使用されます。

<db-locale-source
data-source-name="jdbc/OracleCoreDS"
locale-source-table="customer"
user-column="customer_email"
user-key="userid"
language-column="nls_language"
territory-column="nls_territory"
timezone-column="timezone"
>oracle.i18n.servlet.localesource.DBLocaleSource</db-locale-source>
<locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage</locale-source>

使用例3には、事前定義済のデータベース・ロケール・ソースDBLocaleSourceが含まれていることに注意してください。これにより、カスタムのデータベース・ロケール・ソースを記述せずに、構成ファイル内でユーザー・プロファイル情報を指定できます。この例では、ユーザー・プロファイル表は"customer"です。列は、"customer_email"、"nls_language"、"nls_territory"および"timezone"です。各列には、一意の電子メール・アドレス、使用言語のOracle名、使用地域のOracle名およびユーザーのタイム・ゾーンIDが格納されます。user-keyは必須属性で、アプリケーションからGDKフレームワークにユーザーIDを渡すために使用する属性名を指定します。

- 使用例4: GDKフレームワークは最初のページに許容言語を使用します。ユーザーがロケールを入力すると、そのロケールがキャッシュされ、ユーザーがアプリケーションにログインするまで使用されます。ユーザーの認証後、GDKフレームワークはデータベースのロケール・ソースを使用します。データベースのロケール・ソースは、ユーザーがログアウトするまでキャッシュに残ります。ユーザーがログアウトした後は、再び許容言語が使用されるか、ユーザーがロケールを入力するとユーザー入力が使用されます。

<locale-source>demo.DatabaseLocaleSource</locale-source>
<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage</locale-source>

使用例4では、カスタムのデータベース・ロケール・ソースを使用していることに注意してください。ユーザー・プロファイル情報が複数の表にわかれている場合など、ユーザー・プロファイル・スキーマが複雑な場合は、アプリケーションがカスタムのロケール・ソースを提供する必要があります。カスタム・ロケール・ソースの例は、$ORACLE_HOME/nls/gdk/demoディレクトリにあります。

locale-parameter-name

このタグでは、現行のユーザー・ロケールをリクエスト間で渡すことができるように、ユーザー入力で使用されるロケール・パラメータの名前を定義します。

表8-3に、GDKフレームワークで使用されるパラメータを示します。

表8-3 GDKフレームワークで使用されるロケール・パラメータ

デフォルトのパラメータ名

値

locale

ISOロケール。ISO 639の言語コードとISO 3166の国コードをアンダースコア(_)またはハイフン(-)でつないだものです。たとえば、中国で使用される簡体字中国語の場合はzh_CNとなります。

language

Oracleの言語名。たとえば、米英語の場合はAMERICANです。

territory

Oracleの地域名。たとえば、SPAINです。

timezone

タイム・ゾーン名。たとえば、American/Los_Angelesです。

iso-currency

ISO 4217の通貨コード。たとえば、ユーロの場合はEURです。

date-format

日付書式のパターン・マスク。たとえば、DD_MON_RRRRです。

long-date-format

長い日付書式のパターン・マスク。たとえば、DAY-YYY-MM-DDです。

date-time-format

日時書式のパターン・マスク。たとえば、DD-MON-RRRR HH24:MI:SSです。

long-date-time-format

長い日時書式のパターン・マスク。たとえば、DAY YYYY-MM-DD HH12:MI:SS AMです。

time-format

時刻書式のパターン・マスク。たとえば、HH:MI:SSです。

number-format

数値書式。たとえば、9G99G990D00です。

currency-format

通貨書式。たとえば、L9G99G990D00です。

linguistic-sorting

言語ソート順序名。たとえば、日本語の多言語ソートの場合はJAPANESE_Mです。

charset

キャラクタ・セット。たとえば、WE8ISO8859P15です。

writing-direction

書込み方向を示す文字列。たとえば、左から右への書込み方向の場合はLTR、右から左への書込み方向の場合はRTLです。

command

GDKコマンド。たとえば、更新操作の場合はstoreです。

各パラメータ名は、HTMLフォームまたはURLでパラメータに使用されます。

message-bundles

このタグでは、アプリケーションで使用されるリソース・バンドルのベース・クラス名を定義します。マッピングは、リソース・バンドル内の翻訳済テキストを検索するLocalizer.getMessageメソッドに使用されます。

<message-bundles>
<resource-bundle>Messages</resource-bundle>
<resource-bundle name="newresource">NewMessages</resource-bundle>
</message-bundles>

<resource-bundle>タグにname属性を指定しない場合、またはname="default"として指定した場合は、対応するリソース・バンドルがデフォルトのメッセージ・バンドルとして使用されます。アプリケーションで複数のリソース・バンドルをサポートするには、デフォルト以外のリソース・バンドルにリソース・バンドル名を割り当てる必要があります。デフォルト以外のバンドル名は、getMessageメソッドのパラメータとして渡してください。

次に例を示します。

Localizer loc = ServletHelper.getLocalizerInstance(request);
String translatedMessage = loc.getMessage("Hello");
String translatedMessage2 = loc.getMessage("World", "newresource");

url-rewrite-rule

このタグは、URL書換え操作の動作を制御するために使用されます。書換え規則は正規表現です。

<url-rewrite-rule fallback="no">
<pattern>(.*)/([^/]+)$</pattern>
<result>$1/$L/$2</result>
</url-rewrite-rule>

関連項目:
「GDKでのローカライズされたコンテンツの管理」

リクエストされたロケールについてローカライズされたコンテンツが使用できない場合、GDKフレームワークは最も近い翻訳ロケールにマップして、ロケール代替メカニズムをトリガーできます。デフォルトでは、代替オプションはオフに設定されます。fallback="yes"を指定すると、このオプションをオンに設定できます。

たとえば、アプリケーションでサポートされている翻訳がen、deおよびjaのみで、enがアプリケーションのデフォルト・ロケールであるとします。現行のアプリケーション・ロケールがde-USの場合は、かわりにdeが使用されます。ユーザーがアプリケーション・ロケールとしてzh-TWを選択すると、かわりにenが使用されます。

サポートされているアプリケーション・ロケールの数が翻訳ロケール数よりも多い場合は、通常、代替メカニズムが必要になります。この代替が発生するのは、一般に複数のロケールが1つの翻訳を共有している場合です。その一例がスペイン語です。アプリケーションは、スペインのみでなくスペイン語圏の複数の国を1組の翻訳ファイルでサポートする必要がある場合があります。

デフォルト以外のURL書換え規則に名前属性を割り当てると、複数のURL書換え規則を指定できます。デフォルト以外のURL書換え規則を使用するには、その規則名をrewriteURLメソッドのパラメータとして渡す必要があります。次に例を示します。

<img src="<%=ServletHelper.rewriteURL("images/welcome.gif", request) %>">
<img src="<%=ServletHelper.rewriteURL("US.gif", "flag", request) %>">

最初の規則では、"images/welcome.gif"のURLがローカライズされたwelcomeイメージ・ファイルに変更されます。第2の規則"flag"では、"US.gif"のURLがユーザーの国旗のイメージ・ファイルに変更されます。規則は次のように定義する必要があります。

<url-rewrite-rule fallback="yes">
<pattern>(.*)/([^/]+)$</pattern>
<result>$1/$L/$2</result>
</url-rewrite-rule>
<url-rewrite-rule name="flag">
<pattern>US.gif/pattern>
<result>$C.gif</result>
</url-rewrite-rule>

例: GDKアプリケーション構成ファイル

この項では、次のアプリケーション・プロパティを使用してアプリケーション構成ファイルの例を示します。

- アプリケーションでサポートしているロケールは、アラビア語(ar)、ギリシャ語(el)、英語(en)、ドイツ語(de)、フランス語(fr)、日本語(ja)および中国の簡体字中国語(zh-CN)です。

- 英語がデフォルトのアプリケーション・ロケールです。

- jaロケールのページ・キャラクタ・セットは常にUTF-8です。

- Internet Explorerクライアント使用時の、enおよびdeロケールのページ・キャラクタ・セットはwindows-1252です。

- 他のWebブラウザ・クライアントでのen、deおよびfrロケールのページ・キャラクタ・セットはiso-8859-1です。

- 他のすべてのロケールのページ・キャラクタ・セットは、そのロケールのデフォルトのキャラクタ・セットです。

- ユーザー・ロケールは、ユーザー入力ロケール、Accept-Languageの順に判別されます。

- ローカライズされたコンテンツは、該当言語のサブフォルダに格納されます。フォルダ名は、ISO 639の言語コードから導出されます。各フォルダは、アプリケーションのルート・ディレクトリにあります。たとえば、/shop/welcome.jpgの日本語ファイルは/ja/shop/welcome.jpgに格納されます。

<?xml version="1.0" encoding="utf-8"?>
<gdkapp
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="gdkapp.xsd">
<!-- Language to Character set mapping -->
<locale-charset-maps>
<locale-charset>
<locale>ja</locale>
<charset>UTF-8</charset>
</locale-charset>
<locale-charset>
<locale>en,de</locale>
<user-agent>^Mozilla\/[0-9\. ]+\(compatible; MSIE [^;]+; \)</user-agent>
<charset>WINDOWS-1252</charset>
</locale-charset>
<locale-charset>
<locale>en,de,fr</locale>
<charset>ISO-8859-1</charset>
</locale-charset>
</locale-charset-maps>

<!-- Application Configurations -->
<page-charset>AUTO-CHARSET</page-charset>
<application-locales>
<locale>ar</locale>
<locale>de</locale>
<locale>fr</locale>
<locale>ja</locale>
<locale>el</locale>
<locale default="yes">en</locale>
<locale>zh-CN</locale>
</application-locales>
<locale-determine-rule>
<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage</locale-source>
</locale-determine-rule>
<!-- URL rewriting rule -->
<url-rewrite-rule fallback="no">
<pattern>(.*)/([^/]+)$</pattern>
<result>/$L/$1/$2</result>
</url-rewrite-rule>
</gdkapp>

Java用GDK提供のパッケージおよびクラス

Oracle Globalization Services for Javaには、次のパッケージが含まれています。

- oracle.i18n.lcsd

- oracle.i18n.net

- oracle.i18n.servlet

- oracle.i18n.text

- oracle.i18n.util

関連項目:
『Oracle Globalization Development Kit Java API Reference』

oracle.i18n.lcsd

oracle.i18n.lcsdパッケージは、テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出して認識するクラスを提供します。プレーン・テキスト・ファイルとHTMLファイルの両方の検出がサポートされます。言語はISOに基づき、エンコーディングはIANAまたはOracleキャラクタ・セットに基づきます。このパッケージには次のクラスがあります。

- LCSDetector: テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出して認識するメソッドが含まれています。

- LCSDResultSet: LCSDResultSetクラスは、LCSDetectorにより生成される結果の格納用です。このクラスのメソッドを使用すると、結果から特定の情報を取り出すことができます。

- LCSDetectionInputStream: ストリーム・オブジェクトの言語およびエンコーディングを透過的に検出します。

- LCSDetectionReader: 入力データの言語およびエンコーディングを透過的に検出し、Unicodeに変換します。

- LCSDetectionHTMLInputStream: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionInputStreamクラスを拡張します。

- LCSDetectionHTMLReader: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionReaderクラスを拡張します。

oracle.i18n.net

oracle.i18n.netパッケージは、グローバリゼーションのためのインターネット関連のデータ変換を提供します。このパッケージには次のクラスがあります。

- CharEntityReference: 文字列を文字参照形式または実体参照形式との間でエスケープまたはアンエスケープするためのユーティリティ・クラスです。

- CharEntityReference.Form: エスケープ形式を指定するフォーム・パラメータ・クラスです。

oracle.i18n.servlet

oracle.i18n.Servletパッケージは、JSPおよびJavaサーブレットで自動ロケールのサポートを可能にし、ローカライズされたコンテンツをアプリケーションに返します。このパッケージには次のクラスがあります。

- ApplicationContext: フレームワークでアプリケーション・スコープ操作を制御するアプリケーション・コンテキスト・クラスです。

- Localizer: 最も一般に使用されるグローバリゼーション情報へのアクセスを可能にするオールインワン・オブジェクト・クラスです。

- ServletHelper: Java Servletとグローバリゼーション・オブジェクト間を結ぶ委譲クラスです。

oracle.i18n.text

oracle.i18n.textパッケージは、汎用的なテキスト・データ・グローバリゼーション・サポートを提供します。このパッケージには次のクラスがあります。

- OraCollationKey: 特定のOraCollatorオブジェクトの特定の規則に基づくStringを表すクラスです。

- OraCollator: 言語照合やバイナリ・ソートなど、ロケール依存の文字列比較を実行するクラスです。

- OraDateFormat: 日時と文字列のロケール間で書式指定と解析を行う抽象クラスです。Oracleの日時の書式設定の動作をサポートします。

- OraDecimalFormat: 数値と文字列のロケール間で書式指定と解析を行う具象クラスです。Oracleの数値の書式設定の動作をサポートします。

- OraDecimalFormatSymbol: Oracleの数値書式と通貨書式に使用されるOracleの書式記号を維持するクラスです。

- OraNumberFormat: 数値と文字列のロケール間で書式指定と解析を行う抽象クラスです。Oracleの数値の書式設定の動作をサポートします。

- OraSimpleDateFormat: 日時と文字列のロケール間で書式指定と解析を行う具象クラスです。Oracleの日時の書式設定の動作をサポートします。

oracle.i18n.util

oracle.i18n.utilパッケージは、グローバリゼーション・サポート用の汎用ユーティリティを提供します。このパッケージには次のクラスがあります。

- LocaleMapper: Oracleのロケール要素と他のベンダーおよび規格の等価ロケール要素の間のマッピングを提供します。

- OraDisplayLocaleInfo: ロケールと属性の翻訳を提供する翻訳ユーティリティ・クラスです。

- OraLocaleInfo: 言語、地域およびCollatorオブジェクトを含むOracleロケール・クラスです。

- OraSQLUtil: SQLを処理する便利なメソッドを含むOracle SQL Utilityクラスです。

PL/SQL用GDK提供のパッケージ

PL/SQL用GDKには、次のPL/SQLパッケージが含まれています。

- UTL_I18N

- UTL_LMS

UTL_I18Nは、開発者が国際化されたアプリケーションを構築する際に役立つPL/SQLサービスのセットです。UTL_I18N PL/SQLパッケージは、次のファンクションを提供します。

- 各種データ型の文字列変換ファンクション

- HTMLおよびXML文書で使用される事前定義済の文字とマルチバイト・キャラクタのエスケープ・シーケンスとアンエスケープ・シーケンス

- Oracle、Internet Assigned Numbers Authority(IANA)、ISOおよび電子メール・アプリケーションのキャラクタ・セット、言語および地域間でマップするファンクション

- Oracle言語名からOracleキャラクタ・セット名を戻すファンクション

- スクリプトの文字変換を実行するファンクション

- 特定の地域に対してサポートされているISO通貨コード、ローカル・タイム・ゾーンおよびローカル言語を戻すファンクション

- 特定の言語に対してサポートされている最も一般的な言語ソート、使用可能なすべての言語ソートのリストおよびローカル地域を戻すファンクション

- Oracleのフル言語名と短縮言語名間をマップするファンクション

- 特定の言語および地域名の言語翻訳を戻すファンクション

- 最も一般的なタイム・ゾーンのリストを戻すファンクション

UTL_LMSは、様々な言語でエラー・メッセージを取り出して書式指定します。

関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

GDKエラー・メッセージ

GDK-03001: 無効またはサポートされていないソート・ルールです

原因: 指定されたソート・ルール名が無効か、またはサポートされていません。

処置: 有効なソート・ルール名を選択してください。また、ソート・ルール名のリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

GDK-03002: 関数ドリブンのソートはサポートされていません。

原因: 関数ドリブン・ソート・ルール名が指定されました。

処置: 有効なソート・ルール名を選択してください。また、ソート・ルール名のリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

GDK-03003: 言語データファイルがありません。

原因: 有効なソート・ルールが指定されましたが、関連データファイルが見つかりません。

処置: GDKのjarファイルがJavaアプリケーションに正しくインストールされているかどうかを確認してください。

GDK-03005 指定されたキャラクタ・セットでは、バイナリ・ソートは使用できません。

原因: 指定されたキャラクタ・セットのバイナリ・ソートはサポートされていません。

処置: バイナリ・ソートをサポートするキャラクタ・セットについては、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

GDK-03006 比較強調レベルが無効です

原因: 無効な比較強調レベルが指定されました。

処置: リストから有効な比較強調レベルであるPRIMARY、SECONDARYまたはTERTIARYを選択してください。

GDK-03007 合成レベル設定が無効です。

原因: 無効な合成レベル設定が指定されました。

処置: リストから有効な合成レベルとしてNO_COMPOSITIONまたはCANONICAL_COMPOSITIONを選択してください。

GDK-04001: OracleキャラクタをUnicodeにマップできません

原因: プログラムは、UnicodeにマップできないOracleキャラクタ・セットの文字を使用しようとしました。

処置: 無効な文字に使用する別の例外ハンドラを記述するか、無効な文字を有効な置換文字で置換できるようにwithReplacementメソッドをコールしてください。

GDK-04002: UnicodeをOracleキャラクタにマップできません

原因: プログラムは、Oracleキャラクタ・セットの文字にマップできないUnicode文字を使用しようとしました。

処置: 無効な文字に使用する別の例外ハンドラを記述するか、無効な文字を有効な置換文字で置換できるようにwithReplacementメソッドをコールしてください。

GDK-05000 日付書式のリテラルが長すぎます。

原因: 日付書式で指定された文字列リテラルが長すぎます。

処置: 日付書式には、より短い文字列リテラルを使用してください。

GDK-05001 日付書式が内部バッファに対して長すぎます。

原因: 日付書式パターンが長すぎます。

処置: より短い日付書式パターンを使用してください。

GDK-05002 ユリウス日の指定が有効範囲を超えています。

原因: 無効な日付範囲が指定されました。

処置: 日付が指定した範囲0から3439760内にあるかどうかを確認してください。

GDK-05003: 日付/時間の取得でエラーが発生しました

原因: これは内部エラーです。

処置: Oracleサポート・サービスに連絡してください。

GDK-05010: 重複する書式コードが指定されています

原因: 書式パターンに同じ書式コードが2回以上使用されています。

処置: 重複する書式コードを削除してください。

GDK-05011 ユリウス日と年間通算日は混在できません。

原因: ユリウス日と年間通算日の両方が指定されました。

処置: ユリウス日または年間通算日のどちらか一方を削除してください。

GDK-05012 年は1度のみ指定できます。

原因: 年の書式コードが2回以上指定されました。

処置: 重複する年の書式コードを削除してください。

GDK-05013 時は1度のみ指定できます。

原因: 時間の書式コードが2回以上指定されました。

処置: 重複する時間書式コードを削除してください。

GDK-05014: AM/PMとA.M./P.M.は混在できません

原因: A.M./P.M.とともにAM/PMが指定されました。

処置: AM/PMまたはA.M./P.M.のどちらか一方を使用します。両方を使用しないでください。

GDK-05015: BC/ADとB.C./A.D.は混在できません

原因: B.C./A.D.とともにBC/ADが指定されました。

処置: BC/ADまたはB.C./A.D.のどちらか一方を使用します。両方を使用しないでください。

GDK-05016: 重複する月が指定されています

原因: 月の書式コードが2回以上指定されました。

処置: 重複する月の書式コードを削除してください。

GDK-05017 曜日は1度のみ指定できます。

原因: 曜日の書式コードが2回以上指定されました。

処置: 重複する曜日の書式コードを削除してください。

GDK-05018 24時間表示とAM/PMは混在できません。

原因: AM/PMとともに24時間表示が指定されました。

処置: 24時間表示またはAM/PM付き12時間表示のどちらか一方を使用します。

GDK-05019 符号付き年とBC/ADは混在できません。

原因: BC/ADとともに符号付き年が指定されました。

処置: 符号付き年または符号なしBC/AD付きの年のどちらか一方を使用してください。

GDK-05020 日付入力書式に含まれている書式コードが無効です。

原因: 日付入力書式に書式コードが使用されています。

処置: 書式コードを削除してください。

GDK-05021: 日付書式コードが無効です

原因: サポートされていない書式コードが指定されました。

処置: 書式コードを修正してください。

GDK-05022 年代書式コードがこのカレンダでは無効です。

原因: カレンダに無効な年代書式コードが指定されました。

処置: 年代書式コードを削除するか、年代をサポートする別のカレンダを使用してください。

GDK-05030 日付書式の変換で不要なデータが含まれています。

原因: 不完全な日付書式パターンが指定されました。

処置: 入力文字列全体を含むように書式パターンを書き換えてください。

GDK-05031 年とユリウス日は混在できません。

原因: ユリウス日に対して互換性のない年が指定されました。

処置: ユリウス日と年が混在していないかどうかを確認してください。

GDK-05032 年間通算日とユリウス日は混在できません。

原因: ユリウス日に対して互換性のない年間通算日が指定されました。

処置: ユリウス日と年間通算日が混在していないかどうかを確認してください。

GDK-05033 月とユリウス日は混在できません。

原因: ユリウス日に対して互換性のない月が指定されました。

処置: ユリウス日と月が混在していないかどうかを確認してください。

GDK-05034 月単位の日付とユリウス日は混在できません。

原因: ユリウス日に対して互換性のない月単位の日付が指定されました。

処置: ユリウス日と月単位の日付が混在していないかどうかを確認してください。

GDK-05035 曜日とユリウス日は混在できません。

原因: ユリウス日に対して互換性のない曜日が指定されました。

処置: ユリウス日と曜日が混在していないかどうかを確認してください。

GDK-05036 時と日単位の秒が一致していません。

原因: 指定された時と日単位の秒に互換性がありません。

処置: 時と日単位の秒が矛盾しないかどうかを確認してください。

GDK-05037 時単位の分と日単位の秒が一致していません。

原因: 指定された時単位の分と日単位の秒に互換性がありません。

処置: 時単位の分と日単位の秒が矛盾しないかどうかを確認してください。

GDK-05038 分単位の秒と日単位の秒が一致していません。

原因: 指定された分単位の秒と日単位の秒に互換性がありません。

処置: 分単位の秒と日単位の秒が矛盾しないかどうかを確認してください。

GDK-05039: 指定された月に対して日付が無効です

原因: 月に対して無効な日付が指定されました。

処置: 月の日付範囲を確認してください。

GDK-05040: 入力した値の長さが日付書式に対して不足しています

原因: 指定された書式コードが多すぎます。

処置: 不要な書式コードを削除するか、より長い値を指定してください。

GDK-05041 周年は-4713と+9999の間の0以外の数字を指定する必要があります

原因: 無効な年が指定されました。

処置: 指定された範囲内の年を指定してください。

GDK-05042: 四半期は1から4の間で指定する必要があります。

原因: 無効な四半期が指定されました。

処置: 四半期が指定の範囲内にあるかどうかを確認してください。

GDK-05043: 指定した月が無効です

原因: 無効な月が指定されました。

処置: 月が1から12であるか、または有効な月名であるかどうかを確認してください。

GDK-05044: 年単位の週は1から52の間で指定する必要があります。

原因: 無効な年単位の週が指定されました。

処置: 年単位の週が指定の範囲内にあるかどうかを確認してください。

GDK-05045: 月単位の週は1から5の間で指定する必要があります。

原因: 無効な月単位の週が指定されました。

処置: 月単位の週が指定の範囲内にあるかどうかを確認してください。

GDK-05046: 指定した曜日が無効です

原因: 無効な曜日が指定されました。

処置: 曜日が1から7であるか、または有効な曜日名であるかどうかを確認してください。

GDK-05047 月単位の日付は1から月末日の間で指定する必要があります。

原因: 無効な月単位の日付が指定されました。

処置: 月単位の日付が指定の範囲内にあるかどうかを確認してください。

GDK-05048 年単位の日付は1から365(うるう年は366)の間で指定する必要があります。

原因: 無効な年単位の日付が指定されました。

処置: 年単位の日付が指定の範囲内にあるかどうかを確認してください。

GDK-05049: 時は1から12の間で指定する必要があります。

原因: 無効な時が指定されました。

処置: 時が指定の範囲内にあるかどうかを確認してください。

GDK-05050: 時は0から23の間で指定する必要があります。

原因: 無効な時が指定されました。

処置: 時が指定の範囲内にあるかどうかを確認してください。

GDK-05051: 分は0から59の間で指定する必要があります。

原因: 無効な分が指定されました。

処置: 分が指定の範囲内にあるかどうかを確認してください。

GDK-05052: 秒は0から59の間で指定する必要があります。

原因: 無効な秒が指定されました。

処置: 秒が指定の範囲内にあるかどうかを確認してください。

GDK-05053: 日単位の秒は0から86399の間で指定する必要があります。

原因: 無効な日単位の秒が指定されました。

処置: 日単位の秒が指定の範囲内にあるかどうかを確認してください。

GDK-05054: ユリウス日は1から5373484の間で指定する必要があります。

原因: 無効なユリウス日が指定されました。

処置: ユリウス日が指定の範囲内にあるかどうかを確認してください。

GDK-05055: AM/A.M.やPM/P.M.がありません。

原因: 書式パターンにAM/A.M.もPM/P.M.も指定されていません。

処置: AM/A.M.またはPM/P.M.を指定してください。

GDK-05056: BC/B.C.やAD/A.D.がありません。

原因: 書式パターンにBC/B.C.もAD/A.D.も指定されていません。

処置: BC/B.C.またはAD/A.D.を指定してください。

GDK-05057: タイムゾーン・コードが無効です

原因: 無効なタイムゾーン・コードが指定されました。

処置: 有効なタイムゾーン・コードを指定してください。

GDK-05058: 数値以外の文字が指定されています

原因: 数値が必要ですが、数値以外の文字が見つかりました。

処置: 文字が数値かどうかを確認してください。

GDK-05059: アルファベット以外の文字が指定されています

原因: アルファベットが必要ですが、アルファベット以外の文字が見つかりました。

処置: 文字がアルファベットかどうかを確認してください。

GDK-05060: 年単位の週は1から53の間で指定する必要があります。

原因: 無効な年単位の週が指定されました。

処置: 年単位の週が指定の範囲内にあるかどうかを確認してください。

GDK-05061 リテラルが書式文字列と一致しません。

原因: 入力の文字列リテラルの長さが、書式パターンのリテラルと(先行の空白を除き)異なります。

処置: 書式パターンをリテラルにあわせて修正してください。FX修飾子がオンになっている場合、リテラルは余分な空白なしで正確に一致する必要があります。

GDK-05062 桁数がこの書式項目と一致しません。

原因: 桁数が書式項目の長さと一致しません。

処置: 入力日付を修正するか、FXまたはFM書式修飾子をオフにしてください。入力日付にFXまたはFM書式コードが指定されている場合、桁数は書式コードで指定された数と正確に一致する必要があります。たとえば、9は書式コードDDと一致しませんが、09は一致します。

GDK-05063 この年は現行カレンダではサポートされていません。

原因: 現行のカレンダでサポートされない年が指定されました。

処置: 現行のカレンダでサポートされる年については、『Oracle Databaseグローバリゼーション・サポート・ガイド』で確認してください。

GDK-05064 指定した日付はカレンダの有効範囲外です。

原因: 指定された日付はカレンダの有効範囲外です。

処置: カレンダで有効な日付を指定してください。

GDK-05065: 年代が無効です

原因: 無効な年代が指定されました。

処置: 年代が有効かどうかを確認してください。

GDK-05066 日付時間クラスが無効です。

原因: これは内部エラーです。

処置: Oracleサポート・サービスに連絡してください。

GDK-05067 間隔が無効です。

原因: 無効な間隔が指定されました。

処置: 有効な間隔を指定してください。

GDK-05068 間隔の先行精度が小さすぎます。

原因: 間隔に指定された先行精度が小さすぎて、間隔を格納できません。

処置: 間隔の先行精度を大きくするか、小さい先行精度を使用して間隔を指定してください。

GDK-05069: 今後使用予定の予約番号

原因: 予約済。

処置: 予約済。

GDK-05070 指定された間隔と日付時間は互いに比較できません。

原因: 指定された間隔と日付時間は互いに比較できません。

処置: 互いに比較できる間隔または日付時間のペアを指定してください。

GDK-05071: 秒数は60より小さい必要があります。

原因: 60以上の秒数が指定されました。

処置: 秒数には59以下の値を指定してください。

GDK-05072: 今後使用予定の予約番号

原因: 予約済。

処置: 予約済。

GDK-05073 間隔の先行精度が小さすぎます。

原因: 間隔に指定された先行精度が小さすぎて、間隔を格納できません。

処置: 間隔の先行精度を大きくするか、小さい先行精度を使用して間隔を指定してください。

GDK-05074 無効なタイムゾーンの時間が指定されました。

原因: タイムゾーンの時間は-12から13である必要があります。

処置: -12から13の範囲内でタイムゾーンの時間を指定してください。

GDK-05075 無効なタイムゾーンの分が指定されました。

原因: タイムゾーンの分は0から59である必要があります。

処置: 0から59の範囲内でタイムゾーンの分を指定してください。

GDK-05076 無効な年が指定されました。

原因: 年は-4713以上である必要があります。

処置: -4713以上の年を指定してください。

GDK-05077 内部バッファに対して文字列が長すぎます。

原因: これは内部エラーです。

処置: Oracleサポート・サービスに連絡してください。

GDK-05078 指定したフィールドが日付時間または間隔で見つかりません

原因: 指定されたフィールドが日付時間または間隔内で見つかりませんでした。

処置: 指定したフィールドが日付時間または間隔内にあるかどうかを確認してください。

GDK-05079 無効なhh25フィールドが指定されました。

原因: hh25フィールドは0から24である必要があります。

処置: 0から24の範囲内でhh25フィールドを指定してください。

GDK-05080 無効な小数秒が指定されました。

原因: 小数秒は0から999999999である必要があります。

処置: 0から999999999の範囲内で小数秒の値を指定してください。

GDK-05081 無効なタイムゾーンのリージョンIDが指定されました。

原因: 指定されたタイムゾーンのリージョンIDは無効です。

処置: Oracleサポート・サービスに連絡してください。

GDK-05082: タイムゾーンのリージョン名が見つかりません

原因: 指定されたリージョン名が見つかりません。

処置: Oracleサポート・サービスに連絡してください。

GDK-05083: 今後使用予定の予約番号

原因: 予約済。

処置: 予約済。

GDK-05084: 内部の書式設定エラーです

原因: これは内部エラーです。

処置: Oracleサポート・サービスに連絡してください。

GDK-05085: オブジェクト型が無効です

原因: 無効なオブジェクト型が指定されました。

処置: サポートされているオブジェクト型を使用してください。

GDK-05086: 日付の書式スタイルが無効です

原因: 無効な書式スタイルが指定されました。

処置: 有効な書式スタイルを選択してください。

GDK-05087 NULLの書式パターンが指定されました。

原因: NULLの書式パターンは指定できません。

処置: 有効な書式パターンを指定してください。

GDK-05088: 数値書式モデルが無効です

原因: 無効な数値書式コードが指定されました。

処置: 数値書式コードを修正してください。

GDK-05089: 数値が無効です

原因: 無効な数値が指定されました。

処置: 入力を修正してください。

GDK-05090: 今後使用予定の予約番号

原因: 予約済。

処置: 予約済。

GDK-0509: 日付時間/間隔の内部エラーです

原因: これは内部エラーです。

処置: Oracleサポート・サービスに連絡してください。

GDK-05098: 精度指定子が多すぎます

原因: プログラムは日付を切捨てまたは丸めようとしましたが、日付書式パターンに余分なデータが見つかりました。

処置: 日付書式パターンの構文を確認してください。

GDK-05099: 指定した精度が無効です

原因: 無効な精度指定子が指定されました。

処置: 有効な精度指定子を使用してください。

GDK-05200: WE8ISO8859P1データファイルがありません

原因: WE8ISO8859P1のキャラクタ・セット・データファイルがインストールされていません。

処置: GDKのjarファイルがJavaアプリケーションに正しくインストールされているかどうかを確認してください。

GDK-05201: 16進値への変換に失敗しました

原因: HTML/XMLデータに無効な16進文字列が含まれていました。

処置: 文字列に&x[0-9A-Fa-f]+;形式の16進値が含まれているかどうかを確認してください。

GDK-05202: 10進値への変換に失敗しました

原因: HTML/XMLデータに無効な10進文字列が見つかりました。

処置: 文字列に&[0-9]+;形式の10進値が含まれているかどうかを確認してください。

GDK-05203: 未登録のキャラクタ・エンティティです

原因: HTML/XMLデータに無効なキャラクタ・エンティティが見つかりました。

処置: HTML/XMLデータに有効なキャラクタ・エンティティを使用してください。登録済の文字エンティティについては、HTML/XML規格を参照してください。

GDK-05204: Quoted-Printableの値が無効です

原因: データに無効なQuoted-Printableデータが見つかりました。

処置: 入力データが正しいQuoted-Printable形式でエンコードされているかどうかを確認してください。

GDK-05205: MIMEヘッダーの書式が無効です

原因: 無効なMIMEヘッダーの書式が指定されました。

処置: MIMEヘッダーの書式についてはRFC 2047を参照してください。入力データがその形式に準拠しているかどうかを確認してください。

GDK-05206: 数値の書式が無効です

原因: URLのデコード中に%FF形式の無効な文字が見つかりました。

処置: 入力のURL文字列が有効で、正しくエンコードされているかどうかを確認してください。%FFは有効な16進数にする必要があります。

GDK-05207: キャラクタ・セット・マッピングに対するユーザー定義のロケールにおいて、オブジェクト、キーのクラスが無効です

原因: ユーザー定義ロケールからキャラクタ・セットへのマッピング表で、keyオブジェクトのクラスがjava.util.Localeではありません。

処置: ユーザー定義ロケールからキャラクタ・セットへのマッピング表についてMapオブジェクトを構成するときには、keyオブジェクト用にjava.util.Localeを指定してください。

GDK-05208: キャラクタ・セット・マッピングに対するユーザー定義のロケールにおいて、オブジェクト、値のクラスが無効です

原因: ユーザー定義ロケールからキャラクタ・セットへのマッピング表で、valueオブジェクトのクラスがjava.lang.Stringではありません。

処置: ユーザー定義ロケールからキャラクタ・セットへのマッピング表についてMapオブジェクトを構成するときには、valueオブジェクト用にjava.lang.Stringを指定してください。

GDK-05209: リライト規則が無効です

原因: リライト規則で照合パターンに対して無効な正規表現が指定されました。

処置: リライト規則の照合パターンに有効な正規表現を使用しているかどうかを確認してください。

GDK-05210: キャラクタ・セットが無効です

原因: 無効なキャラクタ・セット名が指定されました。

処置: 有効なキャラクタ・セット名を指定してください。

GDK-0521: デフォルトのロケールは、サポートされているロケールとして定義されていません

原因: デフォルトのアプリケーション・ロケールがサポート対象ロケールのリストにありません。

処置: デフォルトのアプリケーション・ロケールをサポート対象ロケールのリストに組み込むか、またはデフォルト・ロケールをリストにあるロケールに変更してください。

GDK-05212 リライト規則は、3つの要素の文字列配列にする必要があります。

原因: リライト規則パラメータが、3つの要素からなる文字列配列ではありません。

処置: リライト規則パラメータが、3つの要素の文字列配列であることを確認してください。最初の要素は正規表現の一致パターンを表し、2番目の要素はServletHelper.rewriteURLのJavaDocで指定された形式の結果パターンを表し、3番目の要素はロケールの代替操作を実行するかどうかを指定するTrueまたはFalseのブール値を表します。

GDK-05213: ユーザー定義のパラメータ名マッピングにおいて、オブジェクト、キーのクラスの型が無効です

原因: ユーザー定義パラメータ名のマッピング表で、keyオブジェクトのクラスがjava.lang.Stringではありません。

処置: ユーザー定義パラメータ名のマッピング表についてMapオブジェクトを構成するときには、keyオブジェクト用にjava.lang.Stringを指定してください。

GDK-05214 ユーザー定義のパラメータ名マッピング内のオブジェクト、値のクラスは、"java.lang.String"の型にする必要があります。

原因: ユーザー定義パラメータ名のマッピング表で、valueオブジェクトのクラスがjava.lang.Stringではありません。

処置: ユーザー定義パラメータ名のマッピング表についてMapオブジェクトを構成するときには、valueオブジェクト用にjava.lang.Stringを指定してください。

GDK-05215 パラメータ名は、[a-z][a-z0-9]*という形式にする必要があります。

原因: パラメータ名に無効な文字が含まれています。

処置: パラメータ名が [a-z][a-z0-9]*形式であるかどうかを確認してください。

GDK-05216 属性"scope"が設定されている場合は、属性"var"の指定が必要です。

原因: タグには"scope"属性が設定されていますが、"var"属性が指定されていません。

処置: 変数名を表す"var"属性を指定してください。

GDK-05217 "message"タグ内には、"param"タグをネストする必要があります。

原因: "param"タグが"message"タグ内にネストされていません。

処置: "param"タグが"message"タグで囲まれているかどうかを確認してください。

GDK-05218 無効な"scope"属性が指定されています。

原因: 無効な"scope"値が指定されました。

処置: 有効範囲として"application"、"session"、"request"または"page"を指定してください。

GDK-05219: 日付の書式スタイルが無効です

原因: 指定された日付書式スタイルは無効です。

処置: 有効な日付書式スタイルとして"default"、"short"または"long"を指定してください。

GDK-05220 対応するOracleキャラクタ・セットが、IANAキャラクタ・セットに存在しません。

原因: サポートされていないIANAキャラクタ・セット名が指定されました。

処置: 対応するOracleキャラクタ・セットがあるIANAキャラクタ・セットを指定してください。

GDK-05221: パラメータ名が無効です

原因: ユーザー定義パラメータのマッピング表で、無効なパラメータ名が指定されました。

処置: 指定したパラメータ名がサポートされているかどうかを確認してください。サポートされているパラメータ名のリストを取得するには、LocaleSource.Parameter.toArrayをコールします。

GDK-05222 ユーザー定義のメッセージ・バンドル・マッピングにおいて、オブジェクト、キーのクラスの型が無効です

原因: ユーザー定義メッセージ・バンドルのマッピング表で、keyオブジェクトのクラスがjava.lang.Stringではありません。

処置: ユーザー定義メッセージ・バンドルのマッピング表についてMapオブジェクトを構成するときには、keyオブジェクト用にjava.lang.Stringを指定してください。

GDK-05223: ユーザー定義のメッセージ・バンドル・マッピングにおいて、オブジェクト、値のクラスの型が無効です

原因: ユーザー定義メッセージ・バンドルのマッピング表で、valueオブジェクトのクラスがjava.lang.Stringではありません。

処置: ユーザー定義メッセージ・バンドルのマッピング表についてMapオブジェクトを構成するときには、valueオブジェクト用にjava.lang.Stringを指定してください。

GDK-05224: ロケール文字列が無効です

原因: GDKアプリケーション構成ファイルで指定されたISOロケール名に、無効な文字が含まれています。

処置: ISOロケール名に有効な文字のみが使用されていることを確認してください。標準的な名前の書式では、ISO 639の言語とISO 3166の国をハイフンでつなぎます。たとえば、米国ではen-USを使用して米英語のロケールを指定します。

GDK-06001: LCSDetectorプロファイルは使用できません

原因: 指定されたプロファイルが見つかりません。

処置: GDKのjarファイルがJavaアプリケーションに正しくインストールされているかどうかを確認してください。

GDK-06002: 無効なIANAキャラクタ・セット名や対応しないOracleの名前が指定されています

原因: 指定されたIANAキャラクタ・セットが無効か、または対応するOracleキャラクタ・セットがありません。

処置: IANAキャラクタ・セットが有効かどうかと、対応するOracleキャラクタ・セットがあるかどうかを確認してください。

GDK-06003: 無効なISO言語名や対応しないOracleの名前が指定されています

原因: 指定されたISO言語が無効か、または対応するOracleの言語がありません。

処置: 指定したISO言語が無効かどうか、または対応するOracleの言語がないかどうかを確認してください。

GDK-06004 キャラクタ・セット・フィルタと言語フィルタは、同時に設定できません。

原因: LCSDetectorオブジェクトでキャラクタ・セット・フィルタと言語フィルタが同時に設定されています。

処置: キャラクタ・セットまたは言語のどちらか一方のみを設定してください。

GDK-06005 異なるデータソースを使用してLCSDetectorで作業するには、再設定する必要があります。

原因: LCSDetectorオブジェクトに異なる型のデータソースが使用される前に、resetメソッドが起動されていません。

処置: LCSDetector.resetをコールしてDetectorをリセットしてから、他の型のデータソースの検出に切り替えてください。

ORA-17154: OracleキャラクタをUnicodeにマップできません

原因: Oracleの文字が無効または不完全で、Unicode値にマップできません。

処置: 無効な文字に使用する別の例外ハンドラを記述するか、無効な文字を有効な置換文字で置換できるようにwithReplacementメソッドをコールしてください。

ORA-17155: UnicodeをOracleキャラクタにマップできません

原因: Unicode文字に対応する文字がOracleキャラクタ・セットにありません。

処置: 無効な文字に使用する別の例外ハンドラを記述するか、無効な文字を有効な置換文字で置換できるようにwithReplacementメソッドをコールしてください。

9 グローバル環境でのSQLとPL/SQLのプログラミング

この章では、グローバリゼーション・サポート環境でのSQLプログラミングに役立つ情報について説明します。この章の内容は、次のとおりです。

- オプションのNLSパラメータを伴うロケール依存のSQL関数

- ロケール依存のその他のSQL関数

- グローバル環境でのSQLとPL/SQLのプログラミングに関するその他のトピック

オプションのNLSパラメータを伴うロケール依存のSQL関数

動作をグローバリゼーション・サポートの規則に依存しているすべてのSQL関数で、NLSパラメータを指定できます。これらの関数は、次のとおりです。

TO_CHAR

TO_DATE

TO_NUMBER

NLS_UPPER

NLS_LOWER

NLS_INITCAP

NLSSORT

これらの関数のNLSパラメータを明示的に指定すると、セッションのNLSパラメータに依存せずに関数を評価できます。この機能は、数字や日付が文字列リテラルとして含まれているSQL文で重要となる場合があります。

たとえば、次の問合せは、日付に対する言語がAMERICANに指定されている場合、正しく評価されます。

SELECT last_name FROM employees WHERE hire_date > '01-JAN-2005';

このような問合せを現行の日付言語に依存しないようにするには、次のような文を使用します。

SELECT last_name FROM employees
WHERE hire_date > TO_DATE('01-JAN-2005','DD-MON-YYYY',
'NLS_DATE_LANGUAGE = AMERICAN');

このようにして、セッションの言語に依存しないSQL文を、必要に応じて定義できます。文字列リテラルが、ビュー、CHECK制約またはトリガー内のSQL文にある場合には、このような文の指定が必要となる場合があります。

注意:
ロケール依存のSQL関数でオプションのNLSパラメータを明示的に指定する必要があるのは、セッションのNLSパラメータ値に依存しない必要があるSQL文のみです。通常、SQL関数でNLSパラメータにセッションのデフォルト値を使用するほうが、パフォーマンスが改善されます。

すべての文字関数は、シングルバイトとマルチバイトの両方の文字をサポートします。単位を明示的に示した場合を除いて、文字関数は、バイト単位ではなく文字単位で動作します。

これ以降の内容は、次のとおりです。

- SQL関数のNLSパラメータのデフォルト値

- SQL関数のNLSパラメータの指定

- SQL関数で受け入れられないNLSパラメータ

SQL関数のNLSパラメータのデフォルト値

SQL関数でビューやトリガーが評価される場合、NLS関数パラメータには現行のセッションからのデフォルト値が使用されます。SQL関数でCHECK制約が評価される場合は、データベースの作成時にNLSパラメータに指定されたデフォルト値が使用されます。

SQL関数のNLSパラメータの指定

NLSパラメータは、SQL関数で次のように指定できます。

'parameter = value'

次に例を示します。

'NLS_DATE_LANGUAGE = AMERICAN'

SQL関数では、次のNLSパラメータを指定できます。

NLS_DATE_LANGUAGE

NLS_NUMERIC_CHARACTERS

NLS_CURRENCY

NLS_ISO_CURRENCY

NLS_DUAL_CURRENCY

NLS_CALENDAR

NLS_SORT

表9-1に、特定のSQL関数に有効なNLSパラメータを示します。

表9-1 SQL関数と有効なNLSパラメータ

SQL関数

有効なNLSパラメータ

TO_DATE

NLS_DATE_LANGUAGE NLS_CALENDAR

TO_NUMBER

NLS_NUMERIC_CHARACTERS NLS_CURRENCY NLS_DUAL_CURRENCY NLS_ISO_CURRENCY

TO_CHAR

NLS_DATE_LANGUAGE NLS_NUMERIC_CHARACTERS NLS_CURRENCY NLS_ISO_CURRENCY NLS_DUAL_CURRENCY NLS_CALENDAR

TO_NCHAR

NLS_DATE_LANGUAGE NLS_NUMERIC_CHARACTERS NLS_CURRENCY NLS_ISO_CURRENCY NLS_DUAL_CURRENCY NLS_CALENDAR

NLS_UPPER

NLS_SORT

NLS_LOWER

NLS_SORT

NLS_INITCAP

NLS_SORT

NLSSORT

NLS_SORT

次の例に、SQL関数でNLSパラメータを使用する方法を示します。

TO_DATE ('1-JAN-99', 'DD-MON-YY',
'nls_date_language = American')

TO_CHAR (hire_date, 'DD/MON/YYYY',
'nls_date_language = French')

TO_CHAR (SYSDATE, 'DD/MON/YYYY',
'nls_date_language=''Traditional Chinese'' ')

TO_NUMBER ('13.000,00', '99G999D99',
'nls_numeric_characters = '',.''')

TO_CHAR (salary, '9G999D99L', 'nls_numeric_characters = '',.''
nls_currency = ''EUR''')

TO_CHAR (salary, '9G999D99C', 'nls_numeric_characters = ''.,''
nls_iso_currency = Japan')

NLS_UPPER (last_name, 'nls_sort = Swiss')

NLSSORT (last_name, 'nls_sort = German')

注意:
一部の言語では、様々な小文字が複数の大文字に、またはその逆に対応する場合もあります。その結果、NLS_UPPER、NLS_LOWERおよびNLS_INITCAP関数の出力の長さが入力の長さと異なる場合があります。

関連項目:

- 「特殊な大文字」

- 「特殊な小文字」

SQL関数で受け入れられないNLSパラメータ

次のNLSパラメータは、NLSSORTを除くSQL関数では受け入れられません。

- NLS_LANGUAGE

- NLS_TERRITORY

- NLS_DATE_FORMAT

NLS_DATE_FORMATおよびNLS_TERRITORY_FORMATは、必要な書式マスクを妨げる可能性があるため、パラメータとしては受け入れられません。TO_CHAR関数またはTO_DATE関数にNLSパラメータがある場合は、常に、日付書式を指定する必要があります。このため、NLS_DATE_FORMATおよびNLS_TERRITORY_FORMATは、TO_CHARまたはTO_DATE関数に対する有効なNLSパラメータではありません。TO_CHARまたはTO_DATE関数でNLS_DATE_FORMATまたはNLS_TERRITORY_FORMATを指定すると、エラーが戻されます。

NLS_LANGUAGEは、NLS_DATE_LANGUAGEのセッション値を妨げる可能性があります。たとえば、TO_CHAR関数でNLS_LANGUAGEを指定した場合、その値がNLS_DATE_LANGUAGEのセッション値と異なっていれば無視されます。

ロケール依存のその他のSQL関数

この項の内容は、次のとおりです。

- CONVERT関数

- 様々な長さセマンティクスに使用するSQL関数

- 様々な長さセマンティクスに使用するLIKE条件

- キャラクタ・セットのSQL関数

- NLSSORT関数

CONVERT関数

CONVERT関数は、キャラクタ・セット間で文字データを変換します。

CONVERT関数は、あるキャラクタ・セットの文字列のバイナリ表現を、別のキャラクタ・セットのバイナリ表現に変換します。データベースとクライアントの間のキャラクタ・セット変換とまったく同じ方法を使用します。したがって、置換文字を使用するため、同じ制限があります。

関連項目:
「クライアントとサーバーの間のキャラクタ・セット変換」

CONVERTの構文は、次のとおりです。

CONVERT(char, dest_char_set[, source_char_set])

charは変換される値です。source_char_setは変換元キャラクタ・セットでdest_char_setは変換先キャラクタ・セットです。source_char_setパラメータが指定されていない場合、データベース・キャラクタ・セットがデフォルト値として使用されます。

関連項目:

- CONVERT関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- CONVERT関数にのみ使用されるキャラクタ・セット・エンコーディングについては、「キャラクタ・セット変換のサポート」を参照してください。

様々な長さセマンティクスに使用するSQL関数

Oracleには、様々な長さセマンティクスに従って動作するSQL関数が用意されています。この種のSQL関数は、SUBSTR、LENGTHおよびINSTRという3つのグループに分かれています。グループ内の各関数は異なる種類の長さセマンティクスに基づいており、関数名に追加される文字または数字で区別されます。たとえば、SUBSTRBはバイト・セマンティクスに基づいています。

SUBSTR関数は、サブストリングの要求された部分を戻します。LENGTH関数は、文字列の長さを戻します。INSTR関数は、文字列内のサブストリングを検索します。

SUBSTR関数は、文字列の長さを様々な方法で計算します。表9-2に、計算方法を示します。

表9-2 SUBSTR関数による文字列の長さの計算方法

関数

計算方法

SUBSTR

文字列の長さを、データ型のキャラクタ・セットに関連付けられた長さセマンティクスに基づいて、文字数単位で計算します。たとえば、AL32UTF8の文字は、UCS-4文字の数で計算されます。UTF8およびAL16UTF16の文字は、UCS-2文字の数で計算されます。1つの補助文字は、AL32UTF8では1文字、UTF8およびAL16UTF16では2文字としてカウントされます。VARCHARおよびNVARCHARでは異なるキャラクタ・セットが使用されている場合があるため、2つの文字列が同一の場合にも、データ型が異なるとSUBSTRでの結果が異なる可能性があります。アプリケーションで一貫性が必要な場合は、SUBSTR2またはSUBSTR4を使用して、すべてのセマンティクスの計算を強制的にそれぞれUCS-2またはUCS-4にしてください。

SUBSTRB

文字列の長さをバイト数単位で計算します。

SUBSTR2

文字列の長さを、Java文字列とWindowsクライアント環境に準拠するUCS-2文字の数で計算します。各文字は、UCS-2または16ビットUnicode値で表されます。補助文字は2文字としてカウントされます。

SUBSTR4

文字列の長さをUCS-4文字数で計算します。各文字は、UCS-4または32ビットUnicode値で表されます。補助文字は1文字としてカウントされます。

SUBSTRC

文字列の長さをUnicode合成文字数で計算します。補助文字と合成文字は、1文字としてカウントされます。

LENGTHおよびINSTR関数は、関数名に追加された文字または数字に従って、文字列の長さを同様の方法で計算します。

次に、データベース・キャラクタ・セットがAL32UTF8のデータベースで、SUBSTRとSUBSTRBを実行した場合の相違がわかる例を示します。

Fußball文字列の場合、次の文では2文字目からの長さ4文字のサブストリングが戻されます。

SELECT SUBSTR ('Fußball', 2 , 4) SUBSTR FROM DUAL;

SUBS
----
ußba

Fußball文字列の場合、次の文では2バイト目からの長さ4バイトのサブストリングが戻されます。

SELECT SUBSTRB ('Fußball', 2 , 4) SUBSTRB FROM DUAL;

SUB
---
ußb

関連項目:
SUBSTR、LENGTHおよびINSTR関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

様々な長さセマンティクスに使用するLIKE条件

LIKE条件によって、パターン一致を使用するテストを指定します。等価演算子(=)は、ある文字の値と別の文字の値を完全に照合しますが、LIKE条件は、1番目の値の中に2番目で指定されたパターンがあるかどうかを検索し、ある文字の値と別の文字の値の一部を照合します。

LIKEでは、入力のキャラクタ・セットに関連付けられた長さセマンティクスを使用して、文字列の長さが文字数単位で計算されます。表9-3に、LIKE2、LIKE4およびLIKECの各条件を示します。

表9-3 LIKE条件

関数

説明

LIKE2

文字がUCS-2のセマンティクスで表される場合に使用します。補助文字は2文字とみなされます。

LIKE4

文字がUCS-4のセマンティクスで表される場合に使用します。補助文字は1文字とみなされます。

LIKEC

文字が完全なUnicodeキャラクタ・セマンティクスで表される場合に使用します。合成文字は1文字として処理されます。

LIKEB条件はありません。

キャラクタ・セットのSQL関数

2つのSQL関数NLS_CHARSET_NAMEおよびNLS_CHARSET_IDで、キャラクタ・セットID番号とキャラクタ・セット名の間の変換ができます。これらの関数は、OCIを介して変数をバインドするために、キャラクタ・セットID番号の判断が必要なプログラムで使用されます。

もう1つのSQL関数NLS_CHARSET_DECL_LENは、列のバイト単位の長さが指定されている場合、列の宣言の長さを文字数で戻します。

この項の内容は、次のとおりです。

- キャラクタ・セット番号からキャラクタ・セット名への変換

- キャラクタ・セット名からキャラクタ・セット番号への変換

- NCHAR列の長さを戻す

関連項目:
『Oracle Database SQL言語リファレンス』

キャラクタ・セット番号からキャラクタ・セット名への変換

NLS_CHARSET_NAME(n)関数は、ID番号nに対応するキャラクタ・セットの名前を戻します。nがキャラクタ・セットIDとして認識されない値である場合、関数はNULLを戻します。

キャラクタ・セット名からキャラクタ・セット番号への変換

NLS_CHARSET_ID(text)は、textによって指定された名前に対応するキャラクタ・セットIDを戻します。textには、ランタイムVARCHAR2の値としてキャラクタ・セット名が定義されます。textの値は、データベース・キャラクタ・セットまたは各国語キャラクタ・セット以外のキャラクタ・セットに解決されるNLSRTL名にすることができます。

値CHAR_CSをtextに入力すると、この関数はサーバーのデータベース・キャラクタ・セットIDを戻します。値NCHAR_CSをtextに入力すると、この関数はサーバーのデータベース・キャラクタ・セットIDを戻します。textが名前として認識されない場合、この関数はNULLを戻します。

注意:
textの値は、大文字で入力してください。

NCHAR列の長さを戻す

NLS_CHARSET_DECL_LEN(BYTECNT, CSID)は、列のバイト単位の長さが指定されている場合、列の宣言の長さを文字数で戻します。BYTECNT は列のバイト単位の長さです。CSID は列のキャラクタ・セットIDです。

NLSSORT関数

NLSSORT関数では、ORDER BY句に言語ソートを使用できます。文字列は言語ソート・メカニズムで使用される等価のソート文字列で置換されるため、置換文字列をソートして必要なソート基準を生成できます。バイナリ・ソートの場合、ソート文字列は入力文字列と同じです。

ORDER BY句で使用される言語ソートの種類はNLS_SORTセッション・パラメータによって決定されますが、NLSSORT関数を明示的に使用することでオーバーライドできます。

例9-1では、NLS_SORTセッション・パラメータを使用したドイツ語ソートを指定しています。

例9-1 NLS_SORTセッション・パラメータを使用したドイツ語ソートの指定

ALTER SESSION SET NLS_SORT = GERMAN;
SELECT * FROM table1
ORDER BY column1;

例9-2 NLSSORT関数を使用したフランス語ソートの指定

この例では、最初にNLS_SORTセッション・パラメータをGERMANに設定しますが、NLSSORT関数でフランス語ソートを指定することでオーバーライドします。

ALTER SESSION SET NLS_SORT = GERMAN;
SELECT * FROM table1
ORDER BY NLSSORT(column1, 'NLS_SORT=FRENCH');

WHERE句では、NLS_COMPがBINARYに設定されている場合、バイナリ比較が使用されますが、これはWHERE句にNLSSORT関数を使用してオーバーライドできます。

例9-3 WHERE句を使用した言語上の比較

ALTER SESSION SET NLS_COMP = BINARY;
SELECT * FROM table1
WHERE NLSSORT(column1, 'NLS_SORT=FRENCH')>
NLSSORT(column2, 'NLS_SORT=FRENCH');

NLS_COMPセッション・パラメータをLINGUISTICに設定すると、WHERE句にはNLS_SORT値が使用されます。

これ以降の内容は、次のとおりです。

- NLSSORTの構文

- WHERE句の文字列の比較

- NLS_COMPパラメータを使用したWHERE句での比較の簡素化

- ORDER BY句の制御

NLSSORTの構文

NLSSORTは、次の4通りの方法で使用できます。

- NLSSORT()(NLS_SORTパラメータに従います。)

- NLSSORT(column1, 'NLS_SORT=xxxx')

- NLSSORT(column1, 'NLS_LANG=xxxx')

- NLSSORT(column1, 'NLS_LANGUAGE=xxxx')

NLSSORT関数のNLS_LANGパラメータは、クライアント環境設定のNLS_LANGとは異なります。NLSSORT関数では、NLS_LANGによって言語の略称(米語はUS、ポーランド語はPLなど)が指定されます。次に例を示します。

SELECT * FROM table1
ORDER BY NLSSORT(column1, 'NLS_LANG=PL');

WHERE句の文字列の比較

NLSSORTによって、アプリケーションは、アルファベットの規則に従った文字列の一致を実行できます。通常、WHERE句の文字列は、文字のバイナリ値を使用して比較されます。データベース・キャラクタ・セットでのバイナリ値が大きい場合、その文字は他の文字よりも大きいとみなされます。文字のバイナリ値に基づいた文字順が言語のアルファベット順と一致しない場合があるため、このような比較では、アルファベットの規則に従わないことがあります。たとえば、列(column1)にISO 8859-1の8ビット・キャラクタ・セットの値ABC、ABZ、BCDおよびÄBCが含まれている場合、Äの数値はBより大きいため、次の問合せではBCDとÄBCの両方が戻されます。

SELECT column1 FROM table1 WHERE column1 > 'B';

Äは、ドイツ語ではアルファベット順でBの前にソートされますが、スウェーデン語ではÄは、Zの後にソートされます。WHERE句でNLSSORTを使用すると、次のように言語上の比較を行うことができます。

WHERE NLSSORT(col) comparison_operator NLSSORT(comparison_string)

NLSSORTは、比較演算子の両側に指定する必要があります。次に例を示します。

SELECT column1 FROM table1 WHERE NLSSORT(column1) > NLSSORT('B');

ドイツ語の言語ソートが設定されている場合、ドイツ語ではアルファベット順でÄはBの前にくるため、この文ではÄで始まる文字列は戻されません。スウェーデン語の言語ソートが設定されている場合、スウェーデン語ではアルファベット順でÄはZの後にくるため、Äで始まる文字列が戻されます。

NLS_COMPパラメータを使用したWHERE句での比較の簡素化

デフォルトでは、WHERE句またはPL/SQLブロックでの比較はバイナリで行われます。言語上の比較にNLSSORT関数を使用するのは、特にNLS_SORTセッション・パラメータにすでに言語ソートが指定されている場合は、面倒な場合があります。NLS_COMPパラメータを使用すると、WHERE句またはPL/SQLブロックでの比較に、NLS_SORTセッション・パラメータに従った言語を使用するように指定できます。

注意:
NLS_COMPパラメータは、パーティション表に対する比較動作には影響しません。VALUES LESS THANパーティションに基づく文字列の比較は、常にバイナリで行われます。

関連項目:
「NLS_COMP」

ORDER BY句の制御

言語ソートを使用中の場合、ORDER BY句では文字データに対して暗黙的なNLSSORTが使用されます。ORDER BY句のソート方法(言語またはバイナリ)は、アプリケーション側で意識することはありません。ただし、NLSSORT関数がORDER BY句に明示的に指定されている場合、暗黙的なNLSSORTは実行されません。

NLS_SORTセッション・パラメータで言語ソートが定義されている場合、アプリケーションではORDER BY句に暗黙的なNLSSORT関数が使用されます。明示的なNLSSORT関数を指定すると、暗黙的なNLSSORT関数がオーバーライドされます。

ソート方法が言語として定義されている場合、通常、ORDER BY句にNLSSORT関数は不要です。

ソート方法がデフォルトであるか、バイナリとして定義されている場合、次のような問合せではバイナリ・ソートが使用されます。

SELECT last_name FROM employees
ORDER BY last_name;

次の問合せによって、ドイツ語の言語ソートを取得できます。

SELECT last_name FROM employees
ORDER BY NLSSORT(last_name, 'NLS_SORT = GERMAN');

関連項目:
「言語ソートの使用」

グローバル環境でのSQLとPL/SQLのプログラミングに関するその他のトピック

この項の内容は、次のとおりです。

- SQLの日付書式マスク

- 週番号の計算

- SQLの数値書式マスク

- LOB列への外部BFILEデータのロード

関連項目:
書式マスクの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SQLの日付書式マスク

TO_CHAR、TO_DATEおよびTO_NUMBERの各関数には、複数の書式マスクが用意されています。

RM(Roman Month)書式要素は、ローマ数字で月を戻します。RMまたはrmを使用して、大文字または小文字を指定できます。たとえば、2007年9月7日の場合、DD-rm-YYYYでは07-ix-2007が戻り、DD-RM-YYYYでは07-IX-2007が戻ります。

書式マスクMONおよびDYは、長さ3文字以内の月および曜日の略称を明示的にサポートします。たとえば、フランス語のLundiとMardiに対して、それぞれの略称LuとMaを指定できます。

週番号の計算

WW書式マスクで戻される週番号は、アルゴリズムint(dayOfYear+6)/7に従って算出されます。この週番号のアルゴリズムは、ISO規格(2015、1992-06-15)に従っていません。

ISO規格をサポートするために、IW書式要素が用意されています。これによりISOの週番号が戻されます。また、Y、YY、YYYおよびYYYYの各書式要素の動作と同等の書式要素I、IY、IYYおよびIYYYは、ISO週番号に関連する年を戻します。

ISO規格では、ISO週番号に関連する年が、暦年と異なることがあります。たとえば、2007年1月1日は、2008年のISO週番号53になります。週は、常に月曜日に始まって日曜日に終わります。週番号は、次の規則に従って決定されます。

- 1月1日が金曜日、土曜日または日曜日の場合、1月1日を含む週は、その週の大半の日が前年に属するため、前年の最後の週になります。

- 1月1日が月曜日、火曜日、水曜日または木曜日の場合は、1月1日を含む週は、その週の大半の日が新しい年に属するため、新しい年の最初の週になります。

たとえば、1991年1月1日は火曜日であるため、1990年12月31日の月曜日から1991年1月6日の日曜日までが第1週になります。したがって、1990年12月31日のISO週番号および年は、1および1991となります。ISO週番号を取得するには、週番号にIW書式マスクを使用し、年にIY書式のいずれかを使用します。

SQLの数値書式マスク

数値を書式設定するための書式要素がいくつか用意されています。

要素

説明

用途

D

小数

小数点文字を戻します。

G

グループ

グループ・セパレータを戻します。

L

各国通貨

各国通貨記号を戻します。

C

国際通貨

ISO通貨記号を戻します。

RN

ローマ数字

数値を同等のローマ数字として戻します。

ローマ数字の場合は、RNまたはrnを使用して、大文字または小文字のいずれかを指定できます。変換される数値は、1から3999の範囲の整数であることが必要です。

LOB列への外部BFILEデータのロード

DBMS_LOB PL/SQLパッケージを使用すると、外部BFILEデータをLOB列にロードできます。Oracleデータベースでは、バイナリ・データをCLOB列またはNCLOB列にロードする前に、キャラクタ・セットの変換を行います。したがって、正常に動作させるために、BFILEデータをデータベース・キャラクタ・セットまたは各国語キャラクタ・セットと同じキャラクタ・セットにする必要はありません。各APIによって、指定したBFILEキャラクタ・セットから、CLOBデータ型の場合はデータベース・キャラクタ・セット、NCLOBデータ型の場合は各国語キャラクタ・セットへとデータが変換されます。クライアント上ではBFILEデータはサポートされないため、ロードはサーバー上で発生します。

- BLOB列をロードするには、DBMS_LOB.LOADBLOBFROMFILEを使用します。

- CLOB列およびNCLOB列をロードするには、DBMS_LOB.LOADCLOBFROMFILEを使用します。

関連項目:

- 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』

- 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』

10 グローバル環境でのOCIプログラミング

この章では、グローバル環境でのOCIプログラミングについて説明します。この章の内容は、次のとおりです。

- OCI NLS関数の使用

- OCIでのキャラクタ・セットの指定

- OCIでのロケール情報の取得

- Oracleと他の規格とのロケール情報のマッピング

- OCIでの文字列操作

- OCIでの文字の分類

- OCIでのキャラクタ・セットの変換

- OCIメッセージ関数

- lmsgenユーティリティ

OCI NLS関数の使用

多くのOCI NLS関数では、次のいずれかを受け入れます。

- 環境ハンドル

- ユーザー・セッション・ハンドル

OCI環境ハンドルは、クライアントNLS環境に関連付けられており、クライアントNLS環境変数によって初期化されます。サーバーに対してALTER SESSION文が使用されても、この環境は変わりません。環境ハンドルに関連付けられているキャラクタ・セットは、クライアント・キャラクタ・セットです。

OCIセッション・ハンドルは、サーバー・セッション環境に関連付けられています。ALTER SESSION 文よってセッション環境が変更されると、このNLS設定も変更されます。セッション・ハンドルに関連付けられているキャラクタ・セットは、データベース・キャラクタ・セットです。

OCIセッション・ハンドルは、そのセッションで最初のトランザクションが始まるまで、どのNLS設定とも関連付けられていません。SELECT文では、トランザクションは始まりません。

関連項目:
OCI NLS関数の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

OCIでのキャラクタ・セットの指定

OCI環境の作成時にOCIEnvNlsCreate関数を使用して、クライアント側データベースと各国語キャラクタ・セットを指定します。この関数を使用すると、NLS_LANGおよびNLS_NCHAR初期化パラメータの設定に関係なく、アプリケーションでキャラクタ・セット情報を動的に設定できます。また、1つのアプリケーションで、同じサーバー環境内で異なるクライアント環境に使用する複数の環境ハンドラを初期化できます。

AL16UTF16を除くOracleキャラクタ・セットIDを指定するには、OCIEnvNlsCreate関数を通じてメタデータ、SQL CHARデータおよびSQL NCHARデータのエンコーディングを指定します。UTF-16データを指定するには、OCIEnvNlsCreate関数でOCI_UTF16IDを使用します。

関連項目:
OCIEnvNlsCreate関数の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

OCIでのロケール情報の取得

Oracleのロケールは、言語、地域およびキャラクタ・セットの定義で構成されています。ロケールによって、日付、時刻、数字および通貨の書式と、曜日名、月名などの規則が定義されます。国際化されたアプリケーションは、ユーザーのロケール設定と文化的な慣習に従って動作します。たとえば、ロケールがドイツ語に設定されている場合、曜日名と月名はドイツ語で表示されます。

OCINlsGetInfo()関数を使用すると、次のロケール情報を取得できます。

曜日(変換後)

曜日の略称(変換後)

月名(変換後)

月の略称(変換後)

Yes/No(変換後)

AM/PM(変換後)

AD/BC(変換後)

数値書式

借方/貸方

日付書式

通貨書式

デフォルトの言語

デフォルトの地域

デフォルトのキャラクタ・セット

デフォルトの言語ソート

デフォルトのカレンダ

表10-1に、ロケール情報を戻すOCI関数を示します。

表10-1 ロケール情報を戻すOCI関数

関数

説明

OCINlsGetInfo()

ロケール情報を戻します。前述の説明を参照してください。

OCINlsCharSetNameTold()

指定されたOracleキャラクタ・セット名のOracleキャラクタ・セットIDを戻します。

OCINlsCharSetIdToName()

指定されたキャラクタ・セットIDのOracleキャラクタ・セット名を戻します。

OCINlsNumericInfoGet()

最大文字サイズなど、指定された数値情報を戻します。

OCINlsEnvironmentVariableGet()

NLS_LANGからのキャラクタ・セットID、またはNLS_NCHARからの各国語キャラクタ・セットIDを戻します。

関連項目:
『Oracle Call Interfaceプログラマーズ・ガイド』

Oracleと他の規格とのロケール情報のマッピング

OCINlsNameMap関数は、Oracleキャラクタ・セット名、言語名および地域名と、Internet Assigned Numbers Authority (IANA)名および国際標準化機構(ISO)名の間のマッピングを行います。

OCIでの文字列操作

文字列操作では、次の2種類のデータ構造がサポートされています。

- ネイティブ・キャラクタ文字列

- ワイド・キャラクタ文字列

ネイティブ・キャラクタ文字列は、Oracleのネイティブ・キャラクタ・セットでエンコードされます。ネイティブ・キャラクタ文字列を処理する関数は、その文字列の長さをバイト単位で計算して1単位として扱います。ワイド・キャラクタ(wchar)文字列関数は、文字列操作の柔軟性を高めます。この種の関数は、文字列の長さを文字数で計算し、文字ベースと文字列ベースの操作をサポートします。

ワイド・キャラクタのデータ型はOracle固有です。ANSI/ISOのC規格で定義されているwchar_tデータ型と混同しないでください。Oracleのワイド・キャラクタのデータ型は、すべてのプラットフォームで常に4バイトですが、wchar_tのサイズは実装とプラットフォームに依存します。Oracleのワイド・キャラクタのデータ型によって、ネイティブ・キャラクタは簡単に処理できる固定幅になるように正規化されます。これにより、Oracleのワイド・キャラクタ形式とネイティブ・キャラクタ形式の間でラウンドトリップ変換時にデータ消失が発生しないことが保証されます。

次の文字列操作が含まれます。

- ネイティブ・キャラクタ形式とワイド・キャラクタ形式間の文字列の変換

- 文字の分類

- 大/小文字の変換

- 表示長の計算

- 比較、連結、検索などの一般的な文字列操作

表10-2に、OCI文字列操作関数を示します。

注意:
表10-2では、マルチバイト文字列に言及している関数と説明は、ネイティブ・キャラクタ文字列に適用されます。

表10-2 OCI文字列操作関数

関数

説明

OCIMultiByteToWideChar()

ヌル文字で終了する文字列全体をwchar書式に変換します。

OCIMultiByteInSizeToWideChar()

文字列の一部をwchar書式に変換します。

OCIWideCharToMultiByte()

ヌル文字で終了するワイド・キャラクタ文字列全体をマルチバイト文字列に変換します。

OCIWideCharInSizeToMultiByte()

ワイド・キャラクタ文字列の一部をマルチバイト書式に変換します。

OCIWideCharToLower()

wcで指定されたwchar文字を、指定したロケールに存在する場合は対応する小文字に変換します。対応する小文字が存在しない場合は、wc自体を戻します。

OCIWideCharToUpper()

wcで指定されたwchar文字を、指定したロケールに存在する場合は対応する大文字に変換します。対応する大文字が存在しない場合は、wc自体を戻します。

OCIWideCharStrcmp()

2つのワイド・キャラクタ文字列を、バイナリ、言語または大/小文字を区別しない比較方法で比較します。

注意: UNICODE_BINARYソート・メソッドは、OCIWideCharStrcmp()とともに使用して、指定されたワイド・キャラクタ引数の言語比較を実行することはできません。

OCIWideCharStrncmp()

この関数はOCIWideCharStrcmp()に似ています。2つのワイド・キャラクタ文字列を、バイナリ、言語または大/小文字を区別しない比較方法で比較します。str1から最大len1バイト、str2から最大len2バイトが比較されます。

注意: OCIWideCharStrcmp()と同様に、UNICODE_BINARYソート・メソッドは、OCIWideCharStrcmp()とともに使用して、指定されたワイド・キャラクタ引数の言語比較を実行することはできません。

OCIWideCharStrcat()

wsrcstrで示された文字列のコピーを追加します。その後、結果文字列の文字数を戻します。

OCIWideCharStrncat()

wsrcstrで示された文字列のコピーを追加します。その後、結果文字列の文字数を戻します。最大n文字が追加されます。

OCIWideCharStrchr()

wstrで示された文字列の中で、最初に出現するwcを検索します。検索が正常終了した場合は、wcharへのポインタを戻します。

OCIWideCharStrrchr()

wstrで示された文字列の中で、最後に出現するwcを検索します。

OCIWideCharStrcpy()

wsrcstrで示されたwchar文字列をwdststrで示された配列にコピーします。その後、コピーされた文字数を戻します。

OCIWideCharStrncpy()

wsrcstrで示されたwchar文字列をwdststrで示された配列にコピーします。その後、コピーされた文字数を戻します。最大n文字が配列からコピーされます。

OCIWideCharStrlen()

wstrで示されたwchar文字列にある文字数を計算し、その数を戻します。

OCIWideCharStrCaseConversion()

wsrcstrで示されたワイド・キャラクタ文字列をフラグの指定により大文字または小文字に変換し、その結果をwdststrで示された配列にコピーします。

OCIWideCharDisplayLength()

wcを表示するために必要な列位置の数を決定します。

OCIWideCharMultibyteLength()

wcをマルチバイト・エンコーディングで表す場合に必要なバイト数を決定します。

OCIMultiByteStrcmp()

2つのマルチバイト・キャラクタ文字列を、バイナリ、言語または大/小文字を区別しない比較方法で比較します。

OCIMultiByteStrncmp()

2つのマルチバイト・キャラクタ文字列を、バイナリ、言語または大/小文字を区別しない比較方法で比較します。str1から最大len1バイト、str2から最大len2バイトが比較されます。

OCIMultiByteStrcat()

srcstrで示されたマルチバイト文字列のコピーを追加します。

OCIMultiByteStrncat()

srcstrで示されたマルチバイト文字列のコピーを追加します。srcstrから最大nバイトがdststrに追加されます。

OCIMultiByteStrcpy()

srcstrが指し示すマルチバイト文字列を、dststrが指し示す配列にコピーします。これは、コピーされたバイト数を戻します。

OCIMultiByteStrncpy()

srcstrが指し示すマルチバイト文字列を、dststrが指し示す配列にコピーします。これは、コピーされたバイト数を戻します。ただし、srcstrが指し示す配列からdststrが指し示す配列にコピーされるのは、最大nバイトです。

OCIMultiByteStrlen()

strで示されたマルチバイト文字列のバイト数を戻します。

OCIMultiByteStrnDisplayLength()

nバイトの範囲内のすべての文字が占有する表示位置の大きさを戻します。

OCIMultiByteStrCaseConversion()

文字列の一部をあるキャラクタ・セットから別のキャラクタ・セットに変換します。

関連項目:
『Oracle Call Interfaceプログラマーズ・ガイド』

OCIでの文字の分類

表10-3に、OCIの文字の分類関数を示します。

表10-3 OCIの文字の分類関数

関数

説明

OCIWideCharIsAlnum()

ワイド・キャラクタが、アルファベット文字であるか10進数字であるかをテストします。

OCIWideCharIsAlpha()

ワイド・キャラクタが、アルファベット文字であるかどうかをテストします。

OCIWideCharIsCntrl()

ワイド・キャラクタが、制御文字であるかどうかをテストします。

OCIWideCharIsDigit()

ワイド・キャラクタが、10進数字であるかどうかをテストします。

OCIWideCharIsGraph()

ワイド・キャラクタが、図形文字であるかどうかをテストします。

OCIWideCharIsLower()

ワイド・キャラクタが、小文字であるかどうかをテストします。

OCIWideCharIsPrint()

ワイド・キャラクタが、印字可能文字であるかどうかをテストします。

OCIWideCharIsPunct()

ワイド・キャラクタが、句読点文字であるかどうかをテストします。

OCIWideCharIsSpace()

ワイド・キャラクタが、スペース文字であるかどうかをテストします。

OCIWideCharIsUpper()

ワイド・キャラクタが、大文字であるかどうかをテストします。

OCIWideCharIsXdigit()

ワイド・キャラクタが、16進数字であるかどうかをテストします。

OCIWideCharIsSingleByte()

wcがマルチバイトに変換されるとき、シングルバイト文字であるかどうかをテストします。

関連項目:
『Oracle Call Interfaceプログラマーズ・ガイド』

OCIでのキャラクタ・セットの変換

Oracleキャラクタ・セットとUnicode(16ビットの固定幅Unicodeエンコーディング)間の変換がサポートされています。UnicodeからOracleキャラクタ・セットへのマッピングがない場合は、置換文字が使用されます。したがって、データ消失なしで元のキャラクタ・セットへ戻る変換が常に可能なわけではありません。

表10-4に、OCIのキャラクタ・セット変換関数を示します。

表10-4 OCIキャラクタ・セット変換関数

関数

説明

OCICharsetToUnicode()

srcで示されたマルチバイト文字列をUnicodeに変換し、dstで示された配列に格納します。

OCIUnicodeToCharset()

srcで示されたUnicode文字列をマルチバイトに変換し、dstで示された配列に格納します。

OCINlsCharSetConvert()

文字列をあるキャラクタ・セットから別のキャラクタ・セットに変換します。

OCICharSetConversionIsReplacementUsed()

OCINlsCharSetConvert()またはOCIUnicodeToCharSet()の最後の起動時に変換できなかった文字に、置換文字が使用されたかどうかを示します。

関連項目:

- 『Oracle Call Interfaceプログラマーズ・ガイド』

- 「Unicodeを使用したOCIプログラミング」

OCIメッセージ関数

ユーザー・メッセージAPIには、カートリッジ開発者のための簡易インタフェースが用意されています。これによって、Oracleメッセージと同様にユーザー自身のメッセージを取り出すことができます。

表10-5に、OCIメッセージ関数を示します。

表10-5 OCIメッセージ関数

関数

説明

OCIMessageOpen()

hndlで示された言語で、メッセージ・ハンドルをオープンします。

OCIMessageGet()

msgnoで識別されるメッセージ番号の付いたメッセージを取り出します。バッファが0(ゼロ)でない場合、この関数はmsgbufで指定されたバッファにメッセージをコピーします。

OCIMessageClose()

msghで示されたメッセージ・ハンドルをクローズし、そのハンドルに関連付けられているメモリーをすべて解放します。

関連項目:
『Oracle Databaseデータ・カートリッジ開発者ガイド』

lmsgenユーティリティ

用途

lmsgenユーティリティは、テキスト・ベースのメッセージ・ファイル(.msg)をバイナリ形式(.msb)に変換します。これにより、ユーザーが提供するOracleメッセージとOCIメッセージを、必要な言語でOCI関数に戻すことができます。

サーバーが使用するメッセージは、$ORACLE_HOME/product_name/mesgディレクトリにあるバイナリ形式ファイル、あるいはそれに相当するオペレーティング・システム用ファイルに格納されます。このファイルには、次のファイル名規則に従って、サポート対象言語ごとに1バージョンずつ、複数のバージョンが存在します。

<product_id><language_abbrev>.msb

たとえば、ORAは製品ID(<product_id>)でFはフランス語の略称(<language_abbrev>)であるため、フランス語のサーバー・メッセージが含まれたファイルはoraf.msbと呼ばれます。product_nameの値はrdbmsであるため、$ORACLE_HOME/rdbms/mesgディレクトリにあります。

構文

LMSGEN text_file product facility [language] [-i indir] [-o outdir]

text_fileはメッセージ・テキスト・ファイルです。
productは製品名です。
facilityは機能名です。
languageは、NLS_LANGパラメータで指定した言語に対応するオプションのメッセージ言語です。パラメータは、メッセージ・ファイルが言語に正しくタグ付けされていない場合に必要です。
indirは、テキスト・ファイルの場所を指定するオプション・ディレクトリです。
outdirは、出力ファイルの場所を指定するオプション・ディレクトリです。

出力(.msb)ファイルは、$ORACLE_HOME/product/mesg/ディレクトリの下に生成されます。

テキスト・メッセージ・ファイル

テキスト・メッセージ・ファイルは、次のガイドラインに従う必要があります。

- /および//で始まる行は内部コメントとして扱われ、無視されます。

- メッセージ・ファイルを特定の言語でタグ付けするには、次のような1行を追加します。

#   CHARACTER_SET_NAME= Japanese_Japan.JA16EUC

- 各メッセージには、次の3つのフィールドがあります。

message_number, warning_level, message_text

message_numberは、メッセージ・ファイル内で一意であることが必要です。

warning_levelは、現在使用されていません。0(ゼロ)を使用してください。

message_textは、511バイトを超えることはできません。

次に、Oracleメッセージ・テキスト・ファイルの例を示します。

/ Copyright (c) 2006 by Oracle.  All rights reserved.
/ This is a test us7ascii message file
# CHARACTER_SET_NAME= american_america.us7ascii
/
00000, 00000, "Export terminated unsuccessfully\n"
00003, 00000, "no storage definition found for segment(%lu, %lu)"

例: テキスト・メッセージ・ファイルからのバイナリ・メッセージ・ファイルの作成

次の表に、lmsgenパラメータのサンプル値を示します。

パラメータ

値

product

myapp

facility

imp

language

AMERICAN

text_file

impus.msg

テキスト・メッセージ・ファイル内の1行は、次のとおりです。

00128,2, "Duplicate entry %s found in %s"

lmsgenユーティリティは、テキスト・メッセージ・ファイル(impus.msg)をバイナリ形式のファイルimpus.msbに変換します。$ORACLE_HOME/myapp/mesgディレクトリがすでに存在している必要があります。

% lmsgen impus.msg myapp imp AMERICAN

出力は次のようになります。

Generating message file impus.msg -->
$ORACLE_HOME/myapp/mesg/impus.msb

NLS Binary Message File Generation Utility: Version 10.2.0.1.0 - Production

Copyright (c) Oracle 1979, 2006.  All rights reserved.

CORE 10.2.0.1.0       Production

11 キャラクタ・セットの移行

この章では、キャラクタ・セット変換とキャラクタ・セットの移行について説明します。この章の内容は、次のとおりです。

- キャラクタ・セットの移行の概要

- 既存のデータベースのデータベース・キャラクタ・セットの変更

- NCHARデータ型への移行

- キャラクタ・セット移行後の変換に関する考慮事項

キャラクタ・セットの移行の概要

使用しているデータベースに適切なキャラクタ・セットを選択することは、重要な決定事項です。データベース・キャラクタ・セットの選択時には、次の要因を考慮する必要があります。

- 格納する必要があるデータの型

- データベースで現在および将来対応する必要のある言語

- 各キャラクタ・セットの異なるサイズ要件とその要件がパフォーマンスに与える影響

関連するトピックとして、既存のデータベース用の新規キャラクタ・セットの選択があります。既存のデータベース用のデータベース・キャラクタ・セットを変更することを、キャラクタ・セットの移行と呼びます。データベース・キャラクタ・セットを移行する場合、適切なキャラクタ・セットを選択する必要があります。また、次の原因によるデータの消失を最小限に抑える必要があります。

- データの切捨て

- キャラクタ・セット変換の問題

関連項目:
第2章「キャラクタ・セットの選択」

データの切捨て

データベースがバイト・セマンティクスを使用して作成されている場合、CHARおよびVARCHAR2データ型のサイズは、文字単位ではなくバイト単位で指定されます。たとえば、表定義でCHAR(20)と指定すると、文字データを格納するために20バイトが割り当てられます。データベース・キャラクタ・セットでシングルバイト文字コード体系が使用されている場合は、文字数がバイト数と同じであるため、文字の格納時にデータ消失は発生しません。データベース・キャラクタ・セットでマルチバイト・キャラクタ・セットが使用されている場合は、1文字が1バイト以上で構成される場合があるため、バイト数は文字数とは異なります。

新規キャラクタ・セットへの移行時には、既存のCHARおよびVARCHAR2列の列幅を検証することが重要です。これは、マルチバイトを格納する必要があるエンコーディングをサポートするために、列幅の拡張が必要となる場合があるためです。変換によってデータが拡張されると、データが切り捨てられる可能性があります。

表11-1に、変換を通じてシングルバイト文字がマルチバイト文字になる場合のデータ拡張例を示します。

表11-1 シングルバイトとマルチバイトのエンコーディング

文字

WE8MSWIN 1252エンコーディング

AL32UTF8エンコーディング

ä

E4

C3 A4

ö

F6

C3 B6

©

A9

C2 A9

€

80

E2 82 AC

表11-1の1列目は選択した文字、2列目はWE8MSWIN1252キャラクタ・セットでの文字の16進表現、3列目はAL32UTF8キャラクタ・セットでの各文字の16進表現を示します。文字と数字のペアは、それぞれ1バイトを表します。たとえば、ä(ウムラウト付きのa)は、WE8MSWIN1252のシングルバイト文字(E4)ですが、AL32UTF8では、2バイト文字(C3 A4)になります。また、ユーロ記号のエンコーディングは1バイト(80)から3バイト(E2 82 AC)に拡張されます。

新しいキャラクタ・セットのデータにデータ型でサポートされるバイト・サイズより大きい記憶域が必要な場合は、スキーマを変更する必要があります。CLOB列の使用が必要になる場合があります。

関連項目:
「長さセマンティクス」

データの切捨てによって生じるその他の問題

データの切捨てによって次の問題が発生する可能性があります。

- データベース・データ・ディクショナリ内でのスキーマ・オブジェクト名は、30バイトを超えることはできません。スキーマ・オブジェクト名が新規データベース・キャラクタ・セットで30バイトを超える場合は、そのオブジェクト名を変更する必要があります。たとえば、タイ語の各国語キャラクタ・セットではタイ語1文字に1バイト必要です。一方、AL32UTF8では3バイト必要です。タイ語11文字の名前を持つ表を定義している場合、データベース・キャラクタ・セットをAL32UTF8に変更するときは、この表名を10文字以下に短縮する必要があります。

- 既存のOracleユーザー名またはパスワードが文字ベースで作成されており、その内容が変換先のキャラクタ・セットでサイズ変更された場合、新規キャラクタ・セットへの移行後は認証がエラーとなるため、ユーザーのログイン時に問題が発生します。この問題が発生するのは、データ・ディクショナリに格納されている暗号化されたユーザー名とパスワードを、新規キャラクタ・セットへの移行時に更新できないためです。たとえば、現行のデータベース・キャラクタ・セットがWE8MSWIN1252で、変換先のデータベース・キャラクタ・セットがAL32UTF8の場合、ユーザー名scött(ウムラウト付きのo)の長さは5バイトから6バイトに変更されます。AL32UTF8では、ユーザー名が異なるため、scöttはログインできなくなります。ユーザー名とパスワードにはASCII文字を使用することをお薦めします。ASCII文字以外の場合は、新規キャラクタ・セットへの移行後に、影響のあるユーザー名とパスワードを再設定する必要があります。

注意:
データ・ディクショナリに暗号化された状態で格納されているユーザー名およびパスワードは、CSALTERスクリプトを使用して移行すると更新されませんが、インポート・ユーティリティおよびエクスポート・ユーティリティを使用して移行すると更新されます。

- CHARデータに、新規キャラクタ・セットへの移行後に拡張される文字が含まれている場合、デフォルトでは、データベースのエクスポート時に空白埋込みは削除されません。つまり、これらの行は、新規キャラクタ・セットでデータベースにインポートされるときに拒否されます。これを回避するには、CHARデータをインポートする前にBLANK_TRIMMING初期化パラメータをTRUEに設定します。

関連項目:
BLANK_TRIMMING初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

キャラクタ・セット変換の問題

この項の内容は、次のとおりです。

- エクスポート・ユーティリティとインポート・ユーティリティの使用による置換文字

- クライアントのNLS_LANGパラメータ設定が不適切であるために生じる無効なデータ

- シングルバイトからマルチバイトへのキャラクタ・セット変換とOracle Data Pump

エクスポート・ユーティリティとインポート・ユーティリティの使用による置換文字

エクスポート・ユーティリティとインポート・ユーティリティでは、オリジナルのデータベース・キャラクタ・セットから新規のデータベース・キャラクタ・セットにキャラクタ・セットを変換できます。ただし、キャラクタ・セット変換によって、データが消失したり、破損する可能性があります。たとえば、キャラクタ・セットAからキャラクタ・セットBに移行する場合に、変換先キャラクタ・セットBはキャラクタ・セットAのスーパーセットであることが必要です。変換先キャラクタ・セットBがスーパーセットであるのは、キャラクタ・セットAで定義されているすべての文字が含まれる場合です。キャラクタ・セットBで使用できない文字は、置換文字に変換されます。この置換文字は、通常、?または¿として指定されるか、使用不可能な文字に関連する1文字として指定されます。たとえば、ä(ウムラウト付きのa)はaで変換できます。置換文字は、変換先キャラクタ・セットで定義されます。

注意:
変換先キャラクタ・セットBは、キャラクタ・セットAのスーパーセットであることが必要という必要条件に対して例外があります。キャラクタ・セットAに含まれるが、キャラクタ・セットBに含まれない文字がデータの中に入っていなければ、データ消失またはデータ破損を防ぐために、変換先キャラクタ・セットがキャラクタ・セットAのスーパーセットである必要はありません。

図11-1に、著作権記号とユーロ記号が?に変換され、äがaに変換されるキャラクタ・セット変換の例を示します。

図11-1 キャラクタ・セット変換での置換文字

データ消失のリスクを削減するには、類似する文字レパートリを持つキャラクタ・セットを変換先に選択してください。AL32UTF8には既存のキャラクタ・セットのほとんどの文字が含まれているため、Unicodeへの移行は最もよい選択肢である可能性があります。

クライアントのNLS_LANGパラメータ設定が不適切であるために生じる無効なデータ

データ消失の可能性があるキャラクタ・セット移行の使用例として、無効なデータを含むデータベースの移行が考えられます。NLS_LANGパラメータがクライアント上で適切に設定されていないため、通常は、データベースに無効なデータが含まれます。NLS_LANG値には、クライアント・オペレーティング・システム・コード・ページを反映する必要があります。たとえば、英語版Windows環境では、コード・ページはWE8MSWIN1252です。NLS_LANGパラメータを適切に設定すると、データベースはクライアント・オペレーティング・システムからのデータを自動的に変換できます。NLS_LANGパラメータが適切に設定されていないと、データベースに入ってくるデータは適切に変換されません。たとえば、データベース・キャラクタ・セットがAL32UTF8で、クライアントが英語版Windowsオペレーティング・システムで、クライアント上でのNLS_LANG設定がAL32UTF8であるとします。データベースに入ってくるデータはWE8MSWIN1252でエンコードされており、クライアント上のNLS_LANG設定がデータベース・キャラクタ・セットと一致するため、AL32UTF8データには変換されません。そのため、Oracleでは変換は不要であるとみなされ、データベースに無効なデータが入力されます。

この結果、データの非一貫性の問題が2つ発生する可能性があります。一方の問題が発生するのは、データベースに含まれているデータのキャラクタ・セットがデータベース・キャラクタ・セットとは異なっているが、両方のキャラクタ・セットに同じコード・ポイントが存在する場合です。たとえば、データベース・キャラクタ・セットがWE8ISO8859P1で、中国語版Windows NTクライアントのNLS_LANG設定がSIMPLIFIED CHINESE_CHINA.WE8ISO8859P1の場合、(ZHS16GBKキャラクタ・セットの)すべてのマルチバイトの中国語データは、シングルバイトWE8ISO8859P1データの倍数として格納されます。これは、Oracleではこれらの文字がシングルバイトWE8ISO8859P1文字として処理されることを意味します。そのため、SUBSTRやLENGTHなどのSQL文字列操作関数はすべて、文字ではなくバイトを基準にして処理されます。ZHS16GBKデータを構成するすべてのバイトは、有効なWE8ISO8859P1コードです。このようなデータベースをAL32UTF8などの別のキャラクタ・セットに移行する場合、文字コードは、WE8ISO8859P1内の文字コードと同様に変換されます。このように、ZHS16GBK文字の2バイトはそれぞれ個別に変換され、AL32UTF8では意味のない値になります。図11-2に、この不適切なキャラクタ・セット置換の例を示します。

図11-2 不適切なキャラクタ・セットの置換

2つ目の問題は、混在するキャラクタ・セットのデータがデータベースにある場合です。たとえば、データ・キャラクタ・セットがWE8MSWIN1252で、ドイツ語とギリシャ語を使用している2つの別々のWindowsクライアントがともに、NLS_LANGキャラクタ・セットとしてWE8MSWIN1252を使用している場合、データベースにはドイツ語とギリシャ語の文字が混在することになります。図11-3に、異なるクライアントが、同一データベースの異なるキャラクタ・セットを使用する方法を示します。

図11-3 キャラクタ・セットの混在

データベース・キャラクタ・セットの移行を適切に行うには、この2つの状況の場合、手作業による調整が必要です。これは、Oracle Databaseでは格納されているデータのキャラクタ・セットを判断できないためです。不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。

シングルバイトからマルチバイトへのキャラクタ・セット変換とOracle Data Pump

Oracle Data Pumpを使用している場合に、キャラクタ・セットをシングルバイトからマルチバイトへの移行するときは、データ・ポンプのPL/SQLパッケージを再ロードする必要があります。

既存のデータベースのデータベース・キャラクタ・セットの変更

データベース・キャラクタ・セットの移行には、データ・スキャニングとデータ変換という2つの段階があります。データベース・キャラクタ・セットを変更する前に、考えられるデータベース・キャラクタ・セット変換の問題とデータの切捨てを識別する必要があります。このステップはデータ・スキャニングと呼ばれます。

データ・スキャニングによって、データベース・キャラクタ・セットの変更前に、データを新しい文字コード体系に移行するために必要な作業量が識別されます。データ・スキャニング時に検出される例には、列幅の拡張が必要なスキーマ・オブジェクトの数や、変換先の文字レパートリに存在しないデータの分布などがあります。この情報は、データベース・キャラクタ・セットの最適な変換方法の決定に役立ちます。

不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。

データベースに「キャラクタ・セット変換の問題」で説明した非一貫性がない場合、あるデータベース・キャラクタ・セットから別のデータベース・キャラクタ・セットにデータを変換するには、3つの方法があります。このような非一貫性があるデータベースを移行する方法は、ここでは説明しません。詳細は、Oracleコンサルティング・サービスにお問い合せください。

この項の内容は、次のとおりです。

- 全体エクスポートおよび全体インポートを使用した文字データの移行

- CSALTERスクリプトを使用したキャラクタ・セットの移行

- CSALTERスクリプトと選択式のインポートを使用した文字データの移行

関連項目:
データ・スキャニングの詳細は、第12章「Character Set Scannerユーティリティ」を参照してください。

全体エクスポートおよび全体インポートを使用した文字データの移行

多くの場合、すべてのデータを新規キャラクタ・セットに正しく変換するには、全体エクスポートおよび全体インポートをお薦めします。文字データ型の列は、サイズ増加を処理するためにインポート前に拡張が必要となる場合があるため、データ切捨ての問題に注意することが重要です。既存のPL/SQLコードをレビューして、LENGTHB、SUBSTRBおよびINSTRBなどのバイトベースのすべてのSQL関数、PL/SQL CHARおよびVARCHAR2の宣言が有効であることを確認する必要があります。

関連項目:
エクスポート・ユーティリティとインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

CSALTERスクリプトを使用したキャラクタ・セットの移行

CSALTERスクリプトは、Database Character Set Scannerユーティリティに付属しています。CSALTERスクリプトはキャラクタ・セットの移行方法としては最も簡単ですが、使用できるのは、すべてのスキーマ・データが、新しいキャラクタ・セットの完全なサブセットである場合のみです。新規キャラクタ・セットが現行のキャラクタ・セットの完全なスーパーセットであるのは、次の場合です。

- 現行のキャラクタ・セット内のすべての文字が、新規キャラクタ・セットで使用可能な場合。

- 現行のキャラクタ・セット内のすべての文字が、新規キャラクタ・セット内で同じコード・ポイント値を持つ場合。たとえば、多くのキャラクタ・セットはUS7ASCIIの完全なスーパーセットです。

完全なスーパーセットという基準からみると、CSALTERスクリプトにより新しいキャラクタ・セットに変換されるのはメタデータのみとなります。ただし、CSALTERスクリプトでは、Oracleにより作成されたデータ・ディクショナリとサンプル・スキーマのCLOB列に対してのみデータ変換が実行されます。ユーザーが作成したCLOB列には、別個の処理が必要になる場合があります。Oracle9iからは、データ・ディクショナリおよびサンプル・スキーマの一部の内部フィールドはCLOB列に格納されます。ユーザーもCLOBフィールドにデータを格納できます。データベース・キャラクタ・セットがマルチバイトの場合、CLOBデータはUCS-2データとの互換形式で格納されます。データベース・キャラクタ・セットがシングルバイトの場合、CLOBデータはデータベース・キャラクタ・セットを使用して格納されます。CSALTERスクリプトで変換されるのは、Oracleにより作成されたデータ・ディクショナリおよびサンプル・スキーマのCLOB列にあるデータのみであるため、CSALTERスクリプトを実行する前に、他に作成されたCLOB列をエクスポートしてスキーマから削除する必要があります。

データベース・キャラクタ・セットを変更する手順は、次のとおりです。

1. SHUTDOWN IMMEDIATE文またはSHUTDOWN NORMAL文のいずれかを使用して、データベースをシャットダウンします。

2. CSALTERスクリプトはロールバックできないため、データベースの全体バックアップを実行します。

3. データベースを起動します。

4. Database Character Set Scannerユーティリティを実行します。

CSSCAN /AS SYSDBA FULL=Y...

5. CSALTERスクリプトを実行します。

@@CSALTER.PLB
SHUTDOWN IMMEDIATE; -- or SHUTDOWN NORMAL;
STARTUP;

CSALTERスクリプトは、ユーザーのデータ変換は実行しないことに注意してください。このスクリプトで変更されるのは、データ・ディクショナリ内のキャラクタ・セット・メタデータのみです。したがって、CSALTER操作の後、Oracleは、新規のキャラクタ・セットを使用してデータベースが作成されたかのように動作します。

関連項目:

- 「CSALTERスクリプトと選択式のインポートを使用した文字データの移行」

- 「Database Character Set ScannerのCSALTERスクリプト」

Oracle Real Application Clusters環境でのCSALTERスクリプトの使用

Oracle Real Application Clusters環境では、CSALTERスクリプトを発行する前に、ユーザーが接続に使用しているインスタンスに関連付けられたバックグラウンド・プロセス以外に、Oracleバックグラウンド・プロセスが実行されていないことを確認してください。これを確認するには、DBA権限を使用して次のSQL文を発行します。

SELECT SID, SERIAL#, PROGRAM FROM V$SESSION;

キャラクタ・セットの変更を完了できるように、CLUSTER_DATABASE初期化パラメータをFALSEに設定します。キャラクタ・セットの変更後に、TRUEにリセットしてください。

CSALTERスクリプトと選択式のインポートを使用した文字データの移行

もう1つの文字データ移行方法は、選択式のエクスポートを指定した後に再スキャンしてCSALTERスクリプトを実行することです。この方法は、シングルバイトのサブセット・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合に最も一般的です。この使用例では、エンコーディングがシングルバイトのキャラクタ・セットからUCS-2互換形式に変化するため、ユーザー作成のCLOBを変換する必要があります。UCS-2は、マルチバイトのエンコーディングに関係なくOracleでCLOBの格納に使用されます。Database Character Set Scannerでは、これらの列が変換可能として識別されます。ユーザーは、これらの列をエクスポートし、スキーマから削除した後で再スキャンし、残りのデータに問題がなければCSALTERスクリプトを実行する必要があります。これらの手順が完了した後、CLOB列をデータベースにインポートして移行を完了します。

NCHARデータ型への移行

Oracleデータベースでは、NCHARデータ型の列に格納されるデータには、データベース・キャラクタ・セットに関係なくUnicodeエンコーディングのみが使用されます。このため、データベース・キャラクタ・セットとしてUnicodeを使用しないデータベースに、Unicodeを格納できます。

この項の内容は、次のとおりです。

- バージョン8 NCHAR列のOracle9i以上への移行

- 各国語キャラクタ・セットの変更

- CHAR列からNCHAR列への移行

バージョン8 NCHAR列のOracle9i以上への移行

バージョン8のOracleデータベースでは、各国語文字データ型(NCHAR)を導入しました。このデータ型によって、データベース・キャラクタ・セットに加えて、2つ目の代替キャラクタ・セットが使用できるようになりました。NCHARデータ型は、複数の固定幅のアジア言語のキャラクタ・セットをサポートしています。これらのキャラクタ・セットは、アジア言語の文字データの処理パフォーマンスを向上させるために導入されたものです。

Oracle9iからは、SQL NCHARデータ型の使用は、Unicodeキャラクタ・セット・エンコーディング(UTF8とAL16UTF16)に制限されています。JA16SJISFIXEDなどのアジア言語のキャラクタ・セットも含めて、NCHARデータ型で使用可能であったバージョン8の他のキャラクタ・セットは、現在ではサポートされていません。

既存のNCHAR、NVARCHAR2およびNCLOBの各列をOracle9i以上のNCHARデータ型に移行する手順は、次のとおりです。

1. すべてのNCHAR列をバージョン8またはOracle8i のデータベースからエクスポートします。

2. NCHAR列を削除します。

3. データベースを新しいリリースにアップグレードします。

4. NCHAR列をアップグレード後のデータベースにインポートします。

移行ユーティリティでは、バージョン8およびOracle8iのNCHAR列を新しいリリースのNCHAR列に変換することもできます。移行ユーティリティでは、utlnchar.sqlというSQL NCHARのアップグレード・スクリプトが提供されています。このスクリプトをデータベース移行操作の最後に実行して、バージョン8とOracle8iのNCHAR列を新しいリリースのNCHAR列に変換します。スクリプトの実行後は、データをダウングレードできません。バージョン8またはOracle8iに移動して戻る唯一の方法は、すべてのNCHAR列を削除してデータベースをダウングレードし、古いNCHARデータを前のバージョン8またはOracle8i のエクスポート・ファイルからインポートすることです。データベースを将来ダウングレードする必要がある場合は、バージョン8またはOracle8iのNCHARデータのバックアップ(エクスポート・ファイル)があることを確認してください。

関連項目:

- エクスポートとインポートの手順の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- NCHARの移行の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

各国語キャラクタ・セットの変更

各国語キャラクタ・セットを変更するには、CSALTERスクリプトを使用します。

関連項目:
CSALTERスクリプトの構文は、第12章「Character Set Scannerユーティリティ」を参照してください。

CHAR列からNCHAR列への移行

次の方法で列のデータ型定義を変更できます。

- ALTER TABLE MODIFY文

- 表のオンライン再定義

ALTER TABLE MODIFY文には、表のオンライン再定義に比べて次の利点があります。

- 使用方法が簡単

- 制限が少ない

表のオンライン再定義には、ALTER TABLE MODIFY文に比べて次の利点があります。

- 列に大量のデータが含まれている場合に高速である

- 一度に複数の列を移行可能

- ほとんどの移行プロセス中に表をDMLに使用可能

- 表の断片化が回避されるため、領域が節約され、データへの高速アクセスが可能

- CLOBデータ型からNCLOBデータ型への移行に使用可能

この項の内容は、次のとおりです。

- ALTER TABLE MODIFY文を使用したCHAR列からNCHAR列への変更

- 表のオンライン再定義を使用した大きい表のUnicodeへの移行

ALTER TABLE MODIFY文を使用したCHAR列からNCHAR列への変更

ALTER TABLE MODIFY文を使用すると、表の列定義をCHARデータ型からNCHARデータ型に変更できます。また、列のすべてのデータをデータベース・キャラクタ・セットからNCHARキャラクタ・セットに変換できます。ALTER TABLE MODIFY文の構文は、次のとおりです。

ALTER TABLE table_name MODIFY (column_name datatype);

移行する列に索引が作成されている場合、索引は各行とともに更新されるため、索引を削除するとALTER TABLE MODIFY文のパフォーマンスを改善できます。

NCHAR列とNVARCHAR2列の最大列長は、2000バイトと4000バイトです。NCHARのキャラクタ・セットがAL16UTF16の場合、NCHAR列とNVARCHAR2列の最大長は1000文字と2000文字、つまり2000バイトと4000バイトです。移行中にこのサイズ制限に対する違反となる場合は、かわりに列をNCLOBデータ型に変更することを考慮してください。

注意:
ALTER TABLE MODIFY文を使用してCLOB列をNCLOB列に移行することはできません。列をCLOBデータ型からNCLOBデータ型に変更するには、表のオンライン再定義を使用します。

関連項目:
「表のオンライン再定義を使用した大きい表のUnicodeへの移行」

表のオンライン再定義を使用した大きい表のUnicodeへの移行

多数の行を含む大きい表をUnicodeデータ型に移行するには、長時間かかります。この移行中は、列データを読込みや更新に使用できません。表のオンライン再定義を使用すると、移行時間を大幅に短縮できます。また、この場合、移行時間中の大部分は、表にDMLでアクセスできます。

次のタスクを実行し、表のオンライン再定義を使用して、表をUnicodeデータ型に移行します。

1. DBMS_REDEFINITION.CAN_REDEF_TABLE PL/SQLプロシージャを使用して、表をオンラインで再定義できることを確認します。たとえば、scott.emp表を移行するには、次のコマンドを入力します。

DBMS_REDEFINITION.CAN_REDEF_TABLE('scott','emp');

2. 再定義する表と同じスキーマに空の仮表を作成します。作成時には、属性にNCHARデータ型を指定します。たとえば、次のように文を入力します。

CREATE TABLE int_emp(
empno NUMBER(4),
ename NVARCHAR2(10),
job NVARCHAR2(9),
mgr NUMBER(4),
hiredate DATE,
sal NUMBER(7,2),
deptno NUMBER(2),
org NVARCHAR2(10));

3. 表のオンライン再定義を開始します。次のようにコマンドを入力します。

DBMS_REDEFINITION.START_REDEF_TABLE('scott',
'emp',
'int_emp',
'empno empno,
to_nchar(ename) ename,
to_nchar(job) job,
mgr mgr,
hiredate hiredate,
sal sal,
deptno deptno,
to_nchar(org) org');

CLOB列をNCLOB列に移行する場合は、TO_NCLOB SQL関数のかわりにTO_NCHAR SQL変換関数を使用します。

4. 仮表のトリガー、索引、権限付与および制約を作成します。仮表に適用される参照制約は、DISABLEDモードで作成する必要があります(仮表は、参照制約の親表または子表です)。仮表に定義するトリガーは、表のオンライン再定義プロセスが完了するまで実行されません。

5. 仮表を元の表と同期化できます。オンライン再定義の開始後に元の表に多数のDML操作が適用されている場合は、DBMS_REDEFINITION.SYNC_INTERIM_TABLEプロシージャを実行します。これにより、DBMS_REDEFINITION.FINISH_REDEF_TABLEプロシージャの所要時間が短縮されます。次のようにコマンドを入力します。

DBMS_REDEFINITION.SYNC_INTERIM_TABLE('scott', 'emp', 'int_emp');

6. DBMS_REDEFINITION.FINISH_REDEF_TABLEプロシージャを実行します。次のようにコマンドを入力します。

DBMS_REDEFINITION.FINISH_REDEF_TABLE('scott', 'emp', 'int_emp');

このプロセスが完了すると、次の条件が満たされます。

- 元の表は、仮表のすべての属性、索引、制約、権限付与およびトリガーを持つように再定義されます。

- 仮表に適用される参照制約が、再定義後の元の表に適用されます。

7. 仮表を削除します。次のような文を入力します。

DROP TABLE int_emp;

表のオンライン再定義タスクの結果は、次のようになります。

- 元の表がUnicode列に移行されます。

- START_REDEF_TABLEサブプログラムからFINISH_REDEF_TABLEサブプログラムまでに、仮表に対して定義されたトリガー、権限付与、索引および制約が、再定義後の元の表に定義されます。仮表に適用される参照制約が、再定義後の元の表に適用され、使用可能になります。

- 再定義前に元の表に定義されていたトリガー、権限付与、索引および制約が仮表に転送され、仮表を削除すると一緒に削除されます。仮表に再定義を適用する前に元の表に適用されていた参照制約が、使用禁止になります。

- 再定義前に元の表に定義されていたPL/SQLプロシージャとカーソルが無効になります。これらは、次回に使用されるときに自動的に再検証されます。表の定義が変更されているため、再検証は失敗することがあります。

関連項目:
表のオンライン再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

キャラクタ・セット移行後の変換に関する考慮事項

移行後のデータベース・スキーマを元の状態にリカバリするために、追加のタスクが必要になる場合があります。表11-2に、考慮が必要な問題を示します。

表11-2 移行したデータベース・スキーマのリカバリ中の問題

問題

説明

索引

ALTER TABLE MODIFY文によって表の列がCHARデータ型からNCHARデータ型に変更されると、その列に作成される索引はデータベースによって自動的に変更されます。このため、ALTER TABLE MODIFY文のパフォーマンスが低下します。ALTER TABLE MODIFY文を発行する前に索引を削除した場合は、移行後に再作成します。

制約

移行前に制約を使用禁止にした場合は、移行後に再び使用可能にします。

トリガー

移行前にトリガーを使用禁止にした場合は、移行後に再び使用可能にします。

レプリケーション

Unicodeデータ型に移行する列が複数のサイト間でレプリケートされる場合は、マスター定義サイトで変更を実行する必要があります。これにより、変更が他のサイトに伝播します。

バイナリ順序

データベースとNCHARデータのキャラクタ・セットが異なる場合、CHARデータ型からNCHARデータ型への移行にはキャラクタ・セット変換が伴います。エンコーディングが異なると、同じデータのバイナリ順序が異なる可能性があります。これは、バイナリ順序に依存するアプリケーションに影響します。

アプリケーション

アプリケーションのAPIコールを変更して、入力変数および出力変数のキャラクタ・セット・フォームをNCHARに設定する必要があります。正確な変更内容はAPIごとに異なります。一般的なOracle APIで必要な変更は、第7章「Unicodeを使用したプログラミング」を参照してください。

12 Character Set Scannerユーティリティ

この章では、Language and Character Set File ScannerとDatabase Character Set Scannerについて説明します。Character Set Scannerユーティリティは、有効なデータと無効なデータを検出して検証するためのツールです。Language and Character Set File Scannerはテキスト・ファイルをサポートしますが、Database Character Set Scannerはデータベース内でデータをスキャンします。

ここでは、次の項目について説明します。

- Language and Character Set File Scanner

- Database Character Set Scanner

- Database Character Set Scannerのスキャン・モード

- Database Character Set Scannerのインストールと起動

- Database Character Set Scannerパラメータ

- Database Character Set Scannerセッション: 例

- Database Character Set Scannerレポート

- データ・ディクショナリ内の変換可能データまたは不可逆データを処理する方法

- Database Character Set Scannerの記憶域とパフォーマンスに関する考慮事項

- Database Character Set ScannerのCSALTERスクリプト

- Database Character Set Scannerのビュー

- Database Character Set Scannerエラー・メッセージ

Language and Character Set File Scanner

Language and Character Set File Scanner(LCSSCAN)は、統計に基づく高パフォーマンスのユーティリティであり、不明なファイル・テキストの言語とキャラクタ・セットを判別します。様々な言語とキャラクタ・セットのペアを自動的に識別できます。言語およびキャラクタ・セット検出エンジンでは、各テキストを使用して一連の確率が設定され、各確率は1つの言語およびキャラクタ・セットのペアに対応します。統計的に最も可能性の高いペアにより、主要な言語とキャラクタ・セットが識別されます。

テキストの純粋性は、言語およびキャラクタ・セット検出の正確さに影響します。理想的なケースは、スペルや構文の誤りのない単一言語による文章です。この種のテキストには100文字以上のデータを必要とする場合があり、信頼率の高い結果を戻すことができます。これに対して、ある種の技術文書は、より長いセグメントにしなければ認識されない場合があります。ドキュメントに複数の言語やキャラクタ・セット、住所、電話番号などのテキストまたはプログラミング言語コードが混在していると、適切な結果が得られない可能性があります。たとえば、ドキュメントにフランス語とドイツ語の両方が埋め込まれていると、どちらかの言語が正常に推測される精度は統計的に減少します。プレーン・テキストとHTMLの両方のファイルが受け入れられます。書式が判明している場合は、精度を上げるためにFORMATパラメータを設定する必要があります。

この項の内容は、次のとおりです。

- LCSSCANコマンドの構文

- 例: LCSSCANコマンドの使用

- Language and Character Set File Scannerのコマンドライン・ヘルプの利用

- サポート対象の言語とキャラクタ・セット

- LCSSCANエラー・メッセージ

LCSSCANコマンドの構文

Language and Character Set File Scannerを起動するには、LCSSCANコマンドを使用します。構文は次のとおりです。

LCSSCAN  [RESULTS=number] [FORMAT=file_type] [BEGIN=number] [END=number] FILE=file_name

ここでは、各パラメータについて説明します。

RESULTS

RESULTSパラメータはオプションです。

プロパティ

説明

デフォルト値

1

最小値

1

最大値

3

用途

戻される言語とキャラクタ・セットのペアの数。確率順に表示されます。最初の選択肢の比較重量は定量化できません。このパラメータの推奨値は、デフォルト値1です。

FORMAT

FORMATパラメータはオプションです。

プロパティ

説明

デフォルト値

text

用途

スキャン対象となるファイルのタイプを識別します。可能な値は、html、textおよびautoです。

BEGIN

BEGINパラメータはオプションです。

プロパティ

説明

デフォルト値

1

最小値

1

最大値

ファイルのバイト数

用途

入力ファイル内でLCSSCANによるスキャン処理の開始位置を示すバイト。デフォルト値は入力ファイルの1バイト目です。

END

ENDパラメータはオプションです。

プロパティ

説明

デフォルト値

ファイルの終わり

最小値

3

最大値

ファイルのバイト数

用途

入力ファイル内でLCSSCANによりスキャンされる最終バイト。デフォルト値は入力ファイルの最終バイトです。

FILE

FILEは必須パラメータです。

プロパティ

説明

デフォルト値

なし

用途

スキャン対象となるテキスト・ファイルの名前を指定します。

例: LCSSCANコマンドの使用

例12-1 LCSSCANコマンドでファイル名のみを指定する例

LCSSCAN FILE=example.txt

この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.txtファイル全体がスキャンされます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。

例12-2 書式をHTMLに指定する例

LCSSCAN FILE=example.html FORMAT=html

この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.htmlファイル全体がスキャンされます。このスキャンでは、スキャンする前にHTMLタグが取り除かれるため、より正確な結果を得られます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。

例12-3 LCSSCANに対してRESULTSおよびBEGINパラメータを指定する例

LCSSCAN RESULTS=2 BEGIN=50 FILE=example.txt

スキャン処理はファイルの50バイト目から始まり、ファイルの終わりまで続行されます。言語とキャラクタ・セットのペアが2つ戻されます。

例12-4 LCSSCANに対してRESULTSおよびENDパラメータを指定する例

LCSSCAN RESULTS=3 END=100 FILE=example.txt

スキャン処理はファイルの先頭から始まり、ファイルの100バイト目で終了します。言語とキャラクタ・セットのペアが3つ戻されます。

例12-5 LCSSCANに対してBEGINおよびENDパラメータを指定する例

LCSSCAN BEGIN=50 END=100 FILE=example.txt

スキャン処理はファイルの50バイト目から始まり、ファイルの100バイト目で終了します。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。

Language and Character Set File Scannerのコマンドライン・ヘルプの利用

Language and Character Set File Scannerパラメータのサマリーを取得するには、次のコマンドを入力します。

LCSSCAN HELP=y

このコマンドを実行すると、出力にはLanguage and Character Set File Scannerパラメータのサマリーが表示されます。

サポート対象の言語とキャラクタ・セット

Language and Character Set File Scannerは、言語ごとに複数のキャラクタ・セットをサポートしています。

言語のバイナリ値が、サブセット/スーパーセット関係を持つ複数のエンコーディングと一致する場合は、サブセットのキャラクタ・セットが戻されます。たとえば、言語がドイツ語ですべての文字が7ビットの場合は、WE8MSWIN1252、WE8ISO8859P15またはWE8ISO8859P1のかわりにUS7ASCIIが戻されます。

キャラクタ・セットがUTF-8であると判別されると、テキスト内で4バイト文字(補助文字)が検出されないかぎり、デフォルトでOracleのキャラクタ・セットUTF8が戻されます。4バイト文字が検出されると、キャラクタ・セットはAL32UTF8としてレポートされます。

関連項目:
サポートされている言語とキャラクタ・セットのリストは、「言語およびキャラクタ・セット検出のサポート」を参照してください。

LCSSCANエラー・メッセージ

LCD-00001 An unknown error occured.

原因: 内部構造へのアクセス中にエラーが発生しました。

処置: このエラーをOracleサポートに連絡してください。

LCD-00002 NLS data could not be loaded.

原因: $ORACLE_HOME/nls/dataへのアクセス中にエラーが発生しました。

処置: $ORACLE_HOME/nls/dataが存在し、アクセス可能かどうかを確認してください。このディレクトリが見つからない場合は、$ORA_NLS10ディレクトリを調べてください。

LCD-00003 An error occurred while reading the profile file.

原因: $ORACLE_HOME/nls/dataへのアクセス中にエラーが発生しました。

処置: $ORACLE_HOME/nls/dataが存在し、アクセス可能かどうかを確認してください。このディレクトリが見つからない場合は、$ORA_NLS10ディレクトリを調べてください。

LCD-00004 The beginning or ending offset has been set incorrectly.

原因: 開始オフセットと終了オフセットは、1以上の整数である必要があります。

処置: オフセットを正数に変更してください。

LCD-00005 The ending offset has been set incorrectly.

原因: 終了オフセットは開始オフセットよりも大きい値に設定する必要があります。

処置: 終了オフセットを開始オフセットよりも大きい値に変更してください。

LCD-00006 An error occurred when opening the input file.

原因: ファイルが見つからないか、オープンできません。

処置: 指定したファイル名を確認してください。完全ファイル名を指定したかどうかと、ファイルが使用中でないかどうかを確認してください。

LCD-00007 The beginning offset has been set incorrectly.

原因: 開始オフセットは、ファイルのバイト数よりも小さい値に設定する必要があります。

処置: ファイルのサイズを確認して開始オフセットの設定値を小さくしてください。

LCD-00008 No result was returned.

原因: 入力されたテキストが短いため、結果を生成できません。

処置: 信頼できる結果を生成するには、より大きいサンプル・テキストを入力する必要があります。

Database Character Set Scanner

Database Character Set Scannerは、Oracleデータベースから新しいデータベース・キャラクタ・セットへの移行の実現可能性を査定します。Database Character Set Scannerにより、データベースのすべての文字データがチェックされ、キャラクタ・セット・エンコーディングの変更による影響と問題点がテストされます。スキャンの終了時には、データベースを新規キャラクタ・セットに変換するために必要な作業の範囲を示すサマリー・レポートが生成されます。

サマリー・レポートの情報を参考にして、管理者は、データベースのキャラクタ・セットを移行する最も適切な方法を決定できます。次の移行方法があります。

- エクスポート・ユーティリティとインポート・ユーティリティ

- CSALTERスクリプト

- 選択した表に対するエクスポート・ユーティリティおよびインポート・ユーティリティとCSALTERスクリプト

注意:
Database Character Set Scannerで変換例外が示される場合は、後述の方法を使用する前に、その問題を修正する必要があります。この修正には、問題のデータを分析し修正して、これらの例外を取り除く作業も含まれます。極端な例では、データベースとアプリケーションの両方の修正が必要となる場合もあります。データベース・キャラクタ・セットの移行に関するサービスについては、Oracleコンサルティング・サービスにお問い合せください。

関連項目:
「既存のデータベースのデータベース・キャラクタ・セットの変更」

文字データの変換テスト

Database Character Set Scannerは、文字データを読み取り、各データ・セルについて次の条件をテストします。

- 新規キャラクタ・セットへの変換時に、データ・セルの文字コード・ポイントが変わるかどうか

- データ・セルは新規キャラクタ・セットに正常に変換できるかどうか

- 変換後のデータは現行の列サイズに適合するかどうか

Database Character Set Scannerは、ネストした表に加えて、CHAR、VARCHAR2、LONG、CLOB、NCHAR、NVARCHAR2、NCLOBおよびVARRAY列のデータを読み取ってテストします。LONG、CLOBおよびNCLOB列については、変換後の列サイズのテストは実行しません。

Database Character Set Scannerのスキャン・モード

Database Character Set Scannerには、次の4つのデータベース・スキャン・モードがあります。

- 全データベース・スキャン

- ユーザー・スキャン

- 表スキャン

- 列スキャン

全データベース・スキャン

Database Character Set Scannerは、データ・ディクショナリ(SYSおよびSYSTEMユーザー)も含めたデータベース内の全ユーザーに属しているすべての表の文字データを読み取って検証し、新規データベース・キャラクタ・セットへの擬似的な移行による影響をレポートします。ストアド・パッケージ、プロシージャ、ファンクションおよびデータ・ディクショナリの一部として格納されているオブジェクト定義を含めて、すべてのスキーマ・オブジェクトがスキャンされます。

新規データベース・キャラクタ・セットへのデータベース移行の実現可能性を把握するには、全データベース・スキャンを実行する必要があります。

ユーザー・スキャン

Database Character Set Scannerは、指定したユーザーに属しているすべての表の文字データを読み取って検証し、キャラクタ・セットの変更による表への影響をレポートします。

表スキャン

Database Character Set Scannerは、指定した表の文字データを読み取って検証し、キャラクタ・セットの変更による表への影響をレポートします。

列スキャン

Database Character Set Scannerは、指定した列の文字データを読み取って検証し、キャラクタ・セットの変更による表への影響をレポートします。

Database Character Set Scannerのインストールと起動

この項では、Database Character Set Scannerをインストールして起動する方法について説明します。内容は次のとおりです。

- Database Character Set Scanner用のアクセス権限

- Database Character Set Scannerのシステム表のインストール

- Database Character Set Scannerの起動

- Database Character Set Scannerパラメータ・ファイルの作成

- Database Character Set Scannerのコマンドライン・ヘルプの利用

Database Character Set Scanner用のアクセス権限

Database Character Set Scannerを使用するには、Oracle DatabaseのSYSDBA権限が必要です。

Database Character Set Scannerのシステム表のインストール

Database Character Set Scannerを使用する前に、スキャンするデータベースで必要なシステム表を設定するために、csminst.sqlスクリプトを実行する必要があります。csminst.sqlスクリプトを実行する必要があるのは1回のみです。このスクリプトは、次の作業を実行して、データベースをスキャンする準備を行います。

- ユーザー名CSMIGの作成

- 必要な権限のCSMIGへの割当て

- デフォルト表領域のCSMIGへの割当て

- CSMIGの下にCharacter Set Scannerのシステム表を作成

csminst.sqlスクリプトを編集すると、CSMIGのデフォルト表領域を変更できます。csminst.sqlで次の文を変更し、次のように、指定した表領域をCSMIGに割り当てます。

ALTER USER csmig DEFAULT TABLESPACE tablespace_name;

データベースをスキャンする前に、割り当てられた表領域に使用可能な記憶域が十分にあることを確認する必要があります。必要な領域の量は、スキャンのタイプおよびデータベース内のデータの性質によって異なります。

関連項目:
「Database Character Set Scannerの記憶域とパフォーマンスに関する考慮事項」

UNIXプラットフォームの場合は、次のコマンドとSQL文を使用してcsminst.sqlを実行します。

% cd $ORACLE_HOME/rdbms/admin
% sqlplus sys/password as sysdba
SQL> START csminst.sql

Database Character Set Scannerの起動

Database Character Set Scannerは、次のいずれかの方法でコマンドラインから起動できます。

- Database Character Set Scannerパラメータ・ファイルを使用する方法。

CSSCAN username/password PARFILE=file_name

- コマンドラインを使用してパラメータ値を指定する方法。次に例を示します。

CSSCAN username/password FULL=y TOCHAR=al32utf8 ARRAY=10240 PROCESS=3

- 対話型セッションを使用する方法。

CSSCAN username/password

対話型セッションでは、次のパラメータの値を入力するように求められます。

FULL/TABLE/USER
TOCHAR
ARRAY
PROCESS

他のパラメータを指定する場合は、Database Character Set Scannerパラメータ・ファイルを使用するか、またはCSSCANコマンドでパラメータ値を指定します。

Database Character Set Scannerパラメータ・ファイルの作成

Database Character Set Scannerパラメータ・ファイルを使用すると、ファイルにDatabase Character Set Scannerパラメータを指定でき、パラメータの変更や再利用を簡単に実行できます。パラメータ・ファイルの作成にはテキスト・エディタを使用します。

Database Character Set Scannerパラメータ・ファイル内で、次のいずれかの書式を使用してパラメータを指定します。

parameter_name=value
parameter_name=(value1, value2, ...)

シャープ(#)記号を前に付けて文を記述すると、パラメータ・ファイルにコメントを追加できます。シャープ記号の右側の文字はすべて無視されます。

パラメータ・ファイルの例を次に示します。

USERID='sys as sysdba'
USER=HR # scan HR tables
TOCHAR=al32utf8
ARRAY=4096000
PROCESS=2 # use two concurrent scan processes
FEEDBACK=1000

関連項目:
「Database Character Set Scannerパラメータ」

Database Character Set Scannerのコマンドライン・ヘルプの利用

Database Character Set Scannerには、コマンドライン・ヘルプが用意されています。次のコマンドを入力します。

CSSCAN HELP=Y

このコマンドを実行すると、出力にはDatabase Character Set Scannerパラメータのサマリーが表示されます。

Database Character Set Scannerパラメータ

次の表に、Database Character Set Scannerのパラメータのサマリーを示します。表に続いて、各パラメータの詳細を説明します。

パラメータ

デフォルト

プロンプト

説明

USERID

-

あり

ユーザー名/パスワード

FULL

N

あり

データベース全体のスキャン

USER

-

あり

スキャンする表の所有者

TABLE

-

あり

スキャンする表のリスト

EXCLUDE

-

なし

除外する表のリスト

TOCHAR

-

あり

新規のデータベース・キャラクタ・セット名

FROMCHAR

-

なし

現行のデータベース・キャラクタ・セット名

TONCHAR

-

なし

新規の各国語キャラクタ・セット名

FROMNCHAR

-

なし

現行の各国語キャラクタ・セット名

ARRAY

1024000

あり

配列フェッチ・バッファのサイズ

PROCESS

1

あり

同時スキャン・プロセス数

MAXBLOCKS

-

なし

分割しない場合の表の最大許容ブロック数

CAPTURE

N

なし

変換可能なデータの取得

COLUMN

-

なし

スキャンする列のリスト

QUERY

-

なし

スキャンの前に出力の制限に適用する問合せ

SUPPRESS

-

なし

表ごとにログに記録される最大例外数

FEEDBACK

-

なし

n行ごとに進行をレポート

BOUNDARIES

-

なし

サマリー・レポートの列サイズ境界のリスト

LASTRPT

N

なし

前回のデータベース・スキャンのレポートを生成

LOG

scan

なし

レポート・ファイルのベース・ファイル名

PARFILE

-

なし

パラメータ・ファイル名

PRESERVE

N

なし

既存のスキャン結果の保持

LCSD

N

なし

言語およびキャラクタ・セット検出の有効化

LCSDDATA

LOSSY

なし

言語およびキャラクタ・セット検出の有効範囲の定義

HELP

N

なし

ヘルプ画面の表示

ARRAY

プロパティ

説明

デフォルト値

1024000

最小値

4096

最大値

無制限

用途

データのフェッチに使用される配列バッファのサイズをバイト単位で指定します。配列バッファのサイズによって、一度にフェッチされる行数が決まります。

次の式で、指定の表について一度にフェッチされる行数が見積もられます。

rows fetched =
(ARRAY value) / [(sum of all the CHAR and VARCHAR2 column sizes) +
(number of CLOB columns * 4000) + (number of VARRAY columns * 4000)]

たとえば、表AにCHAR列が2つ(5バイトと10バイト)、VARCHAR2列が2つ(100バイトと200バイト)およびCLOB列が1つあるとします。ARRAY=1024000(デフォルト)の場合、フェッチされる行数は次のように計算されます。

1024000/[5 + 10 + 100 + 200 + (1*4000) + (0*4000)] = 237.3

Database Character Set Scannerでは、表Aから一度に23行のデータをフェッチできます。

分母の合計がARRAYパラメータの値を超える場合は、一度に1行のみがフェッチされます。LONG列がある表は、一度に1行のみがフェッチされます。

このパラメータは、データベース・スキャンの処理時間に影響を与えます。通常、配列バッファのサイズが大きくなると、処理時間は短くなります。スキャン・プロセスごとに、指定したサイズの配列バッファが割り当てられます。

BOUNDARIES

プロパティ

説明

デフォルト値

なし

用途

アプリケーション・データの変換サマリー・レポートに使用される列境界サイズのリストを指定します。このパラメータは、CHAR、VARCHAR2、NCHARおよびNVARCHAR2データ型のアプリケーション・データの分散位置を示すために使用されます。

たとえば、BOUNDARIES値を(10, 100, 1000)と指定すると、アプリケーション・データの変換サマリー・レポートは、CHARデータをその列の長さによって、CHAR(1..10)、CHAR(11..100)およびCHAR(101..1000)のグループに分割します。この動作は、VARCHAR2、NCHARおよびNVARCHAR2データ型の場合も同様です。

CAPTURE

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

デフォルトの例外行のみの格納に加えて、変換可能な個々の行に関する情報を取得するかどうかを示します。CAPTUREパラメータをY設定すると、変換可能行に関する情報がCSM$ERRORS表に書き込まれます。これによって、変換先キャラクタ・セットへの変換時に、変換する必要のあるデータが記録されます。また、CAPTUREをYに設定すると、データ・ディクショナリのCONVERTIBLEデータ・セルが、データベース・スキャンの個別例外レポートscan.errにリストされます。CAPTUREをYに設定すると、スキャンの完了に必要な時間が長くなり、必要な記憶容量が増える場合があります。

COLUMN

プロパティ

説明

デフォルト値

なし

用途

スキャンする列の名前を指定します。

このパラメータを指定すると、指定した列がスキャンされます。列の名前は次の方法で指定できます。

- schemanameでは、スキャンする表を含むユーザー・スキーマの名前を指定します。

- tablenameでは、スキャンする列を含む表の名前を指定します。

- columnnameでは、スキャンする列の名前を指定します。

たとえば、次のコマンドでは、hrサンプル・スキーマ内のLASTNAMEおよびFIRSTNAME列がスキャンされます。

CSSCAN "'sys as sysdba'" COLUMN=(HR.EMPLOYEES.LASTNAME, HR.EMPLOYEES.FIRSTNAME) ...

EXCLUDE

プロパティ

説明

デフォルト値

なし

用途

スキャンから除外する表の名前を指定します。

このパラメータを指定すると、指定した表がスキャン対象から除外されます。表の名前は次の方法で指定できます。

- schemanameでは、除外する表を含むユーザー・スキーマの名前を指定します。

- tablenameでは、除外する1つ以上の表の名前を指定します。

たとえば、次のコマンドでは、employeesおよびdepartments表を除き、hrサンプル・スキーマに属している表がすべてスキャンされます。

CSSCAN "'sys as sysdba'" USER=HR EXCLUDE=(HR.EMPLOYEES , HR.DEPARTMENTS) ...

FEEDBACK

プロパティ

説明

デフォルト値

なし

最小値

100

最大値

100000

用途

N行がスキャンされるたびに、ドットが1つ表示される形式で進捗メーターを表示することを指定します。

たとえば、FEEDBACK=1000と指定すると、1000行がスキャンされるたびにドットが1つ表示されます。FEEDBACK値は、スキャン対象の表すべてに適用されます。表ごとに個別に設定することはできません。

FROMCHAR

プロパティ

説明

デフォルト値

なし

用途

データベース内のCHAR、VARCHAR2、LONGおよびCLOBデータ型の現行のキャラクタ・セット名を指定します。デフォルトでは、前述のデータ型のキャラクタ・セットは、データベース・キャラクタ・セットであるとみなされます。

このパラメータを使用すると、データベース内のCHAR、VARCHAR2、LONGおよびCLOBデータのデフォルトのデータベース・キャラクタ・セット定義をオーバーライドできます。

FROMNCHAR

プロパティ

説明

デフォルト値

現行のデータベース・キャラクタ・セット。

用途

データベース内のNCHAR、NVARCHAR2およびNCLOBデータ型の現行の各国語データベース・キャラクタ・セット名を指定します。デフォルトでは、前述のデータ型のキャラクタ・セットは、各国語データベース・キャラクタ・セットであるとみなされます。

このパラメータを使用すると、データベース内のNCHAR、NVARCHAR2およびNCLOBデータのデフォルトのデータベース・キャラクタ・セット定義をオーバーライドできます。

FULL

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

全データベース・スキャンを実行するかどうか(つまり、データ・ディクショナリも含めてデータベース全体をスキャンするかどうか)を示します。全データベース・モードでスキャンする場合はFULL=Yを指定します。

関連項目:
全データベース・スキャンの詳細は、「Database Character Set Scannerのスキャン・モード」を参照してください。

HELP

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

Database Character Set Scannerパラメータの説明が記述されたヘルプ・メッセージを表示します。

関連項目:
Database Character Set Scannerのコマンドライン・ヘルプの利用

LASTRPT

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

直前のデータベース・スキャンで収集した統計情報に基づいて、Database Character Set Scannerレポートを再生成するかどうかを示します。

LASTRPT=Yと指定すると、データベースはスキャンされず、かわりに以前のデータベース・スキャン・セッションが残した情報を使用してレポート・ファイルが作成されます。

LASTRPT=Yを指定した場合は、USERID、BOUNDARIESおよびLOGパラメータのみが有効です。

LCSD

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

スキャン中に言語およびキャラクタ・セット検出を適用するかどうかを示します。

LCSD=Yを指定すると、Database Character Set Scanner(CSSCAN)はLCSDDATAパラメータで分類されたデータ・セルに対して言語およびキャラクタ・セット検出を実行します。検出精度は、分析するテキストのサイズと品質に大きく左右されます。理想的なケースは、スペルや構文の誤りのない単一言語による文章です。データ・セルに言語、キャラクタ・セットまたは住所や名前などのテキストが混在していると、適切な結果が得られない可能性があります。CSSCANで最も可能性の高い言語とキャラクタ・セットを判別できない場合は、セルごとに最も可能性の高い言語とキャラクタ・セットが最大3つまで戻されます。また、1つも戻されない場合もあります。CSSCANでは、9バイト以下のデータを含むデータ・セルは無視され、その言語とキャラクタ・セットについてはUNKNOWNが戻されます。

言語およびキャラクタ・セット検出は統計に基づくテクノロジであるため、その精度は入力データの品質に応じて異なります。その目的は、CSSCANユーザーにデータベース内の不明データに関する追加情報を提供することです。CSSCANユーザーは、データを他のキャラクタ・セットに移行する前に、検出結果とデータ自体を検討する必要があります。

分析するデータ量によっては、言語およびキャラクタ・セット検出を実行するとDatabase Character Set Scannerのパフォーマンスが低下する可能性があることに注意してください。

関連項目:
「Language and Character Set File Scanner」

LCSDDATA

プロパティ

説明

デフォルト値

LOSSY

値の範囲

LOSSY、TRUNCATION、CONVERTIBLE、CHANGELESS、ALL

用途

言語およびキャラクタ・セット検出の有効範囲を指定します。デフォルトでは、検出はLOSSYデータ・セルにのみ適用されます。

このパラメータは、LCSD=Yを指定している場合にのみ有効です。たとえば、LCSD=YかつLCSDDATA=LOSSY, CONVERTIBLEの場合は、LOSSYまたはCONVERTIBLEであるデータ・セルのキャラクタ・セットと言語の検出が試行されます。CHANGELESSおよびTRUNCATIONとして分類されるデータは処理されません。LCSDDATA=ALLに設定すると、現行のセッションでスキャンされた全データ・セルに対して言語およびキャラクタ・セット検出が実行されます。

CONVERTIBLEおよびTRUNCATIONデータ・セルに言語およびキャラクタ・セット検出が適用された後、一部のデータ・セルが元の分類からLOSSYに変更されることがあります。この分類変更が発生するのは、キャラクタ・セット検出プロセスにより、これらのデータ・セルのキャラクタ・セットがFROMCHARパラメータに指定されているキャラクタ・セットではないと判別された場合です。

LOG

プロパティ

説明

デフォルト値

scan

用途

次のDatabase Character Set Scannerレポート・ファイルのベース・ファイル名を指定します。

- 拡張子が.txtのデータベース・スキャンのサマリー・レポート・ファイル

- 拡張子が.errの個別例外レポート・ファイル

- 拡張子が.outの画面ログ・ファイル

デフォルトでは、現行のディレクトリにscan.txt、scan.errおよびscan.outの3つのテキスト・ファイルが生成されます。

MAXBLOCKS

プロパティ

説明

デフォルト値

なし

最小値

1000

最大値

無制限

用途

表ごとの最大ブロック・サイズを指定し、サイズの大きい表をDatabase Character Set Scannerが処理するための小さいチャンクに分割します。

たとえば、MAXBLOCKSパラメータを1000に設定すると、サイズが1000ブロックよりも大きい表は、n個のチャンクに分割されます。この場合は、n=CEIL(table block size/1000)です。

大きい表をいくつかの小さい部分に分割する処理が有効なのは、PROCESSで設定されたプロセスの数が1より大きい場合のみです。MAXBLOCKSパラメータが設定されていない場合、Database Character Set Scannerは独自の最適化ルールに基づいて大きい表の分割を試みます。

PARFILE

プロパティ

説明

デフォルト値

なし

用途

Database Character Set Scannerパラメータのリストが含まれているファイルの名前を指定します。

関連項目:
「Database Character Set Scannerの起動」

PRESERVE

プロパティ

説明

デフォルト値

N

値の範囲

YまたはN

用途

前回のスキャン・セッションから収集された統計を保つかどうかを示します。

PRESERVE=Yと指定すると、前回のスキャンからの統計がすべて保持されます。現行のスキャン・リクエストでスキャンされる表の新規統計は、追加(PRESERVE=Yの場合)または上書き(PRESERVE=Nの場合)されます。

PROCESS

プロパティ

説明

デフォルト値

1

最小値

1

最大値

32

用途

データベース・スキャンに利用するための同時実行スキャン・プロセスの数を指定します。

QUERY

プロパティ

説明

デフォルト値

なし

用途

SELECT文の句を指定することで、スキャンするデータを制限するフィルタを適用します。この句は、スキャナ・セッションのすべての表と列に適用されます。

問合せパラメータの値は、SELECT文のWHERE句を含む文字列です。この句は、TABLEパラメータとCOLUMNパラメータにリストされたすべての表と列に適用されます。

使用できる問合せ句は、スキャン・セッションごとに1つのみです。QUERYパラメータは、表または列のスキャンを実行する場合のみ適用できます。全データベースまたはユーザーのスキャンを実行する場合、このパラメータは無視されます。QUERYは、複数の表と列のスキャンに適用できますが、指定したすべての表と列に同じWHERE句が追加されます。

たとえば、次のコマンドでは、過去30日以内に雇用された従業員がスキャンされます。

CSSCAN "'sys as sysdba'" TABLE=HR.EMPLOYEES QUERY= 'hire_date > SYSDATE - 180' ...

QUERYパラメータ内では、WHERE句は必要ありません。QUERYパラメータで最初の5文字がWHERE句と認識されると、CSSCANによって、この句は自動的に削除されます。

SUPPRESS

プロパティ

説明

デフォルト値

未設定(行数は無制限)

最小値

0

最大値

無制限

用途

ログに記録されるデータ例外の最大数を表ごとに指定します。

データ・セルで例外が検出されると、CSM$ERRORS表に情報が挿入されます。表は、レポートされる例外数に応じて大きくなります。

このパラメータを使用して、表ごとに指定した数の例外が挿入された後、個々の例外情報のロギングを抑制します。たとえば、SUPPRESSを100に設定すると、表ごとに最大100個の例外レコードが記録されます。

関連項目:
「Database Character Set Scannerの記憶域に関する考慮事項」

TABLE

プロパティ

説明

デフォルト値

なし

用途

スキャンする表の名前を指定します。

表の名前は次の方法で指定できます。

- schemanameでは、スキャンする表を含むユーザー・スキーマの名前を指定します。

- tablenameでは、スキャンする1つ以上の表の名前を指定します。

たとえば、次のコマンドでは、HRサンプル・スキーマ内のemployeesおよびdepartments表がスキャンされます。

CSSCAN "'sys as sysdba'" TABLE=(HR.EMPLOYEES, HR.DEPARTMENTS)

TOCHAR

プロパティ

説明

デフォルト値

なし

用途

CHAR、VARCHAR2、LONGおよびCLOBデータの変換先データベース・キャラクタ・セット名を指定します。

TONCHAR

プロパティ

説明

デフォルト値

なし

用途

NCHAR、NVARCHAR2およびNCLOBデータの変換先データベース・キャラクタ・セット名を指定します。

TONCHARの値を指定しない場合、NCHAR、NVARCHAR2およびNCLOBデータはスキャンされません。

USER

プロパティ

説明

デフォルト値

なし

用途

スキャンする表の所有者を指定します。

USERパラメータを指定すると、指定した所有者に属しているすべての表がスキャンされます。たとえば、次の文を使用すると、HRに属しているすべての表がスキャンされます。

CSSCAN "'sys as sysdba'" USER=hr ...

USERID

プロパティ

説明

デフォルト値

なし

用途

データベースをスキャンするユーザーのユーザー名とパスワード(およびオプションの接続文字列)を指定します。パスワードを省略すると、パスワードの入力を求められます。

次の書式はすべて有効です。

username/password
username/password@connect_string
username
username@connect_string

Database Character Set Scannerセッション: 例

次の例は、コマンドラインおよびパラメータ・ファイルを使用して、全データベース、ユーザー、単一表および列の各スキャン・モードを使用する方法を示しています。

全データベース・スキャンの例

次の例は、データベースをAL32UTF8に移行する場合の影響を調べるために、全データベースをスキャンする方法を示しています。この例では、現行のデータベース・キャラクタ・セットがWE8ISO8859P1であるとします。

例12-6 パラメータ・ファイル方式でデータベースをスキャンする例

% csscan "'sys as sysdba'" parfile=param.txt

param.txtファイルには、次の情報が記述されています。

full=y
tochar=al32utf8
array=4096000
process=4

例12-7 コマンドライン方式でデータベースをスキャンする例

% csscan "'sys as sysdba'" full=y tochar=al32utf8 array=4096000 process=4

Database Character Set Scannerメッセージ

scan.outファイルは、どの表がスキャンされたかを示します。レポートのデフォルト・ファイル名は、LOGパラメータを使用して変更できます。

関連項目:
「LOG」

Database Character Set Scanner vx.x : Release xx.x.x.x.x - Production

Copyright (c) 1982, 200x, Oracle.  All rights reserved.

Connected to:
Oracle Database xxx Enterprise Edition Release xx.x.x.x.x - Production
With the Partitioning and Data Mining options

Enumerating tables to scan...

. process 1 scanning SYS.SOURCE$[AAAABHAABAAAAJqAAA]
. process 2 scanning SYS.TAB$[AAAAACAABAAAAA0AAA]
. process 2 scanning SYS.CLU$[AAAAACAABAAAAA0AAA]
. process 2 scanning SYS.ICOL$[AAAAACAABAAAAA0AAA]
. process 2 scanning SYS.COL$[AAAAACAABAAAAA0AAA]
. process 1 scanning SYS.IND$[AAAAACAABAAAAA0AAA]
. process 1 scanning SYS.TYPE_MISC$[AAAAACAABAAAAA0AAA]
. process 1 scanning SYS.LOB$[AAAAACAABAAAAA0AAA]
.
.
.
. process 1 scanning IX.AQ$_ORDERS_QUEUETABLE_G
. process 2 scanning IX.AQ$_ORDERS_QUEUETABLE_I

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

ユーザー・スキャンの例

次の例は、ユーザー表をAL32UTF8に移行する場合の影響を調べるために、ユーザー表をスキャンする方法を示しています。この例では、現行のデータベース・キャラクタ・セットはUS7ASCIIであるが、格納されている実際のデータは西ヨーロッパのWE8MSWIN1252エンコーディングであると仮定しています。

例12-8 パラメータ・ファイル方式でユーザーをスキャンする例

% csscan "'sys as sysdba'" parfile=param.txt

param.txtファイルには、次の情報が記述されています。

user=hr
fromchar=we8mswin1252
tochar=al32utf8
array=4096000
process=1

例12-9 コマンドライン方式でユーザーをスキャンする例

% csscan "'sys as sysdba'" user=hr fromchar=we8mswin1252
tochar=al32utf8 array=4096000 process=1

Database Character Set Scannerメッセージ

scan.outファイルは、どの表がスキャンされたかを示します。

Database Character Set Scanner vx.x : Release xx.x.x.x.x - Production

Copyright (c) 1982, 200x, Oracle.  All rights reserved.

Connected to:
Oracle Database xxx Enterprise Edition Release xx.x.x.x.x - Production
With the Partitioning and Data Mining options
Copyright (c) 1983, 200x Oracle. All rights reserved.

Enumerating tables to scan...

. process 1 scanning HR.JOBS
. process 1 scanning HR.DEPARTMENTS
. process 1 scanning HR.JOB_HISTORY
. process 1 scanning HR.EMPLOYEES

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

単一表のスキャンの例

次の例は、単一表をWE8MSWIN1252に移行する場合の影響を調べるために、単一表をスキャンする方法を示しています。この例では、現行のデータベース・キャラクタ・セットがUS7ASCIIであるとします。LOSSYデータ・セルに対して言語およびキャラクタ・セット検出が実行されます。

例12-10 パラメータ・ファイル方式で単一表をスキャンする例

% csscan "'sys as sysdba'" parfile=param.txt

param.txtファイルには、次の情報が記述されています。

table=hr.employees
tochar=we8mswin1252
array=4096000
process=1
suppress=100
lcsd=y

例12-11 コマンドライン方式で単一表をスキャンする例

% csscan "'sys as sysdba'" table=hr.employees tochar=we8mswin1252 array=4096000 process=1 supress=100 lcsd=y

Database Character Set Scannerメッセージ

scan.outファイルは、どの表がスキャンされたかを示します。

Database Character Set Scanner vx.x : Release xx.x.x.x.x - Production

Copyright (c) 1982, 200x, Oracle.  All rights reserved.

Connected to:
Oracle Database xxx Enterprise Edition Release xx.x.x.x.x - Production
With the Partitioning and Data Mining options
Copyright (c) 1983, 200x Oracle. All rights reserved.

. process 1 scanning HR.EMPLOYEES

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

次の例は、単一表をWE8MSWIN1252に移行する場合の影響を調べるために、単一表をスキャンする方法を示しています。スキャンする前に、表に対して問合せを実行し、スキャンする行を制限します。この例では、現行のデータベース・キャラクタ・セットはUS7ASCIIであると仮定しています。LOSSYデータ・セルに対して言語およびキャラクタ・セット検出が実行されます。

例12-12 パラメータ・ファイル方式で単一表をスキャンし、WE8MSWIN1252への移行の影響を示す例

% csscan "'sys as sysdba'" parfile=param.txt

param.txtファイルには、次の情報が記述されています。

table=hr.employees
query='hire_date > SYSDATE - 180'
tochar=we8mswin1252
array=4096000
process=1
suppress=100
lcsd=y

例12-13 コマンドライン方式で単一表をスキャンし、WE8MSWIN1252への移行の影響を示す例

% csscan "'sys as sysdba'" table=hr.employees query='hire_date > SYSDATE - 180' tochar=we8mswin1252 array=4096000 process=1 supress=100 lcsd=y

Database Character Set Scannerメッセージ

scan.outファイルは、どの表がスキャンされたかを示します。

Database Character Set Scanner vx.x : Release xx.x.x.x.x - Production

Copyright (c) 1982, 200x, Oracle.  All rights reserved.

Connected to:
Oracle Database xxx Enterprise Edition Release xx.x.x.x.x - Production
With the Partitioning and Data Mining options
Copyright (c) 1983, 200x Oracle. All rights reserved.

. process 1 scanning HR.EMPLOYEES

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

列スキャンの例

次の例は、WE8MSWIN1252に移行する場合の影響を調べるために、単一表内の複数の列をスキャンする方法を示しています。この例では、現行のデータベース・キャラクタ・セットはUS7ASCIIであると仮定しています。LOSSYデータ・セルに対して言語およびキャラクタ・セット検出が実行されます。

例12-14 パラメータ・ファイル方式で列をスキャンする例

% csscan "'sys as sysdba'" parfile=param.txt

param.txtファイルには、次の情報が記述されています。

column=(hr.employees.lastname, hr.employees.firstname)
tochar=we8mswin1252
array=4096000
process=1
suppress=100
lcsd=y

例12-15 コマンドライン方式で列をスキャンする例

% csscan "'sys as sysdba'" column=(hr.employees.lastname, hr.employees.firstname)
tochar=we8mswin1252 array=4096000 process=1 supress=100 lcsd=y

Database Character Set Scannerメッセージ

scan.outファイルは、どの表がスキャンされたかを示します。

Database Character Set Scanner vx.x : Release xx.x.x.x.x - Production

Copyright (c) 1982, 200x, Oracle.  All rights reserved.

Connected to:
Oracle Database xxx Enterprise Edition Release xx.x.x.x.x - Production
With the Partitioning and Data Mining options
Copyright (c) 1983, 200x Oracle. All rights reserved.

. process 1 scanning HR.EMPLOYEES

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

Database Character Set Scannerレポート

Database Character Set Scannerでは、スキャンごとに次の2つのレポートが生成されます。

- データベース・スキャンのサマリー・レポート

- データベース・スキャンの個別例外レポート

データベース・スキャンのサマリー・レポートは、scan.txtファイルに生成されます。データベース・スキャンの個別例外レポートは、scan.errファイルに生成されます。

レポートのデフォルト・ファイル名は、LOGパラメータを使用して変更できます。

関連項目:
「LOG」

データベース・スキャンのサマリー・レポート

scan.txtファイルには、データベース・スキャンのサマリー・レポートが記述されます。次の出力は、レポート・ヘッダーの例を示しています。この項には、各スキャン・プロセスの実行日時が記述されます。

Database Scan Summary Report

Time Started  : 200x-12-16 20:35:56
Time Completed: 200x-12-16 20:37:31

Process ID         Time Started       Time Completed
---------- -------------------- --------------------
1  200x-12-16 20:36:07  2002-12-16 20:37:30
2  200x-12-16 20:36:07  2002-12-16 20:37:30
---------- -------------------- --------------------

レポートは、次の項で構成されます。

- データベース・サイズ

- データベース・スキャン・パラメータ

- スキャン・サマリー

- データ・ディクショナリの変換サマリー

- アプリケーション・データの変換サマリー

- 列サイズ境界ごとのアプリケーション・データの変換サマリー

- 表ごとの変換可能データの分散状態

- 列ごとの変換可能データの分散状態

- 再構築対象の索引

- キャラクタ・セマンティクスによる切捨て

各項に出力される情報は、選択したスキャンのタイプおよびパラメータによって異なります。

データベース・サイズ

この項では、現行のデータベース・サイズがレポートされ、キャラクタ・セット移行後に可能性のあるデータ拡張量が識別されます。

次に出力例を示します。

Tablespace                           Used            Free           Total       Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM                            206.63M         143.38M         350.00M         588.00K
SYSAUX                              8.25M         131.75M         140.00M            .00K
------------------------- --------------- --------------- --------------- ---------------
Total                             214.88M         275.13M         490.00M         588.00K

The size of the largest CLOB is 57370 bytes

データベース・スキャン・パラメータ

この項には、選択したパラメータおよびスキャンのタイプが記述されます。次に出力例を示します。

Parameter                      Value
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1
Instance Name                  rdbms06
Database Version               10.2.0.0.0
Scan type                      Full database
Scan CHAR data?                YES
Database character set         WE8ISO8859P1
FROMCHAR                       WE8ISO8859P1
TOCHAR                         AL32UTF8
Scan NCHAR data?               NO
Array fetch buffer size        1024000
Number of processes            2
Capture convertible data?      NO
Charset Language Detections    Yes
Charset Language Parameter     LOSSY
------------------------------ ------------------------------------------------

スキャン・サマリー

この項には、データベース・キャラクタ・セット移行の実現可能性が示されます。データベースのキャラクタ・セット移行の実現可能性を判断する基本的な規準は2つあります。1つはデータ・ディクショナリの状態で、もう1つはアプリケーション・データの状態です。

関連項目:
「Database Character Set ScannerのCSALTERスクリプト」

スキャン・サマリー・セクションは、次の2つのステータス行で構成されています。1つはデータ・ディクショナリの状態で、もう1つはアプリケーション・データの状態です。

スキャン・サマリーからのサンプル出力を次に示します。

All character type data in the data dictionary are convertible to the new character set
Some character type application data are not convertible to the new character set

表12-1に、データ・ディクショナリとアプリケーション・データに関してレポートできるステータスのタイプを示します。

表12-1 データ・ディクショナリとアプリケーション・データに可能なステータス

データ・ディクショナリのステータス

アプリケーション・データのステータス

データ・ディクショナリ内のキャラクタ・タイプ・データはすべて、新規キャラクタ・セットでも変わりません。

キャラクタ・タイプのアプリケーション・データはすべて、新規キャラクタ・セットでも変わりません。

データ・ディクショナリ内のキャラクタ・タイプ・データはすべて、新規キャラクタ・セットに変換できます。

キャラクタ・タイプのアプリケーション・データはすべて、新規キャラクタ・セットに変換できます。

データ・ディクショナリ内のキャラクタ・タイプ・データの一部は、新規キャラクタ・セットに変換できません。

キャラクタ・タイプのアプリケーション・データの一部は、新規キャラクタ・セットに変換できません。

すべてのデータが新規キャラクタ・セットでも変わらない場合は、変換元キャラクタ・セットのエンコーディング値が、変換先キャラクタ・セットでも同一であることを意味します。たとえば、ASCIIデータは、WE8ISO8859P1でもAL32 UTF8でも同じバイナリ値を使用して格納されます。この場合、データベース・キャラクタ・セットはCSALTERスクリプトを使用して移行できます。

すべてのデータが新規キャラクタ・セットに変換できる場合、データベースはエクスポート・ユーティリティとインポート・ユーティリティを使用して安全に移行できます。ただし、移行後データのエンコーディング値は、変換先キャラクタ・セットでは異なる値になります。

関連項目:

- 変換不可能なデータの詳細は、「データベース・スキャンの個別例外レポート」を参照してください。

- 「CSALTERスクリプトを使用したキャラクタ・セットの移行」

- 「全体エクスポートおよび全体インポートを使用した文字データの移行」

データ・ディクショナリの変換サマリー

この項には、データ・ディクショナリのデータの変換に関する統計情報が記述されます。各種ステータスのデータ・セルの数がデータ型別にレポートされます。データ・ディクショナリの包括的な変換サマリーを実現するには、全データベース・スキャンを使用する必要があります。

表12-2に、データ・セルのステータスに可能なタイプを示します。

表12-2 データに可能なステータス

ステータス

説明

Changeless

データは新規キャラクタ・セットでも変わりません。

Convertible

データ・セルは新規キャラクタ・セットに正常に変換できます。

Truncation

変換時にデータが切り捨てられます。

Lossy

変換時に文字データが失われます。

データ・ディクショナリのデータを変換する方法について詳しい情報を提供するため、データ・ディクショナリ変換サマリー・レポートは、データ・ディクショナリ表とXML CSXディクショナリ表の2つの部分に分かれています。小型バイナリXML(CSX)は、Oracle Database 11gリリース2(11.2)のXML DBで使用されるXMLドキュメントの新しいフォーマットです。XMLドキュメントをCSX列に挿入すると、データベースはCXSデータをアプリケーション・データ部のBLOB列に保存します。同時に、データベースはデータ・ディクショナリに属するXDBユーザーの表にデータを保存します。データ・ディクショナリでは、これらの表はXML CSXディクショナリ表と呼ばれます。

同様に、Convertible、TruncatedおよびLossyデータの表ごとや列ごとの分散を示す表は、データ・ディクショナリ表、XML CSXディクショナリ表、アプリケーション・データという3つの部分から構成されています。

拡張されたデータ・ディクショナリ変換サマリー・レポートの例を次に示します。

Database Scan Summary Report

Time Started  : 2006-08-15 01:13:24
Time Completed: 2006-08-15 01:16:32

Process ID         Time Started       Time Completed
---------- -------------------- --------------------
1  2006-08-15 01:13:28  2006-08-15 01:16:30
---------- -------------------- --------------------

[Database Size]

Tablespace                           Used            Free           Total       Expansion
------------------------- --------------- --------------- --------------- ---------------
SYSTEM                            542.77M           9.82M         552.59M           1.41M
SYSAUX                             80.00M            .00K          80.00M         574.00K
TEMP                                 .00K            .00K            .00K            .00K
XDB_RESINFO                        51.81M          48.19M         100.00M          18.00K
XDB_TEMP                             .00K            .00K            .00K            .00K
------------------------- --------------- --------------- --------------- ---------------
Total                             674.59M          58.01M         732.59M           1.98M

The size of the largest CLOB is 61115 bytes

[Database Scan Parameters]

Parameter                      Value
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1
Instance Name                  cm2
Database Version               11.1.0.0.0
Scan type                      Full database
Scan CHAR data?                YES
Database character set         WE8ISO8859P1
FROMCHAR                       we8iso8859p1
TOCHAR                         utf8
Scan NCHAR data?               YES
NCHAR character set            AL16UTF16
FROMNCHAR                      al16utf16
TONCHAR                        utf8
Array fetch buffer size        102400
Number of processes            1
Capture convertible data?      NO
------------------------------ ------------------------------------------------

[Scan Summary]

All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set

[Data Dictionary Conversion Summary]

Data Dictionary Tables:

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                     3,294,477                0                0                0
CHAR                             1,941                0                0                0
LONG                           133,551                0                0                0
CLOB                            21,633              841                0                0
NVARCHAR2                            0                0                0                0
NCHAR                                0                0                0                0
NCLOB                                0                0                0                0
VARRAY                          26,965                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                        3,478,567              841                0                0
Total in percentage             99.976%           0.024%           0.000%           0.000%

The data dictionary can be safely migrated using the CSALTER script

XML CSX Dictionary Tables:

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                           173                8                0                0
CHAR                                 0                0                0                0
LONG                                 0                0                0                0
CLOB                                 0                0                0                0
NVARCHAR2                            0                0                0                0
NCHAR                                0                0                0                0
NCLOB                                0                0                0                0
VARRAY                               0                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                              173                8                0                0
Total in percentage             95.580%           4.420%           0.000%           0.000%

[Application Data Conversion Summary]

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                        36,011                0                0                0
CHAR                             5,533                0                0                0
LONG                                 0                0                0                0
CLOB                                27               26                0                0
NVARCHAR2                            0           17,280                0                0
NCHAR                                0                0                0                0
NCLOB                                4                0                0                0
VARRAY                             319                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                           41,894           17,306                0                0
Total in percentage             70.767%          29.233%           0.000%           0.000%

[Distribution of Convertible, Truncated and Lossy Data by Table]

Data Dictionary Tables:

USER.TABLE                                              Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
SYS.EXTERNAL_TAB$                                                 1                0                0
SYS.METASTYLESHEET                                              145                0                0
SYS.RULE$                                                         1                0                0
SYS.SCHEDULER$_EVENT_LOG                                         26                0                0
SYS.WRH$_SQLTEXT                                                239                0                0
SYS.WRH$_SQL_PLAN                                               217                0                0
SYS.WRI$_ADV_DIRECTIVE_META                                       5                0                0
SYS.WRI$_ADV_OBJECTS                                              1                0                0
SYS.WRI$_DBU_FEATURE_METADATA                                    94                0                0
SYS.WRI$_DBU_FEATURE_USAGE                                        3                0                0
SYS.WRI$_DBU_HWM_METADATA                                        17                0                0
SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY                                71                0                0
SYS.WRI$_REPT_FILES                                               4                0                0
XDB.XDB$RESCONFIG                                                 9                0                0
XDB.XS$PRINCIPALS                                                 1                0                0
XDB.XS$SECURITYCLASS                                              7                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

XML CSX Dictionary Tables:

USER.TABLE                                              Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
XDB.X$QN0S0VE2C21FAJ8E0G5PHDLAO3BO                                8                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

Application Data:

USER.TABLE                                              Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
OE.PRODUCT_DESCRIPTIONS                                      17,280                0                0
OE.WAREHOUSES                                                     4                0                0
PM.ONLINE_MEDIA                                                  14                0                0
PM.PRINT_MEDIA                                                    8                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

[Distribution of Convertible, Truncated and Lossy Data by Column]

Data Dictionary Tables:

USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
SYS.EXTERNAL_TAB$|PARAM_CLOB                                      1                0                0
SYS.METASTYLESHEET|STYLESHEET                                   145                0                0
SYS.RULE$|CONDITION                                               1                0                0
SYS.SCHEDULER$_EVENT_LOG|ADDITIONAL_INFO                         26                0                0
SYS.WRH$_SQLTEXT|SQL_TEXT                                       239                0                0
SYS.WRH$_SQL_PLAN|OTHER_XML                                     217                0                0
SYS.WRI$_ADV_DIRECTIVE_META|DATA                                  5                0                0
SYS.WRI$_ADV_OBJECTS|ATTR4                                        1                0                0
SYS.WRI$_DBU_FEATURE_METADATA|INST_CHK_LOGIC                     11                0                0
SYS.WRI$_DBU_FEATURE_METADATA|USG_DET_LOGIC                      83                0                0
SYS.WRI$_DBU_FEATURE_USAGE|FEATURE_INFO                           3                0                0
SYS.WRI$_DBU_HWM_METADATA|LOGIC                                  17                0                0
SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY|EXPRESSION                     71                0                0
SYS.WRI$_REPT_FILES|SYS_NC00005$                                  4                0                0
XDB.XDB$RESCONFIG|XMLDATA                                         9                0                0
XDB.XS$PRINCIPALS|XMLDATA                                         1                0                0
XDB.XS$SECURITYCLASS|XMLDATA                                      7                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

XML CSX Dictionary Tables:

USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
XDB.X$QN0S0VE2C21FAJ8E0G5PHDLAO3BO|LOCALNAME                      8                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

Application Data:

USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
-------------------------------------------------- ---------------- ---------------- ----------------
OE.PRODUCT_DESCRIPTIONS|TRANSLATED_DESCRIPTION                8,640                0                0
OE.PRODUCT_DESCRIPTIONS|TRANSLATED_NAME                       8,640                0                0
OE.WAREHOUSES|SYS_NC00003$                                        4                0                0
PM.ONLINE_MEDIA|SYS_NC00042$                                      7                0                0
PM.ONLINE_MEDIA|SYS_NC00062$                                      7                0                0
PM.PRINT_MEDIA|AD_FINALTEXT                                       4                0                0
PM.PRINT_MEDIA|AD_SOURCETEXT                                      4                0                0
-------------------------------------------------- ---------------- ---------------- ----------------

[Indexes to be Rebuilt]

USER.INDEX on USER.TABLE(COLUMN)
-----------------------------------------------------------------------------------------
SYS.I_WRI$_OPTSTAT_HH_ST on SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY(SYS_NC00024$)
SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST on SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY(SYS_NC00024$)
SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST on SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY(OBJ#)
SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST on SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY(INTCOL#)
SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST on SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY(COLNAME)
OE.PROD_NAME_IX on OE.PRODUCT_DESCRIPTIONS(TRANSLATED_NAME)
XDB.X$QQ0S0VE2C21FAJ8E0G5PHDLAO3BO on XDB.X$QN0S0VE2C21FAJ8E0G5PHDLAO3BO(NMSPCID)
XDB.X$QQ0S0VE2C21FAJ8E0G5PHDLAO3BO on XDB.X$QN0S0VE2C21FAJ8E0G5PHDLAO3BO(LOCALNAME)
XDB.X$QQ0S0VE2C21FAJ8E0G5PHDLAO3BO on XDB.X$QN0S0VE2C21FAJ8E0G5PHDLAO3BO(FLAGS)
-----------------------------------------------------------------------------------------

以前のリリースでのデータ・ディクショナリ変換サマリー・レポートの例を次に示します。

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                     1,214,557                0                0                0
CHAR                               967                0                0                0
LONG                            88,657                0                0                0
CLOB                               138              530                0                0
VARRAY                              18                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                        1,304,337              530                0                0
Total in percentage             99.959%           0.041%           0.000%           0.000%

The data dictionary can be safely migrated using the CSALTER script.

データ・ディクショナリ表およびXML CXSディクショナリ表で、Convertible、TruncationおよびLossy列に記録されたデータ・セルの数が0(ゼロ)の場合は、データ・ディクショナリをそのままFROMCHARキャラクタ・セットからTOCHARキャラクタ・セットに移行でき、データ変換は必要ありません。

データ・ディクショナリ表およびXML CSXディクショナリ表の両方で、TruncationおよびLossy列の数値がすべて0(ゼロ)で、Convertible列に0(ゼロ)以外の数値がある場合は、データ・ディクショナリのすべてのデータが新規キャラクタ・セットに変換できることを意味します。ただし、データベースへの影響を理解していない場合、データ・ディクショナリのデータを変換するのは危険です。XML CSXディクショナリ表の変換可能なセルはすべて安全に変換されるため、データ・ディクショナリ表から暗示的に出力されます。CSALTERスクリプトを使用すると、データ・ディクショナリ内で変換可能な一部のセルを変換できます。変換サマリー表に続くメッセージは、この変換をCSALTERスクリプトでサポートできるかどうかを示します。

データ・ディクショナリ表またはXML CSXディクショナリ表で、Lossy列の数値が0(ゼロ)以外の場合は、データ・ディクショナリに変換できないデータがあります。このため、現行データベースの新規キャラクタへの移行は実現しません。これは、エクスポートおよびインポート・プロセスでデータを新規キャラクタ・セットに変換できないためです。たとえば、表名に無効な文字が使用されていたり、新規キャラクタ・セットにマップできないデータがPL/SQLプロシージャのコメント行に含まれている場合があります。スキーマ・オブジェクトに対するこのような変更は、新規キャラクタ・セットへの移行前に、手動で訂正する必要があります。

データ・ディクショナリ表またはXML CXSディクショナリ表で、Truncation列の数値が0(ゼロ)以外の場合は、エクスポートおよびインポート・プロセスによりデータが切り捨てられます。

関連項目:

- 「Database Character Set ScannerのCSALTERスクリプト」

- 「データ・ディクショナリ内の変換可能データまたは不可逆データを処理する方法」

アプリケーション・データの変換サマリー

この項には、アプリケーション・データの変換サマリーの統計情報が記述されます。各種ステータスのデータ・セルの数がデータ型別にレポートされます。表12-2に、レポートできるステータスのタイプを示します。

次に出力例を示します。

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                        37,757                3                0                0
CHAR                             6,404                0                0                0
LONG                                 4                0                0                0
CLOB                                23               20                0                1
VARRAY                             319                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                           44,507               23                0                1
Total in percentage             99.946%           0.051%               0%           0.002%

列サイズ境界ごとのアプリケーション・データの変換サマリー

この項には、CHARおよびVARCHAR2のアプリケーション・データの変換サマリーが記述されます。各種ステータスのデータ・セルの数は、BOUNDARIESパラメータで指定した列サイズ境界別にレポートされます。表12-2に、使用可能なステータスのタイプを示します。この情報は、BOUNDARIESパラメータが指定されている場合にのみ使用可能です。次に出力例を示します。

Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2(1..30)                 28,702                2                0                0
VARCHAR2(31..4000)               9,055                1                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
CHAR(1..30)                      6,404                0                0                0
CHAR(31..4000)                       0                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                           44,161                3                0                0

表ごとの変換可能データの分散状態

次の項は、Convertible、TruncationおよびLossyデータがデータベース内にどのように分散しているかを示します。統計は、表別にレポートされます。リストに数行のみ表示されている場合、Convertibleデータは局所的に集中しています。リストに多数の行が表示されている場合、Convertibleデータはデータベース全体に分散しています。次に出力例を示します。

USER.TABLE                        Convertible       Truncation            Lossy
---------------------------- ---------------- ---------------- ----------------
HR.EMPLOYEES                                1                0                0
OE.CUSTOMERS                                2                0                0
PM.ONLINE_MEDIA                            13                0                0
PM.PRINT_MEDIA                              7                0                1
SYS.EXTERNAL_TAB$                           1                0                0
SYS.METASTYLESHEET                         80                0                0
---------------------------- ---------------- ---------------- ----------------

列ごとの変換可能データの分散状態

次の項は、Convertible、TruncationおよびLossyデータがデータベース内にどのように分散しているかを示します。統計は、列別にレポートされます。次に出力例を示します。

USER.TABLE|COLUMN                          Convertible       Truncation            Lossy
------------------------------------- ---------------- ---------------- ----------------
HR.EMPLOYEES|FIRST_NAME                              1                0                0
OE.CUSTOMERS|CUST_EMAIL                              1                0                0
OE.CUSTOMERS|CUST_FIRST_NAME                         1                0                0
PM.ONLINE_MEDIA|SYS_NC00042$                         6                0                0
PM.ONLINE_MEDIA|SYS_NC00062$                         7                0                0
PM.PRINT_MEDIA|AD_FINALTEXT                          3                0                1
PM.PRINT_MEDIA|AD_SOURCETEXT                         4                0                0
SYS.EXTERNAL_TAB$|PARAM_CLOB                         1                0                0
SYS.METASTYLESHEET|STYLESHEET                       80                0                0
------------------------------------- ---------------- ---------------- ----------------

再構築対象の索引

データベース・キャラクタ・セットの移行によって影響を受ける全索引のリストが生成されます。これらの索引は、データのインポート後に再作成できます。次に出力例を示します。

USER.INDEX on USER.TABLE(COLUMN)
--------------------------------------------------------------------------------------
HR.EMP_NAME_IX on HR.EMPLOYEES(FIRST_NAME)
HR.EMP_NAME_IX on HR.EMPLOYEES(LAST_NAME)
OE.CUST_EMAIL_IX on OE.CUSTOMERS(CUST_EMAIL)
--------------------------------------------------------------------------------------

キャラクタ・セマンティクスによる切捨て

この項は、キャラクタ・セマンティクスを使用して定義されている列にのみ適用されます。この項では、データベース・キャラクタ・セットがCSALTERスクリプトで更新される前に、変換先キャラクタ・セットに(SQL CONVERT関数または他のインライン変換プロセスなどにより)変換された場合に切り捨てられるデータ・セルの数が識別されます。データベース・キャラクタ・セットの変更後にデータ変換が発生する場合は、この項を無視してかまいません。

たとえば、WE8MSWIN1252データベースのVARCHAR2(5 char)列には、5バイトを使用して最大5文字を格納できます。これらの文字がAL32UTF8に移行されると、同じ5文字が長さ最大20バイトまで拡張する可能性があります。列に割り当てられる物理バイト制限は現行のデータベース・キャラクタ・セットにより決定されるため、データを変換先キャラクタ・セットで変換する前に、この列を手動で20バイトに拡張する必要があります。または、データベース・キャラクタ・セットの変更後に、この列にキャラクタ・セット変換を適用できます。この場合は、同じVARCHAR2(5 char)定義で自動的に20バイトが割り当てられ、特殊処理は必要ありません。

次に、レポートのキャラクタ・セマンティクスによる切捨てセクションの出力例を示します。

USER.TABLE|COLUMN                                        Truncation
-------------------------------------------------- ----------------
HR.EMPLOYEES|FIRST_NAME                                           1

キャラクタ・セット検出結果

この項は、LCSDパラメータで言語およびキャラクタ・セット検出がオンになっている場合に出力されます。この項には、Database Character Set Scannerで検出されたキャラクタ・セットのリストが表示されます。キャラクタ・セットは出現順です。NUMBERは、データ・セル数です。

次に、キャラクタ・セット検出結果セクションの出力例を示します。

CHARACTER SET                            NUMBER       PERCENTAGE
------------------------------ ---------------- ----------------
WE8MSWIN1252                                 38          97.436%
UNKNOWN                                       1           2.564%
------------------------------ ---------------- ----------------

言語検出結果

この項は、LCSDパラメータで言語およびキャラクタ・セット検出がオンになっている場合に出力されます。この項には、Database Character Set Scannerで検出された言語のリストが表示されます。言語は出現順です。

次に、言語検出結果セクションの出力例を示します。

LANGUAGE                                 NUMBER       PERCENTAGE
------------------------------ ---------------- ----------------
ENGLISH                                      36          92.308%
FRENCH                                        2           5.128%
UNKNOWN                                       1           2.564%
------------------------------ ---------------- ----------------

データベース・スキャンの個別例外レポート

scan.errファイルには、個別例外レポートが記述されます。このレポートは、次のサマリーで構成されています。

- データベース・スキャン・パラメータ

- データ・ディクショナリの個別例外

- アプリケーション・データ個別例外

データベース・スキャン・パラメータ

この項には、選択したパラメータおよびスキャンのタイプが記述されます。次に出力例を示します。

Parameter                      Value
------------------------------ ------------------------------------------------
CSSCAN Version                 v2.1
Instance Name                  rdbms06
Database Version               10.2.0.0.0
Scan type                      Full database
Scan CHAR data?                YES
Database character set         WE8ISO8859P1
FROMCHAR                       WE8ISO8859P1
TOCHAR                         AL32UTF8
Scan NCHAR data?               NO
Array fetch buffer size        1024000
Number of processes            2
Capture convertible data?      NO
Charset Language Detection     Yes
Charset Language Parameter     LOSSY
------------------------------ ------------------------------------------------

データ・ディクショナリの個別例外

この項には、データ・ディクショナリのデータが変換可能であるか、または例外があるかがレポートされます。例外には2つのタイプがあります。

- 列サイズの超過(exceed column size)

- 非可逆式変換(lossy conversion)

次に、変換可能なデータを含むデータ・ディクショナリに関する出力例を示します。

User  : SYS
Table : OBJ$
Column: NAME
Type  : VARCHAR2(30)
Number of Exceptions         : 0
Max Post Conversion Data Size: 30

ROWID              Exception Type      Size Cell Data(first 30 bytes)
------------------ ------------------ ----- ------------------------------
AAAAASAABAAAikLAAQ convertible              Aufträge
------------------ ------------------ ----- ------------------------------

関連項目:

- 例外の詳細は、「アプリケーション・データ個別例外」を参照してください。

- 「データ・ディクショナリ内の変換可能データまたは不可逆データを処理する方法」

アプリケーション・データ個別例外

このレポートには、例外があるデータが示されるため、必要に応じて該当データを修正できます。

例外には2つのタイプがあります。

- 列サイズの超過(exceed column size)
最大列幅を超過している場合は、列サイズを拡張する必要があります。列サイズを拡張しないと、データの切捨てが発生します。

- 非可逆式変換(lossy conversion)
新規キャラクタ・セットへの移行前にデータを訂正する必要があります。データを訂正しないと、無効な文字が置換文字に変換されます。置換文字は通常、?または¿、あるいはソース文字と言語的に同様の文字です。

次の個別例外レポートの例では、データベース・キャラクタ・セットをWE8ISO8859P1からAL32UTFに変更するときに発生する可能性があるいくつかの問題が示されています。

User:   USER1
Table:  TEST
Column: NAME
Type:   VARCHAR2(10)
Number of Exceptions: 2
Max Post Conversion Data Size: 11

ROWID              Exception Type      Size Cell Data(first 30 bytes)
------------------ ------------------ ----- ------------------------------
AAAA2fAAFAABJwQAAg exceed column size    11 Ährenfeldt
AAAA2fAAFAABJwQAAu lossy conversion         órâclë8™
AAAA2fAAFAABJwQAAu exceed column size    11 órâclë8™
------------------ ------------------ ----- ------------------------------

値Ährenfeldtおよびórâclë8(tm)は、列サイズ(10バイト)を超過しています。これは、Ä、ó、âおよびëの各文字が、WE8ISO8859P1では1バイトですがAL32UTF8では2バイトであるためです。値órâclë8(tm)は、商標記号(tm)(コード153)が有効なWE8ISO8859P文字ではないことに起因するAL32UTF8への不可逆変換です。この文字は、WE8ISO8859P1のスーパーセットであるWE8MSWIN1252の文字です。

SELECT文を発行すると、例外があるデータを表示できます。

SELECT name FROM user1.test WHERE ROWID='AAAA2fAAFAABJwQAAu';

UPDATE文を発行すると、例外があるデータを修正できます。

UPDATE user1.test SET name = 'Oracle8 TM'
WHERE ROWID='AAAA2fAAFAABJwQAAu';

言語およびキャラクタ・セット検出オプションが有効化されている場合、CSSCANはLCSDDATAパラメータで指定されたデータ・セルについて最も可能性の高い言語およびキャラクタ・セットの提供を試みます。

次に、個別例外レポートの出力例を示します。このレポートは、データベース・キャラクタ・セットをUS7ASCIIからAL32UTF8に変更する場合の、不可逆データ・セルに関する言語およびキャラクタ・セット検出の結果を示しています。

User:   USER2
Table:  TEST
Column: NAME
Type:   VARCHAR2(30)
Number of Exceptions: 2
Max Post Conversion Data Size: 11

ROWID              Exception Type      Size Cell Data(first 30 bytes)   Language & Character Set
------------------ ------------------ ----- --------------------------- ------------------------
AAAA2fAAFAABJwQAAt lossy conversion         C'est français              (French,UTF8)
AAAA2fAAFAABJwQAAu lossy conversion         Ciò è italiana              (Italian,WE8MSWIN1252)
------------------ ------------------ ----- --------------------------- ------------------------

関連項目:

- 「データの切捨て」

- 「キャラクタ・セット変換の問題」

データ・ディクショナリ内の変換可能データまたは不可逆データを処理する方法

ユーザー・アプリケーションのデータ変更とは異なり、データ・ディクショナリ表の内容を直接更新したり変更する操作はサポートされません。内部の依存性を把握せずにシステム表を更新すると、データベースが破損する可能性があります。

データ・ディクショナリが変換可能な場合、データ・セルはFROMCHARキャラクタ・セットでエンコードされます。データ・ディクショナリに変換可能なデータがある場合については、次の3つの一般的な使用例があります。

- データ・ディクショナリ内のCLOBデータの場合
シングルバイト・キャラクタ・セットの場合、CLOBデータはデータベース・キャラクタ・セットのエンコーディングで格納されます。マルチバイト・キャラクタ・セットの場合、CLOBデータはUCS-2互換の内部Oracle形式で格納されます。たとえば、US7ASCIIデータベースのVARCHAR2列に格納されている文字列ABCのバイト表現は、AL32UTF8に移行後も変わりません。CLOB列に格納されている同じ文字列のサイズは2倍であり、格納方法もまったく異なります。シングルバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合、CLOBデータがCHANGELESSになることはありません。

- データ・ディクショナリ内のXML CSXデータの場合
データ・ディクショナリ内のXML CSXデータは、変換可能なアプリケーション・データと同様にすべて安全に変換されます。

- データベースをキャラクタ・セットに移行するが、そのキャラクタ・セットは変換元キャラクタ・セットの文字をすべて含むスーパーセットであり、一部の文字のバイナリ値が2つのキャラクタ・セット間で異なる場合
これは、データ・セルを新規キャラクタ・セットに手動で変換する必要のあるユーザー・アプリケーション・データの場合に似ています。この操作の一般的な原因は、ユーザーのオブジェクト定義(表名、列名、パッケージ名およびパッケージ本体など)の作成に、ASCII以外の文字が使用されていることです。通常、これらはユーザーのネイティブ言語に含まれる文字または記号です。

変換可能なデータ・ディクショナリのデータを移行する場合に最も簡単なアプローチは、変換先キャラクタ・セットで新規データベースを作成してから、エクスポートとインポートによりデータ・ディクショナリおよびスキーマ定義をすべて再作成することです。ただし、この方法では新規データベースを作成することになります。

新規データベースを作成するかわりに既存のデータベースを移行する場合、データ・ディクショナリ内の変換可能なCLOBデータを移行し、既存のデータベース・キャラクタ・セットを変換先キャラクタ・セットに変更するには、CSALTERスクリプトを使用するのが最も簡単な方法です。

関連項目:
「Database Character Set ScannerのCSALTERスクリプト」

データ・ディクショナリのうちCLOBデータでないCONVERTIBLEデータ・セルの場合は、変換可能なデータを含むスキーマ・オブジェクトを検索する必要があります。これにより、次のいずれかの操作を選択できます。

- データ・セルがCHANGELESSになるように、オブジェクト定義を修正します(たとえば、パッケージ本体のコメントからASCII以外の文字を削除します)。

- これらのオブジェクトをデータベース・スキーマからまとめて削除し、データベース・キャラクタ・セットを変換先キャラクタ・セットに移行した後で再作成します。

LOSSYディクショナリ・データ・セルについては、さらにデータ・ディクショナリを検査し、現行のFROMCHARキャラクタ・セットがデータベースの実際のキャラクタ・セットかどうかを確認する必要があります。データベースの実際のキャラクタ・セットであれば、これらのオブジェクト定義を訂正する必要があります(たとえば、パッケージ本体のコメントから問題の文字を削除します)。これにより、データ・セルがCHANGELESSとなり、変換先キャラクタ・セットに安全に移行できます。

データ・ディクショナリ内でCONVERTIBLEデータ・セルとLOSSYデータ・セルを検索できるように、Database Character Set Scannerには次の3つのSQLスクリプトが付属しています。

- analyze_source.sql

- analyze_histgrm.sql

- analyze_rule.sql

各スクリプトは$ORACLE_HOME/nls/csscan/sqlディレクトリに格納されています。これらのスクリプトでは、問題のデータ・ディクショナリ・オブジェクトを識別できるように、SYS.SOURCE$、SYS.HISTGRM$およびSYS.RULE$データ・ディクショナリ表に対してSQL SELECT操作が実行されます。

次に、analyze_source.sqlスクリプトの出力例を示します。

SQL> @$ORACLE_HOME/nls/csscan/sql/analyze_source.sql

Table: SYS.SOURCE$
Error: CONVERTIBLE DATA

no rows selected

Table: SYS.SOURCE$
Error: EXCEPTIONAL DATA

OWNER       OBJECT_NAME     OBJECT_TYPE     EXCEPTIONAL
----------- --------------  -------------   -----------
SCOTT       FOO             FUNCTION        1

Database Character Set Scannerの記憶域とパフォーマンスに関する考慮事項

この項では、Database Character Set Scannerの記憶域とパフォーマンスに関する問題について説明します。内容は次のとおりです。

- Database Character Set Scannerの記憶域に関する考慮事項

- Database Character Set Scannerのパフォーマンスに関する考慮事項

- Database Character Set Scannerに関する推奨事項と制限事項

Database Character Set Scannerの記憶域に関する考慮事項

この項では、Database Character Set Scannerのシステム表のサイズと拡張について説明し、それらをメンテナンスする方法について説明します。データベースに格納されているデータの性質に応じて、急速に増大する可能性があるシステム表が3つあります。

csminst.sqlスクリプトを修正すると、ユーザーCSMIGに大きい表領域を割り当てることができます。デフォルトでは、SYSTEM表領域がユーザーCSMIGに割り当てられます。

この項の内容は、次のとおりです。

- CSM$TABLES

- CSM$COLUMNS

- CSM$ERRORS

CSM$TABLES

スキャンする必要があるすべての表が、CSM$TABLES表に列挙されます。

次のSQL文を発行すると、データベース内の表の数を調べる(CSM$TABLESがどの程度大きくなるかの見積りを取得する)ことができます。

SELECT COUNT(*) FROM DBA_TABLES;

CSM$COLUMNS

スキャンされた各列の統計情報が、CSM$COLUMNS表に格納されます。

次のSQL文を発行すると、データベース内の文字列型の列の数を調べる(CSM$COLUMNSがどの程度大きくなるかの見積りを取得する)ことができます。

SELECT COUNT(*) FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE IN ('CHAR', 'VARCHAR2', 'LONG', 'CLOB', 'VARRAY');

CSM$ERRORS

セル・データで例外が検出されると、個々の例外情報がCSM$ERRORS表に挿入されます。この情報は個別例外レポートに表示され、必要に応じて修正するレコードの識別に役立ちます。

データベースにExceptionalまたはConvertible(パラメータCAPTURE=Yが設定されている場合)の印が付いたデータが多数含まれている場合は、CSM$ERRORS表が極端に大きくなる可能性があります。SUPPRESSパラメータを使用すると、CSM$ERRORS表が不必要に増大することを防止できます。

SUPPRESSパラメータはすべての表に適用されます。指定した数の例外が挿入された後は、個々のExceptional情報の挿入が抑制されます。記録される例外数を制限しても、例外が異なる表に散在している場合は役に立たない可能性があります。

Database Character Set Scannerのパフォーマンスに関する考慮事項

この項では、データベース・スキャン時のパフォーマンスを向上させる方法を説明します。

マルチ・スキャン・プロセスの使用

比較的大規模なデータベース(50GB以上のデータベースなど)のスキャンを計画している場合は、マルチ・スキャン・プロセスの利用を考慮できます。マルチ・スキャン・プロセスを使用すると、マシンで使用可能なCPUやメモリーなどのハードウェア・リソースを使用することによって、データベース・スキャンの継続時間が短縮されます。使用するスキャン・プロセスの数を判断するためのガイドラインは、CPU_COUNT初期化パラメータ値と同じ値に設定することです。

配列フェッチ・バッファ・サイズの設定

配列フェッチを許可すると、1回に複数行がフェッチされます。通常は、大きなサイズの配列フェッチ・バッファを使用すると、パフォーマンスを改善できます。各プロセスでは、独自のフェッチ・バッファが割り当てられます。

QUERY句の最適化

QUERYパラメータを指定せずにCharacter Set Scannerを実行すると、CSSCANによって作成されたSELECTの各操作に、/*+ROWID*/ヒントが自動的に含まれます。これによって、表のスキャンの実行時にROWIDを使用してすべてのデータの取得が実行されるため、アクセスが高速になります。QUERYパラメータを指定すると、WHERE句の条件は、他の方法ですでに最適化されているとみなされます。したがって、ROWIDヒントはQUERY句に追加されません。

QUERYパラメータを使用する場合に最適なパフォーマンスを保持するには、SELECT文に入念なチューニング(追加索引の作成など)が必要となります。

例外および変換可能ログの抑制

ExceptionalおよびConvertible(CAPTURE=Yの場合)の個別情報は、CSM$ERRORS表に挿入されます。通常、CSM$ERRORS表への挿入は、データ・フェッチよりもリソースを消費します。データベースにExceptionalまたはConvertibleの印が付いたデータが多数あると、多数の挿入文が発行されるため、パフォーマンスが低下します。SUPPRESSパラメータを使用して、記録する例外行の数に制限を設定することをお薦めします。

Database Character Set Scannerに関する推奨事項と制限事項

CHAR、VARCHAR2、LONG、CLOBおよびVARRAY列の文字ベースのデータはすべて、データベース・キャラクタ・セットに格納されます。これは、データベースを最初に作成したときに、CREATE DATABASE文で指定したデータベース・キャラクタ・セットです。ただし、構成によっては、意図的にまたは意図せずに、データベース・キャラクタ・セットと異なるキャラクタ・セットにデータを格納する可能性があります。これは、NLS_LANGキャラクタ・セットがデータベース・キャラクタ・セットと同一の場合に最もよく発生します。このような場合、Oracleデータベースはデータを変換または検証の保証なしにそのまま送受信するためです。また、2つのキャラクタ・セットの一方が他方のスーパーセットである場合にも発生します。この状況では、コード・ポイントの大部分が変換されない場合と同様に表示されます。たとえば、NLS_LANGがWE8ISO8859P1に設定されていて、データベース・キャラクタ・セットがWE8MSWIN1252の場合は、クライアント/サーバー変換を実行しても、128～159の範囲以外のすべてのコード・ポイントが保持されます。

同じバイナリ・コード・ポイント値を使用して、様々なキャラクタ・セット間で異なる文字を表すことができます。ほとんどのヨーロッパ言語のキャラクタ・セットは、8ビット範囲の自由な使用を共有してネイティブ文字をエンコードするため、不適切な理由でセルが互換性ありとレポートされる可能性が高くなります。FROMCHARパラメータを設定する場合、すべての文字データがキャラクタ・セットでエンコードされていても、Database Character Set Scannerでは妥当性を正確に判断できないものとみなすことになります。

たとえば、FROMCHARパラメータをWE8MSWIN1252に設定してDatabase Character Set Scannerを使用すると、この問題が発生する可能性があります。このシングルバイト・キャラクタ・セットは、使用可能なすべてのコード・ポイントで文字をエンコードするため、スキャン対象がどのようなデータであっても、スキャナは常にデータ・セルを変換元キャラクタ・セットで使用可能と識別します。

データベース・キャラクタ・セットにないデータを含むデータベースのスキャン

データベースにデータベース・キャラクタ・セットにないデータが含まれていても、別のキャラクタ・セットでエンコードされており、エンコードされたキャラクタ・セットがFROMCHARパラメータで指定されている場合は、Database Character Set Scannerでスキャンを実行できます。

2つ以上のキャラクタ・セットからのデータを含むデータベースのスキャン

データベースに複数のキャラクタ・セットからのデータが含まれている場合、Database Character Set Scannerでは、1回のスキャンではデータベース・キャラクタ・セットの変更による影響を正確にテストできません。データを各キャラクタ・セットに対して1つずつ、別個の表に分割できる場合、Database Character Set Scannerでは複数の表スキャンを実行してデータの妥当性を検証できます。

スキャンごとに、異なる値のFROMCHARパラメータを使用し、指定したキャラクタ・セットにある場合と同様に、表内のターゲット列すべてを処理するように、Database Character Set Scannerに対して指示できます。

Database Character Set ScannerのCSALTERスクリプト

CSALTERスクリプトは、特殊なキャラクタ・セット移行処理のためのDBAツールです。廃止になったALTER DATABASE CHARACTER SET SQL文と同様に、CSALTERは、システム管理者のみが使用してください。システム管理者は、最初にDatabase Character Set Scannerを実行して、CSALTERの実行に適した条件が存在していることを確認する必要があります。また、CSALTERの実行前にデータベースのバックアップを実行してください。CSALTERは引数を取らず、このデータベース上で実行された最新のCSSCANによって格納された情報を使用します。たとえば、CSALTERによって、TOCHAR CSSCAN値が新しいNLS_CHARACTERSETとして使用されます。

CSALTERスクリプトを実行するには、SQL*Plusを起動して、キャラクタ・セットを移行するデータベースに接続します。Database Character Set Scannerは、CSALTERスクリプトの前に実行する必要があることに注意してください。その後、次のコマンドを入力します。

sqlplus> @@CSALTER.PLB

CSALTERスクリプトには、次のフェーズがあります。

- CSALTERスクリプトのチェック・フェーズ

- CSALTERスクリプトの更新フェーズ

CSALTERスクリプトのチェック・フェーズ

CSALTERスクリプトのチェック・フェーズでは、次のタスクが実行されます。

1. ユーザー・ログインがSYSかどうかがチェックされます。このスクリプトの実行を許可されるのはユーザーSYSのみです。

2. 過去7日以内に全データベース・スキャンが実行されているかどうかがチェックされます。この期間内に全データベース・スキャンが実行されていない場合は、スクリプトが停止し、エラーがレポートされます。データベース管理者は、全データベース・スキャンの実行時からCSALTERスクリプトの実行時までの間に、他のユーザーによりデータベースが更新されないことを確認する必要があります。

3. Oracleデータベースにより作成されたデータ・ディクショナリ内のすべてのCLOB列が変更不可能か、または変換可能かがチェックされます。変換可能なCLOB列が発生するのは、シングルバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合です。データ・ディクショナリのCLOB列に不可逆セルが見つかると、スクリプトが停止します。不可逆CLOBには特殊な処理が必要になる場合があります。詳細は、Oracleサポート・サービスに問い合せてください。
次のスキーマに属している表は、データ・ディクショナリの一部とみなされます。

SYS

SYSTEM

CTXSYS

DIP

DMSYS

EXFSYS

LBACSYS

MDSYS

ORDDATA

ORDPLUGINS

ORDSYS

SI_INFORMTN_SCHEMA

XDB

4. Oracleデータベースにより作成されたサンプル・スキーマ内のすべてのCLOB列が変更不可能か、または変換可能かがチェックされます。変換可能なCLOB列が発生するのは、シングルバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合です。次のスキーマに属している表は、サンプル・スキーマの一部です。

HR

OE

SH

PM

5. CLOBデータ型が、データ・ディクショナリ内とサンプル・スキーマ内で変換可能なデータを含む唯一のデータ型かどうかがチェックされます。他のすべてのユーザーの表に、CLOBデータ型を含めてすべてのデータ型の変換可能なデータがないかどうかがチェックされます。CSALTERスクリプトは、現行のデータベースが新規データベースの正しいサブセットである場合のみ実行されることを意図しているため、すべてのデータは変更不可能であることが必要ですが、その例外としてCLOBデータが考えられます。シングルバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合、ユーザー作成のCLOBデータは変換する必要があり、最初にエクスポートしてスキーマから削除する必要があります。CSALTERスクリプトを実行するには、データベースを再スキャンしてください。変換可能または切捨て対象としてレポートされる他のすべてのデータ型のセルは、Database Character Set Scannerを再実行する前に訂正する必要があります。

関連項目:

- 「サブセットとスーパーセット」

- CSALTERスクリプトとCLOBデータの詳細は、「CSALTERスクリプトを使用したキャラクタ・セットの移行」を参照してください。

CSALTERスクリプトの更新フェーズ

CSALTERスクリプトでは、データ・ディクショナリ内の各CLOBが「CSALTERスクリプトのチェック・フェーズ」で説明したチェックを通ったことが確認されると、変換が実行されます。データ・ディクショナリ内とサンプル・スキーマ内のすべてのCLOBデータが更新された後、このスクリプトにより変更がコミットされ、情報がCSM$TABLESビューに保存されます。データ・ディクショナリ内のすべてのCLOBデータが更新された後、CSALTERスクリプトによりデータベースのメタデータが新規キャラクタ・セットに更新されます。これで移行プロセス全体が完了します。

CSALTERスクリプトは再開可能です。データベースを新規キャラクタ・セットに更新する処理の途中で失敗した場合、データベース管理者はなんらかの操作を実行する前にデータベースを停止して再起動し、CSALTERスクリプトを再実行する必要があります。更新後の情報はすでにCSM$TABLESビューに保存されているため、スクリプトではデータ・ディクショナリ表のCLOBデータが2回更新されることはありません。移行プロセスは単に再開され、新規キャラクタ・セットへのデータベースの更新が完了します。

CSALTERスクリプトに失敗した場合は、次の方法で更新を再開してください。

1. CSALTERスクリプトを実行したSQL*Plusセッションから、即時に次のコマンドを入力します。

SHUTDOWN ABORT

2. CSALTERでデータベースをオープンする必要があるため、データベースを起動してオープンします。

STARTUP OPEN

3. CSALTERスクリプトを実行します。

@@CSALTER.PLB

4. IMMEDIATEまたはNORMALオプションを指定してデータベースを停止します。

5. データベースを起動します。

Database Character Set Scannerのビュー

Database Character Set Scannerでは、次のビューが使用されます。

- CSMV$COLUMNS

- CSMV$CONSTRAINTS

- CSMV$ERRORS

- CSMV$INDEXES

- CSMV$TABLES

CSMV$COLUMNS

このビューには、スキャンされた列の統計情報が含まれます。

列名

データ型

NULL

説明

OWNER_ID

NUMBER

NOT NULL

表所有者のユーザーID

OWNER_NAME

VARCHAR2(30)

NOT NULL

表所有者のユーザー名

TABLE_ID

NUMBER

NOT NULL

表のオブジェクトID

TABLE_NAME

VARCHAR2(30)

NOT NULL

表のオブジェクト名

COLUMN_ID

NUMBER

NOT NULL

列ID

COLUMN_INTID

NUMBER

NOT NULL

内部列ID(抽象データ型用)

COLUMN_NAME

VARCHAR2(30)

NOT NULL

列名

COLUMN_TYPE

VARCHAR2(9)

NOT NULL

列データ型

TOTAL_ROWS

NUMBER

NOT NULL

この表の行数

NULL_ROWS

NUMBER

NOT NULL

NULLデータ・セルの数

CONV_ROWS

NUMBER

NOT NULL

変換する必要があるデータ・セルの数

ERROR_ROWS

NUMBER

NOT NULL

例外があるデータ・セルの数

EXCEED_SIZE_ROWS

NUMBER

NOT NULL

切捨てがあるデータ・セルの数

DATA_LOSS_ROWS

NUMBER

-

不可逆変換を行ったデータ・セルの数

MAX_POST_CONVERT_SIZE

NUMBER

-

変換後の最大データ・サイズ

CSMV$CONSTRAINTS

このビューには、スキャンされた制約の統計情報が含まれます。

列名

データ型

NULL

説明

OWNER_ID

NUMBER

NOT NULL

制約所有者のユーザーID

OWNER_NAME

VARCHAR2(30)

NOT NULL

制約所有者のユーザー名

CONSTRAINT_ID

NUMBER

NOT NULL

制約のオブジェクトID

CONSTRAINT_NAME

VARCHAR2(30)

NOT NULL

制約のオブジェクト名

CONSTRAINT_TYPE#

NUMBER

NOT NULL

制約タイプ番号

CONSTRAINT_TYPE

VARCHAR2(11)

NOT NULL

制約タイプ名

TABLE_ID

NUMBER

NOT NULL

表のオブジェクトID

TABLE_NAME

VARCHAR2(30)

NOT NULL

表のオブジェクト名

CONSTRAINT_RID

NUMBER

NOT NULL

ルート制約ID

CONSTRAINT_LEVEL

NUMBER

NOT NULL

制約レベル

CSMV$ERRORS

このビューには、セル・データおよびオブジェクト定義の個別例外情報が含まれます。

列名

データ型

NULL

説明

OWNER_ID

NUMBER

NOT NULL

表所有者のユーザーID

OWNER_NAME

VARCHAR2(30)

NOT NULL

表所有者のユーザー名

TABLE_ID

NUMBER

NOT NULL

表のオブジェクトID

TABLE_NAME

VARCHAR2(30)

-

表のオブジェクト名

COLUMN_ID

NUMBER

-

列ID

COLUMN_INTID

NUMBER

-

内部列ID(抽象データ型用)

COLUMN_NAME

VARCHAR2(30)

-

列名

DATA_ROWID

VARCHAR2(1000)

-

データの行ID

COLUMN_TYPE

VARCHAR2(9)

-

オブジェクト型の列データ型

ERROR_TYPE

VARCHAR2(11)

-

発生したエラーのタイプ

CSMV$INDEXES

このビューには、索引に関する個々の例外情報が含まれます。

列名

データ型

NULL

説明

INDEX_OWNER_ID

NUMBER

NOT NULL

索引所有者のユーザーID

INDEX_OWNER_NAME

VARCHAR2(30)

NOT NULL

索引所有者のユーザー名

INDEX_ID

NUMBER

NOT NULL

索引のオブジェクトID

INDEX_NAME

VARCHAR2(30)

-

索引のオブジェクト名

INDEX_STATUS#

NUMBER

-

索引のステータス番号

INDEX_STATUS

VARCHAR2(8)

-

索引のステータス

TABLE_OWNER_ID

NUMBER

-

表所有者のユーザーID

TABLE_OWNER_NAME

VARCHAR2(30)

-

表所有者のユーザー名

TABLE_ID

NUMBER

-

表のオブジェクトID

TABLE_NAME

VARCHAR2(30)

-

表のオブジェクト名

COLUMN_ID

NUMBER

-

列ID

COLUMN_INTID

NUMBER

-

内部列ID(抽象データ型用)

COLUMN_NAME

VARCHAR2(30)

-

列名

CSMV$TABLES

このビューには、スキャンするデータベース表に関する情報が含まれます。スキャンするすべての表がこのビューに列挙されます。

列名

データ型

NULL

説明

OWNER_ID

NUMBER

NOT NULL

表所有者のユーザーID

OWNER_NAME

VARCHAR2(30)

NOT NULL

表所有者のユーザー名

TABLE_ID

NUMBER

-

表のオブジェクトID

TABLE_NAME

VARCHAR2(30)

-

表のオブジェクト名

MIN_ROWID

VARCHAR2(18)

-

表の分割範囲の最小行ID

MAX_ROWID

VARCHAR2(18)

-

表の分割範囲の最大行ID

BLOCKS

NUMBER

-

分割範囲内のブロック数

SCAN_COLUMNS

NUMBER

-

スキャンされる列数

SCAN_ROWS

NUMBER

-

スキャンされる行数

SCAN_START

VARCHAR2(8)

-

表スキャンの開始時間

SCAN_END

VARCHAR2(8)

-

表スキャンの終了時間

Database Character Set Scannerエラー・メッセージ

Database Character Set Scannerには、次のエラー・メッセージがあります。

CSS-00100: failed to allocate memory size of number (%d)

原因: サイズ0または最大サイズよりも大きい値でメモリーを割り当てようとしました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00101 failed to release memory

原因: 無効なポインタでメモリーを解放しようとしました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00102 failed to release memory, null pointer given

原因: NULLポインタでメモリーを解放しようとしました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00105 failed to parse BOUNDARIES parameter

原因: BOUNDARIESパラメータが無効な書式で指定されました。

処置: 正しい構文はマニュアルを参照してください。

CSS-00106 failed to parse SPLIT parameter

原因: SPLITパラメータが無効な書式で指定されました。

処置: 正しい構文はマニュアルを参照してください。

CSS-00107 Character set migration utility schem not installed

原因: CSM$VERSION表がデータベースにありません。

処置: データベースでCSMINST.SQLを実行してください。

CSS-00108 Character set migration utility schema not compatible

原因: 非互換のCSM$*表がデータベースにあります。

処置: データベースでCSMINST.SQLを実行してください。

CSS-00110 failed to parse USERID

原因: USERIDパラメータが無効な書式で指定されました。

処置: 正しい構文はマニュアルを参照してください。

CSS-00111 failed to get RDBMS version

原因: データベースのバージョン値の取得に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00112 database version not supported

原因: データベースのバージョンがリリース8.0.5.0.0より前です。

処置: データベースをリリース8.0.5.0.0以上にアップグレードします。その後に再試行してください。

CSS-00113: user username (%s) is not allowed to access data dictionary

原因: 指定したユーザーは、データ・ディクショナリにアクセスできません。

処置: O7_DICTIONARY_ACCESSIBILITYパラメータをTRUEに設定するか、SYSユーザーを使用してください。

CSS-00114: failed to get database character set name characterset_name (%s)

原因: NLS_DATABASE_PARAMETERSビューからのNLS_NCHAR_CHARACTERSETまたはNLS_CHARACTERSETパラメータの値の取得に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00115: invalid character set name characterset_name (%s)

原因: 指定したキャラクタ・セットは、有効なOracleキャラクタ・セットではありません。

処置: 有効なOracleキャラクタ・セット名を指定して再試行してください。

CSS-00116: failed to reset NLS_LANG or NLS_NCHAR parameter

原因: NLS_LANGキャラクタ・セットをデータベース・キャラクタ・セットと一致させることができませんでした。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00117 failed to clear previous scan log

原因: CSM$*表からの全行削除に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00118 failed to save command parameters

原因: CSM$PARAMETERS表への複数行の挿入に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00119 failed to save scan start time

原因: CSM$PARAMETERS表への行の挿入に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00120 failed to enumerate tables to scan

原因: スキャンする表のCSM$TABLESへの列挙に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00121 failed to save scan complete time

原因: CSM$PARAMETERS表への行の挿入に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00122 failed to create scan report

原因: データベース・スキャン・レポートの作成に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00123: failed to check if user username (%s) exists

原因: 指定したユーザーがデータベースに存在するかどうかをチェックするSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00124: user username (%s) not found

原因: 指定したユーザーはデータベースに存在していません。

処置: ユーザー名をチェックしてください。

CSS-00125: failed to check if table username.tablename (%s.%s) not found

原因: 指定した表がデータベースに存在するかどうかをチェックするSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00126: table username.tablename (%s.%s) not found

原因: 指定した表はデータベースに存在していません。

処置: ユーザー名と表名が正しいかどうかチェックしてください。

CSS-00127: user username (%s) does not have DBA privilege

原因: 指定したユーザーには、データベースのスキャンに必要なDBA権限がありません。

処置: DBA権限が付与されているユーザーを選択してください。

CSS-00128 failed to get server version string

原因: データベースのバージョン文字列の取得に失敗しました。

処置: なし。

CSS-00129: query cannot be used in ALL or USER scan mode

原因: 問合せパラメータは、全データベース・スキャン・モードおよびユーザー・スキャン・モードでは使用できません。

処置: 問合せパラメータを削除してください。

CSS-00130 failed to initialize semaphore

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00131: failed to spawn scan process number (%d)

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00132 failed to destroy semaphore

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00133 failed to wait semaphore

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00134 failed to post semaphore

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00140: failed to scan table (tid=number (%d), oid=number (%d))

原因: この特定の表でデータ・スキャンに失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00141 failed to save table scan start time

原因: CSM$TABLES表の行の更新に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00142 failed to get table information

原因: 表のユーザーIDおよびオブジェクトIDからの様々な情報の取得に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00143 failed to get column attributes

原因: 表の列属性の取得に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00144: failed to scan table username.tablename (%s.%s)

原因: この特定の表でデータ・スキャンに失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00145 failed to save scan result for columns

原因: CSM$COLUMNS表への複数行の挿入に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00146 failed to save scan result for table

原因: CSM$TABLES表の行の更新に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00147 unexpected data truncation

原因: フェッチ・バッファ用に列バイト・サイズと正確に同じサイズのメモリーが割り当てられましたが、予期しないデータ切捨てが行われました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00150 failed to enumerate table

原因: 指定した表情報の取得に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00151 failed to enumerate user tables

原因: 指定したユーザーに属する表すべてを列挙できませんでした。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00152 failed to enumerate all tables

原因: データベース内の表すべてを列挙できませんでした。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00153 failed to enumerate character type columns

原因: スキャンする表のCHAR、VARCHAR2、LONGおよびCLOB列すべてを列挙できませんでした。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00154 failed to create list of tables to scan

原因: スキャンする表のCSM$TABLESへの列挙に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00155 failed to split tables for scan

原因: 指定した表の分割に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00156 failed to get total number of tables to scan

原因: スキャンする表の数を取得するSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00157 failed to retrieve list of tables to scan

原因: 表IDすべてをスキャナ・メモリーに読み取ることができませんでした。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00158 failed to retrieve index defined on column

原因: 列に定義された索引を取得するSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00160 failed to open summary report file

原因: FILE OPEN関数でエラーが戻されました。

処置: ディスクに対する作成または書込み権限があるかどうかをチェックし、LOGパラメータに指定したファイル名が有効であるかどうかをチェックしてください。

CSS-00161 failed to report scan elapsed time

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00162 failed to report database size information

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00163 failed to report scan parameters

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00164 failed to report scan summary

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00165 failed to report conversion summary

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00166: failed to report conversion per table and column

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00167 failed to open exception report file

原因: FILE OPEN関数でエラーが戻されました。

処置: ディスクに対する作成または書込み権限があるかどうかをチェックし、LOGパラメータに指定したファイル名が有効であるかどうかをチェックしてください。

CSS-00168 failed to report individual exceptions

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00170: failed to retrieve size of tablespace tablespacename (%s)

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00171: failed to retrieve free size of tablespace tablespacename (%s)

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00172: failed to retrieve total size of tablespace tablespacename (%s)

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00173 failed to retrieve used size of the database

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00174: scanner capture data not available

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00175: TOCHAR or TONCHAR parameter not specified

原因: TOCHARまたはTONCHARパラメータが指定されていません。

処置: TOCHARまたはTONCHARパラメータを指定します。

CSS-00176 failed to enumerate user tables in bitmapped tablespace

原因: ビットマップ表領域内の表の例挙に失敗しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00177: failed to retrive max LOB size

原因: 不明です。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00178: failed to check if column username.tablename.columnname(%s.%s.%s) exists

原因: 指定した列がデータベースに存在するかどうかをチェックするSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00179: column %s.%s.%s not found

原因: 指定した列はデータベースに存在していません。

処置: ユーザー名、表名および列名が正しいかどうかチェックしてください。

CSS-00180: failed to check the index on the csm$columns table

原因: 索引IDX_CSM$COLUMNSが存在するかどうかをチェックするSELECT文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

CSS-00181: failed to drop index on the csm$columns table

原因: 索引 IDX_CSM$COLUMNSをドロップするSQL文でエラーが発生しました。

処置: これは内部エラーです。Oracleサポート・サービスに連絡してください。

13 ロケール・データのカスタマイズ

この章では、ロケール・データのカスタマイズ方法について説明します。この章の内容は、次のとおりです。

- Oracle Locale Builderユーティリティの概要

- Oracle Locale Builderを使用した新規言語定義の作成

- Oracle Locale Builderを使用した新規地域定義の作成

- Oracle Locale Builderを使用したコード・チャートの表示

- Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

- Oracle Locale Builderを使用した新規言語ソートの作成

- GINSTALLユーティリティを使用したJavaコンポーネントへのカスタムのロケール定義の追加

- NLBファイルの生成とインストール

- その他のプラットフォームにおけるカスタムNLBファイルのデプロイ

- 旧リリースOracle DatabaseからのカスタムNLBファイルのアップグレード

- NLBデータ・フォームの別のプラットフォームへの転送

Oracle Locale Builderユーティリティの概要

Oracle Locale Builderは、ロケール・データをカスタマイズするための簡単で効率的な方法を提供します。ロケール固有のデータを簡単に表示、変更および定義できるGUIも提供します。Oracle Locale Builderではテキストおよびバイナリ定義ファイルからデータを抽出して、読取り可能な形式で表示するため、ユーザーはこれらのファイルで使用されている形式を気にせずに情報を処理できます。

Oracle Locale Builderでは、言語、地域、キャラクタ・セットおよび言語ソートの4種類のロケール定義を管理します。ユーザー定義文字やカスタマイズされた言語規則もサポートします。既存のテキスト定義ファイルやバイナリ定義ファイルの定義を表示して、変更を加えたり、独自の定義を作成できます。

この項の内容は、次のとおりです。

- Oracle Locale Builder用のUnicodeフォントの構成

- Oracle Locale Builderのユーザー・インタフェース

- Oracle Locale Builderのページとダイアログ・ボックス

Oracle Locale Builder用のUnicodeフォントの構成

Oracle Locale Builderでは、多くの機能でUnicode文字が使用されます。たとえば、Unicodeコード・ポイントへのローカル文字コード・ポイントのマッピングが表示されます。Oracle Locale Builderは、文字が表現されるオペレーティング・システム上で使用可能なローカル・フォントに依存します。したがって、Oracle Locale Builderを完全にサポートするUnicodeフォントの使用をお薦めします。ローカル・フォントで文字を表現できない場合、その文字は空の四角として表示される可能性があります。

Windowsでのフォント構成

Windowsには、Unicodeをサポートする多数のTrueTypeフォントおよびOpenTypeフォントがあります。MicrosoftのArial Unicode MSフォントを使用することをお薦めします。このフォントには、50,000を超える絵文字が含まれ、Unicode 5.0のほとんどの文字をサポートしているためです。

インストールしたUnicodeフォントは、Oracle Locale Builderで使用できるように、Java Runtimeのfont.propertiesファイルに追加します。このfont.propertiesファイルは、$JAVAHOME/jre/libディレクトリにあります。たとえば、Arial Unicode MSフォントの場合は、font.propertiesファイルに次のエントリを追加します。

dialog.n=Arial Unicode MS, DEFAULT_CHARSET
dialoginput.n=Arial Unicode MS, DEFAULT_CHARSET
serif.n=Arial Unicode MS, DEFAULT_CHARSET
sansserif.n=Arial Unicode MS, DEFAULT_CHARSET

n は、フォント・リスト内でArial Unicode MSフォントに割り当てるための次の順序番号です。Java Runtimeは、各仮想フォントについてフォント・マッピング・リストを検索し、システムで使用可能な最初のフォントを使用します。

font.propertiesファイルの編集後に、Oracle Locale Builderを再起動してください。

関連項目:
font.propertiesファイルの詳細は、Sun社の国際化Webサイトを参照してください。

その他のプラットフォームでのフォント構成

Windows以外のプラットフォーム用Unicodeフォントは、Windowsプラットフォームよりも選択肢が限られています。文字を十分にカバーするUnicodeフォントが見つからない場合は、異なる言語に複数のフォントを使用します。前述のWindowsプラットフォームの場合の手順に従って、各フォントをインストールし、そのフォントのエントリをfont.propertiesファイルに追加してください。

たとえば、フォントricoh-hg minchoを使用してSun社のSolarisで日本語の文字を表示するには、エントリを$JAVAHOME/libにある既存のfont.propertiesファイルのdialog、dialoginput、serifおよびsansserifセクションに追加します。次に例を示します。

serif.plain.3=-ricoh-hg mincho l-medium-r-normal--*-%d-*-*-m-*-jisx0201.1976-0

注意:
オペレーティング・システムのロケールによっては、ロケール固有のfont.propertiesファイルを使用できます。たとえば、Sun社のSolarisで現行のオペレーティング・システムのロケールがja_JP.eucJPの場合は、font.properties.jaを使用できます。

関連項目:
使用可能なフォントの詳細は、ご使用のオペレーティング・システムのマニュアルを参照してください。

Oracle Locale Builderのユーザー・インタフェース

Oracle Locale Builderを起動する前に、ORACLE_HOMEパラメータが設定されていることを確認してください。

UNIXオペレーティング・システム上でOracle Locale Builderを起動するには、$ORACLE_HOME/nls/lbuilderディレクトリに変更して次のコマンドを発行します。

% ./lbuilder

Windowsオペレーティング・システム上では、「スタート」メニューからOracle Locale Builderを起動します。「スタート」→「プログラム」→Oracle-OraHome10→「コンフィグレーションおよび移行ツール」→「Locale Builder」を選択します。DOSプロンプトから%ORACLE_HOME%\nls\lbuilderディレクトリに移動してlbuilder.batコマンドを実行する方法もあります。

Oracle Locale Builderを起動すると、図13-1の画面が表示されます。

図13-1 Oracle Locale Builderユーティリティ

Oracle Locale Builderのページとダイアログ・ボックス

Oracle Locale Builderでの特定のタスクを使用する前に、次のようなタブ・ページとダイアログ・ボックスについて理解しておく必要があります。

- 「既存の定義」ダイアログ・ボックス

- 「セッション・ログ」ダイアログ・ボックス

- 「NLTのプレビュー」タブ・ページ

- ファイルを開くダイアログ・ボックス

注意:
Oracle Locale Builderには、オンライン・ヘルプが付属しています。

「既存の定義」ダイアログ・ボックス

「新規言語」、「新規地域」、「新規キャラクタ・セット」または「新規言語ソート」を選択すると、最初に「一般」タブ・ページが表示されます。「既存の定義の表示」をクリックすると、「既存の定義」ダイアログ・ボックスが表示されます。

「既存の定義」ダイアログ・ボックスでは、ロケール・オブジェクトを名前でオープンできます。起動する特定の言語、地域、言語ソート(照合)またはキャラクタ・セットがわかっている場合は、表示されている名前をクリックします。たとえば、図13-2では、AMERICAN言語定義ファイルをオープンできます。

図13-2 「既存の定義」ダイアログ・ボックス

「AMERICAN」を選択すると、lx00001.nlbファイルがオープンします。NLBファイルは、特定の言語、地域、キャラクタ・セットまたは言語ソートの設定を含むバイナリ・ファイルです。

言語と地域の略称は参照用のため、オープンできません。

「セッション・ログ」ダイアログ・ボックス

「ツール」→「ログの表示」を選択すると、「セッション・ログ」ダイアログ・ボックスが表示されます。「セッション・ログ」ダイアログ・ボックスには、現行のセッションで行われた処理が表示されます。「ログの保存」をクリックすると、すべての変更のレコードが保存されます。図13-3に、セッション・ログの例を示します。

図13-3 「セッション・ログ」ダイアログ・ボックス

「NLTのプレビュー」タブ・ページ

NLT(National Languare Text)ファイルは、ファイル拡張子が.nltのXMLファイルで、特定の言語、地域、キャラクタ・セットまたは言語ソートの設定を格納します。「NLTのプレビュー」タブ・ページには、ファイルが読取り可能な書式で表示されるため、変更内容が適切かどうかを確認できます。「NLTのプレビュー」タブ・ページからはNLTファイルを変更できません。NLTファイルを変更するには、Oracle Locale Builderで提供される特定のツールとプロシージャを使用する必要があります。

図13-4に、ユーザー定義言語AMERICAN FRENCHの「NLTのプレビュー」タブ・ページの例を示します。

図13-4 NLTファイルのプレビュー

ファイルを開くダイアログ・ボックス

「ファイル」→「開く」→ファイル名で指定を選択すると、「ファイルを開く」ダイアログ・ボックスを表示できます。次に、変更あるいはテンプレートとして使用するNLB(National Language Binary)ファイルを選択します。NLBファイルは、ファイル拡張子が.nlbのバイナリ・ファイルで、そのNLTファイル内の情報に相当するバイナリが含まれています。図13-5に、lx00001.nlbファイルが選択されているファイルを開くダイアログ・ボックスを示します。「プレビュー」ペインは、このNLBファイルがAMERICAN言語用であることを示しています。

図13-5 ファイルを開くダイアログ・ボックス

Oracle Locale Builderを使用した新規言語定義の作成

この項では、フランス語に基づいて新規言語を作成する方法について説明します。この新しい言語は、AMERICAN FRENCHと呼ぶことにします。最初に、「既存の定義」ダイアログ・ボックスからFRENCHをオープンします。次に、「一般」タブ・ページで言語名をAMERICAN FRENCHに変更し、「言語の略称」を「AF」に変更します。他の設定はデフォルト値のままにします。図13-6に、設定後の「一般」タブ・ページを示します。

図13-6 言語の一般情報

言語などのロケール・オブジェクトの名前を選択するときには、次の制限事項が適用されます。

- 名前にはASCII文字のみを使用する必要があります。

- 名前は文字で開始する必要があります。

- 言語、地域およびキャラクタ・セット名にはアンダースコアを使用できません。

ユーザー定義言語の場合、「言語ID」フィールドの有効範囲は1,000から10,000です。Oracle Locale Builderで提供される値を受け入れるか、この範囲内の値を指定できます。

注意:
特定のID範囲は、ユーザー定義のLANGUAGE、TERRITORY、CHARACTER SET、MONOLINGUAL COLLATIONおよびMULTILINGUAL COLLATIONの定義に対してのみ有効です。この章の各項では、各タイプのユーザー定義ロケール・オブジェクトに関係する範囲が指定されています。

図13-7に、「月名」タブ・ページを使用して月の名前を設定する方法を示します。

図13-7 「月名」タブ・ページ

すべての名前は、NLTファイルに表示されているとおりに示されます。先頭の文字を大文字にするかどうかに対して「はい」を選択すると、アプリケーションでは月の名前の先頭に大文字が使用されますが、「月名」タブ・ページでは大文字で表示されません。

図13-8に、「曜日」タブ・ページを示します。

図13-8 「曜日」タブ・ページ

ユーザー定義言語に曜日名を選択できます。すべての名前は、NLTファイルに表示されているとおりに示されます。先頭の文字を大文字にするかどうかに対して「はい」を選択すると、アプリケーションでは曜日名の先頭に大文字が使用されますが、曜日タブ・ページでは大文字で表示されません。

図13-9に、「共通情報」タブ・ページを示します。

図13-9 「共通情報」タブ・ページ

現在の言語に関連付けられている地域、キャラクタ・セット、Windows用キャラクタ・セットおよび言語ソートを表示できます。通常、最も適切な項目または最も一般的に使用されている項目が、最初に表示されます。たとえば、FRENCH言語では、共通地域はFRANCE、BELGIUM、CANADAおよびDJIBOUTIで、サポートされているキャラクタ・セットは、WE8ISO8859P1、WE8MSWIN1252、AL32UTF8およびWE8ISO8859P15です。Windows環境では、WE8ISO8859P1よりもWE8MSWIN1252が一般的であるため、最初に表示されます。

Oracle Locale Builderを使用した新規地域定義の作成

この項では、新規の地域REDWOOD SHORESを作成し、地域の略称としてRSを使用する方法について説明します。新規の地域は、既存の地域定義に基づいていません。

基本タスクは次のとおりです。

- 地域名の割当て

- カレンダ、数値、日付、時刻および通貨の各書式の選択

図13-10に、「地域名」としてREDWOOD SHORES、「地域ID」として1001、「地域の略称」としてRSが設定されている「一般」タブ・ページを示します。

図13-10 地域の「一般」タブ・ページ

ユーザー定義地域に対する「地域ID」フィールドの有効範囲は、1000から10000です。

図13-11に、「暦」タブ・ページのカレンダ書式の設定を示します。

図13-11 カレンダ書式の選択

月曜日が週の開始日として設定され、暦年の第1週がISO週として設定されています。図13-11には、サンプル・カレンダを示しています。

関連項目:

- 週の開始日と暦年の第1週を選択する方法の詳細は、「カレンダ書式」を参照してください。

- カレンダ自体をカスタマイズする方法は、「NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ」を参照してください。

図13-12に、「日付と時間」タブ・ページを示します。

図13-12 日付書式と時刻書式の選択

リストから書式を選択すると、書式の例が表示されます。このケースでは、短い日付書式がDD-MM-YY、短い時間書式がHH24:MI:SS、Oracle日付書式がDD-MM-YY、長い日付書式がfmDay, Month dd, yyyyに設定されています。タイムスタンプ・タイムゾーン書式は設定されていません。

ドロップダウン・メニューから選択せずに、独自のフォーマットを入力することもできます。

関連項目:

- 「日付書式」

- 「時刻書式」

- 「タイム・ゾーン・データのカスタマイズ」

図13-13に、「数値」タブ・ページを示します。

図13-13 数値書式の選択

「小数点記号」にはピリオドが選択されています。負の記号の位置は数値の左に設定されています。数値グループ・セパレータはカンマです。数値グループ化は3桁、リスト・セパレータはカンマ、測定法はメトリック、丸め指定は4に指定されています。

リストの値を使用せずに、独自の値を入力することもできます。

リストから書式を選択すると、書式の例が表示されます。

関連項目:
「数値書式」

図13-14に、「通貨」タブ・ページの通貨書式の設定を示します。

図13-14 通貨書式の選択

各国通貨記号には$が設定されています。代替通貨記号はユーロ記号です。通貨表記には、各国通貨記号、借方記号および数値が順に並びます。「小数点記号」はピリオド、「グループ・セパレータ」はカンマ、通貨数値のグループ化は3です。通貨の精度、つまり小数点以下の桁数は3です。貸方記号は+、借方記号は-です。国際通貨セパレータは空白であるため、フィールドには表示されていません。国際通貨記号(ISO通貨記号)はUSDです。Oracle Locale Builderには、ユーザーが選択した通貨書式の例が表示されます。

リストを使用せずに、独自の値を入力することもできます。

関連項目:
「通貨書式」

図13-15に、「共通情報」タブ・ページを示します。

図13-15 「共通情報」タブ・ページ

現在の地域の共通言語と共通タイム・ゾーンを表示できます。たとえば、地域がCANADAの場合、共通言語はENGLISH、CANADIAN FRENCHおよびFRENCHです。共通タイム・ゾーンは、America/Montreal、America/St_Johns、America/Halifax、America/Winnipeg、America/Regina、America/EdmontonおよびAmerica/Vancouverです。

これ以降の内容は、次のとおりです。

- タイム・ゾーン・データのカスタマイズ

- NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ

タイム・ゾーン・データのカスタマイズ

タイム・ゾーン・ファイルには、有効なタイム・ゾーン名が含まれています。各タイム・ゾーンには、次の情報が含まれています。

- 協定世界時(UTC)からのオフセット。

- 夏時間への移行時間。

- 標準時間と夏時間の略称。略称は、タイム・ゾーン名とともに使用されます。

タイム・ゾーン・ファイルはOracleデータベースのホーム・ディレクトリにあります。デフォルト・ファイルはoracore/zoneinfo/timezlrg_14.datです。一般に使用される、より小さいタイム・ゾーンは、oracore/zoneinfo/timezone_14.datに含まれています。

関連項目:
タイム・ゾーン・ファイルの内容と小さい方のタイム・ゾーン・ファイルのインストール方法の詳細は、「タイム・ゾーン・ファイルの選択」を参照してください。

NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ

Oracleデータベースは、複数のカレンダをサポートしています。これらのカレンダはすべてOracleデータベースのグローバリゼーション・サポートから導出されるデータで定義されていますが、一部は、将来、元号やうるう年の追加が必要になる場合があります。Oracleデータベースの新リリースまで待たずにこの情報を追加するには、カレンダ機能の実行時に自動的にロードされる外部ファイルを使用できます。

カレンダのデータは、最初にテキスト・ファイルに定義します。このテキスト定義ファイルは、バイナリ形式に変換する必要があります。NLSカレンダ・ユーティリティ(lxegen)を使用すると、テキスト定義ファイルをバイナリ形式に変換できます。

テキスト定義ファイルの名前とlxegenユーティリティに対する位置は、プラットフォーム依存の値でハードコード化されています。UNIXプラットフォームの場合、ファイル名はlxecal.nltで、$ORACLE_HOME/nlsディレクトリにあります。テキスト定義ファイルのサンプルは、$ORACLE_HOME/nls/demoディレクトリに含まれています。デモ・ファイルのインストール方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

lxegenユーティリティでは、テキスト定義ファイルからバイナリ・ファイルが生成されます。バイナリ・ファイル名もプラットフォーム依存の値でハードコード化されています。UNIXプラットフォームの場合、バイナリ・ファイル名はlxecal.nlbです。このバイナリ・ファイルは、テキスト・ファイルと同じディレクトリに生成され、既存のバイナリ・ファイルが上書きされます。

バイナリ・ファイルが生成されると、そのファイルはシステムの初期化時に自動的にロードされます。このファイルを移動したり名前を変更しないでください。

カレンダ・ユーティリティを起動するには、コマンドラインから次のように入力します。

% lxegen

関連項目:

- ご使用のシステム上のファイルの位置については、オペレーティング・システムのマニュアルを参照してください。

- 「暦法」

Oracle Locale Builderを使用したコード・チャートの表示

Oracle Locale Builderでは、キャラクタ・セットのコード・チャートを表示して印刷できます。Oracle Locale Builderの初期画面から「ファイル」→「新規」→「キャラクタ・セット」を選択します。図13-16に、表示される画面を示します。

図13-16 キャラクタ・セットの「一般」タブ・ページ

「既存の定義の表示」をクリックします。表示するキャラクタ・セットを選択します。図13-17に、US7ASCIIが選択されている「既存の定義」ダイアログ・ボックスを示します。

図13-17 「既存の定義」ダイアログ・ボックスでのUS7ASCIIの選択

「開く」をクリックしてキャラクタ・セットを選択します。図13-18に、US7ASCIIが選択されている「一般」タブ・ページを示します。

図13-18 US7ASCIIが選択されている「一般」タブ・ページ

「文字データのマッピング」タブをクリックします。図13-19に、US7ASCIIの「文字データのマッピング」タブ・ページを示します。

図13-19 US7ASCIIの「文字データのマッピング」タブ・ページ

「コード・チャートの表示」をクリックします。図13-20に、US7ASCIIのコード・チャートを示します。

図13-20 US7ASCIIコード・チャート

このコード・チャートは、ローカル・キャラクタ・セットでの各文字のエンコーディング値、各文字に関連付けられた絵文字、およびUnicode値を示しています。

コード・チャートを印刷する場合は、「ページの印刷」をクリックします。

Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

特定のユーザーのニーズにあわせてキャラクタ・セットをカスタマイズできます。エンコードされた既存のキャラクタ・セット定義を拡張できます。ユーザー定義文字は、多くの場合、次のような文字要素を表現する特殊文字をエンコードするために使用されます。

- 固有名

- 既存のキャラクタ・セット規格で定義されていない旧漢字

- ベンダー固有の文字

- ユーザーが新たに定義した記号または文字

この項では、Oracle Databaseでユーザー定義文字がどのようにサポートされているかを説明します。内容は次のとおりです。

- ユーザー定義文字(UDC)とキャラクタ・セット

- Oracle Databaseのキャラクタ・セット変換アーキテクチャ

- Unicode 5.0のPrivate Use Area

- キャラクタ・セット間でのユーザー定義文字のクロス・リファレンス

- 既存のキャラクタ・セットから新規キャラクタ・セットを作成する際のガイドライン

- 例: Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

ユーザー定義文字(UDC)とキャラクタ・セット

一般的に、ユーザー定義文字は東アジア諸国のキャラクタ・セットでサポートされています。東アジア諸国のキャラクタ・セットには、ユーザー定義文字を使用するために、コード・ポイントの予約域が少なくとも1つ用意されています。たとえば、日本語シフトJISでは、1880のコード・ポイントがユーザー定義文字用に確保されています。表13-1を参照してください。

表13-1 シフトJISのユーザー定義文字の範囲

日本語シフトJISのユーザー定義文字の範囲

コード・ポイント数

F040-F07E、F080-F0FC

188

F140-F17E、F180-F1FC

188

F240-F27E、F280-F2FC

188

F340-F37E、F380-F3FC

188

F440-F47E、F480-F4FC

188

F540-F57E、F580-F5FC

188

F640-F67E、F680-F6FC

188

F740-F77E、F780-F7FC

188

F840-F87E、F880-F8FC

188

F940-F97E、F980-F9FC

188

表13-2に示すOracleキャラクタ・セットには、ユーザー定義文字をサポートする事前定義済の範囲が含まれています。

表13-2 ユーザー定義文字の範囲を含むOracleデータベースのキャラクタ・セット

キャラクタ・セット名

ユーザー定義文字に使用可能なコード・ポイント数

JA16DBCS

4370

JA16EBCDIC930

4370

JA16SJIS

1880

JA16SJISYEN

1880

KO16DBCS

1880

KO16MSWIN949

1880

ZHS16DBCS

1880

ZHS16GBK

2149

ZHT16DBCS

6204

ZHT16MSWIN950

6217

Oracleデータベースのキャラクタ・セット変換アーキテクチャ

特定の文字を表すコード・ポイントの値は、キャラクタ・セットによって異なります。図13-21に、日本語の漢字を示します。

図13-21 日本語の漢字

次の表に、この文字が様々なキャラクタ・セットでどのようにエンコードされるかを示します。

Unicodeエンコーディング

JA16SJISエンコーディング

JA16EUCエンコーディング

JA16DBCSエンコーディング

4E9C

889F

B0A1

4867

Oracleデータベースでは、すべてのキャラクタ・セットをUnicode 5.0のコード・ポイントの見地から定義しています。つまり、それぞれの文字はUnicode 5.0のコード値として定義されています。中間フォームとしてUnicodeを使用することによって、ユーザーが意識することなく文字変換が行われます。たとえば、JA16SJISのクライアントがJA16EUCのデータベースに接続する場合、JA16SJISのクライアントから入力した図13-21の文字のコード・ポイント値は889Fとなります。この文字は内部的にUnicode(コード・ポイント値は4E9C)に変換された後、JA16EUC(コード・ポイント値はB0A1)に変換されます。

Unicode 5.0のPrivate Use Area

Unicode 5.0では、Private Use Area(PUA)用にE000からF8FFの範囲が予約されています。PUAは、エンド・ユーザーまたはベンダーがプライベートで使用する文字を定義するためのものです。

ユーザー定義文字は、標準文字と同様に中間フォームとしてUnicode 5.0のPUAを使用して、2つのOracleデータベース・キャラクタ・セット間で変換されます。

キャラクタ・セット間でのユーザー定義文字のクロス・リファレンス

ユーザー定義文字を複数のオペレーティング・システムにまたがって登録する場合は、異なるキャラクタ・セット間のクロス・リファレンスが必要になります。クロス・リファレンスにより、キャラクタ・セットがUnicode PUAの値にマッピングされ、ユーザー定義文字を異なるキャラクタ・セット間で確実に正しく変換できます。

たとえば、ユーザー定義文字を日本語シフトJISのオペレーティング・システムと日本語IBMホスト・オペレーティング・システムの両方に登録する場合、この文字に対して、シフトJISのオペレーティング・システムではF040コード・ポイント、IBMホスト・オペレーティング・システムでは6941コード・ポイントの割当てができます。これによって、キャラクタ・セットJA16SJISとJA16DBCSの間で、この文字が正しくマップされます。

Oracle Locale Builderを使用してキャラクタ・セット定義を表示すると、ユーザー定義文字のクロス・リファレンス情報を検索できます。たとえば、シフトJISのUDC値F040とIBMホストのUDC値6941が、同じUnicode PUA値E000にマップされていることがわかります。

関連項目:
付録B「Unicode文字コードの割当て」

既存のキャラクタ・セットから新規キャラクタ・セットを作成する際のガイドライン

デフォルトの場合、Oracle Locale Builderは次に使用可能なキャラクタ・セットIDを生成します。独自のキャラクタ・セットIDを選択することもできます。キャラクタ・セット定義用NLTファイルのネーミングには、次の書式を使用します。

lx2dddd.nlt

ddddは、16進数で4桁のキャラクタ・セットIDです。

キャラクタ・セットを変更する場合は、次のガイドラインに従ってください。

- 既存の文字を再マップしないでください。

- すべての文字のマッピングは一意であることが必要です。

- 新規文字は、Unicodeのプライベート使用範囲(e000からf4ff)にマップする必要があります。(実際のUnicode 5.0のプライベート使用範囲はe000からf8ffです。ただし、f500からf8ffはOracleデータベース固有のプライベート使用のために予約されています。)

- キャラクタ・セット定義ファイルでは、1行の最大文字数は80文字です。

注意:
既存のキャラクタ・セットから新規のマルチバイト・キャラクタ・セットを作成する場合は、元のキャラクタ・セットとして8ビットまたはマルチバイト・キャラクタ・セットを使用してください。

新規キャラクタ・セットを既存のOracle Databaseキャラクタ・セットから導出する場合は、次のキャラクタ・セットのネーミング規則を使用することをお薦めします。

<Oracle_character_set_name><organization_name>EXT<version>

たとえば、Sun社などの会社がJA16EUCキャラクタ・セットにユーザー定義文字を追加する場合、適切なキャラクタ・セット名は次のようになります。

JA16EUCSUNWEXT1

このキャラクタ・セット名は、次の各部分で構成されています。

- JA16EUCは、Oracle Databaseが定義したキャラクタ・セット名です。

- SUNWは、会社名(Sun社の株式取引上の略称)を表します。

- EXTは、JA16EUCキャラクタ・セットに対する拡張要素であることを示します。

- 1はバージョンを示します。

例: Oracle Locale Builderを使用した新規キャラクタ・セット定義の作成

この項では、キャラクタ・セットIDに10001を指定して、新規のキャラクタ・セットMYCHARSETを作成する方法について説明します。この例では、WE8ISO8859P1キャラクタ・セットを使用して中国語の10文字を追加します。

図13-22に、MYCHARSETの「一般」タブ・ページを示します。

図13-22 MYCHARSETの「一般」タブ・ページ

「既存の定義の表示」をクリックし、「既存の定義」ダイアログ・ボックスからWE8ISO8859P1キャラクタ・セットを選択します。

「ISOキャラクタ・セットID」フィールドと「基本キャラクタ・セットID」フィールドはオプションです。「基本キャラクタ・セットID」は値の継承に使用され、基本キャラクタ・セットのプロパティがテンプレートとして使用されます。「キャラクタ・セットID」は自動的に生成されますが、オーバーライドして変更することもできます。ユーザー定義キャラクタ・セットIDの有効範囲は、8000から8999または10000から20000です。

注意:
Pro*COBOLを使用している場合は、8000から8999のキャラクタ・セットIDを選択してください。

ユーザー定義キャラクタ・セットの場合、「ISOキャラクタ・セットID」フィールドは空白のままです。

この例では、「基本キャラクタ・セットID」フィールドは空白のままです。ただし、テンプレートとして使用するキャラクタ・セットを指定できます。「型指定」タブ・ページの設定は、「基本キャラクタ・セットID」フィールドに入力した基本キャラクタ・セットの型設定と一致する必要があります。型設定が一致しない場合、カスタム・キャラクタ・セットの生成時にエラーが表示されます。

図13-23に、「型指定」タブ・ページを示します。

図13-23 「型指定」タブ・ページ

キャラクタ・セット・カテゴリはASCII_BASEDで、「BYTE_UNIQUE」ボタンが選択されています。

既存のキャラクタ・セットを選択した場合、「型指定」タブ・ページのフィールドはすでに適切な値に設定されています。変更する特別な理由がないかぎり、これらの値を保持してください。設定の変更が必要な場合は、次のガイドラインを使用します。

- 「FIXED_WIDTH」は、同じ長さの文字のキャラクタ・セットを示すために使用します。

- 「BYTE_UNIQUE」は、コード・ポイントのシングルバイト範囲がマルチバイト範囲と区別されていることを示します。先頭バイトのコードは、その文字がシングルバイトかマルチバイトかを示します。例: JA16EUC。

- 「DISPLAY」は、格納用ではなくクライアントでの表示用にのみ使用されるキャラクタ・セットを示します。一部のアラビア語、デーバナーガリ語およびヘブライ語のキャラクタ・セットは、表示用キャラクタ・セットです。

- 「SHIFT」は、シングルバイト文字とマルチバイト文字とを区別するために、追加のシフト文字が必要なキャラクタ・セットに対して使用します。

関連項目:
シフトイン・キャラクタ・セットとシフトアウト・キャラクタ・セットの詳細は、「可変幅マルチバイト・コード体系」を参照してください。

図13-24に、ユーザー定義文字の追加方法を示します。

図13-24 ユーザー定義文字データのインポート

「文字データのマッピング」タブ・ページをオープンします。キャラクタ・セット内で追加する文字の前になる文字を選択します。この例では、0xffローカル文字の値が選択されています。

1回に1文字を追加することも、テキスト・ファイルを使用して大量の文字をインポートすることも可能です。この例では、テキスト・ファイルをインポートしています。最初の列は、ローカル文字の値です。2列目はUnicode値です。このファイルには、次の文字の値が含まれています。

88a2 963f 88a3 54c0 88a4 611b 88a5 6328 88a6 59f6 88a7 9022 88a8 8475 88a9 831c 88aa 7a50 88ab 60aa

「ファイル」→「インポート」→「ユーザー定義文字データ」を選択します。

図13-25に、インポートした文字をキャラクタ・セットの0xffの後に追加した状態を示します。

図13-25 キャラクタ・セットの新しい文字

Oracle Locale Builderを使用した新規言語ソートの作成

この項では、「照合ID」を10001に設定してMY_GENERIC_Mと呼ばれる新規の多言語ソートを作成する方法を示します。新規言語ソートの基礎としてGENERIC_M言語ソートを使用しています。図13-26に、この操作の開始方法を示します。

図13-26 照合の「一般」タブ・ページ

フラグの設定は、自動的に導出されます。「SWAP_WITH_NEXT」は、タイ語とラオ語のソートに関係します。「REVERSE_SECONDARY」は、フランス語のソート用です。「CANONICAL_EQUIVALENCE」は、標準的な規則を使用するかどうかを決定します。この例では、「CANONICAL_EQUIVALENCE」がオンになっています。

ユーザー定義ソートのための「照合ID」(ソートID)の有効範囲は、単一言語照合の場合は1000から2000、多言語照合の場合は10000から11000です。

関連項目:

- 標準的な規則の詳細は、図13-30「「標準規則」ダイアログ・ボックス」を参照してください。

- 第5章「言語ソートと文字列検索」

図13-27に、「Unicode照合順序」タブ・ページを示します。

図13-27 「Unicode照合順序」タブ・ページ

この例では、文字の後にソートされるように数字を移動して、言語ソートをカスタマイズします。手順は次のとおりです。

1. 移動するUnicode値を選択します。図13-27では、\x0034 Unicode値が選択されています。「Unicode照合順序」タブ・ページでの値の位置は、ノードと呼ばれます。

2. 「切取り」をクリックします。ノードを移動する位置を選択します。

3. 「貼付け」をクリックします。「貼付け」をクリックすると、図13-28に示す「ノードの貼付け」ダイアログ・ボックスがオープンします。

図13-28 「ノードの貼付け」ダイアログ・ボックス

- 「ノードの貼付け」ダイアログ・ボックスでは、選択した位置の後にノードを貼り付けるか前に貼り付けるかを選択できます。隣に貼り付けるノードに対するノードのレベル(1次、2次または3次)を選択することもできます。
ノードを貼り付ける位置とレベルを選択します。

図13-28では、「後」ボタンと「1次」ボタンが選択されています。

- 「OK」をクリックしてノードを貼り付けます。
同様の手順に従って、他の数字を文字aからzの後の位置に移動します。

図13-29に、数字0から4を文字aからzの後の位置に移動した後の「Unicode照合順序」タブ・ページを示します。

図13-29 変更後の「Unicode照合順序」画面

これ以降の内容は、次のとおりです。

- 同じ発音区別記号を持つすべての文字のソート順序の変更

- 発音区別記号を持つ1文字のソート順序の変更

同じ発音区別記号を持つすべての文字のソート順序の変更

次の例に、発音区別記号付きの文字のソート順序を変更する方法を示します。そのためには、特定の発音区別記号を含むすべての文字のソート順序を変更する方法と、一度に1文字ずつ変更する方法があります。この例では、曲折アクセント記号付きの各文字(ûなど)のソート順序を、チルドが付いた同じ文字の後になるように変更します。

「ツール」→「標準規則」を選択して、現在のソート順序を確認します。図13-30の「標準規則」ダイアログ・ボックスが開きます。

図13-30 「標準規則」ダイアログ・ボックス

図13-30に、アクセント記号付き文字が、対応する標準的な文字に分解される方法と現在のソート順序を示します。たとえば、ûはuと^の組合せとして表されます。

関連項目:
標準的な規則の詳細は、第5章「言語ソートと文字列検索」を参照してください。

Oracle Locale Builderの照合の「一般」タブ・ページ(図13-26)で、「空白以外の文字」タブをクリックします。「空白以外の文字」タブ・ページを使用すると、発音区別記号に対する変更がすべての文字に適用されます。図13-31に、「空白以外の文字」タブ・ページを示します。

図13-31 同じ発音区別記号を持つすべての文字のソート順序の変更

曲折アクセント記号を選択して「切取り」をクリックします。「削除の確認」ダイアログ・ボックスで「はい」をクリックします。チルドを選択して「貼付け」をクリックします。「ノードの貼付け」ダイアログ・ボックスで「後」と「2次」を選択して「OK」をクリックします。

図13-32に、新しいソート順序を示します。

図13-32 同じ発音区別記号を持つ文字の新規のソート順序

発音区別記号を持つ1文字のソート順序の変更

発音区別記号を持つ特定の文字の順序を変更するには、その文字を適切な位置に直接挿入します。発音区別記号付きの文字は「Unicode照合順序」タブ・ページに表示されないため、新しい位置へのカット・アンド・ペーストはできません。

この例では、äのソート順序をZの後にソートされるように変更します。

「Unicode照合」タブをクリックします。äの隣に配置する文字Zを選択します。「追加」をクリックします。図13-33の「新規ノードの挿入」ダイアログ・ボックスが表示されます。

図13-33 発音区別記号を持つ1文字のソート順序の変更

「新規ノードの挿入」ダイアログ・ボックスで「後」と「1次」を選択します。äのUnicodeコード・ポイント値を入力します。このコード・ポイント値は、\x00e4です。「OK」をクリックします。

図13-34に、変更後のソート順序を示します。

図13-34 1文字を変更後の新規ソート順序

NLBファイルの生成とインストール

新規言語、地域、キャラクタ・セットまたは言語ソートを定義した後は、NLTファイルから新規のNLBファイルを次のように生成します。

1. ファイルの所有者(通常はユーザーoracle)として、ORA_NLS10ディレクトリ内で、NLSインストール・ブート・ファイル(lx0boot.nlb)とNLSシステム・ブート・ファイル(lx1boot.nlb)のバックアップを作成します。UNIXプラットフォームの場合は、次のようなコマンドを入力します。

% setenv ORA_NLS10 $ORACLE_HOME/nls/data
% cd $ORA_NLS10
% cp -p lx0boot.nlb lx0boot.nlb.orig
% cp -p lx1boot.nlb lx1boot.nlb.orig

-pオプションを指定すると、元のファイルのタイムスタンプが保たれることに注意してください。

2. Oracle Locale Builderで、「ツール」→「NLBの生成」を選択するか、左側のバーで「NLBの生成」アイコンをクリックします。

3. 「参照」をクリックして、NLTファイルが格納されているディレクトリを検索します。位置を指定するダイアログ・ボックスは、図13-35のとおりです。

図13-35 「位置」ダイアログ・ボックス

NLTファイルは指定しないでください。Oracle Locale Builderは、各NLTファイルに対してNLBファイルを生成します。

4. 「OK」をクリックしてNLBファイルを生成します。
図13-36は、ディレクトリ内の全NLTファイルに対してNLBファイルが正常に生成されたことを示す最終的な通知を示しています。

図13-36 「NLBの生成の成功」ダイアログ・ボックス

5. lx1boot.nlbファイルをORA_NLS10環境変数で指定したパスにコピーします。たとえば、UNIXプラットフォームの場合は、次のようなコマンドを入力します。

% cp /directory_name/lx1boot.nlb $ORA_NLS10/lx1boot.nlb

6. 新規のNLBファイルをORA_NLS10ディレクトリにコピーします。たとえば、UNIXプラットフォームの場合は、次のようなコマンドを入力します。

% cp /directory_name/lx22710.nlb $ORA_NLS10
% cp /directory_name/lx52710.nlb $ORA_NLS10

注意:
Oracle Locale Builderでは、NLTファイルと同じディレクトリにNLBファイルが生成され、一般的には../nlsrtl3/admin/dataです。

7. 新規に作成したロケール・データを使用できるように、データベースを再起動します。

8. 新規のロケール・データをクライアント側で使用するには、NLBファイルをインストールしてからクライアントを終了し、再起動します。

関連項目:
ORA_NLS10環境変数の詳細は、「オンデマンドのロケール・データ」を参照してください。

その他のプラットフォームにおけるカスタムNLBファイルのデプロイ

ロケール・カスタマイズ・ファイルを、同じOracleデータベースのリリースで動作し、かつ同じオペレーティング・システム・プラットフォームを使用する他のOracleデータベースのインストールにデプロイする場合、すべてのカスタムNLBファイルとlx1boot.nlbファイルをターゲット・マシンにコピーする必要があります。カスタムNLBファイルを別のプラットフォームにデプロイするには、カスタム.NLTファイルを新規プラットフォームにコピーしてから、「NLBファイルの生成とインストール」の項で説明しているNLBの生成とインストールの手順を繰り返す必要があります。

旧リリースOracle DatabaseからのカスタムNLBファイルのアップグレード

ロケール定義ファイルは、データベースのリリースに依存しています。たとえば、Oracle Database 9iおよびOracle Database 10gのNLBファイルは、Oracle Database 11gリリース1などで直接サポートされていません。ロケール・カスタマイズ・ファイルを旧リリースのデータベースから現行のリリースに移行するには、最初にこのファイルを最新のNLT形式に変換する必要があります。そのためには、ロケール・カスタマイズ・ファイル(NLBまたはNLT)をロードし、現行バージョンのOracle Locale Builderを使用してこれらのファイルを個別にNLTファイルに保存します。次に、「NLBファイルの生成とインストール」の項で説明しているNLBの生成とインストールの手順を繰り返す必要があります。

Oracle Locale Builderは、旧バージョンのNLTファイルおよびNLBファイルの読込みと処理、さらに別のプラットフォームからのこれらのファイルの読込みと処理が可能である点に注意してください。ただし、Oracle Locale Builderでは、インストールされているOracle Databaseのリリースの最新の書式でNLTファイルが保存および生成されます。

NLBデータ・フォームの別のプラットフォームへの転送

あるプラットフォーム上で生成されるNLBデータを、FTPまたはその他のコピー・ユーティリティを使用して別のプラットフォームに転送できます。転送されたNLBファイルは、元のプラットフォームで生成されたNLBファイルと同じ方法で使用できます。たとえば、Solarisプラットフォーム上で生成されたNLBファイルをFTPでWindowsプラットフォームにコピーし、そこで同じ機能を提供できます。これにより、あるプラットフォームでロケール・データを変更して他のプラットフォームにコピーできるため便利です。プラットフォーム間では、変更があったファイルのみでなく、すべてのNLBファイルをコピーする必要があることに注意してください。また、「NLBファイルの生成とインストール」の操作の実行方法は、以前のリリースと同じであることにも注意してください。

NLBのロード中には、様々なバイナリ形式(32ビット、64ビット、ビッグ・エンディアン、リトル・エンディアン、ASCIIおよびEBCDICなど)が、透過的に処理されます。

GINSTALLユーティリティを使用したJavaコンポーネントへのカスタムのロケール定義の追加

ginstallユーティリティは、使用するアプリケーションのJavaコンポーネントにカスタム・キャラクタ・セット、言語、地域、および言語ソートを追加します。Locale Builderを使用して、カスタム・キャラクタ・セット、言語、地域、および言語ソートを定義します。カスタム定義を含むNLTファイルがLocale Builderによって生成されます。カスタム定義をJavaコンポーネントを追加するには、ginstallを実行してgdk_custom.jarを生成します。Oracle Databaseリリース10.2および10.1でも、リリース11.1および11.2と同様の手順を使用できます。

キャラクタ・セット、言語、地域、および言語ソートにカスタム定義を追加する手順は、次のとおりです。

1. Oracle Locale Builderを使用して、NLTファイルを生成します。
カスタムのNLBファイルを旧リリースからアップグレードする場合、「旧リリースOracle DatabaseからのカスタムNLBファイルのアップグレード」で説明する手順に従ってください。

2. ginstallを-addまたは-aオプションを指定して実行し、gdk_custom.jarを生成します。

ginstall –[add | a] lx2dddd.nlt

NLTファイルを生成する手順は、次のとおりです。

ginstall -[add | a] lx2ddd.nlt lx2dddd.nlt lx2dddd.nlt

3. gdk_custom.jarを、orai18n.jarまたはorai18n-mapping.jarと同じディレクトリにコピーします。

カスタム定義を削除する手順は、次のとおりです。

- 次のようにして、ginstallを実行します。

ginstall –[remove | r] <path to gdk_custom.jar> <name of NLT file>

カスタム定義を更新する手順は、次のとおりです。

- 次のようにして、ginstallを実行します。

ginstall –[update | u] <path to gdk_custom.jar> <name of NLT file>

A ロケール・データ

この付録では、Oracle Databaseでサポートされている言語、地域、キャラクタ・セットおよびその他のロケール・データについて説明します。ここでは、次の項目について説明します。

- 言語

- 翻訳済メッセージ

- 地域

- キャラクタ・セット

- 言語およびキャラクタ・セット検出のサポート

- 言語ソート

- 暦法

- タイム・ゾーン・リージョン名

- 廃止されたロケール・データ

キャラクタ・セット、言語、地域および言語ソートに関する情報は、V$NLS_VALID_VALUES動的パフォーマンス・ビューを問い合せて取得できます。

関連項目:
このビューで戻すことができるデータの詳細は、『Oracle Databaseリファレンス』を参照してください。

言語

表A-1に示す言語は、それぞれ次のようなロケール依存情報をサポートしています。

- 日と月の名前および略称

- A.M.、P.M.、A.D.およびB.C.に相当する記号

- ORDER BY SQL句が指定されている場合の文字データのデフォルトのソート順序

- 書込み方向(左から右または右から左)

- 肯定的および否定的な応答文字列(YESおよびNOなど)

Unicodeデータベースとデータ型を使用することで、表A-1に示されていない多数の言語も含め、ほとんどすべての現代言語についてデータの格納、処理および取出しを実行できます。

表A-1 Oracle Databaseがサポートしている言語

言語名

言語の略称

デフォルト・ソート

ALBANIAN

sq

GENERIC_M

AMERICAN

us

バイナリ

ARABIC

ar

ARABIC

ASSAMESE

as

バイナリ

AZERBAIJANI

az

AZERBAIJANI

BANGLA

bn

バイナリ

BELARUSIAN

be

RUSSIAN

BRAZILIAN PORTUGUESE

ptb

WEST_EUROPEAN

BULGARIAN

bg

BULGARIAN

CANADIAN FRENCH

frc

CANADIAN FRENCH

CATALAN

ca

CATALAN

CROATIAN

hr

CROATIAN

CYRILLIC KAZAKH

ckk

GENERIC_M

CYRILLIC SERBIAN

csr

GENERIC_M

CYRILLIC UZBEK

cuz

GENERIC_M

CZECH

cs

CZECH

DANISH

dk

DANISH

DUTCH

nl

DUTCH

EGYPTIAN

eg

ARABIC

ENGLISH

gb

バイナリ

ESTONIAN

et

ESTONIAN

FINNISH

sf

FINNISH

FRENCH

f

FRENCH

GERMAN DIN

din

GERMAN

GERMAN

d

GERMAN

GREEK

el

GREEK

GUJARATI

gu

バイナリ

HEBREW

iw

HEBREW

HINDI

hi

バイナリ

HUNGARIAN

hu

HUNGARIAN

ICELANDIC

is

ICELANDIC

INDONESIAN

in

INDONESIAN

IRISH

ga

バイナリ

ITALIAN

i

WEST_EUROPEAN

JAPANESE

ja

バイナリ

KANNADA

kn

バイナリ

KOREAN

ko

バイナリ

LATIN AMERICAN SPANISH

esa

SPANISH

LATIN SERBIAN

lsr

バイナリ

LATIN UZBEK

luz

GENERIC_M

LATVIAN

lv

LATVIAN

LITHUANIAN

lt

LITHUANIAN

MACEDONIAN

mk

バイナリ

MALAY

ms

MALAY

MALAYALAM

ml

バイナリ

MARATHI

mr

バイナリ

MEXICAN SPANISH

esm

WEST_EUROPEAN

NORWEGIAN

n

NORWEGIAN

ORIYA

or

バイナリ

POLISH

pl

POLISH

PORTUGUESE

pt

WEST_EUROPEAN

PUNJABI

pa

バイナリ

ROMANIAN

ro

ROMANIAN

RUSSIAN

ru

RUSSIAN

SIMPLIFIED CHINESE

zhs

バイナリ

SLOVAK

sk

SLOVAK

SLOVENIAN

sl

SLOVENIAN

SPANISH

e

SPANISH

SWEDISH

s

SWEDISH

TAMIL

ta

バイナリ

TELUGU

te

バイナリ

THAI

th

THAI_DICTIONARY

TRADITIONAL CHINESE

zht

バイナリ

TURKISH

tr

TURKISH

UKRAINIAN

uk

UKRAINIAN

VIETNAMESE

vn

VIETNAMESE

翻訳済メッセージ

Oracleデータベースのエラー・メッセージは、表A-2に示す言語に翻訳されています。

表A-2 Oracle Databaseがサポートしているメッセージ

名前

略称

ARABIC

ar

BRAZILIAN PORTUGUESE

ptb

CATALAN

ca

CZECH

cs

DANISH

dk

DUTCH

nl

FINNISH

sf

FRENCH

f

GERMAN

d

GREEK

el

HEBREW

iw

HUNGARIAN

hu

ITALIAN

i

JAPANESE

ja

KOREAN

ko

NORWEGIAN

n

POLISH

pl

PORTUGUESE

pt

ROMANIAN

ro

RUSSIAN

ru

SIMPLIFIED CHINESE

zhs

SLOVAK

sk

SPANISH

e

SWEDISH

s

THAI

th

TRADITIONAL CHINESE

zht

TURKISH

tr

地域

表A-3に、Oracleデータベースでサポートしている地域を示します。

表A-3 Oracle Databaseがサポートしている地域

名前

名前

名前

ALBANIA

GREECE

PUERTO RICO

ALGERIA

HONG KONG

QATAR

AMERICA

HUNGARY

ROMANIA

ARGENTINA

ICELAND

RUSSIA

AUSTRALIA

INDIA

SAUDI ARABIA

AUSTRIA

INDONESIA

SERBIA AND MONTENEGRO

AZERBAIJAN

IRAQ

SINGAPORE

BAHRAIN

IRELAND

SLOVAKIA

BANGLADESH

ISRAEL

SLOVENIA

BELARUS

ITALY

SOMALIA

BELGIUM

JAPAN

SOUTH AFRICA

BRAZIL

JORDAN

SPAIN

BULGARIA

KAZAKHSTAN

SUDAN

CANADA

KOREA

SWEDEN

CATALONIA

KUWAIT

SWITZERLAND

CHILE

LATVIA

SYRIA

CHINA

LEBANON

TAIWAN

COLOMBIA

LIBYA

THAILAND

COSTA RICA

LITHUANIA

THE NETHERLANDS

CROATIA

LUXEMBOURG

TUNISIA

CYPRUS

MALAYSIA

TURKEY

CZECH REPUBLIC

MAURITANIA

UKRAINE

DENMARK

MEXICO

UNITED ARAB EMIRATES

DJIBOUTI

MOROCCO

UNITED KINGDOM

ECUADOR

NEW ZEALAND

UZBEKISTAN

EGYPT

NICARAGUA

VENEZUELA

EL SALVADOR

NORWAY

VIETNAM

ESTONIA

OMAN

YEMEN

FINLAND

PANAMA

-

FRANCE

PERU

-

FYR MACEDONIA

PHILIPPINES

-

GUATEMALA

POLAND

-

GERMANY

PORTUGAL

-

キャラクタ・セット

ここでは、Oracle Databaseがサポートしているキャラクタ・セットを、次の3つの広範囲なカテゴリに分けて示します。

- 推奨するデータベース・キャラクタ・セット

- その他のキャラクタ・セット

- クライアント専用のキャラクタ・セット

また、共通のキャラクタ・セットのサブセットとスーパーセットの組合せも示します。一部のキャラクタ・セットは、特定のデータ型のみで使用できます。たとえば、AL16UTF16キャラクタ・セットはNCHARキャラクタ・セットとしてのみ使用でき、データベース・キャラクタ・セットとしては使用できません。

コメント・セクションには、ユーザーまたはデータベース管理者にとって重要な、キャラクタ・セットに固有のその他の特徴も記載されています。たとえば、キャラクタ・セットがユーロ通貨記号をサポートしているかどうか、ユーザー定義文字がサポートされているかどうか、およびキャラクタ・セットがASCIIの完全なスーパーセットであるかどうかなどの情報が記載されています。(すべてのスキーマ・データが新しいキャラクタ・セットの完全なサブセットである場合のみ、CSALTERスクリプトを使用して、既存のデータベースを新しいキャラクタ・セットに移行できます。)

キャラクタ・セット表のコメント列の凡例は、次のとおりです。

SB: シングルバイト・エンコーディング

MB: マルチバイト・エンコーディング

FIXED: 固定幅マルチバイト・エンコーディング

ASCII: ASCIIの完全なスーパーセット

EURO: ユーロ記号をサポート

UDC: ユーザー定義文字をサポート

個々のコード・ページのレイアウトは記述されていません。特定のキャラクタ・セット固有の情報、文字レパートリおよびコード・ポイントの値については、Oracle Locale Builderを使用できます。それ以外の場合は、実際の各国の規格、国際規格またはベンダー固有の規格を参照してください。

関連項目:
第13章「ロケール・データのカスタマイズ」

推奨するデータベース・キャラクタ・セット

表A-4に、最も一般的に使用されているお薦めのASCIIベースOracleデータベース・キャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表A-4 推奨するASCIIデータベース・キャラクタ・セット

名前

説明

コメント

アジア地域

-

-

-

-

JA16EUC

EUC 24ビット日本語

MB、ASCII

-

JA16EUCTILDE

波形のダッシュとチルドがUnicodeとの間でマッピングされる方法を除き、JA16EUCと同じ

MB、ASCII

-

JA16SJIS

シフトJIS 16ビット日本語

MB、ASCII、UDC

-

JA16SJISTILDE

波形のダッシュとチルドがUnicodeとの間でマッピングされる方法を除き、JA16SJISと同じ

MB、ASCII、UDC

-

KO16MSWIN949

MS Windowsコード・ページ949韓国語

MB、ASCII、UDC

-

TH8TISASCII

タイ工業規格620-2533 - ASCII 8ビット

SB、ASCII、EURO

-

VN8MSWIN1258

MS Windowsコード・ページ1258 8ビット・ベトナム語

SB、ASCII、EURO

-

ZHS16GBK

GBK 16ビット簡体字中国語

MB、ASCII、UDC

-

ZHT16HKSCS

MS Windowsコード・ページ950香港補足キャラクタ・セットHKSCS-2001付き(Unicodeとの間のキャラクタ・セット変換はUnicode 3.0に基づきます。)

MB、ASCII、EURO

-

ZHT16MSWIN950

MS Windowsコード・ページ950繁体字中国語

MB、ASCII、UDC

-

ZHT32EUC

EUC 32ビット繁体字中国語

MB、ASCII

ヨーロッパ地域

-

-

-

-

BLT8ISO8859P13

ISO 8859-13バルト語

SB、ASCII

-

BLT8MSWIN1257

MS Windowsコード・ページ1257 8ビット・バルト語

SB、ASCII、EURO

-

CL8ISO8859P5

ISO 8859-5ラテン語/キリル文字

SB、ASCII

-

CL8MSWIN1251

MS Windowsコード・ページ1251 8ビット・ラテン語/キリル文字

SB、ASCII、EURO

-

EE8ISO8859P2

ISO 8859-2東ヨーロッパ語

SB、ASCII

-

EL8ISO8859P7

ISO 8859-7ラテン語/ギリシャ語

SB、ASCII、EURO

-

EL8MSWIN1253

MS Windowsコード・ページ1253 8ビット・ラテン語/ギリシャ語

SB、ASCII、EURO

-

EE8MSWIN1250

MS Windowsコード・ページ1250 8ビット東ヨーロッパ語

SB、ASCII、EURO

-

NE8ISO8859P10

ISO 8859-10北ヨーロッパ語

SB、ASCII

-

NEE8ISO8859P4

ISO 8859-4北ヨーロッパ語および北東ヨーロッパ語

SB、ASCII

-

WE8ISO8859P15

ISO 8859-15西ヨーロッパ語

SB、ASCII、EURO

-

WE8MSWIN1252

MS Windowsコード・ページ1252 8ビット西ヨーロッパ語

SB、ASCII、EURO

中東地域

-

-

-

-

AR8ISO8859P6

ISO 8859-6ラテン語/アラビア語

SB、ASCII

-

AR8MSWIN1256

MS Windowsコード・ページ1256 8ビット・ラテン語/アラビア語

SB、ASCII、EURO

-

IW8ISO8859P8

ISO 8859-8ラテン語/ヘブライ語

SB、ASCII

-

IW8MSWIN1255

MS Windowsコード・ページ1255 8ビット・ラテン語/ヘブライ語

SB、ASCII、EURO

-

TR8MSWIN1254

MS Windowsコード・ページ1254 8ビット・トルコ語

SB、ASCII、EURO

-

WE8ISO8859P9

ISO 8859-9西ヨーロッパ語

SB、ASCII

ユニバーサル

-

-

-

-

AL32UTF8

Unicode 5.0 UTF-8ユニバーサル・キャラクタ・セット

MB、ASCII、EURO

表A-5に、最も一般的に使用されているお薦めのEBCDICベースOracleデータベース・キャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表A-5 推奨するEBCDICデータベース・キャラクタ・セット

名前

説明

コメント

アジア地域

-

-

-

-

JA16DBCS

IBM EBCDIC 16ビット日本語

MB、UDC

-

JA16EBCDIC930

IBM DBCSコード・ページ290 16ビット日本語

MB、UDC

-

KO16DBCS

IBM EBCDIC 16ビット韓国語

MB、UDC

-

TH8TISEBCDICS

タイ工業規格620-2533-EBCDICサーバー8ビット

SB

ヨーロッパ地域

-

-

-

-

BLT8EBCDIC1112S

EBCDICコード・ページ1112サーバー8ビット・バルト多言語

SB

-

CE8BS2000

Siemens EBCDIC.DF.04 8ビット中央ヨーロッパ語

SB

-

CL8BS2000

Siemens EBCDIC.EHC.LC 8ビット・キリル文字

SB

-

CL8EBCDIC1025R

EBCDICコード・ページ1025サーバー8ビット・キリル文字

SB

-

CL8EBCDIC1158R

EBCDICコード・ページ1158サーバー8ビット・キリル文字

SB

-

D8EBCDIC1141

EBCDICコード・ページ1141 8ビット・ドイツ語(オーストリア)

SB、EURO

-

DK8EBCDIC1142

EBCDICコード・ページ1142 8ビット・デンマーク語

SB、EURO

-

EE8BS2000

Siemens EBCDIC.DF.04 8ビット東ヨーロッパ語

SB

-

EE8EBCDIC870S

EBCDICコード・ページ870サーバー8ビット東ヨーロッパ語

SB

-

EL8EBCDIC423R

RDBMSサーバー側用IBM EBCDICコード・ページ423

SB

-

EL8EBCDIC875R

EBCDICコード・ページ875サーバー8ビット・ギリシア語

SB

-

F8EBCDIC1147

EBCDICコード・ページ1147 8ビット・フランス語

SB、EURO

-

I8EBCDIC1144

EBCDICコード・ページ1144 8ビット・イタリア語

SB、EURO

-

SE8EBCDCI1143

EBCDICコード・ページ1143 8ビット・スウェーデン語

SB、EURO

-

WE8BS2000

Siemens EBCDIC.DF.04 8ビット西ヨーロッパ語

SB

-

WE8BS2000E

Siemens EBCDIC.DF.04 8ビット西ヨーロッパ語

SB、EURO

-

WE8BS2000L5

Siemens EBCDIC.DF.L5 8ビット西ヨーロッパ語/トルコ語

SB

-

WE8EBCDIC1047E

Latin 1/オープン・システム1047

SB、EBCDIC、EURO

-

WE8EBCDIC1140

EBCDICコード・ページ1140 8ビット西ヨーロッパ語

SB、EURO

-

WE8EBCDIC1145

EBCDICコード・ページ1145 8ビット西ヨーロッパ語

SB、EURO

-

WE8DBCDIC1146

EBCDICコード・ページ1146 8ビット西ヨーロッパ語

SB、EURO

-

WE8EBCDIC1148

EBCDICコード・ページ1148 8ビット西ヨーロッパ語

SB、EURO

中東地域

-

-

-

-

AR8EBCDIC420S

EBCDICコード・ページ420サーバー8ビット・ラテン語/アラビア語

SB

-

IW8EBCDIC424S

EBCDICコード・ページ424サーバー8ビット・ラテン語/ヘブライ語

SB

-

TR8EBCDIC1026S

EBCDICコード・ページ1026サーバー8ビット・トルコ語

SB

その他のキャラクタ・セット

表A-6に、その他のASCIIベースOracleデータベース・キャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表A-6 その他のASCIIベース・データベース・キャラクタ・セット

名前

説明

コメント

アジア地域

-

-

-

-

BN8BSCII

バングラデシュ国内規格コード8ビットBSCII

SB、ASCII

-

IN8ISCII

複数スクリプト・インド標準8ビット・ラテン語/諸インド語

SB、ASCII

-

JA16VMS

JVMS 16ビット日本語

MB、ASCII

-

KO16KSC5601

KSC5601 16ビット韓国語

MB、ASCII

-

KO16KSCCS

KSCCS 16ビット韓国語

MB、ASCII

-

TH8MACTHAIS

Macサーバー8ビット・ラテン語/タイ語

SB、ASCII

-

VN8VN3

VN3 8ビット・ベトナム語

SB、ASCII

-

ZHS16CGB231280

CGB2312-80 16ビット簡体字中国語

MB、ASCII

-

ZHT16BIG5

BIG5 16ビット繁体字中国語

MB、ASCII

-

ZHT16CCDC

HP CCDC 16ビット繁体字中国語

MB、ASCII

-

ZHT16DBT

台湾課税16ビット繁体字中国語

MB、ASCII

-

ZHT16HKSCS31

MS Windowsコード・ページ950香港補足キャラクタ・セットHKSCS-2001付き(Unicodeとの間のキャラクタ・セット変換はUnicode 3.1に基づきます)

MB、ASCII、EURO

-

ZHT32SOPS

SOPS 32ビット繁体字中国語

MB、ASCII

-

ZHT32TRIS

TRIS 32ビット繁体字中国語

MB、ASCII

中東地域

-

-

-

-

AR8ADOS710

アラビア語MS-DOS 710サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8ADOS720

アラビア語MS-DOS 720サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8APTEC715

APTEC 715サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8ASMO8X

ASMO拡張708 8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8ISO8859P6

ISO 8859-6ラテン語/アラビア語

SB、ASCII

-

AR8MUSSAD768

Mussa'd Alarabi/2 768サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8NAFITHA711

Nafitha拡張711サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8NAFITHA721

Nafitha International 721サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8SAKHR706

SAKHR 706サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AR8SAKHR707

SAKHR 707サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

AZ8ISO8859P9E

ISO 8859-9ラテン語/アゼルバイジャン語

SB、ASCII

-

IN8ISCII

複数スクリプト・インド標準8ビット・ラテン語/諸インド語

SB、ASCII

-

IW8MACHEBREW

Macクライアント8ビット・ヘブライ語

SB

-

IW8PC1507

IBM-PCコード・ページ1507/862 8ビット・ラテン語/ヘブライ語

SB、ASCII

-

LA8ISO6937

ISO 6937 8ビット・テキスト通信用コード・キャラクタ・セット

SB、ASCII

-

TR8DEC

DEC 8ビット・トルコ語

SB、ASCII

-

TR8PC857

IBM-PCコード・ページ857 8ビット・トルコ語

SB、ASCII

ヨーロッパ地域

-

-

-

-

AR8ARABICMAC

Macクライアント8ビット・ラテン語/アラビア語

SB

-

AR8ARABICMACS

Macサーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

BG8MSWIN

MS Windows 8ビット・ブルガリア語/キリル文字

SB、ASCII

-

BG8PC437S

IBM-PCコード・ページ437 8ビット(ブルガリア語の変化形)

SB、ASCII

-

BLT8CP921

ラトビア語標準LVS8-92(1)Windows/Unix 8ビット・バルト語

SB、ASCII

-

BLT8PC775

IBM-PCコード・ページ775 8ビット・バルト語

SB、ASCII

-

CDN8PC863

IBM-PCコード・ページ863 8ビット・カナダ系フランス語

SB、ASCII

-

CEL8ISO8859P14

ISO 8859-14ケルト系言語

SB、ASCII

-

CL8ISOIR111

ISOIR111キリル文字

SB

-

CL8KOI8R

RELCOMインターネット標準8ビット・ラテン語/キリル文字

SB、ASCII

-

CL8KOI8U

KOI8ウクライナ語/キリル文字

SB

-

CL8MACCYRILLICS

Macサーバー8ビット・ラテン語/キリル文字

SB、ASCII

-

EE8MACCES

Macサーバー8ビット中央ヨーロッパ語

SB、ASCII

-

EE8MACCROATIANS

Macサーバー8ビット・クロアチア語

SB、ASCII

-

EE8PC852

IBM-PCコード・ページ852 8ビット東ヨーロッパ語

SB、ASCII

-

EL8DEC

DEC 8ビット・ラテン語/ギリシャ語

SB

-

EL8MACGREEKS

Macサーバー8ビット・ギリシャ語

SB、ASCII

-

EL8PC437S

IBM-PCコード・ページ437 8ビット(ギリシャ語の変化形)

SB、ASCII

-

EL8PC851

IBM-PCコード・ページ851 8ビット・ギリシャ語/ラテン語

SB、ASCII

-

EL8PC869

IBM-PCコード・ページ869 8ビット・ギリシャ語/ラテン語

SB、ASCII

-

ET8MSWIN923

MS Windowsコード・ページ923 8ビット・エストニア語

SB、ASCII

-

HU8ABMOD

ハンガリー語8ビット特殊AB変化形

SB、ASCII

-

HU8CWI2

ハンガリー語8ビットCWI-2

SB、ASCII

-

IS8PC861

IBM-PCコード・ページ861 8ビット・アイスランド語

SB、ASCII

-

LA8ISO6937

ISO 6937 8ビット・テキスト通信用コード・キャラクタ・セット

SB、ASCII

-

LA8PASSPORT

ドイツ政府プリンタ8ビット全ヨーロッパ・ラテン語

SB、ASCII

-

LT8MSWIN921

MS Windowsコード・ページ921 8ビット・リトアニア語

SB、ASCII

-

LT8PC772

IBM-PCコード・ページ772 8ビット・リトアニア語(ラテン語/キリル文字)

SB、ASCII

-

LT8PC774

IBM-PCコード・ページ774 8ビット・リトアニア語(ラテン語)

SB、ASCII

-

LV8PC8LR

ラトビア語バージョンIBM-PCコード・ページ866 8ビット・ラテン語/キリル文字

SB、ASCII

-

LV8PC1117

IBM-PCコード・ページ1117 8ビット・ラトビア語

SB、ASCII

-

LV8RST104090

IBM-PC代替コード・ページ8ビット・ラトビア語(ラテン語/キリル文字)

SB、ASCII

-

N8PC865

IBM-PCコード・ページ865 8ビット・ノルウェー語

SB、ASCII

-

RU8BESTA

BESTA8ビット・ラテン語/キリル文字

SB、ASCII

-

RU8PC855

IBM-PCコード・ページ855 8ビット・ラテン語/キリル文字

SB、ASCII

-

RU8PC866

IBM-PCコード・ページ866 8ビット・ラテン語/キリル文字

SB、ASCII

-

SE8ISO8859P3

ISO 8859-3南ヨーロッパ語

SB、ASCII

-

TR8MACTURKISH

Macクライアント8ビット・トルコ語

SB

-

TR8MACTURKISHS

Macサーバー8ビット・トルコ語

SB、ASCII

-

TR8PC857

IBM-PCコード・ページ857 8ビット・トルコ語

SB、ASCII

-

US7ASCII

ASCII 7ビット・米語

SB、ASCII

-

US8PC437

IBM-PCコード・ページ437 8ビット米語

SB、ASCII

-

WE8DEC

DEC 8ビット西ヨーロッパ語

SB、ASCII

-

WE8DG

DG 8ビット西ヨーロッパ語

SB、ASCII

-

WE8ISO8859P1

ISO 8859-1西ヨーロッパ語

SB、ASCII

-

WE8MACROMAN8S

Macサーバー8ビット拡張Roman8西ヨーロッパ語

SB、ASCII

-

WE8NCR4970

NCR 4970 8ビット西ヨーロッパ語

SB、ASCII

-

WE8NEXTSTEP

NeXTSTEP PostScript 8ビット西ヨーロッパ語

SB、ASCII

-

WE8PC850

IBM-PCコード・ページ850 8ビット西ヨーロッパ語

SB、ASCII

-

WE8PC858

IBM-PCコード・ページ858 8ビット西ヨーロッパ語

SB、ASCII、EURO

-

WE8PC860

IBM-PCコード・ページ860 8ビット西ヨーロッパ語

SB、ASCII

-

WE8ROMAN8

HP Roman8 8ビット西ヨーロッパ語

SB、ASCII

ユニバーサル

-

-

-

-

UTF8

Unicode 3.0 UTF-8ユニバーサル・キャラクタ・セット、CESU-8準拠

MB、ASCII、EURO

表A-7に、その他のEBCDICベースOracleデータベース・キャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表A-7 その他のEBCDICベース・データベース・キャラクタ・セット

名前

説明

コメント

アジア地域

-

-

-

-

TH8TISEBCDIC

タイ工業規格620-2533 - EBCDIC 8ビット

SB

-

ZHS16DBCS

IBM EBCDIC 16ビット簡体字中国語

MB、UDC

-

ZHT16DBCS

IBM EBCDIC 16ビット繁体字中国語

MB、UDC

中東地域

-

-

-

-

AR8EBCDICX

EBCDIC XBASICサーバー8ビット・ラテン語/アラビア語

SB

-

IW8EBCDIC424

EBCDICコード・ページ424 8ビット・ラテン語/ヘブライ語

SB

-

IW8EBCDIC1086

EBCDICコード・ページ1086 8ビット・ヘブライ語

SB

-

TR8EBCDIC1026

EBCDICコード・ページ1026 8ビット・トルコ語

SB

-

WE8EBCDIC37C

EBCDICコード・ページ37 8ビットOracle/c

SB

ヨーロッパ地域

-

-

-

-

BLT8EBCDIC1112

EBCDICコード・ページ1112サーバー8ビット・バルト多言語

SB

-

CL8EBCDIC1025

EBCDICコード・ページ1025 8ビット・キリル文字

SB

-

CL8EBCDIC1025C

EBCDICコード・ページ1025クライアント8ビット・キリル文字

SB

-

CL8EBCDIC1025S

EBCDICコード・ページ1025サーバー8ビット・キリル文字

SB

-

CL8EBCDIC1025X

EBCDICコード・ページ1025(修正版)8ビット・キリル文字

SB

-

CL8EBCDIC1158

EBCDICコード・ページ1158 8ビット・キリル文字

SB

-

D8BS2000

Siemens 9750-62 EBCDIC 8ビット・ドイツ語

SB

-

D8EBCDIC273

EBCDICコード・ページ273/1 8ビット・ドイツ語(オーストリア)

SB

-

DK7SIEMENS9780X

Siemens 97801/97808 7ビット・デンマーク語

SB

-

DK8BS2000

Siemens 9750-62 EBCDIC 8ビット・デンマーク語

SB

-

DK8EBCDIC277

EBCDICコード・ページ277/1 8ビット・デンマーク語

SB

-

E8BS2000

Siemens 9750-62 EBCDIC 8ビット・スペイン語

SB

-

EE8EBCDIC870

EBCDICコード・ページ870 8ビット東ヨーロッパ語

SB

-

EE8EBCDIC870C

EBCDICコード・ページ870クライアント8ビット東ヨーロッパ語

SB

-

EL8EBCDIC875

EBCDICコード・ページ875 8ビット・ギリシア語

SB

-

EL8GCOS7

Bull EBCDIC GCOS7 8ビット・ギリシア語

SB

-

F8BS2000

Siemens 9750-62 EBCDIC 8ビット・フランス語

SB

-

F8EBCDIC297

EBCDICコード・ページ297 8ビット・フランス語

SB

-

I8EBCDIC280

EBCDICコード・ページ280/1 8ビット・イタリア語

SB

-

S8BS2000

Siemens 9750-62 EBCDIC 8ビット・スウェーデン語

SB

-

S8EBCDIC278

EBCDICコード・ページ278/1 8ビット・スウェーデン語

SB

-

US8ICL

ICL EBCDIC 8ビット米語

SB

-

US8BS2000

Siemens 9750-62 EBCDIC 8ビット米語

SB

-

WE8EBCDIC924

Latin 9 EBCDIC 924

SB、EBCDIC

-

WE8EBCDIC37

EBCDICコード・ページ37 8ビット西ヨーロッパ語

SB

-

WE8EBCDIC284

EBCDICコード・ページ284 8ビット・スペイン語(南米)

SB

-

WE8EBCDIC285

EBCDICコード・ページ285 8ビット西ヨーロッパ語

SB

-

WE8EBCDIC1047

EBCDICコード・ページ1047 8ビット西ヨーロッパ語

SB

-

WE8EBCDIC1140C

EBCDICコード・ページ1140 8ビット西ヨーロッパ語

SB、EURO

-

WE8EBCDIC1148C

EBCDICコード・ページ1148クライアント8ビット西ヨーロッパ語

SB、EURO

-

WE8EBCDIC500C

EBCDICコード・ページ500 8ビットOracle/c

SB

-

WE8EBCDIC500

EBCDICコード・ページ500 8ビット西ヨーロッパ語

SB

-

WE8EBCDIC871

EBCDICコード・ページ871 8ビット・アイスランド語

SB

-

WE8ICL

ICL EBCDIC 8ビット西ヨーロッパ語

SB

-

WE8GCOS7

Bull EBCDIC GCOS7 8ビット西ヨーロッパ語

SB

ユニバーサル

-

-

-

-

UTFE

Unicode 3.0 UTF-8ユニバーサル・キャラクタ・セットのEBCDICフォーム(UTF-EBCDIC)

MB、EURO

ユーロ記号をサポートしているキャラクタ・セット

表A-8に、ユーロ記号をサポートしているキャラクタ・セットを示します。

表A-8 ユーロ記号をサポートしているキャラクタ・セット

キャラクタ・セット名

ユーロ記号の16進コード値

AL16UTF16

20AC

AL32UTF8

E282AC

AR8MSWIN1256

80

BLT8MSWIN1257

80

CL8EBCDIC1158

E1

CL8EBCDIC1158R

9F

CL8MSWIN1251

88

D8EBCDIC1141

9F

DK8EBCDIC1142

5A

EE8MSWIN1250

80

EL8EBCDIC423R

FD

EL8EBCDIC875R

DF

EL8ISO8859P7

A4

EL8MSWIN1253

80

F8EBCDIC1147

9F

I8EBCDIC1144

9F

IW8MSWIN1255

80

KO16KSC5601

A2E6

KO16KSCCS

D9E6

KO16MSWIN949

A2E6

SE8EBCDIC1143

5A

TH8TISASCII

80

TR8MSWIN1254

80

UTF8

E282AC

UTFE

CA4653

VN8MSWIN1258

80

WE8BS2000E

9F

WE8EBCDIC1047E

9F

WE8EBCDIC1140

9F

WE8EBCDIC1140C

9F

WE8EBCDIC1145

9F

WE8EBCDIC1146

9F

WE8EBCDIC1148

9F

WE8EBCDIC1148C

9F

WE8EBCDIC924

9F

WE8ISO8859P15

A4

WE8MACROMAN8

DB

WE8MACROMAN8S

DB

WE8MSWIN1252

80

WE8PC858

DF

ZHS32GB18030

A2E3

ZHT16HKSCS

A3E1

ZHT16HKSCS31

A3E1

ZHT16MSWIN950

A3E1

クライアント専用のキャラクタ・セット

表A-9に、クライアント専用のキャラクタ・セットとしてサポートされているOracleデータベース・キャラクタ・セットを示します。言語グループ内はアルファベット順に記載しています。

表A-9 クライアント専用のキャラクタ・セット

名前

説明

コメント

アジア地域

-

-

-

-

JA16EUCYEN

EUC 24ビット日本語(バックスラッシュは日本語の円記号(\)になります。)

MB

-

JA16MACSJIS

Macクライアント・シフトJIS 16ビット日本語

MB

-

JA16SJISYEN

シフトJIS 16ビット日本語(バックスラッシュは日本語の円記号(\)になります。)

MB、UDC

-

TH8MACTHAI

Macクライアント8ビット・ラテン語/タイ語

SB

-

ZHS32GB18030

GB18030-2000

MB、ASCII、EURO

-

ZHS16MACCGB231280

MacクライアントCGB2312-80 16ビット簡体字中国語

MB

ヨーロッパ地域

-

-

-

-

CH7DEC

DEC VT100 7ビット・スイス語(ドイツ語/フランス語)

SB

-

CL8MACCYRILLIC

Macクライアント8ビット・ラテン語/キリル文字

SB

-

D7SIEMENS9780X

Siemens 97801/97808 7ビット・ドイツ語

SB

-

D7DEC

DEC VT100 7ビット・ドイツ語

SB

-

EEC8EUROASCI

EEC Targon 35 ASCI西ヨーロッパ語/ギリシア語

SB

-

EEC8EUROPA3

EEC EUROPA3 8ビット西ヨーロッパ語/ギリシア語

SB

-

EE8MACCROATIAN

Macクライアント8ビット・クロアチア語

SB

-

EE8MACCE

Macクライアント8ビット中央ヨーロッパ語

SB

-

EL8PC737

IBM-PCコード・ページ737 8ビット・ギリシア語/ラテン語

SB

-

EL8MACGREEK

Macクライアント8ビット・ギリシア語

SB

-

E7DEC

DEC VT100 7ビット・スペイン語

SB

-

E7SIEMENS9780X

Siemens 97801/97808 7ビット・スペイン語

SB

-

F7DEC

DEC VT100 7ビット・フランス語

SB

-

F7SIEMENS9780X

Siemens 97801/97808 7ビット・フランス語

SB

-

I7DEC

DEC VT100 7ビット・イタリア語

SB

-

I7SIEMENS9780X

Siemens 97801/97808 7ビット・イタリア語

SB

-

IS8MACICELANDICS

Macサーバー8ビット・アイスランド語

SB

-

IS8MACICELANDIC

Macクライアント8ビット・アイスランド語

SB

-

NL7DEC

DEC VT100 7ビット・オランダ語

SB

-

NDK7DEC

DEC VT100 7ビット・ノルウェー語/デンマーク語

SB

-

N7SIEMENS9780X

Siemens 97801/97808 7ビット・ノルウェー語

SB

-

SF7DEC

DEC VT100 7ビット・フィンランド語

SB

-

S7SIEMENS9780X

Siemens 97801/97808 7ビット・スウェーデン語

SB

-

S7DEC

DEC VT100 7ビット・スウェーデン語

SB

-

SF7ASCII

ASCII 7ビット・フィンランド語

SB

-

TR7DEC

DEC VT100 7ビット・トルコ語

SB

-

WE8ISOICLUK

ICL特別バージョンISO8859-1

SB

-

WE8MACROMAN8

Macクライアント8ビット拡張Roman8西ヨーロッパ語

SB

-

WE8HP

HP LaserJet 8ビット西ヨーロッパ語

SB

-

YUG7ASCII

ASCII 7ビット・ユーゴスラビア語

SB

中東地域

-

-

-

-

AR8ARABICMAC

Macクライアント8ビット・ラテン語/アラビア語

SB

-

AR8MUSSAD768

Mussa'd Alarabi/2 768サーバー8ビット・ラテン語/アラビア語

SB、ASCII

-

IW7IS960

イスラエル標準960 7ビット・ラテン語/ヘブライ語

SB

-

IW8MACHEBREW

Macクライアント8ビット・ヘブライ語

SB

-

TR8MACTURKISH

Macクライアント8ビット・トルコ語

SB

ユニバーサル・キャラクタ・セット

表A-10に、世界言語サポートを提供しているOracleデータベース・キャラクタ・セットを示します。これらのキャラクタ・セットは、アジア、ヨーロッパおよび中東地域の言語にかぎらず、それらを含めた世界中のすべての言語をサポートします。

表A-10 ユニバーサル・キャラクタ・セット

名前

説明

コメント

AL16UTF16

Unicode 5.0 UTF-16ユニバーサル・キャラクタ・セット

MB、EURO、FIXED

AL32UTF8

Unicode 5.0 UTF-8ユニバーサル・キャラクタ・セット

MB、ASCII、EURO

UTF8

Unicode 3.0 UTF-8ユニバーサル・キャラクタ・セット、CESU-8準拠

MB、ASCII、EURO

UTFE

Unicode 3.0 UTF-8ユニバーサル・キャラクタ・セットのEBCDICフォーム(UTF-EBCDIC)

MB、EURO

注意:
CESU-8では、補助文字の表現を除き、UTF-8と同じUnicodeのコード体系が定義されています。CESU-8では、補助文字は、UTF-16の各サロゲート・コード単位を、入力されたサロゲート・ペアをスカラー値に変換せずに、UTF-8の変換と同等の8ビット形式に変換した結果得られる6バイトのシーケンスとして表現されます。Unicodeテクニカル・レポート#26を参照してください。

関連項目:
第6章「Unicodeを使用した多言語データベースのサポート」

キャラクタ・セット変換のサポート

次のキャラクタ・セット・エンコーディングは、変換専用としてサポートされています。データベース・キャラクタ・セットまたは各国語キャラクタ・セットとしては使用できません。

AL16UTF16LE

ISO2022-CN

ISO2022-JP

ISO2022-KR

HZ-GB-2312

これらのキャラクタ・セットは、CONVERT 関数でsource_char_setまたはdest_char_setに使用できます。

CONVERT関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。「CONVERT関数」も参照してください。

サブセットとスーパーセット

表A-11に、一般的なサブセットとスーパーセットの関連を示します。

表A-11 サブセットとスーパーセットのペア

サブセット

スーパーセット

AR8ARABICMACT

AR8ARABICMAC

AR8ISO8859P6

AR8ASMO8X

BLT8CP921

BLT8ISO8859P13

BLT8CP921

LT8MSWIN921

D7DEC

D7SIEMENS9780X

D7SIEMENS9780X

D7DEC

DK7SIEMENS9780X

N7SIEMENS9780X

I7DEC

I7SIEMENS9780X

I7SIEMENS9780X

IW8EBCDIC424

IW8EBCDIC424

IW8EBCDIC1086

KO16KSC5601

KO16MSWIN949

LT8MSWIN921

BLT8ISO8859P13

LT8MSWIN921

BLT8CP921

N7SIEMENS9780X

DK7SIEMENS9780X

US7ASCII

表A-12「US7ASCIIのスーパーセット」を参照してください。

UTF8

AL32UTF8

WE8DEC

TR8DEC

WE8DEC

WE8NCR4970

WE8ISO8859P1

WE8MSWIN1252

WE8ISO8859P9

TR8MSWIN1254

WE8NCR4970

TR8DEC

WE8NCR4970

WE8DEC

WE8PC850

WE8PC858

US7ASCIIは特殊で、非常に多くのキャラクタ・セットがUS7ASCIIのスーパーセットになっています。表A-12に、US7ASCIIのスーパーセットをリストします。

表A-12 US7ASCIIのスーパーセット

スーパーセットaからc

スーパーセットeからn

スーパーセットrからz

AL32UTF8

EE8MACCROATIANS

RU8BESTA

AR8ADOS710

EE8MSWIN1250

RU8PC855

AR8ADOS720

EE8PC852

RU8PC866

AR8APTEC715

EL8DEC

SE8ISO8859P3

AR8ARABICMACS

EL8ISO8859P7

TH8MACTHAIS

AR8ASMO8X

EL8MACGREEKS

TH8TISASCII

AR8ISO8859P6

EL8MSWIN1253

TR8DEC

AR8MSWIN1256

EL8PC437S

TR8MACTURKISHS

AR8MUSSAD768

EL8PC851

TR8MSWIN1254

AR8NAFITHA711

EL8PC869

TR8PC857

AR8NAFITHA721

ET8MSWIN923

US8PC437

AR8SAKHR706

HU8ABMOD

UTF8

AR8SAKHR707

HU8CWI2

VN8MSWIN1258

AZ8ISO8859P9E

IN8ISCII

VN8VN3

BG8MSWIN

IS8PC861

WE8DEC

BG8PC437S

IW8ISO8859P8

WE8DG

BLT8CP921

IW8MACHEBREWS

WE8ISO8859P1

BLT8ISO8859P13

IW8MSWIN1255

WE8ISO8859P15

BLT8MSWIN1257

IW8PC1507

WE8ISO8859P9

BLT8PC775

JA16EUC

WE8MACROMAN8S

BN8BSCII

JA16EUCTILDE

WE8MSWIN1252

CDN8PC863

JA16SJIS

WE8NCR4970

CEL8ISO8859P14

JA16SJISTILDE

WE8NEXTSTEP

CL8ISO8859P5

JA16VMS

WE8PC850

CL8KOI8R

KO16KSC5601

WE8PC858

CL8KOI8U

KO16KSCCS

WE8PC860

CL8ISOIR111

KO16MSWIN949

WE8ROMAN8

CL8MACCYRILLICS

LA8ISO6937

ZHS16CGB231280

CL8MSWIN1251

LA8PASSPORT

ZHS16GBK

EE8ISO8859P2

LT8MSWIN921

ZHT16BIG5

EE8MACCES

LT8PC772

ZHT16CCDC

-

LT8PC774

ZHT16DBT

-

LV8PC1117

ZHT16HKSCS

-

LV8PC8LR

ZHT16MSWIN950

-

LV8RST104090

ZHT32EUC

-

N8PC865

ZHT32SOPS

-

NE8ISO8859P10

ZHT32TRIS

-

NEE8ISO8859P4

ZHS32GB18030

言語およびキャラクタ・セット検出のサポート

表A-13に、Character Set Scannerユーティリティ(CSSCANおよびLCSSCAN)とGlobalization Development Kit(GDK)による言語とキャラクタ・セットの検出でサポートされている言語とキャラクタ・セットを示します。

各言語には、検出可能な複数のキャラクタ・セットがあります。

言語のバイナリ値が、サブセット/スーパーセット関係を持つ複数のエンコーディングと一致する場合は、サブセットのキャラクタ・セットが戻されます。たとえば、言語がドイツ語ですべての文字が7ビットの場合は、WE8MSWIN1252、WE8ISO8859P15またはWE8ISO8859P1のかわりにUS7ASCIIが戻されます。

キャラクタ・セットがUTF-8であると判別されると、テキスト内で4バイト文字(補助文字)が検出されないかぎり、デフォルトでOracle Databaseのキャラクタ・セットUTF8が戻されます。4バイト文字が検出されると、キャラクタ・セットはAL32UTF8としてレポートされます。

表A-13 CSSCAN、LCSSCANおよびGDKでサポートされている言語とキャラクタ・セット

言語

キャラクタ・セット

アラビア語

AL16UTF16、AL32UTF8、AR8ISO8859P6、AR8MSWIN1256、UTF8

ブルガリア語

AL16UTF16、AL32UTF8、CL8ISO8859P5、CL8MSWIN1251、UTF8

カタロニア語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

クロアチア語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

チェコ語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

デンマーク語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

オランダ語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

英語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

エストニア語

AL16UTF16、AL32UTF8、NEE8IOS8859P4、UTF8

フィンランド語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

フランス語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ドイツ語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ギリシア語

AL16UTF16、AL32UTF8、EL8ISO8859P7、EL8MSWIN1253、UTF8

ヘブライ語

AL16UTF16、AL32UTF8、IW8ISO8859P8、IW8MSWIN1255、UTF8

ハンガリー語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

イタリア語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

日本語

AL16UTF16、AL32UTF8、ISO2022-JP、JA16EUC、JA16SJIS、UTF8

韓国語

AL16UTF16、AL32UTF8、ISO2022-KR、KO16KSC5601、KO16MSWIN949、UTF8

マレー語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ノルウェー語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ポーランド語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

ポルトガル語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ルーマニア語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

ロシア語

AL16UTF16、AL32UTF8、CL8ISO8859P5、CL8KOI8R、CL8MSWIN1251、UTF8

簡体字中国語

AL16UTF16、AL32UTF8、HZ-GB-2312、UTF8、ZHS16GBK、ZHS16CGB231280

スロバキア語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

スペイン語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

スウェーデン語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

タイ語

AL16UTF16、AL32UTF8、TH8TISASCII、UTF8

繁体字中国語

AL16UTF16、AL32UTF8、UTF8、ZHT16MSWIN950

トルコ語

AL16UTF16、AL32UTF8、TR8MSWIN1254、UTF8、WE8ISO8859P9

言語ソート

Oracleデータベースでは、単一言語ソートと多言語ソートの2種類の言語ソートを提供しています。また、単一言語ソートを拡張することにより特殊な事例に対応できます。一般的に、(接頭辞Xで表す)この特殊な事例とは、文字がそのASCII値とは異なる順にソートされる場合を意味します。たとえば、XSPANISHでは、chとllが1つの文字として取り扱われます。

すべての言語ソートは、言語ソート名に_CIまたは_AIを追加し、それぞれ大/小文字またはアクセントを区別しないソートとして実行することもできます。

表A-14に、Oracleデータベースがサポートしている単一言語ソートを示します。

関連項目:
各言語のデフォルト・ソートのリストは、表A-1「Oracle Databaseがサポートしている言語」を参照してください。

表A-14 単一言語ソート

基本名

拡張名

特殊な事例

ARABIC

-

-

ARABIC_MATCH

-

-

ARABIC_ABJ_SORT

-

-

ARABIC_ABJ_MATCH

-

-

ASCII7

-

-

AZERBAIJANI

XAZERBAIJANI

i、I、ドットなし小文字のi、ドット付き大文字のI

BENGALI

-

-

BIG5

-

-

BINARY

-

-

BULGARIAN

-

-

CATALAN

XCATALAN

æ、AE、 ß

CROATIAN

XCROATIAN

D、L、N、d、l、n、ß

CZECH

XCZECH

ch、CH、Ch、ß

CZECH_PUNCTUATION

XCZECH_PUNCTUATION

ch、CH、Ch、ß

DANISH

XDANISH

A、ß、Å、å

DUTCH

XDUTCH

ij、IJ

EBCDIC

-

-

EEC_EURO

-

-

EEC_EUROPA3

-

-

ESTONIAN

-

-

FINNISH

-

-

FRENCH

XFRENCH

-

GERMAN

XGERMAN

ß

GERMAN_DIN

XGERMAN_DIN

ß, ä, ö, ü, Ä, Ö, Ü

GBK

-

-

GREEK

-

-

HEBREW

-

-

HKSCS

-

-

HUNGARIAN

XHUNGARIAN

cs、gy、ny、sz、ty、zs、ß、CS、Cs、GY、Gy、NY、Ny、SZ、Sz、TY、Ty、ZS、Zs

ICELANDIC

-

-

INDONESIAN

-

-

ITALIAN

-

-

LATIN

-

-

LATVIAN

-

-

LITHUANIAN

-

-

MALAY

-

-

NORWEGIAN

-

-

POLISH

-

-

PUNCTUATION

XPUNCTUATION

-

ROMANIAN

-

-

RUSSIAN

-

-

SLOVAK

XSLOVAK

dz、DZ、Dz、ß(カロン)

SLOVENIAN

XSLOVENIAN

ß

SPANISH

XSPANISH

ch、ll、CH、Ch、LL、Ll

SWEDISH

-

-

SWISS

XSWISS

ß

TURKISH

XTURKISH

æ、AE、 ß

UKRAINIAN

-

-

UNICODE_BINARY

-

-

VIETNAMESE

-

-

WEST_EUROPEAN

XWEST_EUROPEAN

ß

表A-15に、Oracleデータベースで使用可能な多言語ソートを示します。これらすべては、GENERIC_M(ラテン語に基づく文字ソートのISO規格)を基礎として含んでいます。多言語ソートは、ラテン語に基づく文字とともに、特定の主要な言語に使用されます。たとえば、KOREAN_Mは韓国語とラテン語に基づく文字はソートしますが、中国語、タイ語または日本語の文字は照合しません。

表A-15 多言語ソート

ソート名

説明

CANADIAN_M

フランス語(カナダ)のソートは、逆2次ソートで特殊な拡張文字をサポートしています。

DANISH_M

デンマーク語のソートは、小文字の前に大文字をソートします。

FRENCH_M

フランス語のソートは、逆2次ソートをサポートしています。

GENERIC_M

ISO14651およびUnicodeの標準的な同値化規則(互換性のある同値化規則を除く)に基づいた一般的なソート順序です。

JAPANESE_M

日本語のソートは、SJISキャラクタ・セットのソート順序およびSJISには含まれないEUC文字をサポートしています。

KOREAN_M

韓国語のソート: ハングル文字はUnicodeのバイナリ順序に基づいてソートします。ハンジャ文字は発音順に基づいてソートします。すべてのハングル文字がハンジャ文字の前にソートされます。

SPANISH_M

従来のスペイン語のソートは、特殊な短縮文字をサポートしています。

THAI_M

タイ語のソートは、一部の母音と子音について、文字の交換をサポートしています。

SCHINESE_RADICAL_M

この簡体字中国語のソートは、最初に部首、次に画数に基づいて行います。

SCHINESE_STROKE_M

この簡体字中国語のソートは、最初に画数、次に部首に基づいて行います。

SCHINESE_PINYIN_M

この簡体字中国語のソートは、ピンイン(中国語の発音記号)順に行います。

TCHINESE_RADICAL_M

この繁体字中国語のソートは、最初に部首、次に画数に基づいて行います。

TCHINESE_STROKE_M

この繁体字中国語のソートは、最初に画数、次に部首に基づいて行います。補助文字がサポートされます。

関連項目:
第5章「言語ソートと文字列検索」

暦法

デフォルトでは、ほとんどの地域定義でグレゴリオ暦が使用されています。表A-14に、Oracleデータベースがサポートしているその他の暦法を示します。

表A-16 サポートしている暦法

名前

デフォルトの日付書式

デフォルトの日付書式に使用するキャラクタ・セット

Japanese Imperial(日本の元号暦)

EEYYMMDD

JA16EUC

ROC Official(台湾暦)

EEyymmdd

ZHT32EUC

Thai Buddha(タイ仏教暦)

dd month EE yyyy

TH8TISASCII

Persian(ペルシャ暦)

DD Month YYYY

AR8ASMO8X

Arabic Hijrah(イスラム歴)

DD Month YYYY

AR8ISO8859P6

English Hijrah(英語版イスラム歴)

DD Month YYYY

AR8ISO8859P6

図A-1に、Japanese Imperial(日本の元号暦)で1998年3月27日がどのように表示されるかを示します。

図A-1 Japanese Imperial(日本の元号暦)の例

タイム・ゾーン・リージョン名

表A-17に、Oracle Databaseで提供されているバージョン11のタイム・ゾーン・ファイル内のタイム・ゾーン・リージョン名を示します。タイム・ゾーン・ファイルの詳細は、第4章「日時データ型とタイム・ゾーン・サポート」を参照してください。

次の文を発行すると、タイム・ゾーン・リージョン名が表示されます。

SELECT DISTINCT(TZNAME) FROM V$TIMEZONE_NAMES;

表A-17 タイム・ゾーン・リージョン名

タイム・ゾーン名

小さいタイム・ゾーン・ファイル内での有無

タイム・ゾーン名

小さいタイム・ゾーン・ファイル内での有無

Afric/Abidjan

不可

Asia/Qatar

不可

Africa/Accra

不可

Asia/Qyzylorda

不可

Africa/Addis_Ababa

不可

Asia/Rangoon

不可

Africa/Algiers

不可

Asia/Riyadh

可能

Africa/Asmara

不可

Asia/Saigon

不可

Africa/Asmera

不可

Asia/Sakhalin

不可

Africa/Bamako

不可

Asia/Samarkand

不可

Africa/Bangui

不可

Asia/Seoul

可能

Africa/Banjul

不可

Asia/Shanghai

可能

Africa/Bissau

不可

Asia/Singapore

可能

Africa/Blantyre

不可

Asia/Taipei

可能

Africa/Brazzaville

不可

Asia/Tashkent

不可

Afria/Bujumbura

不可

Asia/Tbilisi

不可

Africa/Cairo

可能

Asia/Tehran

可能

Africa/Casablanca

不可

Asia/Tel_Aviv

可能

Africa/Ceuta

不可

Asia/Thimbu

不可

Africa/Conakry

不可

Asia/Thimphu

不可

Africa/Dakar

不可

Asia/Tokyo

可能

Africa/Dar_es_Salaam

不可

Asia/Ujung_Pandang

不可

Africa/Djibouti

不可

Asia/Ulaanbaator

不可

Africa/Doula

不可

Asia/Ulan_Bator

不可

Africa/El_Aaiun

不可

Asia/Urumqi

不可

Africa/Freetown

不可

Asia/Vientiane

不可

Africa/Gaborone

不可

Asia/Vladivostok

不可

Africa/Harare

不可

Asia/Yakutsk

不可

Africa/Johannesburg

不可

Asia/Yetaterinburg

不可

Africa/Kampala

不可

Asia/Yerevan

不可

Africa/Khartoum

不可

Atlantic/Azores

不可

Africa/Kigali

不可

Atlantic/Bermuda

不可

Africa/Kinshasa

不可

Atlantic/Canary

不可

Africa/Lagos

不可

Atlantic/Cape_Verde

不可

Africa/Libreville

不可

Atlantic/Faeroe

不可

Africa/Lome

不可

Atlantic/Faroe

不可

Africa/Luanda

不可

Atlantic/Jan_Mayen

不可

Africa/Lubumbashi

不可

Atlantic/Madeira

不可

Africa/Lusaka

不可

Atlantic/Reykjavik

可能

Africa/Malabo

不可

Atlantic/South_Georgia

不可

Africa/Maputo

不可

Atlantic/St_Helena

不可

Africa/Maseru

不可

Atlantic/Stanley

不可

Africa/Mbabane

不可

Australia/ACT

可能

Africa/Mogadishu

不可

Australia/Adelaide

可能

Africa/Monrovia

不可

Australia/Brisbane

可能

Africa/Nairobi

不可

Australia/Broken_Hill

可能

Africa/Ndjamena

不可

Australia/Canberra

可能

Africa/Niamey

不可

Australia/Currie

不可

Africa/Nouakchott

不可

Australia/Darwin

可能

Africa/Ouagadougou

不可

Australia/Eucla

不可

Africa/Porto-Novo

不可

Australia/Hobart

可能

Africa/Sao_Tome

不可

Australia/LHI

可能

Africa/Timbuktu

不可

Australia/Lindeman

可能

Africa/Tripoli

可能

Australia/Lord_Howe

可能

Africa/Tunis

不可

Australia/Melbourne

可能

Africa/Windhoek

不可

Australia/NSW

可能

America/Adak

可能

Australia/North

可能

America/Anchorage

可能

Australia/Perth

可能

America/Anguilla

不可

Australia/Queensland

可能

Ameica/Antigua

不可

Australia/South

可能

America/Araguaina

不可

Australia/Sydney

可能

America/Argentina/Buenos_Aires

不可

Australia/Tasmania

可能

America/Argentina/Catamarca

不可

Australia/Victoria

可能

America/Argentina/ComodRivadavia

不可

Australia/West

可能

America/Argentina/Cordoba

不可

Australia/Yancowinna

可能

America/Argentina/Jujuy

不可

Brazil/Acre

可能

America/Argentina/La_Rioja

可能

Brazil/DeNoronha

可能

America/Argentina/Mendoza

不可

Brazil/East

可能

America/Argentina/Rio_Gallegos

可能

Brazil/West

可能

America/Argentina/Salta

不可

CET

可能

America/Argentina/San_Juan

可能

CST

可能

America/Argentina/San_Luis

不可

CST6CDT

可能

America/Argentina/Tucuman

可能

Canada/Atlantic

可能

America/Argentina/Ushuaia

可能

Canada/Central

可能

America/Aruba

不可

Canada/East-Saskatchewan

可能

America/Asuncion

不可

Canada/Eastern

可能

America/Atikokan

不可

Canada/Mountain

可能

America/Atka

可能

Canada/Newfoundland

可能

America/Bahia

不可

Canada/Pacific

可能

America/Barbados

不可

Canada/Saskatchewan

可能

America/Belem

不可

Canada/Yukon

可能

America/Belize

不可

Chile/Continental

可能

America/Blanc-Sablon

不可

Chile/EasterIsland

可能

America/Boa_Vista

不可

Cuba

可能

America/Bogota

不可

EET

可能

America/Boise

不可

EST

可能

America/Buenos_Aires

不可

EST5EDT

可能

America/Cambridge_Bay

不可

Egypt

可能

America/Campo_Grande

不可

Eire

可能

America/Cancun

不可

Etc/GMT

可能

America/Caracas

不可

Etc/GMT+0

可能

America/Catamarca

不可

Etc/GMT+1

可能

America/Cayenne

不可

Etc/GMT+10

可能

America/Cayman

不可

Etc/GMT+11

可能

America/Chicago

可能

Etc/GMT+12

可能

America/Chihuahua

不可

Etc/GMT+2

可能

America/Coral_Harbour

不可

Etc/GMT+3

可能

America/Cordoba

不可

Etc/GMT+4

可能

America/Costa_Rica

不可

Etc/GMT+5

可能

America/Cuiaba

不可

Etc/GMT+6

可能

America/Curacao

不可

Etc/GMT+7

可能

America/Danmarkshavn

不可

Etc/GMT+8

可能

America/Dawson

不可

Etc/GMT+9

可能

America/Dawson_Creek

不可

Etc/GMT-0

可能

America/Denver

可能

Etc/GMT-1

可能

America/Detroit

可能

Etc/GMT-10

可能

America/Dominica

不可

Etc/GMT-11

可能

America/Edmonton

可能

Etc/GMT-12

可能

America/Eirunepe

可能

Etc/GMT-13

可能

America/El_Salvador

不可

Etc/GMT-14

可能

America/Ensenada

可能

Etc/GMT-2

可能

America/Fort_Wayne

可能

Etc/GMT-3

可能

America/Fortaleza

不可

Etc/GMT-4

可能

America/Glace_Bay

不可

Etc/GMT-5

可能

America/Godthab

不可

Etc/GMT-6

あり

America/Goose_Bay

不可

Etc/GMT-7

可能

America/Grand_Turk

不可

Etc/GMT-8

可能

America/Grenada

不可

Etc/GMT-9

可能

America/Guadeloupe

不可

Etc/GMT0

可能

America/Guatemala

不可

Etc/Greenwich

可能

America/Guayaquil

不可

Europe/Amsterdam

不可

America/Guyana

不可

-

-

America/Halifax

可能

Europe/Andorra

不可

America/Havana

可能

Europe/Athens

不可

America/Hermosillo

不可

Europe/Belfast

可能

America/Indiana/Indianapolis

可能

Europe/Belgrade

不可

America/Indiana/Knox

不可

Europe/Berlin

不可

America/Indiana/Marengo

不可

Europe/Bratislava

不可

America/Indiana/Petersburg

不可

Europe/Brussels

不可

America/Indiana/Tell_City

不可

Europe/Bucharest

不可

America/Indiana/Vevay

不可

Europe/Budapest

不可

America/Indiana/Vincennes

不可

Europe/Chisinau

不可

America/Indiana/Winamac

不可

Europe/Copenhagen

不可

America/Indianapolis

可能

Europe/Dublin

可能

America/Inuvik

不可

Europe/Gibraltar

不可

America/Iqaluit

不可

Europe/Guernsey

可能

America/Jamaica

可能

Europe/Helsinki

不可

America/Jujuy

不可

Europe/Isle_of_Man

可能

America/Juneau

不可

Europe/Istanbul

可能

America/Kentucky/Louisville

不可

Europe/Jersey

可能

America/Kentucky/Monticello

不可

Europe/Kaliningrad

不可

America/Knox_IN

不可

Europe/Kiev

不可

America/La_Paz

不可

Europe/Lisbon

可能

America/Lima

不可

Europe/Ljubljana

不可

America/Los_Angeles

可能

Europe/London

可能

America/Louisville

不可

Europe/Luxembourg

不可

America/Maceio

不可

Europe/Madrid

不可

America/Managua

不可

Europe/Malta

不可

America/Manaus

可能

Europe/Mariehamn

不可

America/Marigot

不可

Europe/Minsk

不可

America/Martinique

不可

Europe/Monaco

不可

America/Mazatlan

可能

Europe/Moscow

可能

America/Mendoza

不可

Europe/Nicosia

不可

America/Menominee

不可

Europe/Oslo

不可

America/Merida

不可

Europe/Paris

不可

America/Mexico_City

可能

Europe/Podgorica

不可

America/Miquelon

不可

Europe/Prague

不可

America/Moncton

不可

Europe/Riga

不可

America/Monterrey

可能

Europe/Rome

不可

America/Montevideo

不可

Europe/Samara

不可

America/Montreal

可能

Europe/San_Marino

不可

America/Montserrat

不可

Europe/Sarajevo

不可

America/Nassau

不可

Europe/Simferopol

不可

America/New_York

可能

Europe/Skopje

不可

America/Nipigon

不可

Europe/Sofia

不可

America/Nome

不可

Europe/Stockholm

不可

America/Noronha

可能

Europe/Tallinn

不可

America/North_Dakota/Center

不可

Europe/Tirane

不可

America/North_Dakota/New_Salem

不可

Europe/Tiraspol

不可

America/Panama

不可

Europe/Uzhgorod

不可

America/Pangnirtung

不可

Europe/Vaduz

不可

America/Paramaribo

不可

Europe/Vatican

不可

America/Phoenix

可能

Europe/Vienna

不可

America/Port-au-Prince

不可

Europe/Vilnius

不可

America/Port_of_Spain

不可

Europe/Volgograd

不可

America/Porto_Acre

不可

Europe/Warsaw

可能

America/Porto_Velho

不可

Europe/Zagreb

不可

America/Port_of_Spain

不可

Europe/Zaporozhye

不可

America/Porto_Acre

不可

Europe/Zurich

不可

America/Porto_Velho

不可

GB

可能

America/Puerto_Rico

不可

GB-Eire

可能

America/Rainy_River

不可

GMT

可能

America/Rankin_Inlet

不可

GMT+0

可能

America/Recife

不可

GMT-0

可能

America/Regina

可能

GMT0

可能

America/Resolute

不可

Greenwich

可能

America/Rio_Branco

可能

HST

可能

America/Rosario

不可

Hongkong

可能

America/Santiago

可能

Iceland

可能

America/Santo_Domingo

不可

Indian/Antananarivo

不可

America/Sao_Paulo

可能

Indian/Chagos

不可

America/Scoresbysund

不可

Indian/Christmas

不可

America/Shiprock

可能

Indian/Cocos

不可

America/St_Barthelemy

不可

Indian/Comoro

不可

America/St_Johns

可能

Indian/Kerguelen

不可

America/St_Kitts

不可

Indian/Mahe

不可

America/St_Lucia

不可

Indian/Maldives

不可

America/St_Thomas

不可

Indian/Mauritius

不可

America/St_Vincent

不可

Indian/Mayotte

不可

America/Swift_Current

不可

Indian/Reunion

不可

America/Tegucigalpa

不可

Iran

可能

America/Thule

不可

Israel

可能

America/Thunder_Bay

不可

Jamaica

可能

America/Tijuana

可能

日本

可能

America/Tortola

不可

Kwajalein

可能

America/Vancouver

可能

Libya

可能

America/Virgin

不可

MET

可能

America/Whitehorse

可能

MST

可能

America/Winnipeg

可能

MST7MDT

可能

America/Yakutat

不可

Mexico/BajaNorte

可能

America/Yellowknife

不可

Mexico/BajaSur

可能

Antarctica/Casey

不可

Mexico/General

可能

Antarctica/Davis

不可

NZ

可能

Antarctica/DumontDUrville

不可

NZ-CHAT

可能

Antarctica/Mawson

不可

Navajo

可能

Antarctica/McMurdo

不可

PRC

可能

Antarctica/Palmer

不可

PST

可能

Antarctica/South_Pole

不可

PST8PDT

可能

Antarctica/Syowa

不可

Pacific/Apia

不可

Arctic/Longyearbyen

不可

Pacific/Auckland

可能

Asia/Aden

不可

Pacific/Chatham

可能

Asia/Almaty

不可

Pacific/Easter

可能

Asia/Amman

不可

Pacific/Efate

不可

Asia/Anadyr

不可

Pacific/Enderbury

不可

Asia/Aqtau

不可

Pacific/Fakaofo

不可

Asia/Aqtobe

不可

Pacific/Fiji

不可

Asia/Ashgabat

不可

Pacific/Funafuji

不可

Asia/Ashkhabad

不可

Pacific/Galapagos

不可

Asia/Baghdad

不可

Pacific/Gambier

不可

Asia/Bahrain

不可

Pacific/Guadalcanal

不可

Asia/Baku

不可

Pacific/Guam

不可

Asia/Bangkok

不可

Pacific/Honolulu

可能

Asia/Beirut

不可

Pacific/Johnston

不可

Asia/Bishkek

不可

Pacific/Kiritimati

不可

Asia/Brunei

不可

Pacific/Kosrae

不可

Asia/Calcutta

可能

Pacific/Kwajalein

可能

Asia/Choibalsan

不可

Pacific/Majuro

不可

Asia/Chongqing

不可

Pacific/Marquesas

不可

Asia/Chungking

不可

Pacific/Midway

不可

Asia/Colombo

不可

Pacific/Nauru

不可

Asia/Dacca

不可

Pacific/Niue

不可

Asia/Damascus

不可

Pacific/Norfolk

不可

Asia/Dhaka

不可

Pacific/Noumea

不可

Asia/Dili

不可

Pacific/Pago_Pago

可能

Asia/Dubai

不可

Pacific/Palau

不可

Asia/Dushanbe

不可

Pacific/Pitcairn

不可

Asia/Gaza

不可

Pacific/Ponape

不可

Asia/Harbin

不可

Pacific/Rarotonga

不可

Asia/Ho_Chi_Minh

不可

Pacific/Rarotonga

不可

Asia/Hong_Kong

可能

Pacific/Saipan

不可

Asia/Hovd

不可

Pacific/Samoa

可能

Asia/Irkutsk

不可

Pacific/Tahiti

不可

Asia/Istanbul

可能

Pacific/Tarawa

不可

Asia/Jakarta

不可

Pacific/Tongatapu

不可

Asia/Jayapura

不可

Pacific/Truk

不可

Asia/Jerusalem

可能

Pacific/Wake

不可

Asia/Kabul

不可

Pacific/Wallis

不可

Asia/Kamchatka

不可

Pacific/Yap

不可

Asia/Karachi

不可

Poland

可能

Asia/Kashgar

不可

Portugal

可能

Asia/Kathmandu

不可

ROC

可能

Asia/Katmandu

不可

ROK

可能

Asia/Kolkata

不可

Singapore

可能

Asia/Krasnoyarsk

不可

Turkey

可能

Asia/Kuala_Lumpur

不可

US/Alaska

可能

Asia/Kuching

不可

US/Aleutian

可能

Asia/Kuwait

不可

US/Arizona

可能

Asia/Macao

不可

US/Central

可能

Asia/Macau

不可

US/East-Indiana

可能

Asia/Magadan

不可

US/Eastern

可能

Asia/Makassar

不可

US/Hawaii

可能

Asia/Manila

不可

US/Indiana-Starke

不可

Asia/Muscat

不可

US/Michigan

可能

Asia/Nicosia

不可

US/Mountain

可能

Asia/Novosibirsk

不可

US/Pacific

可能

Asia/Omsk

不可

US/Pacific-New

可能

Asia/Oral

不可

US/Samoa

可能

Asia/Phnom_Penh

不可

UTC

不可

Asia/Pontianak

不可

W-SU

可能

Asia/Pyongyang

不可

WET

可能

関連項目:
「タイム・ゾーン・ファイルの選択」

廃止されたロケール・データ

この項では、廃止された言語ソート、キャラクタ・セット、言語および地域について説明します。廃止された言語ソート、言語および地域の定義は引き続き使用できます。ただし、これらは下位互換性を目的としてサポートされており、将来のリリースではサポートされなくなる可能性があります。現行データベース・リリースの廃止されたキャラクタ・セット、言語、地域および言語ソートのリストは、V$NLS_VALID_VALUESビューを問い合せて取得できます。

廃止になった言語ソート

表A-18に、Oracle Database 10gでサポートされなくなった言語ソートを示します。

表A-18 廃止された言語ソート

廃止になったソート名

置換ソート

THAI_TELEPHONE

THAI_M

THAI_DICTIONARY

THAI_M

CANADIAN FRENCH

CANADIAN_M

JAPANESE

JAPANESE_M

廃止された地域

表A-19に、Oracle Database 10gでサポートが廃止になった地域を示します。

表A-19 廃止された地域

廃止された地域名

置換地域

CIS

RUSSIA

MACEDONIA

FYR MACEDONIA

YUGOSLAVIA

SERBIA AND MONTENEGRO

CZECHOSLOVAKIA

CZECH REPUBLICまたはSLOVAKIA

廃止された言語

表A-20に、Oracle Database 10gでサポートされなくなった言語を示します。

表A-20 廃止された言語

廃止された言語名

置換言語

BENGALI

BANGLA

廃止されたキャラクタ・セットおよび置換キャラクタ・セット

表A-21に、廃止されたキャラクタ・セットを示します。次のキャラクタ・セットをコード内で参照する場合は、新しいキャラクタ・セット名に置き換えてください。

表A-21 廃止されたキャラクタ・セットおよび置換文字

旧キャラクタ・セット

置換キャラクタ・セット

AL24UTFSS

UTF8、AL32UTF8

AR8ADOS710T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8ADOS720T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8APTEC715T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8ASMO708PLUS

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8HPARABIC8T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8MUSSAD768T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8NAFITHA711T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8NAFITHA721T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8SAKHR707T

AR8ISO8859P6、AR8MSWIN1256およびAL32UTF8

AR8MSAWIN

AR8MSWIN1256

AR8XBASIC

AR8EBCDIC420S

CL8EBCDIC875S

CL8EBCDIC875R

CL8MSWINDOW31

CL8MSWIN1251

EL8EBCDIC875S

EL8EBCDIC875R

JVMS

JA16VMS

JEUC

JA16EUC

SJIS

JA16SJIS

JDBCS

JA16DBCS

KSC5601

KO16KSC5601

KDBCS

KO16DBCS

CGB2312-80

ZHS16CGB231280

CNS 11643-86

ZHT32EUC

JA16EUCFIXED

UTF8およびAL16UTF16に置換されました。関連項目: この項の「注意」。

ZHS32EUCFIXED

UTF8およびAL16UTF16に置換されました。

ZHS16GBKFIXED

UTF8およびAL16UTF16に置換されました。

JA16DBCSFIXED

UTF8およびAL16UTF16に置換されました。

KO16DBCSFIXED

UTF8およびAL16UTF16に置換されました。

ZHS16DBCSFIXED

UTF8およびAL16UTF16に置換されました。

ZHS16CGB231280FIXED

UTF8およびAL16UTF16に置換されました。

ZHT16DBCSFIXED

UTF8およびAL16UTF16に置換されました。

KO16KSC5601FIXED

UTF8およびAL16UTF16に置換されました。

JA16SJISFIXED

UTF8およびAL16UTF16に置換されました。関連項目: この項の「注意」。

ZHT16BIG5FIXED

UTF8およびAL16UTF16に置換されました。

ZHT32TRISFIXED

UTF8およびAL16UTF16に置換されました。

注意:
次のような場合、キャラクタ・セットJA16EUCFIXED (1830)およびJA16SJISFIXED (1832)は、データベース・クライアント側でサポートされます。

- クライアント側のNLS_NCHAR環境変数に指定されているとき。

- OCIEnvNlsCreate()のncharset(最終)パラメータで指定されているとき。

- バインドあるいは定義ハンドルのOCI_ATTR_CHARSET_ID属性の値として指定されているとき。

AL24UTFFSSキャラクタ・セットの非サポート

Unicodeキャラクタ・セットAL24UTFFSSは、Oracle9i ではサポートされなくなりました。Oracle Database 10gでは、Unicode 4.0に基づくUnicodeデータベース・キャラクタ・セットAL32UTF8と、Unicode 3.0に基づくUTF8が提供されます。これらはUnicode 5.0に組み込まれした。

既存のAL24UTFFSSデータベースを移行する場合は、Oracle11g にアップグレードする前にUTF8にアップグレードします。新規データベース・キャラクタ・セットへのすべての移行と同様に、既存のデータベース・キャラクタ・セットをUTF8に移行する前に、Character Set Scannerをデータ分析に使用することをお薦めします。

注意:
AL24UTFFSSは、Unicode規格1.1に基づくUTF-8コード体系をサポートするUnicodeキャラクタ・セットとしてOracle Databaseのバージョン7から導入されましたが、現在では不要と考えられます。

関連項目:
第12章「Character Set Scannerユーティリティ」

Oracle Databaseの言語および地域定義ファイルの更新

Oracle Database 11gでは、一部の言語および地域定義ファイルの内容が変更されています。Oracleでサポートされている言語および地域の一部では、ローカルの表記規則と一致しなくなったレガシー定義を修正するために、これらの更新が必要です。これらの変更には、通貨記号、月名およびグループ・セパレータの変更が含まれます。その一例が、ブラジルのローカル通貨記号です。この記号は、Oracle Database 10gではCr$からR$に更新されています。

詳細な変更リストについては、$ORACLE_HOME/nls/data/old/data_changes.html ファイル内の「Oracleの言語定義と地域定義の変更」表を参照してください。

Oracle Database 11gのユーザーは、既存のアプリケーション・コードを検討し、Oracle Database 10gで定義されている正しい文化的な慣習が使用されていることを確認する必要があります。アプリケーションのサポートに必要なコード変更を行えないユーザーのために、Oracleデータベースには、Oracle9iのロケール定義ファイルが付属しています。

Oracle9iの言語および地域の動作に戻る手順は、次のとおりです。

1. データベースを停止します。

2. $ORACLE_HOME/nls/data/oldディレクトリからcr9idata.plスクリプトを実行します。

3. ORA_NLS10環境変数を、新規作成した$ORACLE_HOME/nls/data/9idataディレクトリに設定します。

4. データベースを再起動します。

Oracle9iの定義ファイルに戻る必要があるすべてのOracle Database 11gのクライアントにとっては、手順2および3を繰り返す必要があります。

オラクル社では、Oracle Database 11gまたはOracle Database 10gのロケール定義ファイルの使用をお薦めします。Oracle9iのロケール定義ファイルは、将来のリリースでサポートされなくなる予定です。

B Unicode文字コードの割当て

この付録では、Unicode文字の割当てを紹介します。ここでは、次の項目について説明します。

- Unicodeのコード範囲

- UTF-16エンコーディング

- UTF-8エンコーディング

Unicodeのコード範囲

表B-1に、UnicodeでUTF-16文字コード用に割り当てられているコード範囲を示します。

表B-1 UTF-16文字コード用のUnicode文字コード範囲

文字のタイプ

最初の16ビット

次の16ビット

ASCII

0000-007F

-

ヨーロッパ語(ASCIIを除く)、アラビア語、ヘブライ語

0080-07FF

-

インド語、タイ語、記号(ユーロ記号など)、中国語、日本語、韓国語

0800-0FFF

1000 - CFFF

D000 - D7FF

F900-FFFF

-

Private Use Area #1

E000 - EFFF

F000 - F8FF

-

補助文字: その他の中国語、日本語および韓国語の文字、旧漢字、音楽記号および数学記号

D800 - D8BF

D8C0 - DABF

DAC0 - DB7F

DC00 - DFFF

DC00 - DFFF

DC00 - DFFF

Private Use Area #2

DB80 - DBBF

DBC0 - DBFF

DC00 - DFFF

DC00 - DFFF

表B-2に、UnicodeでUTF-8文字コード用に割り当てられているコード範囲を示します。

表B-2 UTF-8文字コード用のUnicode文字コード範囲

文字のタイプ

第1バイト

第2バイト

第3バイト

第4バイト

ASCII

00-7F

-

-

-

ヨーロッパ語(ASCIIを除く)、アラビア語、ヘブライ語

C2-DF

80-BF

-

-

インド語、タイ語、記号(ユーロ記号など)、中国語、日本語、韓国語

E0

E1-EC

ED

EF

A0-BF

80-BF

80-9F

A4-BF

80-BF

80-BF

80-BF

80-BF

-

Private Use Area #1

EE

EF

80-BF

80-A3

80-BF

80-BF

-

補助文字: その他の中国語、日本語および韓国語の文字、旧漢字、音楽記号および数学記号

F0

F1-F2

F3

90-BF

80-BF

80-AF

80-BF

80-BF

80-BF

80-BF

80-BF

80-BF

Private Use Area #2

F3

F4

B0-BF

80-8F

80-BF

80-BF

80-BF

80-BF

注意:
空白は、適用外のコード割当てを示します。文字コードは16進表現で示されています。

UTF-16エンコーディング

表B-1のように、一部の文字(その他の中国語/日本語/韓国語の文字およびPrivate Use Area #2)のUTF-16文字コードは、2単位の16ビットで表現されます。これらは補助文字です。1つの補助文字は、2つの16ビット値で構成されています。最初の16ビット値は0xD800から0xDBFFの範囲内でエンコードされます。次の16ビット値は0xDC00から0xDFFFの範囲内でエンコードされます。補助文字を使用すると、UTF-16文字コードは100万種類以上の文字を表現できます。補助文字を使用しなければ、65,536文字しか表現できません。OracleデータベースのAL16UTF16キャラクタ・セットは、補助文字をサポートしています。

関連項目:
「補助文字」

UTF-8エンコーディング

表B-2のUTF-8文字コードは、次の条件が適用されることを示しています。

- ASCII文字には1バイトを使用します。

- ヨーロッパ語(ASCIIを除く)、アラビア語およびヘブライ語の文字の場合は、2バイト必要です。

- インド語、タイ語、中国語、日本語および韓国語の文字、およびユーロなどの記号の場合は、3バイト必要です。

- Private Use Area #1の文字の場合は、3バイト必要です。

- 補助文字の場合は、4バイト必要です。

- Private Use Area #2の文字の場合は、4バイト必要です。

Oracle DatabaseのAL32UTF8キャラクタ・セットは、1バイト、2バイト、3バイトおよび4バイト値をサポートしています。Oracle DatabaseのUTF8キャラクタ・セットは、1バイト、2バイトおよび3バイト値をサポートしていますが、4バイト値はサポートしていません。

用語集

アクセント

文字の発音を変更する記号。アクセントの一般的な意味は文字の強勢または強調に関連しているため、『Oracle Databaseグローバリゼーション・サポート・ガイド』では発音区別記号という用語を使用します。

「発音区別記号」も参照。

アクセントを区別しない言語ソート

発音区別記号や大/小文字ではなく、ベース文字に関する情報のみを使用するソート。

「言語ソート」、「ベース文字」、「発音区別記号」、「ケース」も参照。

AL16UTF16

SQL NCHARデータ型に使用されるデフォルトのOracleデータベースのキャラクタ・セットで、各国語キャラクタ・セットに使用されます。このキャラクタ・セットは、UnicodeデータをUTF-16エンコーディングでエンコードします。

「各国語キャラクタ・セット」も参照。

AL32UTF8

SQL CHARデータ型に使用されるOracleデータベースのキャラクタ・セットで、データベース・キャラクタ・セットに使用されます。このキャラクタ・セットは、UnicodeデータをUTF-8エンコーディングでエンコードします。

「データベース・キャラクタ・セット」も参照。

ASCII

米国の情報交換標準コード。英語用のエンコードされた共通7ビット・キャラクタ・セット。ASCIIには、文字AからZとaからz、数字、句読点記号および制御文字が含まれます。Oracle Databaseのキャラクタ・セット名はUS7ASCIIです。

ベース文字

発音区別記号なしの文字。たとえば、a、A、äおよびÄのベース文字はaです。

「発音区別記号」も参照。

バイナリ・ソート

バイナリ・コード値に基づいた文字列の順序付け。

バイト・セマンティクス

文字列を一連のバイトとして取り扱うこと。

「キャラクタ・セマンティクス」と「長さセマンティクス」も参照。

標準的な同値化

文字間または文字列間の基本的な同値化。たとえば、çは、cと,の組合せと同じです。正常にレンダリングされている場合は、両者を区別できません。

ケース

大文字であるか小文字であるかの条件を指します。たとえばラテン・アルファベットの場合、Aが大文字で、それに対する小文字がaです。

大/小文字の変換

ある文字を大文字から小文字に、または小文字から大文字に変換すること。

大/小文字を区別しない言語ソート

大/小文字ではなく、ベース文字と発音区別記号に関する情報を使用するソート。

「ベース文字」、「ケース」、「発音区別記号」、「言語ソート」も参照。

文字

テキストの抽象要素。文字は、その文字の特定の表現である絵文字とは異なります。たとえば、英大文字の最初の文字は、A、A、Aのように表示されます。これらの形式は、同じ文字を表現する異なる絵文字です。文字、文字コードおよび絵文字には、次のような関連があります。

文字 --(エンコーディング)--> 文字コード --(フォント)--> 絵文字

たとえば、英大文字の最初の文字は、コンピュータのメモリーでは数値として表されます。この数値は、エンコーディングまたは文字コードと呼ばれます。英大文字の最初の文字の文字コードは、ASCIIコード体系では0x41で、EBCDICコード体系では0xc1です。

この文字を表示または印字するには、フォントを選択する必要があります。使用可能なフォントは、使用するコード体系によって異なります。たとえば、文字をA、AまたはAとして印字または表示できます。これらの形式は、同じ文字を表現する異なる絵文字です。

「文字コード」と「絵文字」も参照。

文字の分類

各文字コードに関連付けられた文字のタイプに関する詳細を提供する情報。たとえば、文字には大文字、小文字、句読点、制御文字があります。

文字コード

特定の文字を表現する番号。この番号はコード体系によって異なります。たとえば、英大文字の最初の文字の文字コードは、ASCIIコード体系では0x41ですが、EBCDICコード体系では0xc1です。

「文字」も参照。

文字コード体系

キャラクタ・セットのすべての文字に対して番号(文字コード)を割り当てる規則。コード体系、エンコーディング・メソッドおよびエンコーディングも、文字コード体系を意味します。

文字レパートリ

特定のキャラクタ・セットを表したり、エンコードしたりするときに使用される文字のこと。

キャラクタ・セマンティクス

文字列を一連の文字として取り扱うこと。

「バイト・セマンティクス」と「長さセマンティクス」も参照。

キャラクタ・セット

特定の言語または言語グループのテキスト情報を表す要素の集まり。1つの言語を複数のキャラクタ・セットで表現できます。

キャラクタ・セットは、必ずしも特定の文字コード体系を示すわけではありません。文字コード体系は、キャラクタ・セットの各文字に対する文字コードの割当てです。

このマニュアルでは、通常、キャラクタ・セットは特定の文字コード体系を示しています。したがって、このマニュアルでは、キャラクタ・セットとエンコードされたキャラクタ・セットは同じです。

キャラクタ・セットの移行

既存のデータベースのキャラクタ・セットを変更すること。

文字列

順序付きの文字グループ。

文字列に文字が含まれていない場合もあります。この場合、その文字列はヌル文字列と呼ばれます。ヌル文字列の文字列長は0(ゼロ)です。

クライアント・キャラクタ・セット

クライアントで使用される、エンコードされたキャラクタ・セット。クライアント・キャラクタ・セットは、サーバーのキャラクタ・セットとは異なる場合があります。サーバーのキャラクタ・セットは、データベース・キャラクタ・セットと呼ばれます。クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと異なる場合は、キャラクタ・セット変換が必要です。

「データベース・キャラクタ・セット」も参照。

コード・ポイント

キャラクタ・セットの1文字の数値表現。たとえば、ASCIIキャラクタ・セットでは、Aのコード・ポイントは0x41です。文字のコード・ポイントは、その文字のエンコーディング値とも呼ばれます。

「Unicodeコード・ポイント」も参照。

コード単位

エンコードされたテキストを処理および交換する単位。コード単位のサイズは、文字コード体系に応じて異なります。ほとんどの文字エンコーディングでは、コード単位は1バイトです。ただし、UTF-16とUCS-2の場合は2バイトのコード単位が使用され、ワイド・キャラクタの場合は4バイトが使用されます。

「文字コード体系」も参照。

照合

特定のロケールの言語に関連付けられた文字のソートに関する規則に従って文字列を順序付けすること。言語ソートとも呼ばれます。

「言語ソート」、「単一言語ソート」、「多言語ソート」、「アクセントを区別しない言語ソート」、「大/小文字を区別しない言語ソート」も参照。

データ・スキャニング

データベース・キャラクタ・セットの移行前に、キャラクタ・セット変換とデータの切捨てに伴う問題の可能性を識別するプロセス。

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

テキストをデータベースに格納するために使用される、エンコードされたキャラクタ・セット。CHAR、VARCHAR2、LONGおよび固定幅のCLOB列の値と、すべてのSQLおよびPL/SQLテキストが含まれます。

発音区別記号

文字または文字列の上または下にある記号で、それが付いていない場合の文字とは発音が異なることを示します。たとえば、façadeの場合、セディラは発音区別記号です。セディラが付いている場合は、cの発音が変化します。

EBCDIC

拡張2進化10進コード。IBMシステムで最も使用されるエンコードされたキャラクタ・セット・ファミリ。

エンコードされたキャラクタ・セット

文字コード体系が関連付けられているキャラクタ・セット。エンコードされたキャラクタ・セットは、各文字に割り当てる番号(文字コード)を指定します。

「文字コード体系」も参照。

エンコーディング値

キャラクタ・セットの1文字の数値表現。たとえば、ASCIIキャラクタ・セットでは、Aのコード・ポイントは0x41です。文字のエンコーディング値は、その文字のコード・ポイントとも呼ばれます。

フォント

キャラクタ・セット内の文字をグラフィカルに表現する順序付けられた絵文字の集まり。

グローバリゼーション

ソフトウェアを多様な言語および文化の環境に適したものにするプロセス。グローバリゼーションとローカライゼーションは異なるものであり、ローカライゼーションとは、ソフトウェアをある固有のロケールで使用できるように準備するプロセスです(たとえば、ある言語から他の言語へのエラー・メッセージやユーザー・インタフェースの翻訳)。

絵文字

文字の固有の表現。1つの文字は、多数の異なる絵文字を持つことができます。たとえば、英大文字の最初の文字は、A、A、Aのように印字または表示されます。これらの形式は、同じ文字を表現する異なる絵文字です。

「文字」も参照。

表意文字

概念を表現する記号。表意的記述法の例に中国語があります。

ISO

国際標準化機構(ISO)。130か国からなる標準機関の世界的な連合。ISOでは、世界規模の規格を開発および促進し、商品やサービスの国際的な交流を容易にすることを目的としています。

ISO 8859

8ビットのエンコードされたキャラクタ・セット・ファミリ。最も一般的なものは、ISO 8859-1(ISO Latin-1として知られています)で、西ヨーロッパ諸国で使用されています。

ISO 14651

ほとんどの言語向けに設計された国際的な多言語ソート規格。

「多言語ソート」も参照。

ISO/IEC 10646

現在、世界で使用されているほとんどの主要文字を定義しているユニバーサル・キャラクタ・セットの規格。1993年には、ISOによってUnicodeバージョン1.1がISO/IEC 10646-1:1993として承認されています。ISO/IEC 10646には、2バイト固定幅形式のUCS-2と4バイト固定幅形式のUCS-4があります。実装には3つのレベルがあり、すべてのレベルは複合文字のサポートに関係します。

- レベル1では、複合文字をサポートする必要はありません。

- レベル2では、特定の文字(アラビア文字、タイ文字などのほとんどのUnicode文字を含む)をサポートする必要があります。

- レベル3では、あらゆる言語の複合文字を無制限にサポートする必要があります。

ISO通貨

各国通貨を示すために使用される3文字の略称で、ISO 4217規格に基づいています。たとえば、USDは米国のドルを表します。

ISO Latin-1

ISO 8859-1キャラクタ・セット規格。ASCIIに対する8ビット拡張機能で、西ヨーロッパで最も頻繁に使用される共通のラテン文字を含む128文字が追加されています。Oracle Databaseのキャラクタ・セット名は、WE8ISO8859P1です。

「ISO 8859」も参照。

長さセマンティクス

文字列の長さの取扱い方法を決定します。文字列の長さは、一連の文字またはバイトとして取り扱うことができます。

「キャラクタ・セマンティクス」と「バイト・セマンティクス」も参照。

言語索引

言語上のソート順序に基づいた索引。

言語ソート

文字列のバイナリ表現ではなく、ロケールに関する要件に基づいた文字列の順序付け。

「多言語ソート」と「単一言語ソート」も参照。

ロケール

特定の地域で参照される言語的および文化的な情報の集まり。一般的に、ロケールはNLSデータファイルに定義されている言語、地域、キャラクタ・セット、言語処理およびカレンダ情報で構成されます。

ローカライゼーション

言語固有または文化固有の情報をソフトウェア・システムに提供するプロセス。アプリケーションのユーザー・インタフェースの翻訳は、ローカライゼーションの1つの例です。ローカライゼーションとグローバリゼーションは異なるものです。グローバリゼーションとは、ソフトウェアを多様な言語および文化的な環境に適したものにすることです。

単一言語ソート

文字列を2つのレベルで比較するOracleデータベースのソート。単一言語ソートを使用すると、ヨーロッパ地域の大半の言語はソートできますが、アジア地域の言語には不向きです。

「多言語ソート」も参照。

単一言語サポート

1つの言語のみのサポート。

マルチバイト

2バイト以上であること。

特定の言語(または言語グループ)のすべての文字に対して文字コードが割り当てられた場合は、1バイト(8ビット)では256の異なる文字を表現できます。2バイト(16ビット)では、65,536の異なる文字を表現できます。すべての文字を表現するために、2バイトでは不十分な言語も多いです。一部の文字には3または4バイト必要です。

たとえば、UnicodeのUTF8エンコーディングがあります。UTF8には、多数の2バイトおよび3バイトの文字があります。

また、台湾で使用する繁体字中国語もこの例の1つ。この言語では、80,000以上の文字が使用されます。台湾で使用されている一部の文字コード体系は、4バイトを使用して文字をエンコードします。

「シングルバイト」も参照。

マルチバイト・キャラクタ

ある文字コード体系で、2バイト以上の文字コードから構成される文字。

コード体系が異なると、同じ文字に異なる文字コードが対応する場合があります。使用している文字コード体系が不明な場合、Oracleデータベースでは文字がマルチバイト・キャラクタであるかどうかを判断できません。たとえば、日本語の半角カタカナ文字は、JA16SJISのエンコードされたキャラクタ・セットでは1バイト、JA16EUCでは2バイト、UTF8では3バイトです。

「シングルバイト文字」も参照。

マルチバイト・キャラクタ文字列

次のいずれかの文字列で構成される文字列。

- 文字なし(ヌル文字列と呼ばれます)

- 1つ以上のシングルバイト文字

- 1つ以上のシングルバイト文字と1つ以上のマルチバイト文字の混合

- 1つ以上のマルチバイト文字

多言語ソート

3つのレベルで文字列を評価するOracleデータベースのソート。アジア言語の場合は、1言語によるデータしか存在しない場合にも、多言語ソートが必要です。多言語ソートは、複数言語によるデータが存在する場合にも使用されます。

各国語キャラクタ・セット

NCHAR、NVARCHAR2およびNCLOB列に指定できるデータベース・キャラクタ・セットの代替キャラクタ・セット。各国語キャラクタ・セットはUnicode内のみです。

NLBファイル

ロケール固有のデータを定義するためにLocale Builderが使用するバイナリ・ファイル。このファイルでは、特定リリースのOracle Databaseに付属するロケール定義がすべて定義されます。Oracle Locale Builderを使用すると、ユーザー定義のNLBファイルを作成できます。

「Oracle Locale Builder」と「NLTファイル」も参照。

NLS

National Language Support。NLSによって、ユーザーは母国語でデータベースと対話できます。さらに、アプリケーションを様々な言語および文化の環境で実行できます。Oracleデータベースはかつて複数のグローバル・ユーザーをサポートしていたため、この用語は幾分古いです。

NLSRTL

National Language Supportランタイム・ライブラリ。このライブラリは、ロケールに依存しない国際化に関するアルゴリズムを提供します。ロケール固有の情報(つまり、NLSDATA)は、実行中にNLSRTLライブラリによって読み込まれます。

NLTファイル

ロケール固有のデータを定義するためにLocale Builderが使用するテキスト・ファイル。このファイルはテキスト形式なので、内容を表示できます。

ヌル文字列

文字が含まれていない文字列。

Oracle Locale Builder

ロケール固有のデータを表示、変更または定義する方法を提供するGUIユーティリティ。言語、地域、キャラクタ・セットおよび言語ソートについて、独自の形式を作成することもできます。

置換文字

ソース文字がターゲット・キャラクタ・セットにない場合、その文字の変換時に使用される文字。たとえば、Oracleデータベースでは多くの場合、?がデフォルトの置換文字として使用されます。

制限付き多言語サポート

関連する言語のグループに制限された多言語サポート。西ヨーロッパ諸国の言語は、ISO 8859-1などで表現されます。多言語サポートが制限付きの場合、タイ語は言語グループに追加できません。

SQL CHARデータ型

CHAR、VARCHAR、VARCHAR2、CLOBおよびLONGデータ型が含まれます。

SQL NCHARデータ型

NCHAR、NVARCHAR、NVARCHAR2およびNCLOBデータ型が含まれます。

スクリプト

特定の書記体系。書記体系で使用される、関連する図形記号の集まり。スクリプトの中には複数の言語を表現できるものもあり、言語の中には複数のスクリプトを使用するものもあります。スクリプトの例として、ラテン文字、アラビア文字および漢字があります。

シングルバイト

1バイト。1バイトは、通常8ビットで構成されます。特定の言語のすべての文字に文字コードを割り当てる場合、1バイト(8ビット)では256の異なる文字を表現できます。

「マルチバイト」も参照。

シングルバイト文字

ある文字コード体系で、1バイトの文字コードで構成される文字。コード体系が異なると、同じ文字に異なる文字コードが対応する場合があります。使用しているコード体系が不明な場合、Oracle Databaseではどの文字がシングルバイト文字であるかを判断できません。たとえば、ユーロ通貨記号は、WE8MSWIN1252のエンコードされたキャラクタ・セットでは1バイト、AL16UTF16では2バイト、UTF8では3バイトです。

「マルチバイト・キャラクタ」も参照。

シングルバイト文字列

シングルバイト文字列は、次のいずれかの文字列で構成されます。

- 文字なし(ヌル文字列と呼ばれます)

- 1つ以上のシングルバイト文字

補助文字

Unicodeの最初のバージョンは16ビットの固定幅エンコーディングで、各文字のエンコーディングに2バイトを使用していました。このため、65,536文字を表現できました。しかし、アジア言語の多数の表意文字の関係で、より多くの文字のサポートが必要となっています。

Unicode 3.1では、このニーズを満たすために補助文字が定義されていました。Unicode 3.1では、2つの16ビット・コード単位(サロゲート・ペアとも呼ばれます)を使用して、1つの文字が表現するようになりました。このため、さらに1,048,576文字の定義が可能でした。Unicode 3.1規格には、最初のグループとして44,944文字の補助文字が追加されました。Unicode 4.0でも補助文字が追加され、Unicode 5.0ではさらに1,369文字が追加されました。

サロゲート・ペア

「補助文字」も参照。

表音文字セット

日本語などの言語で使用する表意文字とともに表音的情報を伝達する方法を提供します。

UCS-2

1993 ISO/IEC規格のキャラクタ・セット。固定幅の16ビットUnicodeキャラクタ・セットです。各文字は16ビットの領域を持ちます。ISO Latin-1文字は最初の256コード・ポイントであり、ISO Latin-1の16ビット拡張とみなすことができます。

UCS-4

固定幅の32ビットUnicodeキャラクタ・セット。各文字は32ビットの領域を持ちます。UCS-2の文字はこの規格の最初の65,536コード・ポイントであるため、UCS-2の32ビット拡張とみなすことができます。ISO-10646と呼ばれる場合もあります。

Unicode

エンコードされたユニバーサル・キャラクタ・セットのことで、1つのキャラクタ・セットを使用して任意の言語の情報を格納できます。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。

Unicodeデータベース

データベース・キャラクタ・セットがUTF-8のデータベース。

Unicodeコード・ポイント

Unicodeコード領域にある0から0x10FFFFの値。Unicodeでは、各文字に一意のコード・ポイントが割り当てられます。

Unicodeデータ型

SQL NCHARデータ型(NCHAR、NVARCHAR2およびNCLOB)。データベース・キャラクタ・セットがUnicodeでない場合も、これらのデータ型の列にUnicode文字を格納できます。

無制限多言語サポート

要求に応じて多数の言語を使用するための機能。Unicodeなどのユニバーサル・キャラクタ・セットを使用すると、無制限に多言語をサポートできるようになります。ユニバーサル・キャラクタ・セットでは大規模な文字レパートリをサポートしています。この文字レパートリには世界のほとんどの現代語が含まれています。

UTFE

6バイト補助文字のサポート付きUnicode 5.0 UTF-8 Oracleデータベース・キャラクタ・セット。EBCDICプラットフォームでのみ使用されます。

UTF8

UTF8 Oracleデータベース・キャラクタ・セットは、文字を1バイト、2バイトまたは3バイトでエンコードします。ASCIIベースのプラットフォーム用です。UTF8キャラクタ・セットはUnicode5.0をサポートし、CESU-8規格に準拠しています。Unicode 3.1では、特定の補助文字にコード・ポイントが割り当てられていませんでしたが、Unicode 3.0では補助文字用のコード・ポイント範囲が割り当てられていました。補助文字は、6バイトを占める2つの別個のユーザー定義文字として処理されます。

UTF-8

Unicodeの8ビット・エンコーディング。可変幅エンコーディングです。UTF-8エンコーディングでは、1つのUnicode文字を、1バイト、2バイト、3バイトまたは4バイトで表すことができます。ヨーロッパ言語の文字は、1バイトまたは2バイトで表します。ほとんどのアジア言語の文字は、3バイトで表します。補助文字は、4バイトで表します。UTF-8をサポートするOracleデータベース・キャラクタ・セットはAL32UTF8です。

UTF-16

Unicodeの16ビット・エンコーディング。UCS-2の拡張であり、UCS-2コード・ポイントのペアを使用して、Unicodeに定義されている補助文字をサポートします。UTF-16エンコーディングでは、1つのUnicode文字を、2バイトか4バイトで表すことができます。ヨーロッパ言語とほとんどのアジア言語の文字(ASCII文字を含む)は、ともに2バイトで表します。補助文字は、4バイトで表します。UTF-16をサポートするOracleデータベース・キャラクタ・セットはAL16UTF16です。

ワイド・キャラクタ

固定幅の文字形式。固定幅の領域でデータが処理されるので、大量のテキスト処理に適しています。ワイド・キャラクタは、内部の文字処理をサポートすることを目的としています。

索引
A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  Q  R  S  T  U  V  W  X

記号

$ORACLE_HOME/nls/dataディレクトリ, 1.1.1

$ORACLE_HOME/oracore/zoneinfo/timezone.datタイム・ゾーン・ファイル, 4.6

数字

7ビット・コード体系, 2.1.4.1, 2.1.4.1

8ビット・コード体系, 2.1.4.1, 2.1.4.1

A

略称

言語, A.1

抽象データ型

NCHARとして作成, 2.3.9

アクセント, 5.5 アクセントを区別しない言語ソート, 5.5 ADCSスクリプト

Real Application Clustersでのキャラクタ・セットの移行, 11.2.2.1

ADD_MONTHS SQL関数, 4.4 ADOインタフェースとUnicode, 7.6.6 AL16UTF16キャラクタ・セット, 6.2.3, A.4.5 AL24UTFFSSキャラクタ・セット, 6.2.3 AL32UTF8キャラクタ・セット, 6.2.3, 6.3.1, A.4.5 ALTER SESSION文

SET NLS_CURRENCY句, 3.9.2, 3.9.3

SET NLS_LANGUAGE句, 3.5.2.1

SET NLS_NUMERIC_CHARACTERS句, 3.8.2

SET NLS_TERRITORY句, 3.5.2.1

ALTER TABLE MODIFY文

CHARからNCHARへの移行, 11.3.3, 11.3.3.1

analyse_histgrm.sqlスクリプト, 12.8 analyse_rule.sqlスクリプト, 12.8 analyse_source.sqlスクリプト, 12.8 application-locales, 8.8.3 Arial Unicode MSフォント, 13.1.1.1 ARRAYパラメータ

Database Character Set Scanner, 12.5

ASCIIエンコーディング, 2.1.3.1 AT LOCAL句, 4.11 AT TIME ZONE句, 4.11

B

ベース文字, 5.3.3.1, 5.4.1

BFILEデータ

LOBへのロード, 9.3.4

バイナリ・ソート, 5.2

大/小文字およびアクセントを区別しない, 5.5.2

例, 5.5.3

OCIでのCLOBおよびNCLOBデータのバインドと定義, 7.3.7 OCIでのSQL CHARデータ型のバインドと定義, 7.3.4 OCIでのSQL NCHARデータ型のバインドと定義, 7.3.5 BLANK_TRIMMINGパラメータ, 11.1.1.1 BLOB

索引の作成, 6.5.4.3

BOUNDARIESパラメータ

Database Character Set Scanner, 12.5

バイト・セマンティクス, 2.2, 3.12.1

C

C数値書式マスク, 3.9.3

カレンダ・ユーティリティ, 13.3.2

カレンダ

カスタマイズ, 13.3.2

パラメータ, 3.7

サポート対象, A.7

標準的な同値化, 5.3.2, 5.4.6 CAPTUREパラメータ

Database Character Set Scanner, 12.5

ケース, 5.1 大/小文字を区別しない言語ソート, 5.5 CESU-8準拠, A.4.5 CHAR列

NCHAR列への移行, 11.3.3

文字データ

CONVERT SQL関数による変換, 9.2.1

文字データ変換

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

文字データのスキャン

キャラクタ・セットの移行前, 11.2

文字の再配列, 5.4.8 文字レパートリ, 2.1.1 キャラクタ・セマンティクス, 2.2, 3.12.1 キャラクタ・セット

変換, 13.5.2

データ消失

変換時, 2.3.3

Globalization Development Kitを使用した検出, 8.7.6 各国語, 7.2.1.2 キャラクタ・セットの変換

OCIクライアントとデータベース・サーバーの間, 7.3.2

パラメータ, 3.11

キャラクタ・セット定義

カスタマイズ, 13.5.6

ファイルの編集に関するガイドライン, 13.5.5

ファイルのネーミング, 13.5.5

キャラクタ・セットの移行

CSALTERスクリプト, 11.2.2

文字データ変換の問題の識別, 11.2

移行後のタスク, 11.4

文字データのスキャン, 11.2

キャラクタ・セット

AL16UTF16, 6.2.3

AL24UTFFSS, 6.2.3

AL32UTF8, 6.2.3

アジア地域, A.4.1, A.4.1, A.4.1

データベース作成後の変更, 2.4

選択, 11.1

Unicodeデータベース用キャラクタ・セットの選択, 6.3.4

各国語キャラクタ・セットの選択, 6.3.4

変換, 2.3.3, 2.5.1, 9.2.1

OCIを使用した変換, 10.7

カスタマイズ, 13.5

データ消失, 11.1.2.1

エンコーディング, 2.1

ヨーロッパ地域, A.4.2, A.4.2

ISO 8859シリーズ, 2.1.3.1

中東地域, A.4.4

移行およびデータ・ディクショナリ, 12.8

移行, 11.1, 11.1.1

ネーミング, 2.1.5

各国語, 6.3.2, 7.2.1.1

名前を表すために使用するキャラクタ・セットに関する制限事項, 2.3.5.1

スーパーセットとサブセット, A.4.7

サポート対象, A.4

様々な文字レパートリのサポート, 2.1.3

ユニバーサル, A.4.5

UTFE, 6.2.3

キャラクタ各国語, 2.3.8 文字列型の変換

エラー・レポート, 3.11.1

文字

すべてのOracleデータベース・キャラクタ・セットで使用可能, 2.1.3

状況依存, 5.4.5

短縮, 5.4.3

ユーザー定義, 13.5.1

キャラクタ・セットの選択, 11.1 UnicodeデータベースとUnicodeデータ型の間の選択, 6.3.3 クライアントのオペレーティング・システム

アプリケーションとのキャラクタ・セットの互換性, 2.3.2

CLOBおよびNCLOBデータ

OCIでのバインドと定義, 7.3.7

CLOB

索引の作成, 6.5.4.2

コード・チャート

表示と印刷, 13.4

コード・ポイント, 2.1.1 照合

カスタマイズ, 13.6

COLUMNパラメータ

Database Character Set Scanner, 12.5

互換性

クライアントのオペレーティング・システムとアプリケーションのキャラクタ・セットの互換性, 2.3.2

合成文字, 5.4.3 状況依存, 5.4.5 短縮文字, 5.4.3 短縮文字, 5.4.10 制御文字, エンコーディング, 2.1.2.3 変換

キャラクタ・セットID番号とキャラクタ・セット名, 9.2.4

CONVERT SQL関数, 9.2.1

キャラクタ・セット, A.4.6

タイム・ゾーンの変換, 4.11 変換可能なデータ

データ・ディクショナリ, 12.8

文字データの変換

CONVERT SQL関数, 9.2.1

キャラクタ・セット間の文字データ変換, 9.2.1 協定世界時, 4.2.1.3, 4.2.1.4 Unicodeデータ型を使用したデータベースの作成, 6.3.2 Unicodeデータベースの作成, 6.3.1 CSALTERスクリプト, 11.2.2, 11.2.2.1

チェック・フェーズ, 12.10.1

実行, 12.10

更新フェーズ, 12.10.2

CSM$COLUMNS表, 12.9.1.2 CSM$ERRORS表, 12.9.1.3 CSM$TABLES表, 12.9.1.1 CSMIGユーザー, 12.4.2 csminst.sqlスクリプト

実行, 12.4.2

CSMV$COLUMNSビュー, 12.11.1 CSMV$CONSTRAINTSビュー, 12.11.2 CSMV$ERRORビュー, 12.11.3 CSMV$INDEXESビュー, 12.11.4 CSMV$TABLESビュー, 12.11.5 通貨

書式, 3.9.1

CURRENT_DATE SQL関数, 4.4 CURRENT_TIMESTAMP SQL関数, 4.4 タイム・ゾーン・データのカスタマイズ, 13.3.1

D

データ変換

Pro*C/C++, 7.4.1

OCIドライバ, 7.5.5.1

ODBCおよびOLE DBドライバ, 7.6.3

Thinドライバ, 7.5.5.2

UnicodeのJava文字列, 7.5.5

データ・ディクショナリ

キャラクタ・セット, 12.8

変換可能データまたは不可逆データ, 12.8

データ・ディクショナリ・ビュー

NLS_DATABASE_PARAMETERS, 3.4.1

NLS_INSTANCE_PARAMETERS, 3.4.1

NLS_SESSION_PARAMETER, 3.4.1

データの拡張

キャラクタ・セット移行時, 11.1.1

データ変換時, 7.3.2.3

データ消失の原因となるデータの非一貫性, 11.1.2.2 データ消失

データの非一貫性が原因, 11.1.2.2

キャラクタ・セット変換時, 2.3.3

キャラクタ・セット移行時, 11.1.2.1

データ型変換時

例外, 7.2.3

OCIのUnicodeキャラクタ・セット変換時, 7.3.2.1 キャラクタ・セットの混在, 11.1.2.2 データ・ポンプのPL/SQLパッケージおよびキャラクタ・セットの移行, 11.1.2.3 データの切捨て, 11.1.1

制限事項, 11.1.1.1

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

文字データ変換, 11.2

選択, 2.3

クライアントのオペレーティング・システムとアプリケーションとの互換性, 2.3.2

パフォーマンス, 2.3.4

Database Character Set Scanner, 12.5

analyse_histgrm.sqlスクリプト, 12.8

analyse_rule.sqlスクリプト, 12.8

analyse_source.sqlスクリプト, 12.8

ARRAYパラメータ, 12.5

BOUNDARIESパラメータ, 12.5

CAPTUREパラメータ, 12.5

COLUMNパラメータ, 12.5

CSM$COLUMNS表, 12.9.1.2

CSM$ERRORS表, 12.9.1.3

CSM$TABLES表, 12.9.1.1

CSMV$COLUMNSビュー, 12.11.1

CSMV$CONSTRAINTSビュー, 12.11.2

CSMV$ERRORビュー, 12.11.3

CSMV$INDEXESビュー, 12.11.4

CSMV$TABLESビュー, 12.11.5

データベース・スキャンのサマリー・レポート, 12.7.1

エラー・メッセージ, 12.12

EXCLUDEパラメータ, 12.5

FEEDBACKパラメータ, 12.5

FROMNCHARパラメータ, 12.5

FULLパラメータ, 12.5

HELPパラメータ, 12.5

個別例外レポート, 12.7.2

起動, 12.4.3

LASTRPTパラメータ, 12.5, 12.5

MAXBLOCKSパラメータ, 12.5

オンライン・ヘルプ, 12.4.5

パフォーマンス, 12.9.2

PRESERVEパラメータ, 12.5

QUERYパラメータ, 12.5

制限事項, 12.9.3

スキャン・モード, 12.3

SUPPRESSパラメータ, 12.5

TABLEパラメータ, 12.5

TOCHARパラメータ, 12.5

USERパラメータ, 12.5

USERIDパラメータ, 12.5

ユーティリティ, 12.2

ビュー, 12.11

データベース・スキャンのサマリー・レポート, 12.7.1 データベース・スキーマ

複数言語用の設計, 6.5

データベースのタイム・ゾーン, 4.9 データ型変換

データ消失と例外, 7.2.3

暗黙的, 7.2.4

SQL関数, 7.2.5

データ型

概要, 2.3.9

日付, 4.2.1.1

日時, 4.2

日時データ型への値の挿入, 4.2.1.5

期間データ型への値の挿入, 4.2.2.3

期間, 4.2, 4.2.2

INTERVAL DAY TO SECOND, 4.2.2.2

INTERVAL YEAR TO MONTH, 4.2.2.1

サポート対象, 2.3.9

TIMESTAMP, 4.2.1.2

TIMESTAMP WITH LOCAL TIME ZONE, 4.2.1.4

TIMESTAMP WITH TIME ZONE, 4.2.1.3

日付および時間を指定するパラメータ, 3.6 DATEデータ型, 4.2.1.1 日付書式, 3.6.1, 3.6.1.1, 9.3.1

パーティション・バウンド式, 3.6.1.1

日付

ISO規格, 3.7.1.2, 9.3.2

NLS_DATE_LANGUAGEパラメータ, 3.6.1.2

日時データ型, 4.2

値の挿入, 4.2.1.5

日時書式パラメータ, 4.5.1 夏時間

Oracleでのサポート, 4.12

ルール, 4.7.1

夏時間セッション・パラメータ, 4.5.3 夏時間アップグレード・パラメータ, 4.5.4 曜日

書式要素, 3.6.1.2

名前の言語, 3.6.1.2

データベースのタイム・ゾーンDB_TZ, 4.10 DBMS_LOB PL/SQLパッケージ, 9.3.4 DBMS_LOB.LOADBLOBFROMFILEプロシージャ, 9.3.4 DBMS_LOB.LOADCLOBFROMFILEプロシージャ, 9.3.4 DBMS_REDEFINITION.CAN_REDEF_TABLEプロシージャ, 11.3.3.2 DBTIMEZONE SQL関数, 4.4 dest_char_setパラメータ, A.4.6 言語とキャラクタ・セットの検出

Globalization Development Kit, 8.7.6

検出

サポート対象の言語とキャラクタ・セット, A.5

発音区別記号, 5.1 DST_UPGRADE_INSERT_CONV初期化パラメータ, 4.5.4 動的パフォーマンス・ビュー

V$NLS_PARAMETERS, 3.4.2

V$NLS_VALID_VALUES, 3.4.2

E

エンコーディング

制御文字, 2.1.2.3

表意的記述法, 2.1.2.2

数字, 2.1.2.3

表音的記述法, 2.1.2.1

句読点, 2.1.2.3

記号, 2.1.2.3

コード体系

7ビット, 2.1.4.1, 2.1.4.1

8ビット, 8-bit, 2.1.4.1, 2.1.4.1

固定幅, 2.1.4.2

マルチバイト, 2.1.4.2

シフト・センシティブ可変幅, 2.1.4.2

シフト・センシティブ可変幅マルチバイト, 2.1.4.2

シングルバイト, 2.1.4.1

可変幅, 2.1.4.2

環境変数

ORA_SDTZ, 4.5.2, 4.10

ORA_TZFILE, 4.5.2

エラー・メッセージ

言語, A.2

変換, A.2

ERROR_ON_OVERLAP_TIMEセッション・パラメータ, 4.5.3 ユーロ

Oracleでのサポート, 3.9.5

EXCLUDEパラメータ

Database Character Set Scanner, 12.5

拡張文字, 5.4.9

文字

拡張, 5.4.4

EXTRACT (datetime) SQL関数, 4.4

F

FEEDBACKパラメータ

Database Character Set Scanner, 12.5

固定幅マルチバイト・コード体系, 2.1.4.2 フォント

Unicode, 13.1.1

UNIX用Unicode, 13.1.1.2

Windows用Unicode, 13.1.1.1

書式要素, 9.3.3

C, 9.3.3

D, 9.3.3

曜日, 3.6.1.2

G, 9.3.3

IW, 9.3.2

IY, 9.3.2

L, 9.3.3

月, 3.6.1.2

RM, 9.3.1

RN, 9.3.3

書式マスク, 3.8.2, 9.3.1 書式

通貨, 3.9.1

日付, 3.6.1.1, 4.5.1

数値, 3.8.1

時間, 3.6.2

FROM_TZ SQL関数, 4.4 FROMCHARパラメータ, 12.5

Database Character Set Scanner, 12.5

FROMNCHARパラメータ

Database Character Set Scanner, 12.5

FULLパラメータ

Database Character Set Scanner, 12.5

G

GDK

アプリケーション構成ファイル, 8.6.1

GDKアプリケーション構成ファイル, 8.8

例, 8.8.8

J2EE用GDKアプリケーション・フレームワーク, 8.6, 8.6 GDKのコンポーネント, 8.4 GDKエラー・メッセージ, 8.11 GDKのJava API, 8.7 GDKのJava提供パッケージおよびクラス, 8.9 GDK Localizerオブジェクト, 8.6.4 gdkapp.xmlアプリケーション構成ファイル, 8.8 gdkapp.xmlアプリケーション構成ファイル, 8.6.1 getString()メソッド, 7.5.6.1 getStringWithReplacement()メソッド, 7.5.6.1 Globalization Development Kit, 8.1

アプリケーション構成ファイル, 8.8

キャラクタ・セットの変換, 8.7.3

コンポーネント, 8.4

サポートされているアプリケーション・ロケールの定義, 8.6.5

電子メール・プログラム, 8.7.8

エラー・メッセージ, 8.11

フレームワーク, 8.6

ロケール・ソースの統合, 8.6.2

Java API, 8.7

Java提供パッケージおよびクラス, 8.9

ロケール検出, 8.6.3

Localizerオブジェクト, 8.6.4

静的ファイルでのローカライズされたコンテンツの管理, 8.6.7.2

JSPとJava Servletでの文字列の管理, 8.6.7.1

HTMLページでのASCII以外の入出力, 8.6.6

Oracleのバイナリ・ソートと言語ソート, 8.7.5

Oracleの日付、数値および通貨書式, 8.7.4

言語およびキャラクタ・セット検出の有効化, 8.7.6

Oracleロケール情報, 8.7.1

Oracleロケール・マッピング, 8.7.2

Oracleの翻訳済ロケール名とタイム・ゾーン名, 8.7.7

サポートされているロケール・リソース, 8.6.2

グローバリゼーションの機能, 1.2 グローバリゼーション・サポート

アーキテクチャ, 1.1

グリニッジ標準時, 4.2.1.3, 4.2.1.4 言語またはキャラクタ・セットの推測, 12.1

H

HELPパラメータ

Database Character Set Scanner, 12.5

I

IANAキャラクタ・セット

ISOロケールとのマッピング, 8.6.6

表意的記述法, エンコーディング, 2.1.2.2 無視可能文字, 5.4.2 暗黙的なデータ型変換, 7.2.4 索引

CLOBとして格納されたドキュメント用の作成, 6.5.4.2

多言語ドキュメントの検索用に作成, 6.5.4

BLOBとして格納されたドキュメントに対する索引の作成, 6.5.4.3

パーティション, 9.2.5.3

個別例外レポート, 12.7.2 初期化パラメータ

DST_UPGRADE_INSERT_CONV, 4.5.4

初期化パラメータ

NLS_DATE_FORMAT, 4.5.1

NLS_TIMESTAMP_FORMAT, 4.5.1

NLS_TIMESTAMP_TZ_FORMAT, 4.5.1

INSTR SQL関数, 7.2.6, 9.2.2, 9.2.2 インターネット・アプリケーション

ロケール

判別, 8.3.1

単一言語, 8.2, 8.2.1 多言語, 8.2, 8.2.2 期間データ型, 4.2, 4.2.2

値の挿入, 4.2.2.3

INTERVAL DAY TO SECONDデータ型, 4.2.2.2 INTERVAL YEAR TO MONTHデータ型, 4.2.2.1 ISO 8859キャラクタ・セット, 2.1.3.1 ISOロケール

IANAキャラクタ・セットとのマッピング, 8.6.6

ISO規格

日付書式, 9.3.2

ISO規格日付書式, 3.7.1.2, 9.3.2 ISO週番号, 9.3.2 IW書式要素, 9.3.2 IY書式要素, 9.3.2

J

Java

Unicodeデータ変換, 7.5.5

Java文字列

Unicodeでのバインドと定義, 7.5.1

JDBCドライバ

使用フォームの引数, 7.5.3

JDBC OCIドライバ

Unicode, 7.1.1

JDBCのプログラミング

Unicode, 7.5

サーバー側JDBC内部ドライバ

Unicode, 7.1.1

サーバー側JDBC Thinドライバ

Unicode, 7.1.1

JDBC Thinドライバ

Unicode, 7.1.1

L

言語

Globalization Development Kitを使用した検出, 8.7.6

言語の略称, A.1 Language and Character Set File Scanner, 12.1 言語の定義

カスタマイズ, 13.2

オーバーライド, 3.2.2

言語サポート, 1.2.1 言語

エラー・メッセージ, A.2

言語とキャラクタ・セット

LCSSCANのサポート対象, A.5

LAST_DAY SQL関数, 4.4 LASTRPTパラメータ

Database Character Set Scanner, 12.5, 12.5

LCSSCAN

エラー・メッセージ, 12.1.5

LCSSCAN, 12.1

サポート対象の言語とキャラクタ・セット, 12.1.4, A.5

LCSSCANコマンド

BEGINパラメータ, 12.1.1

ENDパラメータ, 12.1.1

例, 12.1.2

FILEパラメータ, 12.1.1

HELPパラメータ, 12.1.3

オンライン・ヘルプ, 12.1.3

RESULTSパラメータ, 12.1.1

構文, 12.1.1

長さセマンティクス, 2.2, 3.12 LENGTH SQL関数, 9.2.2, 9.2.2 SQL文のLIKE条件, 9.2.3 LIKE2 SQL条件, 9.2.3 LIKE4 SQL条件, 9.2.3 LIKE SQL条件, 9.2.3 言語ソートの定義

サポート対象, A.6

言語ソート

アクセント区別なし, 5.5

バイナリ, 5.5.2

BINARY_AI, 言語ソート

BINARY_CI, 5.5.2

大/小文字区別なし, 5.5 制御, 9.2.5.4 カスタマイズ, 13.6

発音区別記号付き文字, 13.6.1, 13.6.2

レベル, 5.3.3.1 デフォルトのリスト, A.1 パラメータ, 3.10 リスト・パラメータ, 3.8 lmsgenユーティリティ, 10.9 LOBへの外部BFILEデータのロード, 9.3.4 LOB

外部BFILEデータのロード, 9.3.4

複数言語によるドキュメントの格納, 6.5.3

ロケール, 3.2

依存性, 3.2.3

検出

Globalization Development Kit, 8.6.3

インターネット・アプリケーション

判別, 8.3.1

バリアント, 3.2.3 ロケール情報

Oracleと他の規格とのマッピング, 10.4

locale-charset-map, 8.8.1 locale-determine-rule, 8.8.4 LocaleMapperクラス, 8.7.8 locale-parameter-name, 8.8.5 LOCALTIMESTAMP SQL関数, 4.4 不可逆データ

データ・ディクショナリ, 12.8

lxegenユーティリティ, 13.3.2

M

MAXBLOCKSパラメータ

Database Character Set Scanner, 12.5

message-bundles, 8.8.6 キャラクタ・セットの移行

CSALTERスクリプト, 11.2.2

Real Application Clustersでのキャラクタ・セットの移行, 11.2.2.1 移行

CHAR列からNCHAR列へ, 11.3.3

キャラクタ・セット, 11.1

NCHARデータ型へ, 11.3

バージョン8からOracle9i以降へのNCHAR列の移行, 11.3.1

キャラクタ・セットの混在

データ消失, 11.1.2.2

通貨パラメータ, 3.9 単一言語インターネット・アプリケーション, 8.2.1 単一言語ソート

例, 5.5.3

サポート対象, A.6

月

書式要素, 3.6.1.2

名前の言語, 3.6.1.2

MONTHS_BETWEEN SQL関数, 4.4 マルチバイト・コード体系, 2.1.4.2

固定幅, 2.1.4.2

シフト・センシティブ可変幅, 2.1.4.2

可変幅, 2.1.4.2

マルチレクサー

作成, 6.5.4.1

多言語データ

列の長さの指定, 6.5.1

多言語ドキュメントの検索

索引の作成, 6.5.4

多言語インターネット・アプリケーション, 8.2.2 多言語ソート

例, 5.5.3

サポート対象, A.6

多言語サポート

制限付き, 2.6.1

無制限, 2.6.2

複数言語

データベース・スキーマの設計, 6.5

データの格納, 6.5.2

LOBへのドキュメントの格納, 6.5.3

N

N SQL関数, 7.2.5

各国語キャラクタ・セット, 2.3.8, 6.3.2, 7.2.1.1, 7.2.1.2

NCHAR列

バージョン8からOracle9i以降への移行, 11.3.1

NCHARデータ型, 7.2.1.1

抽象データ型の作成, 2.3.9

移行, 11.3

移行, 11.3.1

NCHAR SQL関数, 7.2.7 NCLOBデータ型, 7.2.1.3 NEW_TIME SQL関数, 4.4 NEXT_DAY SQL関数, 4.4 NLBデータ

トランスポータブル, 13.10

NLBファイル, 13.1.3.1 NLBファイル, 13.1

生成とインストール, 13.7

NLSカレンダ・ユーティリティ, 13.3.2 NLSパラメータ

SQL関数でのデフォルト値, 9.1.1

リスト, 3.1

設定, 3.1

SQL関数での指定, 9.1.2

SQL関数で受け入れられない, 9.1.3

NLSランタイム・ライブラリ, 1.1.1 NLS_CALENDARパラメータ, 3.7.2 NLS_CHARSET_DECL_LEN SQL関数, 9.2.4.3 NLS_CHARSET_ID SQL関数, 9.2.4.2 NLS_CHARSET_NAME SQL関数, 9.2.4.1 NLS_COMPパラメータ, 3.10.2, 9.2.5.3 NLS_CREDITパラメータ, 3.9.7 NLS_CURRENCYパラメータ, 3.9.2 NLS_DATABASE_PARAMETERSデータ・ディクショナリ・ビュー, 3.4.1 NLS_DATE_FORMAT初期化パラメータ, 4.5.1 NLS_DATE_FORMATパラメータ, 3.6.1.1 NLS_DATE_LANGUAGEパラメータ, 3.6.1.2 NLS_DEBITパラメータ, 3.9.8 NLS_DUAL_CURRENCYパラメータ, 3.9.4 NLS_INITCAP SQL関数, 5.4.11, 9.1 NLS_INSTANCE_PARAMETERSデータ・ディクショナリ・ビュー, 3.4.1 NLS_ISO_CURRENCYパラメータ, 3.9.3 NLS_LANGパラメータ, 3.2

ロケールの選択, 3.2

クライアントの設定, 3.2.4

例, 3.2.1

OCIクライアント・アプリケーション, 7.3.3

指定, 3.2.1

UNIXクライアント, 3.2.4

Windowsクライアント, 3.2.4

NLS_LANGUAGEパラメータ, 3.5.1 NLS_LENGTH_SEMANTICS初期化パラメータ, 2.2 NLS_LENGTH_SEMANTICSセッション・パラメータ, 2.2 NLS_LIST_SEPARATORパラメータ, 3.11 NLS_LOWER SQL関数, 5.4.11, 5.5, 9.1 NLS_MONETARY_CHARACTERSパラメータ, 3.9.6 NLS_NCHAR_CONV_EXCPパラメータ, 3.11.1 NLS_NUMERIC_CHARACTERSパラメータ, 3.8.2 NLS_SESSION_PARAMETERSデータ・ディクショナリ・ビュー, 3.4.1 NLS_SORTパラメータ, 3.10.1, 5.7.3.1 NLS_TERRITORYパラメータ, 3.5.2 NLS_TIMESTAMP_FORMAT初期化パラメータ, 4.5.1 NLS_TIMESTAMP_FORMATパラメータ, 3.6.2.1

パラメータ

NLS_TIMESTAMP_FORMAT, 3.6.2.2

NLS_TIMESTAMP_TZ_FORMAT初期化パラメータ, 4.5.1 NLS_UPPER SQL関数, 5.4.11, 5.5, 9.1 NLSRTL, 1.1.1 NLSSORT SQL関数, 9.1, 9.2.5

構文, 9.2.5.1

NLTファイル, 13.1 数字, エンコーディング, 2.1.2.3 数値書式, 3.8.1

SQLマスク, 9.3.3

数値パラメータ, 3.8 NUMTODSINTERVAL SQL関数, 4.4 NUMTOYMINTERVAL SQL関数, 4.4 NVARCHARデータ型

Pro*C/C++, 7.4.3

NVARCHAR2データ型, 7.2.1.2

O

廃止になったロケール・データ, A.9.4

OCI

OCIでのCLOBおよびNCLOBデータのバインドと定義, 7.3.7

SQL NCHARデータ型のバインドと定義, 7.3.5

キャラクタ・セットの設定, 10.2

SQL CHARデータ型, 7.3.4

OCIおよびUnicode, 7.1.1 OCIキャラクタ・セットの変換, 7.3.2.2

データ消失, 7.3.2.1

パフォーマンス, 7.3.2.2

OCIクライアント・アプリケーション

Unicodeキャラクタ・セットを使用, 7.3.3

OCIのデータ変換

データの拡張, 7.3.2.3

OCI_ATTR_CHARSET_FORM属性, 7.3.2.1 OCI_ATTR_MAXDATA_SIZE属性, 7.3.2.3 OCI_UTF16IDキャラクタ・セットID, 7.3.1 OCIBind()関数, 7.3.4 OCICharSetConversionIsReplacementUsed(), 10.7 OCICharSetConvert(), 10.7 OCICharsetToUnicode(), 10.7 OCIDefine()関数, 7.3.4 OCIEnvNlsCreate(), 7.3.1, 10.2 OCILobRead()関数, 7.3.7 OCILobWrite()関数, 7.3.7 OCIMessageClose(), 10.8 OCIMessageGet(), 10.8 OCIMessageOpen(), 10.8 OCIMultiByteInSizeToWideChar(), 10.5 OCIMultiByteStrCaseConversion(), 10.5 OCIMultiByteStrcat(), 10.5 OCIMultiByteStrcmp(), 10.5 OCIMultiByteStrcpy(), 10.5 OCIMultiByteStrlen(), 10.5 OCIMultiByteStrncat(), 10.5 OCIMultiByteStrncmp(), 10.5 OCIMultiByteStrncpy(), 10.5 OCIMultiByteStrnDisplayLength(), 10.5 OCIMultiByteToWideChar(), 10.5 OCINlsCharSetIdToName(), 10.3 OCINlsCharSetNameTold(), 10.3 OCINlsEnvironmentVariableGet(), 10.3 OCINlsGetInfo(), 10.3, 10.3 OCINlsNameMap(), 10.4 OCINlsNumericInfoGet(), 10.3 OCIUnicodeToCharset(), 10.7 OCIWideCharDisplayLength(), 10.5 OCIWideCharInSizeToMultiByte(), 10.5 OCIWideCharIsAlnum(), 10.6 OCIWideCharIsAlpha(), 10.6 OCIWideCharIsCntrl(), 10.6 OCIWideCharIsDigit(), 10.6 OCIWideCharIsGraph(), 10.6 OCIWideCharIsLower(), 10.6 OCIWideCharIsPrint(), 10.6 OCIWideCharIsPunct(), 10.6 OCIWideCharIsSingleByte(), 10.6 OCIWideCharIsSpace(), 10.6 OCIWideCharIsUpper(), 10.6, 10.7 OCIWideCharIsXdigit(), 10.6 OCIWideCharMultibyteLength(), 10.5 OCIWideCharStrCaseConversion(), 10.5 OCIWideCharStrcat(), 10.5 OCIWideCharStrchr(), 10.5 OCIWideCharStrcmp(), 10.5 OCIWideCharStrcpy(), 10.5 OCIWideCharStrlen(), 10.5 OCIWideCharStrncat(), 10.5 OCIWideCharStrncmp(), 10.5 OCIWideCharStrncpy(), 10.5 OCIWideCharStrrchr(), 10.5 OCIWideCharToLower(), 10.5 OCIWideCharToMultiByte(), 10.5 OCIWideCharToUpper(), 10.5 ODBC Unicodeアプリケーション, 7.6.4 OLE DB Unicodeデータ型, 7.6.5 表のオンライン再定義

CHARからNCHARへの移行, 11.3.3, 11.3.3.2

オペレーティング・システム

アプリケーションとのキャラクタ・セットの互換性, 2.3.2

ORA_DST_AFFECTED SQL関数, 4.4 ORA_DST_CONVERT SQL関数, 4.4 ORA_DST_ERROR SQL関数, 4.4 ORA_NLS10環境変数, 1.1.1 ORA_SDTZ環境変数, 4.5.2, 4.10 ORA_TZFILE環境変数, 4.5.2 Oracle Call InterfaceとUnicode, 7.1.1 Oracle Data Provide for .NETとUnicode, 7.1.1 Oracle Data Pumpおよびキャラクタ・セットの変換, 11.1.2.3 Oracle言語およびキャラクタ・セット検出Javaクラス, 8.7.6 Oracle Locale Builder

カレンダ書式の選択, 13.3

通貨書式の選択, 13.3

日付および時刻書式の選択, 13.3

コード・チャートの表示, 13.4

「既存の定義」ダイアログ・ボックス, 13.1.3.1

フォント, 13.1.1.1, 13.1.1.2

ファイルを開くダイアログ・ボックス, 13.1.3.4

「NLTのプレビュー」画面, 13.1.3.3

ロケール・オブジェクト名に関する制限事項, 13.2

「セッション・ログ」ダイアログ・ボックス, 13.1.3.2

起動, 13.1.2

Oracle ODBCドライバとUnicode, 7.1.1 Oracle OLE DBドライバとUnicode, 7.1.1 Oracle Pro*C/C++とUnicode, 7.1.1 Oracle Real Application Clusters

データベース・キャラクタ・セットの移行, 11.2.2.1

oracle.i18n.lcsdパッケージ, 8.9.1 oracle.i18n.netパッケージ, 8.9.2 oracle.i18n.servletパッケージ, 8.9.3 oracle.i18n.textパッケージ, 8.9.4 oracle.i18n.utilパッケージ, 8.9.5 oracle.sql.CHARクラス

キャラクタ・セットの変換, 7.5.6.1

getString()メソッド, 7.5.6.1

getStringWithReplacement()メソッド, 7.5.6.1

toString()メソッド, 7.5.6.1

ORDER BY句, 9.2.5.4 オペレーティング・システムのローカルのタイム・ゾーンOS_TZ, 4.10 言語定義と地域定義のオーバーライド, 3.2.2

P

page-charset, 8.8.2

パラメータ

BLANK_TRIMMING, 11.1.1.1

カレンダ, 3.7

キャラクタ・セットの変換, 3.11

言語ソート, 3.10

設定方法, 3.1

通貨, 3.9

NLS_CALENDAR, 3.7.2

NLS_COMP, 3.10.2

NLS_CREDIT, 3.9.7

NLS_CURRENCY, 3.9.2

NLS_DATE_FORMAT, 3.6.1.1

NLS_DATE_LANGUAGE, 3.6.1.2

NLS_DEBIT, 3.9.8

NLS_DUAL_CURRENCY, 3.9.4

NLS_ISO_CURRENCY, 3.9.3

NLS_LANG, 3.2

NLS_LANGUAGE, 3.5.1

NLS_LIST_SEPARATOR, 3.11

NLS_MONETARY_CHARACTERS, 3.9.6

NLS_NCHAR_CONV_EXCP, 3.11.1

NLS_NUMERIC_CHARACTERS, 3.8.2

NLS_SORT, 3.10.1

NLS_TERRITORY, 3.5.2

NLS_TIMESTAMP_FORMAT, 3.6.2.1

数値, 3.8

設定, 3.1

日付と時間, 3.6

タイム・ゾーン, 3.6.2.2

パーティション

索引, 9.2.5.3

表, 9.2.5.3

パフォーマンス

各国語キャラクタ・セットの選択, 2.3.4

OCIのUnicodeキャラクタ・セット変換時, 7.3.2.2

表音的記述法, エンコーディング, 2.1.2.1 PL/SQLおよびSQLとUnicode, 7.1.1 PRESERVEパラメータ

Database Character Set Scanner, 12.5

1次レベル・ソート, 5.3.3.1 Private Use Area, 13.5.3 Pro*C/C++

データ変換, 7.4.1

NVARCHARデータ型, 7.4.3

UVARCHARデータ型, 7.4.4

VARCHARデータ型, 7.4.2

句読点, エンコーディング, 2.1.2.3

Q

QUERYパラメータ

Database Character Set Scanner, 12.5

R

REGEXP SQL関数, 5.9

正規表現

文字クラス, 5.9.3

文字範囲, 5.9.1

照合要素デリミタ, 5.9.2

同値化クラス, 5.9.4

例, 5.9.5

多言語環境, 5.9

置換文字

CONVERT SQL関数, 9.2.1

制限付き多言語サポート, 2.6.1, 2.6.1 制限事項

データの切捨て, 11.1.1.1

パスワード, 11.1.1.1

エクスポート時の空白埋込み, 11.1.1.1

ユーザー名, 11.1.1.1

逆2次ソート, 5.4.7 ROUND (date) SQL関数, 4.4 RPAD SQL関数, 7.2.6

S

スキャン・モード

Database Character Set Scanner, 12.3

全データベース・スキャン, 12.3.1

単一表のスキャン, 12.3.3

ユーザー表のスキャン, 12.3.2

scan.errファイル, 12.7 scan.outファイル, 12.6.1.1, 12.6.2.1, 12.6.3.1, 12.6.3.2, 12.6.4.1 scan.txtファイル, 12.7 多言語ドキュメントの検索, 6.5.4 文字列の検索, 5.8 2次レベル・ソート, 5.3.3.2 セッション・パラメータ

ERROR_ON_OVERLAP, 4.5.3

セッション・タイム・ゾーン, 4.10 SESSIONTIMEZONE SQL関数, 4.4 setFormOfUse()メソッド, 7.5.3 シフト・センシティブ可変幅マルチバイト・コード体系, 2.1.4.2 シングルバイト・コード体系, 2.1.4.1 ソート

逆2次, 5.4.7

非デフォルトの言語ソートの指定, 3.10.1, 3.10.2

source_char_setパラメータ, A.4.6 空白埋込み

エクスポート時, 11.1.1.1

特殊組合せ文字, 5.4.3, 5.4.10 特殊文字, 5.4.4, 5.4.9 特殊な小文字, 5.4.12 特殊な大文字, 5.4.11 SQL CHARデータ型, 2.3

OCI, 7.3.4

SQL条件

LIKE2, 9.2.3

LIKE4, 9.2.3

LIKEC, 9.2.3

SQL関数

ORA_DST_AFFECTED, 4.4

ORA_DST_CONVERT, 4.4

ORA_DST_ERROR, 4.4

SQL関数

ADD_MONTHS, 4.4

CONVERT, 9.2.1

CURRENT_DATE, 4.4

CURRENT_TIMESTAMP, 4.4

データ型変換, 7.2.5

DBTIMEZONE, 4.4

NLSパラメータのデフォルト値, 9.1.1

EXTRACT (datetime), 4.4

FROM_TZ, 4.4

INSTR, 7.2.6, 9.2.2, 9.2.2

LAST_DAY, 4.4

LENGTH, 9.2.2, 9.2.2

LOCALTIMESTAMP, 4.4

MONTHS_BETWEEN, 4.4

N, 7.2.5

NCHR, 7.2.7

NEW_TIME, 4.4

NEXT_DAY, 4.4

NLS_CHARSET_DECL_LEN, 9.2.4.3

NLS_CHARSET_ID, 9.2.4.2

NLS_CHARSET_NAME, 9.2.4.1

NLS_INITCAP, 5.4.11, 9.1

NLS_LOWER, 5.4.11, 5.5, 9.1

NLS_UPPER, 5.4.11, 5.5, 9.1

NLSSORT, 9.1, 9.2.5

NUMTODSINTERVAL, 4.4

NUMTOYMINTERVAL, 4.4

ROUND (date), 4.4

RPAD, 7.2.6

SESSIONTIMEZONE, 4.4

NLSパラメータの指定, 9.1.2

SUBSTR, 9.2.2, 9.2.2

SUBSTR2, 9.2.2

SUBSTR4, 9.2.2

SUBSTRB, 9.2.2

SUBSTRC, 9.2.2

SYS_EXTRACT_UTC, 4.4

SYSDATE, 4.4

SYSTIMESTAMP, 4.4

TO_CHAR, 9.1

TO_CHAR (datetime), 4.4

TO_DATE, 7.2.5, 9.1

TO_DSINTERVAL, 4.4

TO_NCHAR, 7.2.5

TO_NUMBER, 9.1

TO_TIMESTAMP, 4.4

TO_TIMESTAMP_TZ, 4.4

TO_YMINTERVAL, 4.4

TRUNC (date), 4.4

TZ_OFFSET, 4.4

受け入れられないNLSパラメータ, 9.1.3

UNISTR, 7.2.7

SQL NCHARデータ型

OCIでのバインドと定義, 7.3.5

SQL文

LIKE条件, 9.2.3

完全なスーパーセット, 6.2.2.1 文字列の比較

WHERE句, 9.2.5.2

文字列リテラル

Unicode, 7.2.7

OCIを使用した文字列操作, 10.5 文字列

検索, 5.8

SUBSTR SQL関数, 9.2.2 SUBSTR SQL関数, 9.2.2

SUBSTR, 9.2.2

SUBSTR2, 9.2.2

SUBSTR4, 9.2.2

SUBSTRB, 9.2.2

SUBSTRC, 9.2.2

SUBSTR4 SQL関数, 9.2.2 SUBSTRB SQL関数, 9.2.2 SUBSTRC SQL関数, 9.2.2 スーパーセット, 完全, 6.2.2.1 スーパーセットとサブセット, A.4.7 補助文字, 5.3.2, 6.2.1

言語ソートのサポート, A.6

サポート対象のデータ型, 2.3.9 サポートしている地域, A.3 SUPPRESSパラメータ

Database Character Set Scanner, 12.5

サロゲート・ペア, 6.2.1 表音文字セット, 2.1.2.2 記号, エンコーディング, 2.1.2.3 SYS_EXTRACT_UTC SQL関数, 4.4 SYSDATE SQL関数, 4.4

セッションのタイム・ゾーンの影響, 4.10

SYSTIMESTAMP SQL関数, 4.4

T

TABLEパラメータ

Database Character Set Scanner, 12.5

表

パーティション, 9.2.5.3

地域

依存性, 3.2.3

地域の定義, 3.5.2

カスタマイズ, 13.3

オーバーライド, 3.2.2

サポートしている地域, 1.2.2, A.3 地域のバリアント, 3.2.3 3次レベル・ソート, 5.3.3.3 タイ語とラオ語の文字の再配列, 5.4.8 チルド, 7.5.7.1 日付および時間を指定するパラメータ, 3.6 タイム・ゾーン

略称, 4.6

データ・ソース, 4.6

データベース, 4.9

SYSDATE SQL関数への影響, 4.10

環境変数, 4.5.2

ファイル, 4.6

ネーミング, 4.6

パラメータ, 3.6.2.2

セッション, 4.10

タイム・ゾーン・ファイル

選択, 4.6

デフォルト, 4.6

アップグレードの手順, 4.7.3

アップグレード, 4.7

タイム・ゾーン

変換, 4.11

カスタマイズ, 13.3.1

タイム・ゾーン・ファイルのアップグレード, 4.7

TIMESTAMPデータ型, 4.2.1.2

使用する状況, 4.2.1.6

TIMESTAMPデータ型

選択, 4.2.1.6

タイムスタンプ書式, 3.6.2.1 TIMESTAMP WITH LOCAL TIME ZONEデータ型, 4.2.1.4

使用する状況, 4.2.1.6

TIMESTAMP WITH TIME ZONEデータ型, 4.2.1.3

使用する状況, 4.2.1.6

TO_CHAR (datetime) SQL関数, 4.4 TO_CHAR SQL関数, 9.1

デフォルトの日付書式, 3.6.1.1, 4.5.1

書式マスク, 9.3.1

グループ・セパレータ, 3.8.2

日付の言語, 3.6.1.2

曜日と月の表記, 3.6.1.2

TO_DATE SQL関数, 7.2.5, 9.1

デフォルトの日付書式, 3.6.1.1, 4.5.1

書式マスク, 9.3.1

日付の言語, 3.6.1.2

曜日と月の表記, 3.6.1.2

TO_DSINTERVAL SQL関数, 4.4 TO_NCHAR SQL関数, 7.2.5 TO_NUMBER SQL関数, 9.1

書式マスク, 9.3.1

TO_TIMESTAMP SQL関数, 4.4 TO_TIMESTAMP_TZ SQL関数, 4.4 TO_YMINTERVAL SQL関数, 4.4 TOCHARパラメータ

Database Character Set Scanner, 12.5

toString()メソッド, 7.5.6.1 転送可能なNLBデータ, 13.10 TRUNC (date) SQL関数, 4.4 TZ_OFFSET SQL関数, 4.4 TZABBREV, 4.6 TZNAME, 4.6

U

UCS-2エンコーディング, 6.2.2.2

Unicode, 6.1

Java文字列のバインドと定義, 7.5.1

文字コードの割当て, B.1

OCIクライアントとデータベース・サーバーの間のキャラクタ・セット変換, 7.3.2

UTF-16文字のコード範囲, B.1

UTF-8文字のコード範囲, B.1

Javaでのデータ変換, 7.5.5

エンコーディング, 6.2.2

フォント, 13.1.1

JDBC OCIドライバ, 7.1.1

JDBCのプログラミング, 7.5

サーバー側JDBC内部ドライバ, 7.1.1

サーバー側JDBC Thinドライバ, 7.1.1

JDBC Thinドライバ, 7.1.1

モード, 7.3.1

ODBCとOLE DBのプログラミング, 7.6

Oracle Call Interface, 7.1.1

Oracle Data Provider for .NET, 7.1.1

Oracle ODBCドライバ, 7.1.1

Oracle OLE DBドライバ, 7.1.1

Oracle Pro*C/C++, 7.1.1

Oracleでのサポート, 6.2.3

Javaを使用したXMLストリームの解析, 7.7.3

PL/SQLとSQL, 7.1.1

Private Use Area, 13.5.3

プログラミング, 7.1

Javaを使用したXMLファイルの読取り, 7.7.2

文字列リテラル, 7.2.7

UCS-2エンコーディング, 6.2.2.2

UTF-16エンコーディング, 6.2.2.3

UTF-8エンコーディング, 6.2.2.1

Javaを使用したXMLファイルの作成, 7.7.1

XMLプログラミング, 7.7

Unicodeデータベース, 6.3.1

事例, 6.4

キャラクタ・セットの選択, 6.3.4

Unicodeデータ型との併用(事例), 6.4

使用する状況, 6.3.3.1

Unicodeデータ型, 6.3.2

事例, 6.4

各国語キャラクタ・セットの選択, 6.3.4

Unicodeデータベースとの併用(事例), 6.4

使用する状況, 6.3.3.2

UNISTR SQL関数, 7.2.7 無制限多言語サポート, 2.6.2 アップグレード

夏時間, 4.5.4

url-rewrite-rule, 8.8.7 US7ASCII

スーパーセット, A.4.7

USERパラメータ

Database Character Set Scanner, 12.5

ユーザー定義文字, 13.5.1

キャラクタ・セット定義への追加, 13.5.6

キャラクタ・セット間でのクロス・リファレンス, 13.5.4

USERIDパラメータ

Database Character Set Scanner, 12.5

UTC, 4.2.1.3, 4.2.1.4 UTF-16エンコーディング, 6.2.2.3, B.2 UTF8キャラクタ・セット, 6.3.1, A.4.5 UTF-8エンコーディング, 6.2.2.1, B.3 UTFEキャラクタ・セット, 6.2.3, 6.3.1, A.4.5 UTL_FILEパッケージ, NCHARとともに使用, 7.2.9 UTL_I18N PL/SQLパッケージ, 8.10 UTL_LMS PL/SQLパッケージ, 8.10 UVARCHARデータ型

Pro*C/C++, 7.4.4

V

V$NLS_PARAMETERS動的パフォーマンス・ビュー, 3.4.2

V$NLS_VALID_VALUES動的パフォーマンス・ビュー, 3.4.2

VARCHARデータ型

Pro*C/C++, 7.4.2

可変幅マルチバイト・コード体系, 2.1.4.2 バージョン8のNCHAR列

Oracle9i以降への移行, 11.3.1

W

波形のダッシュ, 7.5.7.1

WHERE句

文字列の比較, 9.2.5.2

X

XML

Javaを使用してUnicodeで解析, 7.7.3

Javaを使用してUnicodeで読取り, 7.7.2

Javaを使用してUnicodeで作成, 7.7.1

XMLプログラミング

Unicode, 7.7

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2013, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。