Administrator's Guide Netscape Enterprise Server

Previous      Contents      Index      Next

Appendix D   International Content Support

The following information covers the international considerations for general server capabilities:

• Entering UTF-8 Data
• Using the Accept-language Header

Entering UTF-8 Data

If you want to enter UTF-8 data on the Server Manager or the Administration Server pages, you need to be aware of the following issues:

File or Directory Names

If a file or directory name is to appear in a URL, it cannot contain 8-bit or multi-byte characters.

LDAP Users and Groups

To make sure you enter characters in the correct format for users and groups, use a UTF-8 form-capable client (such as Netscape) to input 8-bit or multi-byte data.

If you let users access their own user and group information, they will need to use a UTF-8 form-capable client.

Using the Accept-language Header

When clients contact a server using HTTP, they can send header information that describes the various languages they accept. You can configure your server to parse this language information as described in Chapter 14 "Content Management."

You can enable or disable the server to the acceptlanguage directive in the server.xml file.

Table D-1    International Settings in server.xml

acceptlanguage

on, off

Enables or disables the Accept-language header parsing.

For example, if acceptlanguage is set to on, and a client sends the Accept-language header with the value fr-CH,de, when requesting the following URL:

http://www.example.com/somepage.html

Your server searches for the file in the following order:

1. The Accept-language list fr-CH,de.

http://www.example.com/fr_ch/somepage.html
 

http://www.example.com/somepage_fr_ch.html
 

http://www.example.com/de/somepage.html
 

http://www.example.com/somepage_de.html
 

2. Language codes without the country codes (fr in the case of fr-CH):

http://www.example.com/fr/somepage.html
 

http://www.example.com/somepage_fr.html
 

3. The DefaultLanguage , such as en, defined in the magnus.conf file.

http://www.example.com/en/somepage.html
 

http://www.example.com/somepage_en.html
 

4. If none of these are found, the server tries:

http://www.example.com/somepage.html

Note	Keep in mind when naming your localized files that country codes like CH and TW are converted to lower case and dashes (-) are converted to underscores (_).


 

Servlet Internationalization

---

When form data is submitted from a browser to the server using POST, the browser:

• url-encodes the POST data
• Sets the Content-Type to application/x-www-form-urlencoded
• Does not send any charset information in the Content-Type header

On the server side, if a servlet tries to access POST data using getParameter or getParameterValues, the servlet container does not have any information about which character encoding to use for getParameter strings.

You can configure Enterprise Server 6.1 to instruct the servlet container which character encoding to use for interpreting POST data strings. To do this, you would specify the character encodingusing the parameter-encoding element in web-apps.xml:

<parameter-encoding enc="value"/>

where value can be one of the following:

• auto (default)
• none
• any valid encoding

These values are described below.

auto

auto requires the servlet container to look for some hints regarding the character encoding to be used. The hint can be provided using:

• A request attribute with the name: com.netscape.server.http.servlet.parameterEncoding. The value is of type String. The request attribute must be set before any calls to getParameter() or getParameterValues(). Example:

request.setAttribute("com.netscape.server.http.servlet.
parameterEncoding", "Shift_JIS");
request.getParameter("test");
 

This option is used if the servlet knows beforehand what the charset of the posted data is.
 

• A j_encoding parameter in the form data. The form that is being submitted can have a hidden element. Example:

<input type=hidden name="j_encoding" value="Shift_JIS" >
 

This option is typically used if the servlet that is reading the data does not necessarily know what the charset of the posted data is. The hint parameter name, which by default is j_encoding can be changed using theparameter-encoding element in web-apps.xml.
 

none

Use this option if you wish the platform default encoding to be used for the servlet parameter data.

any valid encoding

If none of the above options are specified, the servlet container interprets this string itself as the encoding, so this can be any valid encoding string like Shift_JIS, or UTF-8. For example, you would specify this as UTF-8 if you know that the form POST data is always in UTF-8.

Note	The server will always try to resolve the charset from the Content-Type header of the request first.

For more information on parameter-encoding, see the Netscape Enterprise Server Programmer's Guide to Servlets.

Posting to JSPs

---

You can configure parameter-encoding to work the same way when you are posting to a JSP instead of a servlet. The following example demonstrates a JSP configuration of `auto' to read parameters which are in Japanese Shift_JIS encoding:

<%@ page contentType="text/html;charset=Shift_JIS" %>
<html>
<head>
<title>JSP Test Case</title>
</head>
<body>
<% request.setAttribute("com.netscape.server.http.servlet.parameterEnc oding", "Shift_JIS");
%>
<h1>The Entered Name is : <%= request.getParameter("test") %> </h1>
</body>
</html>

© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002 Netscape Communications Corporation. All rights reserved.

Last Updated August 02, 2002