マルチバイト環境での使用にあたって
 |
 |
 |
|
WebLogic Server の国際化 (I18n) の基本的な特徴は以下のようになります。
WebLogic Server を使ってマルチバイトの文字情報を扱う分散システムを構築する際には、Java および J2EE 特有のエンコーディングの指定方法を十分に理解する必要があります。それに加えて、OS、インターネット、バックエンド システムなど、WebLogic Server と接続するシステムのエンコーディングの扱いを十分に検討した上で、エンコーディング コンバージョンを正しくコントロールする必要があります。
それぞれの特徴を簡単に説明します。
WebLogic Server は 100% pure Java アプリケーション サーバ プログラムです。サーバ内部のエンコーディングには Unicode を使用しています。
WebLogic Server は Unicode で扱える文字ならばどんな言語の文字でも同時に扱うことが可能です。
WebLogic Server の外部と文字データのやり取りをする際にはエンコーディングのコンバージョンが発生します。
通常の OS では、Java の内部コードである Unicode で動作する環境はほとんどありません。ネイティブ エンコーディングと呼ばれる、個別のプラットフォームで個別に定義されたエンコーディングで動作します。例えば Windows であれば言語に応じたコード ページ、UNIX では LANG 環境変数により指定されたロケールに応じたエンコーディング、データベースであればデータベースを作成する際に指定したキャラクタ セットやクライアントのキャラクタ セットなどがネイティブ エンコーディングに相当します。
このため、WebLogic Server で文字の入出力をする際に、ネイティブ エンコーディングの文字と Unicode との間でエンコーディングを相互にコンバージョン (キャラクタ セットの変換) する必要があります。このエンコーディングのコンバージョンは OS や外部リソースとのキャラクタ データの入出力の際に常に発生します。
注意: Java クラスをシリアライズしたストリームに含まれる文字は Unicode のまま (UTF-8 でエンコード) されてクラスの内部情報として保持されているため、コード コンバージョンは考慮する必要ありません。例えば EJB や RMI では通常エンコーディングについて考慮する必要はありません。
また、エンコーディングのコンバージョンは文字 1 つずつに対して個別に全て行わなければならないため比較的大きな CPU リソースを必要とします。アプリケーション設計の際には、コード コンバージョンをなるべく減らす工夫がよりよいパフォーマンスにつながります。
WebLogic Server はサーバ本体のエンコーディング コンバージョンと、アプリケーション コンポーネントや WebLogic Server 上のリソースのエンコーディング コンバージョンを分離しています。
WebLogic Server はどんな言語のコンテンツをサービスしていようとも、サーバ本体のログのエンコーディングや、管理コンソールのエンコーディングはアプリケーション コンポーネントとは関係なく、サーバ本体の JavaVM のデフォルト エンコーディングやブラウザの言語設定により動作します。
また、あるアプリケーション コンポーネントを WebLogic Server にデプロイすると、どんなロケール (言語) の環境で動作する WebLogic Server であっても、全く同じ動作をするようにコンフィグレーションすることが可能です。
JDBC コネクション プールなど、WebLogic Server コンテナ上でコンフィグレーションされるリソースに対してもリソース毎に個別にエンコーディング コンバージョンのための設定をすることができます。
WebLogic Server 本体のエンコーディング コンバージョンとして以下のものがあります。
アプリケーション パッケージ個別のコンバージョンとして以下のものがあります。
WebLogic Server 上のリソースとしては以下のものがあります。
そこで、WebLogic Server 上でエンコーディングを指定する場合には、その指定は上記 3 つのカテゴリのどこに対して指定しているのかを明確にする必要があります。その上で、WebLogic Server 内に正しい Character オブジェクトが作れるか、もしくは WebLogic Server 内の Character オブジェクトが希望のエンコーディングの文字に変換されて出力されるか、常に意識する必要があります。
このように、WebLogic Server 上でマルチバイト文字を扱う場合には、エンコーディング コンバージョンの働きを一通り理解し、必要に応じて設定を行う必要があります。エンコーディング コンバージョンの設定をしなければアプリケーションは正しくマルチバイト文字を扱えない場合があります。
いずれの場合においてもエンコーディングを指定しない場合は何らかのデフォルトのエンコーディングが使用されます。デフォルトのエンコーディングはそれぞれの仕様や、環境により異なる場合があります。
WebLogic Server の動作に関係するデフォルトのエンコーディングとして一例をあげると次のような種類があります。
例:
このように技術仕様によってデフォルトのエンコーディングが異なるため、エンコーディングに関する指定を全くしない場合は、WebLogic Server ではマルチバイトを正しく扱うことができません。次章以降の個別のエンコーディングの指定方法をよくご理解いただいた上でエンコーディングのコンバージョンをコントロールしてください。
エンコーディングという言葉は Java で使われているキャラクタ セットのことですが、この言葉は場合によっていくつかの異なる呼び名があり、それぞれ若干定義が異なるので注意が必要です。
Java でのエンコーディングやインターネット上でキャラクタ セットと呼ばれているものは、特定の言語の文字をコンピュータ上で扱えるように、その文字のまとまりをコンピュータのコードに割り当てた定義のことです。
Java はこれらの違いを入出力部分で吸収し、内部では常に Unicode で扱います。このためエンコーディングの定義さえあればどんなキャラクタ セットでも扱うことができる優れた特徴をもっています。つまり、Java はさまざまなシステム間に存在するエンコーディングの違いを全て吸収できる可能性を持った言語であると言えます。しかしながら、現状では細かなエンコーディングの違い全てに対応したエンコーディング変換テーブルは存在しません。また既に存在するエンコーディング テーブルにも Unicode との整合性からいくつか制限があります。
Java Web アプリケーション サーバで特に重要なのは Java のエンコーディング名と、Internet や XML で使用される IANA で定義された MIME キャラクタ セットの違いです。WebLogic Server ではこの違いを吸収するため、Java エンコーディング名と IANA のキャラクタ セットとの名前のマッピング テーブル (WebLogic Server で既に定義している MIME-Java エンコーディング マップを参照) を持っています。これにより、例えば JSP 上では Shift_JIS として定義したファイルを Java の SJIS として扱うことができます。 また、Web コンポーネントに対しては、この WebLogic Server システムのマッピング テーブルを変更して、例えば 'Shift_JIS' という IANA キャラクタ セット名を 'cp943' という Java エンコーディングとして扱うことも可能です (HTTP レスポンスに関する Java エンコーディングと IANA キャラクタ セットのマッピングの変更 (J2EE非互換) を参照)。
WebLogic Server 組み込みの XML パーサである xerces では独自に IANA と Java のマッピング テーブルを持っています。これはユーザ側でカスタマイズすることはできません。例えば IANA の charset 名の Shift_JIS は Java のエンコーディング名の SJIS にマップされています。
WebLogic Server では基本的に Java のエンコーディング名でエンコーディングを設定するようになっています。また、J2EE、Internet、XML では IANA キャラクタ セット名を使用します。必要に応じてこのマッピングの変更を行ってください。
WebLogic Server は様々な有効範囲でエンコーディングを指定することができます。例えば JSP では JSP2.0 仕様に準拠したページ毎のエンコーディングの指定を行う page タグがあります。このように特定の有効範囲毎に指定するエンコーディングは、WebLogic Server が動作する JavaVM のデフォルトのエンコーディング (JavaVM の内部実装が、動作するプラットフォームのロケール環境から決定するエンコーディング) とは関係がありません。JavaVM が英語のロケールであっても、マルチバイト文字を含んだ JSP ファイルを使ったサービスをすることには何ら問題ありません。しかしながら以下の項目については JavaVM のデフォルトのエンコーディングに依存して文字列を取り扱います。
これらは JavaVM のデフォルトのエンコーディングで動作します。プラットフォームのロケールを切り替えることで WebLogic Server のログメッセージの言語、エンコーディングを切り替えたい場合は以下のように指定します。なお、JavaVM のデフォルトのエンコーディングは VM の起動後に動的に切り替えることはできません。以下の設定を確認した後で WebLogic Server を再起動してください。
[コントロール パネル｜地域 (または地域のオプション)] から [英語 (U.S.)] または [日本語]、[韓国語]、[中国語 (中国)]、[中国語 (台湾)] などを選択します。これにより、サーバは CP1252 または MS932、MS949、GBK、MS950 などをデフォルトのエンコーディングとして動作します。
LANG 環境変数にプラットフォームでサポートするロケールを指定します。
サーバのエンコーディングと LANG 環境変数の例として、一部を以下の表にまとめます。その他は、お使いのプラットフォームのマニュアル等でご確認ください。
| プラットフォーム | エンコーディング | LANG 環境変数 |
|---|---|---|
| Solaris | EUC-JP、SJIS | ja または ja_JP.eucJP、ja_JP.PCK |
| Solaris | EUC-KR | ko または ko_KR |
| Solaris | GB2312、GBK | zh_CN または zh_CN.GBK |
| Solaris | GB18030 | zh_CN.GB18030 |
| Solaris | Big5 | zh_TW.BIG5 |
| HP | EUCJIS、SJIS | ja_JP.eucJP、ja_JP.SJIS |
| HP | EUC-KR | ko.eucKR または ko_KR |
| HP | GB2312 | zh_CN.hp15CN |
| HP | GB18030 | zh_CN.gb18030 |
| HP | Big5 | zh_TW.big5 |
たとえば、Solaris で EUC-JP を指定する場合は次のようになります。
LANG=ja
ドメイン内の全ての WebLogic Server のエンコーディングは同じものを使用します。
WebLogic Server では、ドメイン内の全てのサーバは同一エンコーディングに設定する必要があります。
例えば、ドメイン内に Windows プラットフォームが存在する場合、ドメインを MS932 エンコーディングで統一します。エンコーディングの異なるサーバがあった場合、そのサーバのログは正しく表示する事ができません。
クラスタ内の全ての WebLogic Server のエンコーディングは同じものを使用します。
WebLogic Server では、クラスタ内の全てのサーバは同一エンコーディングに設定する必要があります。
例えば、クラスタ内に Windows プラットフォームが存在する場合、ドメインを MS932 エンコーディングで統一します。エンコーディングの異なるサーバがあった場合、そのサーバのログは正しく表示する事ができません。
config.xml ファイルは UTF-8 で入出力します。テキスト エディタなどで直接 config.xml ファイルを編集する場合は、UTF-8 で読込み/保存してください。
JDBC コネクション プールを作成する場合、マルチバイトを扱う DB への接続にはエンコーディングの指定を正しく行う必要があります。また、構築するシステムの要件によっては、エンコーディング コンバージョン マッピングを Web 層と DB 層で合わせる必要があります。
WebLogic Server では、J2EE コンポーネントの DD ファイルのマルチバイト文字は XML 宣言に従って扱います。XML 宣言がない場合、もしくは XML 宣言があっても encoding 属性がない場合はファイルを UTF-8 として扱います。
管理コンソールを起動したときに表示される言語は、お使いの Web ブラウザの言語プロパティで指定している言語になります。例えば、日本語 Windows で動作する IE で特に設定を変更していなければ、管理コンソールを起動すると、日本語で表示されます。表示を英語にする場合は、ブラウザの言語設定を「英語」にし、他の言語のリストを全て削除してください。なお、管理コンソールの出力エンコーディングは、全ての言語で UTF-8 に統一されています。
WebLogic Serverでは、電子メールの送信の実装にJavaMailを使用しています。したがって、JavaMail用のシステムプロパティmail.mime.charsetをWebLogic Serverの起動オプションに加えることにより、送信される電子メールのエンコーディングを変更することができます(このプロパティを省略した場合は、JavaVMのデフォルトのエンコーディングが使用されます)。
例:
-Dmail.mime.charset=ISO-2022-JP
なお、WebLogic Serverから電子メールを送信する場合の典型的な例として、システム管理における診断サービスの通知にSMTPを使用した場合などが挙げられます。
国際化の概要で述べたとおり、WebLogic Server は全ての文字列を内部的に Unicode で扱いますが、外部リソースとのキャラクタ データの入出力でエンコーディング コンバージョンが発生します。ここでは、アプリケーション プログラミングの観点で、マルチバイト文字を処理する上での注意点をトピックとして扱います。
WebLogic Server では RFC3280 に基づいて、公開鍵証明書で UTF-8 エンコーディングをサポートしています。RFC3280 の詳細については、Internet X.509 Public Key Infrastructure: Certificate and CRL Profile を参照して下さい。
Web コンポーネントでは、WebLogic Server から見たエンコーディング コンバージョンが発生する外部リソースは、HTTP プロトコルとなります。HTTP プロトコル上のメッセージは、様々なエンコーディングで送信することができるように仕様が規定されています。このため、サーバ内部で扱われる Unicode 文字列と、HTTP プロトコル上の特定のエンコーディングでエンコードされたメッセージとの間のエンコーディング コンバージョンを、Web コンポーネントとしてどう扱うかは非常に重要な問題です。この問題に対し、エンコーディング コンバージョンのための設定が、J2EE の仕様や WebLogic Server 独自の仕様により、いくつかの API やパラメータとして用意されています。これからの説明をよくご理解の上、構築するシステムの要件に合わせて最も適切な設定を組み合わせてください。
J2EE の Web コンポーネントに関連するエンコーディングの設定対象は以下になります。
J2EE の仕様では、これらの設定対象を省略した場合のデフォルト エンコーディングを定義しています。各コンポーネントのデフォルト エンコーディングは以下のようになります。
| コンポーネント名 | デフォルト エンコーディング |
|---|---|
| Servlet | ISO-8859-1 |
| JSP | ISO-8859-1 |
| XML 形式 JSP Document | UTF-8 |
| Tag ファイル | ISO-8859-1 |
| XML 形式 Tag ファイル | UTF-8 |
このように、XML 形式のコンポーネント以外では、デフォルト エンコーディングとして ISO-8859-1 エンコーディングが使用されるため、マルチバイト文字を使用する場合は、エンコーディングの設定が必須となります。以下、Web コンポーネント毎に設定の詳細を表にまとめて説明します。表の各カラムの意味は以下のとおりです。
Servlet のレスポンスのエンコーディング指定には以下の 3 つの方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| ServletResponse#setContentType メソッド | HTTP レスポンス毎 | Charset 属性 (IANA 名) 付きの MIME タイプ | YES | 1 |
setContentType("text/html;charset=Shift_JIS");
|
| ServletResponse#setCharacterEncoding メソッド | HTTP レスポンス毎 | IANA 名 | YES | 1 |
setCharacterEncoding("EUC-JP");
|
| ServletResponse#setLocale メソッド | HTTP レスポンス毎 | ロケール名 (注 1) | YES | 2 |
setLocale(ja);
|
注 1: ロケール名から決まる IANA 名により、エンコーディングが決定されます。ロケールと IANA 名のマップについては、Locale から IANA へのマップを参照してください。
なお、これらのメソッドは以下のように、Writer を取得する前に呼び出す必要があります。
res.setContentType("text/html;charset=Shift_JIS");
PrintWriter out = res.getWriter();
JSP のレスポンスのエンコーディング指定には以下の 5 つの方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| Page ディレクティブの contentType 属性 | ファイル毎 | Charset 属性 (IANA 名) 付きの MIME タイプ | YES | 1 |
<%@ page contentType="text/html; charset=EUC-JP" %>
|
| web.xml の page-encoding 要素 | 指定の URL パターン内 | IANA 名と URL パターン | YES | 2 |
<jsp-config>
|
| Page ディレクティブの pageEncoding 属性 | ファイル毎 | IANA 名 | YES | 2 (注 1) |
<%@ page pageEncoding="Windows-31J" %>
|
| weblogic.xml の encoding 要素 (非推奨) | Web アプリケーション全体 | Java エンコーディング名 | NO | 3 |
<jsp-descriptor>
|
| weblogic-application.xml の application-param 要素内の webapp.encoding.default パラメータ (注 2) | エンタープライズ アプリケーション全体 | IANA 名 | NO | 4 |
<application-param>
|
注 1: JSP2.0 の仕様により、web.xml の page-encoding 要素と page ディレクティブの pageEncoding 属性が異なると、JSP のコンパイル時にエラーとなります。その結果として、両者の優先度は同じになります。
注 2: ここで設定した値は、JSP がコンパイルされた Servlet コード内の ServletResponse#setContentType メソッドの引数に反映されます。したがって、webapp.encoding.default を変更した場合、変更を有効にするには、エンタープライズ アプリケーション全体の JSP ファイルを再ビルドする必要があります。
JSP Document のレスポンスのエンコーディング指定には以下の方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| Page ディレクティブの contentType 属性 | ファイル毎 | Charset 属性 (IANA 名) 付きの MIME タイプ | YES | 1 |
<jsp:directive.page contentType="text/html; CHARSET=euc-jp"/>
|
HTTP リクエストのエンコーディングを指定する方法として、最も HTTP 仕様に即したものは、HTTP リクエストの ContentType ヘッダの charset 属性にキャラクタ セットを記述することです。これにより、受け取り側の WebLogic Server は正しく HTTP リクエストのエンコーディングをプロトコルベースで認識することができます。しかし、マイクロソフトの IE、およびネットスケープ ブラウザ等の主要な Web ブラウザは、この値を指定することはできません。このため、HTTP リクエストのエンコーディングの指定も WebLogic Server 側で設定することになります。
リクエストのエンコーディングの設定は、JSP/Servlet で共通で、以下の 3 つの方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| ServletRequest#setCharacterEncoding メソッド | HTTP リクエスト毎 | IANA 名 | YES | 1 |
setCharacterEncoding("EUC-JP");
|
| weblogic.xml の input-charset 要素 | 指定の URL パターン内 | Java エンコーディング名と URL パターン | NO | 2 |
<charset-params>
|
| weblogic-application.xml の application-param 要素内の webapp.encoding.default パラメータ | エンタープライズ アプリケーション全体 | IANA 名 | NO | 3 |
<application-param>
|
Servlet 以外の Web コンポーネントは、Web コンテナが実行時に適当なエンコーディングで読み込む必要があります。例えば、JSP コンパイラは、JSP ファイルを Servlet の Java コードに翻訳する時に、適当なエンコーディングを使って JSP ファイルを読み込みます。このように、Servlet 以外の Web コンポーネントについては、ファイルのエンコーディングを正しく設定する必要があります。
JSP ファイルのエンコーディング指定には以下の 4 つの方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| web.xml の page-encoding 要素 | 指定の URL パターン内 | IANA 名と URL パターン | YES | 1 |
<jsp-config>
|
| page ディレクティブの pageEncoding 属性 | ファイル毎 | IANA 名 | YES | 1 (注 1) |
<%@ page pageEncoding="Windows-31J" %>
|
| page ディレクティブの contentType 属性 | ファイル毎 | charset 属性 (IANA 名) 付きの MIME タイプ | YES | 2 |
<%@ page contentType="text/html; charset=EUC-JP" %>
|
| weblogic.xml の encoding 要素 (非推奨) | Web アプリケーション全体 | Java エンコーディング名 | NO | 3 |
<jsp-descriptor>
|
注 1: JSP2.0 の仕様により、web.xml の page-encoding 要素と page ディレクティブの pageEncoding 属性が異なると、翻訳時にエラーとなります。その結果として、両者の優先度は同じになります。
JSP Document は、XML として記述されるので、JSP Document ファイルのエンコーディング指定は XML の仕様に準拠します。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| XML 宣言の encoding 属性 | ファイル毎 | IANA 名 | YES | 1 |
<?xml version='1.0' encoding='utf-8' ?>
|
なお、JSP2.0 の仕様により、JSP Document において、web.xml の page-encoding 要素や page ディレクティブの pageEncoding 属性によるファイル エンコーディングの設定をした場合、これらが JSP Document の XML 宣言の encoding 属性と矛盾していると、翻訳時にエラーとなります。
Tag ファイルのエンコーディング指定は以下の方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| tag ディレクティブの pageEncoding 属性 | ファイル毎 | IANA 名 | YES | 1 |
<%@ tag pageEncoding="Windows-31J" %>
|
XML 形式 Tag ファイルのエンコーディング指定は以下の方法があります。
| 設定箇所 | 有効範囲 | 設定値 | J2EE 準拠 | 優先度 | 設定例 |
|---|---|---|---|---|---|
| XML 宣言の encoding 属性 | ファイル毎 | IANA 名 | YES | 1 |
<?xml version='1.0' encoding='utf-8' ?>
|
なお、JSP2.0 の仕様により、XML 形式 Tag ファイルに、tag ディレクティブの pageEncoding 属性によるファイル エンコーディングの設定をすると、翻訳時にエラーとなります。
JSP2.0 の仕様により、page ディレクティブの同じ要素が 2 回以上出現し、かつそれらが異なると翻訳時にエラーとなります。例えば、1 つのファイルに、2 つ以上のエンコーディング指定の異なる contentType があった場合などが該当します。
<%@ include file="relativeURL" %>
この場合、インクルードするファイルをすべて読み込んで 1 つのファイルにしてから JSP のコンパイルをする動作になります。したがって、インクルードされる JSP とインクルードする JSP の双方に page ディレクティブのエンコーディングの設定をして、かつそれらが異なると、JSP のパース方法で述べたとおり、翻訳時にエラーになります。
<jsp:include page="{ relativeURL | <%= expression %>}" flush="true" />
jsp:include では、このページをロードした段階ではインクルードは行われず、タグのまま残ります。そしてこのページが実行された段階でインクルードを行うため、インクルード元のエンコーディングの指定を引き継ぐ事ができません。したがってインクルードされるファイルにも必ずエンコーディングの指定が必要になります。
setContentType() や、page タグの Content-Type ディレクティブの指定には IANA のキャラクタ セット名を使用します。しかし、Java アプリケーションである WebLogic Server でエンコーディングを取り扱う場合には、これらの値は Java のエンコーディング名でなければなりません。WebLogic Server では内部でデフォルトのマッピングを持っていて、通常はそれを使用します。また、デフォルトのマッピングには IANA には定義されていないものの、歴史的に HTML の Content-Type で使われてきたものも存在します (WebLogic Server で既に定義している MIME-Java エンコーディング マップを参照)。
例: x-sjis ----> Shift_JIS
このマッピングは独自に変更することが可能です。以下のように、weblogic.xml で設定します。
例えば WebLogic Server では、IANA キャラクタ セットの Shift_JIS は Java の Shift_JIS にマップしている (Java1.4 では SJIS のエイリアスとなっている) ため、contentType が 'Shift_JIS' の場合は SJIS として扱われます。
注意: Java1.3 では IANA キャラクタ セットの Shift_JIS は MS932 として扱われていました (JDK1.1.8 以降 JDK1.4.0 まで。JDK1.4.1 から Shift_JIS は SJIS へ戻されました)。
したがって、デフォルトの設定では Shift_JIS を使用すると MS932 独自文字を使用する事ができません。
デフォルトのマッピングとは異なるエンコーディングを割り当てて使うためには次のようにデフォルトのマッピングを上書きします。weblogic.xml の <charset-mapping> に次のように指定します。
この場合は、Shift_JIS を MS932 にマップしています。
<charset-params>
<charset-mapping>
<iana-charset-name>Shift_JIS</iana-charset-name>
<java-charset-name>MS932</java-charset-name>
</charset-mapping>
</charset-params>
注意: この指定は、HTTP レスポンスに関してのみ有効であることに注意してください。例えば、JSP などのファイルエンコーディング (ページエンコーディング) に対しては有効となりません。
マルチバイトを使用した CGI サービスを WebLogic Server 上の CGI サーブレットへ移行する際は、CGI プログラムが生成する HTTP ヘッダに ContentType で charset パラメータが正しく設定されている必要があります。ContentType を省略した場合は、J2EE Servlet コンテナのデフォルトである ISO-8859-1 が使われます。また、クライアントからの入力文字列を正しく受け取るために、weblogic.xml の input-charset パラメータを使用する必要があります。対象の Web アプリケーションの DD ファイルの記述が必要です。存在しない場合は ISO-8859-1 が使われます。
Form-Based 認証の入力エンコーディングをフォーム内で指定するには、次のように、使用するエンコーディング名を j_character_encoding に指定してください。なお、この機能は WebLogic Server 独自の機能です。
< form method="POST" action="j_security_check" >
Username: <input type="text" name="j_username">
Password: <input type="password" name="j_password">
<input type="hidden" name="j_character_encoding" value="Shift_JIS">
<input type="submit" value="Login">
<input type="reset" value="Reset">
</form>
WebLogic Server は、例えば、以下のような HTTP リクエストを受信した場合、
http://myHostName:port/myContextPath/myRequest/?myRequestParameter
何も設定しない場合、WebLogic Server では myContextPath、myRequest 部分を以下のように扱います。
たとえば、User Agent (web ブラウザ) が MS IE (マイクロソフト インターネット エクスプローラ) の場合、デフォルトではアドレス バーに入力されたマルチバイト文字はまず UTF-8 でエンコードされ、それが URL エンコードされます。WebLogic Server は、デフォルトでこの UTF-8 で送られる URL を正しく String 化します。
注意: IE の [インターネット オプション] の [詳細設定] に [常に UTF-8 として URL を送信する (再起動が必要)] というオプションがありますが、このオプションはオンに (チェック) しておく必要があります。
なお、myRequestParameter 部はリクエストのエンコーディング指定に従ってデコードされます。また、myHostName 部は IESG により、国際化ドメイン名として現在標準化作業が進められています。
独自の User Agent を使用していて、リクエスト URL にマルチバイトが必要な場合には、文字列は UTF-8 でバイト列にした後、URL エンコードして WebLogic Server に送信するようにしてください。URI を作る際に UTF-8 をベースに URL エンコードすることは W3C で推奨されています。(http://www.w3.org/TR/charmod/#sec-URIs)
User Agent によっては、リクエスト URL を UTF-8 で URL エンコードしないものがあります。ネットスケープ ブラウザの場合、アドレス バーの文字はネットスケープ ブラウザが動作する環境のキャラクタ セットでエンコードされ、さらにその文字列が URL エンコードされて WebLogic Server へ送信されます。例えば、日本語 Windows 上で動作するネットスケープ ブラウザは、リクエスト URL を Windows-31J で URL エンコードします。これに対応するには、WebLogic Server で URL デコードした後のバイト ストリームを Windows-31J で String 化するように設定します。次の WebLogic Server の起動オプションにより URL デコードするエンコーディングを変更することができます。
-Dweblogic.http.URIDecodeEncoding=Windows-31J
ただし、この設定は 1 つのサーバ インスタンスで 1 つのみ可能です。
JMS 転送を使用してマルチバイト文字を含むメッセージを送信するには、メッセージを BytesMessage として送信する必要があります。
BytesMessage として送信するにはポートを取得後、以下のいずれかの方法でメッセージ タイプを BytesMessage に設定して下さい。
なお、メッセージの受信側では、送信メッセージと同じタイプを自動的に選択するため、特別な設定は必要ありません。
WebLogic Sever 9.0 の Web サービスは、Enterprise Web Services 1.1 specification (JSR-921) を実装します。JSR-921 では、SOAP1.1 を採用しています。また、SOAP1.1 の HTTP/SOAP メッセージのメディアタイプは 'text/xml' であり、そのエンコーディングの扱いは RFC2376 で規定されています。このため、WebLogic Sever 9.0 の Web サービスの SOAP メッセージの受信のエンコーディングに関する動作は以下のようになります。
SOAP1.1:
開発した Web サービスを HTTP/SOAP で呼び出すクライアントは、ContentType の charset 指定が正しくされていることをご確認ください。
WebLogic Sever は HTTP/SOAP メッセージを UTF-8 で生成します。その際、SOAP メッセージの ContentType ヘッダの charset 属性として、utf-8 が付加されます。
UDDI エクスプローラは us-ascii 文字のみをサポートします。マルチバイト文字は正しく使用できません。
Streaming API for XML (StAX) を使用して生成する XML のヘッダにエンコーディング情報を付加するには、ElementFactory クラスの createStartDocument() を使用して以下のように行います。
XMLOutputStreamFactory factory = XMLOutputStreamFactory.newInstance();
XMLOutputStream output = factory.newOutputStream(new
OutputStreamWriter(new FileOutputStream(fname),"Shift_JIS"));
output.add(ElementFactory.createStartDocument("Shift_JIS","1.0"));
output.flush();
なお、StAX を使用してマルチバイトを含む XML ドキュメントをパースする場合は xerces パーサなどと同様に以下の点にご注意ください。
Oracle データベースは、キャラクタ セット毎に、Unicode とデータベース上のコード ポイントとのマップを持っています。このマップは、文字をデータベースにストアしたり、取り出したりする場合に使用されます。例えば、Oracle Thin ドライバを使用する場合、Oracle データベース サーバ側がこのマップを使用して Unicode とデータベース上のコード ポイントとの変換を行います。
Oracle 用の WebLogic Type4 Driver には、この変換を JDK のコンバータのマップを使って行う codePageOverride というプロパティが用意されています。codePageOverride プロパティで指定できる値と動作については、以下の表のようになります。
| 値 | 動作を保証する接続先のデータベース | 動作 |
|---|---|---|
| SJIS | キャラクタセットが JA16SJIS、JA16SJISTILDE、JA16SJISYEN のいずれか | 接続先のデータベースのキャラクタ セットで扱うことのできるすべてのマップのうち、JDK の SJIS のコンバータと一致するマップによる変換を保証する。一致しないマップは保証されない。 |
| MS932 | キャラクタセットが JA16SJIS、JA16SJISTILDE、JA16SJISYEN のいずれか | 接続先のデータベースのキャラクタ セットで扱うことのできるすべてのマップのうち、JDK の MS932 のコンバータと一致するマップによる変換を保証する。一致しないマップは保証されない。 |
| UTF8 | 全てのデータベース | ドライバは、データベースと通信する際、文字エンコードとしてUTF-8を使用する。この結果、データベースにストアする文字の扱いが Oracle Thin ドライバと同じになる。 |
なお、codePageOverride=SJIS を指定した場合と codePageOverride=MS932 を指定した場合の違いは、MS932 コンバータと SJIS コンバータの違いとしてそのまま現れます。例えば、異なる Unicode にマップされる～ (Wave Dash) や￠ (Cent Sign) 等の記号の扱いなどが影響を受けます。Unicode の定義と Java コンバータに起因する文字化け対策 (日本語を扱う場合のみの注意) などを参考に、構築するシステムの要件に合わせて適切な設定を行ってください。
注意: codePageOverride=UTF8は、WebLogic Server 9.1 以降から使用可能となります。
WebLogic Server 9.0 以降では、codePageOverride プロパティを省略した場合、接続先のデータベースのキャラクタ セットが JA16SJIS、JA16SJISTILDE、JA16SJISYEN については、データベースにストアする文字の扱いが Oracle Thin ドライバと同じなりました。変更内容や以前のバージョンからのバージョンアップに関する注意点などについては、BEA WebLogic Type4 JDBC Driver for Oracle の codePageOverride プロパティについてを参照してください。
JA16SJIS キャラクタ セットのデータベースに対して jDriver for Oracle を使用していて、WebLogic Type4 Oracle ドライバに移行した際に～ (Wave Dash) が文字化けする場合は、データベースを JA16SJISTILDE に移行するか、codePageOverride=MS932 を指定することで回避できます。
プラットフォーム ネイティブのエンコーディングから Unicode へのコンバージョンと、Unicode からプラットフォーム ネイティブのエンコーディングへのコンバージョンでは、同じコンバータを使用しないと正しく文字を扱えない場合があります。ここでは、特に MS932 コンバータと SJIS コンバータで、それぞれ異なる Unicode にマップされる文字に関して、例を挙げて説明します。
例えば、以下のように、データベースにストアされたデータを、WebLogic Server にデプロイした JSP で表示するようなアプリケーションを考えます。
データベース -------------> WebLogic Server -------------> Web ブラウザ
(ネイティブ) MS932 (Unicode) SJIS (ネイティブ)
簡単なアプリケーションですが、エンコーディングのコンバージョンで紹介したとおり、WebLogic Server を介して、プラットフォーム ネイティブのエンコーディングと Unicode のエンコーディング コンバージョンが最低 2 回行われます。この例では、データベースと WebLogic Server 間で MS932 コンバータ、WebLogic Server と Web ブラウザの間で SJIS コンバータが使用されています。この場合、次のコードが正しく扱えず、文字化けなどが生じます。
| SJIS コード |
|---|
| "～" (0x8160) |
| "∥" (0x8161) |
| "￠" (0x817C) |
| "－" (0x8191) |
| "￡" (0x8192) |
| "￢" (0x81CA) |
文字化けを防ぐには、WebLogic Server と Web ブラウザの間、またはデータベースと WebLogic Server 間のエンコーディング コンバージョンを変更して、両者を一致させる必要があります。
<%@ page contentType="text/html; charset=Shift_JIS" %>
と指定している場合 (ここにおける Shift_JIS は IANA 名)、WebLogic Server と Web ブラウザの間で MS932 コンバータを使用するには、以下の 2 つの方法があります。
a) page タグの指定を Shift_JIS (IANA 名) から Windows-31J (IANA 名) へ書き直す。
b) weblogic.xml に次の定義を記述して WebLogic Server が内部的に持つデフォルトのエンコーディング対応テーブル Shift_JIS (IANA 名) -> SJIS (Java コンバータ名) を Shift_JIS (IANA 名) -> MS932 (Java コンバータ名) に変更する。
<charset-params>
<charset-mapping>
<iana-charset-name>Shift_JIS</iana-charset-name>
<java-charset-name>MS932</java-charset-name>
</charset-mapping>
</charset-params>
b) の方法については、HTTP レスポンスに関する Java エンコーディングと IANA キャラクタ セットのマッピングの変更 (J2EE非互換) を参照してください。a) の方法を採用できない場合 (修正量が多すぎる等) に有効です。
BEA WebLogic Type4 Oracle ドライバを使用している場合は、codePageOverride プロパティを使って、データベースと WebLogic Server 間のエンコーディング コンバージョンを変更することができます。
Java の MS932 エンコーディング テーブルは外字エリアのコンバージョンに対応しています。MS932 を使用することで iMode 外字を使用したコンテンツを提供することが可能です。
TUXEDO のドメインに対して wtc のドメインのエンコーディングを指定することができます。以下のパラメータを起動時に指定します。WebLogic Server のスタート スクリプト (StartWebLogic.cmd ファイルなど) を変更します。
-Dweblogic.wtc.encoding=Java エンコーディング名
このエンコーディング指定は TUXEDO ドメイン全体に対して有効です。
|
|
|