| Oracle® Databaseグローバリゼーション・サポート・ガイド 11gリリース2 (11.2) B56307-04 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
国際化されたアプリケーションの設計および開発は、最も経験豊富な開発者にとってさえ困難な作業になる場合があります。これは通常、知識不足やグローバリゼーションの概念と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は、これらのロケール判別方法を宣言的に使用できるアプリケーション・フレームワークを提供します。
ロケール対応またはロケール依存にするには、インターネット・アプリケーションでユーザーのロケールを判別する必要があります。ユーザー・ロケールの判別後に、アプリケーションで次の操作を実行する必要があります。
ロケールの言語による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番目に適切なコンテンツが表示されます。たとえば、カナダ系フランス語のコンテンツが使用できない場合は、かわりにアプリケーションをフランス語ファイルに切り替えることが適切である可能性があります。
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パッケージが用意されています。
Java用GDKが提供する機能は、次の2つのカテゴリにわかれています。
J2EE用GDKアプリケーション・フレームワークは、J2EEベースのインターネット・アプリケーションを構築するためのグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。このフレームワークは、フレームワークへのアクセスをアプリケーションに提供する一連のJavaクラスで構成されます。これらの関連Javaクラスを使用すると、グローバリゼーション動作を宣言的に拡張できるようにアプリケーションをフレームワークに対してコード化できます。
GDKのJava APIは、Javaアプリケーションでの開発サポートを提供し、Oracle Databaseサーバーで提供される一貫したグローバリゼーション操作を提供します。APIはアクセス可能であり、GDKフレームワークから独立しているため、スタンドアロンのJavaアプリケーションとGDKフレームワークに基づかないJ2EEアプリケーションは、Java APIの機能に個別にアクセスできます。Java APIが提供する機能には、Oracle Databaseと同じ方法によるキャラクタ・セットのデータと数値の書式設定、ソートおよび処理が含まれます。
|
注意: GDK Java APIは、バージョン1.4以上のJDKでサポートされています。 |
Java用GDKは、9つの.jarファイルに含まれています。すべてのファイルがorai18n*jarの形式です。これらのファイルはOracle Databaseに付属しており、$ORACLE_HOME/jlibディレクトリにあります。GDKを使用するアプリケーションがデータベースと同じマシンで管理されていない場合、そのアプリケーションを実行するには、GDKファイルをアプリケーション・サーバーにコピーしてCLASSPATHに組み込む必要があります。Javaアプリケーション内では、Oracle Databaseをアプリケーション・サーバーにインストールしなくてもGDKを実行できます。GDKは、あらゆるプラットフォーム上で動作するPure Javaライブラリです。Oracleクライアント・パラメータのNLS_LANGとORACLE_HOMEは必要ありません。
この項では、GDKを使用して、単一言語アプリケーションをグローバルな多言語アプリケーションに変更する方法を説明します。この章の以降の各項では、GDKの使用方法に関する詳細を説明します。
図8-4に、単一言語Webアプリケーションのスクリーンショットを示します。
GDKを使用していない初期のHelloWorld Webアプリケーションは、「HelloWorld」メッセージが出力され、ページの右上に現在の日時が表示されているだけです。例8-1「HelloWorld JSPページ・コード」は、前のイメージに対する元のHelloWorld JSPソース・コードを示しています。
例8-1 HelloWorld JSPページ・コード
<%@ page contentType="text/html;charset=windows-1252"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Hello World Demo</title>
</head>
<body>
<div style="color: blue;" align="right">
<%= new java.util.Date(System.currentTimeMillis()) %>
</div>
<hr/>
<h1>Hello World!</h1>
</body>
</html>
例8-2 「HelloWorld web.xmlコード」は、HelloWorldメッセージに対応するWebアプリケーション・ディスクリプタ・ファイルを示しています。
例8-2 HelloWorld web.xmlコード
<?xml version = '1.0' encoding = 'windows-1252'?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<description>web.xml file for the monolingual Hello World</description>
<session-config>
<session-timeout>35</session-timeout>
</session-config>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>
例8-1のHelloWorld JSPコードは、英語圏のユーザーのみを対象としています。このコードに関する問題の一部を次に示します。
ユーザー設定項目またはブラウザ設定に基づくロケールの判別が行われません。
タイトルおよびヘッダーがコードに含まれています。
ロケール設定項目に基づいて日時の値がローカライズされません。
コードに含まれる文字エンコーディングはLatin-1に対応しています。
GDKフレームワークをHelloWorldコードに統合し、グローバルな多言語アプリケーションにすることができます。前述のコードを変更して次の機能を含めることができます。
ユーザーのブラウザ・ロケールを検出し、クライアントにローカライズされたHTMLページを提供する、自動ロケール・ネゴシエーション。サポートされるアプリケーション・ロケールは、GDK構成ファイルで構成されています。
サポートされるアプリケーション・ロケールをマップするロケール選択リスト。このリストには、ロケールを表す国名であるアプリケーション・ロケール表示名を含めることができます。このリストはWebページに含まれるため、ユーザーは別のロケールを選択できます。
HelloWorld JSPのグローバリゼーション・サポート用のGDKフレームワークおよびAPI。この機能には、ロケールに依存した方法での表示文字列の選択および日時の値の書式設定が含まれます。
この項では、HelloWorldアプリケーションを変更してグローバリゼーションをサポートする方法を説明します。このアプリケーションは、簡体字中国語(zh-CN)、スイス系ドイツ語(de-CH)およびアメリカ英語(en-US)という3つのロケールをサポートするよう変更されます。言語に対して次のルールが使用されます。
クライアント・ロケールでこれらの言語のいずれかがサポートされている場合、その言語がアプリケーションに使用されます。
クライアント・ロケールでこれらの言語のいずれかがサポートされていない場合、アメリカ英語がアプリケーションに使用されます。
さらに、ユーザーはロケール選択リストからサポートされるロケールを選択することで、言語を変更できます。次の各タスクは、アプリケーションの変更方法を説明しています。
タスク1: Hello WorldアプリケーションでのGDKフレームワーク使用の有効化
このタスクでは、Webアプリケーション・デプロイメント・ディスクリプタ・ファイル(web.xml)でGDKフィルタおよびリスナーが構成されます。これによって、GDKフレームワークをHelloWorldアプリケーションに使用できるようになります。例8-3に、GDK対応のweb.xmlファイルを示します。
例8-3 GDK対応のweb.xmlファイル
<?xml version = '1.0' encoding = 'windows-1252'?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <description>web.xml file for Hello World</description> <!-- Enable the application to use the GDK Application Framework.--> <filter> <filter-name>GDKFilter</filter-name> <filter-class>oracle.i18n.servlet.filter.ServletFilter</filter-class> </filter> <filter-mapping> <filter-name>GDKFilter</filter-name> <url-pattern>*.jsp</url-pattern> </filter-mapping> <listener> <listener-class>oracle.i18n.servlet.listener.ContextListener</listener-class> </listener> <session-config> <session-timeout>35</session-timeout> </session-config> <mime-mapping> <extension>html</extension> <mime-type>text/html</mime-type> </mime-mapping> <mime-mapping> <extension>txt</extension> <mime-type>text/plain</mime-type> </mime-mapping> </web-app>
次のタグがファイルに追加されています。
<filter>
フィルタ名はGDKFilterであり、フィルタ・クラスはoracle.i18n.servlet.filter.ServletFilterです。
<filter-mapping>
GDKFilterがURLパターンとともにタグ内に指定されています。
<listener>
リスナー・クラスはoracle.i18n.servlet.listener.ContextListenerです。デフォルトのGDKリスナーは、フレームワークのアプリケーション・スコープ操作を制御するGDK ApplicationContextをインスタンス化するよう構成されています。
タスク2: Hello World用のGDKフレームワークの構成
GDKアプリケーション・フレームワークは、アプリケーション構成ファイルgdkapp.xmlで構成されています。この構成ファイルは、web.xmlファイルと同じディレクトリに置かれています。例8-4に、gdkapp.xmlファイルを示します。
例8-4 GDK構成ファイルgdkapp.xml
<?xml version="1.0" encoding="UTF-8"?>
<gdkapp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="gdkapp.xsd">
<!-- The Hello World GDK Configuration -->
<page-charset default="yes">UTF-8</page-charset>
<!-- The supported application locales for the Hello World Application -->
<application-locales>
<locale>de-CH</locale>
<locale default="yes">en-US</locale>
<locale>zh-CN</locale>
</application-locales>
<locale-determine-rule>
<locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source>
<locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage</locale-source>
</locale-determine-rule>
<message-bundles>
<resource-bundle name="default">com.oracle.demo.Messages</resource-bundle>
</message-bundles>
</gdkapp>
このファイルは、J2EEアプリケーション用に構成する必要があります。このファイルでは次のタグが使用されています。
<page-charset>
ページのエンコーディング・タグにより、HTTPリクエストおよびレスポンスに使用されるキャラクタ・セットが指定されます。UTF-8エンコーディングにより多くの言語を表現できるため、このエンコーディングがデフォルトで使用されます。
<application-locales>
gdkapp.xmlファイルでアプリケーション・ロケールを構成すると、ロケールを定義するための中心的な場所が作成されます。これによって、ソース・コードを変更せずにロケールを簡単に追加および削除できるようになります。ロケール・リストは、GDK APIコールApplicationContext.getSupportedLocalesを使用して取得できます。
<locale-determine-rule>
初期ページの言語は、ブラウザの言語設定により決定されます。ユーザーは、リストから言語を選択してこの言語を上書きできます。Accept-Language HTTPヘッダーをロケールのソースとして最初に使用するために、locale-determine-ruleがGDKにより使用されます。ユーザーがリストからロケールを選択した場合、JSPにより、選択したロケールが含まれるロケール・パラメータ値がポストされます。続いて、GDKにより、コンテンツを含むレスポンスが選択した言語で送信されます。
<message-bundles>
メッセージ・リソース・バンドルにより、Webページに表示されるローカライズされた静的コンテンツへのアプリケーション・アクセスが可能になります。GDKフレームワークの構成ファイルにより、アプリケーションで、様々な言語の翻訳済テキストに対するデフォルトのリソース・バンドルを定義できます。HelloWorldの例では、ローカライズされた文字列メッセージが、MessagesというJavaのListResourceBundleバンドルに格納されます。Messagesバンドルは、デフォルト・ロケールにおけるアプリケーションのベース・リソースで構成されます。他の2つのリソース・バンドルは、中国語およびドイツ語翻訳を提供します。これらのリソース・バンドルは、それぞれMessages_zh_CN.javaおよびMessages_de.javaと呼ばれます。HelloWorldアプリケーションでは、GDKフレームワークにより決定されたロケールに基づき、リソース・バンドルから「Hello World!」に適した翻訳が選択されます。<message-bundles>タグは、アプリケーションで使用されるリソース・バンドルを構成するために使用されます。
タスク3: JSPまたはJavaサーブレットの有効化
GDK APIを使用するには、JSPおよびJavaサーブレットを有効化する必要があります。例8-5に、GDK APIおよびサービスを使用できるよう変更されたJSPを示します。このJSPは、任意の言語およびロケールに対応できます。
例8-5 有効化されたHelloWorld JSP
. . .
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title><%= localizer.getMessage("helloWorldTitle") %></title>
</head>
<body>
<div style="color: blue;" align="right">
<% Date currDate= new Date(System.currentTimeMillis()); %>
<%=localizer.formatDateTime(currDate, OraDateFormat.LONG)%>
</div>
<hr/>
<div align="left">
<form>
<select name="locale" size="1">
<%= getCountryDropDown(request)%>
</select>
<input type="submit" value="<%= localizer.getMessage("changeLocale") %>">
</input>
</form>
</div>
<h1><%= localizer.getMessage("helloWorld") %></h1>
</body>
</html>
図8-5に、ブラウザ設定項目の主要ロケールであるzh-CNロケールにより構成されたHelloWorldアプリケーションを示します。HelloWorldの文字列およびページ・タイトルは、簡体字中国語で表示されています。さらに、日付はロケール表記規則zh-CNで書式設定されています。この例では、ユーザーはロケール選択リストからロケールを上書きできます。
ロケールが変更された場合、またはHTTPリクエストのAccept-Languageヘッダーまたはロケール選択リストを使用して初期化された場合、GUIの動作はそのロケールに適したものとなります。つまり、右上の日時の値は正しくローカライズされます。さらに、「HelloWorld」ページに文字列がローカライズされて表示されます。
GDK Java Localizerクラスは、GDKフレームワークによるロケールの自動検出に基づいてWebページのコンテンツをローカライズする機能を提供します。
次のコードでは、現在のHTTPServletRequestオブジェクトに基づくローカライザのインスタンスが取得されます。さらに、JSPページ内でGDK APIを使用するための複数のインポートが宣言されます。ローカライザにより、代替動作を含むロケールに依存した方法でローカライズされた文字列が取得され、日時が書式設定されます。
<%@page contentType="text/html;charset=UTF-8"%>
<%@page import="java.util.*, oracle.i18n.servlet.*" %>
<%@page import="oracle.i18n.util.*, oracle.i18n.text.*" %>
<%
Localizer localizer = ServletHelper.getLocalizerInstance(request);
%>
次のコードでは、currDate変数に格納された現在日時値が取得されます。この値は、ローカライザのformatDateTimeメソッドにより書式設定されます。formatDateTimeメソッドのOraDateFormat.LONGパラメータは、ローカライザに対し、ロケールの長い書式設定スタイルを使用して日付を書式設定するよう指示します。受信リクエストのロケールがロケール選択リストにより別のロケールに変更された場合、日時の値は、新規ロケールの表記規則に従って書式設定されます。新しく導入されたロケールをサポートするためにコード変更を加える必要はありません。
div style="color: blue;" align="right">
<% Date currDate= new Date(System.currentTimeMillis()); %>
<%=localizer.formatDateTime(currDate, OraDateFormat.LONG)%>
</div>
HelloWorldの文字列およびタイトルはロケール依存の方法で選択されるため、HelloWorld JSPを任意のロケールに再利用できます。翻訳済文字列はリソース・バンドルから選択されます。
GDKでは、リソース・バンドルの代替動作の実装にOraResourceBundleクラスが使用されます。次のコードは、ローカライザがリソース・バンドルからHelloWorldメッセージを選択する方法を示しています。
デフォルトのアプリケーション・リソース・バンドルであるMessagesは、gdkapp.xmlファイルで宣言されます。ローカライザは、メッセージ・リソース・バンドルを使用してメッセージを選択し、ロケール固有のロジックを適用します。たとえば、受信リクエストの現在のロケールが「de-CH」である場合、メッセージはまずmessages_de_CHバンドル内で検索されます。メッセージが存在しない場合、Messages_deリソース・バンドル内で検索されます。
<h1><%= localizer.getMessage("helloWorld") %></h1>
タスク4: ロケール選択リストの作成
ロケール選択リストは、HTTPリクエストのAccept-Languageヘッダーに基づいて選択されたロケールを上書きするために使用されます。GDKフレームワークにより、HTTP POSTリクエストの一部として渡された、新規ロケールの値を示すロケール・パラメータがチェックされます。ロケール選択リストで選択されたロケールは、ロケール・パラメータ値としてポストされます。GDKでは、リクエスト・ロケールにこの値が使用されます。この処理はすべて、GDKコード内で暗黙的に実行されます。
次のサンプル・コードは、ロケール選択リストをHTML selectタグの形式で同じロケールにより表示します。submitタグにより、新しい値がサーバーにポストされます。GDKフレームワークにより適切な選択結果が取得されます。
<form>
<select name="locale" size="1">
<%= getCountryDropDown(request)%>
</select>
<input type="submit" value="<%= localizer.getMessage("changeLocale") %>">
</input>
</form>
ロケール選択リストは、getCountryDropDownメソッドにより生成されるHTMLコードから構成されます。このメソッドにより、構成済のアプリケーション・ロケールがローカライズされた国名に変換されます。
現在のリクエストに関連付けられたApplicationContextオブジェクトを取得するため、ServletHelperクラスがコールされます。このオブジェクトは、アプリケーションに対し、サポートされるロケールおよび構成情報などの情報が含まれるグローバリゼーション・コンテキストを提供します。getSupportedLocalesコールにより、gdkapp.xmlファイル内のロケール・リストが取得されます。構成済アプリケーション・ロケール・リストは、HTML selectのオプションとして表示されます。OraDisplayLocaleInfoクラスは、国名および言語名などのロケール固有要素のローカライゼーション・メソッドを提供します。
このクラスのインスタンスは、GDKフレームワークにより自動的に決定された現在のロケールを渡すことによって作成されます。GDKにより、HTTPリクエストおよびレスポンス用のリクエスト・ラッパーおよびレスポンス・ラッパーが作成されます。request.getLocale()メソッドは、ロケール判別ルールに基づいて、GDKにより決定されたロケールを戻します。
OraDsiplayLocaleInfo.getDisplayCountryメソッドにより、アプリケーション・ロケールのローカライズされた国名が取得されます。ddOptBuffer文字列バッファに、HTMLオプション・リストが作成されます。getCountryDropDownコールは、次のHTML値が含まれる文字列を戻します。
<option value="en_US" selected>United States [en_US]</option> <option value="zh_CN">China [zh_CN]</option> <option value="de_CH">Switzerland [de_CH]</option>
前述の値では、ロケールに対してen-USロケールが選択されています。国名は、現在のロケールに基づいて生成されています。
例8-6に、ロケール選択リストを構成するコードを示します。
例8-6 ロケール選択リストの構成
<%!
public String getCountryDropDown(HttpServletRequest request)
{
StringBuffer ddOptBuffer=new StringBuffer();
ApplicationContext ctx = ServletHelper.getApplicationContextInstance(request);
Locale[] appLocales = ctx.getSupportedLocales();
Locale currentLocale = request.getLocale();
if (currentLocale.getCountry().equals(""))
{
// Since the Country was not specified get the Default Locale
// (with Country) from the GDK
OraLocaleInfo oli = OraLocaleInfo.getInstance(currentLocale);
currentLocale = oli.getLocale();
}
OraDisplayLocaleInfo odli = OraDisplayLocaleInfo.getInstance(currentLocale);
for (int i=0;i<appLocales.length; i++)
{
ddOptBuffer.append("<option value=\"" + appLocales[i] + "\"" +
(appLocales[i].getLanguage().equals(currentLocale.getLanguage()) ? " selected" : "") +
">" + odli.getDisplayCountry(appLocales[i]) +
" [" + appLocales[i] + "]</option>\n");
}
return ddOptBuffer.toString();
}
%>
タスク5: アプリケーションの作成
アプリケーションを作成するには、クラスパスに次の各ファイルを指定する必要があります。
orai18n.jar
regexp.jar
orai18n.jarファイルには、GDKフレームワークおよびAPIが含まれます。regexp.jarファイルには、正規表現ライブラリが含まれます。GDK APIには、ロケール判別機能も含まれます。ora18n-lcsd.jarファイルによりクラスが指定されます。
Java用GDKは、中間層のJ2EEアプリケーション用のグローバリゼーション・フレームワークを提供します。このフレームワークにより、ユーザー・ロケールの判別、ロケールの永続性の維持およびロケール情報の処理など、グローバリゼーション・プログラミングの複雑さがカプセル化されます。また、インターネット・アプリケーションをグローバル対応にするために必要な労力が最小限に抑えられます。図8-6に、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アプリケーション構成ファイルgdkapp.xmlにより制御されます。アプリケーション構成ファイルを使用することで、開発者はグローバル・アプリケーションの動作を1箇所で指定できます。GDKを使用するJ2EEアプリケーションごとに、1つのアプリケーション構成ファイルが必要です。gdkapp.xmlファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリに置く必要があります。このファイルでは、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フレームワークとともに他のフィルタを使用する場合は、競合の可能性に注意してください。
ユーザーの優先ロケールの決定は、アプリケーションをグローバル対応にする作業の最初のステップです。J2EEアプリケーション・フレームワークのロケール検出機能はプリミティブなものです。ロケール・ソースの中から最適なユーザー・ロケールを透過的に取得する方法が備わっていません。HTTP言語プリファレンスによるロケール検出のみが可能で、マルチレベルのロケール代替メカニズムはサポートされません。GDKアプリケーション・フレームワークは、事前定義されたロケール・ソースをサポートすることで、J2EEを補完します。Webアプリケーションでは、複数のロケール・ソースを使用できます。表8-1に、GDKが提供するロケール・ソースを示します。
表8-1 GDK提供のロケール・リソース
| ロケール | 説明 |
|---|---|
|
HTTP言語作業環境 |
HTTPプロトコルに |
|
ユーザー入力ロケール |
ユーザーがメニューまたはHTTPプロトコルのパラメータで指定するロケール。 |
|
データベースからのユーザー・プロファイルのロケール設定項目 |
ユーザー・プロファイルの一部としてデータベースに格納されているロケール設定項目。 |
|
アプリケーションのデフォルト・ロケール |
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では、自動的なロケール検出の機能によって、ユーザーの現行ロケールが決定されます。たとえば、次のコードでは、現行のユーザー・ロケールが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オブジェクトは、オールインワンのグローバリゼーション・オブジェクトであり、アプリケーションでロケール対応機能を構築するときに一般に使用される機能へのアクセスを提供します。また、サポートされているロケールのリストなど、アプリケーション・コンテキストに関する情報を取得するための機能も提供します。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』を参照してください。 |
アプリケーションでサポートする必要のあるロケールの数と名前は、アプリケーションのビジネス要件に基づきます。アプリケーションでサポートされるロケールの名前は、アプリケーション構成ファイルに登録されます。次の例に、アプリケーション構成ファイルの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つであるかどうかが検証されます。検証アルゴリズムは次のとおりです。
アプリケーション構成ファイルからサポート対象アプリケーション・ロケールのリストを取り出します。
検出されたロケールがリストに含まれているかどうかを調べます。リストに含まれている場合は、このロケールを現行のクライアントのロケールとして使用します。
検出されたロケールにバリアントがある場合は、そのバリアントを削除して、削除後のロケールがリストに含まれているかどうかを調べます。たとえば、Javaロケールde_DE_EUROにはEUROバリアントがあります。削除後のロケールがde_DEとなるようにバリアントを削除します。
ロケールに国コードが含まれている場合は、国コードを削除し、削除後のロケールがリストに含まれているかどうかを調べます。たとえば、Javaロケールde_DEには国コードDEがあります。削除後のロケールがdeとなるように国コードを削除します。
検出されたロケールがリストにあるどのロケールとも一致しない場合は、アプリケーション構成ファイルに定義されているデフォルト・ロケールをクライアントのロケールとして使用します。
手順3および4を実行することで、アプリケーションでは、言語要件は同じでもアプリケーション構成ファイルでの定義とは異なるロケール設定を使用するユーザーをサポートできます。たとえば、GDKでは、de-AT(ドイツ語のオーストリア系バリアント)、de-CH(ドイツ語のスイス系バリアント)およびde-LU(ドイツ語のルクセンブルグ系バリアント)をサポートできます。
GDKフレームワークの代替ロケール検出機能は、Java Resource Bundleの機能に似ていますが、Java VMのデフォルト・ロケールの影響を受けません。この例外が発生するのは、GDKロケール代替操作では、アプリケーションのデフォルト・ロケールを使用できるためです。
アプリケーション構成ファイルからapplication-localesセクションを省略すると、GDKはアプリケーションで共通ロケールがサポートされるものと想定します。この共通ロケールは、OraLocaleInfo.getCommonLocalesメソッドから戻されることがあります。
HTMLページのキャラクタ・セット(または文字コード体系)は、ブラウザやインターネット・アプリケーションにとって重要な情報です。ブラウザは、正しいフォントとキャラクタ・セットのマッピング表をページ表示に使用できるように、この情報を解析する必要があります。インターネット・アプリケーションは、HTMLフォームからの入力データを指定のエンコーディングに基づいて安全に処理できるように、この情報を知る必要があります。
ページ・エンコーディングは、インターネット・アプリケーションで提供されるロケール用のキャラクタ・セットとして変換できます。
インターネット・アプリケーションで、GDKフレームワークを使用せずにHTMLページ用のページ・エンコーディングを正しく指定するには、次の操作を実行する必要があります。
指定のロケールについて、必要なページ入力データのキャラクタ・セット・エンコーディングを判別します。
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に変更されることを示しています。
この項の内容は、次のとおりです。
リソース・バンドルを使用すると、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(スペインのスペイン語)ファイルが使用可能であれば、各メソッドはかわりにスペイン語の翻訳済ファイルを選択します。
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の主な機能は、次のとおりです。
言語、地域、言語ソートおよびキャラクタ・セットなど、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のJava APIはLocaleMapperクラスを提供します。Java、IANA、ISO、Oracle間で、等価のロケールおよびキャラクタ・セットがマッピングされます。Javaアプリケーションは、Oracleデータベースのロケール名またはIANAキャラクタ・セット名で指定されたクライアントから、ロケール情報を受信できます。Javaアプリケーションでこの情報を正しく処理するには、同等のJavaロケールやJavaエンコーディングにマッピングできる必要があります。
LocaleMapperクラスの使用例を次に示します。
// Mapping from Java locale to Oracle language and Oracle territory
Locale locale = new Locale("it", "IT");
String oraLang = LocaleMapper.getOraLanguage(locale);
String oraTerr = LocaleMapper.getOraTerritory(locale);
// From Oracle language and Oracle territory to Java Locale
locale = LocaleMapper.getJavaLocale("AMERICAN","AMERICA");
locale = LocaleMapper.getJavaLocale("TRADITONAL CHINESE", "");
// From IANA & Java to Oracle Character set
String ocs1 = LocaleMapper.getOraCharacterSet(
LocaleMapper.IANA, "ISO-8859-1");
String ocs2 = LocaleMapper.getOraCharacterSet(
LocaleMapper.JAVA, "ISO8859_1");
LocaleMapperクラスは、WindowsおよびUNIXプラットフォームの両方で特定のロケールに最も一般的に使用されている、電子メール・キャラクタ・セットを戻すこともできます。これは、電子メール・メッセージを処理する必要のあるJavaアプリケーションの開発時に役立ちます。
GDKのJava APIには、ユーザーがOracleキャラクタ・セット変換を実行できるように、一連のキャラクタ・セット変換クラスAPIが含まれています。Java JDKには多数の標準キャラクタ・セットの変換を実行できるクラスがすでに付属していますが、Oracle固有のキャラクタ・セットとOracleのユーザー定義キャラクタ・セットはサポートしていません。
JDK 1.4では、J2SEに開発者がJavaキャラクタ・セットの拡張に使用するインタフェースが導入されています。GDKのJava APIは、このプラグイン機能を使用してOracleのキャラクタ・セットに対する暗黙的なサポートを提供します。J2SE APIにアクセスして、Oracle固有の動作を取得できます。
図8-7に、GDKキャラクタ・セット変換表がJavaキャラクタ・セット表と同じ方法でJ2SEにプラグインされる状況を示します。このJ2SEの交換可能フレームワークにより、Oracleキャラクタ・セット変換を他のJavaキャラクタ・セット変換と同じ方法で使用できます。
バージョン1.4より前のJDKではjava.nio.charset Javaパッケージを使用できないため、Oracleのキャラクタ・セット・プラグイン機能を使用するにはJDK 1.4以上をインストールする必要があります。
GDKキャラクタ変換クラスは、ユーザー定義のキャラクタ・セットを含むすべてのOracleキャラクタ・セットをサポートします。Javaアプリケーションでは、このクラスを使用して、Javaの内部キャラクタ・セットであるUTF-16との間で正しく変換できます。
Oracleのキャラクタ・セット名はオラクル社独自の名前です。Java独自のキャラクタ・セットとの競合の可能性を回避するために、すべてのOracleキャラクタ・セット名には、JavaのAPIを介してすべてを暗黙的に使用するためのX-ORACLE-接頭辞が付いています。
Oracleキャラクタ・セット変換の使用例を次に示します。
// Converts the Chinese character "three" from UCS2 to JA16SJIS
String str = "\u4e09";
byte[] barr = str.getBytes("x-oracle-JA16SJIS");
他のJavaキャラクタ・セットと同様に、java.nio.charset.Charsetのキャラクタ・セット機能はすべてのOracleキャラクタ・セットに適用されます。たとえば、指定したキャラクタ・セットが他のキャラクタ・セットのスーパーセットかどうかを調べる場合は、次のようにCharset.containsメソッドを使用できます。
Charset cs1 = Charset.forName("x-oracle-US7ASCII");
Charset cs2 = Charset.forName("x-oracle-WE8WINDOWS1252");
// true if WE8WINDOWS1252 is the superset of US7ASCII, otherwise false.
boolean osc = cs2.contains(cs1);
JDBCドライバを使用してデータベースと通信するJavaアプリケーションの場合は、JDBCドライバがアプリケーションとデータベース間で必要なキャラクタ・セット変換を提供します。アプリケーション内でGDKキャラクタ・セット変換メソッドを明示的にコールする必要はありません。Oracleのキャラクタ・セット・エンコーディング形式に基づいてテキスト・ファイルを解析および生成するJavaアプリケーションは、Oracleキャラクタ・セット変換クラスの使用例の1つです。
GDKの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));
Oracleでは、データベースでのバイナリ・ソート、単一言語ソートおよび多言語ソートがサポートされています。Oracleデータベースでは、これらのソートが拡張されており、データベース内で大/小文字を区別しないソートおよび検索機能とアクセントを区別しないソートおよび検索機能が提供されます。GDKのJava APIのOraCollatorクラスを使用すると、Javaアプリケーションでは、大/小文字区別なしのオプションやアクセント区別なしのオプションなど、最新のOracleのバイナリ・ソート機能と言語ソート機能に基づいて情報をソートしたり検索できます。
正規化がソートの重要部分になることがあります。文字の複合と分解はUnicode規格に基づくため、ソートもUnicode規格に依存します。GDKには、複合を実行するメソッドがあります。
|
注意: JDKのバージョンごとにサポートするUnicode規格のバージョンが異なる可能性があるので、GDKではUnicode規格の最新バージョン(現時点ではUnicode 5.0)に基づくOraNormalizerクラスを提供しています。 |
バイナリ・ソートのソート順は、使用中のOracleキャラクタ・セットに基づきます。GDKのJava APIでは、UTFEキャラクタ・セットを除き、すべてのOracleキャラクタ・セットのバイナリ・ソートがサポートされます。GDKのJava APIでサポートされない言語ソートはJAPANESEのみですが、JAPANESE_Mを使用すると、同様でより正確なソート結果を得ることができます。
文字列比較と文字列ソートの例を次に示します。
8-7 文字列の比較および文字列の格納
// compares strings using XGERMAN
private static String s1 = "abcSS";
private static String s2 = "abc\u00DF";
String cname = "XGERMAN";
OraCollator ocol = OraCollator.getInstance(cname);
int c = ocol.compare(s1, s2);
// sorts strings using GENERIC_M
private static String[] source =
new String[]
{
"Hochgeschwindigkeitsdrucker",
"Bildschirmfu\u00DF",
"Skjermhengsel",
"DIMM de Mem\u00F3ria",
"M\u00F3dulo SDRAM com ECC",
};
cname = "GENERIC_M";
ocol = OraCollator.getInstance(cname);
List result = getCollationKeys(source, ocol);
private static List getCollationKeys(String[] source, OraCollator ocol)
{
List karr = new ArrayList(source.length);
for (int i = 0; i < source.length; ++i)
{
karr.add(ocol.getCollationKey(source[i]));
}
Collections.sort(karr); // sorting operation
return karr;
}
GDKの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) );
}
Oracleの言語名、地域名、キャラクタ・セット名、言語ソート名およびタイム・ゾーン名はすべて、英語を含む27の言語に翻訳されています。これらはそのままユーザー・アプリケーションに組み込むことができ、異なる言語を使用するユーザー・アプリケーション間で表示名に一貫性をもたらします。OraDisplayLocaleInfoは、ロケールと属性の翻訳を提供するユーティリティ・クラスです。翻訳済の名前は、ユーザー・インタフェースのテキストやドロップダウン選択ボックスに表示する場合に役立ちます。たとえば、ネイティブのフランス語ユーザーは、英語よりもフランス語で表示されたタイム・ゾーン・リストから選択するほうを好みます。
次の例に、OraDisplayLocaleInfoを使用して、カナダでサポートされているタイム・ゾーン・リストをフランス語の翻訳名を使用して戻す方法を示します。
例8-8 OraDisplayLocaleInfoの使用によるタイム・ゾーンの固有リストの取得
OraLocaleInfo oloc = OraLocaleInfo.getInstance("CANADIAN FRENCH", "CANADA");
OraDisplayLocaleInfo odloc = OraDisplayLocaleInfo.getInstance(oloc);
TimeZone[] loctzs = oloc.getLocaleTimeZones();
String [] disptz = new string [loctzs.length];
for (int i=0; i<loctzs.length; ++i)
{
disptz [i]= odloc.getDisplayTimeZone(loctzs[i]);
...
}
GDKのLocaleMapperクラスを使用すると、最も一般的に使用されている電子メール・キャラクタ・セットを取り出すことができます。LocaleMapper.getIANACharSetFromLocaleをロケール・オブジェクト内で渡してコールします。戻り値は、キャラクタ・セット名の配列です。最初に戻されるキャラクタ・セットが、最も一般的に使用されている電子メール・キャラクタ・セットです。
次に、GBKキャラクタ・セット・エンコーディングで簡体字中国語のデータを含む電子メール・メッセージを送信する例を示します。
例8-9 GBKキャラクタ・セット・コードの簡体字中国語で書かれた電子メールの送信
import oracle.i18n.util.LocaleMapper;
import java.util.Date;
import java.util.Locale;
import java.util.Properties;
import javax.mail.Message;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeUtility;
/**
* Email send operation sample
*
* javac -classpath orai18n.jar:j2ee.jar EmailSampleText.java
* java -classpath .:orai18n.jar:j2ee.jar EmailSampleText
*/
public class EmailSampleText
{
public static void main(String[] args)
{
send("localhost", // smtp host name
"your.address@your-company.com", // from email address
"You", // from display email
"somebody@some-company.com", // to email address
"Subject test zh CN", // subject
"Content ˘4E02 from Text email", // body
new Locale("zh", "CN") // user locale
);
}
public static void send(String smtp, String fromEmail, String fromDispName,
String toEmail, String subject, String content, Locale locale
)
{
// get the list of common email character sets
final String[] charset = LocaleMapper.getIANACharSetFromLocale(LocaleMapper.
EMAIL_WINDOWS,
locale
);
// pick the first one for the email encoding
final String contentType = "text/plain; charset=" + charset[0];
try
{
Properties props = System.getProperties();
props.put("mail.smtp.host", smtp);
// here, set username / password if necessary
Session session = Session.getDefaultInstance(props, null);
MimeMessage mimeMessage = new MimeMessage(session);
mimeMessage.setFrom(new InternetAddress(fromEmail, fromDispName,
charset[0]
)
);
mimeMessage.setRecipients(Message.RecipientType.TO, toEmail);
mimeMessage.setSubject(MimeUtility.encodeText(subject, charset[0], "Q"));
// body
mimeMessage.setContent(content, contentType);
mimeMessage.setHeader("Content-Type", contentType);
mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
mimeMessage.setSentDate(new Date());
Transport.send(mimeMessage);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
GDKアプリケーション構成ファイルでは、GDKアプリケーション・フレームワークの動作およびプロパティと、それを使用するアプリケーションを指定します。このファイルには、アプリケーション構成に関するロケール・マッピング表およびパラメータが含まれます。アプリケーションごとに1つの構成ファイルが必要です。
gdkapp.xmlアプリケーション構成ファイルはXML文書です。このファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリにあります。
次の項では、アプリケーション構成ファイルの内容とプロパティの詳細を説明します。
このセクションを使用すると、アプリケーションで言語から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に設定されることを示しています。
カンマ区切りのリストを使用して、複数のロケールを指定できます。
このセクションでは、アプリケーション・ページのキャラクタ・セットを定義します。このセクションが特定のキャラクタ・セットに明示的に設定されている場合は、すべてのページでこのキャラクタ・セットが使用されます。キャラクタ・セット名は、IANAキャラクタ・セットの表記規則に従う必要があります。
<page-charset>UTF-8</page-charset>
ただし、page-charsetがAUTO-CHARSETに設定されている場合、キャラクタ・セットは現行のユーザー・ロケールのデフォルト・キャラクタ・セットに基づきます。デフォルトのキャラクタ・セットは、アプリケーション構成ファイルで指定されているロケールからキャラクタ・セットへのマッピング表から導出されます。
アプリケーション構成ファイル内のキャラクタ・セット・マッピング表が使用できない場合、キャラクタ・セットはGDK内のデフォルト・ロケール名からIANAキャラクタ・セットへのマッピング表に基づきます。デフォルト・マッピングは、OraLocaleInfoクラスから導出されます。
このタグ・セクションでは、アプリケーションでサポートされているロケールのリストを定義します。次に例を示します。
<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"を指定)することをお薦めします。
このセクションでは、優先ユーザー・ロケールの判別順序を定義します。ロケール・ソースは、アプリケーションでの使用例に基づいて指定する必要があります。このセクションでの使用例は、次のとおりです。
使用例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-3に、GDKフレームワークで使用されるパラメータを示します。
表8-3 GDKフレームワークで使用されるロケール・パラメータ
| デフォルトのパラメータ名 | 値 |
|---|---|
|
|
ISOロケール。ISO 639の言語コードとISO 3166の国コードをアンダースコア( |
|
|
Oracleの言語名。たとえば、米英語の場合は |
|
|
Oracleの地域名。たとえば、 |
|
|
タイム・ゾーン名。たとえば、 |
|
|
ISO 4217の通貨コード。たとえば、ユーロの場合は |
|
|
日付書式のパターン・マスク。たとえば、 |
|
|
長い日付書式のパターン・マスク。たとえば、 |
|
|
日時書式のパターン・マスク。たとえば、 |
|
|
長い日時書式のパターン・マスク。たとえば、 |
|
|
時刻書式のパターン・マスク。たとえば、 |
|
|
数値書式。たとえば、 |
|
|
通貨書式。たとえば、 |
|
|
言語ソート順序名。たとえば、日本語の多言語ソートの場合は |
|
|
キャラクタ・セット。たとえば、 |
|
|
書込み方向を示す文字列。たとえば、左から右への書込み方向の場合は |
|
|
GDKコマンド。たとえば、更新操作の場合は |
各パラメータ名は、HTMLフォームまたはURLでパラメータに使用されます。
このタグでは、アプリケーションで使用されるリソース・バンドルのベース・クラス名を定義します。マッピングは、リソース・バンドル内の翻訳済テキストを検索する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書換え操作の動作を制御するために使用されます。書換え規則は正規表現です。
<url-rewrite-rule fallback="no"> <pattern>(.*)/([^/]+)$</pattern> <result>$1/$L/$2</result> </url-rewrite-rule>
リクエストされたロケールについてローカライズされたコンテンツが使用できない場合、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>
この項では、次のアプリケーション・プロパティを使用してアプリケーション構成ファイルの例を示します。
アプリケーションでサポートしているロケールは、アラビア語(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>
Oracle Globalization Services for Javaには、次のパッケージが含まれています。
|
関連項目: 『Oracle Globalization Development Kit Java API Reference』 |
oracle.i18n.lcsdパッケージは、テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出して認識するクラスを提供します。プレーン・テキスト・ファイルとHTMLファイルの両方の検出がサポートされます。言語はISOに基づき、エンコーディングはIANAまたはOracleキャラクタ・セットに基づきます。このパッケージには次のクラスがあります。
LCSDetector: テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出して認識するメソッドが含まれています。
LCSDResultSet: LCSDResultSetクラスは、LCSDetectorにより生成される結果の格納用です。このクラスのメソッドを使用すると、結果から特定の情報を取り出すことができます。
LCSDetectionInputStream: ストリーム・オブジェクトの言語およびエンコーディングを透過的に検出します。
LCSDetectionReader: 入力データの言語およびエンコーディングを透過的に検出し、Unicodeに変換します。
LCSDetectionHTMLInputStream: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionInputStreamクラスを拡張します。
LCSDetectionHTMLReader: HTML形式の入力の言語およびエンコーディング検出をサポートするようにLCSDetectionReaderクラスを拡張します。
oracle.i18n.netパッケージは、グローバリゼーションのためのインターネット関連のデータ変換を提供します。このパッケージには次のクラスがあります。
CharEntityReference: 文字列を文字参照形式または実体参照形式との間でエスケープまたはアンエスケープするためのユーティリティ・クラスです。
CharEntityReference.Form: エスケープ形式を指定するフォーム・パラメータ・クラスです。
oracle.i18n.Servletパッケージは、JSPおよびJavaサーブレットで自動ロケールのサポートを可能にし、ローカライズされたコンテンツをアプリケーションに返します。このパッケージには次のクラスがあります。
ApplicationContext: フレームワークでアプリケーション・スコープ操作を制御するアプリケーション・コンテキスト・クラスです。
Localizer: 最も一般に使用されるグローバリゼーション情報へのアクセスを可能にするオールインワン・オブジェクト・クラスです。
ServletHelper: Java Servletとグローバリゼーション・オブジェクト間を結ぶ委譲クラスです。
oracle.i18n.textパッケージは、汎用的なテキスト・データ・グローバリゼーション・サポートを提供します。このパッケージには次のクラスがあります。
OraCollationKey: 特定のOraCollatorオブジェクトの特定の規則に基づくStringを表すクラスです。
OraCollator: 言語照合やバイナリ・ソートなど、ロケール依存の文字列比較を実行するクラスです。
OraDateFormat: 日時と文字列のロケール間で書式指定と解析を行う抽象クラスです。Oracleの日時の書式設定の動作をサポートします。
OraDecimalFormat: 数値と文字列のロケール間で書式指定と解析を行う具象クラスです。Oracleの数値の書式設定の動作をサポートします。
OraDecimalFormatSymbol: Oracleの数値書式と通貨書式に使用されるOracleの書式記号を維持するクラスです。
OraNumberFormat: 数値と文字列のロケール間で書式指定と解析を行う抽象クラスです。Oracleの数値の書式設定の動作をサポートします。
OraSimpleDateFormat: 日時と文字列のロケール間で書式指定と解析を行う具象クラスです。Oracleの日時の書式設定の動作をサポートします。
oracle.i18n.utilパッケージは、グローバリゼーション・サポート用の汎用ユーティリティを提供します。このパッケージには次のクラスがあります。
LocaleMapper: Oracleのロケール要素と他のベンダーおよび規格の等価ロケール要素の間のマッピングを提供します。
OraDisplayLocaleInfo: ロケールと属性の翻訳を提供する翻訳ユーティリティ・クラスです。
OraLocaleInfo: 言語、地域およびCollatorオブジェクトを含むOracleロケール・クラスです。
OraSQLUtil: SQLを処理する便利なメソッドを含むOracle SQL Utilityクラスです。
PL/SQL用GDKには、次のPL/SQLパッケージが含まれています。
UTL_I18N
UTL_LMS
UTL_I18Nは、開発者が国際化されたアプリケーションを構築する際に役立つPL/SQLサービスのセットです。UTL_I18N PL/SQLパッケージは、次のファンクションを提供します。
各種データ型の文字列変換ファンクション
HTMLおよびXML文書で使用される事前定義済の文字とマルチバイト・キャラクタのエスケープ・シーケンスとアンエスケープ・シーケンス
Oracle、Internet Assigned Numbers Authority(IANA)、ISOおよび電子メール・アプリケーションのキャラクタ・セット、言語および地域間でマップするファンクション
Oracle言語名からOracleキャラクタ・セット名を戻すファンクション
スクリプトの文字変換を実行するファンクション
特定の地域に対してサポートされているISO通貨コード、ローカル・タイム・ゾーンおよびローカル言語を戻すファンクション
特定の言語に対してサポートされている最も一般的な言語ソート、使用可能なすべての言語ソートのリストおよびローカル地域を戻すファンクション
Oracleのフル言語名と短縮言語名間をマップするファンクション
特定の言語および地域名の言語翻訳を戻すファンクション
最も一般的なタイム・ゾーンのリストを戻すファンクション
UTL_LMSは、様々な言語でエラー・メッセージを取り出して書式指定します。
|
関連項目: 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』 |
