On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote:
J.Patterson Waltz III <lists 'at' cerenit.com> writes:
Notice in the third line of the form data: &personTO.comments=%C3%A9t%C3%A9 That's 'été' URLencoded as UTF-8.
So I'm still stumped. :-(
But that's exactly what you want. The SetCharacterEncodingFilter will set the character encoding of the HttpServletRequest before data is retrieved from it, and when it's retrieved it should be correctly decoded. Are you sure the filter is up and running?
I agree that that encoding is what I want. It's just that it's not getting decoded upon display. Or rather, it's getting URL-decoded, but not UTF-8 decoded.
I'm sure the filter is up and running because I added logging statements to the Apache example code. So in my log, I see:
2005-01-06 17:30:34,706 DEBUG [com.cerenit.sage.util.web.SetCharacterEncodingFilter] ignore = true, encoding = utf-8, request encoding is null
2005-01-06 17:30:34,706 DEBUG [com.cerenit.sage.util.web.SetCharacterEncodingFilter] setting encoding to utf-8
I have the filter set to match the url-patterns *.do and *.jsp.
I'm wondering if the fact that the form fields are all defined in subtiles could make any difference: I'd guess not, since it's the outermost tile which defines the page encoding.
I also have another filter, the ResponseOverrideFilter used by displaytag, which appears before the SetCharacterEncodingFilter in my web.xml. I wonder if it could be interfering with the SetCharacterEncodingFilter?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
