I've found for myself the approach.

parm = new String(param.getBytes("ASCII"), "UTF-8");

I'm uneasy using it however, because sooner or later a version of Tomcat or some other servlet engine is going to fix the problem and do the stream to string conversion based on the character set specified in the headers of the message from the browser.

When that happens existing applications with this code are going to screw up a treat.

Thanks, that was very valuable information. I couldn't make it work because I was using GET.

How does request.getParameter("query") know whether query comes from GET or POST? So in case it comes from GET I do the new String(query.getBytes("ISO-8859-1"), "UTF-8") style conversion.

That's because sometimes it's useful to have the query on the URL so you can bookmark it or send it to others (e.g results.jsp?query=%CE%B1%CE%B2%CE%B3 which is query=abc in Greek)

thanks

For those working with JSP and databases who are still having problems...

I'm working with a MySQL database, JSP, and forms and was having similar problems to others here. The answers here apparently work, but in my case, the key was the database connection. I found an article on JavaWorld describing a similar set-up to my own, with the following key element:

Connection db =
DriverManager.getConnection(
"jdbc:mysql:///" + dbname +
"?requireSSL=false&useUnicode=true&characterEncoding=UTF-8",
"root", "");

As soon as I added the "&useUnicode=true&characterEncoding=UTF-8" to my connection string, all my problems were solved.

See the article (page 2)

On page one of the article, he describes explicitly setting the encoding for the db tables and fields to UTF-8 when creating them. Somewhere else I'd read an article simply advising to use VARCHAR for fields which would contain Unicode - I didn't explictly set my table fields for UTF-8, and that's working fine for me.

After spinning around this same problem for one full day, and trying out various solution that all of your provided, I decided to dig into Tomcat's source code and see what's happening behind the scenes.

FYI, I'm working with a JBoss4.0.3SP1, which ship with a copy of Tomcat 5.5.9:

In org.apache.coyote.Request line#283, inside of a function called getCharacterEncoding(), I found:

   charEncoding = ContentType.getCharsetFromContentType(getContentType());

Step into org.apache.tomcat.util.ContentType, and here comes the evil:

    // Basically return everything after ";charset="
    // If no charset specified, use the HTTP default (ASCII) character set.
    public static String getCharsetFromContentType(String type) {
        if (type == null) {
            return null;
        }
        int semi = type.indexOf(";");
        if (semi == -1) {
            return null;
        }
        int charsetLocation = type.indexOf("charset=", semi);
        if (charsetLocation == -1) {
            return null;
        }
	String afterCharset = type.substring(charsetLocation + 8);
        // The charset value in a Content-Type header is allowed to be quoted
        // and charset values can't contain quotes.  Just convert any quote
        // chars into spaces and let trim clean things up.
        afterCharset = afterCharset.replace('"', ' ');
        String encoding = afterCharset.trim();
        return encoding;
    }

Huh?! Most browsers submits a <form> with content-type=application/x-www-form-urlencoded, and there will be no ";" or "charset=..." coming after that! So if you are submitting some sort of <form>, this function will always return null.

This "null" will then be picked up by function parseParameters() in org.apache.catalina.connector.Request, and this is how it will handle our "null":

    protected void parseParameters() {

        parametersParsed = true;

        Parameters parameters = coyoteRequest.getParameters();

        // getCharacterEncoding() may have been overridden to search for
        // hidden form field containing request encoding
        String enc = getCharacterEncoding();

        boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
        if (enc != null) {
            parameters.setEncoding(enc);
            if (useBodyEncodingForURI) {
                parameters.setQueryStringEncoding(enc);
            }
        } else {
            parameters.setEncoding
                (org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
            if (useBodyEncodingForURI) {
                parameters.setQueryStringEncoding
                    (org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
            }
        }
        ...
        ...
    }

Guys, did you see those two lines of comments?

    // getCharacterEncoding() may have been overridden to search for
    // hidden form field containing request encoding

This is what Tomcat is expecting us to solve our problem. Or if you don't want to extend this whole class just to solve your problem, you can put this few lines after line:

    String enc = getCharacterEncoding();

    //add these lines
    if (enc == null) {
        enc = connector.getURIEncoding();
    }

Now use the build.xml comes with the Tomcat src to rebuild the Tomcat source, problem solved.