Internationalization in WebLogic Server

Overview of Internationalization

All characters inside WebLogic Server are expressed in Unicode. Therefore any input/ output operations of character data will lead to a code conversion.

The encoding conversion must be appropriately specified for WebLogic Server, J2EE component, and resources on the WebLogic Server J2EE container, respectively.

If you do not specify the encoding conversion, the default encoding conversion will be applied.

There are various types of default encoding conversions, and some of them do not conform to the locale of the operating system.

When you are to configure a distributed system that handles multibyte character data using WebLogic Server, you need to fully understand how to specify encoding methods particularly for Java and J2EE. Furthermore, you also need to sufficiently study how the encoding is done in operating system, internet and backend systems which are linked to WebLogic Server, to correctly control the encoding conversions.

The following is a concise description of the encoding handling in WebLogic Server.

Use of Unicode

This allows WebLogic Server to handle characters of all languages at the same time, provided that their characters can be handled by Unicode.

Encoding Conversion

The encoding conversion is needed when WebLogic Server exchanges character data with the outside.

In the common operating systems, the environment to use Unicode which is the internal code inside Java is very rare, instead the encoding called native encoding, which is defined individually for each platform, is generally performed. Some examples of native encoding would be, for Windows, the code page that corresponds to each language, for UNIX, the encoding that corresponds to the locale specified by LANG environment variables, and for databases, the character set specified when the database is generated or the character set for the clients.

For this reason, each time character input or output occurs at WebLogic Server, a conversion between native encoding characters and characters in Unicode must be performed in either way (character set conversion). This encoding conversion occurs every time when character data input/output takes place with the operating system or external resources.

Note: The characters included in the stream to which Java class is serialized do not require the code conversion since Unicode is preserved as internal information of the class after being encoded with UTF-8. Hence generally with EJB or RMI, no considerations on encoding are necessary.

Also, it must be noted that the encoding conversion requires relatively large CPU resources since the conversion must be done for each individual character. This leads to a suggestion that at the time of application designing phase you need to reduce the code conversion as much as possible to obtain better performance.

Separation between the Encoding Conversion for the Server Itself and the Encoding Conversion for Application Components and Resources on WebLogic Server

In WebLogic Server, the encoding conversion for the server itself and the encoding conversion for application components and resources on WebLogic Server are separate.

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, by deploying an application component to WebLogic Server, you can configure it to behave identically, regardless of any locale (language) environment the WebLogic Server is running in.

Also, you can set the encoding conversion individually for each resource configured on the WebLogic Server's container (ex. JDBC Connection Pool).

The encoding conversions of WebLogic Server itself include:

System log output of WebLogic Server

Page encoding of the Administration Console

File input/output operations with local file systems

The encoding conversions of individual applications include:

JSP files

Servlets

XML files

Web services

Resources on WebLogic Server include:

JDBC connection

WTC connection etc.

When you specify an encoding on WebLogic Server, you must clarify to which one of above three categories the encoding is to be applied. Furthermore, you must always be aware whether the right character object can be created in WebLogic Server, or the character object inside WebLogic Server is being correctly encoded and output as it is supposed to be.

As above, when multibyte characters are to be handled on WebLogic Server, the entire process of encoding conversion must be understood and any setting as necessary must be made. In some cases, the application software may not be able to handle the multibyte characters correctly without setting encoding conversion.

In any case, when encoding is not specified, some default encoding will be applied. The default encoding applied may vary with each specification and/or environment.

Example of the Default Encoding

The default encodings relating to the behavior of the WebLogic Server include:

Default encoding of a server VM

Default encoding of J2EEs

Default encoding of XML

Default encoding of the HTTP protocol

Default encoding of a Web browser

Default encoding of Web service (such as SOAP/WSDL/UDDI), etc.

Example:

Default encoding of Java VM in Japanese Windows is MS932

Default encoding of J2EE is ISO-8859-1

Default encoding of XML is UTF-8

Default encoding of HTTP is ISO-8859-1

Since, as shown above, a default encoding varies with the technical specification employed, specifying no encoding at all will lead to incorrect multibyte handling in WebLogic Server. Therefore the full understanding of each way to specify encodings described in the following chapters is strongly recommended to control encoding conversions.

The encoding means the "character set" in Java language terminology. There are a number of words that describe a character set, but the definition of each word is slightly different.

The 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.

Java absorbs these differences at the input/output stage, allowing it to use only Unicode always internally. This represents the excellence of Java to be able to handle any character set wherever encoding definition is available. In other words, Java is said to have the possibility to absorb all the differences of encoding that exist among various systems. However, at the moment, there is no encoding conversion table that can handle all minute differences. Also the existing encoding tables have some limitations due to the consistency with Unicode.

The xerces, an embedded XML parser in WebLogic Server has its own mapping table between IANA and Java. This cannot be customized by users. For example, a character name in IANA ‘Shift_JIS’ is mapped to ‘SJIS’ of Java’s encoding name.

In WebLogic Server, the encoding is basically specified by using encoding names of Java. Also, for J2EE, Internet and XML, IANA character set names are used. The user is requested to change this mapping as necessary.

How to specify Default Encoding for WebLogic Server's Container

WebLogic Server can specify encodings in various different effective areas. For example in JSP, the page tag compliant to JSP2.0 specification is provided to specify the encoding of the individual pages. The encoding for each effective area such as this is nothing to do with the default encoding for JavaVM with which WebLogic Server operates, in other words the encoding which an internal implementation of JavaVM determines from the locale environment of the operating platform. If the locale for JavaVM is English, there is no problem supplying services using JSP file containing multibyte characters. However, with regards to the following items, the character strings will be handled relying on the default encoding of JavaVM.

Log output of WebLogic Server

File input/output operations with local file systems

These will operate with default encoding of JavaVM. When the language and encoding of log messages of WebLogic Server need to be switched by replacing the platform locale, following must be specified. 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

From Control Panel - Region (or Regional Options), select a language, such as English (United States), Japanese, Korean, Chinese (PRC) and Chinese (Taiwan). By this selection, the server will operate using CP1252, MS932, MS949, GBK or MS950 as the default encoding.

For UNIX

Specify the locale supported by your platform in the LANG environment variable.

Some examples of encoding for server vs. LANG environment variables are shown below. For other combinations, consult with your platform manuals.

Platform

Encoding

LANG environment variable

Solaris

EUC-JP, SJIS

ja, ja_JP.eucJP, or ja_JP.PCK

Solaris

EUC-KR

ko or ko_KR

Solaris

GB2312, GBK

zh_CN or 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 or ko_KR

HP

GB2312

zh_CN.hp15CN

HP

GB18030

zh_CN.gb18030

HP

Big5

zh_TW.big5

For example, if you specify EUC-JP on Solaris, the LANG setting looks like this:

LANG=ja

Notes on Configuring Administration and Managed Servers

Use the same encoding for all the WebLogic Servers through out a domain.

In WebLogic Server, it is necessary to have the same encoding settings for all the servers in the domain.

For example, when a Windows platform exists within a domain, standardize with MS932 encoding. In the case of a server with different encoding, that servers' log will not show correctly.

Notes on Configuring Clusters

Use the same encoding for all the WebLogic Servers in a cluster.

In WebLogic Server, it is necessary to have the same encoding settings for all the servers in the cluster.

For example, when a Windows platform exists within a cluster, standardize with MS932 encoding. In the case of a server with different encoding, that servers' log will not show 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.

JDBC connection

When creating a JDBC connection pool, you must specify an appropriate encoding for a connection to a DB which uses multibyte characters. Also depending upon the requirements from the system to be built, encoding conversion mappings for Web layer and DB layer may have to be matched.

Deployment

In WebLogic Server, multibyte characters in DD files of J2EE components are handled according to 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.

Notes on Using Administration Console

Displayed Language on Administration Console

The language displayed when Administration Console is started is the language you specify in the language property for your Web browser. For example, if you have not changed the setting in your IE under Japanese Windows, Japanese language will be displayed when the Administration Console is started. If you wish to change it into English, set the language setting of the browser to "English" and delete all other languages in the list. Note that all output encoding of Administration Console is standardized to UTF-8, regardless of languages.

Encoding for sending an e-mail

For sending an e-mail in WebLogic Server, JavaMail is implemented. Therefore, adding mail.mime.charset, which is the system property for JavaMail, to WebLogic Server startup option will enable you to change the encoding of an e-mail to be sent. (When this property is omitted, the default encoding for JavaVM will be used.)

Example:

Change the encoding of sending an e-mail from WebLogic Server to ISO-2022-JP.

-Dmail.mime.charset=ISO-2022-JP

A typical example of sending an e-mail from WebLogic Server would be to use SMTP for notification of diagnosis service at system management.

Programming

As already described in Overview of Internationalization, all characters inside WebLogic Server are handled by Unicode, but any input/output of character data with external resources will lead to encoding conversion. This section includes topics on some useful notes when processing multibyte characters in view of application programming.

Browser Locale when Setting Security Policy (CR285384)

Security Policy setup will fail if one of the following locales is specified.

ko [Korean]

zh [Chinese]

zh-cn [Chinese/China]

zh-tw [Chinese/Taiwan]

Workaround:

Please change your browser locale to en-us. For how to change the locale setting of your browser, please refer to the browser's help.

Fixed in:

This problem was fixed in WLS9.2MP1.

Web Components

From the view point of WebLogic Server, the external resources which necessitate the encoding conversion are those that use the HTTP protocol. The HTTP protocol is so designed as to transport the messages in various encodings. Therefore it is of a great importance how the encoding conversion between Unicode character strings handled inside the server and the messages encoded by the specific encoding on HTTP protocol is treated as Web components. As the solution to this problem, some encoding conversion settings are prepared as several APIs and parameters, corresponding to J2EE specification and WebLogic Server’s proprietary specification. The user is requested to understand the following explanation and to find the optimum combination of settings to meet the requirements of the system to be built.

Targets of encoding settings for Web components

The targets for encoding setting with regards to J2EE Web components is as follows:

Encoding for responses

Encoding for requests

Encoding for files

In J2EE specification, the default encoding when these items are omitted is specified. The default encoding for each component is as shown below.

Component Name

Default Encoding

Servlet

ISO-8859-1

JSP

ISO-8859-1

XML format JSP Document

UTF-8

Tag File

ISO-8859-1

XML format Tag File

UTF-8

Since ISO-8859-1 encoding is extensively used as default encoding except for XML components, encoding setting is essential for the use of multibyte characters. The details of settings for each Web component are shown below. The meaning of each column in the table is as follows:

Priority: The priority with which set value is used (the smaller the value, the higher priority). The lower priority will be overwritten by higher priority. In general, the one with smaller effective area will have higher priority, and vice versa.

Setting Example: Examples of encoding setting.

Specifying the Encoding for a Response

For Servlets

There are following three ways to specify encoding for response to servlet.

Setting Location

Effective Area

Setting Value

J2EE Compliant

Priority

Setting Example

ServletResponse#setContentType method

Each HTTP response

MIME type with Charset attribute (IANA name)

YES

1

setContentType("text/html;charset=Shift_JIS");

ServletResponse#setCharacterEncoding method

Each HTTP response

IANA name

YES

1

setCharacterEncoding("EUC-JP");

ServletResponse#setLocale method

Each HTTP response

Locale name (Note 1)

YES

2

setLocale(ja);

Note 1: Encoding is determined by IANA name that is identified by locale name. See Locale-to-IANA Mapping for locale vs. IANA name.

Note that you need to call these methods before obtaining Writer, as shown below.

Note 1: Due to JSP2.0 specification, when web.xml page-encoding element and pageEncoding attribute of page directive do not match, an error occurs when compiling JSP. As the result, the priority of both are the same.

Note 2: The value set here will be reflected on the parameters of ServletResponse#setContentType method inside the Servlet code into which JSP is compiled. Therefore when webapp.encoding.default is changed, the JSP files of the whole of enterprise application need to be rebuilt to keep the change effective.

For JSP Documents

There are following ways to specify encoding for response to JSP Document.

Setting Location

Effective Area

Setting Value

J2EE Compliant

Priority

Setting Example

contentType attribute of Page directive

Each file

MIME type with Charset attribute (IANA name)

YES

1

<jsp:directive.page contentType="text/html; CHARSET=euc-jp"/>

Specifying the Encoding for a Request

Among the methods of specifying encoding for a HTTP request, the most compliant one to HTTP specification would be to specify a character set for a charset attribute of ContentType header of HTTP request. By doing this, WegLogic Server on receiving side can correctly recognize HTTP request encoding in protocol base. However, major Web browsers such as Microsoft IE and Netscape browser cannot specify this value. Therefore HTTP request encoding also needs to be specified at WebLogic Server side.

The setting of encoding for a request is common to JSP and Sevlet, and there are following three ways.

Specifying the Encoding for a File

The Web components other than Servlet need to be read by some appropriate encoding at the time of Web container being run. For example, JSP compiler will read JSP file using some appropriate encoding when it translates JSP file into Servlet Java code. Likewise, Web components other than Servlet need to have the encoding for files correctly set.

Note 1: Due to JSP2.0 specification, if web.xml page-encoding element and pageEncoding attribute of page directive do not match, an error occurs at the time of translation. As the result, the priority of both are the same.

For JSP Documents

Since JSP Document is described in XML, how the encoding is specified for JSP Document file will be compliant to XML specification.

Setting Location

Effective Area

Setting Value

J2EE Compliant

Priority

Setting Example

encoding attribute in the XML declaration

Each file

IANA name

YES

1

<?xml version='1.0' encoding='utf-8' ?>

Due to JSP2.0 specification, when in JSP Document any page-encoding elements of web.xml or any file encoding by pageEncoding attributes for page directive is set and if any of these is not compliant to encoding attributes of XML declaration of JSP Document, an error occurs at the time of translation.

For Tag Files

There are following ways to specify encoding for Tag Files.

Setting Location

Effective Area

Setting Value

J2EE Compliant

Priority

Setting Example

pageEncoding attribute of tag directive

Each file

IANA name

YES

1

<%@ tag pageEncoding="Windows-31J" %>

For XML format Tag Files

There are following ways to specify encoding of XML format Tag files.

Setting Location

Effective Area

Setting Value

J2EE Compliant

Priority

Setting Example

encoding attribute in the XML declaration

Each file

IANA name

YES

1

<?xml version='1.0' encoding='utf-8' ?>

Due to JSP2.0 specification, when a file encoding setting by pageEncoding attributes of tag directive is applied to XML format Tag files, an error will occur at compiling.

Parse Method of JSP

Due to JSP2.0 specification, if the same element of page directive appears twice or more, and if these are different, then an error will occur at the time of translation. This happens, for example, when there are two or more contentType with different encodings specified in a single file.

Differences between Static and Dynamic for include tag, and Specifying Encoding in page tag

Static Include

The static include for JSP is described as follows:

<%@ include file="relativeURL" %>

In this case, all files to be included are read and formed into one file first, and then compiling of JSP is performed. Therefore when encoding settings in page directives are done both for JSP to include and JSP to be included, and if these are different, an error will occur at the time of translation as was earlier described in Parse Method of JSP.

Dynamic Include

For jsp:include, the include operation will not happen when this page is loaded, and the tag will remain. 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.

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, which is a Java application, these values must be Java encoding names. WebLogic Server has the default mappings internally 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 Predefined MIME-Java Encoding Mapping Table in WebLogic Server).

Example: x-sjis ----> Shift_JIS

You can change this mapping. This can be set in weblogic.xml as follows:

For example, 'Shift_JIS' setting in the contentType is handled as SJIS in WebLogic Server, because the IANA character set 'Shift_JIS' is mapped to the Java encoding 'Shift_JIS' (Shift_JIS is used as an alias for SJIS in JDK1.4).

Note: In Java1.3, Shift_JIS of IANA character set used to be handled as MS932 (in JDK1.1.8 and thereafter, up to JDK1.4.0; Shift_JIS was changed back to SJIS in JDK1.4.1 and thereafter.)

Consequently, MS932-specific characters cannot be used when Shift_JIS is used with the default setting.

To allocate other encoding than default mapping, you need to overwrite the default mapping as follows: specify following in <charset-mapping> in weblogic.xml.

Note: This setting is only valid for HTTP response.For example, this is not effective for file encoding (page encoding) such as JSP.

CGIServlet

When migrating a CGI service which uses multibyte 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 input-charset parameter in weblogic.xml in order to receive input strings from a client correctly. You need to write it in the DD file of the target Web application. If it does not exist, ISO-8859-1 is used.

Specifying Input Encoding for Form-Based Authentication

To specify input encoding for Form-Based authentication inside the form, specify the encoding name to be used to j_character_encoding. Note that this function is proprietary to WebLogic Server.

For example, if the User Agent (web browser) is MS IE (Microsoft Internet Explorer), by default, the multibyte characters entered in the address bar are first encoded to UTF-8, and it is then URL encoded. WebLogic Server, with default settings, correctly creates the URL string from this UTF-8 encoded URL.

Note: In IE's Internet Options - Advanced, there is an option called Always send URLs as UTF-8 (requires restart), and this option must be ON (checked).

Remember that myRequestParameter portion is decoded in line with Specifying the Encoding for a Request. For myHostName portion, IESG is standardizing it as an international domain name.

In the case where proprietary User Agent is used and multibyte is necessary in the request URL, first make the character string a UTF-8 byte string, then URL encode and send it to the WebLogic Server. It is recommended by the W3C that the URL be encoded with UTF-8 base when creating the URI. (http://www.w3.org/TR/charmod/#sec-URIs)

Method for Specifying Character Encoding when Decoding URLs

Some User Agents do not perform URL encoding of request URL into UTF-8. With Netscape browser, the characters in address bar are encoded first by the character set of the environment where Netscape browser operates, and then the character string is URL encoded to be sent to WebLogic Server. For example, the Netscape browser on Japanese Windows will URL encode the request URL into Windows-31J. To handle this situation, the setting must be made so that the byte stream that is URL decoded in WebLogic Server is converted to String in Windows-31J. Through the following WebLogic Server startup option, encoding which is used for URL decoding can be changed.

-Dweblogic.http.URIDecodeEncoding=Windows-31J

Note that only one of such setting is allowed for one server instance.

Web services

Using Multibyte Characters in JMS Transfer

To send a message containing multibyte characters in JMS transfer, the message must be sent as BytesMessage. To do this, obtain a port and set the message type to BytesMessage using any of the following methods.

No special settings are required on the receiver because it automatically selects the same message type as that of the sent message.

Receiving SOAP messages

Web services of WebLogic Server 9.0 implement Enterprise Web Services 1.1 specification (JSR-921). In JSR-921, SOAP1.1 is adopted. 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. Hence the encoding operations of receiving SOAP messages in Web services of WebLogic Server 9.0 are as follows:

SOAP1.1:

ContentType charset parameter in the HTTP header is used to determine the character set for HTTP/SOAP request.

encoding attribute in the XML declaration of a SOAP message is ignored.

If charset parameter is not specified with ContentType, the message is handled as US-ASCII.

Make sure that the ContentType charset is specified correctly for the client which calls the developed Web service(s) using HTTP/SOAP.

Sending SOAP messages

For WebLogic Server, HTTP/SOAP messages are generated with UTF-8. In this process, UTF-8 is added as charset attribute of ContentType header for the SOAP message.

The followings are notes on parsing an XML document containing multibyte characters using StAX. The main points are the same as in the notes on using the xerces parser.

Use a byte stream when using a stream in the parser input. By using a byte stream, the parser's automatic XML encoding recognition function can be used. This allows the parser to generate character stream internally by the encoding specified by the encoding attributes in XML declaration, and correctly parse it.

When a Unicode character stream is passed, the parser ignores the encoding specified in xml header. In this case, take caution on the user side to pass the correct character stream.

JDBC

BEA WebLogic Type4 Oracle Driver (To be noted only when Japanese language is used)

In the Case of Using codePageOverride Property

Oracle database has a map between Unicode and code point on the database, for each character set. This map is used when characters are stored in a database or retrieved from the database. For example, when using Oracle Thin driver, the Oracle database server side will use the map to perform the conversion between Unicode and code point on the database.

In the WebLogic Type4 Driver for Oracle, a property called codePageOverride is provided to perform this conversion using JDK converter map. Possible values for codePageOverride property and the behaviors are in the following table:

Value

Destination database to be assured

Operation

SJIS

Character set is JA16SJIS, JA16SJISTILDE or JA16SJISYEN

Assures the conversion by the map that matches the converter for SJIS of JDK, among all the maps that can be used for the character set of the destination database. It does not assure the conversion when the map does not match.

MS932

Character set is JA16SJIS, JA16SJISTILDE or JA16SJISYEN

Assures the conversion by the map that matches the converter for MS932 of JDK, among all the maps that can be used for the character set of the destination database. It does not assure the conversion when the map does not match.

UTF8

All databases

The driver will use UTF-8 for character encoding when communicating with database. Consequently, the handling of characters to be stored in database will be the same as Oracle Thin driver.

Note: codePageOverride=UTF8 can be used from WebLogic Server 9.1 or later.

In the Case of Omitting codePageOverride Property

In WebLogic Server 9.0 or thereafter, when codePageOverride property is omitted, the handling of the characters to be stored in database is the same as Oracle Thin Driver provided that the character set of destination database is any one of JA16SJIS, JA16SJISTILDE or JA16SJISYEN. See About codePageOverride Property of BEA WebLogic Type4 JDBC Driver for Oracle for the changed contents and some notes on version upgrade from the earlier versions.

Notes on Migration from jDriver for Oracle

If you are using jDriver for Oracle, for a database with JA16SJIS character set, and if you encounter garbled ～ (Wave Dash) after migrating to WebLogic Type4 Oracle Driver, you will be able to solve this problem by changing the database to JA16SJISTILDE or by specifying codePageOverride=MS932.

Miscellaneous

Countermeasure for Garbled Characters Caused by Unicode Definition and Java Converter (To be noted only when Japanese language is used)

If you do not use the same converter for the conversions from the platform native encoding to the Unicode, and from the Unicode to the platform native encoding, the characters may be handled incorrectly. Here some explanation with examples is given for the case where the use of MS932 converter and SJIS converter against the same characters give the different mapping on Unicode.

Assume for example the application below where the data stored in a database is displayed by JSP deployed in WebLogic Server.

It is a rather simple application, but as shown in Encoding Conversion, via WebLogic Server, the conversion between platform native encoding and Unicode encoding is performed at least twice. In this example, MS932 converter is used between database and WebLogic Server, and SJIS converter is used between WebLogic Server and Web browser. In this case, following codes cannot be handled correctly, giving some problems such as garbled characters.

SJIS Code

"～" (0x8160)

"∥" (0x8161)

"￠" (0x817C)

"－" (0x8191)

"￡" (0x8192)

"￢" (0x81CA)

In order to avoid garbled characters, you need to change encoding conversion between WebLogic Server and Web browser or between database and WebLogic Server, to harmonize the two conversions.

Changing Encoding Conversion Between WebLogic Server and Web Browser

When for example JSP page tag specifies:

<%@ page contentType="text/html; charset=Shift_JIS" %>

(Shift_JIS here is IANA name) there are following two ways for using MS932 converter between WebLogic Server and Web browser.

In the case of Using iMode characters (To be noted only when Japanese language is used)

Specifying Encoding for WTC TUXEDO Domain

Domain encoding for wtc can be specified for TUXEDO domains. Specify the following parameters at time of startup. The start scripts of WebLogic Server (such as StartWebLogic.cmd file) need to be changed.

-Dweblogic.wtc.encoding=Java encoding name

The encoding specified by this is effective for the entire TUXEDO domain.