| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | dev2dev | サポート | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > |
|
日本語環境での使用にあたって |
WebLogic Server 7.0
 |
7.0SP7 日本語環境での使用にあたって
7.0SP4 からの変更点
WebLogicServer7.0SP5 以降で jRockit を使用する場合の設定
RedHat Linux AS2.1用インストーラについて
RedHat Linux AS2.1でサポートされるJVMはjRockitですがサービスパック 5 以降のインストーラにはjRockitはバンドルされていません。
jRockitを弊社ダウンロードサイトより別途ダウンロード、インストール後にWebLogicServerをインストールしてください。
なお、通常インストール、アップグレードインストールのいずれの場合であっても、
jRockit
インストーラは日本BEAのダウンロードサイトのものをお使いください。
[Windows]
・73行目のjdkのjavaコマンドのパスをjRockitのjavaコマンドのパスに変更します。
・19行目の JavaCompilerをjdkのjavacのパスをjRrockitのjavacのパスに変更します 。
・19行目の JavaCompilerをjdkのjavacのパスをjRrockitのjavacのパスに変更します。
・63行目の環境変数 JAVA_HOMEをjRockitをインストールしたディレクトリに変更します。
・256行目の JavaCompilerをjdkのjavacのパスをjRrockitのjavacのパスに変更します。
・41行目の環境変数 JAVA_HOMEをjRockitをインストールしたディレクトリに変更します。
・6行目の環境変数 JAVA_HOMEをjRockitをインストールしたディレクトリに変更します。
以下はどのドメインでも共通の手順となります。
・87行目の環境変数 COMM_JAVA_HOMEをjRockitをインストールしたディレクトリに変更します。
・97行目の環境変数 COMM_JAVA_VENDORを"BEA"に変更します。
・61行目の環境変数 JAVA_HOMEをjRockitをインストールしたディレクトリに変更します。
以上でファイルの編集は完了です。
[Linux]
通常インストールの場合
[例] cp linux_jrockit70sp6_131_14.zip $BEA_HOME/linux_jrockit70sp6_131_14.zip cd $BEA_HOME gunzip linux_jrockit70sp6_131_14.zip PATH=$BEA_HOME/jrockit70sp6_131_14/bin:$PATH export PATH
コンソールモードについてはこちら
http://edocs.beasys.co.jp/e-docs/wls/docs70/install/instcon.html#804367)
アップグレードインストールの場合
[例] cp linux_jrockit70sp6_131_14.zip $BEA_HOME/linux_jrockit70sp6_131_14.zip cd $BEA_HOME gunzip linux_jrockit70sp6_131_14.zip PATH=$BEA_HOME/jrockit70sp6_131_14/bin:$PATH export PATH
コンソールモードについてはこちら
(http://edocs.beasys.co.jp/e-docs/wls/docs70/install/instsp.html#888224)
URLにマルチバイト文字を使用する(CR092089)
サーブレットコンテナ（Webコンテナ）でURLにマルチバイトを使用することができるようになりました。使用するUser agent (web ブラウザなど)に応じて、必要であればサーバの設定を行います。
例えば、以下のようなHTTP リクエストを受信した場合、
http://myHostName:port/myContextPath/myRequest/?myRequestParameter
myContextPath, myRequest 部分は以下のように動作します。(※1)
デフォルトの動作 (UTF-8をベースエンコーディングとしてURLデコード)
何も設定しない場合、WebLogicServer7.0SP2 では以下のようにHTTPリクエストを扱います。
たとえば、User agent (web ブラウザ)がMS IE(マイクロソフト インターネットエクスプローラ)の場合、デフォルトではアドレスバーに入力されたマルチバイト文字はまずutf-8 でエンコードされ、それがURLエンコードされます。 WebLogicServer7.0SP2 では、デフォルトでこのUTF-8 で送られるURLを正しくString 化することが可能となりました。(※2)
URLデコードする際の文字エンコーディングを指定する方法
User agent が Netscape の場合、アドレスバーの文字はNetscape が動作する環境の文字セットでエンコーディングされ、さらにその文字列が URLエンコードされてサーバへ送信されます。たとえば日本語 Windows 上では MS932 でエンコードされた文字列が URLエンコードされることになります。WebLogicServer7.0SP2では URLデコードした後のバイトストリームを MS932 でデコードするように設定することによりこのリクエストを正しく取得することができます。次のWebLogicServer の起動オプションによりURLデコードするエンコーディングを変更することができます。
-Dweblogic.http.URIDecodeEncoding=MS932 (デフォルトは UTF-8)
ただし、この設定は一つのサーバインスタンスで一つのみ可能です。
独自の User Agent を使用する場合
リクエストURIにマルチバイトが必要な場合には、文字列はUTF-8 でバイト列にした後、URLエンコードしてWebLogicServer に送信するようにしてください。
尚、URIを作る際に utf-8 をベースに URLエンコードすることはW3Cで推奨され ています。(http://www.w3.org/TR/charmod/#sec-URIs)
※1 : myRequestParameter 部は URLデコード後、ServletのsetCharacterEncoding() で指定されたエンコーディング、または weblogic.xmlのinput-charset で指定されたエンコーディングにより デコードされます。
また、myHostName 部は IESG により、国際化ドメイン名として現在標準化作業 が進められています。
※2 : IEの「インターネットオプション」の「詳細設定」に「常に UTF-8 としてURL を送信する（再起動が必要）」というオプションがありますが、このオプションはONに(チェック)しておく必要があります。
既知の問題点
migrate コマンドにより config.xml を更新する際に config.xml ファイル内のマルチバイト文字を正しくコンバートすることができない場合があります。 migrate後サーバが起動しない場合は、この問題が発生している可能性があります。
この場合、config.xml ファイルを（UTF-8エンコーディングで編集できる）エディタで開いて以下のタグ内の Notes='"xxx" のダブルクォーテーション内の文字列部分（文字化けが発生している部分）を削除してください。
<MigratableTarget Cluster="mycluster" Name="clsA (migratable)" Notes="システム生成によるデフォルトのサーバ用移行可能対象です。手動で削 除しないでください。" UserPreferredServer="clsA"/>
これによりサーバが起動し、またサーバが起動することでNotes属性も復旧します。
HP上で SP1 から SP2 へのマイグレーションを行う場合、migrate.sh コマンドを起動するとOutOfMemoryError が発生します。
$WL_HOME/server/bin/ant ファイルの JAVA_HOME の指定が jdk131_06 となっているので、jdk131_08 に修正してから migrate.sh コマンドを実行して下さい。
以下のファイルもJDKのパスが正しく設定されないため、そのままでは使用できません。同様にjdkのパスを jdk131_06 から jdk131_08 に書き換えてください。
$WL_HOME/server/bin/startWLBuiler.sh
$WL_HOME/ebcc/bin/ebcc.sh
Administration Console でアップロードするアプリケーションのファイル名にマルチバイト文字は使用できません。
ファイル名にマルチバイト文字を含むアプリケーションをアップロードした場合、アップロード後のファイル名が文字化けします。
修正された問題
この問題は本リリースで修正されました。
WLS6.1からの変更点
WLS7.0SP1から WebLogic サーバ上でSOAPメッセージや、WSDLファイルのやり取りをする際のエンコーディングの取り扱いは、SOAP1.1仕様にしたがい、RFC2376に準拠しました。これにより日本語を含むSOAPメッセージやWSDLファイルをRFCで指定されているとおりのエンコーディングで扱えるようになりました。
WebLogic Server7.0SP1では HTTP上のメディアタイプがtext/xmlのSOAPメッセージ(SOAP1.1メッセージ)のエンコーディングはHTTPヘッダの contentType charset パラメータを使用します。XML宣言のencoding 属性は無視します。contentTypeのcharset指定がない場合は RFC2376によりそのメッセージは us-ascii として扱われます。
これまでのWLS Webサービスの実装ではHTTPのcontentTypeを無視し、SOAPメッセージのXMLのencoding属性を参照してエンコーディングを決定していました。このためSOAPメッセージのXML宣言に encoding 属性が存在しない場合や、HTTPの contentTypeと SOAPメッセージのXML宣言の encoding 属性が同じでない場合に、SOAP仕様には準拠しない動作となっていました。本リリースからSOAPメッセージのエンコーディング扱いはSOAP1.1仕様に定義されているRFC2376に準拠した動作となりました。
なお、SOAPの実装によってはRFCに準拠していないものも存在します。HTTPの contentTypeとSOAP上の XML encoding指定はできる限りどちらも同じに設定することをお勧めします。
WebLogicサーバ、およびwebservice Java Proxy が生成するSOAPメッセージや WSDLは全てUTF-8でエンコードされます。その際、XML宣言には'encoding=utf-8'が、contentTypeには'text/xml;charset=utf-8'が付加されます。
JSP J2EE 仕様による動作の変更
Pageディレクティブが複数存在した場合には 'Fatal translation Error' となります。(CR066562) これはJSP 1.2の仕様に準拠したための変更です。
JSP.2.10.1 The page Directive
The page directive defines a number of page dependent properties and Communicates these to the JSP container.
A translation unit (JSP source file and any files included via the include directive) can contain more than one instance of the page directive, all the attributes will apply to the complete translation unit (i.e. page directives are position independent). However, there shall be only one occurrence of any attribute/value defined by this directive in a given translation unit with the exception of the import attribute; multiple uses of this attribute are cumulative (with ordered set union semantics). Other such multiple attribute/value (re)definitions result in a fatal translation error.
ひとつのコンパイル単位で複数の page directive が出現したら fatal translation error となる、というものです。WebLogicServer7.0 ではこの仕様に準拠するようにJSPの動作が変更になっています。
この変更により問題となるのは、静的include (<%@ include file=. . . %>)で別のJSPファイルをインクルードした場合、インクルード元、インクルード先のそれぞれで page directive を持っている場合です。静的インクルードではインクルードした結果できるjsp全体を1コンパイル単位としてJSPコンテナが評価するため、この場合page directiveが複数存在することになり、 'Fatal translation Error'が発生します。
これまでのリリースではエラーとはなりませんでしたが、本バージョンからエラーが発生することになります。この問題を回避するため、WebLogicServer7.0 では以下のオプションをweblogic.xmlの新規パラメータとして用意しました。
コード リスト 1-1 weblogic.xml に追加された新規パラメータ
<jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
これにより、page directive が1コンパイル単位で複数回出現しても、そのencodingが同一であれば問題なく使用できるようになります。これまでのバージョンで使用していたjspをWebLogicServer7.0でも変更することなく使用することができます。
J2EE デフォルトのエンコーディングの指定
weblogic-application.xml でJ2EEエンタープライズアプリケーション全体でrequestに対するデフォルトの文字エンコーディングの指定が可能になりました。(CR065921)
weblogic-application.xml で次のパラメータをセットすることにより、requestで使用するデフォルトのエンコーディングを設定することができます。
以下のオプションのうちどちらかを使用します。
これらの値はrequestストリームに対するweblogic.xmlの input-charset の指定や setCharacterEncodingなどの指定によって上書きされます。
また、2すなわち webapp.encoding.defaultで指定する値は Javaエンコーディング名であり、IANAの文字セット名ではありません。
もしも、上記の2つのオプションが両方ともセットされていると、1すなわち webapp.encoding.usevmdefaultが使用されます。
コード リスト 1-2 webapp.encoding.usevmdefault の使用例
weblogic-application.xml
<application-param>
<description>webapp.usevmdefault</description>
<param-name>webapp.encoding.usevmdefault</param-name>
<param-value>true</param-value>
</application-param>
または
コード リスト 1-3 weblogic_application.xml のwebapp.encoding.default の使用例
<application-param>
<description>default encoding</description>
<param-name>webapp.encoding.default</param-name>
<param-value>SJIS</param-value>
</application-param>
WTC TUXEDOドメインに対するエンコーディングの指定(CR052022)
TUXEDOのドメインに対してwtc のドメインのエンコーディングを指定することができます。以下のパラメータを起動時に指定します。サーバのスタートスクリプト（StartWebLogic.cmdファイルなど）を変更します。
-Dweblogic.wtc.encoding=Javaエンコーディング名
このエンコーディング指定はTUXEDOドメイン全体に対して有効です。
XML -- StreamParser のマルチバイト文字の扱い
XML Streaming APIを使用して生成する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();
なお、XML StreamingAPIを使用して日本語を含むXMLドキュメントをパースする場合はxercesパーサなどと同様に以下の点にご注意ください。
バイトストリームを使用することによりパーサが持つXMLのエンコーディング自動認識機能を使用できます。これにより、パーサはXMLヘッダのencoding指定に合ったストリームを内部で生成するので、正しくパースすることができるようになります。
DDファイルのエンコーディングの扱い
J2EEコンポーネント(.ear、.war、.jar、.rar ファイル)のDD（デプロイメントディスクリプタ）ファイルにマルチバイト文字を使用する場合の制限がなくなりました。どのコンポーネントにおいてもDDファイルのエンコーディングをXML宣言に従い、正しく扱うことができます。また、WebLogic Builderや管理コンソールなどからDDファイルを編集して保存する際、元のファイルのエンコーディングは保存されます。DDファイルのXML宣言にencoding属性がない場合、およびXML宣言がない場合、ファイルはUTF-8として扱われます。
WebLogic Server のI18n(国際化)の概要
WebLogic Server のI18n の基本的な特徴は以下のようになります。
WLSを使ってマルチバイトの文字情報を扱う分散システムを構築する際にはJavaおよびJ2EE特有のエンコーディングの指定方法を十分に理解する必要があります。それに加えて、OS、インターネット、バックエンドシステムなど、WLSと接続するシステムのエンコーディングの扱いを十分に検討した上で、エンコーディングコンバージョンを正しくコントロールする必要があります。
それぞれの特徴を簡単に説明します。
WLSはUnicodeで扱える文字ならばどんな言語の文字でも同時に扱うことが可能です。
通常のOSでは、Javaの内部コードであるUnicodeで動作する環境はほとんどありません。ネイティブエンコーディングと呼ばれる、個別のプラットフォームで個別に定義されたエンコーディングで動作します。例えば Windowsであれば言語に応じたコードページ、UNIXではLANG環境変数により指定されたロケールに応じたエンコーディング、DBであればDBを作成する際に指定した文字セットやクライアントの文字セットなどがネイティブエンコーディングに相当します。
このため、WLSで文字の入出力をする際に、ネイティブエンコーディングの文字とUnicodeとの間でエンコーディングを相互にコンバージョン（変換）する必要があります。このエンコーディングのコンバージョン（文字セットの変換）はOSや外部リソースとのキャラクタデータの入出力の際に常に発生します。（注1）
また、エンコーディングのコンバージョンは文字ひとつづつに対して個別に全て行わなければならないため比較的大きなCPUリソースを必要とします。アプリケーション設計の際には、コードコンバージョンをなるべく減らす工夫がよりよいパフォーマンスにつながります。
(注1) ： Javaクラスをシリアライズしたストリームに含まれる文字はUnicodeのまま（UTF-8でエンコード)されてクラスの内部情報として保持されているため、コードコンバージョンは考慮する必要ありません。例えばEJBやRMIでは通常エンコーディングについて考慮する必要はありません。
WLSサーバはどんな言語のコンテンツをサービスしていようとも、サーバ本体のログのエンコーディングや、管理コンソールのエンコーディングはアプリケーションコンポーネントとは関係なく、サーバ本体のJavaVMのデフォルトエンコーディングやブラウザの言語設定により動作します。
また、あるアプリケーションコンポーネントをWLSにデプロイすると、どんなロケール（言語）の環境で動作するWLSであっても、全く同じ動作をするようにコンフィグレーションすることが可能です（注）。
JDBCコネクションプールなど、WLSサーバコンテナ上でコンフィグレーションされるリソースに対してもリソース毎に個別にエンコーディングコンバージョンのための設定をすることができます。
WLSサーバ本体のエンコーディングコンバージョンとして以下のものがあります。
WLSサーバのシステムログ出力
管理コンソールのページのエンコーディング、
ローカルファイルシステムとのファイルI/O
アプリケーションパッケージ個別のコンバージョンとして以下のものがあります。
jspファイル
サーブレット
DDファイル
XML
Webサービス
WLSサーバ上のリソースとしては以下のものがあります
JDBCコネクション
WTCコネクション など
そこで、WebLogicServer上でエンコーディングを指定する場合には、その指定は上記３つのカテゴリのどこに対して指定しているのかを明確にする必要があります。その上で、WLS内に正しいCharacterオブジェクトが作れるか、もしくはWLS 内のCharacterオブジェクトが希望のエンコーディングの文字に変換されて出力されるか、常に意識する必要があります。
このように、WLS上でマルチバイト文字を扱う場合には、エンコーディングコンバージョンの働きを一通り理解し、必要に応じて設定を行う必要があります。エンコーディングコンバージョンの設定をしなければアプリケーションは正しくマルチバイト文字を扱えない場合があります。
いずれの場合においてもエンコーディングを指定しない場合は何らかのデフォルトのエンコーディングが使用されます。デフォルトのエンコーディングはそれぞれの仕様や、環境により異なる場合があります。
サーバVMのデフォルトエンコーディング
J2EEのデフォルトエンコーディング
XMLのデフォルトエンコーディング
HTTPプロトコルのデフォルトエンコーディング
Webブラウザのデフォルトのエンコーディング
webservice(SOAP/WSDL/UDDIなど）のデフォルトエンコーディングなど
例：
サーバVMのデフォルトエンコーディングは日本語Windows上ではMS932
J2EEのデフォルトエンコーディングは基本的にISO-8859-1。
XMLのデフォルトエンコーディングは utf-8
HTTPのデフォルトエンコーディングは us-ascii など。
このように技術仕様によってデフォルトのエンコーディングが異なるため、エンコーディングに関する指定をまったくしない場合は、WebLogicServerでは日本語を正しく扱うことができません。次章以降の個別のエンコーディングの指定方法をよくご理解いただいた上でエンコーディングのコンバージョンをコントロールしてください。
エンコーディングという言葉はJavaで使われている文字セットのことですが、この言葉は場合によっていくつかの異なる呼び名があり、それぞれ若干定義が異なるので注意が必要です。
Javaでのエンコーディングやインターネット上で文字セットと呼ばれているものは、特定の言語の文字をコンピュータ上で扱えるように、その文字のまとまりをコンピュータのコード割り当てた定義のことです。
Java はこれらの違いを入出力部分で吸収し、内部では常にUnicode で扱います。このためエンコーディングの定義さえあればどんな文字セットでも扱うことができる優れた特徴をもっています。つまり、Javaはさまざまなシステム間に存在するエンコーディングの違いを全て吸収できる可能性を持った言語であると言えます。 しかしながら、現状では細かなエンコーディングの違い全てに対応したエンコーディング変換テーブルは存在しません。また既に存在するエンコーディングテーブルにもUnicodeとの整合性からいくつか制限があります。
Java Webアプリケーションサーバで特に重要なのはJavaのエンコーディング名と、InternetやXMLで使用されるIANAで定義されたMIME文字セットの違いです。WLSではこの違いを吸収するため、Javaエンコーディング名とIANAの文字セットとの名前のマッピングテーブルを持っています。これにより、例えばJSP上ではShift_JISとして定義したファイルをJavaの MS932 として扱うことができます。 また、このWLSシステムのマッピングを変更して、例えば 'Shift_JIS'という文字セット名を'cp943'というJavaエンコーディングとして扱うことも可能です。
WLSサーバ組み込みのXMLパーサである xercesでは独自にIANAとJavaのマッピングテーブルを持っています。これはユーザ側でカスタマイズすることはできません。例えばIANAのcharset名のShift_JISはJavaのエンコーディング名のSJISにマップされています。
WLSでは基本的にJavaのエンコーディング名でエンコーディングを設定するようになっています。また、J2EE、Internet、XMLではIANA文字セット名を使用します。必要に応じてこのマッピングの変更を行ってください。
インストール
WLS7.0には日本語版インストーラと英語版インストーラがあります。米国BEA Systems IncのWebサイトからは英語版インストーラ、日本BEA?鰍ﾌWeb サイトからは日本語版インストーラをダウンロードできます。
日本語版と英語版との差異は以下のとおりです。WLSサーバの動作にかかわるプログラムファイルは全て同一であり、同じソフトウェアとして扱われます。また、英語版インストーラを使用して起動したWLSサーバと、日本語版インストーラを使用して起動したWLSサーバの相互運用についても問題はありません。
同じもの
weblogic.jar ほか全てのWLSクラスファイル
バージョン文字列
メッセージカタログ、コンソールオンラインヘルプの言語
違うもの
いくつかの翻訳されたテキストファイル
about_wls/readme.txt/index.jsp or html
WebLogic Builderのオンラインヘルプ
日本語サンプルコード(%WL_HOME%\samples\server\src\examples_ja)
WebLogic Server7.0J では以下の項目は使用できません。
WebLogic Server システム管理
以下の項目はWLSサーバのJVMのデフォルトのエンコーディングで動作します。
また、以下の項目はブラウザのデフォルトの言語により動作します。
サーバのデフォルトのエンコーディングで動作するログ出力のエンコーディングなどを変更したい場合は以下の手順で設定してください。
WebLogic Serverコンテナのデフォルトのエンコーディングの指定方法
WebLogic Server 7.0Jは様々なスコープでエンコーディングを指定することができます。例えばJSPではJSP1.2仕様に準拠したページ毎のエンコーディングの指定を行う page タグがあります。 WebLogic jDriver ではJDBC接続のエンコーディングを weblogic.codeset プロパティで設定します。このように特定のスコープ毎に指定するエンコーディングは、WebLogicServer が動作するJavaVM のデフォルトのエンコーディングとは関係がありません。JavaVMが英語のlocaleであっても、日本語のJSPファイルを使ったサービスをすることには何ら問題ありません。しかしながら以下の項目についてはJavaVMのデフォルトのエンコーディングに依存して文字列を取り扱います。
これらはプラットフォーム毎のJavaVMのデフォルトのエンコーディング(Java システムプロパティの file.encoding に設定されたエンコーディング)で動作します。例えば、WebLogic Serverがターミナルコンソールへ出力するログメッセージは、そのプラットフォームの環境からJavaVMがfile.encoding システムプロパティに設定したエンコーディングとシステムロケールにより言語、エンコーディングが決まります。システムのロケールを切り替えることでWebLogic Server のログメッセージの言語・エンコーディングを切り替えたい場合は以下のように指定します。なお、JavaVMのデフォルトのエンコーディングはVMの起動後に動的に切り替えることはできません。以下の設定を確認した後でWebLogic Server を再起動してください。
Windows 2000/Windows NT の場合
[コントロールパネル｜地域（または地域のオプション）］から「英語（U.S）」または「日本語」を選択します。これにより、サーバは CP1252 または MS932 をデフォルトのエンコーディングとして動作します。
UNIX の場合
LANG 環境変数にプラットフォームでサポートするロケールを指定します。
サーバのエンコーディングと LANG 環境変数の設定は次のとおりです。
|
プラットフォーム |
エンコーディング |
LANG 環境変数 |
|---|---|---|
|
Solaris |
EUCJIS SJIS |
ja または ja_JP.eucJP ja_JP.PCK |
|
HP |
EUCJIS SJIS |
a_JP.eucJP ja_JP.SJIS |
たとえば、Solaris で EUCJIS を指定する場合は次のようになります。
LANG=ja
以上のように、JavaVMのデフォルトのエンコーディングがWebLogic Serverのデフォルトのエンコーディングとなります。管理コンソールからログメッセージを参照することで確認することができます。手順は次の通りです。
表示されたエンコーディングがサーバのエンコーディングです。
管理サーバ、管理対象サーバの構成上の注意
ドメイン内の全てのWebLogic Serverのエンコーディングは同じものを使用します
WebLogic Server 7.0Jでは、ドメイン内の全てのサーバは同一エンコーディングに設定する必要があります。
例えば、ドメイン内に Windowsプラットフォームが存在する場合、ドメインをMS932などShift_JIS系のエンコーディングで統一します。エンコーディングの異なるサーバがあった場合、そのサーバのログは正しく表示する事ができません。
クラスタ構成上の注意
クラスタ内の全てのWebLogic Serverのエンコーディングは同じものを使用します
WebLogic Server 7.0Jでは、クラスタ内の全てのサーバは同一エンコーディングに設定する必要があります。
例えば、クラスタ内に Windowsプラットフォームが存在する場合、ドメインをMS932などShift_JIS系のエンコーディングで統一します。エンコーディングの異なるサーバがあった場合、そのサーバのログは正しく表示する事ができません。
config.xml ファイルのエンコーディング
config.xml ファイルは UTF-8 で入出力します。テキストエディタなどで直接config.xml ファイルを編集する場合は、utf-8 で読込み/保存してください。
WebServer（fileservlet）の制限
WLSをWebサーバとして使用する場合の注意点は以下のとおりです。
<mime-mapping>
<extension>htm</extension>
<mime-type>text/html;charset=Shift_JIS</mime-type>
</mime-mapping>
これにより、HTMLファイル内で次のようなMETAタグによるcharset指定を省略することができます。
<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=Shift_JIS">
JDBCコネクション
JDBCコネクションプールを作成する場合、マルチバイトを扱うDBへの接続にはエンコーディングの指定を正しく行う必要があります。また、その際、エンコーディングコンバージョンマッピングをWeb層とDB層で合わせる必要がある場合があります。
詳しくは xxxxxxxx (プログラミング jDriver for xxx )の項を参照ください。
jDriver for Oracle
http://edocs.beasys.co.jp/e-docs/wls/docs70/oracle/advanced.html#415150
jDriver for MS SQL Server
http://edocs.beasys.co.jp/e-docs/wls/docs70/mssqlserver4/API_jmsq4.html#522789"
デプロイメント
WLSでは、J2EEコンポーネントのDDファイルのマルチバイト文字はXML宣言にしたがって扱います。XML宣言がない場合、もしくはXML宣言があってもencoding属性がない場合はファイルをUTF-8として扱います。
WebLogic Builder、管理コンソールでDDファイルを編集すると、ファイルは編集前のXML宣言にしたがってSaveされます。
WebLogic Builder、管理コンソールでDDファイルを生成した際にはXML宣言がありません。エンコーディングを変更する場合は、ファイルのエンコーディングコンバージョンとともに、XML宣言のencoding 属性を正しい値に設定してください。
管理コンソールを使用する場合の注意
管理コンソール起動時の言語について
最初に管理コンソールを起動したときに表示される言語は、お使いのWebブラウザで指定している最優先の言語になります。例えば、日本語Windowsをお使いの場合、最初に管理コンソールを起動すると、日本語で表示されます。最初に表示する言語を英語に切り替えたい場合には、ブラウザのオプション設定の「言語の優先順位」で「英語」を最優先にすることで変更できます。
WLS7.0SP1で選択可能な管理コンソールの言語
SJIS/EUCJIS は管理コンソールが接続している管理サーバ側のエンコーディングに合わせて選択してください。
管理コンソール起動後の言語の切り替え
コンソールのホーム画面から、[プリファレンス]ページで[言語］ のドロップダウンボックスで使いたい言語を選択します。
プログラミング
servlet/JSP を使用する場合の注意
設定するエンコーディングのスコープと優先順位
WebLogic Server 7.0Jは一つのJavaアプリケーションプログラムです。全ての文字列は内部的にはUnicodeで扱います。しかし、HTTPプロトコル上のHTMLでは様々なエンコーディングが使われています。WebLogic Server はHTMLのデータを取り扱う際にはUnicodeとHTMLのエンコーディングの間でJavaのエンコーディングコンバータを使用してエンコーディング変換を行います。このため、WebLogic Server を使用する際にはサーバ内部で扱われるUnicode文字列とHTML上のエンコーディングとの変換をアプリケーションでどう扱うかは非常に重要な問題です。
WebLogic Server 7.0J には特定のスコープにもとづいてエンコーディングを指定するためのパラメータがいくつかあり§使用するアプリケーションに合わせてこの問題に対処できるようになっています。
また、WebLogic Server 7.0J では使用する個々のモジュールそれぞれに対してJavaVMのデフォルトのエンコーディングとは独立に、それぞれのエンコーディングの指定をすることが可能です。
WebLogicServer 7.0Jで日本語の文字列を扱う場合のスコープとして、J2EEの仕様や、WebLogic Server 独自の仕様などによりいくつか決められています。この中から、JSP/Servletに関連した指定項目としては次のものがあります。必ずしも全てを設定する必要はありません。以下の説明をよくご理解の上、お使いの環境に合わせて最も適切な項目を組み合わせてください。
エンコーディングの設定項目
JSP/Servletに関連するエンコーディングの設定項目には次のようなものがあります。 （
これらの設定パラメータは同時に指定された場合の優先順位があらかじめ決まっています。例えば、JSPコンテナのデフォルトがShift_JISが設定されていて、page タグではEUC-JPが指定されていた場合には、page タグの指定が優先されるためEUC-JPが使われる、といった動きになります。基本的にはスコープの狭いものが優先されます。スコープが広い設定でデフォルトの指定を行い、特殊な扱いをする必要のあるものだけはスコープの狭い設定を使用する、などの設定方法が考えられます。
実際の開発では、特定の設定をアプリケーション全体で統一的に使用することをお勧めします。
日本語を使用する場合の全体の流れ
ここまで説明したように、WebLogic Server にはエンコーディングを指定するパラメータがいくつかありますが、次のように、HTTPリクエストからHTTPレスポンスまでをもれなく指定する必要があります。これらの指定がない場合は ISO-8859-1のエンコーディングが使用されます。
Servlet
JSP
Servlet/JSP共通
以下、Servlet の場合、JSPの場合などそれぞれの設定の詳細を説明します。
Servletの場合
HTTPレスポンスのエンコーディング指定 --- response.setContentType()
Servlet が生成するHTMLページのエンコーディングはsetContentType() を使用します。setContentType()を呼び出すと、次の2点が決まります。
このため、setContentType() はWriter を取得する前に呼び出す必要があります
res.setContentType("text/html;charset=Shift_JIS");
PrintWriter out = res.getWriter();
また、HTTPヘッダのcontentTypeが指定されるので、ブラウザの表示エンコーディングがこの呼び出しにより決まります。
HTTPリクエストのエンコーディング指定 ---- request.setCharacterEncoding or <input-charset>
ここまでの設定でWebLogic Server からクライアントへ送信するデータであるHTTPレスポンス の設定が終わりました。続いて、クライアントから WebLogicServer へデータを送信する場合のHTTPリクエストの設定方法を説明します。
HTTPリクエストのエンコーディングを指定するには以下の3つの方法があります。
この方法が最もHTTP仕様に即したものです。しかし、マイクロソフトのインターネットエクスプローラ、およびネットスケープブラウザではこの値を指定することはできません。
request.setCharacterEncoding() を使用します。リクエスト毎にエンコーディングを指定することができます。動的にエンコーディングを制御するなど、細かい操作も可能です。また、setCharacterEncoding() は Servlet 2.3 の仕様に準拠していますからアプリケーションのポータビリティを確保することにもつながります。
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
この設定はWebLogicServer6.0ではweb.xml に設定していたものです。WebLogicServer6.1からはこの設定をweblogic.xml で行うように変更されました。またエレメント名等も異なっています。6.0からの移行の際にはご注意ください。
<input-charset> の指定はクライアント Web ブラウザからのリクエストURLで指定したリソースへのパスに対してサーバ側でエンコーディングを指定するものです。
例えば、
などの設定ができます。
<input-charset> の書き方は以下のようになります。対象となる web アプリケーションの <charset-params> をデプロイメント記述子（weblogic.xml）に以下のように記述します。
<weblogic-web-app> の中の <charset-param>に、エンコーディングを指定したいリクエスト URLのパスと、HTTPリクエストで指定したいエンコーディングをIANA名で記述します。
なお、Java エンコーディング名とIANA文字セット名との対応の仕方ついては、「Java Encoding とIANA character set のマッピング(weblogic.xml への設定)」の項を参照ください。
一つのWebアプリケーション内で複数のエンコーディングに対応するマルチエンコーディングのwebアプリケーションを構成することも可能です。
この例では、「/*」 を Shift_JIS、「/rus/jo/*」 をISO-8859-1に指定しています。
<charset-params>
<input-charset>
<resource-path>
/*
</resource-path>
<java-charset-name>
Shift_JIS
</java-charset-name>
</input-charset>
</charset-params>
<charset-params>
<input-charset>
<resource-path>
/rus/joe/*
</resource-path>
<java-charset-name>
ISO-8859-1
</java-charset-name>
</input-charset>
</charset-params>
この設定の詳細は、『Web アプリケーションのアセンブルとコンフィグレーション』の「文字セット パラメータの定義」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/webapp/webappdeployment.html
JSPの場合
JSP ファイルのエンコーディングの指定--- pageEncoding (オプション)
次のようにpageタグ pageEncodingを指定すると、WebLogic Server 7.0J JSPコンテナまたはJSPコンパイラがJSPファイルを読み込むエンコーディングを指定できます。
<%@ page contentType="text/html; charset=Shift_JIS" pageEncoding="Shift_JIS" %>
ページの出力エンコーディング指定 ---- page タグの contentType ディレクティブ
次のようにpage タグ contentType ディレクティブを指定すると、ページの出力エンコーディングを指定できます。
<%@ page contentType="text/html; charset=Shift_JIS" %>
contentTypeディレクティブはpageEncoding ディレクティブの指定がなかった場合にはJSPファイルを読み込むエンコーディングとしても使われます。
JSPコンテナではこの指定を見つけると、いったんそのJSPファイルのパースを中断し、新たに指定されたエンコーディングにファイルリーダを切り替え、再度ページの最初からパースを実行します。一つのファイルに2つ以上 contentType の指定があった場合にはパースエラーとなります。（注？？？） このため、静的にインクルードするファイルで両方のファイルにエンコーディングを指定している場合はエラーになります。動的にインクルードする場合はエラーにはならず、文字化けが起こります
また、page ディレクティブでcontentType指定を行った場合、HTTPレスポンスのHTTPヘッダにはcontentType指定が入ります。これによりブラウザの表示エンコーディング指定ができることになります。
注？？？：一つのファイルに2つ以上 contentType の指定があった場合でもその指定が同一であればパースエラーにしない指定をすることができます。 （「include タグの静的・動的の違いと page タグでのエンコーディングの指定」を参照）。
このため、静的にインクルードするファイルで異なるエンコーディングを指定している場合もエラーになります。動的にインクルードする場合はエラーにはならず、文字化けが起こります（「include タグの静的・動的の違いと page タグでのエンコーディングの指定」を参照）。
< jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
例えば'<%@ include 'を使って静的インクルードを行う際に、インクルード元、インクルード先の両方でpage directive が存在する場合、この1コンパイル単位で複数回page directiveが出現しても、そのencodingが同一であれば問題なく使用できるようになります。
HTTPリクエストのエンコーディング指定はServlet で行う方法と全く同じです。「「Servletの場合」の項を参照してください。
<%
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
%>request.setCharacterEncoding or <input-charset>
Servlet/JSP共通
Java Encoding とIANA character set のマッピング(weblogic.xml への設定)
setContentType() や、pageタグの Content-Typeディレクティブの指定にはIANAの文字セット名を使用します。しかし、JavaアプリケーションであるWebLogic Server 7.0J でエンコーディングを取り扱う場合には、これらの値はJava のエンコーディング名でなければなりません。WebLogic Server 7.0Jでは内部でデフォルトのマッピングを持っていて、通常はそれを使用します。また、デフォルトのマッピングにはIANAには定義されていないものの、歴史的にHTMLのContent-Type で使われてきたものも存在します。（Appendix A 参照）
例 : x-sjis ----> MS932
この設定は独自に変更することが可能です。以下のように、webアプリケーションの Deployment Descriptor で設定します。
例えばWebLogic Server 7.0Jでは、IANA文字セットのShift_JIS はJavaのShift_JISにマップしている (JavaではMS932のエイリアスとなっている) ため、contentType が 'Shift_JIS' の場合はMS932として扱われます。
注意: Javaでは IANA charset の Shift_JIS はMS932として扱われます。 （JDK1.1.8 以降 JDK1.4.0 まで。なお、Shift_JISはJDK1.4.1からSJISへ戻されました。）
したがって、デフォルトの設定で@、Aなどの MS932 独自文字を使用する事ができます。
デフォルトのマッピングとは異なるエンコーディングを割り当てて使うためには次のようにデフォルトのマッピングを上書きします。WebアプリケーションのDeployment Descriptor weblogic.xml の <charset-mapping>に次のように指定します。
この場合は、Shift_JISをSJISにマップしています。
<charset-params>
<charset-mapping>
<iana-charset-name>
Shift_JIS
</iana-charset-name>
<java-charset-name>
SJIS
</java-charset-name>
</charset-mapping>
</charset-params>
この指定は J2EE 互換ではありません。この設定はWebLogicServer6.0ではconfig.xml に設定していたものです。WebLogicServer6.1からはこの設定をWebアプリケーションの Deployment Descriptor weblogic.xml で行うように変更されています。またエレメント名等も異なっています。6.0からの移行の際にはご注意ください。
iso-8859を使ったwork-around（回避策）をそのまま使用する場合の設定
iso-8859 を <input-charset> に指定すると、iso-8859を使用したworkaround をコードを修正することなくそのまま使用できます。
Workaround の例：
new String(request.getParameter(itemQ[i]).getBytes ("8859_1"), "SJIS")
ただし、HTTPリクエストで、HTTPヘッダに下記のようにContent-Type を指定するHTTPクライアントではこの回避策は使用できません。これはHTTPヘッダでの Content-Type の指定が<input-charset>の指定よりも優先するためです。この場合はアプリケーションプログラムのコードを修正する必要があります。
Content-Type: application/x-www-form-urlencoded;charset=shift_jis
include タグの静的・動的の違いと page タグでのエンコーディングの指定
静的インクルード
<%@ include file="relativeURL" %>
この場合、インクルードするファイルをすべて読み込んで一つのファイルにしてからJSPのコンパイルをする動作になります。WLS6.1 までは、インクルードするファイルにエンコーディングの指定があれば、インクルードされるファイルにエンコーディングの指定がなくてもインクルード元と同じエンコーディングのファイルとして扱われました。 WLS7.0 では、インクルード元とインクルード先のファイルの両方にページ ディレクティブが存在すると、コンパイル エラーが発生します。これを防ぐには、 weblogic.xml の'backwardCompatible' を true に設定します。
また、インクルード元と、インクルード先のファイルでエンコーディングの指定が異なっているとJSPのコンパイルエラーとなります。
動的インクルード
<jsp:include page="{ relativeURL | <%= expression %>}" flush="true" />
JSP インクルードでは、このページをロードした段階ではインクルードは行われず、タグのままのこります。そしてこのページが実行された段階でインクルードを行うため、インクルード元のエンコーディングの指定を引き継ぐ事ができません。
したがってインクルードされるファイルにも必ずエンコーディングの指定が必要になります。
CGIServlet
マルチバイトを使用したCGIサービスを WLS 上の CGI サーブレットへ移行する際は、CGIServlet がコンテンツをバイトストリームとしてそのま転送するように、web.xml で以下の useByteStream パラメータを true に設定する必要があります。 CGI プログラムにおいて Content-Type ヘッダを設定する必要はありません。これにより、ブラウザ側でエンコーディングが判別され、正しくマルチバイト文字が表示されます。
<servlet>
<servlet-name>CGIServlet</servlet-name>
<servlet-class>weblogic.servlet.CGIServlet</servlet-class>
<init-param>
<param-name>cgiDir</param-name>
<param-value>cgi-bin</param-value>
</init-param>
<init-param>
<param-name>useByteStream</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
また、クライアントからの入力文字列を正しく受け取るために、 input-charset パラメタを使用する必要があります。対象の webアプリケーションのDDファイルの記述が必要です。存在しない場合は ISO-8859-1 が使われます。
WebService
SOAPメッセージとエンコーディングの扱い
WebLogic Sever の Web サービスは、エンコーディングの取り扱いはSOAP1.1仕様に準拠します (注1)。 SOAP1.1 の HTTP/SOAP メッセージのメディアタイプは 'text/xml' であり、そのエンコーディングの扱いは RFC2376 で規定されています。RFC 仕様としては以下の動作をします。
WebLogic Sever 7.0SP1 はこの仕様に準拠して動作するため、WebLogic Workshop の動作もこれに準じます。したがって、WebLogic Workshop で開発した Web サービスをHTTP/SOAP で呼び出すクライアントは、ContentType の charset 指定が正しくされていることをご確認ください。
WebLogic Sever では全ての HTTP/SOAP メッセージは utf-8 で生成します。その際、SOAP メッセージのヘッダに 'encoding=UTF-8' も付加されます。
※注1：WebLogic Server を英語ロケールで起動した場合（UNIX上で LANG=C の環境など）は SOAP メッセージで使用できるのは us-ascii 文字のみです。それ以外の文字は動作保証の対象外となります。 Web サービスで日本語の文字を使用する場合は必ず日本語のロケールで WebLogic Server を起動してください。
なお、英語ロケールで起動した WebLogic Server で us-ascii 以外の文字を使用する場合は以下の起動オプションを WebLogic Server の起動スクリプトファイル内で定義してください。これにより WebLogic Server が英語ロケールで動作していても utf-8 でメッセージを生成できます。
-Iweblogic.webservice.i18n.charset=utf-8
web service ホームページはサーバVMのデフォルトのエンコーディングで生成されます。
UDDIエクスプローラはus-ascii文字のみをサポートします。マルチバイト文字は正しく使用できません。
なおWebLogic Server7.0SP1のWebサービスは、SOAP1.2で定義されているメディアタイプには対応していません。
XML -- StreamParser のマルチバイト文字の扱い
XML Streaming APIを使用して生成する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();
なお、XML StreamingAPIを使用して日本語を含むXMLドキュメントをパースする場合はxercesパーサなどと同様に以下の点にご注意ください。
パーサの入力にストリームを使用する際にはバイトストリームを使用します。 バイトストリームを使用することによりパーサが持つXMLのエンコーディング自動認識機能を使用できます。これにより、パーサはXML宣言のencoding属性で指定されたエンコーディングで文字ストリームを内部で生成し、正しくパースすることができるようになります。
Unicodeキャラクタストリームで渡す場合は、パーサはxmlヘッダのエンコーディング指定を無視します。 この場合はユーザ側で正しいキャラクタストリームを渡すように注意してください。
JDBC
Oracle jDriver を使用する場合
weblogic.jdbc.oci.Driver を使用するには以下のセットアップを行います。jDriver ライセンスの設定が必要になるので注意してください。
Oracle の bin と、WebLogicのOracle ociドライバネイティブライブラリのbinにPathを通します。その際、Oracle のバージョンに合わせた oci ドライバを使用するようにしてください。
Oracle 8.1.7の場合：%WL_HOME%¥bin¥oci817_8;d:¥oracle¥ora81¥bin
Oracle 9.0.1の場合：%WL_HOME%¥bin¥oci901_8;d:¥oracle¥ora90¥bin
NLS_LANGとJ Driver for Oracleのconnection propertiesである weblogic.codesetは常に同じエンコーディングである必要があります。
NLS_LANG = japanese_japan.ja16sjis
なお、NLS_LANGと weblogic.codeset の設定の関係については、『WebLogic jDriver for Oracle ユーザーズ ガイド』の「Oracleの高度な機能」を参照してください。なお、Oracleデータベースがja16sjis で、NLS_LANGをjapanese_japan.ja16sjis、weblogic.codeset=MS932と指定することができる場合、Windowsプラットフォームで使われる文字セットをOracle データベースにストアすることができます。
ここまでの設定でWebLogic Server から接続プールを使わないで WebLogic jDriver for Oracleドライバを使用することができるようになります。例えば、JSPやServletなどのJDBCクライアントから直接データベースに接続することができます。JDBCクライアントがWebLogic Server jDriver for Oracle を使用する場合のプログラミングについては、『WebLogic jDriver for Oracle ユーザーズ ガイド』の「WebLogic jDriver for Oracle の使い方」の「Oracle DBMS への接続」を参照してください。
接続プールを使用する場合はさらに次の設定を管理コンソールから行う必要があります。接続プールの設定の詳細については、『WebLogic jDriver for Oracle ユーザーズ ガイド』の「WebLogic jDriver for Oracle のコンフィグレーション」の「接続プールの設定」を参照してください。以下に設定例を説明します。
URL:
jdbc:weblogic:oracle
ドライバ クラス名:
weblogic.jdbc.oci.Driver
プロパティ:
user=scott
password=tiger
server=ora81
weblogic.codeset=MS932
以上でWebLogic Server jDriver for Oracle を使用できるようになります。
Oracle のoci ドライバを使用する場合の環境の設定方法
d:\oracle\ora81\jdbc\lib\classes12.zip;d:\oracle\ora81\jdbc\lib\nls_charset12.zip
c:\oracle\ora81\bin
ここまでの設定でWebLogic Server から接続プールを使わないで Oracle ociドライバを使用することができるようになります。例えば、JSPやServletなどのJDBCクライアントから直接データベースに接続することができます。JDBCクライアントがOracle ociドライバ を使用する場合のプログラミングについては、Oracle のマニュアルを参照してください。
接続プールを使用する場合はさらに次の設定を管理コンソールから行う必要があります。接続プールの設定の詳細については、『 WebLogic Server 管理者ガイド』の「JDBC 接続の管理」を参照してください。以下に設定例を説明します。
URL:
jdbc:oracle:oci8:@ora81
ドライバ クラス名:
oracle.jdbc.driver.OracleDriver
プロパティ:
user=scott
password=tiger
以上でOracle Oci ドライバを使用できるようになります。
Oracle の thin ドライバを使用する場合の環境の設定方法
Thin ドライバではNLS_LANG環境変数は必要ありません。
d:\oracle\ora81\jdbc\lib\classes12.zip;d:\oracle\ora81\jdbc\lib\nls_charset12.zip
c:\oracle\ora81\bin
ここまでの設定でWebLogic Server から接続プールを使わないで Oracle thinドライバを使用することができるようになります。例えば、JSPやServletなどのJDBCクライアントから直接データベースに接続することができます。JDBCクライアントがOracle thinドライバ を使用する場合のプログラミングについては、Oracle のマニュアルを参照してください。
接続プールを使用する場合はさらに次の設定を管理コンソールから行う必要があります。接続プールの設定の詳細については、『 WebLogic Server 管理者ガイド』の「JDBC 接続の管理」を参照してください。以下に設定例を説明します。
URL:
jdbc:oracle:thin:@jpsol1:1521:ora81
ドライバ クラス名:
oracle.jdbc.driver.OracleDriver
プロパティ:
user=scott
password=tiger
以上で Oracle thin ドライバを使用できるようになります。
異なるエンコーディングのDBに同時に接続する場合の制限事項
OCIドライバを使用する場合、NLS_LANGとweblogic.codeset の指定をセットで同じエンコーディングに指定する必要があります。これらのパラメータをセットで同じに設定しておけば、Oracle側からは特定のNLS_LANGを持つ一つのクライアントとして接続するため、エンコーディングの変換はOralce側が行います。例えばOracleDBがEUC-JPであっても、NLS_LANGとweblogic.codesetが両方ともSJISの場合、Oracle側が適当なエンコーディングの変換を行います。2つのパラメータが同じであればDBのエンコーディングが何であっても接続には問題ありません。
DBを使用する際のエンコーディング変換の注意
プラットフォームネイティブのエンコーディングから Java のエンコーディングへのコンバージョンと Java からプラットフォームネイティブのエンコーディングへのコンバージョンでは同じコンバータを使用しないと正しく文字を扱えない場合があります。これはUnicodeとJISの定義により生じる問題です。
ネイティブ <-> Java間でのエンコーディングコンバージョンで、例えば
DB -------------> WLS -------------> Web ブラウザ
SJIS MS932
のコンバータを使用すると、次のコードが正しく扱えません。
-------------------
"〜" (0x8160)
"‖" (0x8161)
"¢" (0x8191)
"−" (0x817C)
"£" (0x8192)
"¬" (0x81CA)
この場合は、WLS 上から Web ブラウザ への出力にSJISを明示的に使用する必要があります。たとえばJSPの page タグで
<%@ page contentType="text/html; charset=Shift_JIS" %>
と指定していた場合、この 'Shift_JIS' の指定をMS932ではなく、SJISのコンバータを使用してUnicode からネイティブへの変換をしなければなりません。
したがって、このような場合WebアプリケーションのDeployment Descriptor である weblogic.xml に次の定義を記述してWLSが内部的に持つデフォルトのエンコーディング対応テーブルを変更する必要があります。
<charset-params>
<charset-mapping>
<iana-charset-name>
Shift_JIS
</iana-charset-name>
<java-charset-name>
SJIS
</java-charset-name>
</charset-mapping>
</charset-params>
その他
iMode文字を使用する場合
JavaのMS932エンコーディングテーブルは外字エリアのコンバージョンに対応しています。MS932 を使用することで iMode外字を使用したコンテンツを提供することが可能です。
日本語サンプルプログラム examples_ja 以下をビルドするにはSJISロケールが必要
WLS7.0の日本語サンプルコードはShift_JISで提供されています。このため、ビルドするためには antを起動するシェルはSJIS環境にしておく必要があります。
既知の問題
WebLogic Builder
WebLogic Bulder でサーバのログ形式のメッセージが文字化けします。メッセージの内容を知りたい場合はCatInfo コマンドをお使いください。
例：エラーID 101247 が文字化けしていた場合
java.weblogic.i18ntols.CatInfo -id 101247
メッセージカタログの英文との違い
サーバのエラーメッセージに以下の間違いがあります。
Security.xml
誤: 090098: サーバ {1} 上のデフォルト KeyStore ファイル {0} にアクセスできません。
正: 090098: サーバ {1} 上のレルム {2} の jdk cacerts KeyStore {0} にアクセスできません。
誤: 090099: Cannot find default trusted CA KeyStore file {0} on server {1}.
正: 090099: サーバ {1} 上のレルム {2} の jdk cacerts KeyStore {0} にアクセスできません。
（このメッセージは変更になっていましたが、英語で表示されているので関係ないですね。）
Deployer.xml
誤: USAGE_TIMEOUT デプロイメント タスク完了までの最大待機時間（秒）。この期間が経過すると、現在のステータスが出力されてプログラムは終了します。
正: USAGE_TIMEOUT デプロイメント タスク完了までの最大待機時間（秒）。この期間が経過すると、現在のステータスが出力されてプログラムは終了します。この属性に値が設定されていない場合、デフォルト値 3600 秒が使用されます。
DeployerRuntime.xml
(severity の変更 error -> warning)
誤: 149055: 対象サーバ {1} をモジュール {3} に追加する試みは拒否されます。対象サーバがクラスタ {0} のメンバであり、別のメンバ {2} もそのモジュールの対象となっているためです。
正: 49055: クラスタ {0} のサーバ {1} をモジュール {3} の対象として追加しています。このモジュールには、別の対象として同じクラスタに含まれるサーバ {2} が含まれます。クラスタ全体を対象とするのではなく、クラスタ内の複数の個別のサーバを対象として持つ場合、ロード バランスおよびスケーラビリティが最適化されなくなる場合があります。このため、通常お勧めできません。
Appendix A: WLSで既に定義している MIME-Java エンコーディングマップ
ervletで response.setContentType()を呼び出した後で、 getWriter() により返される Writer に使用されるエンコーディングは次のとおりです。
| charset name | Java encoding name |
| ANSI_X3.4-1968 | ASCII |
| iso-ir-6 | ASCII |
| ANSI_X3.4-1986 | ASCII |
| ISO_646.irv:1991 | ASCII |
| ISO646-US | ASCII |
| US-ASCII | ASCII |
| us | ASCII |
| IBM367 | ASCII |
| cp367 | ASCII |
| csASCII | ASCII |
| ASCII | ASCII |
| Big5 | Big5 |
| csBig5 | Big5 |
| IBM037 | Cp037 |
| cp037 | Cp037 |
| ebcdic-cp-us | Cp037 |
| ebcdic-cp-ca | Cp037 |
| ebcdic-cp-wt | Cp037 |
| ebcdic-cp-nl | Cp037 |
| csIBM037 | Cp037 |
| IBM1026 | Cp1026 |
| CP1026 | Cp1026 |
| csIBM1026 | Cp1026 |
| windows-1251 | Cp1251 |
| windows-1252 | Cp1252 |
| windows-1253 | Cp1253 |
| windows-1254 | Cp1254 |
| windows-1255 | Cp1255 |
| windows-1256 | Cp1256 |
| windows-1257 | Cp1257 |
| windows-1258 | Cp1258 |
| IBM273 | Cp273 |
| CP273 | Cp273 |
| csIBM273 | Cp273 |
| IBM277 | Cp277 |
| EBCDIC-CP-DK | Cp277 |
| EBCDIC-CP-NO | Cp277 |
| csIBM277 | Cp277 |
| IBM278 | Cp278 |
| CP278 | Cp278 |
| ebcdic-cp-fi | Cp278 |
| ebcdic-cp-se | Cp278 |
| csIBM278 | Cp278 |
| IBM280 | Cp280 |
| CP280 | Cp280 |
| ebcdic-cp-it | Cp280 |
| csIBM280 | Cp280 |
| IBM284 | Cp284 |
| CP284 | Cp284 |
| ebcdic-cp-es | Cp284 |
| csIBM284 | Cp284 |
| IBM285 | Cp285 |
| CP285 | Cp285 |
| ebcdic-cp-gb | Cp285 |
| csIBM285 | Cp285 |
| IBM297 | Cp297 |
| cp297 | Cp297 |
| ebcdic-cp-fr | Cp297 |
| csIBM297 | Cp297 |
| IBM420 | Cp420 |
| cp420 | Cp420 |
| ebcdic-cp-ar1 | Cp420 |
| csIBM420 | Cp420 |
| IBM424 | Cp424 |
| cp424 | Cp424 |
| ebcdic-cp-he | Cp424 |
| csIBM424 | Cp424 |
| IBM437 | Cp437 |
| cp437 | Cp437 |
| 437 | Cp437 |
| csPC8CodePage437 | Cp437 |
| IBM500 | Cp500 |
| CP500 | Cp500 |
| ebcdic-cp-be | Cp500 |
| ebcdic-cp-ch | Cp500 |
| csIBM500 | Cp500 |
| IBM775 | Cp775 |
| cp775 | Cp775 |
| csPC775Baltic | Cp775 |
| IBM-Thai | Cp838 |
| csIBMThai | Cp838 |
| IBM850 | Cp850 |
| cp850 | Cp850 |
| 850 | Cp850 |
| csPC850Multilingual | Cp850 |
| IBM852 | Cp852 |
| cp852 | Cp852 |
| 852 | Cp852 |
| csPCp852 | Cp852 |
| IBM855 | Cp855 |
| cp855 | Cp855 |
| 855 | Cp855 |
| csIBM855 | Cp855 |
| IBM857 | Cp857 |
| cp857 | Cp857 |
| 857 | Cp857 |
| csIBM857 | Cp857 |
| IBM860 | Cp860 |
| cp860 | Cp860 |
| 860 | Cp860 |
| csIBM860 | Cp860 |
| IBM861 | Cp861 |
| cp861 | Cp861 |
| 861 | Cp861 |
| cp-is | Cp861 |
| csIBM861 | Cp861 |
| IBM862 | Cp862 |
| cp862 | Cp862 |
| 862 | Cp862 |
| csPC862LatinHebrew | Cp862 |
| IBM863 | Cp863 |
| cp863 | Cp863 |
| 863 | Cp863 |
| csIBM863 | Cp863 |
| IBM864 | Cp864 |
| cp864 | Cp864 |
| 864 | Cp864 |
| csIBM864 | Cp864 |
| IBM865 | Cp865 |
| cp865 | Cp865 |
| csIBM865 | Cp865 |
| IBM866 | Cp866 |
| cp866 | Cp866 |
| 866 | Cp866 |
| csIBM866 | Cp866 |
| IBM868 | Cp868 |
| cp868 | Cp868 |
| CP868 | Cp868 |
| cp-ar | Cp868 |
| 868 | Cp868 |
| csIBM868 | Cp868 |
| IBM869 | Cp869 |
| cp869 | Cp869 |
| 869 | Cp869 |
| cp-gr | Cp869 |
| csIBM869 | Cp869 |
| IBM870 | Cp870 |
| cp870 | Cp870 |
| CP870 | Cp870 |
| 870 | Cp870 |
| ebcdic-cp-roece | Cp870 |
| ebcdic-cp-yu | Cp870 |
| csIBM870 | Cp870 |
| IBM871 | Cp871 |
| cp871 | Cp871 |
| CP871 | Cp871 |
| ebcdic-cp-is | Cp871 |
| 871 | Cp871 |
| csIBM871 | Cp871 |
| IBM918 | Cp918 |
| cp918 | Cp918 |
| CP918 | Cp918 |
| ebcdic-cp-ar2 | Cp918 |
| 918 | Cp918 |
| csIBM918 | Cp918 |
| EUC-KR | EUC_KR |
| csEUCKR | EUC_KR |
| Extended_UNIX_Code_Packed_Format_for_Japanese | EUC_JP |
| csEUCPkdFmtJapanese | EUC_JP |
| EUC-JP | EUC_JP |
| ISO-2022-KR | ISO2022KR |
| csISO2022KR | ISO2022KR |
| ISO-2022-JP | ISO2022JP |
| csISO2022JP | ISO2022JP |
| ISO-2022-CN | ISO2022CN |
| JIS_X0201 | JIS0201 |
| X0201 | JIS0201 |
| csHalfWidthKatakana | JIS0201 |
| JIS_C6226-1983 | JIS0208 |
| iso-ir-87 | JIS0208 |
| x0208 | JIS0208 |
| JIS_X0208-1983 | JIS0208 |
| csISO87JISX0208 | JIS0208 |
| JIS_X0212-1990 | JIS0212 |
| x0212 | JIS0212 |
| iso-ir-159 | JIS0212 |
| csISO159JISX02121990 | JIS0212 |
| KOI8-R | KOI8_R |
| csKOI8R | KOI8_R |
| Shift_JIS | Shift_JIS |
| Shift-JIS | Shift_JIS |
| MS_Kanji | MS932 |
| csShiftJIS | SJIS |
| x-sjis | MS932 |
| sjis | SJIS |
| UTF-8 | UTF8 |
| UTF8 | UTF8 |
| utf8 | UTF8 |
| utf-8 | UTF8 |
|
|
|
||
|
|
|
 |
 |
|
|
||