1. Databaseグローバリゼーション・サポート・ガイド
  2. Oracle Globalization Development Kit

8 Oracle Globalization Development Kit

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

8.1 Oracle Globalization Development Kitの概要

国際化されたアプリケーションの設計および開発は、最も経験豊富な開発者にとってさえ困難な作業になる場合があります。これは通常、知識不足やグローバリゼーションの概念とAPIが複雑であるために起こります。Oracle Databaseを使用してアプリケーションを記述するアプリケーション開発者は、様々な文字セット、地域、言語および言語ソート定義のプロパティなど、データベースのグローバリゼーション・サポートのアーキテクチャを理解する必要があります。また、中間層のプログラミング環境のグローバリゼーション機能を理解し、データベースのロケール・モデルとどのように相互作用し、同期化するかを調べる必要もあります。さらに、国際化されたインターネット・アプリケーションを開発するには、文字セットおよびロケール要件の異なる様々なオペレーティング・システム上で実行中の複数のクライアントを同時にサポートする機能を持ったコードを設計し、記述することが必要です。

Oracle Globalization Development Kit(GDK)を使用すると、開発プロセスが簡素化され、グローバル環境のサポートに使用されるインターネット・アプリケーションの開発コストが削減されます。GDKには、JavaおよびPL/SQL用の包括的なプログラミングAPI、サンプル・コード、グローバル・アプリケーションの作成中に発生する設計、開発およびデプロイメント上の様々な問題に対処するドキュメントが含まれています。

GDKは主に、GDK for JavaとGDK for PL/SQLの2つからなります。GDK for Javaは、Javaアプリケーションに対してグローバリゼーション・サポートを提供します。GDK for PL/SQLは、PL/SQLプログラミング環境に対してグローバリゼーション・サポートを提供します。Java用GDKとPL/SQL用GDKでは、提供される機能が異なります。

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

グローバルなWebサイトやグローバルなインターネット・アプリケーションのデプロイには、グローバリゼーション要件とビジネス要件に応じて2つのアーキテクチャ・モデルがあります。どちらのモデルをデプロイするかは、インターネット・アプリケーションの開発方法と、中間層におけるアプリケーション・サーバーの構成方法に影響します。この2つのモデルは次のとおりです。

  • 単一言語インターネット・アプリケーションの複数インスタンス

    単一バイナリでロケールを1つのみサポートするインターネット・アプリケーションは、単一言語アプリケーションとして分類されます。ロケールとは、各国の言語およびその言語が話される地域のことです。たとえば、米国と英国の主要言語は英語です。ただし、この2つの地域の通貨と日付書式の表記規則は異なります。そのため、米国と英国は2つの異なるロケールとみなされます。

    このレベルのグローバリゼーション・サポートは、アプリケーション・インスタンスごとに1つのロケールをサポートする場合に適しています。様々なロケールのアプリケーションにアクセスするには、異なるエントリ・ポイントが必要になります。このモデルが管理可能なのは、サポート対象のロケールが少ない場合のみです。

  • 多言語アプリケーションの単一インスタンス

    単一バイナリで同時に複数のロケールをサポートするインターネット・アプリケーションは、多言語アプリケーションとして分類されます。このレベルのグローバリゼーション・サポートは、1つのインターネット・アプリケーションで同時に複数のロケールをサポートする必要がある場合に適しています。異なるロケール環境のユーザーは、同じエントリ・ポイントを使用してアプリケーションにアクセスします。

    単一言語モデルを使用したアプリケーション開発は、多言語モデルを使用したアプリケーション開発とはまったく異なります。Globalization Development Kitは、どちらのアーキテクチャ・モデルを使用したグローバル・アプリケーション開発も支援できるように複数のライブラリで構成されています。

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

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

次の図に、単一言語インターネット・アプリケーションの複数インスタンスを使用した、グローバル・インターネット・アプリケーションのデプロイを示します。

図8-1 単一言語インターネット・アプリケーションのアーキテクチャ

図8-1の説明が続きます
「図8-1 単一言語インターネット・アプリケーションのアーキテクチャ」の説明

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

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

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

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

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

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

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

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

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

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

サポート対象のロケール数が増えるほど、デメリットがメリットを上回ることになります。単一言語デプロイメント・モデルに伴う制限とメンテナンスのオーバーヘッドを考慮すると、このデプロイメント・アーキテクチャは1つまたは2つのロケールのみをサポートするアプリケーションに適しています。

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

多言語インターネット・アプリケーションは、すべてのロケールを処理する単一アプリケーション・サーバー構成を持つアプリケーション・サーバーにデプロイされます。次の図に、多言語インターネット・アプリケーションのアーキテクチャを示します。

図8-2 多言語インターネット・アプリケーションのアーキテクチャ

図8-2の説明が続きます
「図8-2 多言語インターネット・アプリケーションのアーキテクチャ」の説明

単一のアプリケーション・インスタンスで複数のロケールをサポートするには、アプリケーションで次の操作が必要になる場合があります。

  • ユーザーのロケールを動的に検出し、そのロケールの言語および文化的な慣習に従ってHTMLページを構成することで調整します。

  • どの言語のデータでもサポートできるように、文字データをUnicodeで処理します。文字データは、ユーザーが入力してもバックエンド・データベースから取り出してもかまいません。

  • HTMLページに使用するHTMLページ・エンコーディング(文字セット)を動的に判別し、Unicodeとページ・エンコーディングの間でコンテンツを変換します。

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

  • すべてのアプリケーション・サーバーに1つのアプリケーション・サーバー構成を使用することで、デプロイメント構成が単純化され、メンテナンス・コストが削減されます。

  • パフォーマンス・チューニングと処理能力計画は、Webサイトでサポートされるロケールの数に依存しません。

  • ロケールの追加導入が比較的容易です。新規ロケール用にマシンを追加する必要はありません。

  • 1つのテスト環境で様々なロケールにまたがってアプリケーションをテストできます。

  • このモデルでは、同じアプリケーション・インスタンス内で多言語によるコンテンツをサポートできます。たとえば、このモデルでは、日本語、中国語、英語およびアラビア語のデータを含むWebページを容易にサポートできます。

多言語インターネット・アプリケーションをデプロイするデメリットは、アプリケーション開発時に動的なロケール検出とUnicodeを処理するために余分なコーディングが必要になることです。1つまたは2つの言語のみをサポートすればよい場合、この作業は多額のコストを伴います。

Webサイトで複数のロケールがサポートされている場合には、単一言語アプリケーションをデプロイするよりも多言語インターネット・アプリケーションをデプロイするほうが適しています。

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

異なるロケールをサポートするインターネット・アプリケーションを構築するには、優れた開発力が必要です。

多言語インターネット・アプリケーションの場合は、アプリケーション自体がユーザーのロケールを認識し、ロケールに適したコンテンツを表示できる必要があります。クライアントは、そのロケールに関係なくアプリケーション・サーバーと通信できる必要があります。これにより、アプリケーション・サーバーはデータベース・サーバーと通信し、様々なロケール設定および文字セット設定の作業環境を維持しながらデータを交換します。多言語インターネット・アプリケーションを開発する際に重要な考慮事項の1つは、ユーザーの優先ロケールに従って適切なコンテンツを動的に検出、キャッシュして提供できるようにすることです。

単一言語インターネット・アプリケーションの場合、ユーザーのロケールは常に固定であり、通常はランタイム環境のデフォルト・ロケールに従います。そのため、ロケール構成ははるかに単純です。

次の項では、グローバルなインターネット・アプリケーションの開発時に開発者が直面する最も一般的な問題について説明します。

8.3.1 ロケールの判別

ロケール対応またはロケール依存にするには、インターネット・アプリケーションがユーザーの優先ロケールを判別できる必要があります。

単一言語アプリケーションでは、常にユーザーに同じロケールが提供され、そのロケールは対応するプログラミング環境のデフォルトのランタイム・ロケールと等価である必要があります。

多言語アプリケーションでは、ユーザー・ロケールを次の3つの方法で動的に判別できます。どの方法にもそれぞれメリットとデメリットがありますが、アプリケーションで併用して相互に補完できます。ユーザー・ロケールは、次の方法で判別できます。

  • Oracle Internet DirectoryなどのLDAPディレクトリ・サーバーからのユーザー・プロファイル情報、またはデータベースに格納されている他のユーザー・プロファイル表に基づく方法

    ユーザー・プロファイルのスキーマには、ユーザーのロケールを示す優先ロケール属性を含める必要があります。ユーザーが前にログオンしたことがない場合、このロケール・ユーザーの判別方法は動作しません。

  • ブラウザのデフォルト・ロケールに基づく方法

    ブラウザからデフォルトのISOロケール設定を取得します。ブラウザのデフォルトのISOロケールは、すべてのHTTPリクエストでAccept-Language HTTPヘッダーを介して送信されます。Accept-LanguageヘッダーがNULLの場合は、デフォルトで必要なロケールを英語に設定する必要があります。このアプリケーションの短所は、Accept-Languageヘッダーがユーザーのロケール情報に関して信頼できるソースでない場合があることです。

  • ユーザーの選択に基づく方法

    ユーザーがリスト・ボックスまたはメニューからロケールを選択し、アプリケーションのロケールを選択したロケールに切り替えられるようにします。

Globalization Development Kitは、これらのロケール判別方法を宣言的に使用できるアプリケーション・フレームワークを提供します。

関連項目:

「Globalization Development Kitスタート・ガイド」

8.3.2 ロケール対応

ロケール対応またはロケール依存にするには、インターネット・アプリケーションでユーザーのロケールを判別する必要があります。ユーザー・ロケールの判別後に、アプリケーションで次の操作を実行する必要があります。

  • ロケールの言語による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クラスのセットが用意されています。

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

アプリケーションで多言語環境をサポートするには、コンテンツを使用言語とユーザーのロケールの表記規則で表示できる必要があります。ハードコード化されたユーザー・インタフェースのテキストは、アプリケーションでサポートされる様々な言語に翻訳できるように、イメージ・ファイルとともにアプリケーションから外部化する必要があります。その後、翻訳ファイルを個別のディレクトリにステージングし、アプリケーションでユーザー・ロケール設定に従って関連コンテンツを検索できるようにします。また、代替メカニズムをサポートするために、特殊なアプリケーション処理が必要になることもあります。これにより、ユーザーの優先ロケールが使用できない場合に、2番目に適切なコンテンツが表示されます。たとえば、カナダ系フランス語のコンテンツが使用できない場合は、かわりにアプリケーションをフランス語ファイルに切り替えることが適切である可能性があります。

8.4 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パッケージのスイートが含まれています。

次の図に、GDKの主要コンポーネントと、コンポーネント相互の関係を示します。ユーザー・アプリケーションは、中間層のOracle Application ServerのJ2EEコンテナで実行されます。GDKは、J2EEアプリケーションでグローバリゼーション・サポート用のコーディングを簡素化するためのアプリケーション・フレームワークを提供します。フレームワークとアプリケーションは、どちらもGDKのJava APIをコールしてロケール依存タスクを実行します。PL/SQL用GDKには、PL/SQL環境に固有のグローバリゼーションの問題を解決する上で役立つPL/SQLパッケージが用意されています。

図8-3 GDKのコンポーネント

図8-3の説明が続きます
「図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は必要ありません。

8.5 GDKクイック・スタート

この項では、GDKを使用して、単一言語アプリケーションをグローバルな多言語アプリケーションに変更する方法を説明します。この章の以降の各項では、GDKの使用方法に関する詳細を説明します。

次の図に、単一言語Webアプリケーションのスクリーンショットを示します。

図8-4 元の「HelloWorld」Webページ

図8-4の説明が続きます
「図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。この機能には、ロケールに依存した方法での表示文字列の選択および日時の値の書式設定が含まれます。

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

この項では、HelloWorldアプリケーションを変更してグローバリゼーションをサポートする方法を説明します。このアプリケーションは、簡体字中国語(zh-CN)、スイス系ドイツ語(de-CH)およびアメリカ英語(en-US)という3つのロケールをサポートするよう変更されます。言語に対して次のルールが使用されます。

  • クライアント・ロケールでこれらの言語のいずれかがサポートされている場合、その言語がアプリケーションに使用されます。

  • クライアント・ロケールでこれらの言語のいずれかがサポートされていない場合、アメリカ英語がアプリケーションに使用されます。

さらに、ユーザーはロケール選択リストからサポートされるロケールを選択することで、言語を変更できます。次の各タスクは、アプリケーションの変更方法を説明しています。

タスク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>

次の図に、ブラウザ設定項目の主要ロケールであるzh-CNロケールにより構成されたHelloWorldアプリケーションを示します。HelloWorldの文字列およびページ・タイトルは、簡体字中国語で表示されています。さらに、日付はロケール表記規則zh-CNで書式設定されています。この例では、ユーザーはロケール選択リストからロケールを上書きできます。

図8-5 zh-CNロケールにあわせてローカライズされたHelloWorld

図8-5の説明が続きます
「図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ファイルによりクラスが指定されます。

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

Java用GDKは、中間層のJ2EEアプリケーション用のグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。また、インターネット・アプリケーションをグローバル対応にするために必要な労力が最小限に抑えられます。次の図は、GDKアプリケーション・フレームワークを示しています。

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

図8-6の説明が続きます
「図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オブジェクトをフレームワークにプラグインし、それを使用してユーザー・ロケールを検出できます。

この項には次のトピックが含まれます:

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

J2EE用のGDKアプリケーション・フレームワークの動作は、GDKアプリケーション構成ファイルgdkapp.xmlにより制御されます。アプリケーション構成ファイルを使用することで、開発者はグローバル・アプリケーションの動作を1箇所で指定できます。GDKを使用するJ2EEアプリケーションごとに、1つのアプリケーション構成ファイルが必要です。gdkapp.xmlファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリに置く必要があります。このファイルでは、GDKフレームワークの動作およびプロパティと、それを使用するアプリケーションを指定します。このファイルには、ロケール・マッピング表、コンテンツ・ファイルの文字セットおよびアプリケーションの構成用グローバリゼーション・パラメータが含まれます。アプリケーション管理者はアプリケーション構成ファイルを変更することで、プログラムを変更したり再コンパイルしなくても、アプリケーションのグローバリゼーション動作を変更できます。

関連項目:

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

J2EEアプリケーションで、対応するGDKアプリケーション構成ファイルにより定義されたGDKアプリケーション・フレームワークを使用するには、アプリケーションのweb.xmlファイル内でGDKサーブレット・フィルタとGDKコンテキスト・リスナーを定義する必要があります。web.xmlファイルを変更し、ファイルの先頭に次の行を挿入してください。 

<web-app>
<!-- Add GDK filter that is called after the authentication -->

<filter>
    <filter-name>gdkfilter</filter-name>
    <filter-class>oracle.i18n.servlet.filter.ServletFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>gdkfilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>

<!-- Include the GDK context listener -->

 <listener>
<listener-class>oracle.i18n.servlet.listener.ContextListener</listener-class>
 </listener>
</web-app>

gdkapp.xmlファイルとweb.xmlファイルの例は、$ORACLE_HOME/nls/gdk/demoディレクトリにあります。

GDKアプリケーション・フレームワークは、バージョン2.3以降のサーブレット・コンテナをサポートしています。GDKアプリケーション・フレームワークでは、サーブレット・フィルタ機能を使用して、ユーザー・ロケールの判別やコンテンツ・ファイルの文字セットの指定などの、透過的なグローバリゼーション操作が実行されます。ContextListenerは、GDKアプリケーション構成ファイルに記述されているGDKアプリケーション・パラメータをインスタンス化します。ServletFilterは、リクエスト・オブジェクトとレスポンス・オブジェクトを、それぞれGDKリクエスト(ServletRequestWrapper)およびGDKレスポンス(ServletResponseWrapper)オブジェクトでオーバーライドします。

アプリケーションで他のアプリケーション・フィルタが使用され、同じメソッドのオーバーライドもする場合は、GDKフレームワーク内のフィルタが不正な結果を戻すことがあります。たとえば、getLocaleがen_USを戻しても、その結果が他のフィルタによりオーバーライドされると、GDKロケール検出メカニズムの結果が影響を受けます。GDKフレームワークのフィルタでオーバーライドされるすべてのメソッドについては、『Oracle Globalization Development Kit Java API Reference』を参照してください。GDKフレームワークとともに他のフィルタを使用する場合は、競合の可能性に注意してください。

8.6.2 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』を参照してください

8.6.3 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パラメータ名をアプリケーション構成ファイル内でカスタマイズできることに注意してください。

8.6.4 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』を参照してください

8.6.5 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メソッドから戻されることがあります。

8.6.6 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ロケール情報」

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

この項には次のトピックが含まれます:

8.6.7.1 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クラスのサブクラスのインスタンスです。

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

ロケールを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(スペインのスペイン語)ファイルが使用可能であれば、各メソッドはかわりにスペイン語の翻訳済ファイルを選択します。

8.7 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の主な機能は、次のとおりです。

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

8.7.2 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の使用」

8.7.3 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でサポートされています。

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

図8-7 Oracle文字セット・プラグイン

図8-7の説明が続きます
「図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つです。

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

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

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

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

ノート:

JDKのバージョンごとにサポートするUnicode規格のバージョンが異なる可能性があるので、GDKではUnicode規格の最新バージョン(現時点ではUnicode 12.1)に基づく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;
}

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

8.7.7 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]);
  ...
}

8.7.8 電子メール・プログラムへの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();
    }
  }
}

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

GDKアプリケーション構成ファイルでは、GDKアプリケーション・フレームワークの動作およびプロパティと、それを使用するアプリケーションを指定します。このファイルには、アプリケーション構成に関するロケール・マッピング表およびパラメータが含まれます。アプリケーションごとに1つの構成ファイルが必要です。

gdkapp.xmlアプリケーション構成ファイルはXML文書です。このファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリにあります。

次の項では、アプリケーション構成ファイルの内容とプロパティの詳細を説明します。

8.8.1 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」

8.8.2 page-charset

このセクションでは、アプリケーション・ページの文字セットを定義します。このセクションが特定の文字セットに明示的に設定されている場合は、すべてのページでこの文字セットが使用されます。文字セット名は、IANA文字セットの表記規則に従う必要があります。

<page-charset>UTF-8</page-charset>

ただし、page-charsetがAUTO-CHARSETに設定されている場合、文字セットは現行のユーザー・ロケールのデフォルト文字セットに基づきます。デフォルトの文字セットは、アプリケーション構成ファイルで指定されているロケールから文字セットへのマッピング表から導出されます。

アプリケーション構成ファイル内の文字セット・マッピング表が使用できない場合、文字セットはGDK内のデフォルト・ロケール名からIANA文字セットへのマッピング表に基づきます。デフォルト・マッピングは、OraLocaleInfoクラスから導出されます。

関連項目:

8.8.3 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"を指定)することをお薦めします。

8.8.4 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ディレクトリにあります。

8.8.5 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でパラメータに使用されます。

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

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

8.8.8 例: 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>

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

Oracle Globalization Services for Javaには、次のパッケージが含まれています。

8.9.1 oracle.i18n.lcsd

oracle.i18n.lcsdパッケージは、テキスト入力に基づいて言語と文字セットを自動的に検出して認識するクラスを提供します。プレーン・テキスト・ファイルとHTMLファイルの両方の検出がサポートされます。言語はISOに基づき、エンコーディングはIANAまたはOracle文字セットに基づきます。このパッケージには次のクラスがあります。

  • LCSDetector: テキスト入力に基づいて言語と文字セットを自動的に検出して認識するメソッドが含まれています。

  • LCSDResultSet: LCSDetectorにより生成される結果を格納します。このクラスのメソッドを使用すると、結果から特定の情報を取り出すことができます。

  • LCSDetectionInputStream: ストリーム・オブジェクトの言語およびエンコーディングを透過的に検出します。

  • LCSDetectionReader: 入力データの言語およびエンコーディングを透過的に検出し、Unicodeに変換します。

  • LCSDetectionHTMLInputStream: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionInputStreamクラスを拡張します。

  • LCSDetectionHTMLReader: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionReaderクラスを拡張します。

8.9.1.1 LCSScan

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

関連項目:

「Language and Character Set File Scanner」

8.9.1.1.1 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
8.9.1.1.2 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つ戻されます。

8.9.2 oracle.i18n.net

oracle.i18n.netパッケージは、グローバリゼーションのためのインターネット関連のデータ変換を提供します。このパッケージには次のクラスがあります。

  • CharEntityReference: 文字列を文字参照形式または実体参照形式との間でエスケープまたはアンエスケープするためのユーティリティ・クラスです。

  • CharEntityReference.Form: エスケープ形式を指定するフォーム・パラメータ・クラスです。

8.9.3 oracle.i18n.servlet

oracle.i18n.Servletパッケージは、JSPおよびJavaサーブレットで自動ロケールのサポートを可能にし、ローカライズされたコンテンツをアプリケーションに返します。このパッケージには次のクラスがあります。

  • ApplicationContext: フレームワークでアプリケーション・スコープ操作を実行します。

  • Localizer: 最も一般に使用されるグローバリゼーション情報へのアクセスを提供します。

  • ServletHelper: Java Servletとグローバリゼーション・オブジェクト間を結びます。

8.9.4 oracle.i18n.text

oracle.i18n.textパッケージは、汎用的なテキスト・データ・グローバリゼーション・サポートを提供します。このパッケージには次のクラスがあります。

  • OraCollationKey: 特定のOraCollatorオブジェクトの特定の規則に基づくStringを表します。

  • OraCollator: 言語照合やバイナリ・ソートなど、ロケール依存の文字列比較を実行します。

  • OraDateFormat: 日時と文字列のロケール間で書式指定と解析を実行します。Oracleの日時の書式設定の動作をサポートします。

  • OraDecimalFormat: 数値と文字列のロケール間で書式指定と解析を実行します。Oracleの数値の書式設定の動作をサポートします。

  • OraDecimalFormatSymbol: Oracleの数値書式と通貨書式に使用されるOracleの書式記号を含みます。

  • OraNumberFormat: 数値と文字列のロケール間で書式指定と解析を実行します。Oracleの数値の書式設定の動作をサポートします。

  • OraSimpleDateFormat: 日時と文字列のロケール間で書式指定と解析を実行します。Oracleの日時の書式設定の動作をサポートします。

8.9.5 oracle.i18n.util

oracle.i18n.utilパッケージは、グローバリゼーション・サポート用の汎用ユーティリティを提供します。このパッケージには次のクラスがあります。

  • LocaleMapper: Oracleのロケール要素と他のベンダーおよび規格の等価ロケール要素の間のマッピングを提供します。

  • OraDisplayLocaleInfo: ロケールと属性の翻訳を提供します。

  • OraLocaleInfo: 言語、地域およびCollatorオブジェクトを含みます。

  • OraSQLUtil: SQLを処理する便利なメソッドを提供します。

8.10 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文字セットの文字の最大バイト数を戻すファンクション

  • VARCHAR2、NVARCHAR2、CLOBおよびNCLOBデータの文字エンコーディングを検証するファンクション

UTL_LMSは、様々な言語でエラー・メッセージを取り出して書式指定します。

関連項目:

『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のUTL_I18NおよびUTL_LMSに関する項を参照してください

8.11 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メソッドをコールしてください。