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 correctly if (strParamter != null) { byte[] bit = strParamter.getBytes("ISO8859-1"); strParamter = new String(bit); } // The end of translating if (strParamter == null) { strParamter = ""; } %>
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 effect. 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.
Reopen to update resolution.
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.