This is not a bug. Read http://asg.web.cmu.edu/rfc/rfc2070.html#sec-5.
Use this code:
String result = req.getParameter(parm);
if (result == null)
return null;
try
{
return new String(result.getBytes("ISO-8859-1"), "UTF-8");
}
catch (UnsupportedEncodingException e)
{
return result;
}
Dave Oxley
[EMAIL PROTECTED]
> -----Original Message-----
> From: Jeff Tulley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 25, 2003 6:40 PM
> To: [EMAIL PROTECTED]
> Subject: CoyoteRequest assumption that breaks UTF-8 support
>
> I am convinced that Tomcat 4.x has a very real bug when dealing with
> character encodings on login form submissions. (maybe elsewhere as
> well).
>
> To see what I am observing, watch the flow of code when doing a login
> from Tomcat's admin application. It sets the charset to UTF-8 in the
> tag
> <%@ page language="java" contentType="text/html;charset=UTF-8"
> import="java.util.*" %> at the top of the file. This correctly gets
> the browser into unicode mode, and (with all of the browsers I have
> tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they
> correctly encode your username / password in UTF-8.
>
> But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to
> determine and set the encoding to be used and ends up setting it to be
> null. Why? It looks like in Request.getCharacterEncoding and
> subordinate methods, the header value, "content-type" is checked. On
> all of the browsers that I have checked if this value is set at all, it
> is simply set to "application/x-www-form-urlencoded", without mention of
> UTF-8 or any other charset. The browser assumes that since you
> requested a certain charset in the first place, that you know how to
> deal with a parameter that is sent on encoded in that charset.
>
> Tomcat sees no mention of charsets, so it simply defaults to
> "ISO-8859-1" (hardcoded constant)
>
> Is there a better way to tie the default value to whatever the JSP
> login form originally requested, or even, failing that, can we look up
> the system property, "file.encoding", and require it to be passed in on
> startup. This is less than ideal though. Preferrably it would be
> something settable context-wide, not tomcat-wide.
>
> Where does this leave applications that wish to support extended
> characters in passwords and/or usernames, characters that may not be in
> the ISO-8859-1 range?
>
> Or am I missing the correct place to set this?
>
> Jeff Tulley ([EMAIL PROTECTED])
> (801)861-5322
> Novell, Inc., The Leading Provider of Net Business Solutions
> http://www.novell.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
