You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Niklas Johansson <ni...@hotmail.com> on 2009/04/26 21:07:30 UTC
Struts and encoding ISO-8859-1
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts and encoding ISO-8859-1
Posted by Jeroen De Ridder <vo...@gmail.com>.
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: voetsjoeba@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: voetsjoeba@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: voetsjoeba@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-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
RE: Struts and encoding ISO-8859-1
Posted by Niklas Johansson <ni...@hotmail.com>.
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: voetsjoeba@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: voetsjoeba@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: voetsjoeba@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-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts and encoding ISO-8859-1
Posted by Jeroen De Ridder <vo...@gmail.com>.
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
<%@ page contentType="text/html; charset=UTF-8" %> 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: voetsjoeba@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: voetsjoeba@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-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
RE: Struts and encoding ISO-8859-1
Posted by Niklas Johansson <ni...@hotmail.com>.
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: voetsjoeba@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: voetsjoeba@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-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts and encoding ISO-8859-1
Posted by Jeroen De Ridder <vo...@gmail.com>.
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: voetsjoeba@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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
RE: Struts and encoding ISO-8859-1
Posted by Niklas Johansson <ni...@hotmail.com>.
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: voetsjoeba@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts and encoding ISO-8859-1
Posted by Jeroen De Ridder <vo...@gmail.com>.
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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org