Hey Bruno,
I am not sure if the above patch fixes the problem I mentioned.
The patch replaces this.defaultFormEncoding); by this.containerEncoding);
In our configuration the defaultFormEncoding == containerEncoding == "UTF-8" - so the patch doesn't seem to have a influence on our problem :-(
then your configuration is wrong :-) The containerEncoding should be ISO-8859-1, always.
Ok. So this option is for future use or if you really know, what your webcontainer is doing.
I tried it this way. Normal forms (not multipart/form-data) are submitted correctly with ISO-8859-1 (containerencoding) decoded to UTF-8 (formencoding).
Somewhere the encoding for the Parameters is set to ISO-8859-1 probably because no encoding is set until the first call of getParameter*().
Cocoon doesn't rely on the setCharacterEncoding support of the webcontainer, basically because of historical reasons, that method didn't always exist. Additionally, Cocoon's approach has the advantage that it allows to change the encoding from the sitemap, allowing different parts of the sitemap to use different encodings.
Multipart forms instead seem to send the form fields as UTF-8. Cocoon tries to decode these too from ISO to UTF - so they break and i doesn't work.
Ok, so for our problem a solution would like: ContainerEncoding ISO-8859-1 FormEncoding UTF-8
For all forms that use "multipart/form-data" & utf-8: use the SetCharacterEncodingAction in the sitemap to change the encoding to utf-8.
Unfortunately SetCharacterEncodingAction is only able to change the FormEncoding - not the ContainerEncoding - so that this way wouldn't work without enhancing the action.
Are there any other ways?
Thanks, Stefan.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]