Oracle JavaServer Pages Developer's Guide and Reference
Release 8.1.7

Part Number A83726-01

Library

Product

Contents

Index

Go to previous page Go to beginning of chapter Go to next page

OracleJSP Extended Support for Multibyte Parameter Encoding

Character encoding of request parameters is not well defined in the HTTP specification. Most servlet containers must interpret them using the servlet default encoding, ISO-8859-1.

For such environments, where the servlet container cannot encode multibyte request parameters and bean property settings, OracleJSP offers extended support through the translate_params configuration parameter.

It is also possible to use equivalent code in the JSP page, which is necessary in the Oracle Servlet Environment.


Important:

Do not enable the translate_params flag in the following circumstances:

  • When the servlet container properly handles multibyte parameter encoding itself. Setting translate_params to true in this situation will cause incorrect results. As of this writing, however, it is known that Apache/JServ, JSWDK, and Tomcat all do not properly handle multibyte parameter encoding.

  • When the request parameters use a different encoding from what is specified for the response in the JSP page directive or setContentType() method.

  • When code with workaround functionality equivalent to what translate_params accomplishes is already present in the JSP page. (See "Code Equivalent to the translate_params Configuration Parameter".)

 

Effect of translate_params in Overriding Non-Multibyte Servlet Containers

Set translate_params to true to override servlet containers that cannot encode multibyte request parameters and bean property settings. (For information about how to set OracleJSP configuration parameters, see "OracleJSP Configuration Parameter Settings".)

When this flag is enabled, OracleJSP encodes the request parameters and bean property settings based on the character set of the response object, as indicated by the response.getCharacterEncoding() method.

The translate_params flag affects parameter names and values, specifically:

Code Equivalent to the translate_params Configuration Parameter

The translate_params configuration parameter, being a runtime parameter, cannot be set in the Oracle Servlet Engine environment. (Translation-time configuration can be set for the OSE environment through ojspc command-line options. There is no equivalent for runtime parameters.)

For this reason, and possibly other reasons as well, it is useful to be aware of equivalent functionality that can be implemented through scriptlet code in the JSP page, for example:

<%@ page contentType="text/html; charset=EUC-JP" %>
...
String paramName="XXYYZZ";       // where XXYYZZ is a multibyte string
paramName = 
   new String(paramName.getBytes(response.getCharacterEncoding()), "ISO8859_1");
String paramValue = request.getParameter(paramName);
paramValue= new String(paramValue.getBytes("ISO8859_1"), "EUC-JP");
...

This code accomplishes the following:

See the next two sections for an NLS sample that depends on translate_params being enabled, and an NLS sample that contains the equivalent code so that it does not depend on the translate_params setting.

NLS Sample Depending on translate_params

The following sample accepts a user name in Japanese characters and correctly outputs the name back to the browser. In a servlet environment that cannot encode multibyte request parameters, this sample depends on the OracleJSP configuration setting of translate_params=true.

Presume XXYY is the parameter name (something equivalent to "user name" in Japanese) and AABB is the default value (also in Japanese).

(See the next section for a sample that has the code equivalent of the translate_params functionality, and so does not depend on the translate_params setting.)

<%@ page contentType="text/html; charset=EUC-JP" %>

<HTML>
<HEAD>
<TITLE>Hello</TITLE></HEAD>
<BODY>
<%
   //charset is as specified in page directive (EUC-JP)
   String charset = response.getCharacterEncoding();
%>
   <BR> encoding = <%= charset %> <BR>

<%

String paramValue = request.getParameter("XXYY");

if (paramValue == null || paramValue.length() == 0) { %>
   <FORM METHOD="GET">
   Please input your name: <INPUT TYPE="TEXT" NAME="XXYY" value="AABB" size=20> 
<BR>
   <INPUT TYPE="SUBMIT">
   </FORM>
<% }
else
{ %>
   <H1> Hello, <%= paramValue %> </H1>
<% } %>
</BODY>
</HTML>

Following is the sample input:


and the sample output:


NLS Sample Not Depending on translate_params

The following sample, as with the preceding sample, accepts a user name in Japanese characters and correctly outputs the name back to the browser. This sample, however, has the code equivalent of translate_params functionality, so does not depend on the translate_params setting.


Important:

If you use translate_params-equivalent code, do not also enable the translate_params flag. This would cause incorrect results. (This is not a concern in the OSE environment, where the translate_params flag is not supported.)  


Presume XXYY is the parameter name (something equivalent to "user name" in Japanese) and AABB is the default value (also in Japanese).

For an explanation of the critical code in this sample, see "Code Equivalent to the translate_params Configuration Parameter".

<%@ page contentType="text/html; charset=EUC-JP" %>

<HTML>
<HEAD>
<TITLE>Hello</TITLE></HEAD>
<BODY>
<%
   //charset is as specified in page directive (EUC-JP)
   String charset = response.getCharacterEncoding();
%>
   <BR> encoding = <%= charset %> <BR>
<%
String paramName = "XXYY";

paramName = new String(paramName.getBytes(charset), "ISO8859_1");

String paramValue = request.getParameter(paramName);

if (paramValue == null || paramValue.length() == 0) { %>
   <FORM METHOD="GET">
   Please input your name: <INPUT TYPE="TEXT" NAME="XXYY" value="AABB" size=20> 
<BR>
   <INPUT TYPE="SUBMIT">
   </FORM>
<% }
else
{
   paramValue= new String(paramValue.getBytes("ISO8859_1"), "EUC-JP"); %>
   <H1> Hello, <%= paramValue %> </H1>
<% } %>
</BODY>
</HTML>



Go to previous page
Go to beginning of chapter
Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index