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.


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.

I tried it this way. Normal forms (not multipart/form-data) are submitted correctly with ISO-8859-1 (containerencoding) decoded to UTF-8 (formencoding).

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]



Reply via email to