Joe Germuska <Joe 'at' Germuska.com> writes: [...]
> >As far as I know, the most reliable way is to specify > >"accept-charset" as UTF-8 in the <form> of the HTML (w3.org's > >description of this parameter: "This attribute specifies the list > >of character encodings for input data that is accepted by the > >server processing this form"). Theoretically, this forces the > >browser to send the data in UTF-8. As far as I know, tests showed > >that this should work correctly with current browsers. The > >problem is that this parameter is not available in <html:form> > >from struts, the reason of it I have no clue about. > > This property was added in Struts 1.2.2, as noted on > http://struts.apache.org/userGuide/struts-html.html#form Ah, interesting. I was talking about version 1.1 from which I haven't upgraded yet, my bad. > In my experience, this is not as well supported by browsers as one > would wish. My experience is that the most effective way to coax a > browser to use a specific encoding when returning data is to send the > page in the encoding which you want the browser to use when returning > data. It looks like that's what's being done -- but be careful not to > count on a JSP "page" directive in a tile, since only the "outermost" > tile (the first one which writes to the response stream) has the > chance to set the page encoding. Fine. Then the most effective way would be to do both, probably :) > Also note that Struts' multipart processing currently is rather clumsy > in handling form encoding. If the request object returns null from > "getCharacterEncoding()", then Struts assumes ISO-8859-1. I was Isn't it Tomcat itself? This is a behaviour per servlets specifications (see page 41 of 2.4 specs). > setting the request encoding with a custom command in a chain-request > processor, but the request was still returning a null value in > CommonsMultipartRequestHandler where the non-uploaded fields were > being processed. Of course, this may have nothing to do with your > situation. As far as I know, this is a behaviour per specifications. Page 41 and 198 of servlets 2.4 specs: changing the character encoding must be done prior to reading request parameters or reading input. Odds are high there is something which reads input before you set the request encoding. > In the case where I have a non-multipart form, I have consistently > gotten suitable results simply by making sure that the form page is > delivered to the browser with the character encoding I want to use. Good to know! -- Guillaume Cottenceau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
