Aha, this explains a lot. I know what to do, one final thing for me before changing to 5.0.28 is testing the servlet filter option on 5.0.25.
Thx. > -----Original Message----- > From: Allistair Crossley [mailto:[EMAIL PROTECTED] > Sent: 15 December 2004 13:11 > To: Tomcat Users List > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > Your code is calling request.setChar... sure, but then the > request ends when the page is finished displaying. Clicking > your form submit generates a NEW request which has nothing to > do with the previous request.setChar.. call. > > There is loads of character encoding information in the JSP > Specification ... here is some stuff .. > > When you post a form, the request encoding is applied to the request > > "The request character encoding is the character encoding in > which parameters > in an incoming request are interpreted. It is primarily > managed as the ServletRequest > object's characterEncoding property. > > The JSP specification doesn't provide functionality to handle > the request > character encoding directly. To control the request character > encoding from JSP > pages without embedded Java code, the JSTL > <fmt:requestEncoding> can be used." (or use a servlet-filter). > > When you get data from a response > > "The response character encoding is the character encoding of > the response generated > from a JSP page, if that response is in the form of text. It > is primarily managed > as the javax.servlet.ServletResponse object's > characterEncoding property. > The JSP container determines an initial response character > encoding along > with the initial content type for a JSP page and calls > ServletResponse.setContent- > Type() with this information before processing the page. JSP > pages can set initial > content type and initial response character encoding using > the contentType > attribute of the page directive. > The initial response content type is set to the TYPE value of > the contentType > attribute of the page directive. If the page doesn't provide > this attribute, the initial > content type is "text/html" for JSP pages in standard syntax > and "text/xml" for JSP > documents in XML syntax. > The initial response character encoding is set to the CHARSET > value of the > contentType attribute of the page directive. If the page > doesn't provide this > attribute or the attribute doesn't have a CHARSET value, the > initial response > character encoding is determined as follows: > * For documents in XML syntax, it is UTF-8. > * For JSP pages in standard syntax, it is the character > encoding specified by the > pageEncoding attribute of the page directive or by a JSP > configuration element > page-encoding whose URL pattern matches the page. Only the > character encoding > specified for the requested page is used; the encodings of > files included > via the include directive are not taken into consideration. > If there's no such > specification, no initial response character encoding is > passed to ServletResponse. > setContentType() - the ServletResponse object's default, > ISO-8859-1, is > used." > > > -----Original Message----- > > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > > Sent: 15 December 2004 11:44 > > To: Tomcat Users List > > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > > > > Well, I tested the page on the following tomcat versions : > > > > 4.1.29 : OK > > 4.1.31 : OK > > 5.0.25 : NOK > > 5.0.28 : OK > > 5.5.4 with compt. : OK > > > > So it seems a tomcat bug, if someone could confirm this ? > > I am currently looking in tomcat bugzilla for this ... > > > > Q > > > > > -----Original Message----- > > > From: Quinten Verheyen > > > Sent: 15 December 2004 11:35 > > > To: Tomcat Users List > > > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > > > > > > > It was me who posted that :) > > > > > > I looked into the example servlet filter you gave me, in the > > > end it just calls request.setCharacterEncoding(String) .. why > > > would that call be applied to form post data and the one in > > > the JSP not ? > > > > > > Q > > > > > > > -----Original Message----- > > > > From: Allistair Crossley [mailto:[EMAIL PROTECTED] > > > > Sent: 15 December 2004 10:48 > > > > To: Tomcat Users List > > > > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > > > > > > > > > > oh yes sorry, it's because you need to set request encoding > > > > on your form post. use a servlet filter. there was a post > > > > within the past week where I posted the full code of such > > a filter. > > > > > > > > > -----Original Message----- > > > > > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > > > > > Sent: 15 December 2004 09:16 > > > > > To: Tomcat Users List > > > > > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > > > > > > > > > > > > > I tried that option already, doesn't make a difference .. > > > > > > > > > > <%@ page pageEncoding="utf-8" contentType="text/html; > > > > > charset=UTF-8" language="java" %> > > > > > or > > > > > <%@ page pageEncoding="utf-8" language="java" %> > > > > > <%@ page contentType="text/html; charset=UTF-8" %> > > > > > > > > > > Q > > > > > > > > > > > -----Original Message----- > > > > > > From: Allistair Crossley [mailto:[EMAIL PROTECTED] > > > > > > Sent: 15 December 2004 10:03 > > > > > > To: Tomcat Users List > > > > > > Subject: RE: char encoding bug in tomcat 5.0.25 ? > > > > > > > > > > > > > > > > > > you-re missing a page directive > > > > > > > > > > > > <%@ page contentType="text/html; charset=UTF-8" %> > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > > > > > > > Sent: 15 December 2004 08:28 > > > > > > > To: Tomcat Users List (E-mail) > > > > > > > Subject: char encoding bug in tomcat 5.0.25 ? > > > > > > > > > > > > > > > > > > > > > Hi, *maybe* I'm experiencing a bug in Tomcat > > 5.0.25, but this > > > > > > > is pure assumption, please help me with this troublesome > > > > > > > character encoding problem. > > > > > > > > > > > > > > The test page below gets a request parameter and > > shows it in > > > > > > > a textarea. The goal is to test if special characters are > > > > > > > translated wrongly .. (would actually occur if > > > > > > > encoding/decoding set isn't the same). The problem is in > > > > > > > Tomcat 5.0.25 the character 'é' is translated into é, in > > > > > > > Tomcat 4.1.29 it stays the same. > > > > > > > > > > > > > > Note: when providing the paramter as a get, it works. > > > > > > > > > > > > > > ======== > > > > > > > test.jsp > > > > > > > ======== > > > > > > > > > > > > > > <%@ page pageEncoding="utf-8" language="java" %> > > > > > > > > > > > > > > <% > > > > > > > request.setCharacterEncoding("utf-8"); > > > > > > > String text = request.getParameter("text"); > > > > > > > if (text == null) { > > > > > > > text = ""; > > > > > > > } > > > > > > > %> > > > > > > > > > > > > > > <html> > > > > > > > <head> > > > > > > > <meta http-equiv="Content-Type" content="text/html; > > > > > charset=utf-8"> > > > > > > > <title>test page</title> > > > > > > > </head> > > > > > > > <body> > > > > > > > > > > > > > > <FORM name="test" method="POST"> > > > > > > > <textarea name="text"><%=text%></textarea> > > > > > > > <input type="submit" /> > > > > > > > </form> > > > > > > > > > > > > > > </body> > > > > > > > </html> > > > > > > > > > > > > > > Thx in advance, > > > > > > > Quinten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> > > > > > > ------------------------------------------------------- > > > > > > QAS Ltd. > > > > > > Developers of QuickAddress Software > > > > > > <a href="http://www.qas.com";>www.qas.com</a> > > > > > > Registered in England: No 2582055 > > > > > > Registered in Australia: No 082 851 474 > > > > > > ------------------------------------------------------- > > > > > > </FONT> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
