Glad to have been of help :)
Wow, finally, it works... Thank you indeed, I wouldn't have solved this without your help. I did missunderstand something in your former instructions, the part where I should move the encoding in my web.xml to before the Struts2 filter. It wouldn't have worked anyway I guess since ISO-8859-1 had other problems. But now everything is fine with UTF-8.Wow, it really lifted some burden of me. Thank you so much Jeroen!Cheers :) Niklas ----------------------------------------Date: Tue, 28 Apr 2009 13:46:48 +0200 From: voetsjo...@gmail.com To: user@struts.apache.org Subject: Re: Struts and encoding ISO-8859-1 You shouldn't technically need Struts 2.1.7 to be able to use UTF-8. If you want to stick with 2.1.6, there are two options: either you use useBodyEncodingForURI="true" in Tomcat's server.xml, or you explicitly set URIEncoding="UTF-8" in the connector. I'd advise you to use useBodyEncodingForURI, as this will still allow other webapps in the same Tomcat container to use their own, possibly different encodings. Because of the filter bug in Struts 2.1.6 though, you'll have to make the call to setCharacterEncoding yourself before the Struts filter kicks in. This is exactly what the filter you wrote in your original post does; you just have to make sure that it comes before the Struts 2 filter in your web.xml descriptor. Furthermore, you'll need to make sure that all your pages are sent as UTF-8. This is done in the same way I outlined earlier, ie. by setting the charset in your Content-type header. For JSPs this is done using the directive in your JSPs (I hope it won't garble the brackets now). You can easily verify the page encoding in Firefox by right-clicking anywhere on the page and selecting "View Page Info". You're interested in the "Encoding:" line, not the stuff in the Meta box. Also, you'll want Hibernate to connect to your database using a UTF-8 connection. You can do this by setting the properties hibernate.connection.useUnicode=true and hibernate.connection.characterEncoding=UTF-8. That should be about it. If you can't get it working and/or you'd like to try with a Struts 2.1.7, I can upload a snapshot build for you somewhere so you can try it out. Cheers, JeroenHello, I did download Struts2 trunk and current but count't build any without "BUILD FAILED". Will this be a problem (sorry for being a bit lazy, don't want to switch to 2.1.7 if it doesn't work...)? If I go back to UTF-8, do I need to upgrade to Struts 2.1.7 in order to get åäö working? Do you have any prescription for getting it to work with UTF-8, or is it the same as you already explained below?. I am not paranoid aout saving a few bytes :) Thanks again! Regards, Niklas ----------------------------------------Date: Sun, 26 Apr 2009 23:36:13 +0200 From: voetsjo...@gmail.com To: user@struts.apache.org Subject: Re: Struts and encoding ISO-8859-1 Well, ISO-8859-1 and UTF-8 differ in the fact that ISO-8859-1 is a single-byte encoding and can only encode 256 characters (albeit carefully chosen), while UTF-8 is a multi-byte encoding and can represent any character in the Unicode codespace (ie. any character you can think of). Both will use a single byte for code points 0-127; once you go past that, UTF-8 will start using two bytes, but ISO-8859-1 will run out after 256 characters. So unless you're absolutely paranoid about saving a few bytes of network traffic, UTF-8 is the way to go. If you're encoding text in the Latin-1 range, most of your characters are likely to be regular ASCII characters anyway (as well as all the HTML markup the user doesn't get to see). That, and you'll get the additional benefit of being able to handle anything your users throw at you which is, needless to say, a big plus on the interwebs.Hello, Thank you for you quick reply. Sorry if I was a bit unclear: I am posting via a form, in a JSP page, some information that at a later stage is stored in my DB. When I use åäöÅÄÖ it is messed up to ??????-signs when extracting it on the server side before trying to save it in the db. I didn't try to use ISO-8859-1 at first, but when UTF-8 didn't work I changed. I assume that why it didn't work was because of the bug and the configurations you mentioned below (server.xml config). I'll try tomorrow. What is the purpose of using ISO-8859-1 when it seems like UTF-8 works for all languages then? Or am I mistaken there? I have myself in the past (way back) used Big5 and Gb1251 (think it was) coding Chinese applications using Java. Don't know what happened to my e-mail I sent out, it's totally corrupted I can see now, a lot of information is missing (at least in my web-client...). But I think your answer helps me so I skip completing that missing information now. Thanks again! Regards, Niklas ----------------------------------------Date: Sun, 26 Apr 2009 21:52:23 +0200 From: voetsjo...@gmail.com To: user@struts.apache.org Subject: Re: Struts and encoding ISO-8859-1 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: 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: You can also set the same in a directive if you want, but all modern browsers use the value from the response header rather than the 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, JeroenHello, 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_________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org_________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org_________________________________________________________________ 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
