Bear Bibeault wrote:Of course it's decoded. Why would you not want getParameter() to decode the value? And why would even want the undecoded value? You could always re-encode it if you want.
You mis-understand -- I'm glad getParameter() decodes it. I do want the decoded value. The problem is that getParameter() doesn't decode it properly. Re-read my note -- I'm going from original value > encoded (for use in URL) > getParameter(). The decode done by getParameter() isn't resulting in the original value, because the "+" from the original is being lost in translation. If getParameter() won't do the trick, what technique should I use?
Ah, I see what you are saying. You are saying that the %2B is being incorrectly decoded as a space, rather than a +.
I do not see this behavior under Tomcat 6. I used the following URL:
show.params.jsp is a simple JSP that emits the params passed to it.
How are you forming the URL, and how are you sending it to the server?
Joined: Nov 06, 2000
Thanks for helping out!
I'm using Tomcat 5, Java 5. The code is part of a password recovery routine: I encode a piece of information in a servlet, then put it in a URL I email to the user. When the user follows the URL, another servlet is run which checks the value.
In the first servlet, I encode the value like this:
String param = URLEncoder.encode(originalValue, "UTF-8");
Then I stick param into the URL I email to the user. When the user clicks the URL, the receiving servlet simply does a getParameter() to get the value back.
It seems pretty simple, but then I ran into the problem with "+". I tried setting request.setCharacterEncoding("UTF-8") at the first line in the servlet, but that didn't change anything. Maybe there's a method that returns the raw character string from the parameter (although the decoding may be done by Tomcat).
For now, my kludge solution is to check for a space, and replace it with a "+" -- of course, I'd rather get the decoding to work right. (For example, without a real solution I may discover that getParameter() decodes other characters to a space too.)
Since URL-encoding is allowed to replace a space by a + sign, that error could be caused by doing the URL-decoding twice. The first time would convert %2B to + and the second time would convert + to space.
That's just a possible mechanism for what's happening. Why the URL-decoding is happening twice is another question which I don't see an answer for based on what I've seen so far in this thread.