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, > Jeroen > >> Hello, >> >> 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, >>>>> 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 >>>>> >>>>> >>>>> >>>> _________________________________________________________________ >>>> 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
