On Wed, 2003-03-12 at 17:52, Jeremy Quinn wrote: [...] > As far as I can tell, yes it did solve it. > I was making only one change at a time, after this one, it worked ;) > > > I'm wondering how the SetCharacterEncodingAction could actually do > > anything useful. According to the servlet spec (I'm looking at version > > 2.3), the request.setCharacterEncoding method only does something if > > called before any data is read from the request. > > > > Interesting > > > Since Cocoon itself reads parameters from the request (such as > > cocoon-reload) before any action is executed, this action obviously > > cannot do anything useful? > > > > Hmmm >
I just found out that actually it can work -- the setCharacterEncoding method in Cocoon's request object doesn't correspond to the servlet spec's setCharacterEncoding method but causes some Cocoon-specific decoding/encoding trick to happen. > > Wouldn't it be better if we logged a big warning in this action > > pointing > > to the container/form-encoding parameters in the web.xml (and the same > > in its javadoc)? > > > > Yes, this is a better technique. > I had an idea there may be a configuration here, but could not find an > example of it. > Since I now found out about the above, this action actually does something useful, though I'm not sure if it's good to promote this if we'd ever like to migrate to the servlet spec's setCharacterEncoding method. [...] > > * in the web.xml: set container-encoding to ISO-8859-1 (don't know why > > its configurable because it should be ISO-8859-1 per spec), and set > > form-encoding to the same encoding of the serializer. > > Lets put the config in, it will make it easier for other to see what to > change. We work exclusively in UTF-8 for instance. +1 Since the serializers are using UTF-8 by default, it's only logical that the decoding also uses UTF-8 by default. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
