RE: Problem with utf-8 encoding with struts

[Piero Colagrosso <pi...@thevco.com>]

Hi folks,

I've been struggling with exactly the same problem described by Ronald in
his initial post and have a few comments/questions regarding some of the
points discussed in this thread.

First of all, I think it's important for us to be very explicit about
whether we are referring to the encoding of the *request* or of the
*response*:

- As I understand it, Ron's original post is a problem relating to the
encoding used by the server when generating a *response*.

- However, the particular servlet filter being referred to in the follow-up
responses has to do with the encoding used to parse the *request* (please
correct me if I'm wrong).

In order to get a better understanding of what methods/settings apply to the
response and which ones apply to the request, I've found the following
summary to be very useful for me:

1. When processing a servlet *request*, the server uses the following order
of precedence, first to last, to determine the request character encoding: 

- Code-specific settings (the *request* methods setCharacterEncoding()) 
- Container specific settings (i.e., vendor specific)
- The default setting (ISO 8859-1)

2. When processing a servlet *response*, the server uses the following order
of precedence, first to last, to determine the response character encoding: 

- Code-specific settings (the *response* methods setContentType() and
setLocale(), or the JSP page directive equivalent mentioned by Ronald) 
- Container specific settings (i.e., vendor specific)
- The default setting (ISO 8859-1)

It's also interesting to note that in the case of Struts, the contentType
setting on the controller (set in struts-config.xml) only modifies the
*default* encoding, which can be overridden by the other settings which have
higher precedence.

In my case, what I've found is that if I want to make sure that my responses
are *always* encoded correctly (i.e., same as Paul's problem), I've had to
use a filter which actually wraps the response and encodes it in UTF-8 (via
an overriding of setContentType method).  The implementation I'm using is
actually described in detail at the following link:

http://www.javaworld.com/javaworld/jw-05-2004/jw-0524-i18n_p.html

BTW, the above link seems to provide the best and most up-to-date
information regarding all the issues that need to be taken into account in
order to provide end-to-end internationalization of a web application.  A
definite must read!!

Using a filter seems to be the best way to guarantee a consistent response
and request encoding, because then you don't have to worry about all the
other places in the applications (JSPs, taglibs, Tiles config, etc...) which
might incorrectly override and 'break' the required encoding.

Cheers,

   Piero 


> -----Original Message-----
From: John Cavacas 
Subject: RE: Problem with utf-8 encoding with struts 
Date: Mon, 17 May 2004 21:24:50 -0700

This is not just a problem with JSTL, it's a "problem" with JSPs in general.
A JSP page will default to the system encoding, and not what you may specify
on the response somewhere up the chain. 

I'm aware of 3 options. 

1) Use a Servlet filter as suggested. This only works on Servlet 2.3 and
higher containers. 

2) add this to the top of your JSPs maybe in an include:
<%@ page contentType = "text/html; charset=UTF-8" %>

3) Use another view technology like Velocity

And that's half the battle. The other half is making sure that you can
accept input as UTF-8. But that's a story for another day.

john

> -----Original Message-----
> From: Ronald van den Heuvel [mailto:[EMAIL PROTECTED]
> Sent: May 17, 2004 7:50 AM
> To: Struts Users Mailing List
> Subject: RE: Problem with utf-8 encoding with struts
> 
> Hm ok I will try the filter but this is not the real solution because I
> am not using any other taglibs. Only the standard Struts taglibs.
> 
> 
> 
> -----Original Message-----
> From: Paul McCulloch [mailto:[EMAIL PROTECTED]
> Sent: maandag 17 mei 2004 13:50
> To: 'Struts Users Mailing List'
> Subject: RE: Problem with utf-8 encoding with struts
> 
> That's an old version I gave the URL for. A better place to look would
> be in
> the Tomcat source.
> 
> Paul
> 
> > -----Original Message-----
> > From: Paul McCulloch [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 17, 2004 12:47 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Problem with utf-8 encoding with struts
> >
> >
> > This can happen if you use JSTL tags which overwrite whatever response
> > encoding you set.
> >
> > This can be fixed by using a filter to force the encoding
> >
> > http://www.anassina.com/struts/i18n/SetCharacterEncodingFilter.java
> >
> > Paul
> >
> > > -----Original Message-----
> > > From: Ronald van den Heuvel
> > [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, May 17, 2004 12:28 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Problem with utf-8 encoding with struts
> > >
> > >
> > >  Hello all,
> > >
> > >
> > >
> > > I am using Struts for a web-application and the web-page
> > should be in
> > > UTF-8 encoding, but the application keeps sending the
> > > following header:
> > > Content-Type: text/html;charset=ISO-8859-1. I take the
> > > following action
> > > to get the page into UTF-8.
> > >
> > >  - in the struts config file:
> > >
> > >               <controller contentType="text/html;charset=UTF-8"
> > > nocache="true" />
> > >
> > > - in the main tiles layout:
> > >
> > >             <%@ page language="java" contentType="text/xml;
> > > charset=UTF-8" %> (at the top)
> > >
> > >             <meta http-equiv="content-type" content="text/html;
> > > charset=UTF-8">( in the head part of the document)
> > >
> > >
> > >
> > > The page is valid xhtml 1.0 transitional and I get no errors what so
> > > ever. I tested it in mozilla and IE and both say it is the
> > ISO-8859-1
> > > content type.
> > >
> > >
> > >
> > > Does anybody know the solution to this problem?
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Ronald
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > **********************************************************************
> > Axios Email Confidentiality Footer
> > Privileged/Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this
> > message (or responsible for delivery of the message to such
> > person), you may not copy or deliver this message to anyone.
> > In such case, you should destroy this message, and notify us
> > immediately. If you or your employer does not consent to
> > Internet email messages of this kind, please advise us
> > immediately. Opinions, conclusions and other information
> > expressed in this message are not given or endorsed by my
> > Company or employer unless otherwise indicated by an
> > authorised representative independent of this message.
> > WARNING:
> > While Axios Systems Ltd takes steps to prevent computer
> > viruses from being transmitted via electronic mail
> > attachments we cannot guarantee that attachments do not
> > contain computer virus code.  You are therefore strongly
> > advised to undertake anti virus checks prior to accessing the
> > attachment to this electronic mail.  Axios Systems Ltd grants
> > no warranties regarding performance use or quality of any
> > attachment and undertakes no liability for loss or damage
> > howsoever caused.
> > **********************************************************************
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org