| Download Docs | Site Map | Glossary | |
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > |
|
Notes on Using WebLogic Server 7.0J in Japanese Environment
|
Notes on Using WebLogic Server 7.0J SP7 in Japanese Environment
Changes from WebLogic Server 7.0 SP4
Setting up WebLogic Server 7.0 SP5 or later to use jRockit
Installer for RedHat Linux AS2.1
The supported JVM for RedHat Linux AS2.1 is jRockit. However, the installer for WebLogic Server 7.0 SP5 or later is not bundled with jRockit.
Download the jRockit installer from our Web site http://www.beasys.co.jp/evaluation/index.html and install it to your machine.
Then, modify some files as required. To use jRockit on Weblogic Server, follow these steps for modifying the files:
[Windows]
• On 73rd line, change the path of jdk java command to the path of jRockit java command.
• On 19th line, for javac path of JavaCompiler, change from jdk javac path to jRrockit javac path.
• On 19th line, for javac path of JavaCompiler, change from jdk javac path to jRrockit javac path.
• On 63rd line, change the JAVA_HOME environment variable to the directory where you installed jRockit.
• On 256th line, for javac path of JavaCompiler, change from jdk javac path to jRrockit javac path.
• On 41st line, change the JAVA_HOME environment variable to the directory where you installed jRockit.
• On 6th line, change the JAVA_HOME environment variable to the directory where you installed jRockit.
• On 87th line, change the COMM_JAVA_HOME environment variable to the directory where you installed jRockit.
• On 97th line, change the COMM_JAVA_VENDOR environment variable to "BEA".
• On 61st line, change the JAVA_HOME environment variable to the directory where you installed jRockit.
Now, the modifications of files are completed.
[Linux]
Typical Installation
[ex.] 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
For console-mode installation, see here
http://e-docs.bea.com/wls/docs70/install/instcon.html#804367)
Upgrade Installation
[ex.] 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
For console-mode installation, see here
(http://e-docs.bea.com/wls/docs70/install/instsp.html#1092933)
Using multi-byte characters in URL (CR092089)
As of WebLogic Server 7.0 SP2, you can handle multi-byte characters in URLs on the Servelet Container (Web Container). You may need setting up the server, depending on the user agent (e.g. Web browser) used to access the server.
For example, if the server receives the HTTP request for the following URL: http://myHostName:port/myContextPath/myRequest/?myRequestParameter
The following sections illustrate how "myContextPath" and "myRequest" portions of the URL are handled. (*1)
(Decodes URL encoding presuming base encoding as UTF-8)
By default, WebLogic Server 7.0 SP2 handles the URL of the HTTP request as follows.
For example, if the user agent (Web browser) is Microsoft Internet Explorer, the multi-byte characters typed in the address bar are encoded into UTF-8, and then URL-encoded, by default. As of WebLogic Server 7.0 SP2, you can get the properly decoded Strings of the URL sent in UTF-8 encoding by default. (*2)
If the user agent is Netscape, the characters typed in the address bar are encoded into the character set of environment where Netscape runs. Then, the characters are URL-encoded and sent to the server. For example, on the Japanese version of Windows, the characters are encoded into MS932 and then URL-encoded. As of WebLogic Server 7.0 SP2, you can get the requested URLs properly, by configuring the server to decode URL-decoded byte stream as in MS932 encoding. By specifying startup option for WebLogic Server, you can set the encoding in which the URL-decoded characters are decoded:
-Dweblogic.http.URIDecodeEncoding=MS932
(Default for URIDecodeEncoding is UTF-8.)
Note that you can choose only one encoding for each server instance.
If you need to use multi-byte characters in the URI of the request, the characters are to be encoded into UTF-8 octets, then URL-encoded and sent to WebLogic Sever. It is recommended by W3C to URL-encode based on UTF-8 when creating URI. (http://www.w3.org/TR/charmod/#sec-URIs)
(*1) : "myRequestParameter" portion is URL-decoded and then decoded as the encoding which is specified by setCharacterEncoding() in the servlet or input-charset in weblogic.xml. "myHostName" portion is going to be standardized by IESG as an international domain name.
(*2):You should check (enable) Internet Options->Advanced->Always send URLs as UTF-8 (requires restart) option in IE.
Known Problems
In some cases, multi-byte characters in the config.xml file cannot be converted properly when updating the config.xml by "migrate" command.
If the server does not run after the migration, you should suspect this.
To solve this problem, open the config.xml file by an UTF-8 conscious editor, and delete the characters surrounded by double quotations in Notes="xxx" (where the strings are corrupted), in the following tag.
Now, you can start the server, and the "Notes" attribute will be
recovered when the server starts up.
OutOfMemoryError may occur when you execute a migrate.sh command to migrate from SP1 to SP2 on HP platform,
In $WL_HOME/server/bin/ant file, change JAVA_HOME from jdk131_06 to jdk131_08, and run the migrate.sh command.
JDK paths of the following files also need to be modified. Change them from jdk131_06 to jdk131_08 in the same way.
$WL_HOME/server/bin/startWLBuiler.sh
$WL_HOME/ebcc/bin/ebcc.sh
Multibyte characters cannot be used in filenames for application files uploaded with Administration Console.
The filenames containing multibyte characters will be garbled when uploaded.
Fixed problems
This problem has been fixed in this release.
Changes from WebLogic Server 6.1
SOAP1.1 Compliant Multi-bytes Character Handling for Web Services
As of WebLogic Server 7.0 SP1, encode handling while exchanging SOAP messages or WSDL files on the WebLogic Server conforms to SOAP1.1 specification, and is compliant to RFC2376. This allows WebLogic Server to handle SOAP messages and WSDL files using the encoding specified in RFC.
WebLogic Server 7.0 SP1 uses a contentType charset parameter in HTTP header when it encodes SOAP messages (i.e. SOAP1.1 messages) with text/xml HTTP media type.The encoding attribute in XML declaration is ignored. If charset is not specified with contentType, the message is handled as us-ascii encoding according to RFC2376.
In older versions of WebLogic Server's Web service implementation, XML encoding attribute in a SOAP message is used to determine encoding, and HTTP contentType is ignored. This causes SOAP specification uncompliant behavior when SOAP message's XML declaration has no encoding attribute or HTTP contentType and SOAP message's encoding attributes are different. In this release, encoding handling for SOAP messages is compliant with RFC2376, as referred to in the SOAP1.1 specification.
Note that some SOAP implementation does not conform to RFC. We recommend to set HTTP contentType and XML encoding attribute on SOAP to the same value.
All SOAP messages and WSDLs generated by the WebLogic Server and the webservice Java Proxy are encoded in UTF-8. In generation process, 'encoding=utf-8' is added to the XML declaration and 'text/xml;charset=utf-8' is added to the contentType.
Change of Behavior to Conform to JSP J2EE
In WebLogic Server 7.0 SP1, the 'Fatal translation Error' occurs if multiple page directives exist (CR066562). This change is done for conformity to JSP 1.2 specification.
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.
According to this specification, if multiple page directives are found in a single translation unit, fatal translation error will occur. In WebLogic Server 7.0 SP1, the behavior of JSP is changed to conform this specification.
With this change, you will have troubles if an include origin and a include destination both have own page directive when you include a JSP file into another one using static include ( <%@ include file=... %> ). In static include, the JSP container evaluates whole JSP generated by include as a single translation unit, so that a multiple page directive will be detected. And this causes the 'Fatal translation Error'.
This may cause problems when you use JSPs written for older version of WebLogic Server. To avoid this, the following option is added as a parameter of weblogic.xml in WebLogic Server 7.0.
Code list 1-1 New parameter added to weblogic.xml
<jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
This parameter suppresses the fatal translation error for multiple page directives in a single translation unit, provided that each page directive specifies same encoding. This allows you to use your JSPs which written for older versions of WebLogic Server without modification.
Specifying the J2EE Default Encoding
In WebLogic Server 7.0 SP1, you can specify default character encoding for HTTP request in all J2EE enterprise applications (CR065921).
This is done by setting one of the following parameters.
These values can be overridden by specifying the input-charset in weblogic.xml for a request stream, the setCharacterEncoding or the ContentType charset in a HTTP header.
Note that the value specified in webapp.encoding.default (java_encoding_name) is the Java encoding name rather than IANA character set name.
If you set both above 2 options, the webapp.encoding.usevmdefault will be used.
Code list 1-2 Usage of webapp.encoding.usevmdefault 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>
Code list 1-3 Usage of webapp.encoding.default in weblogic_application.xml
<application-param>
<description>default encoding</description>
<param-name>webapp.encoding.default</param-name>
<param-value>SJIS</param-value>
</application-param>
Specifying the Encoding for WTC TUXEDO Domain (CR052022)
In WebLogic Server 7.0 SP1, you can specify the wtc domain encoding for the TUXEDO domain. This is done by specifying the following parameter when you start the WebLogic Server. You can add this in server's start up script (e.g. StartWebLogic.cmd).
-Dweblogic.wtc.encoding=java_encoding_name
The encoding set by this parameter is valid for whole TUXEDO domain.
XML Multi-bytes Character Handling in StreamParser
In WebLogic Server 7.0 SP1, to add an encoding information in the XML header generated using XML Streaming API, use createStartDocument() of the ElementFactory class as following.
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();
The followings are notes on parsing XML document containing Japanese characters using XML Streaming API. Main points are the same as in the notes on using the xerces parser.
This enables XML encoding auto detection of the parser, so that parser can generate a character stream using the encoding specified by encoding attribute in XML declaration, which assures appropriate parsing.
Handling of the Encoding in DD Files
In WebLogic Server 7.0 SP1, the limitation on using multi-bytes characters in DD (Deployment Descriptor) files of J2EE component (.ear, .war, .jar, .rar files) is removed. This ensures appropriate encoding handling of DD files as specified in XML declaration for all components. In addition, when you edit the DD file and save changes in WebLogic Builder or Administration Console, the encoding of the file is kept as the original file. If the DD file has no encoding attribute in the XML declaration or has no XML declaration, the file is handled as UTF-8.
2. Overview of I18n in WebLogic Server
Main features of I18n in WebLogic Server:
You should understand how to specify appropriate encoding specific to Java and J2E before you build a distributed system that handles data with multi-byte characters using WebLogic Server. Moreover, you should control the encoding conversion with due regard for the encoding handling of the system (e.g. operating system, the Internet, backend system) connected to WebLogic Server.
The following is a concise description of the encoding handling in WebLogic Server.
This allows WebLogic Server to handle characters of all languages at the same time, provided that their characters can be handled by Unicode.
In ordinary operating systems there is almost no environment working with Unicode, which is internal encoding of Java. Operating systems work with encoding called 'native encoding' which is defined individually for each platform. For example, the native encoding of the Windows system is a code page relevant to the language, the native encoding of the Unix system is encoding corresponding to the locale which is specified with the LANG environment variable, and the native encoding of a data base is a character set specified at the time of data base creation or the character set specified by the client.
Because of this situation, encoding conversion between native encoding and Unicode is needed when input and output is done in WebLogic Server. This encoding conversion always occurs when WebLogic Server exchanges character data with an operating system or an external resource (*Note).
The encoding conversion process utilizes a large amount of CPU resource, because the conversion is done for individual characters. Avoiding code conversion is good practice in the designing of an application to ensure better system performance.
*Note: Characters included in a serialized Java class stream are held as (UTF-8 encoded) Unicode in the internal information of the class. This means that you do not need to consider code conversion for serialized streams. For example, you do not need to consider encoding for EJB or RMI.
In WebLogic Server, the encoding of the server log or the Administration Console is determined by the default encoding of a server's Java VM or a browser's language setting independently of the encoding of the application component or the language of the content that the WebLogic Server is serving.
Moreover, you can configure the WebLogic Server's behavior independently of the locale or the language on which the WebLogic Server is working.
Also, you can set the encoding conversion individually for resources configured on the WebLogic Server's container.
There are three categories of target for which the encoding conversion is applied, as followgs:
The encoding conversion of WebLogic Server itself includes:
System log output of WebLogic Server
Page encoding of the Administration Console
File I/O between WebLogic Server and local file system
The encoding conversion of individual applications includes:
JSP files
Servlets
DD files
XMLs
Web services
Resources on WebLogic Server include:
JDBC connection
WTC connection etc.
When you specify the encoding on WebLogic Server, you need to make clear for which categories you are specified the encoding. Then you need to check if a valid Character object can be created and if a Character object in WebLogic Server can be properly converted tothe intended encoding.
As indicated above, you should understand the behavior of the encoding conversion for appropriate setting. If you do not specify the encoding conversion, applications may not handle multi-byte characters properly.
If you do not specify the encoding, the default encoding appropriate for the situation is used. The default encoding may vary according to the target's specification or the environment.
Because different default encoding is used for different targets, as indicated above, WebLogic Server cannot handle Japanese properly if you do not specify the appropriate encoding. You should understand following sections to be able to control the encoding conversion.
JThe encoding or the character set means the definition which assigns computer-readable codes to the set of characters of a specific language so that the computer can deal with these characters. This definition is called "encoding" in the Java terminology, "character set" in the Internet terminology and "code page" in the Windows terminology, and is handled as one of the attributes of a locale on Unix. In addition to this, there are various subtypes of "Shift JIS" character set. Each hardware or software vendor uses different "Shift JIS" subtypes
Java language absorbs these differences in its I/O section, so that it handles all character as Unicode inside it. This means that Java can handle any character set as long as the encoding definition for the character set exists, and can absorb any encoding differences existing between various systems. However, there is no encoding conversion table that handles all minor differences of all existing encodings at the present time. Also, there are some limitations on the existing encoding table that result from the problem of consistency with Unicode.
In Java Web application servers, the difference between the Java encoding name and the MIME character set is especially important. The MIME character set is defined by IANA, which is used on the Internet and in a XML files. WebLogic Server uses a mapping table which associates the Java encoding name and the IANA character set name to absorb this difference. Using this table, WebLogic Server can handle a file defined as 'Shift_JIS' on JSP or as 'MS932' with the Java encoding name. You can modify the mapping table of WebLogic Server to handle the 'Shift_JIS' character set as 'cp943' Java encoding.
Xerces is a built-in XML parser of the WebLogic Server, and it has its own IANA-to-Java mapping table. The user cannot customize this mapping. For example, the IANA charset name of 'Shift_JIS' is mapped to the Java encoding name of 'SJIS'.
Basically, in WebLogic Server, use a Java encoding name to specify encoding. In J2EE, Internet or XML, use the IANA character set name. You can modify this mapping as necessary.
3. Installation
WLS 7.0 provides a Japanese-version installer and an English-version installer. The former can be downloaded from the BEA Systems Japan Ltd web site, and the latter can be downloaded from the BEA Systems, Inc. web site.
These two installers are the same with regard to program files that affect the behavior of WebLogic Server, and you can regard them as having the same software. In addition, you will have no problem about interoperability between the WebLogic Server installed using the English-version installer and that installed using the Japanese-version installer. The differences between the Japanese-version installer and the English-version installer are as follows:
In the WebLogic Server 7.0J, the following features are not available:
4. WebLogic Server System Administration
The following items work with the JVM default encoding for the WLS server:
The following item works with the default language of the browser:
To change the encoding for log output, etc., working with the server default encoding, use the following procedure:
Encoding in WebLogic Server and the Java Virtual Machine (JVM)
In WebLogic Server 7.0, you can set the encoding with various scopes. For example, you can set the ContentType/Charset to specify the encoding that WebLogic Server outputs to a client. Also, you can use the weblogic.codeset property to specify the encoding for a JDBC connection when using WebLogic jDriver. These and many other features are discussed in this document.
Note that there is no relationship between the encoding that you specify for a particular scope and the default encoding for the Java VM on which WebLogic Server runs. If the Java VM is running in the English locale, there is no problem in providing services using Japanese JSP files. However, the handling of the following strings is dependent on the Java VM default encoding:
These strings work with the Java VM default encoding for each platform (the encoding specified by the file.encoding Java system property). For example, the language and encoding of log messages which WebLogic Server outputs to a terminal console are dependent on the encoding specified in the Java VM. The file.encoding java system property is based on the platform environment and the system locale. If you want to switch the language and encoding of the WebLogic Server log messages, you need to switch the system locale accordingly. You cannot switch the Java VM default encoding dynamically once the VM has been started. Make sure of the following settings before you restart WebLogic Server.
For Windows 2000/Windows NT
Select English (U.S) or Japanese from the Regional option in the Control Panel. This allows the server to use CP1252 or MS932 as the default encoding.
For UNIX
Specify the locale supported by your platform in the LANG environment variable.
Below are the settings of the server encoding and the LANG environment variable:
For example, if you specify EUCJIS on Solaris, the LANG setting looks like this:
LANG=ja
How to Check the Server Encoding
The Java VM default encoding becomes the WebLogic Server default encoding. You can check the encoding by referring to the log messages from the Administration Console. The following are the steps:
The displayed encoding is the server encoding.
Notes on Configuring Administration and Managed Servers
In WebLogic Server 7.0, you must set the same encoding for all of the servers in a domain.
If a server of which the encoding is different from the others exists within the domain, that server's log will not be displayed correctly.
Notes on Configuring Clusters
In WebLogic Server 7.0, you must set the same encoding for all of the servers in a cluster.
If a server of which the encoding is different from the others exists within the cluster, that server's log will not be displayed correctly.
Encoding for config.xml
The config.xml file is input/output in UTF-8. When editing the file directly with a text editor, read and save in utf-8.
Limitation on Using as a Web Server (fileservlet)
Limitation on Using as a Web Server (fileservlet)
<mime-mapping>
<extension>htm</extension>
<mime-type>text/html;charset=Shift_JIS</mime-type>
</mime-mapping>
This allows you to omit the charset setting in the HTML file by using a META tag such as:
<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=Shift_JIS">
JDBC Connection
When creating a JDBC connection pool, you must specify the appropriate encoding for a connection to the DB which uses multi-byte characters. You may need to match the encoding conversion mapping between the Web layer and the DB layer.
For more information, see the following sections.
jDriver for Oracle
http://e-docs.bea.com/wls/docs70/oracle/advanced.html#415150jDriver for MS SQL Server
http://e-docs.bea.com/wls/docs70/mssqlserver4/API_jmsq4.html#522789"
Deployment
In WebLogic Server, the encoding for multi-byte characters in the DD file of the J2EE component is handled as specified in the XML declaration. If the DD file has no encoding attribute in the XML declaration or has no XML declaration, the file is handled as UTF-8.
When you edit the DD file and save changes in WebLogic Builder or Administration Console, the encoding of the file is kept as in the original file.
DD files created in WebLogic Builder or Administration Console have no XML declaration. When you change the encoding of such a file, set the encoding attribute in the XML declaration appropriately.
Notes on Using Administration Console
The Language at Administration Console's Startup
The language displayed when the Administration Console first starts is the preference language specified in your Web browser. For example, if you are using the Japanese version of Windows and Internet Explorer, the Administration Console will be displayed in Japanese when it first starts. If you want to change the language first displayed to English, you can change it by setting the preference language in your browser to English.
The languages you can select for the Administration Console in WLS 7.0 SP1 are:
Select SJIS or EUCJIS according to the encoding for the Administration Server to which the Administration Console is connected.
Select SJIS or EUCJIS according to the encoding for the Administration Server to which the Administration Console is connected.
Select the desired language from the Language drop-down list on the Preferences page on the Console's home page.
5. Programming
JSP/Servlet ----- Notes on Using Servlets and JSPs
Encoding Conversion, Standards, Scope and Preference
WebLogic Server 7.0 is a Java application program. All strings are handled internally as Unicode strings. On the other hand, various charsets are used for HTML pages. In WebLogic Server, the encoding conversion between Unicode and the HTML charsets is performed by using the Java encoding converter when handling HTML data.
In WebLogic Server 7.0, some of the ways that you set the encoding are defined by the J2EE specification. Others are WebLogic proprietary specifications. You need not specify all of them. Read the following description and combine the most appropriate encoding settings for your environment.
Encoding Settings
The encoding settings related to JSP/Servlet include:
Basically, the more specific definition of scope will take priority. For example, if Shift_JIS is set as the default encoding for the JSP container, and EUC-JP is specified in the page tag of a specific JSP, then the encoding specified in the page tag will take priority (i.e. EUC-JP will be used).
It is recommended that you use the same particular encoding throughout your application, or you should set the encoding you primarily wish to use to cover a wide scope as at the JSP container level. Then for areas that require special encoding handling, set the encoding on a more specific level such as the JSP or servlet itself.
Specifying the Encoding
Regarding the following, note that if you do not specify any encoding for HTTP request and HTTP response then ISO-8859-1 encoding will be used.
For Servlets
For JSPs
For both Servlets and JSPs
The following sections give details of each setting of Servlet and JSP.
For Servlets
Specifying the Encoding for an HTTP Response --- response.setContentType()
To specify the encoding for an HTML page generated by a Servlet, use the setContentType() method.
Therefore, you must call the setContentType() before getting a writer.
res.setContentType("text/html;charset=Shift_JIS");
PrintWriter out = res.getWriter();
This call specifies the contentType in the HTTP header. This means that the encoding for your browser display is also specified.
Specifying the Encoding for an HTTP Request ---- request.setCharacterEncoding or <input-charset>
Now you have finished the setting of the encoding for an HTTP response which is data sent from WebLogic Server to a client using the above. The following describes how to set the encoding for an HTTP request when sending data from a client to WebLogic Server.
There are three ways to specify the encoding for an HTTP request:
his method is most compliant with the HTTP specification. However, you cannot specify the value in a Microsoft Internet Explorer or Netscape browser.
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
In WebLogic Server 6.1 or later versions, this is set in weblogic.xml. However, in WebLogic Server 6.0 it is set in web.xml. Also, the element names, etc., are changed. Therefore, in the case of migrating from WebLogic Server 6.0, the weblogic.xml and web.xml files will require modification. Please refer to the migration guide.
<input-charset> For example, you can set it so that encoding for request URLs is obtained as follows:
Write the <input-charset> for the target Web application in the deployment descriptor (weblogic.xml) as shown below.
In the<charset-param> (which is embedded in the <weblogic-web-app> ), write the request URL path for which you want to specify the encoding and the encoding which you want to specify for the HTTP request in the Java name.
For information about mapping between a Java encoding name and an IANA character set, see the uMapping Between a Java Encoding and an IANA (Setting in weblogic.xml)v Character Set (Setting in weblogic.xml)" section.
Below is an example of a single web-app that handles multiple encodings.
In the example below, the encoding for "/*" is set to Shift_JIS and the encoding for "/rus/jo/*" is set to ISO-8859-1. The latter definition is more specific and hence will take priority.
<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>
For more information about this setting, see the "Define character set parameters" section in the "Assembling and Configuring Web Applications".
http://e-docs.bea.com/wls/docs70/webapp/webappdeployment.html
As described above, in WLS, you can specify the encoding for the GET/POST
request for a particular content on the server side by defining the
For JSPs
Specifying the Encoding for a JSP File --- pageEncoding Directive in the page Tag (Optional)
To specify the encoding which the WebLogic Server 7.0 JSP container or JSP compiler uses to read a JSP file, specify the pageEncoding directive in the page tag as follows:
<%@ page contentType="text/html; charset=Shift_JIS" pageEncoding="Shift_JIS" %>
Specifying the Encoding for Page Output ---- contentType Directive in the page Tag
To specify the encoding for page output, specify the contentType directive in the page tag as follows:
<%@ page contentType="text/html; charset=Shift_JIS" %>
When the pageEncoding directive is not set, the contentType directive is used for the encoding for reading a JSP file.
If the JSP container finds the content type setting, it will stop parsing the JSP file, switch the file reader to this new-specified encoding, and parse the JSP page from the beginning again. If more than one contentType is specified in one file, a parsing error occurs (*Note). Therefore, when you include a file in another one using static include, if both files have their own encoding specification, an error occurs. In dynamic include, an error will not occur but garbled characters will be generated.
In addition, when you specify the contentType in the page directive, the same contentType is specified in the HTTP header for HTTP response. This means that the encoding for your browser display is also specified.
*Note: Even if more than one contentType is specified in one file, a parsing error can be suppressed, provided that each specifies the same encoding (See the "Static vs. Dynamic Includes, Encoding Differences" section).
< jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>α¦Ξ' include 'For example, if an 'include origin' and an 'include destination' both have their own page directive when you include using static include (<%@ include), and the single translation unit has multiple page directives, you will have no trouble, provided that each page directive specifies the same encoding.
You can specify the encoding for an HTTP request in a JSP the same way as in a Servlet. See the "For Servlets" See the "For Servlets"section.
<%
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
%>request.setCharacterEncoding or <input-charset>
Use the
See the "For Servlets" section.
For both Servlets and JSPs
For both Servlets and JSPs
When you specify the encoding using the setContentType() method or the contentType directive in the page tag, use an IANA character set name. However, when you handle the encodings in WebLogic Server 7.0, which is a Java application, these values must be Java encoding names. WebLogic Server 7.0 has the default mappings internally also and normally uses them. The default mappings also include mappings which are not defined in IANA, but are conventionally used in the Content-Type for HTML (See Appendix A).
Example: x-sjis ----> MS932
Note: In Java, the IANA character set Shift_JIS is handled as MS932 (From JDK 1.1.8 to JDK 1.4.0, Shift_JIS is handled as SJIS in JDK1.4.1 or later).
This allows you to use the MS932-specific characters (@,A, etc.) with the default setting.
You can overwrite the default mappings by defining the <charset-mapping> in weblogic.xml.
In the example below, Shift_JIS is mapped to SJIS.
<charset-params>
<charset-mapping>
<iana-charset-name>
Shift_JIS
</iana-charset-name>
<java-charset-name>
SJIS
</java-charset-name>
</charset-mapping>
</charset-params>Note that the above mappings are weblogic-specific.
Workaround to Encode an HTTP Request with ISO-8859-1 encoding
iIf ISO-8859-1 is specified as the encoding for an HTTP request in the <input-charset>, you can still obtain an HTTP request with a different encoding by using the following workaround.
new String(request.getParameter(itemQ[i]).getBytes ("8859_1"), "SJIS")However, an HTTP client whose contentType in the HTTP header for HTTP response is specified as follows cannot use this workaround, because the encoding specified in the contentType in the HTTP header will take priority over that specified in the
Content-Type: application/x-www-form-urlencoded;charset=shift_jis
Static vs. Dynamic Includes, Encoding Differences
Static Include
<%@ include file="relativeURL" %>
In this case, all the include files are loaded and gathered together in one file before JSP compile is performed, and therefore if the encoding is specified in the file that does the including, the included file will be handled as a file using the same encoding as the include file, even though it is not specified its encoding.In WLS 6.1 or earlier, a compiling error does not occur if an 'include origin' and an 'include destination' both have the same encoding specifications. In WebLogic Server 7.0, a compiling error will occur if both have their own page directive. To avoid this, set the 'backwardCompatible' in weblogic.xml to true.
Even though the backwardCompatible is set to true, a JSP compiling error occurs if the encoding settings are different between the 'include origin' and the 'include destination'.
Dynamic Include
<jsp:include page="{ relativeURL | <%= expression %>}" flush="true" />With dynamic includes, the page is not included when it is loaded, and left in the tag state. The page will be included when the JSP is executed. Therefore, the encoding set in the JSP that does the including will not apply to the included file(s).
Hence, you must also specify the encoding in the included file.
CGIServlet
When migrating a CGI service which uses multi-byte characters to a CGI servlet on the WebLogic Server, you must specify the appropriate contentType charset parameter in the HTTP header generated by the CGI program. If the contentType is not set, ISO-8859-1 is used, this being the default encoding for the J2EE Servlet container.
You must also use the appropriate
WebService
Handling of SOAP Messages and its Encoding
In the WebLogic Server Web service, encoding handling is compliant with the SOAP1.1 specification (*Note 1). HTTP/SOAP messages based on the SOAP1.1 specification have text/xml media type, and the encoding for these messages is handled according to RFC2376. The following are behaviors based on the RFC2376 specification:
WebLogic Workshop also acts according to this specification as well as WebLogic Sever 7.0 SP1. Therefore, make sure that the contentType charset is specified correctly for the client which calls the Web service(s) developed by WebLogic Workshop using HTTP/SOAP.
All the HTTP/SOAP messages generated by the WebLogic Server are encoded in utf-8. In the generation process, 'encoding=UTF-8' is added to the HTTP header of the SOAP message.
*Note: When you start the WebLogic Server on the English locale (e.g. LANG=C is specified on UNIX), only us-ascii characters can be used in SOAP messages. Other characters are not supported. When Japanese characters are used in the Web service(s), make sure that you start the WebLogic Server in the Japanese locale.
If you want to use characters other than us-ascii on the WebLogic Server started in the English locale, set the following startup option in the WebLogic Server startup script file. This generates messages in utf-8, even if the WebLogic Server is running on the English locale.
-Iweblogic.webservice.i18n.charset=utf-8
Web Services Home Page is generated in the server VM default encoding.
UDDI Explorer supports only us-ascii characters, and cannot use multi-byte characters properly.
The WebLogic Server 7.0 SP1 Web service does not support media types defined in the SOAP1.2 specification.
XML Multi-byte Characters Handling in StreamParser
In WebLogic Server 7.0 SP1, to add encoding information to the XML header generated using XML Streaming API, use createStartDocument() of the ElementFactory class as follows:
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();The followings are notes on parsing an XML document containing Japanese characters using XML Streaming API. The main points are the same as in the notes on using the Xerces parser.
Use byte stream when you supply input for the parser through a stream. This enables XML encoding auto-detection of the parser, so that the parser can generate a character stream using the encoding specified by the encoding attribute in the XML declaration, thus ensuring appropriate parsing.
The parser will ignore the encoding setting in the XML header when the input is made through the Unicode character stream.
JDBC
Setting Up the Environment for Using WebLogic jDriver for Oracle
To use the weblogic.jdbc.oci.Driver, set up the environment as follows. Note that you need to set the jDriver license.
Specify the path to the bin directory of Oracle and the path to the bin directory of WebLogic Oracle Oci driver native library. Use the appropriate Oci driver according to the Oracle version.
For Oracle 8.1.7:%WL_HOME%¥bin¥oci817_8;d:¥oracle¥ora81¥bin
For Oracle 9.0.1:%WL_HOME%¥bin¥oci901_8;d:¥oracle¥ora90¥bin
Both the encodings for the NLS_LANG and the weblogic.codeset which is a connection property for the jDriver for Oracle must be always the same.
NLS_LANG = japanese_japan.ja16sjis
For information about the relation between the NLS_LANG and the weblogic.codeset, see "Advanced Oracle Features" for Installing and Using WebLogic jDriver for Oracle. If you can specify the following encodings: ja16sjis for the Oracle database, japanese_japan.ja16sjis for the NLS_LANG, and MS932 for the weblogic.codeset, the character sets used on a Windows platform can be stored in the Oracle database.
Now, you can use the WebLogic Server jDriver for Oracle without using connection pools from WebLogic Server. For example, you can connect directly to the database from a JDBC client such as JSP or Servlet. For information about programming when a JDBC client uses the WebLogic Server jDriver for Oracle, see the "Connecting to an Oracle DBMS section in the chapter "Using WebLogic jDriver for Oracle" of Installing and Using WebLogic jDriver for Oracle."
If you use connection pools, you need to make the following settings in the Administration Console. For more information on how to set up connection pools, see the "Setting Up a Connection Pool" section in the chapter "Installing WebLogic jDriver for Oracle"of Installing and Using WebLogic jDriver for Oracle.
URL:
jdbc:weblogic:oracle
Driver Class Name:
weblogic.jdbc.oci.Driver
Properties:
user=scott
password=tiger
server=ora81
weblogic.codeset=MS932
Now, you can use the WebLogic Server jDriver for Oracle.
Setting Up the Environment for Using Oracle Oci Driver
d:\oracle\ora81\jdbc\lib\classes12.zip;d:\oracle\ora81\jdbc\lib\nls_charset12.zip
c:\oracle\ora81\bin
Now you can use the Oracle Oci driver without using connection pools from WebLogic Server. For example, you can connect directly to the database from a JDBC client such as JSP or Servlet. For information about programming when a JDBC client uses the Oracle Oci driver, see the Oracle documentation.
If you use connection pools, you need to make the following settings in the Administration Console. For more information on how to set up connection pools, see "Managing JDBC Connectivity" vin the WebLogic Server Administration Guide.
URL:
jdbc:oracle:oci8:@ora81
Driver Class Name:
oracle.jdbc.driver.OracleDriver
Properties:
user=scott
password=tiger
Now you can use the Oracle Oci driver.
Setting Up the Environment for Using Oracle Thin Driver
For the Thin driver, you need not specify the NLS_LANG environment variable.
d:\oracle\ora81\jdbc\lib\classes12.zip;d:\oracle\ora81\jdbc\lib\nls_charset12.zip
c:\oracle\ora81\bin
Now you can use the Oracle Oci driver without using connection pools from WebLogic Server. For example, you can connect directly to the database from a JDBC client such as JSP or Servlet. For information about programming when a JDBC client uses the Oracle Oci driver, see the Oracle documentation.
If you use connection pools, you need to make the following settings in the Administration Console. For more information on how to set up connection pools, see href="http://e-docs.bea.com/wls/docs70/adminguide/jdbc.html">"Managing JDBC Connectivity" in the WebLogic Server Administration Guide.
URL:
jdbc:oracle:thin:@jpsol1:1521:ora81
Driver Class Name:
oracle.jdbc.driver.OracleDriver
Properties:
user=scott
password=tiger
Now you can use the Oracle Oci driver.
Limitations when Connecting Simultaneously to Databases of which the Encodings are Different
When using the OCI driver, you must specify the same encoding for the NLS_LANG and the weblogic.codeset. If these parameters are set to the same value, the encoding conversion will be performed on the Oracle side because you are connected to the Oracle side as a client which has a particular NLS_LANG. For example, if both the encodings for the NLS_LANG and the weblogic.codeset are SJIS, the appropriate encoding conversion will be performed on the Oracle side, even though the encoding for the Oracle DB is EUC-JP. If the two parameters are the same, the connection will be made successfully regardless of the DB's encoding.
Notes on Encoding Conversion Using DB
If you do not use the same converter for the conversion between the platform native encoding and the Java encoding, the characters may be handled incorrectly. This problem is caused by the definition of Unicode and JIS.
For example, if you use the following converters on the encoding conversion between the platform native and Java..
DB -------------> WLS -------------> Web Browser
SJIS MS932
The following codes cannot be handled correctly:
-------------------
"`" (0x8160)
"a" (0x8161)
"" (0x8191)
"|" (0x817C)
"" (0x8192)
"Κ" (0x81CA)
In this case, you must use SJIS exclusively for the output from WLS to the Web browser. For example, if the following encoding is specified in the page tag in JSP:
<%@ page contentType="text/html; charset=Shift_JIS" %>
this Shift_JIS setting must be converted from Unicode to the native platform using the SJIS converter not the MS932 converter.
Therefore, in this case you must write the definition as follows in the deployment descriptor (weblogic.xml) for the Web application to change the default encoding mapping table that WLS has internally.
<charset-params>
<charset-mapping>
<iana-charset-name>
Shift_JIS
</iana-charset-name>
<java-charset-name>
SJIS
</java-charset-name>
</charset-mapping>
</charset-params>
6. Miscellaneous
When Using iMode Characters
Java's MS932 encoding table supports conversion to an external characters area. By using MS932, you can provide content using iMode external characters.
Japanese Code Examples in and below the \examples_ja Directory Need to be Built in SJIS Locale
WLS 7.0 provides Japanese code examples in Shift_JIS. Therefore, to build them set up your shell environment which runs the ant build script in SJIS.
7. Known Problems
WebLogic Builder
In WebLogic Builder, WebLogic Server log messages turn into garbled characters. Use the CatInfo command to display the message content.
Example: For the error ID 101247
java.weblogic.i18ntols.CatInfo -id 101247
Appendix A: MIME-Java Encoding Mapping Table Defined in WLS
The following are encodings used in a writer returned by getWriter() after calling response.setContentType() in a Servlet.
| 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 |
|
|
|
||
 |
|
|
 |
 |
 |
|
||