Oracle® Database

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

12cリリース1 (12.1)

B71319-06(原本部品番号:E41669-12)

2017年1月

Oracle Databaseグローバリゼーション・サポート・ガイド, 12cリリース1 (12.1)

B71319-06

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

原本著者: Rajesh Bhatiya

原本協力者: 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, Sergiusz Wolicki, Simon Wong, Michael Yau, Jianping Yang, Qin Yu, Tim Yu, Weiran Zhang, Yan Zhu

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

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

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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 Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

最新版の『Oracle Databaseグローバリゼーション・サポート・ガイド』における変更点

- Oracle Database 12cリリース1 (12.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 Databaseの照合機能の概要

- バイナリ照合の使用

- 言語照合の使用

- 単一言語照合

- 多言語照合

- 多言語照合レベル

- 1次レベル照合

- 2次レベル照合

- 3次レベル照合

- UCA照合

- UCA比較レベル

- 1次レベル

- 2次レベル

- 3次レベル

- 4次レベル

- UCA照合パラメータ

- 言語照合の特徴

- ベース文字

- 無視可能文字

- 1次無視可能文字

- 2次無視可能文字

- 3次無視可能文字

- 可変文字と可変重み付け

- 短縮文字

- 拡張文字

- 状況依存文字

- 標準的な同値化

- 逆2次ソート

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

- 特殊文字

- 特殊組合せ文字

- 特殊な大文字

- 特殊な小文字

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

- 例: 大/小文字およびアクセントを区別しない照合

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

- 例: 言語照合

- 言語比較の実行

- 照合キー

- 言語比較の精度の制限

- 例: 言語比較

- 言語索引の使用

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

- 複数言語の言語索引

- 言語索引の使用要件

- NLS_SORTを適切に設定

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

- 適切なブロック・サイズでの表領域の使用

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

- 言語の文字列検索

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

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

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

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

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

- 例: 正規表現

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

- Unicode規格とは

- Unicode規格の特長

- コード・ポイントと補助文字

- Unicodeエンコード形式

- UTF-8エンコード形式

- UTF-16エンコード形式

- UCS-2エンコード形式

- UTF-32エンコード形式

- CESU-8エンコード形式

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

- Oracle Databaseでの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

- LCSScan

- LCSScanコマンドの構文

- LCSScanの使用例

- 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

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

- Database Migration Assistant for Unicodeを使用した文字データの移行

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

- データベース・キャラクタ・セットのメタデータの修復

- 例: CSREPAIRの使用

- Language and Character Set File Scanner

- LCSSCANコマンドの構文

- 例: LCSSCANコマンドの使用

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

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

- LCSSCANエラー・メッセージ

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

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

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

- Windowsでのフォント構成

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

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

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

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

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

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

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

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

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

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

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

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

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

- Unicode 6.2のPrivate Use Area

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

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

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

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

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

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

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

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

- 同一プラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

- 別のプラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

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

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

A ロケール・データ

- 言語

- 翻訳済メッセージ

- 地域

- キャラクタ・セット

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

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

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

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

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

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

- バイナリ・サブセット/スーパーセットのペア

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

- 言語ソート

- 暦法

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

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

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

- 廃止された地域

- 廃止された言語

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

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

- Oracle Databaseの言語および地域定義ファイルの更新

B Unicode文字コードの割当て

- Unicodeのコード範囲

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

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

用語集

索引

はじめに

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

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

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

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

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

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

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

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

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

- Unicodeの使用

このマニュアルを使用するには、リレーショナル・データベースの概念、Oracle Databaseの基本概念、および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サンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

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

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

最新版の『Oracle Databaseグローバリゼーション・サポート・ガイド』における変更点

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

- Oracle Database 12cリリース1 (12.1)での変更点

Oracle Database 12cリリース1 (12.1)での変更点

『Oracle Databaseグローバリゼーション・サポート・ガイド』に記載されている、Oracle Database 12cリリース1 (12.1)における変更点は次のとおりです。

新機能

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

- 新しいロケールのサポート
「ロケール・データ」を参照してください。

- Unicode照合アルゴリズムのサポート
「言語ソートと照合」を参照してください。

- Database Migration Assistant for Unicode(DMU)
直感的な操作が可能な、ユーザーに親しみやすいGUIを装備した製品であり、そのインタフェースを介して手作業による手間を大幅に減らし、移行作業を正確かつ効率よく実行して、移行プロセスを効率化できるようになっています。これは、CSSCANユーティリティとCSALTERユーティリティの後継であり、データベースのUnicodeへの移行を支援するツールです。

詳細は、「Database Migration Assistant for Unicodeを使用した文字データの移行」と『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

サポート対象外機能

このマニュアルで前述した機能の一部(CSSCANユーティリティとCSALTERユーティリティ)は、Oracle Database 12cリリース1 (12.1)ではサポートされなくなりました。サポートされなくなった機能の一覧は、『Oracle Databaseアップグレード・ガイド』を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ロケール固有のデータは、ORACLE_HOME/nls/dataディレクトリに格納されます。ORA_NLS10環境変数は、複数のOracle Databaseホームが、同じロケール固有データ・ファイルを共有する場合のように、ロケール固有データ・ファイルに応じて、デフォルトのディレクトリの場所を変更する必要がある場合にのみ定義するようにしてください。

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

関連項目:

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

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

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環境を同期させます。

関連項目:

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

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

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

Unicode(エンコードされたユニバーサル・キャラクタ・セット)では、1つのキャラクタ・セットを使用して任意の言語の情報を格納できます。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。データベース・キャラクタ・セットとしてAL32UTF8を使用することをお薦めします。AL32UTF8は、Unicode規格のUTF-8エンコーディング形式に準拠しています。

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

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

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

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

Unicode環境に移行しやすくなるように、Database Migration Assistant for Unicode(DMU)が用意されています。DMUは、直感的な操作が可能な、ユーザーに親しみやすいGUIを装備しており、そのインタフェースを介して作業負荷を軽減し、移行上の問題をすべて解決して、移行プロセス全体を効率化できるようになっており、また、データ変換も正確に効率よく行えるようになっています。DMUは従来のデータ移行方式と比べて様々な点で優れており、その例を次に示します。

- ワークフローに沿って作業できるようになっています。

- データのクレンジングの実行時に発生する障害などの特定の問題をどのように対処すればよいかを提言します。

- データの変換方法を選択できます。

- 進行状況を確認できます。

関連項目:

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

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

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

- 『Oracle Database Migration Assistant for Unicodeガイド』

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

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

- 言語サポート

- 地域サポート

- 日付と時刻の書式

- 通貨と数値の書式

- 暦法

- 言語ソート

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

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

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

- Unicodeのサポート

言語サポート

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

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

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

関連項目:

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

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

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

地域サポート

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

関連項目:

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

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

日付と時刻の書式

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

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

関連項目:

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

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

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

通貨と数値の書式

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

関連項目:

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

暦法

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

- Gregorian(グレゴリオ暦)

- Japanese Imperial(日本の元号暦)

- ROC Official(台湾暦)

- Thai Buddha(タイ仏教暦)

- Persian(ペルシャ暦)

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

- Arabic Hijrah(イスラム歴)

- Ethiopian(エチオピア歴)

関連項目:

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

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

言語ソート

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

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

関連項目:

言語ソートと照合

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

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

関連項目:

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

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

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

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

関連項目:

「長さセマンティクス」

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

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

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

関連項目:

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

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

Unicodeのサポート

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

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

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

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

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

関連項目:

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

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

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

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

- 長さセマンティクス

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

- マルチテナント・コンテナ・データベースのデータベース・キャラクタ・セットの選択

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

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

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

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

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

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

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

- エンコードされる文字

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

- 文字のエンコード方法

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

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

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

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

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

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

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

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

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

文字の集まり(アルファベット文字、表意文字、記号、句読点および制御文字など)は、キャラクタ・セットとしてエンコードできます。エンコードされたキャラクタ・セットは、キャラクタ・セット内のそれぞれの文字を表す一意の数値コードに対応しています。数値コードはコード・ポイントまたはエンコーディング値と呼ばれます。次の表に、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 Databaseキャラクタ・セットで表示可能で、どのプラットフォームにもトランスポートできます。

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

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

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

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

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

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

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

関連項目:

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

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

- CHR 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つで、現代の主要なスクリプトのほとんどを包含しています。バージョン6.2の時点で、Unicode規格は、110,000以上の文字をエンコードします。

関連項目:

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 Databaseのキャラクタ・セット名には、次のネーミング規則が使用されます。

<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は、このネーミング規則の例外です。

次の表に、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

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

データベース間のキャラクタ・セットの変換または互換性について説明する際、Oracleのドキュメントでは、2つのキャラクタ・セットの関係を説明するために、スーパーセット、サブセット、バイナリ・スーパーセットまたはバイナリ・サブセットという用語を使用します。「バイナリ」が付かないサブセットおよびスーパーセットという用語は、2つのOracleキャラクタ・セットのキャラクタ・リポジトリ、つまり各キャラクタ・セットでサポート(エンコード)される一連のキャラクタに関連します。定義としては、キャラクタ・セットBがサポートするすべてのキャラクタをキャラクタ・セットAがサポートしている場合、AはBのスーパーセットになります。キャラクタ・セットAがキャラクタ・セットBのスーパーセットの場合、BはAのサブセットです。

バイナリ・サブセットおよびバイナリ・スーパーセットという用語は、前述のサブセット/スーパーセットの関係を制限したもので、2つのキャラクタ・セットのキャラクタのバイナリ表現(バイナリ・コード)に条件が付加されます。定義としては、キャラクタ・セットBがサポートするすべてのキャラクタをキャラクタ・セットAがサポートし、これらのすべてのキャラクタのAとBで同じバイナリ表現を持つ場合、AはBのバイナリ・スーパーセットになります。キャラクタ・セットAがキャラクタ・セットBのバイナリ・スーパーセットの場合、BはAのバイナリ・サブセットです。

キャラクタ・セットAがキャラクタ・セットBのバイナリ・スーパーセットの場合、Bでエンコードされたテキストの値は、同時にAでも有効になり、キャラクタ・セット変換の必要はありません。AがBのバイナリ・スーパーセットでない場合、Bでエンコードされたテキストの値は、データが失われることなくAで表示できますが、バイナリ表現を変換するには、キャラクタ・セット変換が必要な場合があります。

Oracle Databaseでは、そのキャラクタ・セットのすべてのサブセット/スーパーセットのペアのリストを保持するわけではなく、トランスポータブル表領域やプラガブル・データベースの互換性を確認するときなど、様々な状況で認識されるバイナリ・サブセット/スーパーセットのペアのリストを保持します。表A-11および表A-12では、Oracle Databaseで認識されるバイナリ・サブセット/スーパーセットの組を示します

長さセマンティクス

シングルバイト・キャラクタ・セットの場合、文字列のバイト数と文字数は同じです。マルチバイト・キャラクタ・セットの場合は、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でもUTF8でも、last_nameに最大10個のUnicodeコード・ポイントを保持できます。NCHARのキャラクタ・セットがAL16UTF16の場合は、保持する10個のコードポイントが最大で20バイトの領域を占有します。NCHARのキャラクタ・セットがUTF8の場合は、最大で30バイトの領域を占有します。

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

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

関連項目:

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

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

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

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

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

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

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

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

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

- Oracle Locale Builderを使用します。

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

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

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

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

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

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

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

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

関連項目:

- 「UCS-2エンコード形式」

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

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

- ロケール・データ

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

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

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

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

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

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

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

- データ消失の可能性

- オーバーヘッドの増加

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

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

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

関連項目:

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

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

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

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

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

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

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

関連項目:

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

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

各国語キャラクタ・セットとは、Unicodeデータベース・キャラクタ・セットがないデータベースにUnicodeの文字データを格納するための代替キャラクタ・セットです。各国語キャラクタ・セットを選択する別の理由は、それぞれの文字コード体系が持つ性質が、幅広い文字処理操作に向いているということです。

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

Unicode文字データを格納する場合は、AL32UTF8データベースでCHAR、VARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。キャラクタ・セットがAL32UTF8以外のデータベースを使用する必要がある場合にのみ、NCHAR、NVARCHAR2、およびNCLOBの各SQLデータ型の使用を検討するようにしてください。

関連項目:

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オブジェクト・リレーショナル開発者ガイド』を参照してください

マルチテナント・コンテナ・データベースのデータベース・キャラクタ・セットの選択

Oracle Database 12cでは、マルチテナント・コンテナ・データベース(CDB)のすべてのコンテナに、同じデータベース・キャラクタ・セットと同じ各国語キャラクタ・セットがある必要があります。つまり、CDBのすべてのプラガブル・データベース(PDB)には、CDBのルート・コンテナと同じキャラクタ・セットがある必要があります。ルート・コンテナのキャラクタ・セットは、CDB全体のキャラクタ・セットとみなされます。

単一のCDBに複数のデータベースをプラグインして統合できます。これらのデータベースは、他のCDBから切り離された従来の非CDBまたはPDBになります。これらの状況は、プラグインされているデータベースのデータベース・キャラクタ・セット、すなわち新しいPDBに応じて発生します。

- キャラクタ・セットは、CDBのデータベース・キャラクタ・セットと同じです。この場合、プラグイン操作は成功します(データベース・キャラクタ・セットに関するかぎり)。

- キャラクタ・セットは、CDBのデータベース・キャラクタ・セットとプラグイン互換です。プラグイン互換とは、それがCDBのキャラクタ・セットのバイナリ・サブセットであり、両方がシングルバイトまたはマルチバイトであることを意味します。この場合、新しいPDBのデータベース・キャラクタ・セットは、最初に開いた時点でCDBのデータベース・キャラクタ・セットに自動的に変更され、プラグイン操作が成功します。

- キャラクタ・セットは、CDBのデータベース・キャラクタ・セットとプラグイン互換ではありません。この場合、新しいPDBは、管理タスク用に制限モードでのみ開くことができ、本番用に使用することはできません。新しいPDBのデータベース・キャラクタ・セットをCDBのキャラクタ・セットに移行できるツールがない場合、新しいPDBは使用できません。

関連項目:

- キャラクタ・セットのバイナリ・サブセットについては、「サブセットとスーパーセット」を参照してください

新しいPDBをプラグインすると、新しいPDBの各国語キャラクタセットに応じて2つの状況が発生します。

- キャラクタ・セットは、CDBの各国語キャラクタ・セットと同じです。この場合、プラグイン操作は成功します(各国語キャラクタ・セットに関するかぎり)。

- キャラクタ・セットは、CDBの各国語キャラクタ・セットと同じではありません。この場合、新しいPDBは、管理タスク用に制限モードでのみ開くことができ、本番用に使用することはできません。新しいPDBの各国語キャラクタ・セットをCDBのキャラクタ・セットに移行できるツールがない場合、新しいPDBは使用できません。

これらの制限により、このCDBのキャラクタ・セットを選択する際に、指定されたCDBにプラグインするデータベースのキャラクタ・セットを考慮してください。次が推奨されます。

- 新しいすべてのデプロイメントで、すべてのPDBが空で作成される場合は、CDBデータベース・キャラクタ・セットにAL32UTF8、CDB各国語キャラクタ・セットにAL16UTF16を強くお薦めします。

- 統合前に既存のデータベースをAL32UTF8に移行できる場合はそのようにし、必要に応じて、1つ以上のAL32UTF8 CDBに統合することをお薦めします。Oracle Database Migration Assistant for Unicodeを使用すると、非CDBをAL32UTF8に移行できます。

- 統合前に既存のデータベースを移行できない場合は、プラグイン互換のデータベース・キャラクタ・セットでそれらを各セットにパーティション化し、適切なスーパーセット・キャラクタ・セットで各セットを個別のCDBにプラグインする必要があります。たとえば、統合するデータベースがUS7ASCII、WE8ISO8859P1、WE8MSWIN1252、WE8ISO8859P15、JA16SJISTILDE、JA16EUC、KO16KSC5601、KO16MSWIN949、UTF8およびAL32UTF8の場合は、次のように統合する必要があります。

- US7ASCII、WE8ISO8859P1およびWE8MSWIN1252をWE8MSWIN1252 CDB

- WE8ISO8859P15をWE8ISO8859P15 CDB

- JA16SJISTILDEをJA16SJISTILDE CDB

- JA16EUCをJA16EUC CDB

- KO16KSC5601、KO16MSWIN949をKO16MSWIN949 CDB

- UTF8およびAL32UTF8をAL32UTF8 CDB

注意:

UTF8およびAL32UTF8の最大文字幅が異なる場合(文字ごとに3バイトと4バイト)、プラグイン操作中のUTF8からAL32UTF8の自動変更により、文字長セマンティクスで列の暗黙的な最大バイト幅が変更されます。ファンクション索引、仮想列、ビットマップ結合索引、ドメイン索引、パーティション化キー、サブパーティション化キー、またはクラスタ・キーがこれらの列に定義されている場合、この変更が失敗することがあります。この操作は、文字長セマンティクス列が索引キーの一部で、キャラクタ・セットの変更後に、索引キーがサイズの制限を超えた場合(索引ブロック・サイズの約70%)にも失敗することがあります。データベースがプラグインされる前に、問題なっているすべてのオブジェクトをデータベースから削除する必要があります。この操作後に、オブジェクトを再作成できます。

関連項目:

- CDBおよびPDBの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

- データベースのキャラクタ・セットをUnicodeに移行する方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

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

データベースの作成後に、データベース・キャラクタ・セットの変更が必要になる場合があります。たとえば、使用しているデータベースでサポートする必要がある言語数が増加したため、UnicodeのAL32UTF8に移行することがあります。

データベース内の文字型のデータをUnicodeに変換する必要があるため、ほとんどのケースで、データベース・キャラクタ・セットをAL32UTF8に変更する際に問題が発生します。たとえば、CHAR列とVARCHAR2列のデータが、宣言された列の長さよりも長くなる可能性があります。文字データをUnicodeに変換する際に、その中に無効な文字が含まれていると、データが失われる可能性があります。

データベース・キャラクタ・セットを変更する前に、問題点をすべて洗い出し、データ移行の計画を十分に練ることが重要です。データベース・キャラクタ・セットをAL32UTF8に変更する場合は、Database Migration Assistant for Unicodeを使用することをお薦めします。

関連項目:

キャラクタ・セットの変更方法の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多言語サポートが必要な場合は、サーバーのデータベース・キャラクタ・セットにUnicode AL32UTF8を使用します。

注意:
Oracle Database 12cリリース2移行では、データベースの作成にOracle Universal InstallerまたはDatabase Configuration Assistantを使用する場合、デフォルトのデータベース・キャラクタ・セットはUnicode AL32UTF8です。

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文字に変換されない場合があることを意味します。

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

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

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

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

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

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

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

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

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

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

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

関連項目:

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関数の有効範囲は示されていません。この表では、有効範囲に次の値を示します。

- I = 初期化パラメータ・ファイル

- E = 環境変数

- A = ALTER SESSION

表3-2 NLSパラメータ

パラメータ

説明

デフォルト

有効範囲

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の値の指定

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

- ロケールのバリアント

関連項目:

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

- プラットフォームに必要な追加のグローバリゼーション設定の詳細は、ご使用のオペレーティング・システムのマニュアルを参照してください。

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を異なる値に設定した場合の動作を示します。

関連項目:

ALTER SESSION文の使用方法の詳細は、「セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド」を参照してください

例3-3 NLS_LANGUAGE=ITALIAN

ALTER SESSION文を使用して、NLS_LANGUAGEをイタリア語に設定します。

SQL> 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
...

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

例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文を発行します。

SQL> ALTER SESSION SET NLS_TERRITORY = France;

次の例に、NLS_TERRITORYとNLS_LANGUAGEを異なる値に設定した場合の動作を示します。

関連項目:

ALTER SESSION文の使用方法の詳細は、「セッション中のNLS_LANGUAGEおよびNLS_TERRITORYのデフォルト値のオーバーライド」を参照してください

例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文を使用して地域をドイツに変更します。

SQL> 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

通貨記号が$から€.に変更されていることに注意してください。基礎となるデータは同じであるため、数値に変更はありません。

例3-7 NLS_LANGUAGE=GERMAN、NLS_TERRITORY=GERMANY

ALTER SESSION文を使用して言語をドイツ語に変更します。

SQL> ALTER SESSION SET NLS_LANGUAGE = German;
Session 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文を使用して地域をアメリカに変更します。

SQL> ALTER SESSION SET NLS_TERRITORY = America;
Session 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では、日付と時刻の表示を制御できます。この項の内容は、次のとおりです。

- 日付書式

- 時刻書式

日付書式

Oracle Databaseの異なる日付書式を、次の表で説明します。

表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'

- 初期化パラメータ・ファイル内で値を変更してから、インスタンスを再起動します。

- 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言語リファレンス』を参照してください。

例3-11 ローマ数字を表示する日付書式の設定

デフォルトの日付書式を設定して、月をローマ数字で表示するには、初期化パラメータ・ファイルに次の行を加えます。

NLS_DATE_FORMAT = "DD RM YYYY"

次のSELECT文を入力します。

SQL> 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のデフォルト値は、次の方法で変更できます。

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の略称

関連項目:

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

例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');

時刻書式

表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

関連項目:

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

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です。

- エチオピア歴: 30日の月が12か月あり、その後に5日間または6日間(うるう年)の13か月めがあります。4年おきに、13月に6日目が追加されます。

暦法は、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(英語版イスラム歴)

- Ethiopian(エチオピア歴)

- Gregorian(グレゴリオ暦)

- Japanese Imperial(日本の元号暦)

- Persian(ペルシャ暦)

- ROC Official(台湾暦)

- Thai Buddha(タイ仏教暦)

関連項目:

暦法、そのデフォルトの日付書式および日付表示に使用されるキャラクタ・セットのリストは、「ロケール・データ」を参照してください

例3-17 NLS_CALENDAR='English Hijrah'

NLS_CALENDARをEnglish Hijrahに設定します。

SQL> ALTER SESSION SET NLS_CALENDAR='English Hijrah';

SELECT文を入力してSYSDATEを表示します。

SQL> 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を次のように定義します。

SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ",.";

SQL文には、数値リテラルまたはテキスト・リテラルを表す数値を組み込めます。数値リテラルは引用符で囲みません。数値リテラルはSQL言語構文の一部で、小数点文字として常にドットを使用し、グループ・セパレータは含まれません。テキスト・リテラルは引用符で囲みます。テキスト・リテラルは、必要に応じて、現行のNLS設定に従って、暗黙的または明示的に数値に変換されます。

次のSELECT文は、ALTER SESSION文で指定された小数点文字とグループ・セパレータを使用して数値4000の書式を設定します。

SQL> 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 通貨書式の例

国名

例

エストニア

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です。

次の表に、その他の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を次のように設定します。

SQL> 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

関連項目:

言語ソートと照合

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文を使用します。

関連項目:

- 言語ソートと照合

- 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データの間で暗黙的または明示的な文字列型の変換時にデータが消失した場合に、エラーをレポートするかどうかを決定します。デフォルト値の場合、エラーはレポートされません。

関連項目:

キャラクタ・セット変換中のデータ消失の詳細は、「キャラクタ・セットの移行」を参照してください

長さセマンティクス

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

- 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に設定しないことをお薦めします。これによって、多数の既存インストール・スクリプトに文字長さセマンティクスを持つ列が予期せず作成され、バッファ・オーバーフローなどのランタイム・エラーが発生する場合があります。

関連項目:

「長さセマンティクス」

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 Databaseの日付値のデフォルト書式は、NLS_DATE_FORMATおよびNLS_DATE_LANGUAGE初期化パラメータから導出されます。この例の日付書式には、日を表す2桁の数値、月名の略称、年の4桁および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関数の使用

次の例に、日時データ型にデータを挿入する方法を示します。

関連項目:

TO_TIMESTAMPまたはTO_TIMESTAMP_TZSQL関数の詳細は、「日時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として入力した情報がローカル・タイム・ゾーンに変更されていることに注意してください。

TIMESTAMPデータ型の選択

TIMESTAMPデータ型は、イベントの時間を記録する日時値(タイム・ゾーンなし)が必要な場合に使用します。たとえば、組立ラインの作業場にいる従業員がタイムカードに出社と退社を記録した時刻情報を格納できます。これは常にローカル時刻であるため、タイムゾーンの部分を保存する必要がありません。TIMESTAMPデータ型では、格納に7バイトまたは11バイトが使用されます。

TIMESTAMP WITH 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 Databaseでは、すべてのタイムスタンプ演算がUTC時間で実行されます。TIMESTAMP WITH LOCAL TIME ZONEデータの場合は、日時値がデータベースのタイム・ゾーンからUTCに変換され、演算の実行後にデータベースのタイム・ゾーンに逆変換されます。TIMESTAMP WITH TIME ZONEデータの場合、日時値には常にUTCが使用されるため、変換は必要ありません。

関連項目:

- 日時および時間隔の演算操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- DATEへの暗黙的な変換を実行する関数については、「日時SQL関数」を参照してください

日時の比較

日付値とタイムスタンプ値を比較する場合、Oracle Databaseではデータが高精度のデータ型に変換されてから比較されます。たとえば、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関数の場合、内部変換は実行されません。

次の表に、Oracle DatabaseのDATEデータ型用に設計された日時関数を示します。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表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を戻します

次の表では、その他の日時関数について説明します。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

表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

文が実行される日付に基づいて、入力値に対応するタイム・ゾーン・オフセットを戻します。

次の表に、夏時間(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 Databaseのタイム・ゾーン・データは、http://www.iana.org/time-zonesにある公開共有情報から導出されます。Oracle Databaseのタイム・ゾーン・データには、このサイトから入手可能な最新データが反映されていない場合があります。

次の文を入力すると、データベースとともにインストールされるタイム・ゾーン・ファイルからタイム・ゾーンの名前と略称のリストを取得できます。

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のすべてのタイム・ゾーン・ファイルが含まれています。これらのリリースでそれぞれ提供されている各種のパッチおよびパッチ・セットにより、タイム・ゾーン・ファイルのバージョンも更新できます。Oracle Database 12cでは、バージョン18が含まれます。

夏時間(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つのみです。また、アップグレードを実行する前に、すべてのエラーを修正する必要があります。

注意:

タイム・ゾーン・ファイルを更新するために使用可能なパッチのマトリクスは、Oracle Supportの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);
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'

Microsoft Windows環境でORA_SDTZ変数を設定するときに、レジストリ、システム環境変数、またはコマンド・プロンプト・ウィンドウで、タイム・ゾーン値を引用符で囲まないでください。

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タイム・ゾーンの日時値に変換しています。

関連項目:

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

例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は、指定のタイム・ゾーンで夏時間が有効かどうかを自動的に判別し、対応するローカル時間を返します。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');

注意:

上の例のglobal_orders表を作成した場合は、例4-7から例4-8を試す前にglobal_orders表を削除してください。

例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時間早い時刻を示します。

例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 Database環境での文字列のソートと検索について説明します。文字列(文字値)間の相互の順序を決定するプロセスを照合と言います。2つの文字列があるときに、並び順がどちらも同じなのか、前後に分かれるのかは照合によって決まります。Oracleのドキュメントでは、照合のかわりにソートという用語がよく使用されます。

表の列のような文字列のセットが、指定の検索条件と等しい値なのか、検索パターンと一致する値なのかを調べる際に、値を等しいと判定する基準が特に重要になります。検索で使用されるSQLの演算子と関数は、'='、LIKE、REGEXP_LIKE、INSTR、およびREGEXP_INSTRです。この章では、一致という言葉は、等価演算子=を使用して文字列全体が等しいと判定できる場合、あるいはLIKE、REGEXP_LIKE、またはREGEXP_INSTRを使用して文字列がパターンと一致するため、部分文字列が等しいと判定できる場合を意味するものとします。Oracle Textにより、Oracle Databaseの高度なフルテキスト検索機能が提供されます。

1つのセットの中にある文字列を並べ替えることをソートと言います。たとえば、ORDER BY句の場合は、問合せ結果をソートするために、文字列の順序の決定に照合が使用され、PL/SQLの場合は、VARCHAR2値で索引付けられた結合配列の中の文字列をソートするために照合が使用され、また、MIN、MAX、GREATEST、およびLEASTの各関数の場合は、最も短い文字値または最も長い文字値を探すために照合が使用されます。

文字列の並び順の決定に適用できる照合は様々です。標準的、慣習的な話し言葉を考慮に入れた照合のことを言語照合と言います。文字列の順序は、ある言語で書かれた辞書、電話帳などの文字で構成される一覧と同様です。対照的に、バイナリ照合の場合は、それぞれの文字列が単純なバイトの並びとして扱われ、バイナリ表現(文字コード)に基づいて文字列が並べ替えられます。

関連項目:

- 『Oracle Textアプリケーション開発者ガイド』

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

- Oracle Databaseの照合機能の概要

- バイナリ照合の使用

- 言語照合の使用

- 言語照合の特徴

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

- 言語比較の実行

- 言語索引の使用

- 言語の文字列検索

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

Oracle Databaseの照合機能の概要

照合は言語によって異なります。さらに、同じアルファベットを使用している文化または国の間でも、文字のソート方法が異なる場合があります。たとえば、デンマークのÆは、Zの後にきます。また、YとÜは同じ文字の変形とみなされます。

照合では、大/小文字区別の有無を指定できます。ケースは、大文字であるか小文字であるかの条件を指します。たとえばラテン・アルファベットの場合、Aが大文字で、それに対する小文字がaです。

照合では、発音区別記号を無視するか考慮するかを指定できます。発音区別記号は、文字または文字列の上または下にある記号で、それが付いていない場合の文字とは発音が異なることを示します。たとえば、façadeの場合、セディラ(,)は発音区別記号です。セディラが付いている場合は、cの発音が変化します。

表音的な照合順序や、文字の外観に基づいた照合順序も指定できます。たとえば、東南アジアの表意文字の場合は、画数に基づいた照合を指定できます。照合の一般的な問題となるものに、結合文字があります。たとえば、伝統的なスペイン語のchは1つの独立した文字であり、ソート順序ではcの後にきます。つまり、正しいソート順序は、cerveza、colorado、cheremoyaのようになります。したがって、文字cは、次にくる文字がhであるかどうかが確認されるまで、ソートされません。

Oracle Databaseには、次のタイプの照合があります。

- バイナリ

- 単一言語

- 多言語

- Unicode照合アルゴリズム(UCA)

単一照合はその言語固有の文字の順序に従って並べ替えるようになっていますが、多言語照合とUCA照合は、様々な言語をまとめて処理できるようになっています。さらに、UCA照合は、Unicode規格で、国際照合標準ISO 14651と完全な互換性があるUnicode照合アルゴリズム(UCA)の仕様をすべて満たしています。UCA規格は、Unicodeのすべての文字、したがって世界中のすべての言語のすべての文字の、完全な言語的順序付けを提供しています。Unicodeアプリケーションは広くデプロイされているため、UCA照合は、多言語データのソートに最適です。

バイナリ照合の使用

文字データをソートする方法の1つは、文字コード体系によって定義された文字の数値に基づいています。このようなソートをバイナリ照合と呼びます。バイナリ照合は最も高速なソート・タイプです。ASCIIやEBCDICの規格では、文字AからZを昇順の数値で定義しているため、英語のアルファベットについてはこのタイプで正しいソート結果が得られます。

注意:

ASCII規格では、大文字はすべて小文字の前にきます。逆に、EBCDIC規格では、小文字はすべて大文字の前にきます。

他の言語で使用されている文字が存在すると、通常、バイナリ照合では正しい結果が得られません。たとえば、文字コード体系で、Äの数値がBの数値より高い場合、昇順のORDER BY問合せでは、ABC、ABZ、BCD、ÄBCの順で文字列が戻ります。表意文字を使用するアジア言語の場合、通常、バイナリ照合に言語的な意味はありません。

言語照合の使用

文字のアルファベット順に一致する照合基準を得るには、文字コード体系内の数値に依存せずに文字をソートする別のソート方法を使用する必要があります。この方法を言語照合と呼びます。言語照合では、各文字を、その文字の言語的に適切な順序を反映した数値に置き換えることによって処理が行われます。

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

- 単一言語照合

- 多言語照合

- UCA照合

単一言語照合

Oracle Databaseでは、単一言語照合の場合、文字列は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 Databaseには多言語照合が用意されているため、複数言語のデータを1つのソートとしてソートできます。この機能は、複雑なソート・ルールや多言語データベースを持つ地域または言語に有効です。Oracle Database 12cの時点で、Oracle Databaseは、以前のリリースによって定義された照合のすべてをサポートしています。

アジア諸国の言語データや多言語データに対しては、ISO 14651規格に基づいたソート・メカニズムが用意されています。たとえば、漢字は、画数、ピンイン(中国語の発音記号)または部首で順序付けできます。

また、多言語照合では、標準的な同値化および補助文字を処理できます。標準的な同値化は、文字間または文字列間での基本的な同値化です。たとえば、çは、cと,の組合せと同じです。補助文字はUnicodeでのユーザー定義文字または事前定義済の文字であり、特定のコード範囲内の2つのコード・ポイントを必要とします。1つの多言語ソートに最大110万のコード・ポイントを定義できます。

たとえば、Oracle Databaseではフランス語の単一言語ソート(FRENCH)がサポートされていますが、フランス語の多言語照合(FRENCH_M)を指定できます。_Mは、多言語ソートに対するISO 14651規格を表します。このソート順では、GENERIC_Mソート順に基づき、発音区別記号を右から左へとソートできます。多言語ソートは、通常、表に多言語データが含まれる場合に使用されます。表にフランス語のみが含まれている場合は、メモリーの使用量が少ないフランス語の単一言語ソートを使用すると、パフォーマンスが向上する可能性があります。メモリー使用量が少ないのは、フランス語の単一言語ソートの方が、フランス語の多言語ソートよりも定義されている文字が少ないためです。どの方法を使用するかは、ソートの範囲とパフォーマンスのトレードオフになります。

関連項目:

- 「標準的な同値化」

- 「コード・ポイントと補助文字」

多言語照合レベル

Oracle Databaseでは、多言語照合を次の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

UCA照合

Unicode照合アルゴリズム(UCA)は、照合に関する国際的な規格であるISO 14651の仕様をすべて満たすUnicode規格です。それぞれに特徴を持った言語すべてを対象にした合理的なデフォルトの順序になるように、UCAに基づいてDefault Unicode Collation Element Table(DUCET)が定義されています。特定言語で正しい順序付けができるようにするために、その言語の言語要件を満たすようにDUCETを調整できます。各種言語に応じたDUCETの調整版が、Unicode Common Locale Data Repositoryに公開されています。UCAおよび関連の用語については、http://www.unicode.orgにある、Unicode照合アルゴリズムの情報を参照してください。

Oracle Databaseは、Oracle Database 12c (12.1.0.2)の時点で、UCA 6.2.0完全準拠のUCA照合を提供しています。DUCETに基づいて照合できるだけでなく、よく使用されている様々な言語の特性に合せて照合することができます。たとえば、UCA照合UCA0620_SCHINESEを指定して、簡体字中国語を含む多言語データをソートできます。この照合は、簡体字中国語のデータをピンイン(中国語の発音記号)の順に表示します。

多言語データのソートではUCA照合をお薦めします。

UCA比較レベル

多言語照合と同様に、UCA照合では、マルチレベルの比較アルゴリズムを使用して文字を評価します。そのレベルは次の4レベルまであります。

- 1次レベル

- 2次レベル

- 3次レベル

- 4次レベル

1次レベル

1次レベルはベース文字を区別するために使用されます。多言語照合の1次レベル照合において使用される比較に類似しています。

関連項目:

ベース文字の違いの例は、「1次レベル照合」を参照してください

2次レベル

2次レベルは、ベース文字が同じである場合に、発音区別記号を区別するために使用されます。多言語照合の2次レベル照合において発音区別記号を区別するために使用される比較に類似しています。

関連項目:

発音区別記号の違いの例は、「2次レベル照合」を参照してください

3次レベル

3次レベルは、発音区別記号が同じであるベース文字でケースを区別するために使用されます。多言語照合の3次レベル照合においてケースを区別するために使用される比較に類似しています。さらに、UCA DUCET照合は、可変文字の重み付けに基づいて、句読点を1次または4次の重要性で処理します。これは、句読点を3次レベルの重要性で処理する、多言語照合の3次レベル照合とは異なります。

関連項目:

大/小文字が違う文字の例は、「3次レベル照合」を参照してください

4次レベル

4次レベル照合は、可変文字の重み付けがshiftedになっている場合に、可変文字とそれ以外の文字の間の区別に使用されます。これは、ベース文字と大/小文字の違いがない平仮名とカタカナの区別にも使用されます。図5-1に例を示します。

図5-1 平仮名とカタカナとの照合

関連項目:

「UCA照合パラメータ」

UCA照合パラメータ

表5-2に、Oracle Database 12cのUCA照合でサポートされている照合パラメータと照合オプションを示します。

表5-2 UCA照合パラメータ

属性

オプション

照合修飾子

strength

primary

secondary

tertiary

quaternary

_AIまたは_S1

_CIまたは_S2

_S3

_S4Foot 1

alternate

non-ignorable

shifted

blanked

_VN

_VS

_VB

backwards

on

off

_BY

_BN

normalization

on

_NY

caseLevel

off

_EN

caseFirst

upper

off

_FUFoot 2

_FNFoot 3

hiraganaQuaternary

on

off

_HY

_HN

numeric

off

_DN

match-style

最小

_MN

脚注1

_S4: alternateがshiftedの場合のみ該当

脚注2

_FU: デンマーク語でのみ有効

脚注3

_FN: それ以外の言語でのみ有効

パラメータstrengthは、UCA比較レベルを表します(「UCA比較レベル」を参照してください)。パラメータalternateは、可変文字の重み付けの方法を制御します。パラメータbackwardsは、発音区別記号を逆順に検索するかどうか制御します。表5-2に示したオプションを使用して、これら3つのUCAパラメータを構成できます。表5-2に記載の他のパラメータのオプションは、調整された言語に基づいて、現在固定されており、Oracle Database 12cの時点では構成できません。

UCA照合パラメータとオプションの詳細は、「Unicode照合アルゴリズム規格」を参照してください(http://www.unicode.org )。

言語照合の特徴

この項では、次の言語照合機能の違いについて説明します。

- ベース文字

- 無視可能文字

- 短縮文字

- 拡張文字

- 状況依存文字

- 標準的な同値化

- 逆2次ソート

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

- 特殊文字

- 特殊組合せ文字

- 特殊な大文字

- 特殊な小文字

言語照合は、必要な特性を含むようにカスタマイズできます。

関連項目:

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

ベース文字

ベース文字はベース文字表に定義されています。この表によって、各文字がベース文字にマップされます。たとえば、a、A、äおよびÄはすべて、ベース文字であるaにマップされます。この概念は、Oracle Textで作業する場合に特に重要です。

関連項目:

『Oracle Textリファレンス』

無視可能文字

多言語照合とUCA照合では、いくつかの文字が無視可能とみなされる場合があります。ソート操作または照合操作で無視可能文字を含む2つの値(文字列)を比較する際、無視可能文字はスキップされ、存在しないものとして処理されます。無視可能文字には、1次無視可能文字、2次無視可能文字、および3次無視可能文字の3種類があります。

- 1次無視可能文字

- 2次無視可能文字

- 3次無視可能文字

1次無視可能文字

1次無視可能文字は、任意の比較に適用される多言語照合またはUCA照合の定義にアクセントを区別しない修飾子_AIがある場合(GENERIC_M_AI、UCA0620_DUCET_AIなど)に無視されます。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ユーティリティの多言語照合の定義では、1次無視可能文字は分音文字と呼ばれます。

2次無視可能文字

2次無視可能文字は、適用される定義にアクセントを区別しない修飾子_AIまたは大/小文字を区別しない修飾子_CIがある場合に無視されます。

多言語照合の2次無視可能文字には、句読点(たとえば空白文字、改行制御コード、ダッシュ、様々な引用符形式、数学演算子、点、カンマ、感嘆符、様々な括弧形式など)が含まれます。アクセントを区別しない(_AI)ソートや、大/小文字を区別しない(_CI)ソートでは、このような句読点は無視されるため、multi-lingualとmulti-lingual、およびe-mailとemailをそれぞれ同じ文字として処理できます。

Oracle Locale Builderユーティリティの多言語照合の定義では、2次無視可能文字は句読点と呼ばれます。

しかし、UCA DUCETでは2次無視可能文字は定義されていません。UCAでは句読点は可変文字として処理されます。

3次無視可能文字

言語比較では、3次無視可能文字は通常、無視されます。これらは主に制御コード、書式文字、異体字セレクタなどで構成されます。

標準的な大/小文字を区別するソートやアクセントを区別するソートが使用されている場合に、1次無視可能文字と2次無視可能文字は無視されません。ただし、文字列の順序を決定する際、無視可能文字は優先順位が低くなります。たとえば、GENERIC_Mソートではmulti-lingualはmultilingualの後にソートされますが、依然としてmultidimensionalとmultinationalの間にソートされます。順序を決定する際、ベース文字の比較d < l < nの方が、2次無視可能文字であるハイフン(U+002D)の有無よりも高い優先順位が付けられます。

多言語照合の定義における分音文字、句読点の完全なリストは、Oracle Locale Builderで定義を表示すると示されます。一般に、単一言語照合の定義には句読点も分音文字も含まれません。一部の単一言語照合の定義には、空白文字とタブ文字が含まれることがあります。比較アルゴリズムでは、マイナー値が各未定義文字に自動的に割り当てられます。これにより、句読点は無視できなくなりますが、多言語照合の場合と同様に、比較する文字列の順序を決定する際の優先順位は低くなります。単一言語照合での句読点間の順序はUnicodeコード・ポイントに基づいているため、ユーザーの予想とは一致しないことがあります。

関連項目:

「大/小文字区別およびアクセント区別なしの言語照合」

可変文字と可変重み付け

UCAには、可変的な照合要素として定義されている文字があります。このような文字は可変文字と呼ばれ、空白文字、句読点、および特定の記号で構成されます。

UCA照合では、可変文字に異なる重み付けをして、ソートまたは比較でのそれらの文字の効果を調整することができます。これを可変重み付けと呼びます。その動作は、照合パラメータalternateで制御されます。Oracle Database 12cのUCA照合では、可変重み付けのオプションとして次のものがサポートされています。

- blanked
可変文字が無視可能文字として扱われます。たとえば、比較時に空白(U+0020)は無視されます。

- non-ignorable
可変文字が、無視可能文字ではない文字として扱われます。たとえば、比較の1次レベルで空白(U+0020)は無視されません。

- shifted
可変文字は、1次、2次および3次レベルで、無視可能文字とみなされます。さらに、新しい4次レベルが、すべての文字に対して使用されます。文字の4次重み付けは、文字が可変、無視可能、その他のいずれであるかに依存します。たとえば、4次レベルで空白文字(U+0020)にはA(U+0041)とは違う重み付けが割り当てられますが、これは、空白文字は可変文字であっても、Aは可変文字でも無視可能文字でもないからです。

関連項目:

「UCA照合パラメータ」

可変重み付けの例

この項では様々な可変重み付けの例を示します。

例5-1 可変重み付けがBlankedに設定されている場合のUCA DUCETの順序

次の例は、UCA0620_DUCET_VBを使用してソートしたときの例です。

blackbird
Blackbird
Black-bird
Black bird
BlackBird

空白文字(U+0020)とハイフン(U+002D)は無視可能文字として扱われるため、Blackbird、Black-bird、およびBlack birdは、照合時の重み付けが同じになります。区別されるエントリのみを選択すると、この動作がよくわかります(結果にBlackbirdだけが現れることに注意してください)。

blackbird
Blackbird
BlackBird

1番目のB(U+0042)の大/小文字の違いにより、Blackbird、Black-bird、およびBlack birdは、blackbirdの後にソートされますが、2番目のb(U+0062)の大/小文字の違いにより、BlackBirdの前にソートされます。

例5-2 可変重み付けがNon-Ignorableに設定されている場合のUCA DUCETの順序

次の例は、UCA0620_DUCET_VNを使用してソートしたときの例です。

Black bird
Black-bird
blackbird
Blackbird
BlackBird

SPACE(U+0020)とHYPHEN(U+002D)は、無視可能文字とみなされず、1次レベルでb(U+0062)より小さいため、Black birdとBlack-birdはblackbirdより前にソートされます。1次レベルでは空白文字(U+0020)はハイフン(U+002D)よりも小さいため、Black birdはBlack-birdの前にソートされます。

例5-3 可変文字がshiftedと重み付けされている場合のUCA DUCET順序

次の例は、UCA0620_DUCETを使用してソートしたときの例です。

blackbird
Black bird
Black-bird
Blackbird
BlackBird

SPACE(U+0020)とHYPHEN(U+002D)が最初の3つのレベルで無視され、最初のb(U+0062)に大文字/小文字の相違があるため、blackbirdはBlack birdとBlack-birdの前にソートされます。HYPHEN(U+002D)の4次重み付けがBlackbirdの文字b(U+0062)より小さいため、Black-birdはBlackbirdより前にソートされます。

短縮文字

照合要素は、通常、単一文字で構成されていますが、一部のロケールでは、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 Database定義の多言語照合には、標準的な同値化フラグ用の適切な設定が含まれています。すべてのデータが合成された形式の場合は、このフラグを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 Databaseは、特殊な小文字をサポートしています。1つの大文字が複数の小文字にマップされる場合があります。たとえば、トルコ語の大文字Iは、小文字のiのドットなしになります。

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

Oracle Database内の操作では、常に大/小文字およびアクセント(発音区別記号)が区別されます。大/小文字およびアクセントを区別しない比較と照合の実行が必要になる場合があります。

以前のバージョンのデータベースでは、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の照合には、大/小文字の区別がなく、アクセントの区別のないオプションが用意されています。次のタイプの言語照合があります。

- ベース文字、発音区別記号、句読点およびケースに関する情報を使用する言語照合。これらは、「言語照合の使用」で説明した標準的な言語照合です。

- ベース文字、発音区別記号、句読点に関する情報を使用するが大/小文字に関する情報を使用しない単一言語の照合と、ベース文字、発音区別記号に関する情報を使用するが句読点、大/小文字に関する情報を使用しない多言語照合およびUCA照合。このタイプのソートを、大/小文字を区別しないソートと呼びます。

- ベース文字と句読点に関する情報のみを使用する単一言語照合、およびベース文字に関する情報のみを使用する多言語照合とUCA照合。このタイプのソートを、アクセントを区別しないソートと呼びます。(アクセントは発音区別記号と同義です。)大/小文字を区別しないソートと同様、アクセントを区別しないソートでもケースに関する情報は使用しません。

アクセントおよび大/小文字を区別しない多言語照合では、「無視可能文字」に記載されているように、句読点は無視されます。

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

- 例: 大/小文字およびアクセントを区別しない照合

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

- 例: 言語照合

関連項目:

- 「NLS_SORT」

- 「NLS_COMP」

例: 大/小文字およびアクセントを区別しない照合

後述の例は、次のソートを示しています。

- ベース文字、発音区別記号、句読点およびケースに関する情報を使用する照合

- 大/小文字を区別しない照合

- アクセントを区別しない照合

例5-4 ベース文字、発音区別記号、句読点およびケース情報を使用した言語照合

次のリストは、ベース文字、発音区別記号、句読点およびケース情報を使用してソートされています。

blackbird
black bird
black-bird
Blackbird
Black-bird
blackbîrd
bläckbird

例5-5 大/小文字を区別しない言語照合

次のリストは、ベース文字、発音区別記号および句読点情報を使用し、ケースを無視してソートされています。

black bird
black-bird
Black-bird
blackbird
Blackbird
blackbîrd
bläckbird

black-birdとBlack-birdの違いはケースのみのため、照合では同じ値となります。この2つの値は、リストでどちらが前にきてもかまいません。Blackbirdとblackbirdの値も照合では同じ値となり、リストでどちらが前にきてもかまいません。

例5-6 アクセントを区別しない言語照合

次のリストは、ベース文字情報のみを使用してソートされています。発音区別記号、句読点およびケース情報は使用されていません。

blackbird
bläckbird
blackbîrd
Blackbird
BlackBird
Black-bird
Black bird

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

NLS_SORTセッション・パラメータを使用して、大/小文字またはアクセントを区別しない照合を指定します。

- 大/小文字を区別しない照合の場合は、Oracle照合名に_CIを追加します。

- アクセントも大/小文字も区別しない照合の場合は、Oracle照合名に_AIを追加します。

たとえば、NLS_SORTを次のタイプの値に設定できます。

UCA0620_SPANISH_AI
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-7 バイナリ照合

ORDER BY句でバイナリ照合を使用します。

SQL> SELECT * FROM test3 ORDER BY name;

次の出力が表示されます。

Diet
Freizeit
À voir

バイナリ照合の結果、À voirがリストの最後に表示されることに注意してください。

例5-8 ドイツ語の単一言語照合

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語照合を取得します。

SQL> SELECT * FROM test3 ORDER BY NLSSORT(name, 'NLS_SORT=german');

次の出力が表示されます。

À voir
Diet
Freizeit

ドイツ語照合では、À voirがリストの先頭になることに注意してください。

例5-9 ドイツ語の単一言語照合とUCA照合の比較

図5-2に示した文字列をtestに挿入します。この場合、横棒付きのDの後にñがきます。

図5-2 文字列の例

NLS_SORTパラメータをgermanに設定してNLSSORT関数を使用し、ドイツ語の単一言語照合を実行します。

SELECT * FROM test2 ORDER BY NLSSORT(name, 'NLS_SORT=german');

ドイツ語照合からの出力では、新しい文字列がエントリ・リストの最後に表示されます。これは、その文字がドイツ語照合では認識されないためです。

次の文を入力してUCA照合を実行します。

SELECT * FROM test2
ORDER BY NLSSORT(name, 'NLS_SORT=UCA0620_DUCET');

出力では、UCAの順序に従って新しい文字列が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-3に、これらの異なる設定を使用した場合のSQLまたはPL/SQL操作の動作の違いを示します。

表5-3 NLS_COMP設定を使用した言語比較の動作

SQLまたはPL/SQL操作

BINARY

LINGUISTIC

ANSI

集合演算子

-

-

-

UNION、INTERSECT、MINUS

バイナリ

NLS_SORTに従います。

バイナリ

スカラー関数

-

-

-

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_REPLACE

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REGEXP_SUBSTR

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

REPLACE

バイナリ

NLS_SORTに従います。

バイナリ

RTRIM、TRIM、LTRIM

バイナリ

NLS_SORTに従います。

バイナリ

TRANSLATE

バイナリ

NLS_SORTに従います。

バイナリ

条件

-

-

-

=, !=, >, <, >=, <=

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

BETWEEN、NOT BETWEEN

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

IN、NOT IN

バイナリ

NLS_SORTに従います。

NLS_SORTに従います。

LIKE

バイナリ

NLS_SORTに従います。

バイナリ

REGEXP_LIKE

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

CASE式

-

-

-

CASE

バイナリ

NLS_SORTに従います。

バイナリ

分析関数句

-

-

-

DISTINCT

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

OVER(ORDER BY)

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

OVER(PARTITION BY)

NLS_SORTに従います。

NLS_SORTに従います。

NLS_SORTに従います。

副問合せ句

-

-

-

DISTINCT、UNIQUE

バイナリ

NLS_SORTに従います。

バイナリ

GROUP BY

バイナリ

NLS_SORTに従います。

バイナリ

ORDER BY

NLS_SORTに従います。

NLS_SORTに従います。

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値の最大長は初期化パラメータMAX_STRING_SIZEの値に応じて変わるため、照合キーの最大長もそのパラメータに従って制御されます。

MAX_STRING_SIZEがSTANDARDに設定されている場合は、照合キーの最大長は2000バイトに制限されます。ソース文字列全体から生成される照合キーの長さが最大長を超える場合、この文字列用に生成される照合キーは、値の最大接頭辞(先頭の部分文字列)に合せて計算されるため、計算結果が2000バイトを超えることはありません。単一言語照合では、接頭辞は一般的に1000文字になります。複数言語照合では、接頭辞は一般的に500文字になります。UCA照合では、接頭辞は一般的に300文字になります。接頭辞の正確な長さは、特定の照合およびソース文字列に含まれる特定の文字によって増減する場合があります。照合キーの生成でこの方法を使用すると、照合キーを使用して言語動作を実行するSQL操作で、長い引数の終了部分が無視される場合があります。たとえば、先頭の1000文字が同じで、それ以降の任意の位置の値が異なる2つの文字列は、GROUP BY句で一緒にグループ化されます。

MAX_STRING_SIZEがEXTENDEDに設定されている場合、照合キーの最大長は32767バイトに制限されます。ソース文字列全体から生成される照合キーの長さが最大長を超える場合は、ORA- 12742が呼び出されます。

例: 言語比較

次に、異なるNLS_COMP設定を使用した動作の例を示します。

例5-10 バイナリ比較バイナリ照合

次に、バイナリ設定を使用した動作を示します。

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-11 言語比較の大/小文字区別なしのバイナリ照合

次に、大/小文字を区別しない設定を使用した動作を示します。

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-12 言語比較のアクセント区別なしのバイナリ照合

次に、アクセントを区別しない設定を使用した動作を示します。

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-13 戻す行が少なくなる言語比較

一部の操作では、言語ルールを適用すると、戻される行が少なくなる場合があります。たとえば、バイナリ設定の場合、次のように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-14 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

例5-15 UCA0620_TSPANISHを使用した言語比較

文字chは、XSPANISHの場合と同様に、UCA照合の伝統的なスペイン語の順序に従って処理されます。

SQL> ALTER SESSION SET NLS_COMP = LINGUISTIC;
SQL> ALTER SESSION SET NLS_SORT = UCA0620_TSPANISH;
SQL> SELECT ename FROM emp3 WHERE ename LIKE 'C%';

ENAME
--------------
Cindy
Clara

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'));

CREATE TABLE文にNOT NULLを指定すると、索引が使用されるようになります。

索引の作成後に、次の例ようなSELECT文を入力します。

SELECT * FROM my_table WHERE name LIKE 'Hein%' ORDER BY name;

この文は、言語索引を使用しない場合の同じSELECT文より速く結果が戻されます。

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

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

- 複数言語の言語索引

- 言語索引の使用要件

関連項目:

- ファンクション索引の詳細は、『Oracle Database管理者ガイド』を参照してください

言語索引でサポートされる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

複数言語の言語索引

複数言語のデータに言語索引を作成する方法には、次の4通りがあります。

- アプリケーションでサポートされている各言語の言語索引を作成します。このアプローチは単純ですが、大量のディスク領域が必要になります。索引ごとに、その索引が作成されている言語以外の言語の複数行が、順番の最後にまとめて照合されます。次の例では、フランス語とドイツ語の言語索引を作成しています。

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 (LANG_COL, 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'));

関連項目:

詳細は、「多言語照合」を参照してください

- UCA0620_DUCETやUCA0620_CFRENCHなどのUCA照合のいずれかを使用して、すべての言語に単一言語索引を作成します。これらの索引では、ISO 14654とUCA 6.2.0に準拠した順序で文字がソートされます。次に例を示します。

CREATE INDEX i
ON t (NLSSORT(col, 'NLS_SORT=UCA0620_DUCET'));

関連項目:

詳細は、「UCA照合」を参照してください

言語索引の使用要件

言語索引を使用するための要件は、次のとおりです。

- 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句は必要ありません。

適切なブロック・サイズでの表領域の使用

文字値から作成された照合キーの長さは、通常はこの値の数倍です。実際の長さの拡張は、使用する特定の照合およびソース値の内容に応じて異なり、ほとんどがUCAベースの照合により拡張されます。

言語索引を作成する場合、Oracle Databaseは、索引キーを形成する文字の列ごとに、照合キー(NLSSORT結果)の推定最大サイズを集計して、最初に索引キーの推定最大サイズを計算します。この計算では、最大バイト長nの文字の列の照合キーの最大サイズは、n*21+5(UCAベースの照合)およびn*8+10(その他の照合)と推定されます。

拡大比が大きいと、特にコンポジット(複数列)キーの場合に、最大索引キーのサイズが大きくなる可能性があります。同時に、索引の最大キー・サイズは、索引を含む表領域のブロック・サイズの約70%を超えることはできません。この場合は、ORA-1450エラーがレポートされます。このエラーを回避するには、言語索引を適切なブロック・サイズの表領域に格納してください(データベースのデフォルトのブロック・サイズより大きくなる場合があります)。必要なブロック・サイズ nに対応する初期化パラメータDB_nK_CACHE_SIZEが適切に設定されている場合は、最適なデータベースをCREATE TABLESPACE文で作成できます。

関連項目:

- Oracle Database管理者ガイド

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

次の例では、フランス語の言語索引の設定方法を示します。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 Databaseの照合の種類と、各照合がSQLおよびSQL正規表現による文字列検索に与える影響について説明します。

関連項目:

- 「言語照合の特徴」

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

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

正規表現は、テキスト本体に含まれる文字列のパターンを識別する強力な方法を提供します。正規表現の用途には、San Franciscoのような文字列の単純検索や、すべてのURLを抽出する複雑なタスク、さらに2文字目に母音を含むすべての単語の検索などのタスクがあります。SQLとPL/SQLは、Oracle Databaseの正規表現をサポートしています。

従来の正規表現エンジンは、英語のテキストのみを処理するように設計されていました。ただし、正規表現の実装には、西欧のテキストとはまったく異なる特性を持った多様な言語を含めることができます。Oracle Databaseの正規表現の実装は、Unicode正規表現ガイドラインに基づいています。REGEXP SQL関数は、データベース・キャラクタ・セットおよび各国語キャラクタ・セットとしてサポートされるキャラクタ・セットをすべて処理します。さらに、Oracle Databaseでは、多言語データの照合に関する固有の言語要件を処理するために、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-16 NLS_SORT値を使用した大/小文字を区別しない一致

Oracle Databaseの正規表現の一致では、大/小文字区別の有無は、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-17 ランタイム照合オプションで上書きされた大/小文字区別の有無

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-18 照合要素演算子[..]を使用した照合

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-19 文字クラス演算子[::]を使用した照合

この式では、小文字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-20 ベース文字演算子[==]を使用した照合

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 Database環境でのUnicode規格の使用方法について説明します。この章の内容は、次のとおりです。

- Unicode規格とは

- Unicode規格の特長

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

- Unicodeの事例

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

Unicode規格とは

Unicode規格は、世界中で話されているほとんどの言語のあらゆる文字を定義する文字コード・システムです。

既存の文字エンコーディングの制約を克服するために、1980年代の後半、複数の組織がグローバル・キャラクタ・セットの作成に着手しました。グローバル・キャラクタ・セットの必要性は、1990年代中頃に入り、World Wide Webの発展とともにますます大きくなりました。インターネットの普及によってビジネスの形態が変化し、グローバル・マーケットに重点が置かれるようになったため、ユニバーサル・キャラクタ・セットが重要な必要条件になってきました。

このグローバル・キャラクタ・セットは、次の条件を満たす必要があります。

- 現在使用されているすべての主要文字を網羅していること。

- レガシー・データや実装をサポートしていること。

- 1つのアプリケーションの1つの実装で、世界中で使用できるような単純なキャラクタ・セットであること。

また、グローバル・キャラクタ・セットには次の機能も必要です。

- 多言語ユーザーや組織のサポート

- 国際規格への準拠

- 世界規模でのデータ交換

現在幅広く使用されているUnicode規格は、グローバルなキャラクタ・セットの要件と機能のすべてを満たします。プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。文字プロパティと処理ルールもいくつか定義されており、複雑な多言語テキスト処理を正しく整合的に実装します。そのような複雑な処理の例には、双方向動作、単語分割、改行があります。

多くのソフトウェアおよびハードウェア・ベンダーがUnicode規格を採用しており、多くのオペレーティング・システムやブラウザがこの規格をサポートしています。Unicode規格は、XML、Java、JavaScript、LDAPおよびWMLなど他の規格には必須です。ISO/IEC 10646規格とも同期化されています。

Oracle Databaseでは、Oracle Database 7でデータベース・キャラクタ・セットAL24UTFFSS (現在では使用されません)として、Unicode規格の文字コードが導入されました。それ以来、各リリースで逐次的な改善が行われ、新しく公開されたバージョンの規格と同期するようにサポートされてきました。Oracle Database 12c (12.1.0.2)では、Unicode規格バージョン6.2のサポートを拡張し、Unicode照合アルゴリズム(UCA)準拠の新しい言語照合を導入しています。

関連項目:

- Unicode規格の詳細は、http://www.unicode.orgを参照してください

- Unicode照合アルゴリズムのサポートの詳細は「言語ソートと照合」を参照してください

Unicode規格の特長

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

- コード・ポイントと補助文字

- Unicodeエンコード形式

- Oracle DatabaseでのUnicode規格のサポート

コード・ポイントと補助文字

Unicode規格の最初のバージョンは16ビットの固定幅エンコーディングで、各文字のエンコーディングに2バイトを使用していました。このため、65,536文字を表現できました。しかし、サポートを必要とする文字数が増え、特に中国語、日本語および韓国語市場では、追加のCJK表意文字のサポートが必要となりました。

Unicode規格の現在の定義では、規格で定義される各文字に番号が割り当てられています。この番号はコード・ポイントと呼ばれ、範囲0から10FFFFの16進数です。文字コード・ポイントを表すUnicode記法では、接頭辞「U+」に、16進数のコード・ポイント値を続けます。コード・ポイント値では、最小長の4になるまで、意味を持たない0を左側に追加します。コード・ポイントU+0000からU+FFFFの文字は、Basic Multilingual Plane文字と呼ばれます。コード・ポイントU+10000からU+10FFFFの文字は、補足文字と呼ばれます。

補足文字を追加したため、固定幅エンコード形式であるUnicode 16ビットは複雑化しました。しかし、Unicode以前に使用されていた何百ものレガシー・エンコーディングを管理するよりはるかに簡素です。

Unicodeエンコード形式

Unicode規格は、Unicodeコード・ポイントからコード単位へのマッピングであるいくつかのエンコード形式を定義します。コード単位は、アプリケーションで処理される整数値です。コード単位は、8、16、32ビットのいずれかです。標準のエンコーディング形式は、UTF-8、UTF-16およびUTF-32です。また、規格および関連のテクニカル・レポートで言及されている、2つの互換エンコーディングもあります(UCS-2とCESU-8)。Unicodeエンコーディング間の変換は、規格に定義されている単純なビット単位操作です。

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

- UTF-8エンコード形式

- UTF-16エンコード形式

- UCS-2エンコード形式

- UTF-32エンコード形式

- CESU-8エンコード形式

- 例: 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-16エンコード形式

UTF-16は、Unicodeの16ビット・エンコード形式です。UTF-16では、1つの文字を、1つの16ビット整数値(2バイト)と、2つの16ビット整数値(4バイト)のいずれかで表すことができます。Basic Multilingual Planeの文字(日常的なテキストで使用される文字の大部分)はすべて、2バイトで表されます。補助文字は、4バイトで表します。単一の補助文字をエンコードしている2つのコード単位(整数値)は、サロゲート・ペアと呼ばれます。

UTF-16は、バージョンJ2SE 5.0以降のJavaおよびバージョン2000以降のMicrosoft Windowsで内部処理に使用されているメインのUnicodeエンコーディングです。

UTF-8と比較したUTF-16の利点は、次のとおりです。

- 一般に使用されるアジア言語の文字のほとんどは2バイトで表されるため、アジア言語の場合は記憶要件がさらに小規模です。

- JavaおよびMicrosoftクライアントとの優れた互換性があります。

関連項目:

- 「コード・ポイントと補助文字」

- 表B-1

UCS-2エンコード形式

UCS-2は、公式のUnicodeエンコード形式ではありません。もともとの名前の由来は、補助文字が導入される前の、ISO/IEC 10646標準の以前のバージョンです。このため、現在では、補助文字とサロゲート・ペアのサポートから抽出された、UTF-16エンコード形式を指すために使用されています。つまり、サロゲート・ペアは、UCS-2では2つの別々の文字として処理されます。UCS-2はサポートしているがUTF-16はサポートしていないアプリケーションは、補助文字を含むテキストを処理しないようにします。テキストを分割する場合に場合サロゲート・ペアを不正確に分割する場合があるためです。通常は、そのようなテキストを表示することもできません。

UCS-2は、バージョンJ2SE 5.0より前のJavaおよびMicrosoft Windows NTで内部処理に使用されているUnicodeエンコーディングです。

UTF-32エンコード形式

UTF-32は、Unicodeの32ビット・エンコード形式です。各Unicodeコード・ポイントは、32ビット、固定幅の単一の整数値によって表されます。最も単純なエンコード形式ですが、容量の点では非常に非効率です。英語テキストの場合、記憶域要件は、UTF-8の4倍、UTF16の2倍です。このため、UTF-32は、内部テキスト処理の中間形式として使用されることはありますが、通常、情報交換のためには使用されません。

Javaでは、バージョンJ2SE 5.0以降、32ビット形式で文字を操作し、int値として格納するように一部のAPIが拡張されました。

CESU-8エンコード形式

CESU-8は、Unicode規格の中核には含まれていません。Unicodeテクニカル・レポート#26に記述されています。CESU-8は、補助文字の表現を除き、UTF-8と同一の互換エンコード形式です。CESU-8では、UTF-16と同様に、補助文字は、サロゲート・ペアとして表されます。補助文字のCESU-8エンコーディングを取得するには、まず文字をUTF-16にエンコードし、サロゲート・コード単位の各々を、同じ値を持つコード・ポイントとみなします。その後で、UTF-8エンコード規則(ビット変換)を各コード・ポイントに適用します。これにより、2つの3バイト表現(計6バイト)が得られます。

CESU-8の利点は2つのみです。

- バイナリ・ソート順がUTF-16と同じです。

- 1文字当たり、同じ数のコードを使用します(1または2)。これは、文字列処理の文字長セマンティクスにとって重要です。

一般に、CESU-8エンコード形式は、可能なかぎり使用しないようにします。

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

次の表に、UTF-16、UTF-8およびUCS-2の各エンコーディングの文字とその文字コードを示します。最後の文字はト音記号(音楽記号)で、補助文字です。

Oracle DatabaseでのUnicode規格のサポート

Oracle Databaseのキャラクタ・セットとして、リリース7のときにUnicodeキャラクタ・セットのサポートを開始しました。表6-1に、Oracle DatabaseでサポートされているUnicodeキャラクタ・セットを示します。

表6-1 Oracle DatabaseでサポートされているUnicodeキャラクタ・セット

キャラクタ・セット

サポートしているRDBMSのリリース

Unicodeエンコード形式

Unicodeのバージョン

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

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

AL24UTFFSS

7.2 - 8i

UTF-8

1.1

可能

不可

UTF8

8.0 - 12c

CESU-8

Oracle Databaseリリース8.0からOracle8iリリース8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

可能

可能(Oracle9i Database以上のみ)

UTFE

8.0 - 12c

UTF-EBCDIC

Oracle8i Databaseリリース8.0から8.1.6の場合: 2.1

Oracle8i Databaseリリース8.1.7以上の場合: 3.0

はい(「注意1」を参照)

不可

AL32UTF8

9i - 12c

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

Oracle Database 12c: 6.2

可能

不可

AL16UTF16

9i - 12c

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

Oracle Database 12c: 6.2

不可

可能

注意1: UTF-EBCDICは、EBCDICベースのシステム(たとえばIBM z/OSまたはFujitsu BS2000)に固有の互換エンコード形式です。Unicodeテクニカル・レポート#16に記述されています。Oracleキャラクタ・セットUTFEは、エンコード形式UTF-EBCDICの部分的な実装で、ECBDICベースのプラットフォーム上でのみサポートされます。Oracle Databaseでは、このエンコーディング形式の5バイト・シーケンスはサポートされず、サポート対象のコード・ポイント範囲はU+000からU+3FFFFに制限されます。UTFEキャラクタ・セットは使用しないことをお薦めします。

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

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

- データベースを作成すると、UTF-8エンコードされた文字をSQL CHARデータ型(CHAR、VARCHAR2、CLOBおよびLONG)として格納できます。

- Unicodeデータを、UTF-16またはCESU-8エンコード形式でSQL NCHARデータ型(NCHAR、NVARCHAR2とNCLOB)に格納できます。SQL NCHARデータ型は、Unicodeデータの格納専用に使用されるため、Unicodeデータ型と呼ばれます。

注意:

単一のデータベースで動作している異なるアプリケーションで必要とされる場合、両方のUnicodeソリューションを結合できます。

次の項で、2つのUnicodeソリューションの使用方法とその選択方法を説明します。

- データベース全体に対する多言語サポートの有効化

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

- Unicodeソリューションの選択

データベース全体に対する多言語サポートの有効化

データベース・キャラクタ・セットでは、SQL CHARデータ型の他に、表名、列名およびSQL文などのメタデータに使用するエンコーディングが指定されます。Unicode規格対応のデータベースとは、Unicode規格に準拠したキャラクタ・セットをデータベース・キャラクタ・セットとして持つデータベースのことです。Unicode規格を実装するデータベースOracleキャラクタ・セットは2つあります。

- AL32UTF8
AL32UTF8 キャラクタ・セットは、UTF-8エンコード形式を実装し、最新バージョンのUnicode規格をサポートしています。このキャラクタ・セットは、各文字を1バイト、2バイト、3バイトまたは4バイトでエンコードします。このキャラクタ・セットでは、各文字は1バイト、2バイトまたは3バイトでエンコードされ、 補助文字には4バイトが必要です。ASCIIベースのプラットフォーム用です。

AL32UTF8は、多言語アプリケーション(たとえば多国籍企業のインターネットWebサイトやアプリケーション)に最適なサポートを提供するため、Oracle Databaseのあらゆる新しいデプロイメントに対する推奨データベース・キャラクタ・セットです。

- UTF8
UTF8キャラクタ・セットはCESU-8エンコード形式を実装し、各文字を1バイト、2バイトまたは3バイトでエンコードします。ASCIIベースのプラットフォーム用です。

UTF8データベースに挿入された補助文字は、CESU-8エンコード形式で格納されます。各文字は2つの3バイト・コードで表され、計6バイトのメモリーを占有します。

UTF8キャラクタ・セットの文字のプロパティは、Unicode規格バージョン3.0以降の更新に対して保証されません。

補助文字と最新版のUnicode規格を全面的にサポートするAL32UTF8への切替えをお薦めします。

注意:

データベース・キャラクタ・セットは、データベースの作成時に指定します。

例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 = '+00:00';

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

データベースにUnicodeデータを格納する代替方法は、SQL NCHARデータ型(NCHAR、NVARCHAR2、NCLOB)を使用することです。データベース・キャラクタ・セットの定義方法に関係なく、これらのデータ型の列にUnicode文字を格納できます。NCHARデータ型はUnicodeデータ型専用です。つまり、このデータ型は、Unicodeエンコード形式でエンコードされたデータを格納します。

Unicode文字データを格納する場合は、AL32UTF8データベースでCHAR、VARCHAR2、およびCLOBの各SQLデータ型を使用することをお薦めします。一部のデータベース機能は、SQL NCHAR、NVARCHAR2およびNCLOBの各データ型をサポートしていません。とりわけ、Oracle TextとXML DBは、これらのデータ型をサポートしていません。

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データ型で格納されているデータは、CESU-8エンコーディング形式になります。UTF8キャラクタ・セットは非推奨です。

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 = '+00:00';

Unicodeソリューションの選択

新しいOracle Databaseをすべてデータベース・キャラクタ・セットAL32UTF8でデプロイし、SQL VARCHAR2、CHARとCLOBデータ型を使用してキャラクタ・データを格納することをお薦めします。SQL NVARCHAR2、NCHARおよびNCLOBの各データ型は、次の場合のみ検討してください。

- データベース・キャラクタ・セットがUnicodeでない既存のデータベースとレガシー・アプリケーションがあって、Unicodeに移行するとビジネス・コストが過大になり、データベースを別々にしても意味がないようなアプリケーションのごく一部または小さな新規モジュールに対して、多言語データ・サポートを追加する必要がある場合、または

- 多言語データをサポートし、顧客によってデプロイされた任意のOracle Databaseにインストールできる必要があるアプリケーションを作成する必要がある場合。

Unicode規格対応データベースのデータベース・キャラクタ・セットとしては、常にAL32UTF8を選択します。各国語キャラクタ・セットには、AL16UTF16を選択します。英語文字データの記憶域要件が低いため、非推奨のUTF8の選択を検討する場合、まず他のオプション(データ圧縮やディスク・ストレージの追加など)を検討します。データベースに多くのデータが蓄積される場合、後からAL16UTF16に移行しようとするとコストが高くつく場合があります。

Unicodeの事例

この項では、Unicode文字をOracle Databaseに格納する場合の代表的な使用例を説明します。

- 例6-3

- 例6-4

例6-3 Unicode規格対応データベースを使用したUnicodeソリューション

Javaアプリケーションを実行しているある米国の企業では、アプリケーションの次のリリースでドイツ語とフランス語のサポートを追加しようとしています。その後、日本語のサポートを追加する予定です。この会社には、現在次のようなシステム構成があります。

- 既存のデータベースは、US7ASCIIのデータベース・キャラクタ・セットです。

- 既存のデータベースの全文字データは、ASCII文字で構成されています。

- データベースでは、PL/SQLストアド・プロシージャが使用されています。

- CLOB列にごくわずかなデータしか格納しない場合で、データベースはおよそ300GBです。

- 夜間の停止時間は4時間です。

この場合、代表的なソリューションでは、次の理由により、データベース・キャラクタ・セットにAL32UTF8を選択します。

- データベースが非常に大規模で、予定されている停止時間が短いこと。Unicodeキャラクタ・セットへのデータベースの移行の高速化が不可欠です。データベースがUS7ASCIIなので、データベースのUnicode規格のサポートを有効化する最も簡単で迅速な方法は、Database Migration Assistant for Unicode (DMU)を使用して、データベース・キャラクタ・セットをAL32UTF8に切り替えることです。US7ASCIIはAL32UTF8のサブセットなので、CLOB以外の列のデータ変換は不要です。

- コードの大部分がJavaとPL/SQLで記述されているため、データベース・キャラクタ・セットのAL32UTF8への変更によって、既存のコードが無駄になることはないこと。Unicodeサポートはアプリケーションで自動的に有効化されます。

例6-4 Unicodeデータ型を使用したUnicodeソリューション

主としてWindowsプラットフォームでレガシー・アプリケーションを実行しているあるヨーロッパの企業で、Visual C/C++で作成された小さな新しいWindowsアプリケーションを追加する必要があります。このアプリケーションでは、日本語と中国語の顧客名をサポートするために、既存のデータベースが使用されます。この会社には、現在次のようなシステム構成があります。

- 既存のデータベースには、WE8MSWIN1252のデータベース・キャラクタ・セットがあります。

- 既存のデータベースの全文字データは、西ヨーロッパの文字で構成されています。

- 多数のCLOB列がある場合で、データベースはおよそ500GBです。

- 新しいアプリケーションでは、フルテキスト検索とXML記憶域のサポートは必要ありません。

代表的なソリューションでは、次のアクションが実行されます。

- NCHARおよびNVARCHAR2データ型を使用してUnicode文字が格納されます。

- WE8MSWIN1252がデータベース・キャラクタ・セットとして維持されます。

- AL16UTF16が各国語キャラクタ・セットとして使用されます。

このソリューションを選択する理由は、次のとおりです。

- データベース・キャラクタ・セットのWE8MSWIN1252(Windows Latin-1キャラクタ・セット)はAL32UTF8のサブセットでないため、既存のデータベースをUnicodeデータベースに移行するには、データ変換が必要になること。また、多くのデータがCLOB列に格納されます。1バイト・データベース・キャラクタ・セットから移行する場合は(たとえばUS7ASCIIまたはWE8MSWIN1252からAL32UTF8へ)、ASCII文字のみを含む場合でも、データベースのすべてのCLOB値を変換する必要があります。その結果、データをAL32UTF8に変換するときに大きなオーバーヘッドが発生します。

- 追加した言語は、新しいアプリケーションでのみサポートされること。既存のアプリケーションまたはスキーマに依存しません。Unicodeデータ型は新しいスキーマで使用し、既存のスキーマは変更しないままのほうが簡単です。

- Unicodeキャラクタ・セットのサポートが必要なのは、顧客名の列のみであること。1つのNCHAR列のみを使用することで、データベース全体を移行せずに顧客の要件を満たすことができます。

- 新しいアプリケーションでは、SQL NCHARデータ型をサポートしないデータベース機能は必要ありません。

- SQL NCHARデータ型の長さは文字数として定義されること。この処理方法は、Windows C/C++プログラムでwchar_t文字列を使用する場合と同じです。この方法は、プログラミングの複雑さを軽減します。

- 既存のスキーマを使用している既存のアプリケーションに対する影響はないこと。

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

複数言語をサポートするようにデータベース・スキーマを設計する場合は、Unicodeソリューションの選択に加えて、次の問題も考慮する必要があります。

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

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

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

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

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

多言語データの格納にNCHARおよびNVARCHAR2データ型を使用する場合、列に指定するサイズは文字数で定義します。(この文字数はエンコードされたUnicodeコード・ポイントの数を意味しますが、サロゲート・ペアで表現されたUnicode補助文字は2文字として数えます。)表6-2に、AL16UTF16およびUTF8の各国語キャラクタ・セットに対するNCHARおよびNVARCHAR2データ型の最大サイズを示します。

表6-2 データ型の最大サイズ

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

NCHARデータ型の最大列サイズ

NVARCHAR2データ型の最大列サイズ(MAX_STRING_SIZE = STANDARDの場合)

NVARCHAR2データ型の最大列サイズ(MAX_STRING_SIZE = EXTENDEDの場合)

AL16UTF16

1000文字

2000文字

16383文字

UTF8

2000文字

4000文字

32767文字

この最大文字数は制約であり、データ型の容量を保証するものではありません。最大容量は、バイトで表されます。NCHARデータ型の場合、最大容量は2000バイトです。NVARCHAR2の場合、初期化パラメータMAX_STRING_SIZEがSTANDARDに設定されている場合は4000バイト、初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定されている場合は32767バイトです。各国語キャラクタ・セットがAL16UTF16である場合、最大文字数が最大容量のバイト数より多くなることはありません。Oracleにおける意味合いでは、各文字が正確に2バイトを占めるためです。ただし、各国語キャラクタ・セットがUTF8である場合、最大文字数を格納できるのは、これらすべての文字が、ASCII規格に対応するUnicode Basic Latinの範囲にある場合のみです。他のUnicode文字はUTF8ではそれぞれ複数バイトを占めるため、4000文字の文字列にそのような文字があると、文字列の長さが上限の4000バイトより長くなります。各国語キャラクタ・セットの列が、任意の各国語キャラクタ・セットにおいて、宣言された数の文字数を保持できるようにする場合は、2000/3=666文字より長いNCHAR列や、4000/3=1333または32767/3=10922文字(MAX_STRING_SIZE初期化パラメータにより異なる)より長いNVARCHAR2列を宣言しないでください。

多言語データの格納にCHARおよびVARCHAR2のデータ型を使用する場合、各列に指定する最大長は、デフォルトではバイト数で指定します。データベースで、タイ語、アラビア語、あるいは中国語や日本語などのマルチバイトの言語をサポートする必要がある場合は、CHAR、VARCHARおよびVARCHAR2の各列の最大サイズを拡張する必要があります。これは、これらの言語をUTF8またはAL32UTF8でエンコードするためのバイト数が、英語や西ヨーロッパの言語に比較してかなり多いためです。たとえば、タイ語キャラクタ・セットの1つのタイ文字は、UTF8またはAL32UTF8で3バイト必要です。アプリケーション・デザイナは、4000バイトを超えるデータを格納する必要がある場合、拡張文字データ型またはCLOBデータ型を使用することを考慮する必要があります。

関連項目:

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

- MAX_STRING_SIZEの値をEXTENDEDに設定することによる文字データ型の拡張の詳細は『Oracle Databaseリファレンス』を参照してください。

複数言語のデータの格納

Unicodeキャラクタ・セットには、世界中で使用されているほとんどの記述言語の文字が含まれます。ただし、特定の文字が所属している言語に関する情報は含まれません。たとえば、äという文字には、それがスウェーデン語の文字なのかドイツ語の文字なのかに関する情報は含まれません。情報をユーザーが望む言語で表示するには、Unicodeデータベースに格納されているデータに、そのデータが所属している言語の情報をタグ付けする必要があります。

データベース・スキーマがデータを言語に関連付ける方法は多数あります。この先の項では、この目標を達成するための手順例を説明します。

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

製品説明や製品名などのデータの場合は、CHARまたはVARCHAR2のデータ型の言語列(language_id)を製品表に追加して、対応する製品情報の言語を識別できます。これによって、アプリケーションは、必要な言語による情報を取り出すことができます。この言語列に可能な値は、データベースの有効なNLS_LANGUAGE値の3文字の略称です。

関連項目:

NLS_LANGUAGE値とその略称のリストは、「ロケール・データ」を参照してください

ビューを作成して、現在の言語のデータを選択することもできます。次に例を示します。

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列のデータはAL16UTF16キャラクタ・セットで格納されます。つまり、データの変換時には、英語のドキュメントに必要な記憶領域は2倍になります。アジア言語のドキュメントをCLOB列に格納する場合は、同じドキュメントをAL32UTF8を使用してLONG列に格納する場合に比較して、必要な記憶領域が少なくなります。ドキュメントの内容にもよりますが、通常およそ30%少なくなります。

NCLOB形式のドキュメントも、データベース・キャラクタ・セットや各国語キャラクタ・セットに関係なく、AL16UTF16キャラクタ・セットで格納されます。記憶領域の必要量は、CLOBデータの場合と同じです。ドキュメントの内容は、NCLOB列への挿入時に、UTF-16に変換されます。非Unicodeデータベースに多言語ドキュメントを格納する場合は、NCLOBを選択してください。ただし、Oracle Textを使用するNCLOB上でのコンテンツ検索はサポートされません。

BLOB書式のドキュメントは、そのまま格納されます。挿入時および取得時にデータ変換は発生しません。ただし、SQL文字列操作関数(LENGTHやSUBSTRなど)と照合関数(NLS_SORTやORDER BYなど)は、BLOBデータ型に適用できません。

表6-3に、ドキュメント格納時のCLOB、NCLOBおよびBLOBデータ型のメリットとデメリットを示します。

表6-3 ドキュメント格納に関するLOBデータ型の比較

データ型

メリット

デメリット

CLOB

- Oracle Textでのコンテンツ検索サポート

- 文字列操作がサポートされています。

- データベース・キャラクタ・セットに依存します。

- 挿入時にデータ変換が必要です。

- バイナリ・ドキュメントは格納できません。

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 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 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パッケージの使用

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の場合は32000文字、AL16UTF16の場合は8000文字です。実際のデータが最大バイト制限の16000の対象となります。2つのサイズ制限は同時に満たす必要があります。PL/SQLでは、NCHARデータの最大長は32767バイトです。NCHAR変数は32767文字まで定義できますが、実際のデータは32767バイトを超えることはできません。列の長さより短い値を挿入すると、最大文字長と最大バイト長のいずれか小さいほうの値まで空白で埋められます。

注意:

UTF8は可変幅キャラクタ・セットであるため、パフォーマンスに影響する場合があります。NCHARフィールドの空白埋めが過剰に行われると、パフォーマンスが低下します。NVARCHAR2データ型を使用するか、NCHARデータ型のキャラクタ・セットをAL16UTF16に変更することを考慮してください。

NVARCHAR2データ型

NVARCHAR2データ型は、各国語キャラクタ・セットを使用する可変長文字列を指定します。NVARCHAR2列を使用して表を作成するときは、列の最大文字数を指定します。NVARCHAR2の長さは、NCHARの場合と同様に常に文字単位です。続いて、値が列の最大長を超えないかぎり、ユーザーが指定したとおりに各値が列内に格納されます。文字列の値が最大長まで埋め込まれることはありません。

NVARCHAR2列の最大長は、MAX_STRING_SIZE = STANDARDのときに4000文字であり、MAX_STRING_SIZE = EXTENDEDのときに32767文字です。これらの長さは、UTF8を使用した場合に基づいており値は2000文字になりますが、AL16UTF16を使用した場合には16383文字になります。

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 データ型間の変換に関する規則

文

規則

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);

関連項目:

SQL NCHARデータ型の明示的な変換関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

例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', NLS_DATE_LANGUAGE =
'AMERICAN');
END;

例7-3に示したように、SQL NCHARデータ型のデータを明示的な変換関数に渡すことができます。複数の文字列パラメータを使用すると、SQL CHARおよびNCHARデータ型のデータを混在させることができます。

その他のSQL関数

大部分のSQL関数は、SQL NCHARデータ型および混合した文字データ型の引数を取ることができます。戻されるデータ型は、最初の引数の型に基づきます。これらの関数に渡されたNUMBERやDATEなどの非文字列データ型は、VARCHAR2に変換されます。次の例では、「Unicodeデータ型のSQL関数」で作成したcustomer表を使用します。

関連項目:

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

例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の右側に埋め込まれます。

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 Databaseによる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データのバインドと定義

関連項目:

グローバル環境での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に設定してください。

次の表では、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管理者ガイド』を参照してください。

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 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 Databaseの文字データに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列用であるとみなします。その結果、これらの変数をデータベース・キャラクタ・セットに変換しようとします。データがデータベースに到着すると、そのデータベースはデータベース・キャラクタ・セットのデータを各国語キャラクタ・セットに暗黙的に変換します。データベース・キャラクタ・セットが各国語キャラクタ・セットのサブセットの場合は、この変換時にデータが消失する可能性があります。各国語キャラクタ・セットは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開発者ガイド』を参照してください。

コード変更なしの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文字列のバインド変数または定義変数について、次の表に様々な状況に対応する変換手順が要約されています。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ドライバに対しては、次の表に示されている変換手順が使用されます。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 Databaseキャラクタ・セットの間の変換を行います。Java Unicodeキャラクタ・セットとデータベース・キャラクタ・セットの間のラウンドトリップ変換で、Javaに戻された文字データは、情報の一部が消失している場合があります。これは、複数のUnicode文字が、データベース・キャラクタ・セットの1つの文字にマップされた場合に発生します。たとえば、Unicodeの全角のチルド付き文字(0xFF5E)が、OracleのJA16SJISキャラクタ・セットにマップされている場合があります。Unicode文字のラウンドトリップ変換で、このUnicode文字は0x301Cとなります。これは波形のダッシュ(日本語で、一般的に範囲を示す場合に使用されます)で、チルドではありません。

次の図に、チルド文字のラウンドトリップ変換を示します。

図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 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);

次の表に、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 Unicodeデータ型のみが受け入れられます。したがって、割当てを行うSysAllocStringやメモリーを解放するSysFreeStringなどの特別な関数では、BSTR Unicode文字列を操作する必要があります。

ODBCとは異なり、OLE DBではサーバーのデータ型を明示的に指定することはできません。クライアントのデータ型を設定すると、OLE DBドライバは、必要に応じて自動的にデータ変換を実行します。

次の表に、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 単一言語インターネット・アプリケーションのアーキテクチャ

各アプリケーション・サーバーは、処理を受け持つロケール用に構成されます。このデプロイメント・モデルは、インターネット・アプリケーションの1つのインスタンスが中間層のアプリケーションと同じロケールで実行されることを想定しています。

インターネット・アプリケーションは、ロケールに使用されるネイティブ・エンコーディングを使用してバックエンド・データベースにアクセスします。単一言語インターネット・アプリケーションをデプロイするメリットは、次のとおりです。

- 個々のロケールのサポートが異なるサーバーに分離されるため、複数のロケールを異なる場所で独立してサポートでき、それに応じてワークロードを分散できます。たとえば、最初は西欧ロケールをサポートし、その後日本語などのアジア・ロケールをサポートできます。

- 同時に複数のロケールをサポートする作業に伴う複雑さが回避されます。多言語インターネット・アプリケーションに比べると、単一言語インターネット・アプリケーションの場合はコードの記述量が大幅に少なくなります。

単一言語インターネット・アプリケーションをデプロイするデメリットは、次のとおりです。

- 異なるロケールについて複数のサーバーをメンテナンスおよび管理するために、余分な作業が必要です。また、様々なアプリケーション・サーバーに異なる構成が必要です。

- アプリケーション・サーバーの最小必要数は、サイトの通信量がアプリケーション・サーバーの能力に到達するかどうかに関係なく、アプリケーションでサポートされるロケールの数に応じて異なります。

- アプリケーション・サーバーのロード・バランシングは、同じロケールのアプリケーション・サーバーのグループに限定されます。

- アプリケーション・サーバーの複数構成には、より多くのQAリソース(ユーザーおよびマシン)が必要です。様々なロケールで実行されるインターネット・アプリケーションは、対応するアプリケーション・サーバー構成で保証される必要があります。

- 多言語によるコンテンツをサポートするようには設計されていません。たとえば、このモデルでは、日本語とアラビア語のデータを含むWebページをサポートするのは容易ではありません。

サポート対象のロケール数が増えるほど、デメリットがメリットを上回ることになります。単一言語デプロイメント・モデルに伴う制限とメンテナンスのオーバーヘッドを考慮すると、このデプロイメント・アーキテクチャは1つまたは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.6以上の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ソース・コードを示します。

例8-2は、HelloWorldメッセージに対応するWebアプリケーション・ディスクリプタ・ファイルを示しています。

例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コード

<?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アプリケーションに使用できるようになります。次の例は、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ファイルと同じディレクトリに置かれています。次の例は、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サーブレットを有効化する必要があります。次の例に、GDK APIおよびサービスを使用できるよう変更されたJSPを示します。この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ロケールが選択されています。国名は、現在のロケールに基づいて生成されています。

次の例に、ロケール選択リストを構成するコードを示します。

<%!
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アプリケーション用のグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。また、インターネット・アプリケーションをグローバル対応にするために必要な労力が最小限に抑えられます。次の図は、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以降のサーブレット・コンテナをサポートしています。サーブレット・フィルタ機能を使用して、ユーザー・ロケールの判別やコンテンツ・ファイルのキャラクタ・セットの指定などの、透過的なグローバリゼーション操作が実行されます。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 Databaseのロケール名または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では、開発者がJavaキャラクタ・セットの拡張に使用するインタフェースが提供されます。GDKのJava APIは、JDKパッケージjava.nio.charsetで提供されるこのプラグイン機能を使用してOracleのキャラクタ・セットに対する暗黙的なサポートを提供します。J2SE APIにアクセスして、Oracle固有の動作を取得できます。

注意:
GDK Java APIは、バージョン1.6以上のJDKでサポートされています。

図8-7に、GDKキャラクタ・セット変換表がJavaキャラクタ・セット表と同じ方法でJ2SEにプラグインされる状況を示します。このJ2SEの交換可能フレームワークにより、Oracleキャラクタ・セット変換を他のJavaキャラクタ・セット変換と同じ方法で使用できます。

図8-7 Oracleキャラクタ・セット・プラグイン

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 Databaseでは、これらのソートが拡張されており、データベース内で大/小文字を区別しないソートおよび検索機能とアクセントを区別しないソートおよび検索機能が提供されます。GDKのJava APIのOraCollatorクラスを使用すると、Javaアプリケーションでは、大/小文字区別なしのオプションやアクセント区別なしのオプションなど、最新のOracleのバイナリ・ソート機能と言語ソート機能に基づいて情報をソートしたり検索できます。

正規化がソートの重要部分になることがあります。文字の複合と分解はUnicode規格に基づくため、ソートもUnicode規格に依存します。GDKには、複合を実行するメソッドがあります。

注意:

JDKのバージョンごとにサポートするUnicode規格のバージョンが異なる可能性があるので、GDKではUnicode規格の最新バージョン(現時点ではUnicode 6.2)に基づくOraNormalizerクラスを提供しています。

バイナリ・ソートのソート順は、使用中のOracleキャラクタ・セットに基づきます。GDKのJava APIでは、UTFEキャラクタ・セットを除き、すべてのOracleキャラクタ・セットのバイナリ・ソートがサポートされます。GDKのJava APIでサポートされない言語ソートはJAPANESEのみですが、JAPANESE_Mを使用すると、同様でより正確なソート結果を得ることができます。

文字列比較と文字列ソートの例を次に示します。

8-3 文字列の比較および文字列の格納

// 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-4 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-5 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クラスを拡張します。

LCSScan

Language and Character Set File Scanner (Javaバージョン)は、統計に基づくユーティリティであり、不明なファイル・テキストの言語とキャラクタ・セットを判別します。この機能および使用方法は、CバージョンのLanguage and Character Set File Scannerと似ています。

関連項目:

「The Language and Character Set File Scanner」

LCSScanコマンドの構文

Usage: java LCSScan <options>
Example: java LCSScan FILE=test.txt RESULTS=3 SIZE=10000

Keyword   Description                                                (Default)
-------   --------------                                             --------
RESULTS   number of language and character set pairs to return 1..3  1
SIZE      sampling size of the file in bytes                         8192
FORMAT    file format TEXT or HTML                                   TEXT
RATIO     show result ratio YES or NO                                NO
FILE      name of input file
HELP      show help screen                                           this screen

LCSScanの使用例

orai18n-lcsd.jarおよびorai18n-mapping.jarファイルがCLASSPATH内にあることを確認します。

例8-6 LCSScanコマンドでファイル名を指定する例

java oracle/i18n/lcsd/LCSScan FILE=example.txt

この例では、8192バイトのexample.txtファイルがスキャンされます。言語とキャラクタ・セットのペアが1つ戻されます。

例8-7 LCSScanコマンドでファイル名およびサンプリング・サイズを指定する例

java oracle/i18n/lcsd/LCSScan FILE=example.txt SIZE=4096

この例では、4096バイトのexample.txtファイルがスキャンされます。言語とキャラクタ・セットのペアが1つ戻されます。

例8-8 LCSScanコマンドでファイル名および言語とキャラクタ・セットのペアの数を指定する例

java oracle/i18n/lcsd/LCSScan FILE=example.txt RESULTS=3

この例では、8192バイトのexample.txtファイルがスキャンされます。言語とキャラクタ・セットのペアが3つ戻されます。

例8-9 LCSScanコマンドでファイル名および結果比率の表示を指定する例

java oracle/i18n/lcsd/LCSScan FILE=example.txt RATIO=YES

この例では、8192バイトのexample.txtファイルがスキャンされます。言語とキャラクタ・セットのペアが1つ結果比率とともに戻されます。

例8-10 ファイル名および書式のHTMLを指定する例

java oracle/i18n/lcsd/LCSScan FILE=example.html FORMAT=html

この例では、8192バイトのexample.htmlファイルがスキャンされます。このスキャンでは、スキャンする前にHTMLタグが取り除かれるため、より正確な結果を得られます。言語とキャラクタ・セットのペアが1つ戻されます。

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のフル言語名と短縮言語名間をマップするファンクション

- 特定の言語および地域名の言語翻訳を戻すファンクション

- 最も一般的なタイム・ゾーンのリストを戻すファンクション

- 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およびNVARCHAR2では異なるキャラクタ・セットが使用されている場合があるため、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関数を明示的に使用することでオーバーライドできます。

次の例では、NLS_SORTセッション・パラメータを使用したドイツ語ソートを指定しています。

ALTER SESSION SET NLS_SORT = GERMAN;
SELECT * FROM table1
ORDER BY column1;

次の例では、最初に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関数を使用してオーバーライドできます。

次の例では、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週番号に関連する年が、暦年と異なることがあります。たとえば、1988年1月1日は、1987年の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 Databaseでは、バイナリ・データを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 Call Interfaceプログラマーズ・ガイド』

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 キャラクタ・セットの移行

この章では、キャラクタ・セット変換とキャラクタ・セットの移行について説明します。この章の内容は、次のとおりです。

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

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

- データベース・キャラクタ・セットのメタデータの修復

- Language and Character Set File Scanner

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

使用しているデータベースに適切なキャラクタ・セットを選択することは、重要な決定事項です。データベース・キャラクタ・セットの選択時には、次の要因を考慮する必要があります。

- 格納する必要があるデータの型

- データベースで現在および将来対応する必要のある言語

- 各キャラクタ・セットの異なるサイズ要件とその要件がパフォーマンスに与える影響

国際的な汎用性を維持し、最新技術や今後の技術、言語の要件に合せるためにUnicodeを選択することをお薦めします。Unicode規格で規定されているキャラクタ・セットは、使用頻度が高い最近の書き言葉にも、めったに使用されない古い文字にもすべて対応しています。また、技術分野、科学分野、音楽表記などの各種の記号にも対応しています。Java、Windows、HTML、XMLなどの各種技術に固有のキャラクタ・セットであり、また推奨のキャラクタ・セットです。このような汎用キャラクタ・セットは他にありません。さらに、Unicodeは工業分野で大きな支持を受けており、採用する動きが急速に広まっています。

AL32UTF8はOracleが実装したUnicodeであり、ASCII文字の文字コードを1バイト、欧州系の文字と中東地方の言語を2バイト、東南アジア系の言語を3バイトで表現します。したがって、Unicodeの保存に必要な領域は通常、同じ言語で比較した場合に、従来のキャラクタ・セットの必要領域よりも多くなります。

関連するトピックとして、既存のデータベース用の新規キャラクタ・セットの選択があります。既存のデータベース用のデータベース・キャラクタ・セットを変更することを、キャラクタ・セットの移行と呼びます。この場合でも、汎用性と互換性を維持するためにUnicodeに移行することをお薦めします。データベース・キャラクタ・セット間の移行を行う際に、次の要因によるデータの損失を最小限に抑えるようにする必要もあります。

- データの切捨て

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

関連項目:

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

データの切捨て

データベースがバイト・セマンティクスを使用して作成されている場合、CHARおよびVARCHAR2データ型のサイズは、文字単位ではなくバイト単位で指定されます。たとえば、表定義でCHAR(20)と指定すると、文字データを格納するために20バイトが割り当てられます。データベース・キャラクタ・セットでシングルバイト文字コード体系が使用されている場合は、文字数がバイト数と同じであるため、文字の格納時にデータ消失は発生しません。データベース・キャラクタ・セットでマルチバイト・キャラクタ・セットが使用されている場合は、1文字が1バイト以上で構成される場合があるため、バイト数は文字数とは異なります。

新規キャラクタ・セットへの移行時には、既存のCHARおよびVARCHAR2列の列幅を検証することが重要です。これは、マルチバイトを格納する必要があるエンコーディングをサポートするために、列幅の拡張が必要となる場合があるためです。変換によってデータが拡張されると、データが切り捨てられる可能性があります。

つぎの表に、変換を通じてシングルバイト文字がマルチバイト文字になる場合のデータ拡張例を示します。

表11-1 シングルバイトとマルチバイトのエンコーディング

文字

WE8MSWIN 1252エンコーディング

AL32UTF8エンコーディング

ä

E4

C3 A4

ö

F6

C3 B6

©

A9

C2 A9

€

80

E2 82 AC

前述の表の最初の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文字以外の場合は、新規キャラクタ・セットへの移行後に、影響のあるユーザー名とパスワードを再設定する必要があります。

- 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のスーパーセットである必要はありません。

次の図に、著作権記号とユーロ記号が?に変換され、äが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 不適切なキャラクタ・セットの置換

2つ目の問題は、混在するキャラクタ・セットのデータがデータベースにある場合です。たとえば、データ・キャラクタ・セットがWE8MSWIN1252で、ドイツ語とギリシャ語を使用している2つの別々のWindowsクライアントがともに、NLS_LANGキャラクタ・セットとしてWE8MSWIN1252を使用している場合、データベースにはドイツ語とギリシャ語の文字が混在することになります。次の図に、異なるクライアントが、同一データベースの異なるキャラクタ・セットを使用する方法を示します。

図11-3 キャラクタ・セットの混在

データベース・キャラクタ・セットの移行を適切に行うには、この2つの状況の場合、手作業による調整が必要です。これは、Oracle Databaseでは格納されているデータのキャラクタ・セットを判断できないためです。不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。Database Migration Assistant for Unicode(DMU)ソフトウェアを使用して、キャラクタ・セットのUnicodeへの移行中に、無効なキャラクタ・データを処理する方法の詳細は、「既存のデータベースのデータベース・キャラクタ・セットの変更」を参照してください。

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

Oracle Data Pumpを使用している場合に、キャラクタ・セットをシングルバイトからマルチバイトへの移行するときは、データ・ポンプのPL/SQLパッケージを再ロードする必要があります。

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

データベース・キャラクタ・セットの移行は、通常、データ・スキャニング、データ・クレンジング、およびデータ変換の3段階からなる複雑なプロセスになります。

データベース・キャラクタ・セットを変更する前に、考えられるデータベース・キャラクタ・セット変換の問題とデータの切捨てを識別する必要があります。このステップはデータ・スキャニングと呼ばれます。データ・スキャニングによって、データベース・キャラクタ・セットの変更前に、データを新しい文字コード体系に移行するために必要な作業量が識別されます。データ・スキャニング時に検出される例には、列幅の拡張が必要なスキーマ・オブジェクトの数や、変換先の文字レパートリに存在しないデータの分布などがあります。この情報は、データベース・キャラクタ・セットの最適な変換方法の決定に役立ちます。

データの潜在的な問題を特定したら、データ変換時にデータの整合性を保持するために、データをクレンジングする必要があります。検出されたデータの問題の大きさや複雑さによっては、データ・クレンジングの作業にかかる時間と手間が大きくなる可能性があります。データ例外をすべて適切に対処するために、データ・スキャニングとデータ・クレンジングを何回も繰り返す場合があります。

データ変換は、文字データを変換元のキャラクタ・セットから変換先のキャラクタ・セット表現に変換するプロセスです。不適切なデータ変換はデータを破損する恐れがあるため、新規キャラクタ・セットにデータを移行する前に、データベース全体のバックアップを作成します。

データベース・キャラクタ・セットを移行する方法は次の2つです。

- Database Migration Assistant for Unicodeを使用した文字データの移行

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

Database Migration Assistant for Unicodeを使用した文字データの移行

Database Migration Assistant for Unicode(DMU)は、直感的な操作が可能な、ユーザーに親しみやすいGUIを装備しており、そのインタフェースを介して手作業による手間を大幅に減らし、移行作業を正確かつ効率よく実行して、Unicodeに効率よく移行できるようになっています。

次にいくつかのDMUの利点を示します。

- ワークフローに沿って作業できるようになっている
DMUの大きな利点は、処理の論理的な流れに沿って、キャラクタ・セットの移行プロセス全体をユーザーに案内することです。

- それぞれの問題に応じた対処方法を提案する
データ・スキャニングやデータ・クレンジングの実行中にエラーや障害などの問題が発生した場合に、DMUはユーザーを支援します。

- データ変換の選択肢を提示する
DMUは、変換が必要なデータのみに絞って、表レベル、列レベル、および行レベルでデータを変換できます。

- プロセスの状況を監視する
DMUは、処理の進行状況をわかりやすく表示するGUIを備えています。

- 対話型の表示機能を備えている
DMUにより、対話型のGUIを介してデータの分析と結果の確認を行うことができます。また、データ自体を確認したり、特定した移行上の問題を対話形式で解決したりすることもできます。

- インライン変換のみをツールでサポート
DMUを使用した場合、Oracle Databaseはデータベースの内容のインライン変換をサポートします。今までの他の変換方式よりもパフォーマンス面でもセキュリティ面でも優れています。

- クレンジングの処理を変換ステップの後の方に回すことができる
データ型の移行などのクレンジングの処理を後に回せば、実際に移行を行う停止期間に入るまでは、本番用のデータベースとアプリケーションは移行の影響を受けずに済みます。

このリリースのDatabase Migration Assistant for Unicodeには、変換できるデータベースについて、いくつかの制約があります。特に、データ・ディクショナリ内に特定のタイプの変換可能データがあるデータベースを変換しません。エクスポート/インポート移行方式を使用すれば、このような制限事項を解消できます。

現在のデータベース・リリースでは、DMUは$ORACLE_HOME/dmuディレクトリにインストールされます。

関連項目:

『Oracle Database Migration Assistant for Unicodeガイド』

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

全体エクスポートと全体インポートは、データベースを新しいキャラクタ・セットに変換する際にも使用できます。別々のターゲット・インスタンスを設定する必要があるため、時間も長くかかり、リソースも大量に必要になる場合があります。データをUnicode以外のキャラクタ・セットに移行する場合は、あまりお薦めできませんが、DMUを使用して、データベース内に無効な文字表現がないかどうかを調べてから、データ変換にエクスポートとインポートを使用することは可能です。Unicodeに移行しない場合は、データのサイズ超過の問題(列およびデータ型の制限に対する違反)をDMUが正確には検出しないことに注意してください。また、ソースのデータベース・キャラクタ・セットにはあっても、ターゲットのUnicode以外のキャラクタ・セットにはない文字を識別しません。

関連項目:

エクスポート・ユーティリティとインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください

データベース・キャラクタ・セットのメタデータの修復

データベースが、一般的にパススルー構成と呼ばれる構成になっていて、クライアントのキャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されている(通常はNLS_LANGクライアント設定になっている)場合は、データベースの文字データが、宣言されているデータベース・キャラクタ・セットとは異なるキャラクタ・セットで格納されている可能性があります。このような場合には、データベース・キャラクタ・セットの特性がデータの実際のキャラクタ・セットを示すと仮定し、DMUを使用して、データベースをUnicodeに移行することをお薦めします。業務上の制約または技術的な制約により、すぐにはUnicodeに移行できない場合は、最低限、データベース・キャラクタ・セットの宣言をデータベースの内容に合せる必要があります。

そのような場合、Database Migration Assistant for Unicodeリリース1.2では、CSREPAIRスクリプトを使用してデータベース・キャラクタ・セット・メタデータを修復できます。CSREPAIRスクリプトは、DMUクライアントと連携して動作し、DMUのリポジトリにアクセスします。これを使用して、データベース・キャラクタ・セットの宣言をデータの実際のキャラクタ・セットに変更できますが、それができるのは、前提とするデータベース・キャラクタ・セット・プロパティをターゲットのキャラクタ・セットに設定した状態でDMUによるデータベースの全体スキャンが完了し、さらに、表現の問題が報告されず、データベース内に存在するデータがすべて、前提とするデータベース・キャラクタ・セットに従って定義されていることが検証される場合にかぎられます。CSREPAIRは、データ・ディクショナリのメタデータ内にあるデータベース・キャラクタ・セットの宣言のみを変更し、データベースのデータを変換しないことに注意してください。

CSREPAIRスクリプトは、インストールされたDMUのadminサブディレクトリにあります。CSREPAIRスクリプトを使用するときの要件は次のとおりです。

1. まず、前提とするデータベース・キャラクタ・セット・プロパティをデータの実際のキャラクタ・セットに設定した状態で、DMUでデータベース全体のスキャンを正常に完了させる必要があります。この場合は、前提とするデータベース・キャラクタ・セットが現在のデータベース・キャラクタ・セットと異なる必要があり、そうでなければ、何も実行されません。DMUが無効なデータの存在を報告する場合は、CSREPAIRスクリプトの処理が中断されます。ただし、スキャンで、変更不要データまたは変換可能なデータが検出された場合は処理が継続されます。

2. 前提とするデータベース・キャラクタ・セットに属するターゲット・キャラクタ・セットは、US7ASCIIのバイナリ・スーパーセットにする必要があります。

3. CLOB型のデータは変換の対象にならないため、シングルバイト・キャラクタ・セット間の修復またはマルチバイト・キャラクタ・セット間の修復のみが可能です。

4. 前提とするキャラクタ・セットを列レベルで設定する場合、前提とするデータベース・キャラクタ・セットと値を同じにする必要があります。そうでなければ、CSREPAIRは実行されません。

5. CSREPAIRを実行するためのSYSDBA権限が必要です。

例: CSREPAIRの使用

一般的な例として、パススルー構成でWE8MSWIN1252データをWE8ISO8859P1データベースに格納するケースを示します。データベース・キャラクタ・セットをWE8ISO8859P1からWE8MSWIN1252に修正する手順は、次のとおりです。

1. DMUをセットアップし、ターゲットのWE8ISO8859P1データベースに接続します。

2. DMUの「データベース・プロパティ」タブを開きます。

3. 前提とするデータベース・キャラクタ・セット・プロパティをWE8MSWIN1252に設定します。

4. DMUを使用して、データベースの全体スキャンを実行します。

5. データベース・スキャン・レポートを開き、無効な表現カテゴリにデータが表示されていないことを確認します。

6. DMUクライアントを終了します。

7. SQL*Plusユーティリティを起動し、SYSDBA権限を持つユーザーになった状態で接続します。

8. 次のCSREPAIRスクリプトを実行します。

SQL> @@CSREPAIR.PLB

完了すると、次のメッセージが表示されます。

データベース・キャラクタ・セットは問題なくWE8MSWIN1252に変更されています。データベースを今すぐ再起動する必要があります。

9. データベースを停止して再起動します。

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コマンドの使用

例11-1 LCSSCANコマンドでファイル名のみを指定する例

LCSSCAN FILE=example.txt

この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.txtファイル全体がスキャンされます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。

例11-2 書式をHTMLに指定する例

LCSSCAN FILE=example.html FORMAT=html

この例では、BEGINおよびENDパラメータがどちらも指定されていないため、example.htmlファイル全体がスキャンされます。このスキャンでは、スキャンする前にHTMLタグが取り除かれるため、より正確な結果を得られます。RESULTSパラメータが指定されていないため、言語とキャラクタ・セットのペアが1つ戻されます。

例11-3 LCSSCANに対してRESULTSおよびBEGINパラメータを指定する例

LCSSCAN RESULTS=2 BEGIN=50 FILE=example.txt

スキャン処理はファイルの50バイト目から始まり、ファイルの終わりまで続行されます。言語とキャラクタ・セットのペアが2つ戻されます。

例11-4 LCSSCANに対してRESULTSおよびENDパラメータを指定する例

LCSSCAN RESULTS=3 END=100 FILE=example.txt

スキャン処理はファイルの先頭から始まり、ファイルの100バイト目で終了します。言語とキャラクタ・セットのペアが3つ戻されます。

例11-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.

原因: 入力されたテキストが短いため、結果を生成できません。

処置: 信頼できる結果を生成するには、より大きいサンプル・テキストを入力する必要があります。

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

この章では、ロケール・データのカスタマイズ方法について説明します。この章の内容は、次のとおりです。

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

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

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

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

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

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

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

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

- 同一プラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

- 別のプラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

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

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

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 6.2のほとんどの文字をサポートしているためです。

インストールした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を起動すると、図12-1の画面が表示されます。

図12-1 Oracle Locale Builderユーティリティ

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

Oracle Locale Builderでの特定のタスクを使用する前に、次のようなタブ・ページとダイアログ・ボックスについて理解しておく必要があります。

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

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

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

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

注意:

Oracle Locale Builderには、オンライン・ヘルプが付属しています。

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

「新規言語」、「新規地域」、「新規キャラクタ・セット」または「新規言語ソート」を選択すると、最初に「一般」タブ・ページが表示されます。「既存の定義の表示」をクリックすると、「既存の定義」ダイアログ・ボックスが表示されます。

「既存の定義」ダイアログ・ボックスでは、ロケール・オブジェクトを名前でオープンできます。起動する特定の言語、地域、言語ソート(照合)またはキャラクタ・セットがわかっている場合は、表示されている名前をクリックします。たとえば、図12-2では、AMERICAN言語定義ファイルをオープンできます。

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

「AMERICAN」を選択すると、lx00001.nlbファイルがオープンします。NLBファイルは、特定の言語、地域、キャラクタ・セットまたは言語ソートの設定を含むバイナリ・ファイルです。

言語と地域の略称は参照用のため、オープンできません。

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

「ツール」→「ログの表示」を選択すると、「セッション・ログ」ダイアログ・ボックスが表示されます。「セッション・ログ」ダイアログ・ボックスには、現行のセッションで行われた処理が表示されます。「ログの保存」をクリックすると、すべての変更のレコードが保存されます。図12-3に、セッション・ログの例を示します。

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

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

NLT(National Language Text)ファイルは、ファイル拡張子が.nltのXMLファイルで、特定の言語、地域、キャラクタ・セットまたは言語ソートの設定を格納します。「NLTのプレビュー」タブ・ページには、ファイルが読取り可能な書式で表示されるため、変更内容が適切かどうかを確認できます。「NLTのプレビュー」タブ・ページからはNLTファイルを変更できません。NLTファイルを変更するには、Oracle Locale Builderで提供される特定のツールとプロシージャを使用する必要があります。

図12-4に、ユーザー定義言語AMERICAN FRENCHの「NLTのプレビュー」タブ・ページの例を示します。

図12-4 NLTファイルのプレビュー

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

「ファイル」→「開く」→ファイル名で指定を選択すると、「ファイルを開く」ダイアログ・ボックスを表示できます。次に、変更あるいはテンプレートとして使用するNLB(National Language Binary)ファイルを選択します。NLBファイルは、ファイル拡張子が.nlbのバイナリ・ファイルで、そのNLTファイル内の情報に相当するバイナリが含まれています。図12-5に、lx00001.nlbファイルが選択されているファイルを開くダイアログ・ボックスを示します。「プレビュー」ペインは、このNLBファイルがAMERICAN言語用であることを示しています。

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

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

この項では、フランス語に基づいて新規言語を作成する方法について説明します。この新しい言語は、AMERICAN FRENCHと呼ぶことにします。最初に、「既存の定義」ダイアログ・ボックスからFRENCHをオープンします。次に、「一般」タブ・ページで言語名をAMERICAN FRENCHに変更し、「言語の略称」を「AF」に変更します。他の設定はデフォルト値のままにします。図12-6に、設定後の「一般」タブ・ページを示します。

図12-6 言語の一般情報

言語などのロケール・オブジェクトの名前を選択するときには、次の制限事項が適用されます。

- 名前にはASCII文字のみを使用する必要があります。

- 名前は文字で開始する必要があります。

- 言語、地域およびキャラクタ・セット名にはアンダースコアを使用できません。

ユーザー定義言語の場合、「言語ID」フィールドの有効範囲は1,000から10,000です。Oracle Locale Builderで提供される値を受け入れるか、この範囲内の値を指定できます。

注意:

特定のID範囲は、ユーザー定義のLANGUAGE、TERRITORY、CHARACTER SET、MONOLINGUAL COLLATIONおよびMULTILINGUAL COLLATIONの定義に対してのみ有効です。この章の各項では、各タイプのユーザー定義ロケール・オブジェクトに関係する範囲が指定されています。

図12-7に、「月名」タブ・ページを使用して月の名前を設定する方法を示します。

図12-7 「月名」タブ・ページ

すべての名前は、NLTファイルに表示されているとおりに示されます。先頭の文字を大文字にするかどうかに対して「はい」を選択すると、アプリケーションでは月の名前の先頭に大文字が使用されますが、「月名」タブ・ページでは大文字で表示されません。

図12-8に、「曜日」タブ・ページを示します。

図12-8 「曜日」タブ・ページ

ユーザー定義言語に曜日名を選択できます。すべての名前は、NLTファイルに表示されているとおりに示されます。先頭の文字を大文字にするかどうかに対して「はい」を選択すると、アプリケーションでは曜日名の先頭に大文字が使用されますが、曜日タブ・ページでは大文字で表示されません。

図12-9に、「共通情報」タブ・ページを示します。

図12-9 「共通情報」タブ・ページ

現在の言語に関連付けられている地域、キャラクタ・セット、Windows用キャラクタ・セットおよび言語ソートを表示できます。通常、最も適切な項目または最も一般的に使用されている項目が、最初に表示されます。たとえば、FRENCH言語では、共通地域はFRANCE、BELGIUM、CANADAおよびDJIBOUTIで、サポートされているキャラクタ・セットは、WE8ISO8859P1、WE8MSWIN1252、AL32UTF8およびWE8ISO8859P15です。Windows環境では、WE8ISO8859P1よりもWE8MSWIN1252が一般的であるため、最初に表示されます。

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

この項では、新規の地域REDWOOD SHORESを作成し、地域の略称としてRSを使用する方法について説明します。新規の地域は、既存の地域定義に基づいていません。

基本タスクは次のとおりです。

- 地域名の割当て

- カレンダ、数値、日付、時刻および通貨の各書式の選択

図12-10に、「地域名」としてREDWOOD SHORES、「地域ID」として1001、「地域の略称」としてRSが設定されている「一般」タブ・ページを示します。

図12-10 地域の「一般」タブ・ページ

ユーザー定義地域に対する「地域ID」フィールドの有効範囲は、1000から10000です。

図12-11に、「暦」タブ・ページのカレンダ書式の設定を示します。

図12-11 カレンダ書式の選択

月曜日が週の開始日として設定され、暦年の第1週がISO週として設定されています。図12-11には、サンプル・カレンダを示しています。

関連項目:

- 週の開始日と暦年の第1週を選択する方法の詳細は、「カレンダ書式」を参照してください

- カレンダ自体をカスタマイズする方法は、「NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ」を参照してください

図12-12に、「日付と時間」タブ・ページを示します。

図12-12 日付書式と時刻書式の選択

リストから書式を選択すると、書式の例が表示されます。このケースでは、短い日付書式がDD-MM-YY、短い時間書式がHH24:MI:SS、Oracle日付書式がDD-MM-YY、長い日付書式がfmDay, Month dd, yyyyに設定されています。タイムスタンプ・タイムゾーン書式は設定されていません。

ドロップダウン・メニューから選択せずに、独自のフォーマットを入力することもできます。

関連項目:

- 「日付書式」

- 「時刻書式」

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

図12-13に、「数値」タブ・ページを示します。

図12-13 数値書式の選択

「小数点記号」にはピリオドが選択されています。負の記号の位置は数値の左に設定されています。数値グループ・セパレータはカンマです。数値グループ化は3桁、リスト・セパレータはカンマ、測定法はメトリック、丸め指定は4に指定されています。

リストの値を使用せずに、独自の値を入力することもできます。

リストから書式を選択すると、書式の例が表示されます。

関連項目:

「数値書式」

図12-14に、「通貨」タブ・ページの通貨書式の設定を示します。

図12-14 通貨書式の選択

各国通貨記号には$が設定されています。代替通貨記号はユーロ記号です。通貨表記には、各国通貨記号、借方記号および数値が順に並びます。「小数点記号」はピリオド、「グループ・セパレータ」はカンマ、通貨数値のグループ化は3です。通貨の精度、つまり小数点以下の桁数は3です。貸方記号は+、借方記号は-です。国際通貨セパレータは空白であるため、フィールドには表示されていません。国際通貨記号(ISO通貨記号)はUSDです。Oracle Locale Builderには、ユーザーが選択した通貨書式の例が表示されます。

リストを使用せずに、独自の値を入力することもできます。

関連項目:

「通貨書式」

図12-15に、「共通情報」タブ・ページを示します。

図12-15 「共通情報」タブ・ページ

現在の地域の共通言語と共通タイム・ゾーンを表示できます。たとえば、地域がCANADAの場合、共通言語はENGLISH、CANADIAN FRENCHおよびFRENCHです。共通タイム・ゾーンは、America/Montreal、America/St_Johns、America/Halifax、America/Winnipeg、America/Regina、America/EdmontonおよびAmerica/Vancouverです。

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

Oracle Locale Builderでは、キャラクタ・セットのコード・チャートを表示して印刷できます。Oracle Locale Builderの初期画面から「ファイル」→「新規」→「キャラクタ・セット」を選択します。図12-16に、表示される画面を示します。

図12-16 キャラクタ・セットの「一般」タブ・ページ

「既存の定義の表示」をクリックします。表示するキャラクタ・セットを選択します。図12-17に、US7ASCIIが選択されている「既存の定義」ダイアログ・ボックスを示します。

図12-17 「既存の定義」ダイアログ・ボックスでのUS7ASCIIの選択

「開く」をクリックしてキャラクタ・セットを選択します。図12-18に、US7ASCIIが選択されている「一般」タブ・ページを示します。

図12-18 US7ASCIIが選択されている「一般」タブ・ページ

「文字データのマッピング」タブをクリックします。図12-19に、US7ASCIIの「文字データのマッピング」タブ・ページを示します。

図12-19 US7ASCIIの「文字データのマッピング」タブ・ページ

「コード・チャートの表示」をクリックします。図12-20に、US7ASCIIのコード・チャートを示します。

図12-20 US7ASCIIコード・チャート

このコード・チャートは、ローカル・キャラクタ・セットでの各文字のエンコーディング値、各文字に関連付けられた絵文字、およびUnicode値を示しています。

コード・チャートを印刷する場合は、「ページの印刷」をクリックします。

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

特定のユーザーのニーズにあわせてキャラクタ・セットをカスタマイズできます。エンコードされた既存のキャラクタ・セット定義を拡張できます。ユーザー定義文字は、多くの場合、次のような文字要素を表現する特殊文字をエンコードするために使用されます。

- 固有名

- 既存のキャラクタ・セット規格で定義されていない旧漢字

- ベンダー固有の文字

- ユーザーが新たに定義した記号または文字

この項では、Oracle Databaseでユーザー定義文字がどのようにサポートされているかを説明します。次のトピックが含まれています:

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

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

- Unicode 6.2のPrivate Use Area

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

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

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

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

一般的に、ユーザー定義文字は東アジア諸国のキャラクタ・セットでサポートされています。東アジア諸国のキャラクタ・セットには、ユーザー定義文字を使用するために、コード・ポイントの予約域が少なくとも1つ用意されています。たとえば、日本語シフトJISでは、1880のコード・ポイントがユーザー定義文字用に確保されています。表12-1を参照してください。

表12-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

表12-2に示すOracleキャラクタ・セットには、ユーザー定義文字をサポートする事前定義済の範囲が含まれています。

表12-2 ユーザー定義文字の範囲を含むOracle Databaseのキャラクタ・セット

キャラクタ・セット名

ユーザー定義文字に使用可能なコード・ポイント数

JA16DBCS

4370

JA16EBCDIC930

4370

JA16SJIS

1880

JA16SJISYEN

1880

KO16DBCS

1880

KO16MSWIN949

1880

ZHS16DBCS

1880

ZHS16GBK

2149

ZHT16DBCS

6204

ZHT16MSWIN950

6217

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

特定の文字を表すコード・ポイントの値は、キャラクタ・セットによって異なります。次の図に、日本語の漢字を示します。

図12-21 日本語の漢字

次の表に、この文字が様々なキャラクタ・セットでどのようにエンコードされるかを示します。

Unicodeエンコーディング

JA16SJISエンコーディング

JA16EUCエンコーディング

JA16DBCSエンコーディング

4E9C

889F

B0A1

4867

Oracle Databaseでは、すべてのキャラクタ・セットをUnicode 7.0のコード・ポイントの見地から定義しています。つまり、それぞれの文字はUnicode 7.0のコード値として定義されています。中間フォームとしてUnicodeを使用することによって、ユーザーが意識することなく文字変換が行われます。たとえば、JA16SJISのクライアントがJA16EUCのデータベースに接続する場合、JA16SJISのクライアントから入力した前述の図の日本語の漢字のコード・ポイント値は889Fとなります。この文字は内部的にUnicode(コード・ポイント値は4E9C)に変換された後、JA16EUC(コード・ポイント値はB0A1)に変換されます。

Unicode 6.2のPrivate Use Area

Unicode 6.2では、Private Use Area(PUA)用にE000からF8FFの範囲が予約されています。PUAは、エンド・ユーザーまたはベンダーがプライベートで使用する文字を定義するためのものです。

ユーザー定義文字は、標準文字と同様に中間フォームとしてUnicode 6.2のPUAを使用して、2つのOracle Databaseキャラクタ・セット間で変換されます。

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

ユーザー定義文字を複数のオペレーティング・システムにまたがって登録する場合は、異なるキャラクタ・セット間のクロス・リファレンスが必要になります。クロス・リファレンスにより、キャラクタ・セットがUnicode PUAの値にマッピングされ、ユーザー定義文字を異なるキャラクタ・セット間で確実に正しく変換できます。

たとえば、ユーザー定義文字を日本語シフトJISのオペレーティング・システムと日本語IBMホスト・オペレーティング・システムの両方に登録する場合、この文字に対して、シフトJISのオペレーティング・システムではF040コード・ポイント、IBMホスト・オペレーティング・システムでは6941コード・ポイントの割当てができます。これによって、キャラクタ・セットJA16SJISとJA16DBCSの間で、この文字が正しくマップされます。

Oracle Locale Builderを使用してキャラクタ・セット定義を表示すると、ユーザー定義文字のクロス・リファレンス情報を検索できます。たとえば、シフトJISのUDC値F040とIBMホストのUDC値6941が、同じUnicode PUA値E000にマップされていることがわかります。

関連項目:

Unicode文字コードの割当て

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

デフォルトの場合、Oracle Locale Builderは次に使用可能なキャラクタ・セットIDを生成します。独自のキャラクタ・セットIDを選択することもできます。キャラクタ・セット定義用NLTファイルのネーミングには、次の書式を使用します。

lx2dddd.nlt

ddddは、16進数で4桁のキャラクタ・セットIDです。

キャラクタ・セットを変更する場合は、次のガイドラインに従ってください。

- 既存の文字を再マップしないでください。

- すべての文字のマッピングは一意であることが必要です。

- 新規文字は、Unicodeのプライベート使用範囲(e000からf4ff)にマップする必要があります。(実際のUnicode 6.2のプライベート使用範囲はe000からf8ffです。ただし、f500からf8ffはOracle Database固有のプライベート使用のために予約されています。)

- キャラクタ・セット定義ファイルでは、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文字を追加します。

図12-22に、MYCHARSETの「一般」タブ・ページを示します。

図12-22 MYCHARSETの「一般」タブ・ページ

「既存の定義の表示」をクリックし、「既存の定義」ダイアログ・ボックスからWE8ISO8859P1キャラクタ・セットを選択します。

「ISOキャラクタ・セットID」フィールドと「基本キャラクタ・セットID」フィールドはオプションです。「基本キャラクタ・セットID」は値の継承に使用され、基本キャラクタ・セットのプロパティがテンプレートとして使用されます。「キャラクタ・セットID」は自動的に生成されますが、オーバーライドして変更することもできます。ユーザー定義キャラクタ・セットIDの有効範囲は、8000から8999または10000から20000です。

注意:

Pro*COBOLを使用している場合は、8000から8999のキャラクタ・セットIDを選択してください。

ユーザー定義キャラクタ・セットの場合、「ISOキャラクタ・セットID」フィールドは空白のままです。

この例では、「基本キャラクタ・セットID」フィールドは空白のままです。ただし、テンプレートとして使用するキャラクタ・セットを指定できます。「型指定」タブ・ページの設定は、「基本キャラクタ・セットID」フィールドに入力した基本キャラクタ・セットの型設定と一致する必要があります。型設定が一致しない場合、カスタム・キャラクタ・セットの生成時にエラーが表示されます。

図12-23に、「型指定」タブ・ページを示します。

図12-23 「型指定」タブ・ページ

キャラクタ・セット・カテゴリはASCII_BASEDで、「BYTE_UNIQUE」ボタンが選択されています。

既存のキャラクタ・セットを選択した場合、「型指定」タブ・ページのフィールドはすでに適切な値に設定されています。変更する特別な理由がないかぎり、これらの値を保持してください。設定の変更が必要な場合は、次のガイドラインを使用します。

- 「FIXED_WIDTH」は、同じ長さの文字のキャラクタ・セットを示すために使用します。

- 「BYTE_UNIQUE」は、コード・ポイントのシングルバイト範囲がマルチバイト範囲と区別されていることを示します。先頭バイトのコードは、その文字がシングルバイトかマルチバイトかを示します。例: JA16EUC。

- 「DISPLAY」は、格納用ではなくクライアントでの表示用にのみ使用されるキャラクタ・セットを示します。一部のアラビア語、デーバナーガリ語およびヘブライ語のキャラクタ・セットは、表示用キャラクタ・セットです。

- 「SHIFT」は、シングルバイト文字とマルチバイト文字とを区別するために、追加のシフト文字が必要なキャラクタ・セットに対して使用します。

図12-24に、ユーザー定義文字の追加方法を示します。

図12-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

「ファイル」→「インポート」→「ユーザー定義文字データ」を選択します。

図12-25に、インポートした文字をキャラクタ・セットの0xffの後に追加した状態を示します。

図12-25 キャラクタ・セットの新しい文字

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

この項では、「照合ID」を10001に設定してMY_GENERIC_Mと呼ばれる新規の多言語ソートを作成する方法を示します。新規言語ソートの基礎としてGENERIC_M言語ソートを使用しています。図12-26に、この操作の開始方法を示します。

図12-26 照合の「一般」タブ・ページ

フラグの設定は、自動的に導出されます。「SWAP_WITH_NEXT」は、タイ語とラオ語のソートに関係します。「REVERSE_SECONDARY」は、フランス語のソート用です。「CANONICAL_EQUIVALENCE」は、標準的な規則を使用するかどうかを決定します。この例では、「CANONICAL_EQUIVALENCE」がオンになっています。

ユーザー定義ソートのための「照合ID」(ソートID)の有効範囲は、単一言語照合の場合は1000から2000、多言語照合の場合は10000から11000です。

関連項目:

- 標準的な規則の詳細は、図12-30を参照してください

- 言語ソートと照合

図12-27に、「Unicode照合順序」タブ・ページを示します。

図12-27 「Unicode照合順序」タブ・ページ

この例では、文字の後にソートされるように数字を移動して、言語ソートをカスタマイズします。手順は次のとおりです。

1. 移動するUnicode値を選択します。図12-27では、\x0034 Unicode値が選択されています。「Unicode照合順序」タブ・ページでの値の位置は、ノードと呼ばれます。

2. 「切取り」をクリックします。ノードを移動する位置を選択します。

3. 「貼付け」をクリックします。「貼付け」をクリックすると、図12-28に示す「ノードの貼付け」ダイアログ・ボックスがオープンします。

図12-28 「ノードの貼付け」ダイアログ・ボックス

- 「ノードの貼付け」ダイアログ・ボックスでは、選択した位置の後にノードを貼り付けるか前に貼り付けるかを選択できます。隣に貼り付けるノードに対するノードのレベル(1次、2次または3次)を選択することもできます。
ノードを貼り付ける位置とレベルを選択します。

図12-28では、「後」ボタンと「1次」ボタンが選択されています。

- 「OK」をクリックしてノードを貼り付けます。
同様の手順に従って、他の数字を文字aからzの後の位置に移動します。

図12-29に、数字0から4を文字aからzの後の位置に移動した後の「Unicode照合順序」タブ・ページを示します。

図12-29 変更後の「Unicode照合順序」画面

この項の残りの部分は、次のトピックで構成されます。

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

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

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

次の例に、発音区別記号付きの文字のソート順序を変更する方法を示します。そのためには、特定の発音区別記号を含むすべての文字のソート順序を変更する方法と、一度に1文字ずつ変更する方法があります。この例では、曲折アクセント記号付きの各文字(ûなど)のソート順序を、チルドが付いた同じ文字の後になるように変更します。

「ツール」→「標準規則」を選択して、現在のソート順序を確認します。図12-30の「標準規則」ダイアログ・ボックスが開きます。

図12-30 「標準規則」ダイアログ・ボックス

図12-30に、アクセント記号付き文字が、対応する標準的な文字に分解される方法と現在のソート順序を示します。たとえば、ûはuと ^の組合せとして表されます。

関連項目:

標準的な規則の詳細は、「言語ソートと照合」を参照してください

Oracle Locale Builderの照合の「一般」タブ・ページ(図12-26)で、「空白以外の文字」タブをクリックします。「空白以外の文字」タブ・ページを使用すると、発音区別記号に対する変更がすべての文字に適用されます。図12-31に、「空白以外の文字」タブ・ページを示します。

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

曲折アクセント記号を選択して「切取り」をクリックします。「削除の確認」ダイアログ・ボックスで「はい」をクリックします。チルドを選択して「貼付け」をクリックします。「ノードの貼付け」ダイアログ・ボックスで「後」と「2次」を選択して「OK」をクリックします。

図12-32に、新しいソート順序を示します。

図12-32 同じ発音区別記号を持つ文字の新規のソート順序

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

発音区別記号を持つ特定の文字の順序を変更するには、その文字を適切な位置に直接挿入します。発音区別記号付きの文字は「Unicode照合順序」タブ・ページに表示されないため、新しい位置へのカット・アンド・ペーストはできません。

この例では、äのソート順序をZの後にソートされるように変更します。

「Unicode照合」タブをクリックします。äの隣に配置する文字Zを選択します。「追加」をクリックします。図12-33の「新規ノードの挿入」ダイアログ・ボックスが表示されます。

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

「新規ノードの挿入」ダイアログ・ボックスで「後」と「1次」を選択します。äのUnicodeコード・ポイント値を入力します。このコード・ポイント値は、\x00e4です。「OK」をクリックします。

図12-34に、変更後のソート順序を示します。

図12-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ファイルが格納されているディレクトリを検索します。位置を指定するダイアログ・ボックスは、図12-35のとおりです。

図12-35 「位置」ダイアログ・ボックス

NLTファイルは指定しないでください。Oracle Locale Builderは、各NLTファイルに対してNLBファイルを生成します。

4. 「OK」をクリックしてNLBファイルを生成します。

図12-36は、ディレクトリ内の全NLTファイルに対してNLBファイルが正常に生成されたことを示す最終的な通知を示しています。

図12-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

注意:

NLTファイルが収容されているディレクトリにNLBファイルが生成されます。

7. 新規に作成したロケール・データを使用できるように、データベースを再起動します。

8. 新規のロケール・データをクライアント側で使用するには、NLBファイルをインストールしてからクライアントを終了し、再起動します。

関連項目:

ORA_NLS10環境変数の詳細は、「オンデマンドのロケール・データ」を参照してください

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

ロケール定義ファイルは、データベースのリリースに依存しています。たとえば、Oracle Database 9iおよびOracle Database 10gのNLBファイルは、Oracle Database 11のインストール環境などで直接サポートされていません。不具合の修正が必要になっても、パッチ・セット内のNLBファイルの形式が若干、変更されていることがあります。パッチ・セットに収容されているOracle提供のNLBファイルのいずれかが変更されている場合は、パッチ・セットまたはパッチ・セット更新(PSU)をインストールしたときに、ユーザーが設定した内容が上書きされる可能性があります。

ロケール・カスタマイズ・ファイルを現行リリースのデータベースから最新のリリースまたはパッチ・セットに移行する手順は、次のとおりです。

1. ディレクトリをコピーし、カスタマイズしたNLBファイルまたはNLTファイルをそのディレクトリにコピーします。

2. 最新リリースのデータベース、パッチ・セットまたはパッチ・セット更新を、必要に応じて既存のOracleホームまたは新しいOracleホームにインストールします。

3. 新しいOracleホームまたは更新後のOracleホームのOracle Locale Builderを使用して、手順(1)でコピーしたファイルをそれぞれ開き、コピー元のディレクトリにNLT形式で保存します。

4. 「NLBファイルの生成とインストール」の項の説明に従って、ここでも最新バージョンのOracle Locale Builderと同じコピー元のディレクトリを使用して、NLBの生成とインストールの手順を繰り返します。

Oracle Locale Builderは、旧バージョンのNLTファイルおよびNLBファイルの読込みと処理、さらに別のプラットフォームからのこれらのファイルの読込みと処理が可能である点に注意してください。ただし、Oracle Locale Builderでは、インストールされているOracle Databaseのリリースの最新の書式でNLTファイルが保存され、NLBファイルが生成されます。

同一プラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

デプロイ元のカスタマイズの生成に使用するOracleホームと、データベースのリリース、パッチの構成、およびプラットフォームがまったく同じ別のOracleホームに、カスタマイズを追加する手順は、次のとおりです。

1. ターゲットのOracleホームで、「NLBファイルの生成とインストール」の手順1を実行します。

2. ターゲットのOracleホームが別のマシン上にある場合は、FTPのバイナリ・モード、リモートにマウントされたファイル・システムへのコピー、rcpユーティリティのように、ファイルのバイナリ・レベルの整合性が維持される方式を使用して、カスタマイズしたNLBファイルと生成したlx1boot.nlbファイルをターゲットのコンピュータにコピーします。

3. ターゲットのコンピュータで、カスタマイズしたNLBファイルとlx1boot.nlbファイルを収容しているディレクトリをdirectory_nameとして使用して、「NLBファイルの生成とインストール」の手順5から8までを実行します。

別のプラットフォーム上のOracleインストール環境に対するカスタムNLBファイルのデプロイ

NLBファイルはリリースに応じて異なりますが、プラットフォームには依存しません。プラットフォームごとのバイナリ形式の違い(32ビットと64ビット、ビッグ・エンディアンとリトル・エンディアン、ASCIIとEBCDIC)は、NLBのロード時には透過的に処理されます。したがって、ロケール・カスタマイズ・ファイルを、Oracle Databaseのリリースとパッチ構成が同じで、オペレーティング・システム・プラットフォームが異なる別のOracle Databaseインストール環境にデプロイする場合は、次の2つの選択肢の中からいずれかを選択できます。

1. カスタム.NLTファイルを新しいプラットフォームに上書きでコピーし、「NLBファイルの生成とインストール」の説明に従って、NLBの生成とインストールの手順を繰り返します。

2. .NLBファイル一式(Oracle提供のNLBファイルとカスタムNLBファイルの両方)を新しいプラットフォームに上書きでコピーします。

2番目の選択肢を採用した場合、透過的なプラットフォームの処理が必要になるため、NLBのロードにかかる時間にある程度のオーバーヘッドが生じる可能性があることに注意してください。しかし、各NLBファイルは通常、Oracle DatabaseインスタンスまたはOracle Clientアプリケーションの起動後にのみロードされ、インスタンスまたはアプリケーションが停止するまではキャッシュされるため、このオーバーヘッドはごくわずかです。また、NLBファイルは必要になったときにロードされます。したがって、ほとんどのインストール環境では、存在するすべてのNLBファイルのうち、常にごく一部しかメモリーにロードされません。

2番目の選択肢は、Oracle Locale Builderがサポートされていないプラットフォーム用にファイルをカスタマイズするときに特に実用的です。

NLBファイル一式を新しいプラットフォームに上書きでコピーする手順は、次のとおりです。

1. ターゲットのOracleホームを使用している、すべてのOracle DatabaseインスタンスとOracle Clientアプリケーションを停止します。

2. ファイルを所有するユーザー(通常はユーザーoracle)になった状態で、すべてのNLBファイルをターゲットのOracleホームのORA_NLS10ディレクトリから、バックアップ用のディレクトリに移動します。UNIXプラットフォームの場合は、次のようなコマンドを入力します。

% setenv ORA_NLS10 $ORACLE_HOME/nls/data
% cd $ORA_NLS10
% mkdir orig
% mv *.nlb orig

3. すべてのNLBファイルをソースのOracleホームNLBディレクトリからターゲットのOracleホームNLB($ORA_NLS10)ディレクトリにコピーします。FTPのバイナリ・モード、リモートにマウントされたファイル・システムへのコピー、rcpユーティリティのように、ファイルのバイナリ・レベルでの整合性が維持されるリモート・コピー方式を使用します。

4. 必要に応じて、データベースのインスタンス、アプリケーションのいずれか、または両方を再起動します。

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を生成します。

java -classpath $ORACLE_HOME/jlib/orai18n.jar:$ORACLE_HOME/lib/xmlparserv2.jar ginstall -[add | a] <Name of NLT file>

NLTファイルを生成する手順は、次のとおりです。

java -classpath $ORACLE_HOME/jlib/orai18n.jar:$ORACLE_HOME/lib/xmlparserv2.jar ginstall -[add | a] <NLT file1>
<NLT file2>
<NLT file3>

3. gdk_custom.jarを、orai18n.jarまたはorai18n-mapping.jarと同じディレクトリにコピーします。

カスタム定義を削除する手順は、次のとおりです。

- 次のようにして、ginstallを実行します。

java -classpath $ORACLE_HOME/jlib/orai18n.jar:$ORACLE_HOME/lib/xmlparserv2.jar ginstall -[remove | r] <Name of NLT file>

カスタム定義を更新する手順は、次のとおりです。

- 次のようにして、ginstallを実行します。

java -classpath $ORACLE_HOME/jlib/orai18n.jar:$ORACLE_HOME/lib/xmlparserv2.jar ginstall -[update | u] <Name of NLT file>

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

Oracle Databaseは、複数のカレンダをサポートしています。場合によっては、その中に、今後の元号の追加が必要なものや、地域的な要件に合せて、うるう年の日数の増減が必要なものがあります。Oracleの運用環境に必要な情報を追加する方法として、カレンダ機能の実行時に自動的にロードされる外部ファイルを使用できます。

カレンダのデータは、最初にテキスト・ファイルに定義します。このテキスト定義ファイルは、バイナリ形式に変換する必要があります。NLSカレンダ・ユーティリティ(lxegen)を使用すると、テキスト定義ファイルをバイナリ形式に変換できます。

テキスト定義ファイルの名前とlxegenユーティリティに対する位置は、プラットフォーム依存の値でハードコード化されています。UNIXプラットフォームの場合、ファイル名はlxecal.nltで、$ORACLE_HOME/nlsディレクトリにあります。テキスト定義ファイルのサンプルは、$ORACLE_HOME/nls/demoディレクトリに含まれています。デモ・ファイルのインストール方法の詳細は、『Oracle Database Examplesインストレーション・ガイド』を参照してください。

テキスト定義ファイル内の参照先カレンダの数に応じて、lxegenユーティリティによって、1つ以上のバイナリ・ファイルが生成されます。バイナリ・ファイルの名前もプラットフォーム依存の値でハードコード化されています。UNIXプラットフォームの場合、バイナリ・ファイルの名前はそれぞれ、lxecalah.nlb(アラビア語版ヒジュラ暦のうるう年)、lxecaleh.nlb(英語版のヒジュラ暦のうるう年)、lxecalji.nlb(日本の元号暦の元号)です。バイナリ・ファイルはテキスト・ファイルと同じディレクトリに生成され、同名のバイナリ・ファイルがあれば上書きされます。

バイナリ・ファイルが生成されると、そのファイルはシステムの初期化時に自動的にロードされます。このファイルを移動したり名前を変更しないでください。Oracle Locale Builderによって生成されるファイルとは異なり、カレンダ個別のバイナリ・ファイルはプラットフォームに依存します。Oracleソフトウェアのリリースとプラットフォームの組合せごとに別々に生成する必要があります。

カレンダ・ユーティリティを起動するには、コマンドラインから次のように入力します。

% lxegen

関連項目:

- ご使用のシステム上のファイルの位置については、オペレーティング・システムのマニュアルを参照してください。

- 「暦法」

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

バイナリ

AMHARIC

am

GENERIC_M

ARABIC

ar

ARABIC

ARMENIAN

hy

GENERIC_M

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

DARI

prs

GENERIC_M

DIVEHI

dv

GENERIC_M

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

バイナリ

KHMER

km

GENERIC_M

KOREAN

ko

バイナリ

LAO

lo

GENERIC_M

LATIN AMERICAN SPANISH

esa

SPANISH

LATIN BOSNIAN

lbs

GENERIC_M

LATIN SERBIAN

lsr

バイナリ

LATIN UZBEK

luz

GENERIC_M

LATVIAN

lv

LATVIAN

LITHUANIAN

lt

LITHUANIAN

MACEDONIAN

mk

バイナリ

MALAY

ms

MALAY

MALAYALAM

ml

バイナリ

MALTESE

mt

GENERIC_M

MARATHI

mr

バイナリ

MEXICAN SPANISH

esm

WEST_EUROPEAN

NEPALI

ne

GENERIC_M

NORWEGIAN

n

NORWEGIAN

ORIYA

or

バイナリ

ペルシア語

fa

GENERIC_M

POLISH

pl

POLISH

PORTUGUESE

pt

WEST_EUROPEAN

PUNJABI

pa

バイナリ

ROMANIAN

ro

ROMANIAN

RUSSIAN

ru

RUSSIAN

SIMPLIFIED CHINESE

zhs

バイナリ

SINHALA

si

GENERIC_M

SLOVAK

sk

SLOVAK

SLOVENIAN

sl

SLOVENIAN

SPANISH

e

SPANISH

SWAHILI

sw

GENERIC_M

SWEDISH

s

SWEDISH

TAMIL

ta

バイナリ

TELUGU

te

バイナリ

THAI

th

THAI_DICTIONARY

TRADITIONAL CHINESE

zht

バイナリ

TURKISH

tr

TURKISH

UKRAINIAN

uk

UKRAINIAN

VIETNAMESE

vn

VIETNAMESE

翻訳済メッセージ

Oracle Databaseのエラー・メッセージは、表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 Databaseでサポートしている地域を示します。

表A-3 Oracle Databaseがサポートしている地域

名前

名前

名前

AFGHANISTAN

FRANCE

PAKISTAN

ALBANIA

FYR MACEDONIA

PANAMA

ALGERIA

GABON

PARAGUAY

AMERICA

GUATEMALA

PERU

ARGENTINA

GERMANY

PHILIPPINES

ARMENIA

GREECE

POLAND

AUSTRALIA

HONDURAS

PORTUGAL

AUSTRIA

HONG KONG

PUERTO RICO

AZERBAIJAN

HUNGARY

QATAR

BAHAMAS

ICELAND

ROMANIA

BAHRAIN

INDIA

RUSSIA

BANGLADESH

INDONESIA

SAUDI ARABIA

BELARUS

IRAQ

SENEGAL

BELGIUM

IRAN

SERBIA

BELIZE

IRELAND

SINGAPORE

BERMUDA

ISRAEL

SLOVAKIA

BOLIVIA

ITALY

SLOVENIA

BOSNIA AND HERZEGOVINA

IVORY COAST

SOMALIA

BRAZIL

JAPAN

SOUTH AFRICA

BULGARIA

JORDAN

SPAIN

CAMBODIA

KENYA

SRI LANKA

CAMEROON

KOREA

SUDAN

CANADA

KUWAIT

SWEDEN

CATALONIA

LAOS

SWITZERLAND

CHILE

LATVIA

SYRIA

CHINA

LEBANON

TAIWAN

COLOMBIA

LIBYA

THAILAND

CONGO BRAZZAVILLE

LITHUANIA

THAILAND

CONGO KINSHASA

LUXEMBOURG

THE NETHERLANDS

COSTA RICA

MALDIVES

TUNISIA

CROATIA

MALTA

TURKEY

CYPRUS

MAURITANIA

UGANDA

CZECH REPUBLIC

MEXICO

UKRAINE

DENMARK

MONTENEGRO

UNITED ARAB EMIRATES

DJIBOUTI

MOROCCO

UNITED KINGDOM

ECUADOR

NEW ZEALAND

URUGUAY

EGYPT

NEPAL

UZBEKISTAN

EL SALVADOR

NICARAGUA

VENEZUELA

ESTONIA

NIGERIA

VIETNAM

ETHIOPIA

NORWAY

YEMEN

FINLAND

OMAN

ZAMBIA

キャラクタ・セット

ここでは、Oracle Databaseがサポートしているキャラクタ・セットを、次の3つの広範囲なカテゴリに分けて示します。

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

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

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

また、共通のキャラクタ・セットのサブセットとスーパーセットの組合せも示します。一部のキャラクタ・セットは、特定のデータ型のみで使用できます。たとえば、AL16UTF16キャラクタ・セットはNCHARキャラクタ・セットとしてのみ使用でき、データベース・キャラクタ・セットとしては使用できません。

コメント・セクションには、ユーザーまたはデータベース管理者にとって重要な、キャラクタ・セットに固有のその他の特徴も記載されています。たとえば、キャラクタ・セットがユーロ通貨記号をサポートしているかどうか、ユーザー定義文字がサポートされているかどうか、およびキャラクタ・セットがASCIIの完全なスーパーセットであるかどうかなどの情報が記載されています。(すべてのスキーマ・データが新しいキャラクタ・セットの完全なサブセットである場合のみ、Database Migration Assistant for Unicodeを使用して、既存のデータベースを新しいキャラクタ・セットに移行できます。)

キャラクタ・セット表のコメント列の凡例は、次のとおりです。

- SB: シングルバイト・エンコーディング

- MB: マルチバイト・エンコーディング

- FIXED: 固定幅マルチバイト・エンコーディング

- ASCII: ASCIIの完全なスーパーセット

- EURO: ユーロ記号をサポート

- UDC: ユーザー定義文字をサポート

個々のコード・ページのレイアウトは記述されていません。特定のキャラクタ・セット固有の情報、文字レパートリおよびコード・ポイントの値については、Oracle Locale Builderを使用できます。それ以外の場合は、実際の各国の規格、国際規格またはベンダー固有の規格を参照してください。

関連項目:

- 『Oracle Database Migration Assistant for Unicodeガイド』

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

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

表A-4に、最も一般的に使用されているお薦めのASCIIベースOracle Databaseキャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表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 6.2 UTF-8ユニバーサル・キャラクタ・セット

MB、ASCII、EURO

表A-5に、最も一般的に使用されているお薦めのEBCDICベースOracle Databaseキャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表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

ヨーロッパ地域

SE8EBCDIC1143

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

ヨーロッパ地域

WE8EBCDIC1146

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 Databaseキャラクタ・セットを示します。それぞれの言語グループ内はアルファベット順に記載しています。

表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ビット(Johab)韓国語

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

中東地域

AR8ARABICMACS

Macサーバー8ビット・ラテン語/アラビア語

SB、ASCII

中東地域

AR8ASMO8X

ASMO拡張708 8ビット・ラテン語/アラビア語

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

中東地域

IW8MACHEBREWS

Macサーバー8ビット・ヘブライ語

SB、ASCII

中東地域

IW8PC1507

IBM-PCコード・ページ1507/862 8ビット・ラテン語/ヘブライ語

SB、ASCII

中東地域

LA8ISO6937

ISO 6937 8ビット・テキスト通信用コード・キャラクタ・セット

SB、ASCII

中東地域

TR8DEC

DEC 8ビット・トルコ語

SB、ASCII

中東地域

TR8MACTURKISHS

Macサーバー8ビット・トルコ語

SB、ASCII

中東地域

TR8PC857

IBM-PCコード・ページ857 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、ASCII

ヨーロッパ地域

CL8KOI8R

RELCOMインターネット標準8ビット・ラテン語/キリル文字

SB、ASCII

ヨーロッパ地域

CL8KOI8U

KOI8ウクライナ語/キリル文字

SB、ASCII

ヨーロッパ地域

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、ASCII

ヨーロッパ地域

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

ヨーロッパ地域

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

アジア地域

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

ヨーロッパ地域

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

中東地域

TR7DEC

DEC VT100 7ビット・トルコ語

SB

中東地域

TR8MACTURKISH

Macクライアント8ビット・トルコ語

SB

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

表A-10に、世界言語サポートを提供しているOracle Databaseキャラクタ・セットを示します。これらのキャラクタ・セットは、アジア、ヨーロッパおよび中東地域の言語にかぎらず、それらを含めた世界中のすべての言語をサポートします。

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

名前

説明

コメント

AL16UTF16

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

MB、EURO、FIXED

AL32UTF8

Unicode 6.2 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を参照してください。

関連項目:

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

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

次のキャラクタ・セット・エンコーディングは、変換専用としてサポートされています。データベース・キャラクタ・セットまたは各国語キャラクタ・セットとしては使用できません。

- AL16UTF16LE

- ISO2022-CN

- ISO2022-JP

- ISO2022-KR

- HZ-GB-2312

- ZHS32GB18030

これらのキャラクタ・セットは、CONVERT 関数でsource_char_setまたはdest_char_setに使用できます。

CONVERT関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。「CONVERT関数」も参照してください。

バイナリ・サブセット/スーパーセットのペア

Oracle Databaseでは、そのキャラクタ・セットのすべてのサブセット/スーパーセットのペアのリストを保持するわけではなく、2つのキャラクタ・セットの互換性を確認するときに認識されるバイナリ・サブセット/スーパーセットのペアのリストを保持します。

表A-11に、Oracle Databaseで認識されるバイナリ・サブセット/スーパーセットのすべての関係を示します。

表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を参照してください。

UTF8

AL32UTF8

WE8DEC

TR8DEC

WE8DEC

WE8NCR4970

WE8ISO8859P1

WE8MSWIN1252

WE8ISO8859P9

TR8MSWIN1254

WE8NCR4970

TR8DEC

WE8NCR4970

WE8DEC

WE8PC850

WE8PC858

US7ASCIIは特殊で、非常に多くのキャラクタ・セットがUS7ASCIIのスーパーセットになっています。表A-12に、Oracle Databaseで認識されるUS7ASCIIのすべてのバイナリ・スーパーセットを示します。

表A-12 US7ASCIIのバイナリ・スーパーセット

スーパーセットaからe

スーパーセット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

AZ8ISO8859PE

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に、Language and Character Set Detectionユーティリティ(LCSSCAN)とGlobalization Development Kit(GDK)でサポートされている言語とキャラクタ・セットを示します。

各言語には、検出可能な複数のキャラクタ・セットがあります。

言語のバイナリ値が、サブセット/スーパーセット関係を持つ複数のエンコーディングと一致する場合は、サブセットのキャラクタ・セットが戻されます。たとえば、言語がドイツ語ですべての文字が7ビットの場合は、WE8MSWIN1252、WE8ISO8859P15またはWE8ISO8859P1のかわりにUS7ASCIIが戻されます。

キャラクタ・セットがUTF-8であると判別されると、テキスト内で4バイト文字(補助文字)が検出されないかぎり、デフォルトでOracle Databaseのキャラクタ・セットUTF8が戻されます。4バイト文字が検出されると、キャラクタ・セットはAL32UTF8としてレポートされます。

表A-13 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、IN8ISCII、UTF8

ハンガリー語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

インドネシア語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

イタリア語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

日本語

AL16UTF16、AL32UTF8、ISO2022-JP、JA16EUC、JA16SJIS、UTF8

韓国語

AL16UTF16、AL32UTF8、ISO2022-KR、KO16KSC5601、KO16MSWIN949、UTF8

ラトビア語

AL16UTF16、AL32UTF8、NEE8ISO8859P4、UTF8

リトアニア語

AL16UTF16、AL32UTF8、NEE8ISO8859P4、UTF8

マレー語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ノルウェー語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

Persian(ペルシャ暦)

AL16UTF16、AL32UTF8、AR8MSWIN1256、UTF8

ポーランド語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

ポルトガル語

AL16UTF16、AL32UTF8、US7ASCII、UTF8、WE8ISO8859P1、WE8ISO8859P15、WE8MSWIN1252

ルーマニア語

AL16UTF16、AL32UTF8、EE8ISO8859P2、EE8MSWIN1250、UTF8

ロシア語

AL16UTF16、AL32UTF8、CL8ISO8859P5、CL8KOI8R、CL8MSWIN1251、RU8PC866、UTF8

セルビア語

AL16UTF16、AL32UTF8、CL8ISO8859P5、CL8MSWIN1251、UTF8

簡体字中国語

AL16UTF16、AL32UTF8、HZ-GB-2312、UTF8、ZHS16GBK、ZHS16CGB231280

スロバキア語

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、TH8TISASCII、UTF8

繁体字中国語

AL16UTF16、AL32UTF8、UTF8、ZHT16MSWIN950

トルコ語

AL16UTF16、AL32UTF8、TR8MSWIN1254、UTF8、WE8ISO8859P9

ウクライナ語

AL16UTF16、AL32UTF8、CL8ISO8859P5、CL8MSWIN1251、UTF8

ベトナム語

AL16UTF16、AL32UTF8、VN8VN3、UTF8

言語ソート

Oracle Databaseでは、単一言語ソートと多言語ソートの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

この繁体字中国語のソートは、最初に画数、次に部首に基づいて行います。補助文字がサポートされます。

関連項目:

言語ソートと照合

表A-16にUCA照合を示します。

表A-16 UCA照合

照合名

UCAバージョン

言語

照合タイプ

照合パラメータのデフォルト設定

UCA0620_DUCET

6.2.0

すべて

DUCET

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_ROOT

6.2.0

すべて

CLDRルート

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_CFRENCH

6.2.0

フランス語(カナダ)

standard

_S4_VS_BY_NY_EN_FN_HN_DN_MN

UCA0620_DANISH

6.2.0

デンマーク語

standard

_S4_VS_BN_NY_EN_FU_HN_DN_MN

UCA0620_JAPANESE

6.2.0

日本語

standard

_S4_VS_BN_NY_EN_FN_HY_DN_MN

UCA0620_KOREAN

6.2.0

韓国語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_SPANISH

6.2.0

スペイン語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_TSPANISH

6.2.0

スペイン語

traditional

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_THAI

6.2.0

タイ語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_SCHINESE

6.2.0

簡体字中国語

pinyin

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_SCHINESE1

6.2.0

簡体字中国語

radical

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_SCHINESE2

6.2.0

簡体字中国語

stroke

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_TCHINESE

6.2.0

繁体字中国語

stroke

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0620_TCHINESE1

6.2.0

繁体字中国語

radical

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_DUCET

6.1.0

すべて

DUCET

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_ROOT

6.1.0

すべて

CLDRルート

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_CFRENCH

6.1.0

フランス語(カナダ)

standard

_S4_VS_BY_NY_EN_FN_HN_DN_MN

UCA0610_DANISH

6.1.0

デンマーク語

standard

_S4_VS_BN_NY_EN_FU_HN_DN_MN

UCA0610_JAPANESE

6.1.0

日本語

standard

_S4_VS_BN_NY_EN_FN_HY_DN_MN

UCA0610_KOREAN

6.1.0

韓国語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_SPANISH

6.1.0

スペイン語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_TSPANISH

6.1.0

スペイン語

traditional

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_THAI

6.1.0

タイ語

standard

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_SCHINESE

6.1.0

簡体字中国語

pinyin

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_SCHINESE1

6.1.0

簡体字中国語

radical

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_SCHINESE2

6.1.0

簡体字中国語

stroke

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_TCHINESE

6.1.0

繁体字中国語

stroke

_S4_VS_BN_NY_EN_FN_HN_DN_MN

UCA0610_TCHINESE1

6.1.0

繁体字中国語

radical

_S4_VS_BN_NY_EN_FN_HN_DN_MN

暦法

デフォルトでは、ほとんどの地域定義でグレゴリオ暦が使用されています。表A-17に、Oracle Databaseがサポートしているその他の暦法を示します。

表A-17 サポートしている暦法

名前

デフォルトの日付書式

デフォルトの日付書式に使用するキャラクタ・セット

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

US7ASCII

Ethiopian(エチオピア歴)

Month DD YYYY

AL32UTF8

Oracle Databaseに実装されているアラビア語版ヒジュラ暦および英語版ヒジュラ暦は、一種の表計算式のイスラム暦であり、30年単位で、それぞれ2番目、5番目、7番目、10番目、13番目、16番目、18番目、21番目、24番目、26番目および29番目の年がうるう年になり、ヒジュラ暦紀元元年1月1日は、西暦622年7月16日に相当します。ユーザーは、自身の要件に合せてカレンダを調整するために、うるう年を交互に切り替えるなどの方法で日数の増減を適用することができます。うるう年の定義の詳細は、「NLSカレンダ・ユーティリティを使用したカレンダのカスタマイズ」を参照してください。アラビア語版ヒジュラ暦と英語版ヒジュラ暦の違いは、月の名前のみであり、対応する月がそれぞれアラビア語と英語で綴られています。

図A-1に、Japanese Imperial(日本の元号暦)で1998年3月27日がどのように表示されるかを示します。

図A-1 Japanese Imperial(日本の元号暦)の例

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

表A-18に、Oracle Databaseで提供されているバージョン11のタイム・ゾーン・ファイル内のタイム・ゾーン・リージョン名を示します。タイム・ゾーン・ファイルの詳細は、「日時データ型とタイム・ゾーン・サポート」を参照してください。

次の文を発行すると、タイム・ゾーン・リージョン名が表示されます。

SELECT DISTINCT(TZNAME) FROM V$TIMEZONE_NAMES;

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

タイム・ゾーン名

小さいタイム・ゾーン・ファイル内での有無

タイム・ゾーン名

小さいタイム・ゾーン・ファイル内での有無

アフリカ/アビジャン

不可

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

不可

アフリカ/ブジュンブラ

不可

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

可能

アメリカ/アンティグア

不可

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-19に、Oracle Database 10g以降で廃止された言語ソートを示します。

表A-19 廃止された言語ソート

廃止になったソート名

置換ソート

THAI_TELEPHONE

THAI_M

THAI_DICTIONARY

THAI_M

CANADIAN FRENCH

CANADIAN_M

JAPANESE

JAPANESE_M

廃止された地域

表A-20に、Oracle Database 10g以降で廃止された地域を示します。

表A-20 廃止された地域

廃止された地域名

置換地域

CIS

RUSSIA

MACEDONIA

FYR MACEDONIA

YUGOSLAVIA

BOSNIA AND HERZEGOVINA、SERBIA、またはMONTENEGRO

SERBIA AND MONTENEGRO

SERBIAまたはMONTENEGRO

CZECHOSLOVAKIA

CZECH REPUBLICまたはSLOVAKIA

廃止された言語

表A-21に、Oracle Database 10g以降で廃止された言語を示します。

表A-21 廃止された言語

廃止された言語名

置換言語

BENGALI

BANGLA

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

表A-22に、廃止されたキャラクタ・セットを示します。次のキャラクタ・セットをコード内で参照する場合は、新しいキャラクタ・セット名に置き換えてください。

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

旧キャラクタ・セット

置換キャラクタ・セット

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では、Oracle8からUnicodeデータベース・キャラクタ・セットであるUTF8をサポートし、Oracle9iからAL32UTF8をサポートするようになりました。Oracle Database 12c (12.1.0.2)になって、AL32UTF8キャラクタ・セットがUnicode 6.2に準拠するように変更されました。

既存のAL24UTFFSSデータベースを移行する場合は、Oracle Database 9i以降にアップグレードする前にUTF8にアップグレードします。Oracle8では、現行のテータベース・キャラクタ・セットをUTF8に移行する前に、Character Set Scannerを使用してデータを分析できます。

注意:

AL24UTFFSSは、Unicode規格1.1に基づくUTF-8コード体系をサポートするUnicodeキャラクタ・セットとしてOracle Databaseのバージョン7から導入されましたが、現在では不要と考えられます。

Oracle Databaseの言語および地域定義ファイルの更新

Oracle Database 10g以降では、一部の言語および地域定義ファイルの内容が変更されています。Oracleでサポートされている言語および地域の一部では、ローカルの表記規則と一致しなくなったレガシー定義を修正するために、これらの更新が必要です。これらの変更には、通貨記号、月名およびグループ・セパレータの変更が含まれます。その一例が、ブラジルのローカル通貨記号です。この記号は、Oracle Database 10gではCr$からR$に更新されています。

詳細な変更リストについては、$ORACLE_HOME/nls/data/old/data_changes.html ファイル内の「Oracleの言語定義と地域定義の変更」表を参照してください。

Oracle Database 12cのカスタマは、Oracle Database 12cのロケール定義ファイルで適切な表記規則が使用されているかどうか、現行のアプリケーション・コードを見直す必要があります。アプリケーションのサポートに必要なコード変更ができない可能性のあるカスタマのために、Oracle Databaseはこのリリースでも引き続き、Oracle9iロケール定義ファイルを提供しています。

Oracle9iの言語および地域の動作に戻る手順は、次のとおりです。

1. データベースを停止します。

2. $ORACLE_HOME/nls/data/oldディレクトリからcr9idata.plスクリプトを実行します。

3. ORA_NLS10環境変数を、新規作成した$ORACLE_HOME/nls/data/9idataディレクトリに設定します。

4. データベースを再起動します。

Oracle9iの定義ファイルに戻る必要があるすべてのOracle Database 12cのクライアントは、手順2および3を繰り返す必要があります。

オラクル社では、Oracle Database 12cのロケール定義ファイルの使用をお薦めします。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 Databaseの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グローバリゼーション・サポート・ガイド』では発音区別記号という用語を使用します。

「diacritic」も参照。

アクセントを区別しない言語ソート

発音区別記号や大/小文字ではなく、ベース文字に関する情報のみを使用するソート。

「言語照合」、「ベース文字」、「「発音区別記号」」、「ケース」も参照。

AL16UTF16

SQL NCHARデータ型に使用されるデフォルトのOracle Databaseのキャラクタ・セットで、各国語キャラクタ・セットに使用されます。このキャラクタ・セットは、UnicodeデータをUTF-16コード体系でエンコードします。

「各国語キャラクタ・セット」、「UTF-16」も参照。

AL32UTF8

SQL CHARデータ型に使用されるOracle Databaseのキャラクタ・セットで、データベース・キャラクタ・セットに使用されます。このキャラクタ・セットは、UnicodeデータをUTF-8コード体系でエンコードします。

「データベース・キャラクタ・セット」も参照。

ASCII

米国の情報交換標準コード。英語用のエンコードされた共通7ビット・キャラクタ・セット。ASCIIには、文字AからZとaからz、数字、句読点記号および制御文字が含まれます。Oracle Databaseのキャラクタ・セット名はUS7ASCIIです。

ベース文字

発音区別記号とケースを除去された文字。たとえば、a、A、äおよびÄのベース文字はaです。

「diacritic」も参照。

バイナリ照合

それぞれの文字列を単純なバイトの並びとして扱い、バイナリ表現(文字コード)に基づいて文字列を並べ替えるタイプの照合。

「照合」、「言語照合」、「単一言語照合」、「多言語照合」、「アクセントを区別しない言語照合」、「大/小文字を区別しない言語照合」も参照。

バイナリ・ソート

バイナリ照合を使用する文字列の順序付け。

バイト・セマンティクス

文字列を一連のバイトとして取り扱うこと。文字列へのオフセットと文字列長はバイトで表されます。

「キャラクタ・セマンティクス」と「長さセマンティクス」も参照。

標準的な同値化

2つの文字または文字列が意味論的に同じ文字とみなされることになっていることを述べるUnicode規格の用語。正しく行われた場合、標準的に同値化された文字は区別できません。たとえば、合成された文字ñ (U+00F1 Latin Small Letter N With Tilde)は、n (U+006E Latin Small Letter N)に ˜ (U+0303 Combining Tilde)が続く文字列に、標準的に同値です。

ケース

大文字であるか小文字であるかの条件を指します。たとえばラテン・アルファベットの場合、Aが大文字で、それに対する小文字がaです。

大/小文字の変換

ある文字を大文字から小文字に、または小文字から大文字に変換すること。

大/小文字を区別しない言語照合

文字列の順序付けを決定するときに、ベース文字と発音区別記号に関する情報は使用するが、ケースに関する情報は使用しない照合。

「ベース文字」、「ケース」、「発音区別記号」、「言語照合」も参照。

文字

テキストの抽象要素。文字は、その文字の特定の表現である絵文字とは異なります。たとえば、英語の大文字アルファベットの先頭の文字は、等幅のA、プロポーショナル斜体のAA、筆記体のAなどとして表示されることができます。これらの形式は、同じ文字を表現する異なる絵文字です。文字、文字コードおよび絵文字には、次のような関連があります。

文字 --(エンコーディング)--> 文字コード --(フォント)--> 絵文字

たとえば、英大文字の最初の文字は、コンピュータのメモリーでは数値として表されます。この数値は、エンコーディングまたは文字コードと呼ばれます。英大文字の最初の文字の文字コードは、ASCIIコード体系では0x41で、EBCDICコード体系では0xc1です。

この文字を表示または印字するには、フォントを選択する必要があります。使用可能なフォントは、使用するコード体系によって異なります。各フォントは、通常、異なる形(つまり、同じ文字を表す異なる絵文字)を使用します。

「文字コード」と「絵文字」も参照。

文字の分類

各文字コードに関連付けられた文字のタイプに関する詳細を提供する情報。たとえば、文字には大文字、小文字、句読点、制御文字があります。

文字コード

文字コードとは、特定の文字を表現するバイト列です。この列は、文字コード体系に依存します。たとえば、英大文字の最初の文字の文字コードは、ASCIIコード体系では0x41ですが、EBCDICコード体系では0xc1です。

「文字」も参照。

文字のエンコード形式

キャラクタ・セットのすべての文字に対して番号を割り当てる規則。

文字コード体系

文字エンコード形式によって割り当てられる番号を、バイト(文字コード)の特定の列にマップするルール。たとえば、UTF-16エンコード形式には、ビッグ・エンディアン・コード体系(UTF-16BE)とリトル・エンディアン・コード体系(UTF-16LE)があります。

大部分のエンコード形式には、1つのコード体系のみがあります。このため、エンコード形式、コード体系およびエンコーディングが区別なく使用されることがよくあります。

Oracleキャラクタ・セットは、文字コード体系に対応しています。たとえば、AL16UTF16は、UTF-16BEコード体系のOracle名です。

文字レパートリ

特定のキャラクタ・セットを表したり、エンコードしたりするときに使用される文字のこと。

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

文字列を一連の文字として取り扱うこと。文字列へのオフセットと文字列長は文字(文字コード)数で表されます。

「バイト・セマンティクス」と「長さセマンティクス」も参照。

キャラクタ・セット

特定の言語または言語グループのテキスト情報を表す要素の集まり。1つの言語を複数のキャラクタ・セットで表現できます。

キャラクタ・セットは、必ずしも特定の文字コード体系を示すわけではありません。文字コード体系は、キャラクタ・セットの各文字に対する文字コードの割当てです。

このマニュアルでは、通常、キャラクタ・セットは特定の文字コード体系を示しています。したがって、このマニュアルでは、キャラクタ・セットとエンコードされたキャラクタ・セットは同じです。

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

既存のデータベースのキャラクタ・セットを変更すること。

文字列

文字の列。

文字列に文字が含まれていない場合もあります。この場合、その文字列はヌル文字列と呼ばれます。ヌル文字列の文字列長は0(ゼロ)です。

クライアント・キャラクタ・セット

データベース・クライアントが使用するエンコード済キャラクタ・セット。クライアント・キャラクタ・セットは、データベース・キャラクタ・セットと異なることがあります。データベース・キャラクタ・セットは、サーバー・キャラクタ・セットと呼ばれることもあります。クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと異なる場合は、キャラクタ・セット変換が必要です。

「データベース・キャラクタ・セット」も参照。

コード・ポイント

キャラクタ・セットの1文字の数値表現。たとえば、ASCIIキャラクタ・セットでは、Aのコード・ポイントは0x41です。文字のコード・ポイントは、その文字のエンコーディング値とも呼ばれます。

「Unicodeコード・ポイント」も参照。

コード単位

エンコードされたテキストを処理および交換する単位。コード単位のサイズは、文字コード体系に応じて異なります。ほとんどの文字エンコーディングでは、コード単位は1バイトです。ただし、UTF-16とUCS-2の場合は2バイトのコード単位が使用され、ワイド・キャラクタの場合は4バイトが使用されます。

「文字エンコード形式」も参照。

照合

特定のロケールの言語に関連付けられた文字のソートに関する規則に従って文字列を順序付けすること。言語ソートとも呼ばれます。

「言語照合」、「単一言語照合」、「多言語照合」、「アクセントを区別しない言語照合」、「大/小文字を区別しない言語照合」も参照。

データ・スキャニング

データベース・キャラクタ・セットの移行前に、キャラクタ・セット変換とデータの切捨てに伴う問題の可能性を識別するプロセス。

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

テキストをデータベースに格納するために使用される、エンコードされたキャラクタ・セット。CHAR、VARCHAR2、LONGおよび固定幅のCLOB列の値と、すべてのSQLおよびPL/SQLテキストが含まれます。

Database Migration Assistant for Unicode(DMU)

直感的な操作が可能な、ユーザーに親しみやすいGUIを装備した、キャラクタ・セットの移行ツール。作業量を大幅に減らし、移行上のあらゆる問題を解決するインタフェースを備えているため、これを使用すれば移行プロセスを効率化できます。

発音区別記号

文字または文字列の上または下にある記号で、それが付いていない場合の文字とは発音が異なることを示します。たとえば、façadeの場合、セディラは発音区別記号です。セディラが付いている場合は、cの発音が変化します。

EBCDIC

拡張2進化10進コード。EBCDICは、IBMメインフレーム・システムで最も使用されるエンコードされたキャラクタ・セット・ファミリ。

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

文字コード体系が関連付けられているキャラクタ・セット。エンコードされたキャラクタ・セットは、各文字に割り当てるバイト列(文字コード)を指定します。

「文字エンコード形式」も参照。

エンコーディング値

キャラクタ・セットの1文字の数値表現。たとえば、ASCIIキャラクタ・セットでは、Aのコード・ポイントは0x41です。文字のエンコーディング値は、その文字のコード・ポイントとも呼ばれます。

フォント

キャラクタ・セット内の文字をグラフィカルに表現する順序付けられた絵文字の集まり。

グローバリゼーション

ソフトウェアを多様な言語および文化の環境に適したものにするプロセス。グローバリゼーションとローカライゼーションは異なるものであり、ローカライゼーションとは、ソフトウェアをある固有のロケールで使用できるように準備するプロセスです(たとえば、ある言語から他の言語へのエラー・メッセージやユーザー・インタフェースの翻訳)。

絵文字

文字の固有の表現(形)。1つの文字は、多数の異なる絵文字を持つことができます。

「文字」も参照。

表意文字

概念を表現する記号。一部の書記体系では、文字の音を通して語を表すのでなく、文字の意味を通して語を表す表意文字を使用します。表意的記述法の例に中国語があります。

ISO

International Organization for Standardization (国際標準化機構)。130か国からなる標準機関の世界的な連合。ISOでは、世界規模の規格を開発および促進し、商品やサービスの国際的な交流を容易にすることを目的としています。

ISO 8859

8ビットのエンコードされたキャラクタ・セット・ファミリ。最も一般的なものは、ISO 8859-1(ISO Latin-1として知られています)で、西ヨーロッパ諸国で使用されています。

ISO 14651

ほとんどの言語向けに設計された国際的な多言語照合規格。

「多言語照合」も参照。

ISO/IEC 10646

現在、世界で使用されているほとんどの主要文字を定義しているユニバーサル・キャラクタ・セットの規格。ISO/IEC 10646は、文字レパートリに関するかぎりUnicode規格との同期を維持しますが、定義するプロパティとテキスト処理アルゴリズムはUnicode規格より少なくなっています。

ISO通貨

各国通貨を示すために使用される3文字の略称で、ISO 4217規格に基づいています。たとえば、USDは米国のドルを表します。

ISO Latin-1

ISO 8859-1キャラクタ・セット規格。ASCIIに対する8ビット拡張機能で、西ヨーロッパで最も頻繁に使用される共通のラテン文字を含む128文字が追加されています。Oracle Databaseのキャラクタ・セット名は、WE8ISO8859P1です。

「ISO 8859」も参照。

長さセマンティクス

文字列の長さの取扱い方法を決定します。長さは、文字(文字コード)の数として、または文字列のバイト数として表すことができます。

「キャラクタ・セマンティクス」と「バイト・セマンティクス」も参照。

言語照合

標準的、慣習的な話し言葉を考慮に入れた照合の一種。

「照合」、「言語照合」、「単一言語照合」、「多言語照合」、「アクセントを区別しない言語照合」。「大/小文字を区別しない言語照合」も参照。

言語索引

言語上のソート順序に基づいた索引。

言語ソート

バイナリ言語照合を使用する文字列の順序付け。

「多言語照合」と「単一言語照合」も参照。

ロケール

特定の地域で参照される言語的および文化的な情報の集まり。一般的に、ロケールはNLSデータファイルに定義されている言語、地域、キャラクタ・セット、言語処理およびカレンダ情報で構成されます。

ローカライゼーション

言語固有または文化固有の情報をソフトウェア・システムに提供するプロセス。アプリケーションのユーザー・インタフェースの翻訳は、ローカライゼーションの1つの例です。ローカライゼーションとグローバリゼーションは異なるものです。グローバリゼーションとは、ソフトウェアを多様な言語および文化的な環境に適したものにすることです。

単一言語照合

文字列を2つのレベルで比較するOracle Databaseの照合。文字列は、まず文字のメジャー値に基づいて順序付けされ、その比較で等しいと判断されると、文字のマイナー値に基づいて順序付けされます。メジャー値はだいたいベース文字に対応し、マイナー値は発音区別記号およびケースに対応します。単一言語照合を使用すると、ヨーロッパ地域の大半の言語はソートできますが、アジア地域の言語や多言語のテキストには不向きです。

「多言語照合」も参照。

単一言語サポート

1つの言語のみのサポート。

マルチバイト

2バイト以上であること。

特定の言語(または言語グループ)のすべての文字に対して文字コードが割り当てられた場合は、1バイト(8ビット)では256の異なる文字を表現できます。2バイト(16ビット)では、65,536の異なる文字を表現できます。すべての文字を表現するために、2バイトでは不十分な言語も多いです。一部の文字には3または4バイト必要です。

たとえば、UnicodeのUTF-8エンコード形式があります。UTF-8には、多数の2バイトおよび3バイトの文字があります。

また、台湾で使用する繁体字中国語もこの例の1つ。この言語では、80,000以上の文字が使用されます。台湾で使用されている一部の文字コード体系は、4バイトを使用して文字をエンコードします。

「シングルバイト」も参照。

マルチバイト・キャラクタ

ある文字コード体系で、2バイト以上の文字コードから構成される文字。

コード体系が異なると、同じ文字に異なる文字コードが対応する場合があります。使用している文字コード体系が不明な場合、Oracle Databaseでは文字がマルチバイト・キャラクタであるかどうかを判断できません。たとえば、日本語の半角カタカナ文字は、JA16SJISのエンコードされたキャラクタ・セットでは1バイト、JA16EUCでは2バイト、AL32UTF8では3バイトです。

「シングルバイト文字」も参照。

マルチバイト・キャラクタ文字列

マルチバイト文字コード体系でエンコードされた文字列。

マルチバイト文字コード体系

文字コードが複数バイトになることがある文字コード体系。

「マルチバイト固定幅文字コード体系」、「マルチバイト変動幅文字コード体系」も参照。

マルチバイト固定幅文字コード体系

各文字コードが1より大きい同じ固定バイト数を持っている文字コード体系。AL16UTF16は、マルチバイト固定幅キャラクタ・セットです。

マルチバイト変動幅文字コード体系

各文字コードが所定の範囲に収まるバイト数を持っている文字コード体系。範囲は、1からキャラクタ・セットの最大文字幅までです。コード体系により異なりますが、キャラクタ・セットの最大文字幅は、2バイト、3バイトまたは4バイトです。たとえば、ZHT16BIG5には1バイトまたは2バイトの文字コードがあります。UTF8には、1バイト、2バイトまたは3バイトの文字コードがあります。AL32UTF8には、1バイト、2バイト、3バイトまたは4バイトの文字コードがあります。Oracleは、文字コード当たりのバイト数が4を超えるコード体系をサポートしません。

多言語照合

3つのレベルで文字列を評価するOracle Databaseの照合。アジア言語の場合は、1言語によるデータしか存在しない場合にも、多言語照合が必要です。多言語照合は、複数言語によるデータが存在する場合にも使用されます。

多言語照合では、文字列はまず1次重み付けに基づいて順序付けられ、その後、必要に応じて2次重み付け、3次重み付けが行われます。文字の場合、1次重み付けはベース文字に、2次重み付けは発音区別記号に、3次重み付けはケースおよび固有の文字飾り(文字を囲む円など)に対応します。表意文字のスクリプトの場合、重み付けが他の文字変化形を表す場合があります。

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

NCHAR、NVARCHAR2およびNCLOB列に指定できるデータベース・キャラクタ・セットの代替キャラクタ・セット。各国語キャラクタ・セットは、AL16UTF16とUTF8のみです。

NLBファイル

ロケール固有のデータを定義するためにLocale Builderが使用するバイナリ・ファイル。このファイルでは、特定リリースのOracle Databaseに付属するロケール定義がすべて定義されます。Oracle Locale Builderを使用すると、ユーザー定義のNLBファイルを作成できます。

「Oracle Locale Builder」と「NLTファイル」も参照。

NLS

National Language Support。NLSによって、ユーザーは母国語でデータベースと対話できます。さらに、アプリケーションを様々な言語および文化の環境で実行できます。この用語は、グローバリゼーションおよびローカライゼーションという用語に置き換えられました。

NLSRTL

National Language Supportランタイム・ライブラリ。このライブラリは、ロケールに依存しない国際化に関するアルゴリズムを提供します。ロケール固有の情報(つまり、NLSDATA)は、実行中にNLSRTLライブラリによって読み込まれます。

NLTファイル

ロケール固有のデータを定義するためにLocale Builderが使用するテキスト・ファイル。このファイルはテキスト形式なので、内容を表示できます。

ヌル文字列

文字が含まれていない文字列。

Oracle Locale Builder

ロケール固有のデータを表示、変更または定義する方法を提供するGUIユーティリティ。

置換文字

ソース文字がターゲット・キャラクタ・セットにない場合、その文字の変換時に使用される文字。たとえば、Oracleキャラクタ・セットでは多くの場合、?がデフォルトの置換文字として使用されます。

制限付き多言語サポート

関連する言語のグループに制限された多言語サポート。西ヨーロッパ諸国の言語は、ISO 8859-1などで表現されますが、ISO 8859-1を使用すると多言語サポートが制限されます。タイ語や中国語をグループに追加できませんでした。

SQL CHARデータ型

CHAR、VARCHAR、VARCHAR2、CLOBおよびLONGデータ型が含まれます。

SQL NCHARデータ型

NCHAR、NVARCHAR2およびNCLOBデータ型が含まれます。

スクリプト

特定の書記体系。書記体系で使用される、関連する図形記号の集まり。スクリプトの中には複数の言語を表現できるものもあり、言語の中には複数のスクリプトを使用するものもあります。スクリプトの例として、ラテン文字、アラビア文字および漢字があります。

シングルバイト

1バイト。1バイトは、通常8ビットで構成されます。特定の言語のすべての文字に文字コードを割り当てる場合、1バイト(8ビット)では256の異なる文字を表現できます。

「マルチバイト」も参照。

シングルバイト文字

ある文字コード体系で、1バイトの文字コードで構成される文字。コード体系が異なると、同じ文字に異なる文字コードが対応する場合があります。使用しているコード体系が不明な場合、Oracle Databaseではどの文字がシングルバイト文字であるかを判断できません。たとえば、ユーロ通貨記号は、WE8MSWIN1252のエンコードされたキャラクタ・セットでは1バイト、AL16UTF16では2バイト、UTF8では3バイトです。

「マルチバイト文字」も参照。

シングルバイト文字列

シングルバイト文字列は、シングルバイト文字コード体系でエンコードされた文字列です。この用語は、たまたまシングルバイト文字のみで構成されているマルチバイト変動幅文字列を記述するために使用される場合もあります。「マルチバイト変動幅文字コード体系」も参照。

ソート

文字列の順序付け。これは、文字列のバイナリ表現でなくロケール表現からの要件に基づくことも(言語ソートと呼ばれます)、バイナリ・エンコードされた値に基づくこともあります(バイナリ・ソートと呼ばれます)。

「多言語照合」と「単一言語照合」も参照。

補助文字

Unicode規格の最初のバージョンは16ビットの固定幅エンコーディングで、各文字のエンコーディングに2バイトを使用していました。このため、65,536文字を表現できました。しかし、アジア言語の多数の表意文字の関係で、より多くの文字のサポートが必要となっています。

Unicode規格バージョン3.1では、このニーズを満たすために、16進数の0000-FFFFから16進数の0000-10FFFFに文字の番号付け範囲を拡張することによって補助文字が定義されました。Unicode 3.1では、2つの16ビット・コード単位(サロゲート・ペアとも呼ばれます)を使用して、UTF-16形式で1つの補助文字を表現するようになりました。このため、さらに1,048,576文字の定義が可能でした。Unicode 3.1規格には、最初のグループとして44,944文字の補助文字が追加されました。以降のバージョンのUnicode規格では、さらに追加が行われました。

サロゲート・ペア

「補助文字」も参照。

表音文字セット

日本語などの言語で使用する表意文字とともに表音的情報を伝達する方法を提供します。

UCS-2

ISO/IEC 10646標準キャラクタ・セット・エンコード形式の古い形式。現在、サロゲート・ペアをサポートしないUTF-16エンコード形式を指すために使用されます。

UCS-4

ISO/IEC 10646標準エンコード形式の旧称。UTF-32と同義。

Unicode規格

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

Unicode規格はまた、様々な可変テキスト処理アルゴリズムおよび関連の文字プロパティを定義して、アラビア語またはデーバナーガリ(ヒンディー語)などスクリプトの複雑なスクリプト処理を助けます。

Unicodeデータベース

データベース・キャラクタ・セットがAL32UTF8またはUTF8であるデータベース。

Unicodeコード・ポイント

Unicodeコード領域にある0から0x10FFFFの値。Unicodeでは、各文字に一意のコード・ポイントが割り当てられます。

Unicodeデータ型

SQL NCHARデータ型(NCHAR、NVARCHAR2およびNCLOB)。データベース・キャラクタ・セットがUnicode規格に基づいていない場合も、これらのデータ型の列にUnicode文字を格納できます。

無制限多言語サポート

要求に応じて多数の言語を使用するための機能。Unicode規格などのユニバーサル・キャラクタ・セットを使用すると、無制限に多言語をサポートできるようになります。ユニバーサル・キャラクタ・セットでは大規模な文字レパートリをサポートしています。この文字レパートリには世界のほとんどの現代語が含まれています。

UTFE

EBCDICプラットフォーム上でのみ使用される、非推奨のUnicode UTF-EBCDICエンコード形式の4バイト・サブセットを実装するOracleキャラクタ・セット。

UTF8

UTF8 Oracleキャラクタ・セットは、文字を1バイト、2バイトまたは3バイトでエンコードします。UTF8キャラクタ・セットはUnicode 3.0をサポートし、CESU-8コード体系を実装しています。Unicode 3.1では、特定の補助文字にコード・ポイントが割り当てられていませんでしたが、Unicode 3.0では補助文字用のコード・ポイント範囲が割り当てられていました。補助文字は、6バイトを占める2つの別個のユーザー定義文字として処理されます。UTF8は非推奨です。

UTF-8

Unicode規格の8ビット・エンコード形式とコード体系。マルチバイト変動幅エンコードです。UTF-8エンコーディングでは、1つのUnicode文字を、1バイト、2バイト、3バイトまたは4バイトで表すことができます。ヨーロッパ言語の文字は、1バイトまたは2バイトで表します。ほとんどのアジア言語の文字は、3バイトで表します。補助文字は、4バイトで表します。UTF-8を実装するOracle Databaseキャラクタ・セットは、AL32UTF8です。

UTF-16

Unicodeの16ビット・エンコード形式です。UTF-16エンコーディングでは、1つのUnicode文字は、1つまたは2つの2コード単位です。スクリプトがヨーロッパの言語と、ほとんどのアジア言語の文字(ASCII文字を含む)は、1コード単位(2バイト)で表します。補助文字は、2コード単位(4バイト)で表します。UTF-16を実装するOracle Databaseキャラクタ・セットは、AL16UTF16とAL16UTF16LEです。AL16UTF16は、UTF-16エンコード形式のビッグエンディアン・コード体系を実装します(各コード単位の、重要性の高い方のバイトがメモリー内で先にきます)。AL16UTF16は、有効な各国語キャラクタ・セットです。AL16UTF16LEは、リトル・エンディアンUTF-16コード体系を実装します。変換専用のキャラクタ・セットで、SQL CONVERTまたはPL/SQL UTL_I18N.STRING_TO_RAWなど、キャラクタ・セット変換関数でのみ有効です。大部分のSQL文字列処理機能は、AL16UTF16の各UTF-16コード単位を別々の文字として扱うことに注意してください。関数INSTR4、SUBSTR4およびLENGTH4は例外です。

ワイド・キャラクタ

マルチバイト固定幅の文字形式。固定幅の領域でデータが処理されるので、大量のテキスト処理に適しています。マルチバイト変動幅の文字値は、より高速な処理のために内部的にワイド・キャラクタ書式に変換されている場合があります。

索引

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  R  S  T  U  V  W  X

数字

- 7ビット・コード体系 1

- 8ビット・コード体系 1

A

- 略称

- 言語 1

- 抽象データ型

- NCHARとして作成 1

- アクセント 1

- アクセントを区別しない言語ソート 1

- ADD_MONTHS SQL関数 1

- ADOインタフェースとUnicode 1

- AL16UTF16キャラクタ・セット 1 , 2

- AL24UTFFSSキャラクタ・セット 1

- AL32UTF8キャラクタ・セット 1 , 2 , 3

- ALTER SESSION文

- SET NLS_CURRENCY句 1 , 2

- SET NLS_LANGUAGE句 1

- SET NLS_NUMERIC_CHARACTERS句 1

- SET NLS_TERRITORY句 1

- application-locales 1

- Arial Unicode MSフォント 1

- ASCIIエンコーディング 1

B

- 基本文字 1 , 2

- BFILEデータ

- LOBへのロード 1

- バイナリ・ソート

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

- 例 1

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

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

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

- BLANK_TRIMMINGパラメータ 1

- BLOB

- 索引の作成 1

- バイト・セマンティクス 1 , 2

C

- カレンダ

- カスタマイズ 1

- パラメータ 1

- サポート対象 1

- カレンダ・ユーティリティ 1

- 標準的な同値化 1 , 2

- ケース 1

- 大/小文字を区別しない言語照合 1

- 大/小文字を区別する言語照合 1

- CDB 1

- CESU-8準拠 1

- 文字データ

- CONVERT SQL関数による変換 1

- 文字データ変換

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

- 文字データのスキャン

- キャラクタ・セットの移行前 1

- 文字の再配列 1

- 文字レパートリ 1

- 文字

- すべてのOracle Databaseキャラクタ・セットで使用可能 1

- 状況依存 1

- 短縮 1

- ユーザー定義 1

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

- キャラクタ・セット

- 変換 1

- データ消失

- 変換時 1

- Globalization Development Kitによる検出 1

- 各国語 1

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

- OCIクライアントとデータベース・サーバーの間 1

- パラメータ 1

- キャラクタ・セット定義

- カスタマイズ 1

- ファイルの編集に関するガイドライン 1

- ファイルのネーミング 1

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

- 文字データ変換の問題の識別 1

- 文字データのスキャン 1

- キャラクタ・セット

- AL16UTF16 1

- AL24UTFFSS 1

- AL32UTF8 1

- アジア地域 1

- データベース作成後の変更 1

- 選択 1

- 変換 1 , 2 , 3

- OCIを使用した変換 1

- カスタマイズ 1

- データ消失 1

- エンコーディング 1

- ヨーロッパ地域 1

- ISO 8859シリーズ 1

- 中東地域 1

- 移行 1 , 2

- ネーミング 1

- 各国語 1 , 2

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

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

- サポート対象 1

- 様々な文字レパートリのサポート 1

- ユニバーサル 1

- UTFE 1

- キャラクタ各国語 1

- 文字列型の変換

- エラー・レポート 1

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

- クライアントのオペレーティング・システム

- アプリケーションとのキャラクタ・セットの互換性 1

- CLOBおよびNCLOBデータ

- OCIでのバインドと定義 1

- CLOB

- 索引の作成 1

- C数値書式マスク 1

- コード・チャート

- 表示と印刷 1

- コード・ポイント 1

- 照合

- 大/小文字を区別しない 1

- 大/小文字を区別 1

- カスタマイズ 1

- ひらがなとカタカナ 1

- 言語 1

- 単一言語 1

- 多言語 1

- Unicode照合アルゴリズム 1

- 比較

- 言語 1

- 互換性

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

- 合成文字 1

- 状況依存文字 1

- 短縮文字 1

- 短縮文字 1

- 制御文字, エンコーディング 1

- 変換

- キャラクタ・セットID番号とキャラクタ・セット名 1

- 文字データの変換

- CONVERT SQL関数 1

- キャラクタ・セット間の文字データ変換 1

- CONVERT SQL関数

- キャラクタ・セット 1

- タイム・ゾーンの変換 1

- 協定世界時 1 , 2

- Unicodeデータ型を使用したデータベースの作成 1

- Unicodeデータベースの作成 1

- CSREPAIRスクリプト 1

- 通貨

- 形式 1

- CURRENT_DATE SQL関数 1

- CURRENT_TIMESTAMP SQL関数 1

D

- データベース

- マルチテナント・コンテナ 1

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

- 文字データ変換 1

- 選択 1

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

- パフォーマンス 1

- Database Migration Assistant for Unicode (DMU) 1

- データベース・スキーマ

- 複数言語用の設計 1

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

- データ変換

- Pro*C/C++ 1

- OCIドライバ 1

- ODBCおよびOLE DBドライバ 1

- Thinドライバ 1

- UnicodeのJava文字列 1

- データの拡張

- キャラクタ・セット移行時 1

- データ変換時 1

- データ消失の原因となるデータの非一貫性 1

- データ消失

- データの非一貫性が原因 1

- キャラクタ・セット変換時 1

- キャラクタ・セット移行時 1

- データ型変換時

- 例外 1

- OCIのUnicodeキャラクタ・セット変換時 1

- キャラクタ・セットの混在 1

- データ・ポンプのPL/SQLパッケージおよびキャラクタ・セットの移行 1

- データの切捨て

- 制限事項 1

- データ型変換

- データ消失と例外 1

- 暗黙的 1

- SQL関数 1

- データ型

- abstract 1

- datetime 1

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

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

- 時間隔 1 , 2

- サポート対象 1

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

- 日付書式

- パーティション・バウンド式 1

- 日付

- ISO規格 1 , 2

- NLS_DATE_LANGUAGEパラメータ 1

- 日時データ型

- 値の挿入 1

- 日時書式パラメータ 1

- 夏時間

- Oracleでのサポート 1

- 規則 1

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

- 曜日

- 書式要素 1

- 名前の言語 1

- DBTIMEZONE SQL関数 1

- dest_char_setパラメータ 1

- 言語とキャラクタ・セットの検出

- Globalization Development Kit 1

- 検出

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

- 発音区別記号 1

- DMU

- Database Migration Assistant for Unicode 1

- DST_UPGRADE_INSERT_CONV初期化パラメータ 1

- DUCET(Default Unicode Collation Element Table) 1

E

- エンコーディング

- 制御文字 1

- 表意的記述法 1

- 数字 1

- 表音的記述法 1

- 句読点 1

- 記号 1

- コード体系

- 7ビット 1

- 8ビット 1

- 固定幅 1

- マルチバイト 1

- シフト・センシティブ可変幅 1

- シフト・センシティブ可変幅マルチバイト 1

- シングルバイト 1

- 可変幅 1

- 環境変数

- ORA_SDTZ 1

- ORA_TZFILE 1

- エラー・メッセージ

- 言語 1

- 翻訳 1

- ユーロ

- Oracleでのサポート 1

- 拡張文字

- 文字

- 拡張 1

- EXTRACT (日時) SQL関数 1

F

- 固定幅マルチバイト・コード体系 1

- フォント

- Unicode 1

- UNIX用Unicode 1

- Windows用Unicode 1

- 書式要素

- C 1

- D 1

- day 1

- G 1

- IW 1

- IY 1

- L 1

- month 1

- RM 1

- RN 1

- フォーマット・マスク 1 , 2

- 書式

- 通貨 1

- 日付 1 , 2

- 数値 1

- 時間 1

- FROM_TZ SQL関数 1

G

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

- 例 1

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

- GDKコンポーネント 1

- GDKエラー・メッセージ 1

- GDKのJava API 1

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

- GDK Localizerオブジェクト 1

- Globalization Development Kit

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

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

- コンポーネント 1

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

- 電子メール・プログラム 1

- エラー・メッセージ 1

- フレームワーク 1

- ロケール・ソースの統合 1

- Java API 1

- Java提供パッケージおよびクラス 1

- ロケール検出 1

- Localizerオブジェクト 1

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

- JSPおよびJavaサーブレットの文字列の管理 1

- HTMLページでの非ASCII入出力 1

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

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

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

- Oracleのロケール情報 1

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

- Oracleの翻訳されたロケール名およびタイムゾーン名 1

- サポートされているロケール・リソース 1

- グローバリゼーション機能 1

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

- アーキテクチャ 1

- グリニッジ標準時 1 , 2

- 言語またはキャラクタ・セットの推測 1

H

- ひらがな 1

I

- IANAキャラクタ・セット

- ISOロケールによるマッピング 1

- 表意的記述法, エンコーディング 1

- 無視可能文字 1

- 暗黙的なデータ型変換 1

- 索引

- CLOBとして格納されたドキュメント用の作成 1

- 多言語ドキュメントの検索用に作成 1

- BLOBとして格納されたドキュメントに対する索引の作成 1

- 言語 1

- パーティション 1

- 初期化パラメータ

- DST_UPGRADE_INSERT_CONV 1

- 初期化パラメータ

- NLS_DATE_FORMAT 1

- NLS_TIMESTAMP_FORMAT 1

- NLS_TIMESTAMP_TZ_FORMAT 1

- INSTR SQL関数 1

- インターネット・アプリケーション

- ロケール

- 判別 1

- 単一言語 1 , 2

- 多言語 1 , 2

- 期間データ型

- 値の挿入 1

- ISO 8859キャラクタ・セット 1

- ISOロケール

- IANAキャラクタ・セットによるマッピング 1

- ISO規格

- 日付書式 1

- ISO規格日付書式 1 , 2

- ISO週番号 1

- IW書式要素 1

- IY書式要素 1

J

- Java

- Unicodeデータ変換 1

- Java文字列

- Unicodeでのバインドと定義 1

- JDBC OCIドライバ

- Unicode 1

- JDBCのプログラミング

- Unicode 1

- サーバー側JDBC内部ドライバ

- Unicode 1

- サーバー側JDBC Thinドライバ

- Unicode 1

- JDBC Thinドライバ

- Unicode 1

K

- カタカナ 1

L

- 言語

- Globalization Development Kitによる検出 1

- 言語の略称 1

- Language and Character Set File Scanner 1

- 言語の定義

- カスタマイズ 1

- オーバーライド 1

- 言語

- エラー・メッセージ 1

- 言語とキャラクタ・セット

- LCSSCANのサポート対象 1

- 言語サポート 1

- LAST_DAY SQL関数 1

- LCSSCAN

- エラー・メッセージ 1

- LCSSCAN

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

- LCSSCANコマンド

- BEGINパラメータ 1

- ENDパラメータ 1

- 例 1

- FILEパラメータ 1

- HELPパラメータ 1

- オンライン・ヘルプ 1

- RESULTSパラメータ 1

- 長さセマンティクス 1 , 2

- SQL文のLIKE条件 1

- 言語比較 1

- 言語索引 1

- 言語ソートの定義

- サポート対象 1

- 言語ソート

- アクセントを区別しない 1

- BINARY 1

- BINARY_AI, 言語ソート

- BINARY_CI 1

- 大/小文字を区別しない 1

- 制御 1

- カスタマイズ

- 発音区別記号付き文字 1 , 2

- レベル 1

- デフォルトのリスト 1

- パラメータ 1

- リスト・パラメータ 1

- lmsgenユーティリティ 1

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

- LOB

- 外部BFILEデータのロード 1

- 複数言語によるドキュメントの格納 1

- ロケール

- 依存性 1

- インターネット・アプリケーション

- 判断 1

- variant 1

- locale-charset-map 1

- locale-determine-rule 1

- ロケール情報

- Oracleと他の規格とのマッピング 1

- locale-parameter-name 1

- LOCALTIMESTAMP SQL関数 1

M

- message-bundles 1

- 移行

- キャラクタ・セット 1

- キャラクタ・セットの混在

- データ消失 1

- 通貨パラメータ 1

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

- 単一言語ソート

- 例 1

- サポート対象 1

- 月

- 書式要素 1

- 名前の言語 1

- MONTHS_BETWEEN SQL関数 1

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

- 固定幅 1

- シフト・センシティブ可変幅 1

- 可変幅 1

- マルチレクサー

- 作成 1

- 多言語データ

- 列の長さの指定 1

- 多言語ドキュメントの検索

- 索引の作成 1

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

- 多言語ソート

- 例 1

- サポート対象 1

- 複数言語

- データベース・スキーマの設計 1

- データの保管 1

- LOBへのドキュメントの格納 1

- マルチテナント・コンテナ・データベース 1

N

- 各国語キャラクタ・セット 1 , 2 , 3 , 4

- NCHARデータ型

- 抽象データ・タイプの作成 1

- NCLOBデータ型 1

- NEW_TIME SQL関数 1

- NEXT_DAY SQL関数 1

- NLBデータ

- トランスポータブル 1

- NLBファイル 1

- NLBファイル

- 生成とインストール 1

- NLS_CALENDARパラメータ 1

- NLS_COMPパラメータ 1 , 2

- NLS_CREDITパラメータ 1

- NLS_CURRENCYパラメータ 1

- NLS_DATE_FORMAT初期化パラメータ 1

- NLS_DATE_FORMATパラメータ 1

- NLS_DATE_LANGUAGEパラメータ 1

- NLS_DEBITパラメータ 1

- NLS_DUAL_CURRENCYパラメータ 1

- NLS_ISO_CURRENCYパラメータ 1

- NLS_LANGパラメータ

- ロケールの選択 1

- クライアントの設定 1

- 例 1

- OCIクライアント・アプリケーション 1

- 指定 1

- UNIXクライアント 1

- Windowsクライアント 1

- NLS_LENGTH_SEMANTICS初期化パラメータ 1

- NLS_LENGTH_SEMANTICSセッション・パラメータ 1

- NLS_LIST_SEPARATORパラメータ 1

- NLS_MONETARY_CHARACTERSパラメータ 1

- NLS_NCHAR_CONV_EXCPパラメータ 1

- NLS_NUMERIC_CHARACTERSパラメータ 1

- NLS_SORTパラメータ 1

- NLS_TERRITORYパラメータ 1

- NLS_TIMESTAMP_FORMAT初期化パラメータ 1

- NLS_TIMESTAMP_TZ_FORMAT初期化パラメータ 1

- NLSカレンダ・ユーティリティ 1

- NLSパラメータ

- SQL関数でのデフォルト値 1

- リスト 1

- 設定 1

- SQL関数での指定 1

- SQL関数で受け入れられない 1

- NLSRTL 1

- NLSランタイム・ライブラリ 1

- NLSSORT SQL関数

- 構文 1

- NLTファイル 1

- 数字, エンコーディング 1

- 数値書式

- SQLマスク 1

- 数値パラメータ 1

- NUMTODSINTERVAL SQL関数 1

- NUMTOYMINTERVAL SQL関数 1

- NVARCHARデータ型

- Pro*C/C++ 1

O

- obsoleteキャラクタ・セット 1

- OCI

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

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

- SQL CHARデータ型 1

- OCI_UTF16IDキャラクタ・セットID 1

- OCIおよびUnicode 1

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

- データ消失 1

- パフォーマンス 1

- OCICharSetConvert() 1

- OCIクライアント・アプリケーション

- Unicodeキャラクタ・セットを使用 1

- OCIのデータ変換

- データの拡張 1

- OCINlsCharSetIdToName() 1

- OCINlsCharSetNameTold() 1

- OCINlsEnvironmentVariableGet() 1

- OCINlsGetInfo() 1

- OCINlsNumericInfoGet() 1

- OCIWideCharIsUpper() 1

- ODBC Unicodeアプリケーション 1

- OLE DB Unicodeデータ型 1

- オペレーティング・システム

- アプリケーションとのキャラクタ・セットの互換性 1

- ORA_DST_AFFECTED SQL関数 1

- ORA_DST_CONVERT SQL関数 1

- ORA_DST_ERROR SQL関数 1

- ORA_SDTZ環境変数 1

- ORA_TZFILE環境変数 1

- Oracle Call InterfaceとUnicode 1

- Oracle Data Provide for .NETとUnicode 1

- Oracle Data Pumpおよびキャラクタ・セットの変換 1

- Oracleの言語およびキャラクタ・セットの検出Javaクラス 1

- Oracle Locale Builder

- カレンダ書式の選択 1

- 通貨書式の選択 1

- 日付および時刻書式の選択 1

- コード・チャートの表示 1

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

- フォント 1 , 2

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

- 「NLTのプレビュー」画面 1

- ロケール・オブジェクト名に関する制限事項 1

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

- 起動 1

- Oracle ODBCドライバとUnicode 1

- Oracle OLE DBドライバとUnicode 1

- Oracle Pro*C/C++とUnicode 1

- ORDER BY句 1

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

P

- page-charset 1

- パラメータ

- BLANK_TRIMMING 1

- カレンダ 1

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

- 言語ソート 1

- 設定方法 1

- 通貨 1

- NLS_CALENDAR 1

- NLS_COMP 1

- NLS_CREDIT 1

- NLS_CURRENCY 1

- NLS_DATE_FORMAT 1

- NLS_DATE_LANGUAGE 1

- NLS_DEBIT 1

- NLS_DUAL_CURRENCY 1

- NLS_ISO_CURRENCY 1

- NLS_LANG 1

- NLS_LIST_SEPARATOR 1

- NLS_MONETARY_CHARACTERS 1

- NLS_NCHAR_CONV_EXCP 1

- NLS_NUMERIC_CHARACTERS 1

- NLS_SORT 1

- NLS_TERRITORY 1

- 数値 1

- 設定 1

- 日付と時間 1

- パーティション

- 索引 1

- 表 1

- PDB 1

- パフォーマンス

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

- OCIのUnicodeキャラクタ・セット変換時 1

- 表音的記述法, エンコーディング 1

- PL/SQLおよびSQLとUnicode 1

- 1次レベル・ソート 1

- Private Use Area 1

- Pro*C/C++

- データ変換 1

- NVARCHARデータ型 1

- VARCHARデータ型 1

- 句読点, エンコーディング 1

R

- 正規表現

- 文字クラス 1

- 文字範囲 1

- 照合要素デリミタ 1

- 同値化クラス 1

- 例 1

- 多言語環境 1

- 置換文字

- CONVERT SQL関数 1

- 制限事項

- データの切捨て 1

- パスワード 1

- エクスポート時の空白埋込み 1

- ユーザー名 1

- 逆2次ソート 1

- ROUND (date) SQL関数 1

- RPAD SQL関数 1

S

- 多言語ドキュメントの検索 1

- 文字列の検索 1

- 2次レベル・ソート 1

- セッション・タイム・ゾーン 1

- SESSIONTIMEZONE SQL関数 1

- シフト・センシティブ可変幅マルチバイト・コード体系 1

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

- ソート

- 逆2次 1

- 非デフォルトの言語ソートの指定 1 , 2

- source_char_setパラメータ 1

- 空白埋込み

- エクスポート時 1

- 特殊組合せ文字 1 , 2

- 特殊文字 1 , 2

- 特殊小文字 1

- 特殊大文字 1

- SQL CHARデータ型

- OCI 1

- SQL関数

- ORA_DST_AFFECTED 1

- ORA_DST_CONVERT 1

- ORA_DST_ERROR 1

- SQL関数

- ADD_MONTHS 1

- CONVERT 1

- CURRENT_DATE 1

- CURRENT_TIMESTAMP 1

- データ型変換 1

- DBTIMEZONE 1

- NLSパラメータのデフォルト値 1

- EXTRACT(日時) 1

- FROM_TZ 1

- INSTR 1

- LAST_DAY 1

- LOCALTIMESTAMP 1

- MONTHS_BETWEEN 1

- NEW_TIME 1

- NEXT_DAY 1

- NLSSORT 1

- NUMTODSINTERVAL 1

- NUMTOYMINTERVAL 1

- ROUND(日付) 1

- RPAD 1

- SESSIONTIMEZONE 1

- NLSパラメータの指定 1

- SYS_EXTRACT_UTC 1

- SYSDATE 1

- SYSTIMESTAMP 1

- TO_CHAR(日時) 1

- TO_DSINTERVAL 1

- TO_TIMESTAMP 1

- TO_TIMESTAMP_TZ 1

- TO_YMINTERVAL 1

- TRUNC(日付) 1

- TZ_OFFSET 1

- 受け入れられないNLSパラメータ 1

- SQL NCHARデータ型

- OCIでのバインドと定義 1

- SQL文

- LIKE条件 1

- 完全なスーパーセット 1

- 文字列の比較

- WHERE句 1

- 文字列リテラル

- Unicode 1

- OCIを使用した文字列操作 1

- 文字列

- 検索 1

- スーパーセット, 完全 1

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

- 補助文字

- 言語ソートのサポート 1

- サポートされているデータ型 1

- サポートされている地域 1

- 表音文字セット 1

- 記号, エンコーディング 1

- SYS_EXTRACT_UTC SQL関数 1

- SYSDATE SQL関数 1

- SYSTIMESTAMP SQL関数 1

T

- 表

- パーティション 1

- 地域

- 依存性 1

- 地域定義

- カスタマイズ 1

- オーバーライド 1

- 地域サポート 1 , 2

- 地域のバリアント 1

- 3次レベル・ソート 1

- タイ語とラオ語の文字の再配列 1

- チルダ 1

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

- TIMESTAMPデータ型

- 使用する状況 1

- TIMESTAMPデータ型

- 選択 1

- タイムスタンプ書式 1

- TIMESTAMP WITH LOCAL TIME ZONEデータ型

- 使用する状況 1

- TIMESTAMP WITH TIME ZONEデータ型

- 使用する状況 1

- タイム・ゾーン

- 略称 1

- データベース 1

- データ・ソース 1

- 環境変数 1

- ファイル 1

- 名前 1

- セッション 1

- タイム・ゾーン・ファイル

- 選択 1

- アップグレード手順 1

- アップグレード 1

- タイム・ゾーン

- 変換 1

- タイム・ゾーン・ファイルのアップグレード 1

- TO_CHAR (日時) SQL関数 1

- TO_CHAR SQL関数

- 書式マスク 1

- グループ・セパレータ 1

- 曜日と月の表記 1

- TO_DATE SQL関数

- 書式マスク 1

- 曜日と月の表記 1

- TO_DSINTERVAL SQL関数 1

- TO_NUMBER SQL関数

- 書式マスク 1

- TO_TIMESTAMP_TZ SQL関数 1

- TO_TIMESTAMP SQL関数 1

- TO_YMINTERVAL SQL関数 1

- 転送可能なNLBデータ 1

- TRUNC (date) SQL関数 1

- TZ_OFFSET SQL関数 1

- TZABBREV 1

- TZNAME 1

U

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

- Unicode

- Java文字列のバインドと定義 1

- 文字コードの割当て 1

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

- UTF-16文字のコード範囲 1

- UTF-8文字のコード範囲 1

- Javaでのデータ変換 1

- エンコーディング 1

- フォント 1

- JDBC OCIドライバ 1

- JDBCのプログラミング 1

- サーバー側JDBC内部ドライバ 1

- サーバー側JDBC Thinドライバ 1

- JDBC Thinドライバ 1

- モード 1

- ODBCとOLE DBのプログラミング 1

- Oracle Call Interface 1

- Oracle Data Provider for .NET 1

- Oracle ODBCドライバ 1

- Oracle OLE DBドライバ 1

- Oracle Pro*C/C++ 1

- Oracleでのサポート 1

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

- PL/SQLとSQL 1

- Private Use Area 1

- プログラミング 1

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

- 文字列リテラル 1

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

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

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

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

- XMLプログラミング 1

- Unicodeデータベース

- 事例 1

- Unicodeデータ型

- 事例 1

- アップグレード

- 夏時間 1

- url-rewrite-rule 1

- US7ASCII

- スーパーセット 1

- ユーザー定義文字

- キャラクタ・セット定義への追加 1

- キャラクタ・セット間でのクロス・リファレンス 1

- UTC 1 , 2

- UTF-16エンコーディング 1 , 2

- UTF8キャラクタ・セット 1 , 2

- UTF-8エンコーディング 1 , 2

- UTFEキャラクタ・セット 1 , 2

V

- VARCHARデータ型

- Pro*C/C++ 1

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

W

- 波形のダッシュ 1

- WHERE句

- 文字列の比較 1

X

- XML

- Javaを使用してUnicodeで解析 1

- Javaを使用してUnicodeで読取り 1

- Javaを使用してUnicodeで作成 1

- XMLプログラミング

- Unicode 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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)を参照してください。