The way I see it, as long as the html login page going out to the browser has character-encoding set to UTF-8, then there are no processes between form submit and the redisplay of the login name which would change its encoding. The string goes thro the http request, into tomcat, into struts action form and then back out into the html page again. I'll soon see I guess.
Adam
On 09/24/2003 01:31 PM Joerg Heinicke wrote:
Adam Hardy wrote:
I can't see why. Perhaps you are overriding it later in the request processing? Struts uses response.setContentType()
The docs say: overridden automatically if a * <code>RequestDispatcher.forward()</code> call is * ultimately invoked.
but that leaves me none the wiser.
Possible. I'm not that deep in the servlet processes, don't know what strange things are done. (I come from the Cocoon world and I'm afraid from the low abstraction in general ;-) ).
But not the problem, we set the content type in one JSP that is included in every other JSP, so we have to maintain this also on one place only.
Joerg
Adam
On 09/23/2003 03:25 PM Joerg Heinicke wrote:
Joerg Heinicke wrote:
I found http://jakarta.apache.org/struts/api/org/apache/struts/config/ControllerConfig.html#contentType and set the contentType in the struts-config.xml with
<controller contentType="text/html;charset=UTF-8"/>.
Does not work as expected. Mozilla recognizes the pages know as ISO-8859-1 and no longer UTF-8.
Joerg
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
