What exactly is giving you trouble? Are your HTTP parameters not
properly received? Does your DB data get garbled when you output it?
I've recently had problems with ISO-8859-1 and Struts 2 as well, and
there are some things you need to be aware of.
It turns out that by default Tomcat uses ISO-8859-1 exclusively for
decoding URI parameters, but only for the URI parameters. This can lead
to bizarre situations such as POST request parameters getting received
perfectly in UTF-8, but GET request parameters getting garbled into
ISO-8859-1. Now, the filter you wrote makes sense and I have found many
similar solutions when researching this issue myself, and Struts 2
actually already does this for you (check out the Dispatcher.prepare
method). The problem, however, is that setCharacterEncoding does not
affect the decoding of the URI parameters; at least not when your Tomcat
instance in Eclipse is set to its default configuration.
The solution is to either explicitly tell Tomcat which URI encoding to
use, or to tell it to use the same encoding as the request body. This
last option makes it so that it will use the encoding set by
setCharacterEncoding for decoding the URI (which is what you'll want).
You can do this by editing your tomcat's server.xml and adding the
attribute useBodyEncodingForURI="true" to your HTTP/1.1 Connector entry.
It would look like this:
<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1"
redirectPort="8443" useBodyEncodingForURI="true" />
Also, don't forget to manually publish to Tomcat for these changes to
take effect; for some reason it doesn't seem to pick up on the changes
unless you manually publish to Tomcat (or maybe I'm just impatient).
You're not out of the woods yet, however. There is also a bug in Struts
2.1.6's filters (eg. StrutsPrepareAndExecuteFilter) which causes the
call to setCharacterEncoding to be performed after the request map and
all the parameters have already been read, so that the call to
setCharacterEncoding become pretty much useless (see
https://issues.apache.org/struts/browse/WW-3075). This issue has been
fixed in Struts 2.1.7, so you can either stick with your current extra
Filter (which should also work fine, provided that useBodyEncodingForURI
is activated and that it comes before the struts filter) or go with a
2.1.7 snapshot. From what I can tell from the dev mailing list it's
pretty close to release, so you shouldn't have too many issues with it.
It uses xwork 2.1.3 as well, which was released recently and fixes at
least one important localization issue
(https://issues.apache.org/struts/browse/WW-2176), which might actually
very well be related to your problem.
Finally, make sure to set a charset in your HTTP Content-type response
header, like so:
Content-type: text/html; charset=iso-8859-1.
If you're using JSPs, for example, this is done using the page directive:
<%@ page contentType="text/html; charset=ISO-8859-1" %>
You can also set the same in a <meta> directive if you want, but all
modern browsers use the value from the response header rather than the
<meta> tag. More importantly, they will also send form data in the same
encoding used by the page the data is sent from. In short, if you send a
page with a form in it as ISO-8859-1 and the user submits the form,
their browser will send you the data as ISO-8859-1.
Having said all the above, I don't see a reason to go with ISO-8859-1
over UTF-8. Either way, I hope this helps you solve your issue. FYI, I
have UTF-8 fully working here using xwork 2.1.3 and a struts 2.1.7
snapshot. Should you decide to switch to UTF-8, I'll be happy to answer
your questions.
Cheers,
Jeroen
Hello,
Using Struts 2.1.6
Tomcat 6
Java 1.6
Eclipse Ganymede
I am trying to get my first Struts2 application working. Everything works fine except the encoding part. Swede as I am I want to use åäöÅÄÖ, i.e. ISO-8859-1, but it doesn't work.
I have searched the net and tried various things, but I think this is pointing in the correct direction so I did as explained (but that person used UTF-8 instead):
I created following file:
public class EncodingFilter implements Filter{
private String encoding = "ISO-8859-1";
@Override
public void destroy() {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException {
request.setCharacterEncoding(encoding);
response.setCharacterEncoding(encoding);
filterChain.doFilter(request, response);
}
@Override
public void init(FilterConfig filterConfig) throws ServletException {
// TODO Auto-generated method stub
String encodingParam = filterConfig.getInitParameter("encoding");
if (encodingParam != null) {
encoding = encodingParam;
}
}
}
My JSP files has this
and this
I added following part to web.xml
EncodingFilter
org.nicsoft.utilities.EncodingFilter
encoding
ISO-8859-1
EncodingFilter
/*
I assume I don't have to do anything else in order to get it working with doFiler, the application server automatically request the doFilter, correct?
I am also using Hibernate for storing data that I post from the form in MySQL. However, I am quite sure that Hiberante has nothing to do with the problem because I am doing I am writing the parameters to the console before Hibernate hooks in.
Can anyone help out, I have no idea how to proceed. I couldn't find any good how-to for this problem or posts on any forum. The best was the one I explained above.
Thank you in advance!
Best Regards,
Niklas
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
