Bug 2760 - request.setCharacterEncoding(strEncode) is not correctly
Summary: request.setCharacterEncoding(strEncode) is not correctly
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 4.0 Beta 6
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2001-07-24 00:53 UTC by dragzhb
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description dragzhb 2001-07-24 00:53:06 UTC
request.setCharacterEncoding(strEncode) is also  incorrectly.when I set 
strEncode to GBK or gb2312 ,String strParamter = request.getParameter("ID") is 
incorrectly . I must translate ISO8859-1 to GBK manual.
This is the source code

<% request.setCharacterEncoding("GBK"); //It is not correctly
	    	String strParamter = request.getParameter("ID");
                  // I must use those code to getting strParamter encoding 
	    	if (strParamter != null) {
	    		byte[] bit = strParamter.getBytes("ISO8859-1");
				strParamter = new String(bit);
		}  // The end of translating 

             if (strParamter == null) {
				strParamter = "";
Comment 1 Craig McClanahan 2001-07-24 17:06:40 UTC
Converting this to an Enhancement request.  See below for more details.

There is a restriction on the request.setCharacterEncoding() method, that it
must be called *before* any of the request.getParameter() family of methods are
called, because any of those methods cause all the request parameters to be
read.  Currently, Jasper is calling request.getParameter("jsp_precompile"), in
order to implement the precompilation protocol as defined in JSP 1.3 PFD3,
Section 8.4.  This means that the parameters have already been processed by the
time your scriptlet executes, so your call to setCharacterEncoding() has no

This issue has been captured as an issue for the next version of JSP after 1.2
(it's too late in the cycle for 1.2 to make large substantive changes).  It's
also being recorded as an enhancement request for Tomcat, to use a different
mechanism to implement the precompilation protocol.

However, there are also two fairly straightforward workarounds for you:

* Implement your web application architecture, such that requests pass
  through a controller servlet before being forwarded to the JSP page.
  In this scenario, your controller servlet can call
  request.setCharacterEncoding() reliably, because it *knows* that no
  request parameters have been processed.

* Implement a filter, using the new javax.servlet.Filter API, that does
  the request.setCharacterEncoding() call for you, without having to
  modify the application architecture.

To make the latter workaround easier, beginning with the 20010724 nightly build
of Tomcat 4.0, a new example filter (filters.SetCharacterEncodingFilter) has
been included in the "/examples" web application.  You can use this filter as is
in your own apps, if you just want to unconditionally set the character
encoding, or use it as a base class for more sophisticated processing.
Comment 2 Larry Isaacs 2003-11-05 14:30:55 UTC
Reopen to update resolution.
Comment 3 Larry Isaacs 2003-11-05 14:39:25 UTC
Craig actually implemented the "enhancement" later that night.  The fix appears 
in the original Tomcat 4.0 release and later versions of Tomcat 4.

It would seem to me to be a bug for the JSP handling to always call
getParameter() before the JSP could call setCharacterEncoding().
With Craig's change, the "jsp_precompile" parameter is now detected by scanning 
the query string directly.