DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29896>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29896 html:text and some japanese character [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2004-07-04 11:39 ------- You trick didn't work for me. I used UTF-8 because my application is multilingual and it's the W3C recommended encoding. Using ISO-2022-JP was already a workaround solution to which seemed to work from Japanese Mac to French PC untill this bug discovery. As you advised, I used <%@ page contentType="text/html; charset=UTF-8" %> in the JSP but using request.setCharacterEncoding("UTF-8") in the reset() method of my DynaActionForm didn't change anything. But I found a workaround. Istead I had to extend the ActionServlet and put request.setCharacterEncoding ("UTF-8") in the process() method! protected void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { request.setCharacterEncoding("UTF-8"); super.process(request, response); } Otherwise, in the RequestProcessor the parameters were already stored in the request and wrongly decoded. I reopen this bug. As your patch for bug#29824 doesn't deal with the ActionServlet class I doubt it would correct the whole problem. Please change its state if it appears I'd be wrong. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
