| Oracle Application Serverグローバリゼーション・ガイド 10gリリース3（10.1.3.1.0） B31838-01 |
|
 戻る |
 次へ |
この章の項目は次のとおりです。
グローバル・インターネット・アプリケーションの拡張に使用可能な様々なHTML機能があります。次の項では、グローバル・アプリケーションの設計時に必要なHTML機能の一部について説明します。
次のガイドラインに従って、HTMLページのフォーマットを設計します。
セル幅をハードコードするのではなく、囲まれたテキストが広がるように表セルをサイズ変更できるようにします。次に、セル幅をハードコードする例を示します。
<TD WIDTH="50">
セル幅を指定する必要がある場合は、widthの値を外部化して、翻訳者が翻訳対象テキストに合せて調整できるようにします。
カスケーディング・スタイル・シート（CSS）を各ロケールや各ロケール・グループ用に作成して、それをHTMLページのレンダリングの制御に使用することをお薦めします。CSSの使用によって、ロケール固有の書式設定情報をHTMLページから切り離します。アプリケーションは、ユーザーのロケールに該当するCSS参照をHTMLページに動的に生成して、ページを該当のロケール固有のフォーマットでレンダリングできるようにする必要があります。CSSファイルのロケール固有情報には、次の項目を指定する必要があります。
フォントの名前とサイズ
位置合せ（右から左へ記述する言語でのみサポート）
テキストの方向（右から左へ記述する言語でのみサポート）
アプリケーションがサポートするすべての言語の絵文字がフォントに含まれているとはかぎらないので、HTMLページで直接フォントを指定しないでください。そのかわりに、各要素はカスケーディング・スタイル・シート（CSS）のクラスからフォントとフォント・サイズを継承します。
アラビア語やヘブライ語などの右から左に記述する言語の場合、ページの<HTML>タグにDIR属性を指定して、右から左へ言語を表示することを示す必要があります。<HTML DIR="RTL">タグによって、HTMLページのすべてのコンポーネントがHTMLタグの方向に従うことになります。開発者にとって透過的に方向を設定するには、CSSファイルで次のように方向を設定します。
HTML{ direction:rtl }
CSSレベル2には、方向プロパティが採用されました。
テキスト位置合せは、テキストの方向に依存する必要があります。HTMLでは、LEFTおよびRIGHTは絶対的な位置合せです。英語などのようにテキストの方向が左から右の場合は、位置合せをLEFTにする必要があります。ヘブライ語などのようにテキストの方向が右から左の場合は、位置合せをRIGHTにする必要があります。
HTMLページのエンコーディングは、ブラウザとインターネット・アプリケーションにとって重要な情報です。ページ・エンコーディングは、インターネット・アプリケーションが従うロケール用に使用するキャラクタ・セットとみなすことができます。ブラウザでは、適切なフォントとキャラクタ・セットのマッピング表を使用してページを表示できるように、ページ・エンコーディングについて認識している必要があります。インターネット・アプリケーションでは、HTMLフォームの入力データを処理できるように、HTMLページ・エンコーディングについて認識している必要があります。HTMLページに対して適切なページ・エンコーディングを指定するには、インターネット・アプリケーションで次のことを行う必要があります。
ページ・エンコーディングの選択
指定のエンコーディングでのHTMLコンテンツのエンコード
エンコーディング名でのHTMLページの正確な指定
HTMLページ・エンコーディングは、ユーザーのロケールに基づきます。アプリケーションが単一言語の場合、インスタンスごとに1つのロケールがサポートされます。このため、そのロケールのシステム固有のエンコーディングでHTMLページをエンコードする必要があります。エンコーディングは、Oracle HTTP Server構成ファイルのNLS_LANGパラメータで指定されたOracleキャラクタ・セットと同一でなくてはなりません。
表4-1に、一般的に使用されるロケールのシステム固有のエンコーディングに対するOracleキャラクタ・セット名を、IANA（Internet Assigned Numbers Authority）エンコーディング名とJavaエンコーディング名とともに示します。単一言語アプリケーションには、これらのキャラクタ・セットを使用します。
表4-1 一般的に使用されるロケールのシステム固有のエンコーディング
| 言語 | Oracleキャラクタ・セット名 | IANAエンコーディング名 | Javaエンコーディング名 |
|---|---|---|---|
|
アラビア語 |
AR8MSWIN1256 |
ISO-8859-6 |
ISO8859_6 |
|
バルト語 |
BLT8MSWIN1257 |
ISO-8859-4 |
ISO8859_4 |
|
中欧語 |
EE8MSWIN1250 |
ISO-8859-2 |
ISO8859_2 |
|
キリル語 |
CL8MSWIN1251 |
ISO-8859-5 |
ISO8859_5 |
|
ギリシャ語 |
EL8MSWIN1253 |
ISO-8859-7 |
ISO8859_7 |
|
ヘブライ語 |
IW8MSWIN1255 |
ISO-8859-8 |
ISO8859_8 |
|
日本語 |
JA16SJIS |
Shift_JIS |
MS932 |
|
韓国語 |
KO16MSWIN949 |
EUC-KR |
MS949 |
|
簡体字中国語 |
ZHS16GBK |
GB2312 |
GBK |
|
タイ語 |
TH8TISASCII |
TIS-620 |
TIS620 |
|
繁体字中国語 |
ZHT16MSWIN950 |
Big5 |
MS950 |
|
トルコ語 |
TR8MSWIN1254 |
ISO-8859-9 |
ISO8859_9 |
|
各国語共通 |
UTF8 |
UTF-8 |
UTF8 |
|
西欧語 |
WE8MSWIN1252 |
ISO-8859-1 |
ISO8859_1 |
多言語アプリケーションでは、現行のユーザーのロケールに使用するエンコーディングを実行時に決定し、そのロケールを表4-1に示すエンコーディングに対応付ける必要があります。
個別のロケールにそれぞれ異なるシステム固有のエンコーディングを使用するのではなく、UTF-8をすべてのページに使用することが可能です。UTF-8エンコーディングを使用すると、多言語アプリケーションのコードを簡単に記述できることに加えて、多言語コンテンツもサポートできます。実際に、多言語インターネット・アプリケーションをPerlで記述する場合、HTMLコンテンツをUTF-8から各種ロケールのシステム固有のエンコーディングに変換する直感的で効果的な方法がプログラミング環境にないので、HTMLページ・エンコーディングとして最適な選択はUTF-8ということになります。
単一言語および多言語アプリケーションに対する最善策は、クライアント・ブラウザに返されるHTMLページのエンコーディングを指定することです。HTMLページのエンコーディングは、ブラウザに次の動作を指示します。
指定したエンコーディングに切り替える
指定したエンコーディングでユーザー入力を返す
次の項では、HTMLページのエンコーディングを指定する方法について説明します。
2つの方法を併用する場合は、HTTPヘッダー内のエンコーディングの指定が優先されます。
HTTPの指定時に、Content-Type HTTPヘッダーを追加します。これによって、コンテンツ・タイプとキャラクタ・セットを指定します。Netscape 4.0以降やInternet Explorer 4.0以降などの一般的に使用されるブラウザでは、このヘッダーが正しく解析されます。Content-Type HTTPヘッダーは、次のような構成になります。
Content-Type: text/plain; charset=iso-8859-4
charsetパラメータでは、HTMLページのエンコーディングを指定します。charsetパラメータの可能な値は、ブラウザがサポートする文字エンコーディングのIANA名です。表4-1に、一般的に使用されるIANA名を示します。
この方法は、主に静的なHTMLページに対して使用します。HTMLヘッダー内で次のように文字エンコーディングを指定してください。
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
charsetパラメータでは、HTMLページのエンコーディングを指定します。charsetパラメータの可能な値は、ブラウザがサポートする文字エンコーディングのIANA名です。表4-1に、一般的に使用されるIANA名を示します。
単一言語でも多言語アプリケーションでも、contentTypeページ・ディレクティブを使用するJavaServer Pages（JSP）のContent-Type HTTPヘッダー内でHTMLページのエンコーディングを指定できます。たとえば、次のように設定します。
<%@ page contentType="text/html; charset=utf-8" %>
これは、JSPファイルがクライアントに送信するレスポンスに使用するMIMEタイプと文字エンコーディングです。JSPコンテナに対して有効なMIMEタイプまたはIANAキャラクタ・セット名を使用できます。デフォルトのMIMEタイプは、text/htmlで、デフォルトのキャラクタ・セットはISO-8859-1です。前述の例では、キャラクタ・セットがUTF-8に設定されています。contentTypeページ・ディレクティブのキャラクタ・セットは、JSPエンジンに動的HTMLページのエンコードを指示し、HTTP Content-Typeヘッダーに指定のキャラクタ・セットを設定します。
Javaサーブレットの場合、サーブレットAPIのsetContentType()メソッドをコールして、HTTPヘッダー内のページ・エンコーディングを指定できます。次のdoGet()関数は、このメソッドをコールする方法を示しています。
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
// generate the MIME type and character set header
response.setContentType("text/html; charset=utf-8");
...
// generate the HTML page
Printwriter out = response.getWriter();
out.println("<HTML>");
...
out.println("</HTML>");
}
getWriter()メソッドは、setContentType()メソッド・コールで指定されたキャラクタ・セットを使用する出力ストリーム・ライターを初期化するので、getWriter()メソッドの前にsetContentType()メソッドをコールする必要があります。ライターに書き込まれ最終的にブラウザに書き込まれるすべてのHTMLコンテンツは、setContentType()コールで指定されたエンコーディングによってエンコードされます。
次の2種類の方法で、PL/SQLフロントエンド・アプリケーションとOracle PL/SQL Server Pages（PSP）にページ・エンコーディングを指定できます。
該当するデータベース・アクセス記述子（DAD）のNLS_LANGパラメータにページ・エンコーディングを指定します。この方法は、他のロケールをサポートするためにアプリケーション・コードを変更することなくページ・エンコーディングを変更できるので、単一言語アプリケーションに対して使用します。
PL/SQLプロシージャとPSPの内部からページ・エンコーディングを明示的に指定します。明示的に指定されたページ・エンコーディングによって、NLS_LANGキャラクタ・セットから引き継いだページ・エンコーディングが上書きされます。この方法は、実行時に個別のロケールに対応して別々のページ・エンコーディングを使用できるので、多言語アプリケーションに対して使用します。
指定されたページ・エンコーディングは、mod_plsqlモジュールとWeb Toolkitに対して、HTMLページのContent-Typeヘッダー内の該当するcharsetパラメータにタグを付けて、ページの内容を該当のキャラクタ・セットに変換することを指示します。
|
関連項目:
|
単一言語アプリケーションでNLS_LANGパラメータからページ・エンコーディングを取得するには、Content-Type HTTPヘッダーにページ・エンコーディングを指定しないでください。PL/SQLプロシージャでのmime_header()へのコールは、次のように記述する必要があります。
owa_util.mime_header('text/html',false);
PSPでは、コンテンツ・タイプ・ディレクティブを次のように記述する必要があります。
<%@ page contentType="text/html"%>
mime_header()関数コールまたはコンテンツ・タイプ・ディレクティブにページ・エンコーディングが指定されていない場合に、Web Toolkit APIは、デフォルトで NLS_LANGキャラクタ・セットをページ・エンコーディングとして使用し、HTMLコンテンツを NLS_LANGキャラクタ・セットに変換します。また、Web Toolkit APIは、Content-Typeヘッダーのcharsetパラメータにデフォルトのページ・エンコーディングを自動的に追加します。
多言語環境に対するPL/SQLでのページ・エンコーディングの指定
JSPページに指定するのと同じ方法で、PSPにページ・エンコーディングを指定できます。次に示すディレクティブは、このページのHTTP Content-Typeヘッダー内のページ・エンコーディングを設定するコードを生成するようにPSPコンパイラに対して指示します。
<%@ page contentType="text/html; charset=utf-8" %>
PL/SQLプロシージャ用のContent-Type HTTPヘッダー内のエンコーディングを指定するには、PL/SQLプロシージャのWeb Toolkit APIを使用します。Web Toolkit APIは、OWA_UTLパッケージで構成され、このパッケージを使用して、次のようにContent-Typeヘッダーを指定できます。
owa_util.mime_header('text/html', false, 'utf-8')
HTTPヘッダーのコンテキストでmime_header()関数をコールする必要があります。これによって、HTTPレスポンスに次のContent-Typeヘッダーが生成されます。
Content-Type: text/html; charset=utf-8
ページ・エンコーディングを指定すると、Web Toolkit APIはHTMLコンテンツを指定のページ・エンコーディングに変換します。
mod_perl環境で実行するPerlスクリプトの場合、HTMLページに対するエンコーディングをHTTP Content-Typeヘッダー内で次のように指定します。
$page_encoding = 'utf-8';
$r->ontent_type("text/html; charset=$page_encoding");
$r->end_http_header;
return OK if $r->eader_only;
|
関連項目: 『Oracle HTTP Server管理者ガイド』 |
単一言語アプリケーションに対するPerlでのページ・エンコーディングの指定
単一言語アプリケーションの場合、HTMLページのエンコーディングは、次のキャラクタ・セットと同一である必要があります。
Perlスクリプトを実行するPOSIXロケールで使用するキャラクタ・セット
Perlスクリプトがデータベースに接続する場合は、NLS_LANGパラメータで指定されたOracleキャラクタ・セット
多言語アプリケーションに対するPerlでのページ・エンコーディングの指定
多言語アプリケーションの場合、Perlスクリプトは次に示す環境で実行する必要があります。
NLS_LANGキャラクタ・セットとPOSIXロケールで使用するキャラクタ・セットが両方ともUTF-8である。
UTF8 Perlプラグマが使用されている。
このプラグマは、PerlインタプリタにUTF-8エンコーディングで識別子と文字列をエンコードするように指示します。
|
関連項目: 『Oracle HTTP Server管理者ガイド』 |
この環境では、あらゆる言語のデータをスクリプトがUTF-8で処理できます。ただし、スクリプトから生成された動的HTMLページのページ・エンコーディングは、UTF-8ではない可能性があります。その場合は、UNICODE::MAPUTF8 Perlモジュールを使用してUTF-8からページ・エンコーディングにデータを変換します。
次の例に、UNICODE::MAPUTF8 Perlモジュールを使用してShift_JISエンコーディングでHTMLページを生成する方法を示します。
use Unicode::MapUTF8 qw(from_utf8)
# This shows how the UTF8 Perl pragma is specified
# but is NOT required by the from_utf8 function.
use utf8;
...
$page_encoding = 'Shift_JIS';
$r->ontent_type("text/html; charset=$page_encoding");
$r->end_http_header;
return OK if $r->eader_only;
...
#html_lines contains HTML content in UTF-8
print (from_utf8({ -string=>$html_lines, -charset=>$page_encoding}));
...
from_utf8()関数は、動的HTMLコンテンツをUTF-8からcharset引数で指定されたキャラクタ・セットに変換します。
モバイル・サービス・アプリケーションのページ・エンコーディングは、他のJavaまたはJSPインターネット・アプリケーションと同様にそのアプリケーション内に指定されます。ページ・エンコーディングは、アプリケーションで生成されたMobile XMLのエンコーディングを指定します。ページ・エンコーディングは、Mobile XMLプロローグおよびHTTP Content-Typeヘッダーに一貫して指定する必要があります。次のHelloGlobe.jspアプリケーションに、Mobile XMLプロローグのページ・エンコーディングの指定方法を示します。
例4-1 HelloGlobe.jsp
<?xml version="1.0" encoding="UTF-8"?> (1) <%@ page contentType="text/vnd.oracle.mobilexml; charset=UTF-8"%> (2) <SimpleResult> <SimpleContainer> <SimpleForm title="Hello Globe" target="HelloGlobeReply.jsp" method="POST"> <SimpleFormItem name="UserName" title="Your Name:" /> </SimpleForm> </SimpleContainer> </SimpleResult>
この例では、行（1）でXMLプロローグにコンテンツ・エンコーディングを設定し、行（2）でHTTP Content-Typeヘッダーにコンテンツ・エンコーディングを設定しています。
Oracle Application Server Wirelessは、Mobile XMLを、XMLプロローグおよびHTTP Content-Typeヘッダーに指定したエンコーディング情報からターゲット・デバイスでサポートされているページ・エンコーディングに変換します。その後、ターゲット・デバイスでサポートされているマークアップ言語で、コンテンツをレンダリングします。XMLプロローグおよびHTTP Content-Typeヘッダーに指定したエンコーディングに一貫性がない場合、Oracle Application Server WirelessによるMobile XML変換は正常に実行されません。
Edge Side Include（ESI）の断片が、対応するESIテンプレートとは異なるページ・エンコーディングである場合、Oracle Web Cacheがその断片をテンプレートのページ・エンコーディングに変換します。これは、キャッシュされたページのコンテンツが複数のページ・エンコーディングで構成されないようにするためです。Oracle Web Cacheでのキャラクタ・セット変換は、テンプレートと断片の両方のページ・エンコーディングが認識されている場合にのみ実行されます。認識されていない場合、Oracle Web Cacheは、両方のページ・エンコーディングが同じであるとみなすため、断片を変換せずにテンプレートに埋め込みます。
Oracle Web Cacheは、HTTPレスポンスのContent-Typeヘッダー内でのみページ・エンコーディング情報を検索します。HTTPレスポンスのコンテンツ内のページ・エンコーディング情報は検索しません。
キャラクタ・セットをESIの断片からESIのテンプレートに変換しているときに情報が失われないようにするには、アプリケーションで、ESIテンプレートのページ・エンコーディングのサブセットであるESIの断片のページ・エンコーディングを使用する必要があります。開発者は、次のいずれかの方法でページ・エンコーディングを指定してください。
UTF-8をESIのテンプレートに対するページ・エンコーディングとして使用します。UTF-8は、他のすべての非Unicodeページ・エンコーディングのスーパーセットであるためです。
ESIの断片およびESIテンプレートに同じページ・エンコーディングを使用します。この場合、キャラクタ・セットの変換は実行されません。
様々なタイプのReports Servicesアプリケーションに使用するページ・エンコーディングは、作成するレポートのタイプによって異なります。この項では、Reports Servicesのページ・エンコーディング・オプションについて説明します。
JSPまたはHTMLのページ・エンコーディングは、Reports BuilderのWebソース・エディタによって指定できます。
ページ・ヘッダーにHTMLページ・エンコーディングを指定します。たとえば、日本語のキャラクタ・セットを指定する場合は、ページ・ヘッダーに次のタグを含めます。
<META http-equiv="Content-Type" content="text/html;charset=Shift_JIS">
このタグは、Reports Builderによって、Before Report ValueおよびBefore Form Valueプロパティを使用して各自のレポートに追加されます。これらのプロパティのデフォルト値は、次のような内容になります。
<html><head><meta http-equiv="Content-Type" content="text/html;charset=&Encoding"></head>
Oracle Reportsに対するNLS_LANG設定と同等のIANAロケール名が、実行時に&Encodingに動的に割り当てられます。したがって、適切なロケールを含めるために、各自のレポート設定またはOracle Reports設定を変更する必要はありません。
|
関連項目: 詳細はReports Builderのオンライン・ヘルプを参照してください。 |
通常、XMLを使用するときは、XML出力ファイルの最初の行にプロローグとして次のような文を挿入して、XMLのエンコーディングを指定します。
<?xml version="1.0" encoding="Shift_JIS"?>
レポートにこのプロローグを設定するには、レポートのXML Prolog Valueプロパティを指定するか、SRW.SET_XML_PROLOGビルトインを使用します。XML Prolog Valueプロパティのデフォルト値は次のとおりです。
<?xml version="1.0" encoding="&Encoding"?>
この場合は、NLS_CHARACTERSETに設定されている値が、XML仕様で想定されている値に変換されます。
|
注意: この対応関係は、REPORTS_NLS_XML_CHARSETに値を追加することで上書きできます。構文は次のとおりです。
例: ISO-8859-8=ISO-8859-8-1;CSEUCKR=EUC-KR;WINDOWS-949=EUC-KR;EUC-CN=GBK;WINDOWS-936=GBK |
|
関連項目: 詳細はReports Builderのオンライン・ヘルプを参照してください。 |
HTMLページに埋込み問合せ文字列を持つURLが含まれる場合は、%XXフォーマットの問合せ文字列のあらゆる非ASCIIバイトをエスケープする必要があります。XXとは、バイトのバイナリ値の16進表現です。たとえば、"Schloß,"というドイツ語の名前を含むUTF-8 JSPを指すURLをインターネット・アプリケーションに埋め込む場合、次のようにURLをエンコードする必要があります。
http://host.domain/actionpage.jsp?name=Schlo%c3%9f
このURLでは、c3と9fは、UTF-8エンコーディングにおけるßという文字の16進バイナリ値を示しています。
URLをエンコードする場合は、必ず次の作業を実施します。
URLをターゲット・オブジェクトで想定されるエンコーディングに変換します。このエンコーディングは通常、ユーザーのアプリケーションで使用されるページ・エンコーディングと同じです。
URLの非ASCIIバイトを%XXフォーマットにエスケープします。
大部分のプログラミング環境には、URLのエンコードおよびデコードを行うためのAPIがあります。次の項では、様々な環境でのURLエンコーディングについて説明します。
JSPまたはJavaサーブレットでURLを構成する場合は、8ビットのバイトを、パーセント符号を先頭に付けた16進値を使用してすべてエスケープする必要があります。JDK 1.4以降に含まれるURLEncoder.encode(String s, String enc)関数を使用すると、特定のHTMLページ・エンコーディングのURLをエスケープできます。2番目の引数のページ・エンコーディングに対応する、正しいJavaエンコーディング名を指定する必要があります。一般的なページ・エンコーディングのJavaエンコーディング名については、表4-1を参照してください。
JDK 1.3を使用している場合は、URLEncoder.encode(String s)関数のみを利用できます。この関数は、デフォルトのJavaエンコーディングのURLのみをエンコードします。他のエンコーディングのURLでこの関数を使用可能にするには、選択したエンコーディングに基づいて、URLの非ASCII文字を16進表現にエスケープするコードを追加する必要があります。
次のコードは、UTF-8エンコーディングに基づいてURLをエンコードする方法の例を示しています。
String unreserved = new String("/\\- _.!~*'()
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz 0123456789");
StringBuffer out = new StringBuffer(url.length());
for (int i = 0; i < url.length(); i++)
{
int c = (int) url.charAt(i);
if (unreserved.indexOf(c) != -1) {
if (c == ' ') c = '+';
out.append((char)c);
continue;
}
byte [] ba;
try {
ba = url.substring(i, i+1).getBytes("UTF8");
} catch (UnsupportedEncodingException e) {
ba = url.getBytes();
}
for (int j=0; j < ba.length; j++)
{
out.append("%" + Long.toHexString((long)(ba[j]&0xff)).toUpperCase());
}
}
String encodedUrl = out.toString();
Oracle Application Serverでは、UTL_URLパッケージのESCAPE()関数をコールしてPL/SQLでURLをエンコードできます。ESCAPE()関数は次のようにコールします。
encodedURL varchar2(100); url varchar2(100); charset varchar2(40); ... encodedURL := UTL_URL.ESCAPE(url, FALSE, charset);
url引数は、エンコードするURLです。charset引数は、エンコードされたURLに使用する文字エンコーディングを指定します。charset引数として妥当なOracleキャラクタ・セット名を使用してください。データベース・キャラクタ・セットでURLをエンコードするには、必ずcharset引数にNULLを指定します。
PerlでURLをエンコードするには、<Apache::Utilモジュールのescape_uri()関数を次のように使用します。
use Apache::Util qw(escape_uri); ... $escaped_url = escape_uri( $url ); ...
escape_uri()関数は、$url入力引数からバイトを取得し、%XXフォーマットにエンコードします。URLを別の文字エンコーディングでエンコードする場合は、escape_uri()関数をコールする前にURLをターゲットのエンコーディングに変換する必要があります。Perlでは、文字変換のためのモジュールがいくつか提供されています。
アプリケーションは、HTMLフォームを生成してユーザー入力を取得します。NetscapeおよびMicrosoft Internet Explorerブラウザの場合、入力のエンコーディングは必ずPOSTリクエストおよびGETリクエストの両方のフォームのエンコーディングと一致しています。フォームのエンコーディングがUTF-8である場合、ブラウザが返す入力テキストはUTF-8でエンコードされます。インターネット・アプリケーションは、情報をリクエストするHTMLフォームに対応するエンコーディングを指定することによって、フォーム入力のエンコーディングを制御できます。
ブラウザが入力をPOSTリクエストに渡す方法は、入力をGETリクエストに渡す方法と異なります。
POSTリクエストの場合、ブラウザは入力をRequest Bodyの一部として渡します。8ビットのデータを渡すことができます。
GETリクエストの場合、ブラウザは、すべての非ASCIIバイトが%XXとしてエンコードされる埋込み問合せ文字列をURLの一部として、入力情報を渡します。XXとは、バイトのバイナリ値の16進表現です。
HTML標準では、名前と番号が付与されたエンティティが許可されます。これらの特殊なコードによって、ユーザーは文字を指定することができます。たとえば、æとæは両方ともæという文字を指しています。これらのエンティティの表は、次のWebサイトを参照してください。
http://www.w3.org/TR/REC-html40/sgml/entities.html
ブラウザの中には、HTMLフォームのエンコーディングでエンコードできない入力文字に対して名前と番号が付与されたエンティティを生成するものがあります。たとえば、HTMLエンコーディングがBig5の場合、ユーロ文字および文字à（Unicode値はそれぞれ8364と224）はBig5エンコーディングでエンコードできないため、€およびàとして送信されます。ただし、HTMLフォームのページ・エンコーディングがUTF-8である場合、すべての文字がUTF-8でエンコード可能なので、ブラウザは番号または名前が付与されたエンティティを生成する必要がありません。UTF-8以外のページ・エンコーディングをサポートするインターネット・アプリケーションは、番号と名前が付与されたエンティティを処理できる必要があります。
ほとんどのJSPとサーブレット・コンテナの場合、サーブレットAPI実装では、受信フォーム入力がISO-8859-1エンコーディングであることが前提になっています。その結果、HttpServletRequest.getParameter() APIがコールされると、入力テキスト内に埋め込まれた%XXデータがすべてデコードされ、デコードされた入力がISO-8859-1からUnicodeに変換されてJava文字列として返されます。HTMLフォームのエンコーディングがISO-8859-1でない場合、返されるJava文字列が正しくありません。ただし、フォーム入力データを変換することによって、この問題を回避できます。JSPまたはJavaサーブレットがフォーム入力を受け取る場合、元のフォームにバイトで戻して元のフォームを適切なエンコーディングに基づくJava文字列に変換します。
次のコードは、Java文字列を適切なエンコーディングに変換しています。Java文字列のrealは、UTF-8フォームから適切な文字を保存するために初期化されます。
String original = request.getParameter("name");
try
{
String real = new String(original.getBytes("8859_1"),"UTF8");
}
catch (UnsupportedEncodingException e)
{
String real = original;
}
Javaエンコーディング名のほかにも、IANAエンコーディング名をJava関数の別名として使用できます。
OC4JはサーブレットAPI 2.3を実装しているので、 getParameter()関数をコールする前にHTTPリクエスト・オブジェクトのCharEncoding属性を設定することによって、適切な入力を取得できます。次のコードを使用します。
request.setCharacterEncoding("UTF8");
String real = request.getParameter("name");
ブラウザはフォーム入力をPL/SQLプロシージャの引数としてPL/SQLプロシージャに渡します。ブラウザがPOSTリクエストまたはGETリクエストを発行する場合、まず、リクエストするHTMLフォームのエンコーディングでフォーム入力をmod_plsqlモジュールに送信します。次に、mod_plsqlモジュールは、入力内のすべての%XXエスケープ・シーケンスを実際のバイナリ表現にデコードします。それから、リクエストに応えるPL/SQLプロシージャに入力を渡します。
VARCHAR2データ型でフォーム入力を受け入れるために使用するPL/SQL引数を構成する必要があります。VARCHAR2のデータは、常にデータベース・キャラクタ・セットでエンコードされます。たとえば、次のPL/SQLプロシージャは、VARCHAR2で2つのパラメータを受け入れます。
procedure test(name VARCHAR2, gender VARCHAR2) begin ... end;
mod_plsqlモジュールは、デフォルトで、PL/SQLプロシージャの引数をバインドするときに、PL/SQLプロシージャが VARCHAR2データ型であることを前提とします。VARCHAR2を引数データ型として使用することは、モジュールがOracleのライブラリに含まれるOracleキャラクタ・セット変換機能を使用して、フォーム入力データをユーザーのページ・エンコーディングでもあるNLS_LANGキャラクタ・セットからデータベース・キャラクタ・セットに変換することを意味します。該当するDADは、NLS_LANGキャラクタ・セットを指定します。その結果、VARCHAR2として渡された引数は、すでにデータベース・キャラクタ・セットでエンコードされ、PL/SQLプロシージャ内で使用する準備ができている状態になります。
単一言語アプリケーションを配置する場合、DADで指定されたNLS_LANGキャラクタ・セットは、ロケールとして選択されたフォーム入力とページ・エンコーディングのキャラクタ・セットと同じです。この結果、VARCHAR2引数として渡されたフォーム入力は、データベース・キャラクタ・セットに透過的に変換され、使用する準備ができている状態になります。
多言語アプリケーションを配置する場合、該当するロケールに対して、ユーザーが選択するページ・エンコーディングによって異なるキャラクタ・セットでフォーム入力をエンコードできます。フォーム入力のキャラクタ・セットは常にNLS_LANGキャラクタ・セットと同一であるとはかぎらないので、Oracleキャラクタ・セット変換機能を使用することはできません。この変換機能を使用すると、入力データが破損します。この問題を解決するには、データベース・キャラクタ・セットと同一のNLS_LANGキャラクタ・セットを該当するDADで指定して、Oracleキャラクタ・セット変換機能を無効化します。変換機能を無効化したら、PL/SQLプロシージャは、フォーム入力をVARCHAR2引数として受け取ります。引数を使用する前に、引数をフォーム入力エンコーディングからデータベース・キャラクタ・セットに変換する必要があります。次のコードを使用すると、引数をISO-8859-1キャラクタ・セットからUTF-8に変換できます。
procedure test(name VARCHAR2, gender VARCHAR2) begin name := CONVERT(name, 'AMERICAN_AMERICA.UTF8', AMERICAN_AMERICA.WE8MSWIN1252') gender := CONVERT(gender, 'AMERICAN_AMERICA.UTF8', AMERICAN_AMERICA.WE8MSWIN1252') ... end;
Oracle HTTP Serverのmod_perl環境では、GETリクエストは、POSTリクエストと異なる方法で、入力をPerlスクリプトに渡します。スクリプトで両方のタイプのリクエストを処理することをお薦めします。次のコードでは、nameパラメータの入力値をHTMLフォームから取得しています。
my $r = shift;
my %params = $r->ethod eq 'POST' ? $r->ontent : $r->rgs ;
my $name = $params{'name'} ;
多言語Perlスクリプトでは、HTMLフォームのページ・エンコーディングは、Perlスクリプトで使用されるUTF-8エンコーディングと異なる場合があります。この場合、処理前に入力データをページ・エンコーディングからUTF-8に変換する必要があります。次の例に、Unicode::MapUTF8 Perlモジュールが文字列をShift_JISからUTF-8に変換する方法を示します。
use Unicode::MapUTF8 qw(to_utf8);
# This is to show how the UTF8 Perl pragma is specified,
# and is NOT required by the from_utf8 function.
use utf8;
...
my $page_encoding = 'Shift_JIS';
my $r = shift;
my %params = $r->ethod eq 'POST' ? $r->ontent : $r->rgs ;
my $name = to_utf8({-string=>$params{'name'}, -charset=>$page_encoding});
...
Oracle Application Server Wireless Toolsの管理ツールを使用して、モバイル・サービスをOracle Application Server Wirelessに登録する場合は、サービスの入力エンコーディング・パラメータを指定する必要があります。Oracle Application Server Wirelessは、サービスの入力エンコーディング・パラメータに指定されたエンコーディングを使用してURLパラメータをエンコードします。モバイル・サービス・アプリケーションは、入力エンコーディング・パラメータと同じエンコーディングを使用して、ターゲットのモバイル・デバイスからの入力を解釈できるように作成する必要があります。次のHelloGlobeReply.jspの例に、サービスHelloGlobe.jsp（例4-1を参照）からのレスポンスの処理方法について示します。
例4-2 HelloGlobeReply.jsp
<%xml version="1.0" encoding="UTF-8"?>
<%@ page contentType="text/vnd.oracle.mobilexml; charset=UTF-8"%>
<%
request.setCharacterEncoding("UTF-8"); (1)
String name = request.getParameter("UserName");
%>
<SimpleResult>
<SimpleContainer>
<SimpleText>
<SimpleTextItem>Hello <%=name%> !</SimpleTextItem>
</SimpleText>
</SimpleContainer>
</SimpleResult>
この例では、行（1）で、UTF-8を使用してパラメータをエンコードすることを指定しています。
これは、HelloGlobe.jspのマスター・サービスの作成時に、入力エンコーディング・パラメータがUTF-8として指定されることを前提としています。モバイル・サービス・アプリケーションでは、ターゲット・デバイスから受信するすべての入力パラメータに同じエンコーディングを指定する必要があります。
Oracle Application Serverに固有のすべてのHTTPヘッダーでは、非ASCII文字を含むすべての値が、RFC 2047仕様に従ってMIMEタイプにエンコードされます。エンコードされたヘッダーは、アプリケーションで使用する前に適切にデコードする必要があります。Oracle Application Serverに配置されたアプリケーションがこれらのHTTPヘッダーを受信する場合があります。
アプリケーションがOracle Single Sign-Onを使用してユーザーを認証する場合、Oracle Single Sign-Onが送信するヘッダーをデコードする必要があります。エンコードされた非ASCII文字が値に含まれるヘッダーには、次のものがあります。
REMOTE_USER
Osso-User-Dn
Osso-Subscriber
Osso-Subscriber-Dn
OC4Jに配置されたJavaベースのWebアプリケーションの場合、REMOTE_USERヘッダーはHTTPServletRequest.getRemoteUser()メソッドですでに解析されており、REMOTE_USERヘッダーはHTTPリクエストから削除されています。他のタイプのWebアプリケーションの場合、REMOTE_USERヘッダーは存在していて、他のヘッダーとともに適切にデコードする必要があります。
ヘッダー値のデコードには、Java Mail APIのjavax.mail.internet.MimeUtilityパッケージを使用します。デコードの例は、「例4-3 ユーザーの表示名のデコード」を参照してください。
PL/SQLアプリケーションの場合は、ユーザーが独自のコードを作成してこれらのヘッダー値をデコードする必要があります。
ログイン・ユーザー名（X-Oracle-User.name）、ユーザーの表示名（X-Oracle-User.DisplayName）、ロケーションの住所行（X-Oracle.User.Location.AddressLine1）などの文字列型のモバイル・コンテキスト情報は、HTTPヘッダーにMIMEタイプでエンコードされます。アプリケーションは、それらをHTTPリクエストから取得した後、デコードする必要があります。例4-3に、JSPアプリケーションでユーザーの表示名を取得してデコードする方法を示します。
<@ page import="java.io.*" %>
<@ page import="javax.mail.internet.MimeUtility" %>
<%
String rawDisplayName = request.getHeader("X-Oracle-User.DisplayName");
String displayName = null;
try
{
displayName = MimeUtility.decodeText(rawDisplayName);
}
catch (UnsupportedEncodingException e)
{
// don't care
displayName = rawDisplayName;
}
%>
HTMLページに表示されるユーザー・インタフェース（UI）とコンテンツは、翻訳する必要があります。HTMLページのコンテンツの翻訳可能なソースは、次のカテゴリに属します。
HTML、イメージおよびカスケーディング・スタイル・シート（CSS）などの静的ファイル
JavaサーブレットとJSPで使用されるJavaリソース・バンドルとして保存された静的UI文字列
C/C++プログラムとPerlスクリプトで使用されるPOSIXメッセージ・ファイルとして保存された静的UI文字列
PL/SQLプロシージャおよびPL/SQL Server Pagesで使用されるデータベース内のリレーショナル・データとして保存された静的UI文字列
データベース内に保存された製品情報などの動的コンテンツ
この項の項目は次のとおりです。
翻訳可能なコンテンツを作成する場合、開発者は次の翻訳ガイドラインに従う必要があります。
Javaサーブレット、JavaServer Pages、Perlスクリプト、PL/SQLプロシージャおよびPL/SQL Server Pagesなどのプログラムで使用される静的かつ翻訳可能なUI文字列をすべてリソース・ファイルに外部化します。これらのリソース・ファイルは、プログラム・コードから独立して翻訳できます。
HTMLページ内のすべての動的テキストは、翻訳されたテキストが拡張されたときに隣のオブジェクトと重ならないように、30%以上拡張できるようにする必要があります。HTMLページは、文字列が30%拡張されても問題なく表示されるようにする必要があります。
実行時に文を構成して、文字列の連結を回避します。連結され翻訳された文字列は、元の文字列と同じ意味にならないことがあります。各種プログラミング言語に提供されている文字列書式関数を使用して、実行時の値をプレースホルダとして代入します。
JavaScriptコードには、翻訳可能な文字列を記述しないでください。JavaScriptは翻訳が困難です。そのかわりに、アプリケーションは、翻訳可能な文字列がある場合は、その文字列をリソース・ファイルやメッセージ表に外部化する必要があります。アプリケーションは、JavaScriptコードを実行時に構成し、動的テキストをユーザーのロケールに対応するテキストに置き換える必要があります。
アプリケーションの初期のリリースでは翻訳が使用できないことが多いので、該当する翻訳が使用できないときにアプリケーションが機能するようにアプリケーションに代替メカニズムを組み込むことが重要です。代替メカニズムは、英語の情報を使用するという簡単な方法か、または、使用可能な最も類似した言語を使用するという複雑な方法を取ることができます。たとえば、fr-CAロケールはフランス語（カナダ）です。この言語を代替する場合、fr（フランス語）またはen（英語）になります。最も類似した使用可能な言語は、ISOロケール名の地域の部分を取り除いた部分が同じものです。代替メカニズムの動作は、アプリケーションによって異なります。
翻訳用のロケール固有のディレクトリ下にファイルをzipできるように、翻訳可能でない静的ファイルの入ったディレクトリとは別のディレクトリに、翻訳可能なHTML、イメージおよびCSSファイルを構成する必要があります。ディレクトリ構造を定義してそれらのファイルを保存するには、数多くの方法があります。たとえば、次のように設定します。
/docroot/images - Non-translatable images /docroot/html - HTML pages common to all languages /docroot/css - Style sheets common to all languages /docroot/lang- Locale directory such as en, fr, ja, and so on. /docroot/lang/images - Images specific forlang/docroot/lang/html - HTML pages specific forlang/docroot/lang/css - Style sheets specific forlang
<lang>プレースホルダをISOロケール名で置換できます。前述の構造に基づいて、URLをパラメータとして受け取り、この構造から使用可能な言語ファイルを検索するgetLocalizedURL()というユーティリティ関数を記述する必要があります。HTMLページでHTML、イメージまたはCSSファイルを参照するたびに、インターネット・アプリケーションからこの関数をコールして、現行のロケールに該当する翻訳済ファイルのパスを構成し、翻訳がない場合は適切な代替策を実行する必要があります。たとえば、パス/docroot/html/welcome.htmlがgetLocalizedURL()関数に渡され、現行のロケールがfr_CAである場合、関数は次の順番でファイルを検索します。
/docroot/fr_CA/html/welcome.html /docroot/fr/html/welcome.html /docroot/en/html/welcome.html /docroot/html/welcome.html
関数は最初に検索されたファイルを返します。この関数は、現行のロケールに該当する翻訳済のバージョンがない場合には必ず英語に戻ります。
UTF-8をページ・エンコーディングとして使用するインターネット・アプリケーションの場合、静的HTMLファイルのエンコーディングもUTF-8である必要があります。ただし、通常、翻訳者は翻訳されたHTMLファイルをターゲット言語のシステム固有のエンコーディングでエンコードします。翻訳されたHTMLをUTF-8に変換するには、Oracle Application Serverに添付されているJDK native2asciiユーティリティを使用します。
たとえば、次の手順では、Shift_JISでエンコードされている日本語のHTMLファイルをUTF-8に変換する方法を示します。
<meta>タグ内のContent-Type HTMLヘッダー内のcharsetパラメータ値をUTF-8に置換します。
native2asciiユーティリティを使用して、日本語のHTMLファイルをjapanese.unicodeという名前の新しいファイルにコピーします。
native2ascii -encoding MS932 japanese.html japanese.unicode
native2asciiユーティリティを使用して、新ファイルをUnicodeに変換します。
native2ascii -reverse -encoding UTF8 japanese.unicode japanese.html
JavaサーブレットとJSP内の翻訳可能な文字列をJavaリソース・バンドルに外部化して、これらのリソース・バンドルがJavaコードから独立して翻訳できるようにする必要があります。翻訳後、リソース・バンドルは英語のバンドルと同じベース・クラス名になりますが、Javaロケール名が接尾辞として付けられます。英語のリソース・バンドルと同じディレクトリにバンドルを配置して、Javaリソース・バンドルの参照メカニズムが正常に機能するようにする必要があります。
JSP文字列のリソース・バンドルへの外部化については、JSPの使用目的を無視しているように見えるので、ちゅうちょする人もいます。JSP文字列の外部化には2つの理由があります。
JSPの翻訳は、翻訳者にとってなじみのないJavaコードで構成されているため、誤りが発生しやすい傾向があります。
翻訳プロセスを開発プロセスと切り離して、翻訳をJSPの開発と並行して実施できるようにする必要があります。これによって、翻訳されたJSPを埋込み型Javaコードのエラーが修正された最新のJSPにマージする作業が大幅に軽減されます。
Javaプログラムでリソース・バンドルを使用するには、ResourceBundleクラスのサブクラスを独自に指定します。さらに、JavaではResourceBundle抽象クラスの2つのサブクラス、ListResourceBundleとPropertyResourceBundleを利用できます。ResourceBundleクラスの実装は、ListResourceBundleのサブクラスにすることをお薦めします。主な理由は次のとおりです。
リスト・リソース・バンドルは、基本的にはコンパイルが必要なJavaプログラムです。コンパイル時に翻訳のエラーを見つけることができます。プロパティ・リソース・バンドルは、Javaから直接読み込まれるテキスト・ファイルです。翻訳のエラーは、実行時にのみ見つけることができます。
プロパティ・リソース・バンドルは、インターネット・アプリケーション内のすべての文字列データをユーザーに公開します。アプリケーションに対してセキュリティとサポートの問題が発生する可能性があります。
次に、リスト・リソース・バンドルの例を示します。
import java.util.ListResourceBundle;
public class Resource extends ListResourceBundle {
public Object[][] getContents() {
return contents;
}
static final Object[][] contents =
{
{"hello", "Hello World"},
...
};
}
翻訳者は通常、ターゲット言語のシステム固有のエンコーディングでリスト・リソース・バンドルを翻訳します。Shift_JISでエンコードされた日本語のリスト・リソース・バンドルは、Javaコンパイラでソース・ファイルがISO-8859-1でエンコードされていることを想定しているので、英語のシステムではコンパイルできません。翻訳されたリスト・リソース・バンドルをプラットフォームに依存しない方法でビルドするには、JDKのnative2asciiユーティリティを実行して、非ASCII文字を\uXXXX書式のUnicodeエスケープ・シーケンスにエスケープする必要があります。XXXXは、Unicodeの16進値です。たとえば、次のように設定します。
native2ascii -encoding MS932 resource_ja.java resource_ja.tmp
翻訳されたリソース・バンドルが使用できない場合、Javaには、リソース・バンドルに対するデフォルトの代替メカニズムが提供されています。アプリケーションは、ロケールの接尾辞が付けられていないベースのリソース・バンドルが必ず同じディレクトリに存在することを確認するだけです。ベースのリソース・バンドルには、代替言語の文字列が含まれている必要があります。たとえば、fr_CAJavaロケールがgetBundle()関数に指定されている場合、Javaはリソース・バンドルを次の順番で参照します。
resource_fr_CA resource_fr resource_en_US /* where en_US is the default Java locale */ resource_en resource (base resource bundle)
単一言語アプリケーションでの文字列の取得
実行時に、単一言語アプリケーションは文字列をデフォルトのJavaロケールのリソース・バンドルから次のように取得します。
ResourceBundle rb = ResourceBundle.getBundle("resource");
String helloStr = rb.getString("hello");
多言語アプリケーションでの文字列の取得
多言語アプリケーションではユーザーのロケールが固定されていないため、getBundle()メソッドをコールしてユーザーのロケールに対応するJavaロケール・オブジェクトを明示的に指定する必要があります。次の例では、Javaロケール・オブジェクトはuser_localeという名前です。
ResourceBundle rb = ResourceBundle.getBundle("resource", user_locale);
String helloStr = rb.getString("hello");
UNIXプラットフォームで実行するC/C++プログラムとPerlスクリプトの場合、C/C++またはPerlスクリプトの静的文字列をPOSIXのメッセージ・ファイルに外部化します。Microsoft Windowsプラットフォームで実行するプログラムの場合、Microsoft WindowsではPOSIXのメッセージ・ファイルをサポートしていないので、静的文字列をデータベース内のメッセージ表に外部化します。
POSIXロケールに関連付けられたメッセージ・ファイル（.poファイル拡張子が付いている）は、ドメイン名で識別されます。メッセージ・ファイルは、.moというファイル拡張子が付いたバイナリ・オブジェクトにコンパイルして、POSIXロケールに対応するディレクトリに配置する必要があります。POSIXロケールのパス名は、実装方法によって異なります。たとえば、Solaris msgfmtユーティリティは、フランス語（カナダ）のメッセージ・ファイルresource.poをコンパイルして、Solaris上の/usr/lib/locale/fr_CA/LC_MESSAGESディレクトリに配置します。
|
関連項目: gettext、msgfmtおよびxgettextについては、オペレーティング・システムのドキュメントを参照してください。
|
次に、resource.poメッセージ・ファイルの例を示します。
domain "resource" msgid "hello" msgstr "Hello World" ...
メッセージ・ファイルに使用するエンコーディングは、対応するPOSIXロケールに使用するエンコーディングと一致する必要があります。
バイナリ・メッセージ・ファイルを実装に固有のディレクトリに配置するのではなく、アプリケーション固有のディレクトリに配置し、ドメインをディレクトリに関連付けるbinddomain()関数を使用する必要があります。次のPerlスクリプトでは、POSIXのメッセージ・ファイルから文字列を取得するLocale::gettext Perlモジュールを使用しています。
use Locale::gettext; use POSIX; ... setlocale( LC_ALL, "fr_CA" ); textdomain( "resource" ); binddomain( "resource", "/usr/local/share"); print gettext( "hello" );
リソース・ファイルのドメイン名はresource、取得対象の文字列IDはhello、使用する翻訳はフランス語（カナダ）（fr_ca）、binary.moファイルのディレクトリは/usr/local/share/fr_CA/LC_MESSAGESです。
メッセージ表には、主に、PL/SQLプロシージャとPSPで使用する静的な翻訳可能文字列が保存されます。メッセージ表は、一部のC/C++プログラムとPerlスクリプトで使用することも可能です。表には静的文字列の言語を指定する言語列があるので、アプリケーションにアクセスするときにユーザーのロケールに基づいてメッセージを取得できます。表は、次のような構造にする必要があります。
CREATE TABLE messages ( msgid NUMBER(5) , langid VARCHAR2(10) , message VARCHAR2(4000) );
この表の主キーは、msgidおよびlangid列で構成されています。これらの列の値に、対応するロケールのOracle言語の略称を選択することをお薦めします。Oracle言語の略称を使用することによって、アプリケーションがメッセージ表にクエリーを発行して、翻訳された情報を透過的に検索できます。
|
関連項目: Oracle言語の略称のリストは、Oracle Databaseドキュメント・ライブラリ内の『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
メッセージの翻訳が使用できない場合に代替メカニズムを提供するには、前述の例で定義したメッセージ表の先頭に次のビューを作成します。
-- fallback language is English which is abbreviated as 'US'.
CREATE VIEW default_message_view AS
SELECT msgid, message
FROM messages
WHERE langid = 'US';
/
-- create view for services, with fall-back mechanism
CREATE VIEW messages_view AS
SELECT d.msgid,
CASE WHEN t.message IS NOT NULL
THEN t.message
ELSE d.message
END AS message
FROM default_view d,
translation t
WHERE t.msgid (+) = d.msgid AND
t.langid (+) = sys_context('USERENV', 'LANG');
メッセージは、英語の代替メッセージに対する論理を備えたmessages_viewビューから検索するために、default_message_viewビューをmessages表に結合します。sys_context() SQL関数は、現行データベース・セッションのロケールのOracle言語の略称を返します。セッションの作成時は、このロケールをユーザーのロケールに初期化します。
メッセージを検索するには、アプリケーションで次のクエリーを使用します。
SELECT message FROM message_view WHERE msgid = 'hello';
データベース・セッションのNLS_LANGUAGEパラメータは、クエリーが検索するメッセージの言語を定義します。このメッセージ表のスキーマではクエリーに関する言語情報は必要ありません。
データベースへのロードを最小化するためには、すべてのメッセージ表とOracle Application Serverのインスタンスの関連ビューを、PL/SQLプロシージャおよびPSPが実行されるデータベースのフロントエンドとして設定する必要があります。
アプリケーション・スキーマには、アプリケーションで使用する製品名や製品説明など、翻訳可能な動的情報が保存されます。次の例は、インターネット店舗のすべての製品を格納する表を示しています。表の翻訳可能な情報は、製品名と製品説明です。
CREATE TABLE product_information
( product_id NUMBER(6)
, product_name VARCHAR2(50)
, product_description VARCHAR2(2000)
, category_id NUMBER(2)
, warranty_period INTERVAL YEAR TO MONTH
, supplier_id NUMBER(6)
, product_status VARCHAR2(20)
, list_price NUMBER(8,2)
);
製品名と製品説明を他の言語で格納するには、主キーがproduct_idとlanguage_id列で構成された次の表を作成します。
CREATE TABLE product_descriptions
( product_id NUMBER(6)
, language_id VARCHAR2(3)
, translated_name NVARCHAR2(50)
, translated_description NVARCHAR2(2000)
);
ユーザーが要求する言語で情報を使用できない場合は代替言語を提供するために、ビューを表の先頭に作成します。たとえば、次のように設定します。
CREATE VIEW product AS
SELECT i.product_id
, d.language_id
, CASE WHEN d.language_id IS NOT NULL
THEN d.translated_name
ELSE i.product_name
END AS product_name
, i.category_id
, CASE WHEN d.language_id IS NOT NULL
THEN d.translated_description
ELSE i.product_description
END AS product_description
, i.warranty_period
, i.supplier_id
, i.product_status
, i.list_price
FROM product_information i
, product_descriptions d
WHERE d.product_id (+) = i.product_id
AND d.language_id (+) = sys_context('USERENV','LANG');
このビューは、product_informationおよびproduction_description表で外部結合を実行して、現行データベース・セッションのOracle言語の略称に相当するlanguage_idの行を選択します。
製品ビューから製品名と製品説明を検索するには、アプリケーションで次のクエリーを使用する必要があります。
SELECT product_name, product_description FROM product
WHERE product_id = '1234';
このクエリーは、NLS_LANGUAGEセッション・パラメータの値に対応する翻訳された製品名と製品説明を検索します。クエリーにはセッション言語を返すsys_context ('USERENV', 'LANG')が使用されるため、クエリーに言語情報を指定する必要はありません。
