eclipse-ee4j / eclipse-ee4j/jersey
Multi-byte characters of form parameters that are url-encoded by browser are not decoded correctly.
- Dominant language
- Java
- Stars
- 730
- Forks
- 382
- PR merge metrics
- No merged PRs in 30d
Description
I'm trying to develop web application using the MVC 1.0 framework (ozark).
The view engine type is JSP and the charset encoding of request and response is **Shift_JIS**.
When retrieving @FormParam parameters from MVC controller resource, some multi-byte characters in parameter values are corrupted.
As a result of investigation, Jersey didn't decoded correctly the parameter values that the browser urlencoded.
It uses java.net.URLDecoder to decode parameters for the application/x-www-form-urlencoded type.
For example, if the parameter value is "テスト" (\u30C6\u30B9\u30C8), the result is:
| URLEncoder type | Encoded string | Decoded string |
| java.net.URLEncoder API | %83%65%83%58%83%67 |  テスト |
| IE Browser | %83e%83X%83g |  _Character corruption_ |
| Firefox Browser | %83e%83X%83g |  _Character corruption_ |
| Chrome Browser | %83e%83X%83g |  _Character corruption_ |
The above encoded string results are all correct.
In RFC-3986, it doesn't always need to encode alpha (uppercase and lowercase letters), digit, hyphen, period, underscore or tilde of multi-byte character's second or later byte-code.
However, java.net.URLDecoder doesn't support this percent-encoding rule fully, so it has critical defect.
I tried to use URLCodec in Apache Commons Codec instead of java.net.URLDecoder, so the problem has been resolved.
Would you be able to consider the replacement of URLDecoder for the form parameters in Jersey?
#### Environment
Oracle JDK 1.8.0_66
GlassFish 4.1.1
#### Affected Versions
[2.22.1]
Contributor guide
Assessment
This issue has not been assessed yet.