| Oracle Application Serverグローバリゼーション・ガイド 10gリリース3（10.1.3.1.0） B31838-01 |
|
 戻る |
 次へ |
この章の項は次のとおりです。
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は、GDK for PL/SQLプログラミング環境に対してグローバリゼーション・サポートを提供します。GDK for JavaとGDK for PL/SQLで提供される機能は同じではありません。
GDK for Javaには、Oracleが開発したベストなグローバリゼーションの手法と機能を使用してグローバルなインターネット・アプリケーションを開発する、J2EEアプリケーション・フレームワークとJava APIが用意されています。GDK for Javaは、グローバルなJavaアプリケーションの開発時に直面する複雑さを軽減し、そのコードを簡略化します。
GDK for Javaは、J2EEが提供する既存のグローバリゼーション機能を補完します。J2EEプラットフォームには、グローバル・アプリケーションを構築するための強力な基盤がすでに備わっていますが、こうしたグローバル機能と動作はOracleの機能とまったく異なる場合があります。GDK for Javaは、中間層のJavaアプリケーションとデータベース・サーバー間で、ロケールに依存する動作を同期化します。
GDK for PL/SQLには、PL/SQLで記述されたアプリケーションにグローバリゼーション機能を追加するPL/SQLパッケージ・スイートが含まれます。
図3-1は、GDKの主要なコンポーネントと、それらの相互関係を示しています。ユーザー・アプリケーションは、中間層にあるOracle Application ServerのJ2EEコンテナ上で実行されます。GDKはJ2EEアプリケーションによって使用されるアプリケーション・フレームワークを提供し、グローバリゼーション・サポートのためのコーディングを簡略化します。フレームワークとアプリケーションの両方が、ロケール依存のタスクを実行するGDK Java APIをコールします。GDK for PL/SQLは、PL/SQL環境に固有なグローバリゼーションの問題の解決に役立つPL/SQLパッケージを提供します。
GDK for Javaが提供する機能は、次の2つのカテゴリに分類できます。
J2EE用のGDKアプリケーション・フレームワークは、J2EEベースのインターネット・アプリケーションを構築するためのグローバリゼーション・フレームワークを提供します。このフレームワークは、ユーザー・ロケールの決定、ロケールの永続性の保持、ロケール情報の処理などのグローバリゼーション・プログラミングの複雑性をカプセル化します。このフレームワークは、フレームワークへのアクセスをアプリケーションに提供するJavaクラス・セットで構成されます。これらの関連するJavaクラスを使用してフレームワークに対するコードをアプリケーションに追加することで、グローバリゼーション動作を宣言的に拡張できるようになります。
GDK Java APIはJavaアプリケーションの開発を支援し、Oracleデータベース・サーバーで実現されているような一貫性のあるグローバリゼーション操作を可能にします。このAPIにはGDKフレームワークから独立してアクセスでき、スタンドアロンJavaアプリケーションやGDKフレームワークに依存しないJ2EEアプリケーションからでもJava APIが提供する各機能にアクセスできます。Java APIが提供する機能には、データと数値の書式設定、ソート、Oracleデータベースと同様のキャラクタ・セット処理などがあります。
|
注意: GDK Java APIはJDKバージョン1.3以降で保証されています。ただし、キャラクタ・セットの変換クラスがJDK 1.4以降で使用可能なjava.nio.charsetパッケージに依存するという例外があります。
|
GDK for Javaは、orai18n.jarとorai18n-lcsd.jarという2つのファイルで提供されます。この両ファイルはOracle Application Serverに付属しています。GDKは、あらゆるプラットフォーム上で動作するPure Javaライブラリです。Oracleクライアント・パラメータのNLS_LANGとORACLE_HOMEは必要ありません。
この項では、単一言語アプリケーションを、GDKを使用してグローバルな多言語アプリケーションに変更する方法について説明します。この章のこの後の各項では、GDKの使用方法の詳細を説明します。
図3-2に、単一言語のWebアプリケーションのページを示します。
最初のGDKを使用しないHelloWorld Webアプリケーションは、"Hello World!"メッセージを出力し、ページの右上部に現在の日時を表示するだけのものです。次のコードは、このページを出力する最初のHelloWorldのJSPソース・コードです。
例3-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>
次のコード例は、HelloWorldメッセージを出力するWebアプリケーションの記述子ファイルです。
例3-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>
例3-1のHelloWorld JSPコードは、英語圏のユーザーのみを対象に記述されています。このコードには、次のような問題があります。
ユーザー・プリファレンスまたはブラウザ設定に基づいてロケールを決めることができない。
タイトルと見出しがコード内に含まれる。
日付と時間値がロケール・プリファレンスに基づいてローカライズされていない。
キャラクタ・エンコーディングがLatin-1用である。
GDKフレームワークをHelloWorldコードに統合することで、これをグローバルな多言語アプリケーションにできます。前述のコードを変更して、次のような機能を組み込むことができます。
ユーザーのブラウザ・ロケールを検出してクライアントにローカライズされたHTMLページを提供する、自動ロケール・ネゴシエーション。サポートされるアプリケーション・ロケールは、GDK構成ファイルに構成されます。
サポートされるアプリケーション・ロケールに対応付けるロケール選択リスト。このリストには、アプリケーション・ロケールの表示名（ロケールを表す国名）を一覧表示できます。リストはWebページに含まれるため、ユーザーは異なるロケールを選択できます。
HelloWorld JSPをグローバリゼーション・サポート化するGDKフレームワークとAPI。これには、ロケールに基づいた表示文字列の選択機能や、日付および時間値の書式設定機能が含まれます。
この項では、グローバリゼーションをサポートするようにHelloWorldアプリケーションを変更する方法について説明します。このアプリケーションを、簡体字中国語（zh-CN）、ドイツ語のスイス・バリアント（de-CH）およびアメリカ英語（en-US）の3つのロケールをサポートするように変更します。これらの言語には、次のルールが適用されます。
クライアント・ロケールがこれらの言語のいずれかをサポートする場合は、その言語がアプリケーションに使用されます。
クライアント・ロケールがこれらの言語をサポートしない場合は、アメリカ英語がアプリケーションに使用されます。
また、ロケール選択リストからサポートされているロケールを選択することで、ユーザーが言語を変更できるようにします。次の各作業によって、アプリケーションの変更方法を説明します。
作業1: GDKフレームワークを使用するためのHello Worldアプリケーションの有効化
この作業では、Webアプリケーションのデプロイメント・ディスクリプタ・ファイルのweb.xmlに、GDKフィルタとリスナーを構成します。これによって、HelloWorldアプリケーションでGDKフレームワークが使用可能になります。例3-3に、GDK対応のweb.xmlファイルを示します。
例3-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>ext/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アプリケーション・コンテキストをインスタンス化するように構成されています。
作業2: Hello World用GDKフレームワークの構成
GDKアプリケーション・フレームワークは、アプリケーション構成ファイルのgdkapp.xmlによって構成します。この構成ファイルは、web.xmlファイルと同じディレクトリにあります。例3-4に、gdkapp.xmlファイルを示します。
例3-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>e-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によって表現できるため、UTF-8エンコーディングがデフォルトとして使用されます。
<application-locales>
gdkapp.xmlファイルにアプリケーション・ロケールを構成することで、ロケールの一元的な定義が可能になります。これによって、ロケールの追加および削除が簡略化され、ソース・コードの変更が不要になります。ロケールのリストは、GDK APIコールのApplicationContext.getSupportedLocalesを使用して取得できます。
<locale-determine-rule>
最初のページの言語は、ブラウザの言語設定に基づいて決まります。ユーザーは、リストから選択することで、この言語をオーバーライドできます。locale-determine-ruleはGDKによって使用され、Accept-Language HTTPヘッダーがロケールのソースとして最初に適用されます。ユーザーがリストからロケールを選択した場合は、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サーブレットを有効化する必要があります。例3-5に、GDK APIとサービスを使用するように変更されたJSPを示します。このJSPは、任意の言語およびロケールに対応できます。
例3-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>
図3-3に、ブラウザ・プリファレンスのプライマリ・ロケールとして、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コード内で暗黙的に実行されます。
次のコード例では、nameに"locale"が指定されたHTMLのselectタグとして、ロケール選択リストが表示されます。"submit"が指定されたタグによって、新しい値がサーバーにポストされます。GDKフレームワークによって、選択が正しく取得されます。
<form>
<select name="locale" size="1">
<%= getCountryDropDown(request)%>
</select>
<input type="submit" value="<%= localizer.getMessage("changeLocale") %>">
</input>
</form>
ロケール選択リストは、getCountryDropDownメソッドによって生成されるHTMLコードにより構築されます。このメソッドは、構成済のアプリケーション・ロケールをローカライズされた国名に変換します。
ServletHelperクラスがコールされ、現行のリクエストに関連付けられたApplicationContextオブジェクトが取得されます。このオブジェクトはアプリケーションのグローバリゼーション・コンテキストを提供し、これには、サポートされているロケールや構成に関する情報などが含まれます。getSupportedLocalesコールは、gdkapp.xmlファイルに指定された一連のロケールを取得します。構成済のアプリケーション・ロケール・リストが、HTML selectのオプションとして表示されます。OraDisplayLocaleInfoクラスは、国名や言語名などのロケール固有要素のローカライズ・メソッドを提供します。
このクラスのインスタンスは、GDKフレームワークによって自動的に決定された現行ロケールを渡すことで作成されます。GDKは、HTTPリクエストおよびレスポンスに対するリクエストおよびレスポンスのラッパーを作成します。request.getLocale()メソッドは、GDKがロケール決定ルールに基づいて決定したロケールを返します。
OraDsiplayLocaleInfo.getDisplayCountryメソッドは、アプリケーション・ロケールのローカライズされた国名を取得します。HTMLオプション・リストは、ddOptBuffer文字列バッファに作成されます。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ロケールがロケールとして選択されます。国名は、現行ロケールに基づいて生成されます。
例3-6に、ロケール選択リストを構築するコードを示します。
例3-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ファイルによって提供されます。
GDKアプリケーション構成ファイルには、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ネーミング規則に従う必要があります。キャラクタ・セット名は、Internet Assigned Numbers Authority（IANA）規則に従います。
オプションとして、マッピング表にuser-agentパラメータを指定して、各種クライアントを区別できます。
<locale-charset> <locale>en,de</locale> <user-agent>^Mozilla/4.0</user-agent> <charset>ISO-8859-1</charset> </locale-charset>
この例では、英語（en）およびドイツ語（de）ロケールで、HTTPヘッダーのuser-agent値が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>
言語要素が*国コードとともに指定されている場合は、この言語コードを持つすべてのロケール名が有効になります。たとえば、de-*（ドイツ語の言語コード）がアプリケーション・ロケールの1つとして定義されている場合は、de-AT（ドイツ語-オーストリア）、de（ドイツ語-ドイツ）、de-LU（ドイツ語-ルクセンブルグ）およびde-CH（ドイツ語-スイス）のみでなく、de-CN（ドイツ語-中国）などの標準以外の組合せのロケールもサポートされます。ただし、事前定義されたロケール・セットをサポートするようにアプリケーションを制限できます。
未サポートのロケールでアプリケーションに接続するカスタマが代替ロケールとして使用できるように、アプリケーション・ロケールの1つをデフォルトに設定することをお薦めします（default="yes"を指定）。
このタグは、推奨ユーザー・ロケールが決定される順序を定義します。アプリケーションの使用例に基づいて、各ロケール・ソースを指定する必要があります。この後の使用例では、GDKフレームワークでlocale-determine-ruleを使用する方法について説明します。
使用例1: GDKフレームワークで常に優先言語を使用します。
<locale-determine-rule> <locale-source>oracle.i18n.servlet.localesource.HTTPAcceptLanguage </locale-source> </locale-determine-rule>
使用例2: GDKフレームワークで優先言語を使用します。ユーザーがロケールを指定した後は、そのロケールを以降の操作で使用します。
<locale-determine-rule> <locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source> <locale-source>oracle.i18n.servlet.localesource.HTTPAcceptLanguage </locale-source> </locale-determine-rule>
使用例3: GDKフレームワークで優先言語を使用します。ユーザーの認証後、GDKフレームワークでデータベース・ロケール・ソースを使用します。ユーザーがログアウトするまで、データベース・ロケール・ソースはキャッシュされます。ユーザーがログアウトした後は、優先言語が再び使用されます。
<locale-determine-rule>
<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>
</locale-determine-rule>
使用例3では、事前定義されたデータベース・ロケール・ソースのDBLocaleSourceが使用されています。これによって、カスタム・データベース・ロケール・ソースを記述することなく、構成ファイルにユーザー・プロファイル情報を指定できます。この例では、customerがユーザー・プロファイル表です。この表には、次の列があります。
customer_emailには、一意の電子メール・アドレスが格納されます。
nls_languageには、推奨言語が格納されます。
nls_territoryには、推奨地域のOracle名が格納されます。
timezoneには、カスタマのタイムゾーンが格納されます。
user-keyは必須属性で、アプリケーションからGDKフレームワークにユーザーIDを渡すために使用する属性名を指定します。
使用例4: GDKフレームワークで、最初のページに優先言語を使用します。ユーザーがロケールを入力した場合は、ユーザーがアプリケーションにログインするまで、そのロケールがキャッシュされて使用されます。ユーザーの認証後、GDKフレームワークでデータベース・ロケール・ソースを使用します。ユーザーがログアウトするまで、データベース・ロケール・ソースはキャッシュされます。ユーザーがログアウトした後は、優先言語が使用されます。または、ユーザーがロケールを入力した場合は、ユーザー入力ロケールが使用されます。
<locale-determine-rule> <locale-source>demo.DatabaseLocaleSource</locale-source> <locale-source>oracle.i18n.servlet.localesource.UserInput</locale-source> <locale-source>oracle.i18n.servlet.localesource.HttpAcceptLanguage </locale-source> </locale-determine-rule>
使用例4では、カスタム・データベース・ロケール・ソースが使用されています。ユーザー・プロファイル情報が複数の表に分割されているなど、ユーザー・プロファイルのスキーマが複数の場合は、アプリケーションでカスタム・ロケール・ソースを用意する必要があります。カスタム・ロケール・ソースのサンプルは、$ORACLE_HOME/nls/gdk/demoディレクトリにあります。
このタグは、現行のユーザー・ロケールをリクエスト間で渡せるように、ユーザー入力で使用されるロケール・パラメータの名前を定義します。
<locale-parameter-name> <timezone>ti</timezone> <linguistic-sort>ls</linguistic-sort> <date-format>df</date-format> </locale-parameter-name>
表3-1に、GDKフレームワークで使用されるパラメータを示します。
表3-1 GDKフレームワークで使用されるロケール・パラメータ
| デフォルト・パラメータ名 | 値 |
|---|---|
|
|
キャラクタ・セット。たとえば、 |
|
|
GDKコマンド。たとえば、更新操作用の |
|
|
通貨の書式。たとえば、 |
|
|
日付書式のパターン・マスク。たとえば、 |
|
|
日付および時間書式のパターン・マスク。たとえば、 |
|
|
ISO 4217通貨コード。たとえば、ユーロを表す |
|
|
Oracle言語名。たとえば、アメリカ英語を表す |
|
|
言語ソートの順序名。たとえば、日本語（多言語）ソートを表す |
|
|
ISO 639言語コードとISO 3166国コードがアンダースコア（ |
|
|
長い日付書式のパターン・マスク。たとえば、 |
|
|
長い日付および時間書式のパターン・マスク。たとえば、 |
|
|
数値書式。たとえば、 |
|
|
Oracle地域名。たとえば、 |
|
|
時間書式のパターン・マスク。たとえば、 |
|
|
タイムゾーン名。たとえば、 |
|
|
記述方向を表す文字列。左から右への記述方向を表す |
パラメータ名は、HTMLフォームまたはURLのどちらのパラメータでも使用されます。
このタグは、アプリケーションで使用されるリソース・バンドルのベース・クラス名を定義します。このマッピングは、リソース・バンドル内の翻訳済テキストを検索するLocalizer.getMessageメソッドで使用されます。
<message-bundles> <resource-bundle>Messages</resource-bundle> <resource-bundle name="newresource">NewMessages</resource-bundle> </message-bundles>
name属性が指定されていない場合または<resource-bundle>タグに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"を指定します。
たとえば、アプリケーションにfallback="yes"が指定されているときに、サポートされる翻訳がen、deおよびjaのみで、enがアプリケーションのデフォルト・ロケールだとします。現行のアプリケーション・ロケールがde-USの場合は、deに代替されます。ユーザーがアプリケーション・ロケールとしてzh-TWを選択した場合は、enに代替されます。
サポートされるアプリケーション・ロケールの数が翻訳ロケールの数よりも多い場合は、代替メカニズムがしばしば必要になります。この状況は、通常、複数のロケールで1つの翻訳を共有する場合に生じます。一例はスペイン語です。アプリケーションは、1セットの翻訳ファイルによって、スペインのみでなく、複数のスペイン語圏の国々をサポートする必要があります。
複数のURLリライト・ルールは、デフォルト以外のURLリライト・ルールにname属性を割り当てることで指定できます。デフォルト以外のURLリライト・ルールを使用するには、rewriteURLメソッドのパラメータとしてその名前を渡す必要があります。たとえば、次のように設定します。
<img src="<%=ServletHelper.rewriteURL("images/welcome.gif", request) %>">
<img src="<%=ServletHelper.rewriteURL("US.gif", "flag", request) %>">
最初のルールでは、"images/welcome.gif" URLがローカライズされたwelcomeイメージ・ファイルに変更されます。"flag"という名前の2番目のルールでは、"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>
例3-7に、次のアプリケーション・プロパティを持つアプリケーション構成ファイルを示します。
アプリケーションでは、次のロケールがサポートされます。
アラビア語（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>zh-CN</locale>
<locale default="yes">en</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>
GDK for Javaは、中間層のJ2EEアプリケーションに対してグローバリゼーション・フレームワークを提供します。このフレームワークは、ユーザー・ロケールの決定、ロケールの永続性の保持、ロケール情報の処理などのグローバリゼーション・プログラミングの複雑性をカプセル化します。このフレームワークによって、インターネット・アプリケーションのグローバル対応化に必要な作業が最小限になります。図3-4に、GDKアプリケーション・フレームワークを示します。
このフレームワークを構成する主要なJavaクラスは次のとおりです。
ApplicationContextは、アプリケーションのグローバリゼーション・コンテキストを提供します。コンテキスト情報には、サポートされるロケールのリストと、ユーザー推奨ロケールを決定するルールが含まれます。コンテキスト情報は、アプリケーションのGDKアプリケーション構成ファイルから取得されます。
LocaleSourceクラス・セットは、フレームワークにプラグインできます。各LocaleSourceクラスはLocaleSourceインタフェースを実装し、対応するソースからロケールを取得します。GDKには、いくつかのLocaleSourceクラスがバンドルされています。たとえば、DBLocaleSourceクラスは、データベース・スキーマから現行ユーザーのロケール情報を取得します。また、同一のLocaleSourceインタフェースを実装してフレームワークにプラグインすることで、カスタマイズされたLocaleSourceクラスを記述することもできます。
ServletRequestWrapperとServletResponseWrapperは、HTTPリクエストとHTTPレスポンスを変換するGDK Servletフィルタの主要なクラスです。ServletRequestWrapperは、ApplicationContextオブジェクトとLocaleSourceオブジェクトから取得した情報に基づいて、各HTTPリクエスト用のLocalizerオブジェクトをインスタンス化し、フォーム・パラメータの適切な処理を保証します。ServletResponseWrapperは、HTTPレスポンスの作成方法を制御します。
Localizerは、現行ユーザーのロケールとアプリケーション・コンテキストに依存する重要な関数を公開するオブジェクトです。Localizerは集中型のメソッド・セットを提供し、それらをコールすることで、現行ユーザーのロケールとアプリケーション・コンテキストに基づくアプリケーションの適切な動作を可能にします。
GDK Java APIは、アプリケーションのグローバリゼーション動作をより緻密に制御するために、いつでも使用できます。
GDKアプリケーション・フレームワークは、アプリケーションで複数のロケールをサポートするために必要なコーディングを簡略化します。このアプリケーション・フレームワークに従ってJ2EEアプリケーションを記述すると、アプリケーション・コードがアプリケーションがサポートするロケールから独立し、GDKアプリケーション構成ファイルにグローバリゼーション・サポートを定義することで、アプリケーションのグローバリゼーション・サポートを制御できます。サポートされるアプリケーション・ロケールのリストにロケールを追加したり、そこからロケールを削除しても、コードの変更は必要ありません。
GDKアプリケーション構成ファイルでのグローバリゼーション・サポートの定義方法の一部を、次に示します。
サポートされるロケールのリストでのロケールの追加と削除
ユーザー・ロケールの決定方法の変更
アプリケーションのHTMLページ・エンコーディングの変更
翻訳済リソースの配置方法の指定
フレームワークへの新しいLocaleSourceオブジェクトの実装と、ユーザー・ロケール検出でのそれらの使用
J2EE用のGDKアプリケーション・フレームワークの動作は、GDKアプリケーション構成ファイルのgdkapp.xmlによって制御されます。開発者はアプリケーション構成ファイルを使用することで、一元化された場所でグローバル・アプリケーションの動作を指定できます。GDKを使用するJ2EEアプリケーションごとに、1つのアプリケーション構成ファイルが必要です。
gdkapp.xmlファイルは、アプリケーションのJ2EE環境の./WEB-INFディレクトリに配置する必要があります。ここには、ロケール・マッピング表、コンテンツ・ファイルのキャラクタ・セット、アプリケーション構成のグローバリゼーション・パラメータなどが含まれます。アプリケーション管理者はアプリケーション構成ファイルを修正することで、プログラムを変更して再コンパイルすることなく、アプリケーションのグローバリゼーション動作を変更できます。
対応するGDKアプリケーション構成ファイルに定義されているGDKアプリケーション・フレームワークをJ2EEアプリケーションで使用するには、アプリケーションのweb.xmlファイルにGDK Servletフィルタと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フレームワークとともに他のフィルタを使用するときは、競合の可能性に注意する必要があります。
|
関連項目:
|
ユーザー推奨ロケールの決定が、アプリケーションをグローバル対応にするための最初の手順になります。J2EEアプリケーション・フレームワークが提供するロケール検出機能は初歩的なものです。それには、ロケール・ソースの中から最適なユーザー・ロケールを透過的に取得する方法が備わっていません。HTTP言語プリファレンスによるロケール検出のみが可能で、マルチレベルのロケール代替メカニズムはサポートされません。GDKアプリケーション・フレームワークは事前定義されたロケール・ソースをサポートすることで、J2EEを補完します。Webアプリケーションでは、複数のロケール・ソースを使用できます。表3-2に、GDKで提供されるロケール・ソースをまとめます。
| ロケール | 説明 |
|---|---|
|
アプリケーションのデフォルト・ロケール |
GDKアプリケーション構成ファイルに定義されているロケール。このロケールはアプリケーションのデフォルト・ロケールとして定義されます。通常、これは他のロケール・ソースを利用できないときに、代替ロケールとして使用されます。 |
|
HTTP言語プリファレンス |
HTTPプロトコルの |
|
ユーザー入力ロケール |
メニューやHTTPプロトコルのパラメータを介してユーザーが指定するロケール。 |
|
データベースにあるユーザー・プロファイルのロケール・プリファレンス |
ユーザー・プロファイルの一部としてデータベースに格納されたロケール・プリファレンス。 |
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ディレクトリにあります。
|
関連項目:
|
GDKでは自動的なロケール検出の機能によって、ユーザーの現行ロケールが決定されます。たとえば、次のJavaコードは現行のユーザー・ロケールを取得します。ここでは、Localeオブジェクトが明示的に使用されています。
Locale loc = request.getLocale();
getLocale()メソッドは、現行のロケールを表すLocaleを返します。これは、JSPまたはJava ServletコードでHttpServletRequest.getLocale()メソッドをコールする場合と類似しています。ただし、GDKフレームワークでは複数のロケール・ソースが考慮されるため、ユーザー・ロケールを決定するロジックが異なります。
かわりに、GDKフレームワークによって決定されるLocaleオブジェクトをカプセル化するLocalizerオブジェクトを取得できます。
Localizer localizer = ServletHelper.getLocalizerInstance(request); Locale loc = localizer.getLocale();
GDKフレームワークのロケール検出ロジックは、GDKアプリケーション構成ファイルに定義されているロケール・ソースに基づきます。ロケール・ソースの名前がアプリケーション構成ファイルに登録されています。次の例は、アプリケーション構成ファイルのロケール決定ルールのセクションを示しています。これは、ユーザー推奨ロケールが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でサポートされるコマンドを示します。
| コマンド | 機能 |
|---|---|
clean
|
キャッシュ内の現行のロケール情報を廃棄します。 |
store
|
使用可能なロケール・ソースにあるユーザー・ロケール・プリファレンスを、指定されたロケール情報で更新します。このコマンドは、読取り専用のロケール・ソースでは無視されます。 |
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オブジェクトの詳細は、『Oracle Globalization Development Kit Java API Reference』を参照してください。
|
アプリケーションでサポートする必要があるロケール数とロケール名は、アプリケーションのビジネス要件によって決まります。アプリケーションによってサポートされるロケール名は、アプリケーション構成ファイルに登録されます。次の例は、アプリケーション構成ファイルのアプリケーション・ロケールのセクションを示しています。これは、アプリケーションがドイツ語（de）、日本語（ja）およびアメリカ英語（en-US）をサポートし、アメリカ英語をデフォルトの代替アプリケーション・ロケールとすることを定義しています。ロケール名はIANA規則に基づくことに注意してください。
<application-locales>
<locale>de</locale>
<locale>ja</locale>
<locale default="yes">en-US</locale>
</application-locales>
GDKフレームワークがユーザー・ロケールを検出すると、返されたロケールがアプリケーション構成ファイルで定義されたサポート対象のロケールであるかどうかが検証されます。この検証アルゴリズムは次のようになります。
アプリケーション構成ファイルから、サポートされるアプリケーション・ロケールのリストを取得します。
検出されたロケールがそのリストに含まれるかどうかをチェックします。リストに含まれる場合は、そのロケールを現行クライアントのロケールとして使用します。
検出されたロケールにバリアントがある場合は、バリアントを削除して、そのロケールがリストにあるかどうかをチェックします。たとえば、Javaロケールのde_DE_EUROにはEUROバリアントがあります。このバリアントを削除すると、ロケールはde_DEになります。
ロケールに国コードが含まれる場合は、国コードを削除して、そのロケールがリストにあるかどうかをチェックします。たとえば、Javaロケールのde_DEには国コードDEがあります。この国コードを削除すると、ロケールはdeになります。
検出されたロケールがリスト内のいずれのロケールとも一致しない場合は、アプリケーション構成ファイルにクライアント・ロケールとして定義されているデフォルト・ロケールを使用します。
手順3と4を実行することで、言語要件が同じにもかかわらず、アプリケーション構成ファイルの定義とは異なるロケール設定を持つユーザーをサポートできます。たとえば、GDKは、de-AT（ドイツ語のオーストリア・バリアント）、de-CH（ドイツ語のスイス・バリアント）およびde-LU（ドイツ語のルクセンブルグ・バリアント）の各ロケールをサポートできます。
GDKフレームワークのロケール代替検出は、JVMのデフォルト・ロケールに影響されないという点を除くと、Javaリソース・バンドルのロケール代替検出と類似しています。この違いは、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キャラクタ・セットが提供されます。
表3-3に、一般的なISOロケールとそのIANAキャラクタ・セット間のマッピングを示します。
表3-3 一般的なISOロケールとIANAキャラクタ・セット間のマッピング
| ISOロケール | IANAキャラクタ・セット | NLS_LANGUAGE値 | NLS_TERRITORY値 |
|---|---|---|---|
|
ar-SA |
WINDOWS-1256 |
ARABIC |
SAUDI ARABIA |
|
de-DE |
WINDOWS-1252 |
GERMAN |
GERMANY |
|
el |
WINDOWS-1253 |
GREEK |
GREECE |
|
en-GB |
WINDOWS-1252 |
ENGLISH |
UNITED KINGDOM |
|
en-US |
WINDOWS-1252 |
AMERICAN |
AMERICA |
|
es-ES |
WINDOWS-1252 |
SPANISH |
SPAIN |
|
fr |
WINDOWS-1252 |
FRENCH |
FRANCE |
|
fr-CA |
WINDOWS-1252 |
CANADIAN FRENCH |
CANADA |
|
it |
WINDOWS-1252 |
ITALIAN |
ITALY |
|
iw |
WINDOWS-1255 |
HEBREW |
ISRAEL |
|
ja |
SHIFT_JIS |
JAPANESE |
JAPAN |
|
ko |
EUC-KR |
KOREAN |
KOREA |
|
nl |
WINDOWS-1252 |
DUTCH |
THE NETHERLANDS |
|
pt |
WINDOWS-1252 |
PORTUGUESE |
PORTUGAL |
|
pt-BR |
WINDOWS-1252 |
BRAZILIAN PORTUGUESE |
BRAZIL |
|
tr |
WINDOWS-1254 |
TURKISH |
TURKEY |
|
zh |
GBK |
SIMPLIFIED CHINESE |
CHINA |
|
zh-TW |
BIG5 |
TRADITIONAL CHINESE |
TAIWAN |
GDKでのロケールとキャラクタ・セット間のマッピングはカスタマイズできます。GDK Java APIに定義されているデフォルトのマッピングを上書きする場合は、ロケールとキャラクタ・セット間のマッピング表をアプリケーション構成ファイルで指定できます。
<locale-charset-maps>
<locale-charset>
<locale>ja</locale><charset>EUC-JP</charset>
</locale-charset>
</locale-charset-maps>
この例では、GDKによって、日本語ロケール（ja）のデフォルトのキャラクタ・セットがSHIFT_JISからEUC-JPに変更されます。
この項の項目は次のとおりです。
リソース・バンドルを使用することで、Java 2 Platform, Standard Edition（J2SE）の実行時に、ローカライズされたコンテンツにアクセスできます。JavaサーブレットおよびJava Server 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>
構成ファイルのこのコードでは、翻訳済コンテンツがJavaバンドル・クラスのresourceにあるデフォルトのリソース・バンドルが宣言されています。アプリケーション構成ファイルには、複数のリソース・バンドルを指定できます。デフォルト以外のバンドルにアクセスするには、getMessageメソッドのnameパラメータを指定します。このメッセージ・バンドル・メカニズムでは、その実装にOraResourceBundle GDKクラスが使用されます。このクラスでは、Javaの動作よりも優先される特別なロケール代替動作が提供されます。そのルールは次のとおりです。
使用可能なリソース・バンドルにあるロケールと指定ロケールが完全に一致する場合は、そのロケールが使用されます。
中国語（シンガポール）（zh_SG）のリソース・バンドルが見つからない場合、簡体字中国語の翻訳では、中国語（中国）（zh_CN）のリソース・バンドルに代替されます。
中国語（香港）（zh_HK）のリソース・バンドルが見つからない場合、繁体字中国語の翻訳では、中国語（台湾）（zh_TW）のリソース・バンドルに代替されます。
中国語（マカオ）（zh_MO）のリソース・バンドルが見つからない場合、繁体字中国語の翻訳では、中国語（台湾）（zh_TW）のリソース・バンドルに代替されます。
その他の中国語ロケール（zh_およびzh）のリソース・バンドルが見つからない場合、簡体字中国語の翻訳では、中国語（中国）（zh_CN）のリソース・バンドルに代替されます。
代替操作では、Locale.getDefaultメソッドによって取得できるデフォルト・ロケールは考慮されません。
このルールでは、香港およびマカオに対する推奨言語が規定されています。JDKの代替ロケールは簡体字中国語（zh）ですが、実際は、繁体字中国語（zh_TW）の方がより多く使用されるためです。
たとえば、デフォルト・ロケールがja_JPで、そのリソース・バンドルが使用可能とします。es_MXのリソース・バンドルがリクエストされたときに、esまたはes_MXのリソース・バンドルがどちらもない場合は、ロケール接尾辞のないベースのリソース・バンドル・オブジェクトが返されます。
OraResourceBundleクラスの使用方法はjava.util.ResourceBundleクラスと類似していますが、OraResourceBundleコールではそれ自身のインスタンスが作成されません。かわりに、getBundleメソッドの戻り値が、java.util.ResourceBundleクラスのサブクラスのインスタンスとなります。
単一のロケールのみをサポートするアプリケーションでは、ユーザーは通常、/index.htmlという接尾辞を持つURLによってアプリケーションの開始ページに導かれます。
グローバル・アプリケーションでは、各言語のコンテンツがそれぞれ用意されるのが一般的で、通常、各コンテンツは言語名や国名に基づいて異なるディレクトリに配置されたり、異なるファイル名が付けられます。次に、この情報を使用して、アプリケーションでローカライズされたコンテンツを取得するためのURLが作成されます。
次のコードは、indexページのフランス語版と日本語版を取得する方法を示しています。これらの接尾辞は次のようになります。
/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のグローバリゼーション機能と動作は、データベースのものと同じではありません。たとえば、J2SEがサポートする一連のロケールとキャラクタ・セットには、Oracleのロケールとキャラクタ・セットとは異なるものがあります。2つの異なる規則に基づいて書式設定されるデータがアプリケーションにある場合は、この非一貫性はユーザーにとって混乱の元となります。たとえば、データベースから取得されたデータはOracleの規則に従って書式設定され、静的なアプリケーション・データはJavaのロケール規則に従って書式設定されます（数値と日付の書式設定や言語ソート順など）。また、Javaのグローバリゼーション機能は、アプリケーションが動作するJDKのバージョンによっても異なる場合があります。
GDK Java APIは、Oracle Application Serverのデータベース・グローバリゼーション機能を中間層に拡張します。GDK Java APIによって、Oracleの日付と数値の書式設定や言語ソートなどのグローバリゼーション・ロジックをアプリケーションが中間層で実行できるようになり、開発者はデータベースに負荷の高いプログラミング・ロジックを実装しなくてもよくなります。その結果、データベース・サーバーでのデータベースの負荷と、アプリケーション層とデータベース・サーバー間の不要なネットワーク通信が減少し、全体的なアプリケーション・パフォーマンスが向上します。
また、GDK Java APIには、言語とキャラクタ・セットの検出や、地域または言語に適用される共通ロケール・データの列挙（たとえば、カナダでサポートされるすべてのタイムゾーン）などの高度なグローバリゼーション機能が用意されています。これらのグローバリゼーション機能は、ほとんどのプログラミング・プラットフォームで利用できません。GDK Java APIを使用しない場合は、開発者がアプリケーション内部にこれらを処理するビジネス・ロジックを記述する必要があります。
次に、GDK Java APIの主要な機能を示します。
Oracleのロケール定義には、言語、地域、言語ソートおよびキャラクタ・セットが含まれ、GDK Java APIに公開されます。Oracleで使用するネーミング規則は、他のベンダーと異なる場合もあります。これらの名前と定義の多くは業界標準に従いますが、一部はOracle固有で、特定のカスタマ要件に合うように調整されています。
Oracleロケール・クラスのOraLocaleInfoには、言語、地域およびコレータ・オブジェクトが含まれます。OraLocaleInfoは、指定されたロケールのロケール関連オブジェクトのコレクションを取得するメソッドをアプリケーションに提供します。たとえば、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クラスが提供されます。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クラスは、Microsoft WindowsとUNIXプラットフォームの両方で、特定のロケールで最も一般的に使用される電子メール用キャラクタ・セットを返すこともできます。これは、電子メール・メッセージの処理が必要なJavaアプリケーションの開発に便利です。
GDK Java APIには、ユーザーによるOracleキャラクタ・セット変換を実行可能にする、一連のキャラクタ・セット変換クラスAPIが用意されています。Java JDKには、数多くの標準キャラクタ・セットに対して変換を実行可能なクラスが備わっていますが、Oracle固有のキャラクタ・セットとOracleユーザー定義のキャラクタ・セットがサポートされていません。
JDK 1.4では、J2SEによって、開発者がJavaキャラクタ・セットを拡張するためのインタフェースが導入されました。GDK Java APIでは、このプラグイン機能を使用して、Oracleキャラクタ・セットを暗黙的にサポートします。開発者は、J2SE APIにアクセスすることで、Oracle固有の動作を実装できます。
図3-5に、Javaキャラクタ・セット表と同じ方法での、GDKキャラクタ・セット変換表のJ2SEへのプラグインを示します。J2SEのこのプラッガブル・フレームワークによって、他のJavaキャラクタ・セット変換と同じ方法で、Oracleキャラクタ・セット変換を使用できます。
java.nio.charset Javaパッケージは、バージョン1.4よりも前のJDKでは使用できません。Oracleキャラクタ・セット・プラグイン機能を使用するには、JDK 1.4以降をインストールする必要があります。
GDKキャラクタ変換クラスは、ユーザー定義のキャラクタ・セットを含むすべてのOracleキャラクタ・セットをサポートします。これらのクラスはJavaアプリケーションで使用可能で、Javaの内部キャラクタ・セットであるUTF-16との適切な相互変換が実現されます。
Oracleキャラクタ・セットの名前は独自のものです。Java固有のキャラクタ・セットと名前が競合する可能性を回避するために、Java APIを介して暗黙的に使用する場合、すべてのOracleキャラクタ・セット名には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キャラクタ・セット変換クラスを使用する例です。
GDK Java APIが提供する書式設定クラスによって、oracle.i18n.textパッケージのJavaアプリケーション用Oracle規則を使用した日付、数値および通貨書式がサポートされます。
長短の日付、数値、通貨書式など、Oracle Application Serverで導入された新しいロケール書式も、これらの書式クラスで提供されます。
次は、Oracle日付、Oracle数値および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 Application Serverでは、これらのソートが拡張され、データベース内における、大文字と小文字やアクセントで区別されないソート機能と検索機能が導入されました。GDK Java APIでは、OraCollatorクラスを使用して、大文字と小文字やアクセントで区別しないオプションを含む最新のOracleバイナリおよび言語ソート機能に基づいた情報のソートと検索を、Javaアプリケーションに実現します。
標準化はソートの重要な要素です。文字の組立てと分割はUnicode標準に基づいて行われるため、ソートもUnicode標準に基づいて行われます。JDKの各バージョンでは異なるバージョンのUnicode標準がサポートされる場合があるため、GDKではUnicode 3.2標準に基づくOraNormalizerクラスが提供されます。このクラスには、組立てを実行するメソッドが含まれています。
バイナリ・ソートのソート順序は、使用中のOracleキャラクタ・セットに基づきます。UTFEキャラクタ・セットを除いて、すべてのOracleキャラクタ・セットのバイナリ・ソートがGDK Java APIでサポートされます。GDK Java APIでサポートされない唯一の言語ソートはJAPANESEですが、JAPANESE_Mの使用によって、同様のより正確なソート結果を達成できます。
次は、文字列比較と文字列ソートの例です。
// 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クラスに対して、言語とキャラクタ・セットを検出できます。このクラスは、長さまたは長さとオフセットの両方が指定されているときに、入力全体または入力の一部のみをサンプル用に取得します。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("Language " + 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("Language " + res.getOraLanguage(2) );
System.out.println("CharacterSet " +res.getOraCharacterSet(2) );
}
if ( high_hit >= 3 )
{
System.out.println("the third best guess ");
System.out.println("Language " + res.getOraLanguage(3) );
System.out.println("CharacterSet " +res.getOraCharacterSet(3) );
}
すべてのOracle言語名、地域名、キャラクタ・セット名、言語ソート名およびタイムゾーン名は、英語を含む27言語に翻訳されています。これらは簡単にユーザー・アプリケーションに挿入でき、異なる言語のユーザー・アプリケーション間での表示名の一貫性を保証します。OraDisplayLocaleInfoは、ロケールと属性の翻訳済名を提供するユーティリティ・クラスです。翻訳済の名前は、ユーザー・インタフェースのテキスト表示や選択ボックスなどで効果的です。たとえば、ネイティブのフランス語スピーカには、英語よりもフランス語で表示されたタイムゾーン・リストから選択することがより適しています。
次は、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キャラクタ・セット・エンコーディングで、簡体字中国語データを含む電子メール・メッセージを送信する例です。
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();
}
}
}
Oracle Globalization Services for Javaには、次のパッケージが用意されています。
|
関連項目: 『Oracle Globalization Development Kit Java API Reference』 |
パッケージoracle.i18n.lcsdは、テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出および認識するクラスを提供します。言語はISOに基づき、エンコーディングはIANAまたはOracleキャラクタ・セットに基づきます。ここには、次のクラスが含まれます。
LCSDetector: テキスト入力に基づいて言語とキャラクタ・セットを自動的に検出および認識するメソッドを含みます。
LCSDResultSet: LCSDetectorによって生成される結果を格納します。このクラスのメソッドは、結果から特定の情報を取得するために使用できます。
パッケージoracle.i18n.netは、グローバリゼーションの目的で使用するインターネット関連のデータ変換を提供します。ここには、次のクラスが含まれます。
CharEntityReference: 文字列を文字参照または実体参照フォームにエスケープまたはアンエスケープするユーティリティ・クラス。
CharEntityReference.Form: エスケープされたフォームを指定するフォーム・パラメータ・クラス。
パッケージoracle.i18n.Servletは、JSPおよびJavaサーブレットで自動ロケールのサポートを可能にし、ローカライズされたコンテンツをアプリケーションに返します。ここには、次のクラスが含まれます。
ApplicationContext: フレームワーク内でのアプリケーション・スコープ操作を制御するアプリケーション・コンテキスト・クラス。
Localizer: 最も一般的に使用されるグローバリゼーション情報へのアクセスを可能にするオールインワンのオブジェクト・クラス。
ServletHelper: Javaサーブレットとグローバリゼーション・オブジェクト間をブリッジする代理クラス。
パッケージ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: 言語、地域およびコレータ・オブジェクトを含むOracleロケール・クラス。
OraSQLUtil: SQLを処理する便利なメソッドを持つOracle SQLユーティリティ・クラス。
GDK for PL/SQLには、次のPL/SQLパッケージが用意されています。
UTL_I18N
UTL_LMS
UTL_I18Nは、開発者によるグローバル対応アプリケーションの構築を支援するPL/SQLサービスのセットです。UTL_I18N PL/SQLパッケージには、次の関数があります。
各種データ型に使用する文字列変換関数
HTMLおよびXML文書で使用される事前定義済文字およびマルチバイト・キャラクタ用のエスケープ・シーケンスおよびアンエスケープ・シーケンス
Oracle、IANA、ISOと、電子メール・アプリケーション・キャラクタ・セット、言語、地域間をマッピングする関数
Oracle言語名からOracleキャラクタ・セット名を返す関数
UTL_LMSは、異なる言語のエラー・メッセージを取得し書式設定します。
|
関連項目: 『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』 |
