Re: S:url and s:param and character encoding
2014-09-01 13:17 GMT+02:00 Miguel Almeida : > I actually had ${answer} and it > worked corretly. I had to change to the alternative due to > an issue with a JSP page with a grouped view - somewhere in the code the > variable #answer is probably being set differently, so with ${answer} I > would get an array [id1,id2...] whereas with value="%{#answer}"/> I would get the correct fileName. What kind of issue? I think it will be hard to figure out what's wrong without example Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S:url and s:param and character encoding
On Mon, 2014-09-01 at 10:20 +0200, Lukasz Lenart wrote: > 2014-08-29 18:11 GMT+02:00 Miguel Almeida : > > I had an issue recently with a download action not finding the > > corresponding file and you might be able to help me with it. The > > filename (on disk) was "Calendário" ("á" is the focus here). > > > > I am using the following s:url (Calendário is within the variable > > #answer): > > > > > action="Filedownload"> > > > name="answer.id">${entityId} > > > name="fileName"> > > > > > href="%{downloadUrl}"> > value="%{#answer}"/> > > It can be an issue in DefaultUrlHelper as it uses > paramValue.toString() (which means it uses server's locale), did you > try to use ${answer} instead of > ? I actually had ${answer} and it worked corretly. I had to change to the alternative due to an issue with a JSP page with a grouped view - somewhere in the code the variable #answer is probably being set differently, so with ${answer} I would get an array [id1,id2...] whereas with I would get the correct fileName. > > > Regards
Re: S:url and s:param and character encoding
2014-08-29 18:11 GMT+02:00 Miguel Almeida : > I had an issue recently with a download action not finding the > corresponding file and you might be able to help me with it. The > filename (on disk) was "Calendário" ("á" is the focus here). > > I am using the following s:url (Calendário is within the variable > #answer): > > action="Filedownload"> > name="answer.id">${entityId} > value="%{#answer}"/> > > href="%{downloadUrl}"> value="%{#answer}"/> It can be an issue in DefaultUrlHelper as it uses paramValue.toString() (which means it uses server's locale), did you try to use ${answer} instead of ? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: S:url and s:param and character encoding
Struts URL modificada por request_locale de 'es' va a refeerncia el archivo de propiedades es global.name = Nombre de usuario global.age = Edad global.submit = Presentar global.heading = seleccionar la configuracion regional global.success = Autenticado correctamente Español <-- ¿no trabaja para ti ? --> > Subject: S:url and s:param and character encoding > From: mig...@almeida.at > To: user@struts.apache.org > Date: Fri, 29 Aug 2014 17:11:11 +0100 > > I had an issue recently with a download action not finding the > corresponding file and you might be able to help me with it. The > filename (on disk) was "Calendário" ("á" is the focus here). > > I am using the following s:url (Calendário is within the variable > #answer): > >action="Filedownload"> >name="answer.id">${entityId} >value="%{#answer}"/> > >href="%{downloadUrl}"> value="%{#answer}"/> > > If I use a plain-old and s:properties I get the normal behaviour: > >href="Filedownload.action?answer.id= value="%{#entityId}"/>&fileName= value="%{#answer}"/>"> > > Is there something missing from s:url? > I also found https://issues.apache.org/jira/browse/WW-2414 which seems > to mention something similar, but marked as solved in 2.0.x. > > Cheers, > > Miguel
S:url and s:param and character encoding
I had an issue recently with a download action not finding the corresponding file and you might be able to help me with it. The filename (on disk) was "Calendário" ("á" is the focus here). I am using the following s:url (Calendário is within the variable #answer): ${entityId} If I use a plain-old and s:properties I get the normal behaviour: &fileName="> Is there something missing from s:url? I also found https://issues.apache.org/jira/browse/WW-2414 which seems to mention something similar, but marked as solved in 2.0.x. Cheers, Miguel
AW: Problem with character encoding during redirect to another action
Thank you very much. This solved my problems. Best Regards, Rafael -Ursprüngliche Nachricht- Von: li wei [mailto:li.wei.linf...@gmail.com] Gesendet: Donnerstag, 27. Januar 2011 04:22 An: Struts Users Mailing List Betreff: Re: Problem with character encoding during redirect to another action I think this is not a struts issue. are you using tomcat as your server? you can try to set URIEncoding of Connector to "utf-8" in server.xml (2011/01/26 23:45), Rafael Karbowski wrote: > Hi @ all, > > > > I have a problem with the encoding of German umlauts. In the getter of the > source action they are correct, > > but the setter of the destination action sets bad encoded values. So far I > can´t find any solution for this problem. > > It would be nice, if somebody has an idea how to fix it. > > > > For a detailed description see > > http://stackoverflow.com/questions/4791166/struts-2-parameter-coding-problem-during-redirect-to-another-action > > > > Best Regards > > Rafael > > > > > > - 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
Re: Problem with character encoding during redirect to another action
I think this is not a struts issue. are you using tomcat as your server? you can try to set URIEncoding of Connector to "utf-8" in server.xml (2011/01/26 23:45), Rafael Karbowski wrote: Hi @ all, I have a problem with the encoding of German umlauts. In the getter of the source action they are correct, but the setter of the destination action sets bad encoded values. So far I can´t find any solution for this problem. It would be nice, if somebody has an idea how to fix it. For a detailed description see http://stackoverflow.com/questions/4791166/struts-2-parameter-coding-problem-during-redirect-to-another-action Best Regards Rafael - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Problem with character encoding during redirect to another action
Hi @ all, I have a problem with the encoding of German umlauts. In the getter of the source action they are correct, but the setter of the destination action sets bad encoded values. So far I can´t find any solution for this problem. It would be nice, if somebody has an idea how to fix it. For a detailed description see http://stackoverflow.com/questions/4791166/struts-2-parameter-coding-problem-during-redirect-to-another-action Best Regards Rafael
Re: Character Encoding Error using new filters
I have set UTF-8 as the default everywhere - struts, tomcat, sitemesh. I had a small breakthrough. It looks like it's a 2.1.6 specific issue. I updated a development version to 2.1.8 and 2.2.1 and both worked fine. I now have to find time to test the updated version for unintended consequences. Are there any issues I should look out for in particular when going from 2.1.6 to 2.2.1? Z. On 19/10/10 2:42 AM, "Dave Newton" wrote: >That defines the encoding of the web.xml file itself... >On Oct 18, 2010 10:32 AM, "Martin Gainty" wrote: >> >> Hi Zoran >> >> can you confirm the encoding attribute at the top of your web.xml e.g. >> >> >> in which case you *should* be able to map >> U+00C6Æc3 86LATIN CAPITAL LETTER AE >> http://www.utf8-chartable.de/ >> >> please confirm >> Martin Gainty >> __ >> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >> >> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >dient lediglich dem Austausch von Informationen und entfaltet keine >rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas >>le >destinataire prévu, nous te demandons avec bonté que pour satisfaire >informez l'expéditeur. N'importe quelle diffusion non autorisée ou la >copie >de ceci est interdite. Ce message sert à l'information seulement et n'aura >pas n'importe quel effet légalement obligatoire. Étant donné que les email >peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >aucune responsabilité pour le contenu fourni. >> >> >> >> >> >>> Date: Mon, 18 Oct 2010 12:05:56 +1100 >>> Subject: Character Encoding Error using new filters >>> From: zo...@sparecreative.com >>> To: user@struts.apache.org >>> >>> I have a really strange character encoding error that is appearing >>>when I >>> attempt to change my struts2 filter configuration from: >>> >>> >>> struts-cleanup >>> >>> >org.apache.struts2.dispatcher.ActionContextCleanUpla >>> ss> >>> >>> >>> struts >>> >>> >org.apache.struts2.dispatcher.FilterDispatcher> >>> >>> >>> sitemesh >>> >>> >com.opensymphony.module.sitemesh.filter.PageFilterla >>> ss> >>> >>> >>> >>> struts-cleanup >>> /* >>> >>> >>> sitemesh >>> /* >>> >>> >>> struts >>> /* >>> >>> >>> >>> To >>> >>> >>> struts-prepare >>> >>> >org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter< >/f >>> ilter-class> >>> >>> >>> >>> sitemesh >>> >>> >com.opensymphony.sitemesh.webapp.SiteMeshFilters> >>> >>> >>> >>> struts-execute >>> >>> >org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter< >/f >>> ilter-class> >>> >>> >>> >>> struts-prepare >>> /* >>> >>> >>> >>> sitemesh >>> /* >>> REQUEST >>> FORWARD >>> INCLUDE >>> >>> >>> >>> struts-execute >>> /* >>> >>> >>> >>> With only this change when I enter a 'æ' character (and e together) it >>> appears a A!|! (garbage). Clearly there is a character encoding issue >here. >>> The whole app as well as Tomcat is encoded to UTF-8. >>> >>> What am I missing here. Please help!!! >>> >>> Z. >> - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: RE: Character Encoding Error using new filters
That defines the encoding of the web.xml file itself... On Oct 18, 2010 10:32 AM, "Martin Gainty" wrote: > > Hi Zoran > > can you confirm the encoding attribute at the top of your web.xml e.g. > > > in which case you *should* be able to map > U+00C6Æc3 86LATIN CAPITAL LETTER AE > http://www.utf8-chartable.de/ > > please confirm > Martin Gainty > __ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > > > > > >> Date: Mon, 18 Oct 2010 12:05:56 +1100 >> Subject: Character Encoding Error using new filters >> From: zo...@sparecreative.com >> To: user@struts.apache.org >> >> I have a really strange character encoding error that is appearing when I >> attempt to change my struts2 filter configuration from: >> >> >> struts-cleanup >> >> org.apache.struts2.dispatcher.ActionContextCleanUp> ss> >> >> >> struts >> >> org.apache.struts2.dispatcher.FilterDispatcher >> >> >> sitemesh >> >> com.opensymphony.module.sitemesh.filter.PageFilter> ss> >> >> >> >> struts-cleanup >> /* >> >> >> sitemesh >> /* >> >> >> struts >> /* >> >> >> >> To >> >> >> struts-prepare >> >> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter> ilter-class> >> >> >> >> sitemesh >> >> com.opensymphony.sitemesh.webapp.SiteMeshFilter >> >> >> >> struts-execute >> >> org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter> ilter-class> >> >> >> >> struts-prepare >> /* >> >> >> >> sitemesh >> /* >> REQUEST >> FORWARD >> INCLUDE >> >> >> >> struts-execute >> /* >> >> >> >> With only this change when I enter a 'æ' character (and e together) it >> appears a A!|! (garbage). Clearly there is a character encoding issue here. >> The whole app as well as Tomcat is encoded to UTF-8. >> >> What am I missing here. Please help!!! >> >> Z. >
RE: Character Encoding Error using new filters
Hi Zoran can you confirm the encoding attribute at the top of your web.xml e.g. in which case you *should* be able to map U+00C6Æc3 86LATIN CAPITAL LETTER AE http://www.utf8-chartable.de/ please confirm Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Mon, 18 Oct 2010 12:05:56 +1100 > Subject: Character Encoding Error using new filters > From: zo...@sparecreative.com > To: user@struts.apache.org > > I have a really strange character encoding error that is appearing when I > attempt to change my struts2 filter configuration from: > > > struts-cleanup > > org.apache.struts2.dispatcher.ActionContextCleanUp ss> > > > struts > > org.apache.struts2.dispatcher.FilterDispatcher > > > sitemesh > > com.opensymphony.module.sitemesh.filter.PageFilter ss> > > > > struts-cleanup > /* > > > sitemesh > /* > > > struts > /* > > > > To > > > struts-prepare > > org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter ilter-class> > > > > sitemesh > > com.opensymphony.sitemesh.webapp.SiteMeshFilter > > > > struts-execute > > org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter ilter-class> > > > > struts-prepare > /* > > > > sitemesh > /* > REQUEST > FORWARD > INCLUDE > > > > struts-execute > /* > > > > With only this change when I enter a 'æ' character (and e together) it > appears a A!|! (garbage). Clearly there is a character encoding issue here. > The whole app as well as Tomcat is encoded to UTF-8. > > What am I missing here. Please help!!! > > Z.
Re: Character Encoding Error using new filters
Sorry, type error: > In your old configuration, [StrutsPrepareFilter] is the last filter applied > to request ==> Should be: In your old configuration, [FilterDispatcher] is the last filter applied to request 2010/10/18 Li Ying : > I did a quick look at the struts2.2.1 source code. > > It looks like the method [HttpServletRequest.setCharacterEncoding] > is invoked by class [FilterDispatcher] and [StrutsPrepareFilter]. > (You can use [Call Hierarchy] view to find out this information) > > In your old configuration, [StrutsPrepareFilter] is the last filter > applied to request, so the encoding set by this filter will > be used. > > But in your new configuration, [StrutsPrepareFilter] is the first > filter applied to request, so the encoding set by this filter > could be overridden by other filters later. > In your case, it could be overridden by [SiteMeshFilter]. > > I suggest you to read source or docs of [SiteMeshFilter], > check out if it changed CharacterEncoding and how to change the > setting of it to use a correct encoding. > > > > 2010/10/18 Zoran Avtarovski : >> I have a really strange character encoding error that is appearing when I >> attempt to change my struts2 filter configuration from: >> >> >> struts-cleanup >> >> org.apache.struts2.dispatcher.ActionContextCleanUp> ss> >> >> >> struts >> >> org.apache.struts2.dispatcher.FilterDispatcher >> >> >> sitemesh >> >> com.opensymphony.module.sitemesh.filter.PageFilter> ss> >> >> >> >> struts-cleanup >> /* >> >> >> sitemesh >> /* >> >> >> struts >> /* >> >> >> >> To >> >> >> struts-prepare >> >> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter> ilter-class> >> >> >> >> sitemesh >> >> com.opensymphony.sitemesh.webapp.SiteMeshFilter >> >> >> >> struts-execute >> >> org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter> ilter-class> >> >> >> >> struts-prepare >> /* >> >> >> >> sitemesh >> /* >> REQUEST >> FORWARD >> INCLUDE >> >> >> >> struts-execute >> /* >> >> >> >> With only this change when I enter a 'æ' character (and e together) it >> appears a A!|! (garbage). Clearly there is a character encoding issue here. >> The whole app as well as Tomcat is encoded to UTF-8. >> >> What am I missing here. Please help!!! >> >> Z. >> > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Character Encoding Error using new filters
I did a quick look at the struts2.2.1 source code. It looks like the method [HttpServletRequest.setCharacterEncoding] is invoked by class [FilterDispatcher] and [StrutsPrepareFilter]. (You can use [Call Hierarchy] view to find out this information) In your old configuration, [StrutsPrepareFilter] is the last filter applied to request, so the encoding set by this filter will be used. But in your new configuration, [StrutsPrepareFilter] is the first filter applied to request, so the encoding set by this filter could be overridden by other filters later. In your case, it could be overridden by [SiteMeshFilter]. I suggest you to read source or docs of [SiteMeshFilter], check out if it changed CharacterEncoding and how to change the setting of it to use a correct encoding. 2010/10/18 Zoran Avtarovski : > I have a really strange character encoding error that is appearing when I > attempt to change my struts2 filter configuration from: > > > struts-cleanup > > org.apache.struts2.dispatcher.ActionContextCleanUp ss> > > > struts > > org.apache.struts2.dispatcher.FilterDispatcher > > > sitemesh > > com.opensymphony.module.sitemesh.filter.PageFilter ss> > > > > struts-cleanup > /* > > > sitemesh > /* > > > struts > /* > > > > To > > > struts-prepare > > org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter ilter-class> > > > > sitemesh > > com.opensymphony.sitemesh.webapp.SiteMeshFilter > > > > struts-execute > > org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter ilter-class> > > > > struts-prepare > /* > > > > sitemesh > /* > REQUEST > FORWARD > INCLUDE > > > > struts-execute > /* > > > > With only this change when I enter a 'æ' character (and e together) it > appears a A!|! (garbage). Clearly there is a character encoding issue here. > The whole app as well as Tomcat is encoded to UTF-8. > > What am I missing here. Please help!!! > > Z. > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Character Encoding Error using new filters
I have a really strange character encoding error that is appearing when I attempt to change my struts2 filter configuration from: struts-cleanup org.apache.struts2.dispatcher.ActionContextCleanUp struts org.apache.struts2.dispatcher.FilterDispatcher sitemesh com.opensymphony.module.sitemesh.filter.PageFilter struts-cleanup /* sitemesh /* struts /* To struts-prepare org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter sitemesh com.opensymphony.sitemesh.webapp.SiteMeshFilter struts-execute org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter struts-prepare /* sitemesh /* REQUEST FORWARD INCLUDE struts-execute /* With only this change when I enter a 'æ' character (and e together) it appears a A!|! (garbage). Clearly there is a character encoding issue here. The whole app as well as Tomcat is encoded to UTF-8. What am I missing here. Please help!!! Z.
RE: Struts 1: character encoding
try to add in the character set you need to MySQL 5.4+ http://dev.mysql.com/doc/refman/5.4/en/adding-collation-unicode-uca.html if you cant locate the charset this means the characters you are adding are UTF-16 characters in which case you'll need to configure UTF-16 for both mysql and your container personally I have i couldnt get chinese colation to work with UTF-8 or any info is incorrect $MYSQL_HOME/share/charsets/index.xml Copyright (C) 2003 MySQL AB This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA This file lists all of the available character sets. To make maintaining easier please: - keep records sorted by collation number. - change charsets.max-id when adding a new collation. Traditional Chinese Big5 Traditional Chinese big-5 bigfive big-five cn-big5 csbig5 primary compiled binary compiled <..snip..> mysql> show collation like 'big5_chinese_ci'; +-+-++-+--+-+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-+-++-+--+-+ | big5_chinese_ci | big5| 1 | Yes | Yes | 1 | +-+-++-+--+-+ 1 row in set (0.02 sec) mysql> CREATE TABLE phonebook ( name VARCHAR(64), phone VARCHAR(64) CHARACTER SE T utf8 COLLATE big5_chinese_ci); ERROR 1253 (42000): COLLATION 'big5_chinese_ci' is not valid for CHARACTER SET ' utf8' feel free to correct if you found a way to install big5_chinese_ci on UTF-8 Martin Gainty __ BTW: all these languages listed here are UTF-8 languages: Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Tue, 6 Oct 2009 10:49:41 -0700 > From: tommy...@yahoo.com > Subject: Re: Struts 1: character encoding > To: user@struts.apache.org > > - Original Message > > From: senderj > > To: user@struts.apache.org > > Sent: Tue, October 6, 2009 3:28:08 AM > > Subject: Struts 1: character encoding > > > > > > The components I use NetBean, Glassfish, Struts 1, EJB, Toplink, jdbc, > > MySQL. > > Basically what I want is to extract info from a web site (utf8 encoded > > Chinese), store the info in MySQL, retrieve the info and display on my web > > site for user to update/change it. But I got problem on the character > > encoding. Here is briefly my logic and coding: > > > > (1) extract from a web page which uses UTF-8 encoded, my coding in an EJB > > run on glassfish: > > char c = (char) myInputStream.read(); > > Listtoken; > > token.add((byte) c); > > byte[] ba = new byte[token.size()]; > > for (int i=0; i > > ba[i] = token.get(i); > > } > > String s = new String(ba, "UTF-8"); > > > > I know it can be simpler, but it's a copy of others coding + my > > amendment. But it works. > > > > (2) String s above is stored onto MySQL via toplink, jdbc. Table is DEFAULT > > CHARSET=utf8. The jdbc URL is > > jdbc:mysql://mysys:3306/testing&useUnicode=true&characterEncoding=utf-8. > > > > (3) Retrieve by Struts Action via EJB. Both EJB
Re: Struts 1: character encoding
- Original Message > From: senderj > To: user@struts.apache.org > Sent: Tue, October 6, 2009 3:28:08 AM > Subject: Struts 1: character encoding > > > The components I use NetBean, Glassfish, Struts 1, EJB, Toplink, jdbc, MySQL. > Basically what I want is to extract info from a web site (utf8 encoded > Chinese), store the info in MySQL, retrieve the info and display on my web > site for user to update/change it. But I got problem on the character > encoding. Here is briefly my logic and coding: > > (1) extract from a web page which uses UTF-8 encoded, my coding in an EJB > run on glassfish: > char c = (char) myInputStream.read(); > Listtoken; > token.add((byte) c); > byte[] ba = new byte[token.size()]; > for (int i=0; i > ba[i] = token.get(i); > } > String s = new String(ba, "UTF-8"); > > I know it can be simpler, but it's a copy of others coding + my > amendment. But it works. > > (2) String s above is stored onto MySQL via toplink, jdbc. Table is DEFAULT > CHARSET=utf8. The jdbc URL is > jdbc:mysql://mysys:3306/testing&useUnicode=true&characterEncoding=utf-8. > > (3) Retrieve by Struts Action via EJB. Both EJB and Action does not have > change of string encoding. The Action put the Chinese string into a > DynaForm, then to JSP. JSP has <%...@page contentType="text/html" > pageEncoding="UTF-8"%> and it generates an html input form. > > (4) However, the Chinese characters were NOT displayed properly in the html > form on IE. > > (5) Anyway, in the html form, I override the incorrect Chinese character by > a writing pad with the correct characters (equivalent to unicode "9326 > 6c5f") and submit. Again, no re-encoding in the Action that process the > update. The Action calls an EJB to update the database with the input data. > But I found that the database was updated with ascii string > "錦江" (exactly this string, not its equivalent > encoded). > > I feel somehow there is/are encoding changes done by the software components > I use (Struts? toplink? jdbc?), but don't know which one and I may be wrong. > If anybody has any idea on this problem please help. > -- > View this message in context: > http://www.nabble.com/Struts-1%3A-character-encoding-tp25766281p25766281.html > Sent from the Struts - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org If you're using Tomcat and doing POST via URL, you need to change Tomcat's URL charset encoding. Default is ISO-8859-1, if I remember correctly. Regards, Tommy - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Struts 1: character encoding
The components I use NetBean, Glassfish, Struts 1, EJB, Toplink, jdbc, MySQL. Basically what I want is to extract info from a web site (utf8 encoded Chinese), store the info in MySQL, retrieve the info and display on my web site for user to update/change it. But I got problem on the character encoding. Here is briefly my logic and coding: (1) extract from a web page which uses UTF-8 encoded, my coding in an EJB run on glassfish: char c = (char) myInputStream.read(); List token; token.add((byte) c); byte[] ba = new byte[token.size()]; for (int i=0; i and it generates an html input form. (4) However, the Chinese characters were NOT displayed properly in the html form on IE. (5) Anyway, in the html form, I override the incorrect Chinese character by a writing pad with the correct characters (equivalent to unicode "9326 6c5f") and submit. Again, no re-encoding in the Action that process the update. The Action calls an EJB to update the database with the input data. But I found that the database was updated with ascii string "錦江" (exactly this string, not its equivalent encoded). I feel somehow there is/are encoding changes done by the software components I use (Struts? toplink? jdbc?), but don't know which one and I may be wrong. If anybody has any idea on this problem please help. -- View this message in context: http://www.nabble.com/Struts-1%3A-character-encoding-tp25766281p25766281.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Character Encoding and s:textarea
I found the problem and it does not involve Struts 2.We changed our SQL Server 2005 Text columns to varcharmax. For Java to properly read the characters out of the DB we had to use rs.getCharacterStream. Thank you for your help. On Thu, Jul 3, 2008 at 5:01 PM, Laurie Harper <[EMAIL PROTECTED]> wrote: > Richard Sayre wrote: >> >> I have a form containing text areas. When I copy a bunch of character >> data such as: >> 2öÂnJ1ÈÏúÄp8éÎdìåmðh4uæEÍÉieÔWán2ÅìbØÉÅÀ1JÎZÏôsC5LòÚAPúÜaÃÙPC5üÆCJWCOzùÙtÒQqùét >> >> into the text are, it displays normally. When I save the data, the >> database stores the characters properly, when the data returns to the >> s:textarea I displays with ?? replacing some characters. >> >> I can't figure out where this is happening. When I write the data out >> to the page as text it all displays properly. When I initially paste >> it into the textarea it displays correctly, so my browser supports the >> character set (ISO-8859-1 or Latin-1). It's only when it comes from >> the database to the textarea that the characters do not display. And >> I verified that the database can handle the characters and that they >> are stored correctly. >> >> This causes a problem when the user saves the second time, the ? get >> saved in the db as ?. >> >> Any ideas as to what is happening or how to fix it? >> >> Thank you, >> >> Rich > > - Are the characters retrieved from the database correctly? (i.e. if you > check the data you're sending to the textarea, is it right?) > > - What character encoding are you using to serve the page? > > - Do you have a @page directive in the JSP specifying the correct character > encoding? > > - Do you have a meta-equiv element in your HTML area to tell the > browser what encoding the page is in? > > - I assume you are using Struts :-) What version? > > L. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character Encoding and s:textarea
Richard Sayre wrote: I have a form containing text areas. When I copy a bunch of character data such as: 2öÂnJ1ÈÏúÄp8éÎdìåmðh4uæEÍÉieÔWán2ÅìbØÉÅÀ1JÎZÏôsC5LòÚAPúÜaÃÙPC5üÆCJWCOzùÙtÒQqùét into the text are, it displays normally. When I save the data, the database stores the characters properly, when the data returns to the s:textarea I displays with ?? replacing some characters. I can't figure out where this is happening. When I write the data out to the page as text it all displays properly. When I initially paste it into the textarea it displays correctly, so my browser supports the character set (ISO-8859-1 or Latin-1). It's only when it comes from the database to the textarea that the characters do not display. And I verified that the database can handle the characters and that they are stored correctly. This causes a problem when the user saves the second time, the ? get saved in the db as ?. Any ideas as to what is happening or how to fix it? Thank you, Rich - Are the characters retrieved from the database correctly? (i.e. if you check the data you're sending to the textarea, is it right?) - What character encoding are you using to serve the page? - Do you have a @page directive in the JSP specifying the correct character encoding? - Do you have a meta-equiv element in your HTML area to tell the browser what encoding the page is in? - I assume you are using Struts :-) What version? L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Character Encoding and s:textarea
I have a form containing text areas. When I copy a bunch of character data such as: 2öÂnJ1ÈÏúÄp8éÎdìåmðh4uæEÍÉieÔWán2ÅìbØÉÅÀ1JÎZÏôsC5LòÚAPúÜaÃÙPC5üÆCJWCOzùÙtÒQqùét into the text are, it displays normally. When I save the data, the database stores the characters properly, when the data returns to the s:textarea I displays with ?? replacing some characters. I can't figure out where this is happening. When I write the data out to the page as text it all displays properly. When I initially paste it into the textarea it displays correctly, so my browser supports the character set (ISO-8859-1 or Latin-1). It's only when it comes from the database to the textarea that the characters do not display. And I verified that the database can handle the characters and that they are stored correctly. This causes a problem when the user saves the second time, the ? get saved in the db as ?. Any ideas as to what is happening or how to fix it? Thank you, Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Character encoding for http request - Configuration for complete application
I am working on I18N application. To handle Http request and response in utf8 I have added following code in my Actionform. Is there way in struts to configure this for my complete application in struts? If it is normal servlet we can do this in init() method. public void reset(ActionMapping mapping, HttpServletRequest request) { super.reset(mapping, request); //To reset all input fields try { request.setCharacterEncoding("UTF-8"); } catch (UnsupportedEncodingException ex) { } }// end of reset()
Re: Character encoding problems with Struts 2 and Freemarker or Velocity
Thanks a lot, that has sorted it out. I'm a bit confused as to why changing the default from utf-8 works though... Jonny Cavell wrote: > > I am setting default_encoding=UTF-8 in freemarker.properties, and leaving > the struts encoding in default.properties untouched (i.e. > struts.i18n.encoding=UTF-8). When I use a struts action to forward to a > test page with Spanish text, without specifying the type (thus defaulting > to jsp), it outputs fine. However, if the action forwards to the same > page, but specifying the type as freemarker, the output is garbled. It is > also garbled for Velocity, making me think that the problem must lie > somewhere within Struts 2. > > Even if I subclass FreemarkerManager, override the createConfiguration > method and explicitly call config.setDefaultEncoding("utf-8") here, and > specify this class as the struts.freemarker.manager.classname in > struts.properties, it makes no difference - the output is garbled. > > Does anybody know why this might be the case? > > Thanks > > Jonny > > -- View this message in context: http://www.nabble.com/Character-encoding-problems-with-Struts-2-and-Freemarker-or-Velocity-tp14538951p14575550.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Character encoding problems with Struts 2 and Freemarker or Velocity
http://www.opensymphony.com/webwork/wikidocs/WebWork%20Freemarker%20Support.html default-encoding needs to be set to ISO-8859-1 in freemarker.properties more specifically: default_encoding=ISO-8859-1 template_update_delay=5 locale=no_NO HTHMartin__Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.> Date: Sat, 29 Dec 2007 08:23:01 -0800> From: [EMAIL PROTECTED]> To: user@struts.apache.org> Subject: Character encoding problems with Struts 2 and Freemarker or Velocity> > > I am setting default_encoding=UTF-8 in freemarker.properties, and leaving the> struts encoding in default.properties untouched (i.e.> struts.i18n.encoding=UTF-8). When I use a struts action to forward to a test> page with Spanish text, without specifying the type (thus defaulting to> jsp), it outputs fine. However, if the action forwards to the same page, but> specifying the type as freemarker, the output is garbled. It is also garbled> for Velocity, making me think that the problem must lie somewhere within> Struts 2.> > Even if I subclass FreemarkerManager, override the createConfiguration> method and explicitly call config.setDefaultEncoding("utf-8") here, and> specify this class as the struts.freemarker.manager.classname in> struts.properties, it makes no difference - the output is garbled.> > Does anybody know why this might be the case?> > Thanks> > Jonny> > -- > View this message in context: http://www.nabble.com/Character-encoding-problems-with-Struts-2-and-Freemarker-or-Velocity-tp14538951p14538951.html> Sent from the Struts - User mailing list archive at Nabble.com.> > > -> To unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]> _ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/
Character encoding problems with Struts 2 and Freemarker or Velocity
I am setting default_encoding=UTF-8 in freemarker.properties, and leaving the struts encoding in default.properties untouched (i.e. struts.i18n.encoding=UTF-8). When I use a struts action to forward to a test page with Spanish text, without specifying the type (thus defaulting to jsp), it outputs fine. However, if the action forwards to the same page, but specifying the type as freemarker, the output is garbled. It is also garbled for Velocity, making me think that the problem must lie somewhere within Struts 2. Even if I subclass FreemarkerManager, override the createConfiguration method and explicitly call config.setDefaultEncoding("utf-8") here, and specify this class as the struts.freemarker.manager.classname in struts.properties, it makes no difference - the output is garbled. Does anybody know why this might be the case? Thanks Jonny -- View this message in context: http://www.nabble.com/Character-encoding-problems-with-Struts-2-and-Freemarker-or-Velocity-tp14538951p14538951.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Struts to use UTF-8 character encoding
To muddy the waters a little further! If for some reason (e.g. you are writing a JSR168 portlet) you cannot use a servlet filters to force UTF-8 encoding, you can alternatively use a ServletRequestListener. HTH Mark Adam Gordon wrote: So, for posterity, we finally got this working. After several days of playing around with a sandbox Struts application that worked, but our webapp that didn't, we finally realized that the ORDER of the filters matters (duh...). We put the character encoding filter first in our chain and it fixed everything. The problem was it was initially #3 in the chain and in filter #2 I was reading parameters off the request to look for specific parameters to mitigate another bug we'd found in production and apparently, whether by design or otherwise, once you read parameters off the request setting the character encoding afterwards appears to have no effect. As mentioned above, moving the character encoding filter to #1 in the chain fixed it. Adam Gordon wrote: I didn't know that page existed though it's essentially what I wound up doing. My only concern now is that it affects our entire webapp and while QA was going to do a full regression anyway, I'm wondering what potential problems are now lurking in the deep, dark corners of our web forms... Thanks for the link. --adam Ted Husted wrote: On Nov 28, 2007 10:53 AM, Adam Gordon <[EMAIL PROTECTED]> wrote: What about the use of a filter to set the character encoding? Is this the only way to go for Struts? I'd say so. It might be possible to add something to the ActionServlet, but the solution wouldn't be any less "heavy handed" than using a filter. This sort of thing is why filters were invented :) There's a page on the Tomcat wiki that talks about setting up a UTF filter, if you haven't seen it. * http://wiki.apache.org/tomcat/Tomcat/UTF-8 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Struts to use UTF-8 character encoding
So, for posterity, we finally got this working. After several days of playing around with a sandbox Struts application that worked, but our webapp that didn't, we finally realized that the ORDER of the filters matters (duh...). We put the character encoding filter first in our chain and it fixed everything. The problem was it was initially #3 in the chain and in filter #2 I was reading parameters off the request to look for specific parameters to mitigate another bug we'd found in production and apparently, whether by design or otherwise, once you read parameters off the request setting the character encoding afterwards appears to have no effect. As mentioned above, moving the character encoding filter to #1 in the chain fixed it. Adam Gordon wrote: I didn't know that page existed though it's essentially what I wound up doing. My only concern now is that it affects our entire webapp and while QA was going to do a full regression anyway, I'm wondering what potential problems are now lurking in the deep, dark corners of our web forms... Thanks for the link. --adam Ted Husted wrote: On Nov 28, 2007 10:53 AM, Adam Gordon <[EMAIL PROTECTED]> wrote: What about the use of a filter to set the character encoding? Is this the only way to go for Struts? I'd say so. It might be possible to add something to the ActionServlet, but the solution wouldn't be any less "heavy handed" than using a filter. This sort of thing is why filters were invented :) There's a page on the Tomcat wiki that talks about setting up a UTF filter, if you haven't seen it. * http://wiki.apache.org/tomcat/Tomcat/UTF-8 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Struts to use UTF-8 character encoding
I didn't know that page existed though it's essentially what I wound up doing. My only concern now is that it affects our entire webapp and while QA was going to do a full regression anyway, I'm wondering what potential problems are now lurking in the deep, dark corners of our web forms... Thanks for the link. --adam Ted Husted wrote: On Nov 28, 2007 10:53 AM, Adam Gordon <[EMAIL PROTECTED]> wrote: What about the use of a filter to set the character encoding? Is this the only way to go for Struts? I'd say so. It might be possible to add something to the ActionServlet, but the solution wouldn't be any less "heavy handed" than using a filter. This sort of thing is why filters were invented :) There's a page on the Tomcat wiki that talks about setting up a UTF filter, if you haven't seen it. * http://wiki.apache.org/tomcat/Tomcat/UTF-8 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Struts to use UTF-8 character encoding
On Nov 28, 2007 10:53 AM, Adam Gordon <[EMAIL PROTECTED]> wrote: > What about the use of a filter to set the character encoding? Is this > the only way to go for Struts? I'd say so. It might be possible to add something to the ActionServlet, but the solution wouldn't be any less "heavy handed" than using a filter. This sort of thing is why filters were invented :) There's a page on the Tomcat wiki that talks about setting up a UTF filter, if you haven't seen it. * http://wiki.apache.org/tomcat/Tomcat/UTF-8 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Struts to use UTF-8 character encoding
Right, hence my last comment in the second paragraph... Incidentally, I saw that web page yesterday and was the one who added the anonymous posting about the URIEncoding attribute not appearing to do anything. What about the use of a filter to set the character encoding? Is this the only way to go for Struts? --adam Martin Gainty wrote: Adam- remember the URI_Encoding for your mod_jk connector http://confluence.atlassian.com/display/DOC/Configuring+Tomcat's+URI+encodin g M-- - Original Message - From: "Adam Gordon" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Tuesday, November 27, 2007 6:09 PM Subject: Configuring Struts to use UTF-8 character encoding Anyone know if there's a configuration parameter somewhere in Struts 1.2.9 that configures the requests to use UTF-8 character encoding? Everything I've found on the web says that Tomcat uses ISO-8859-1 as the default character encoding and that the "fix" is to add a filter that simply sets the character encoding on every request and it works, but it seems a bit heavy-handed. Reading the Tomcat configuration pages (for 5.5) talks about setting the URIEncoding attribute on the Connector element but that doesn't appear to have any effect in my sandbox application. It's possible it's needed for when running Tomcat behind Apache. What about adding the afore mentioned code to our webapp's action servlet or is this basically a glorified filter in the case where a webapp is really only using Struts - which our webapp is? Thoughts? --adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring Struts to use UTF-8 character encoding
Anyone know if there's a configuration parameter somewhere in Struts 1.2.9 that configures the requests to use UTF-8 character encoding? Everything I've found on the web says that Tomcat uses ISO-8859-1 as the default character encoding and that the "fix" is to add a filter that simply sets the character encoding on every request and it works, but it seems a bit heavy-handed. Reading the Tomcat configuration pages (for 5.5) talks about setting the URIEncoding attribute on the Connector element but that doesn't appear to have any effect in my sandbox application. It's possible it's needed for when running Tomcat behind Apache. What about adding the afore mentioned code to our webapp's action servlet or is this basically a glorified filter in the case where a webapp is really only using Struts - which our webapp is? Thoughts? --adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
If you mean like System.out.println(request.getCharacterEncoding()) in top of JSP, I guess I have, have to make a second check though, will return when it's done. Really appreciate your aid, thanks /Riffla = Christopher Schultz-2 wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Riffla, > > riffla wrote: >> Encoding set in: >> >> JSP Page directive >> Content inside Html Meta tag >> And there is also a charsetFilter class used (see below) > > This last one is used for overriding /request/ encoding, right? > >> > That looks good. > >> >> PARAMETER_ENCODING >> UTF-8 >> > > Have you verified that the request encoding is being properly set to > UTF-8? > >> And beside those already mentioned, there's also some lines in >> struts-html.tld: >> >> useLocalEncoding >> false >> true >> > > Hmm... I'm not sure what effect that will have (I don't use JSP). > > - -chris > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGBTHz9CaO5/Lv0PARAhBmAJ9tZwUR1Z0cR8tEBVbPgg05jlcSsQCgjyN+ > p7Ca211yjPSdh1QzQa7Z1Us= > =9SFl > -END PGP SIGNATURE- > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9652704 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Riffla, riffla wrote: > Here's the content of the filter class: [snip] > public void doFilter(ServletRequest request, ServletResponse response, > FilterChain chain) > throws IOException, ServletException { > > request.setCharacterEncoding("UTF-8"); > log.debug(this.getClass().getName() + ": Setting request to " + > request.getCharacterEncoding()); > chain.doFilter(request, response); > } I don't believe this is correct. You should only be overriding the request's encoding when none is provided. Try something like this: public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if(null == request.getCharacterEncoding()) { request.setCharacterEncoding("UTF-8"); log.debug(this.getClass().getName() + ": Set request to " + request.getCharacterEncoding()); chain.doFilter(request, response); } } If you are overriding the browser's character encoding, then you are making a mistake. Also note that this is only setting the character encoding for the request /body/, not for the URL being requested. If your POST requests are failing, the problem might be fixed with the above code. If GET requests are failing, then the problem is elsewhere. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBTLs9CaO5/Lv0PARAic0AKChoeCPSl8fcLZjY5S3E/ZYsPJKWQCfX2Kw i8kt/TNqSc2VE158d8cLYo0= =R3iH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Riffla, riffla wrote: > Encoding set in: > > JSP Page directive > Content inside Html Meta tag > And there is also a charsetFilter class used (see below) This last one is used for overriding /request/ encoding, right? > > PARAMETER_ENCODING > UTF-8 > Have you verified that the request encoding is being properly set to UTF-8? > And beside those already mentioned, there's also some lines in > struts-html.tld: > > useLocalEncoding > false > true > Hmm... I'm not sure what effect that will have (I don't use JSP). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBTHz9CaO5/Lv0PARAhBmAJ9tZwUR1Z0cR8tEBVbPgg05jlcSsQCgjyN+ p7Ca211yjPSdh1QzQa7Z1Us= =9SFl -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
Her's the content of the filter class: package se.telia.kontaktamig.web.util; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import javax.servlet.*; import java.io.IOException; public class CharsetFilter implements Filter { private static Log log = LogFactory.getLog(se.telia.kontaktamig.web.util.CharsetFilter.class); public void init(FilterConfig config) throws ServletException { log.info(this.getClass().getName() + ": Starting filter."); } public void destroy() { log.info(this.getClass().getName() + ": Destroying filter."); } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { request.setCharacterEncoding("UTF-8"); log.debug(this.getClass().getName() + ": Setting request to " + request.getCharacterEncoding()); chain.doFilter(request, response); } } Thanks for your response, guys == Martin Gainty wrote: > > Riffla- > can we see the contents of se.telia.kontaktamig.web.util.CharsetFilter? > M-- > --- > This e-mail message (including attachments, if any) is intended for the > use of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. > --- > Le présent message électronique (y compris les pièces qui y sont annexées, > le cas échéant) s'adresse au destinataire indiqué et peut contenir des > renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le > destinataire de ce document, nous vous signalons qu'il est strictement > interdit de le diffuser, de le distribuer ou de le reproduire. > - Original Message - > From: "riffla" <[EMAIL PROTECTED]> > To: > Sent: Friday, March 23, 2007 9:42 PM > Subject: Re: Character encoding... > > >> >> Encoding set in: >> >> JSP Page directive >> Content inside Html Meta tag >> And there is also a charsetFilter class used (see below) >> >> Struts-config.xml contains: >> === >> > processorClass="org.apache.struts.tiles.TilesRequestProcessor"/> >> === >> >> web.xml contains: >> === >> >> Character Encoding >> se.telia.kontaktamig.web.util.CharsetFilter >> >> >> >> Character Encoding >> /* >> >> >> >> PARAMETER_ENCODING >> UTF-8 >> >> //To be used and loaded as a common property from within Java/JSP code >> === >> >> >> >> And beside those alreade mentioned, there's also som lines in >> struts-html.tld: >> >> useLocalEncoding >> false >> true >> >> for some tag elements (img, link and rewrite tags) >> >> That's about it... >> >> /Riffla >> >> >> Christopher Schultz-2 wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Riffla, >>> >>> riffla wrote: >>>> Of course, forgot to mention, mainly I mean as output on a JSP page >>>> (both >>>> bean:write and <%=...%>, but also System.out.println() in different >>>> places, >>>> always the same result... >>> >>> The method of output is not relevant. Only the character encoding is. >>> Where do you set the character encoding of your pages? >>> >>> - -chris >>> >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.7 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d >>> pZH1HfI4X+5nuznbG/9UaXA= >>> =qVbS >>> -END PGP SIGNATURE- >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Character-encoding...-tf297678.html#a9646134 >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9647817 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
Riffla- can we see the contents of se.telia.kontaktamig.web.util.CharsetFilter? M-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. - Original Message - From: "riffla" <[EMAIL PROTECTED]> To: Sent: Friday, March 23, 2007 9:42 PM Subject: Re: Character encoding... > > Encoding set in: > > JSP Page directive > Content inside Html Meta tag > And there is also a charsetFilter class used (see below) > > Struts-config.xml contains: > === > processorClass="org.apache.struts.tiles.TilesRequestProcessor"/> > === > > web.xml contains: > === > > Character Encoding > se.telia.kontaktamig.web.util.CharsetFilter > > > > Character Encoding > /* > > > > PARAMETER_ENCODING > UTF-8 > > //To be used and loaded as a common property from within Java/JSP code > === > > > > And beside those alreade mentioned, there's also som lines in > struts-html.tld: > > useLocalEncoding > false > true > > for some tag elements (img, link and rewrite tags) > > That's about it... > > /Riffla > > > Christopher Schultz-2 wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Riffla, >> >> riffla wrote: >>> Of course, forgot to mention, mainly I mean as output on a JSP page (both >>> bean:write and <%=...%>, but also System.out.println() in different >>> places, >>> always the same result... >> >> The method of output is not relevant. Only the character encoding is. >> Where do you set the character encoding of your pages? >> >> - -chris >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.7 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d >> pZH1HfI4X+5nuznbG/9UaXA= >> =qVbS >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Character-encoding...-tf297678.html#a9646134 > Sent from the Struts - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Character encoding...
Encoding set in: JSP Page directive Content inside Html Meta tag And there is also a charsetFilter class used (see below) Struts-config.xml contains: === === web.xml contains: === Character Encoding se.telia.kontaktamig.web.util.CharsetFilter Character Encoding /* PARAMETER_ENCODING UTF-8 //To be used and loaded as a common property from within Java/JSP code === And beside those alreade mentioned, there's also som lines in struts-html.tld: useLocalEncoding false true for some tag elements (img, link and rewrite tags) That's about it... /Riffla Christopher Schultz-2 wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Riffla, > > riffla wrote: >> Of course, forgot to mention, mainly I mean as output on a JSP page (both >> bean:write and <%=...%>, but also System.out.println() in different >> places, >> always the same result... > > The method of output is not relevant. Only the character encoding is. > Where do you set the character encoding of your pages? > > - -chris > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d > pZH1HfI4X+5nuznbG/9UaXA= > =qVbS > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9646134 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Riffla, riffla wrote: > Of course, forgot to mention, mainly I mean as output on a JSP page (both > bean:write and <%=...%>, but also System.out.println() in different places, > always the same result... The method of output is not relevant. Only the character encoding is. Where do you set the character encoding of your pages? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d pZH1HfI4X+5nuznbG/9UaXA= =qVbS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
Of course, forgot to mention, mainly I mean as output on a JSP page (both bean:write and <%=...%>, but also System.out.println() in different places, always the same result... /Riffla Christopher Schultz-2 wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Riffla, > > riffla wrote: >> Sending a request form a JSP using ISO-8859-1 with POST method (no >> problem >> using GET method or UTF-8 on origin page) to either a Struts action or >> another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä >> and ö with '?' > > Where do you see the '?'? In a web page? In a log file? In the results > of a database query from a command-line tool? It's possible that your > output isn't sensitive to the character encoding (for instance, a > terminal window or log file). > >> even though I've set the Connector property (Tomcat as >> server) to UTF-8. > > URIEncoding="UTF-8" only affects the interpretation of the URL string in > the request, not the body of the request. The body of the request is > interpreted using the content-type HTTP header. > >> So the problem seems to happen with the POST data in the >> request when going from ISO to UTF using POST method... > > If you are submitting data with a content-type of ISO-8859-1 and then > forcing the request's encoding to be UTF-8, then you are introducing the > problem yourself. ISO != UTF-8, so you shouldn't be doing that. If you > really need to use non-ASCII characters at all, then you should convert > everything to UTF-8. Make sure that all your pages use UTF-8 as the > response encoding, and all POST forms should then use UTF-8 as the > request body encoding. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGBAxn9CaO5/Lv0PARAoNRAJ94LWHNQdZbzTd5wXq6Z/nGfZAsCwCgrkAC > ZupLQFeCLlyi/kit/l9EDxo= > =Gwxy > -END PGP SIGNATURE- > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9642739 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Riffla, riffla wrote: > Sending a request form a JSP using ISO-8859-1 with POST method (no problem > using GET method or UTF-8 on origin page) to either a Struts action or > another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä > and ö with '?' Where do you see the '?'? In a web page? In a log file? In the results of a database query from a command-line tool? It's possible that your output isn't sensitive to the character encoding (for instance, a terminal window or log file). > even though I've set the Connector property (Tomcat as > server) to UTF-8. URIEncoding="UTF-8" only affects the interpretation of the URL string in the request, not the body of the request. The body of the request is interpreted using the content-type HTTP header. > So the problem seems to happen with the POST data in the > request when going from ISO to UTF using POST method... If you are submitting data with a content-type of ISO-8859-1 and then forcing the request's encoding to be UTF-8, then you are introducing the problem yourself. ISO != UTF-8, so you shouldn't be doing that. If you really need to use non-ASCII characters at all, then you should convert everything to UTF-8. Make sure that all your pages use UTF-8 as the response encoding, and all POST forms should then use UTF-8 as the request body encoding. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBAxn9CaO5/Lv0PARAoNRAJ94LWHNQdZbzTd5wXq6Z/nGfZAsCwCgrkAC ZupLQFeCLlyi/kit/l9EDxo= =Gwxy -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
Thanks for the reply Actually, we do use a filter setting the encoding to UTF-8, though I'm not sure if my problem is exactly the same as above. Sending a request form a JSP using ISO-8859-1 with POST method (no problem using GET method or UTF-8 on origin page) to either a Struts action or another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä and ö with '?', even though I've set the Connector property (Tomcat as server) to UTF-8. So the problem seems to happen with the POST data in the request when going from ISO to UTF using POST method... having ran my head against this encoding wall too long now, I'm hoping to get some clues from you guys... /Riffla Christopher Schultz-2 wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Riffla, > > riffla wrote: >> And I guess that the form bean attributes is set prior to any code in the >> form class, so that you can't set the characterEncoding in the form class >> (at, for example, the beginning of initialize() method), or...? > > Correct. You have to use a Filter to do this. Search the archives for > "character encoding filter" and you should find a lot of information, > including the code for the filter itself (or at least a link to the code). > > - -chris > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGA8QY9CaO5/Lv0PARAn7AAJ4vklzBFWc2/m2Go6EHv68eGoe6LQCgrNcX > peNhqvneyvg8Fsmbn99nwEI= > =LZZ+ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9634418 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Riffla, riffla wrote: > And I guess that the form bean attributes is set prior to any code in the > form class, so that you can't set the characterEncoding in the form class > (at, for example, the beginning of initialize() method), or...? Correct. You have to use a Filter to do this. Search the archives for "character encoding filter" and you should find a lot of information, including the code for the filter itself (or at least a link to the code). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGA8QY9CaO5/Lv0PARAn7AAJ4vklzBFWc2/m2Go6EHv68eGoe6LQCgrNcX peNhqvneyvg8Fsmbn99nwEI= =LZZ+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding...
And I guess that the form bean attributes is set prior to any code in the form class, so that you can't set the characterEncoding in the form class (at, for example, the beginning of initialize() method), or...? Joe Germuska wrote: > >>I had problem with character encoding in my web application. I was trying to >>display Polish characters using UTF-8 but data from forms was not getting in >>proper format to the business layer. I managed to solve this by setting >>filter which does request.setCharacterEncoding(encoding); But the question >>is: WHY it didn't work when I was using request.setCharacterEncoding() in >>Action's execute() method?? > > The request's character encoding can only be set before the input > values are read. By the time the Action executes, the ActionForm has > already been populated, which means that the request has already > deserialized the request parameters from bytes on the wire into Java > Strings. Thus, a ServletFilter is the best way to make sure that > this value is set at the earliest possible time. > > Hope this helps, > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Character-encoding...-tf297678.html#a9630453 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts2, tiles2 and character encoding problem
Reported bug: https://issues.apache.org/struts/browse/TILES-104 Let's continue any further conversation on the [EMAIL PROTECTED] mailing list. Joe Germuska wrote: > > OK, a few more notes: > > just to be clear, > > I have specified struts.i18n.encoding=UTF-8. > > > This is not used to directly set the response character encoding. > > I use a CharacterEncodingFilter to set encoding to UTF-8. > > > In my experience, a CharacterEncodingFilter is used to control the request > content type, not the response content type. That's what the Spring class > called CharacterEncodingFilter does. Assuming yours is the same, it won't > come into play in debugging this problem. > > I specify on the page. >> > > I am not sure whether browsers allow this to override an explicit content > type set in the HTTP response, but in any case, it's more important that > the > HTTP response header be explicitly set. In a local test application I > have, > the servlet container is setting the header even when I don't explicitly > set > it. > > Using the latest code, I've tested going directly to a JSP (no struts), > going to a default result (RequestDispatcher.forward) and going to a Tiles > result. I get an explicit content type in all three cases, even though > the > JSP itself doesn't set the content type. I think there's something about > that in the Servlet spec, that the container is required to set a content > type, although that's at odds with what I experienced when I filed > TILES-28 > and with Elin's experience, so I'm not sure. > > This discussion REALLY belongs on [EMAIL PROTECTED] -- user lists are meant to > discuss using the app, not fixing bugs in prereleased code. Elin, if you > want to pursue this, please file a bug with as much as you can offer for > reproducibility (especially since I just tried and can't reproduce it) and > if you want to have further email, please join the [EMAIL PROTECTED] mailing > list. > See http://tiles.apache.org/mail-lists.html > > > On 2/7/07, elin <[EMAIL PROTECTED]> wrote: >> >> >> I double-checked that there is only one tiles-core jar. >> >> Monitoring shows: >> >> Conventional Struts result response's Content-Type header is >> text/html;charset=utf-8 >> >> If I request a jsp directly, the response's Content-Type header is >> text/html;charset=utf-8 >> >> Tiles Result response has no Content-Type header >> >> >> >> Elin >> -- >> View this message in context: >> http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842 >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> ----- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Joe Germuska > [EMAIL PROTECTED] * http://blog.germuska.com > > "The truth is that we learned from João forever to be out of tune." > -- Caetano Veloso > > -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8863903 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts2, tiles2 and character encoding problem
OK, a few more notes: just to be clear, I have specified struts.i18n.encoding=UTF-8. This is not used to directly set the response character encoding. I use a CharacterEncodingFilter to set encoding to UTF-8. In my experience, a CharacterEncodingFilter is used to control the request content type, not the response content type. That's what the Spring class called CharacterEncodingFilter does. Assuming yours is the same, it won't come into play in debugging this problem. I specify charset=UTF-8"/> on the page. I am not sure whether browsers allow this to override an explicit content type set in the HTTP response, but in any case, it's more important that the HTTP response header be explicitly set. In a local test application I have, the servlet container is setting the header even when I don't explicitly set it. Using the latest code, I've tested going directly to a JSP (no struts), going to a default result (RequestDispatcher.forward) and going to a Tiles result. I get an explicit content type in all three cases, even though the JSP itself doesn't set the content type. I think there's something about that in the Servlet spec, that the container is required to set a content type, although that's at odds with what I experienced when I filed TILES-28 and with Elin's experience, so I'm not sure. This discussion REALLY belongs on [EMAIL PROTECTED] -- user lists are meant to discuss using the app, not fixing bugs in prereleased code. Elin, if you want to pursue this, please file a bug with as much as you can offer for reproducibility (especially since I just tried and can't reproduce it) and if you want to have further email, please join the [EMAIL PROTECTED] mailing list. See http://tiles.apache.org/mail-lists.html On 2/7/07, elin <[EMAIL PROTECTED]> wrote: I double-checked that there is only one tiles-core jar. Monitoring shows: Conventional Struts result response's Content-Type header is text/html;charset=utf-8 If I request a jsp directly, the response's Content-Type header is text/html;charset=utf-8 Tiles Result response has no Content-Type header Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "The truth is that we learned from João forever to be out of tune." -- Caetano Veloso
Re: Struts2, tiles2 and character encoding problem
I double-checked that there is only one tiles-core jar. Monitoring shows: Conventional Struts result response's Content-Type header is text/html;charset=utf-8 If I request a jsp directly, the response's Content-Type header is text/html;charset=utf-8 Tiles Result response has no Content-Type header Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts2, tiles2 and character encoding problem
TILES-28 should be resolved in the SNAPSHOT version you indicate, while the subsequent change (to the Taglib URI) hadn't been changed. I just deployed a 2.0-SNAPSHOT rather than let it hang on as something less clear going forward. But back to your issue: it might seem that you've found a variation of the problem that was fixed in TILES-28 Make absolutely sure you don't have more than one version of the tiles-core JAR in your app, but assuming that you don't, we'll have to sniff around some more and figure out what might be different. You're doing the right kind of monitoring already -- what does Fiddler say if you get a conventional Struts result (ServletDispatcherResult) from your app? What about if you get a JSP directly from the app without going through Struts? Joe On 2/7/07, elin <[EMAIL PROTECTED]> wrote: Thank you for your reply. I upgraded from struts 2.0.4 to 2.0.5 but with the same result. I use maven to build the project which gives me the tiles version tiles-core-2.0-20070130.184344-3.jar. It seems to be the latest snapshot. Is this the version where the bug you mentioned is fixed? Or do you mean that it is fixed in the next build? Monitoring the response with fiddler shows that there is no content-type header. I use a tiles definition file and the insertAttribute tag to build the tiles result. Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8841954 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "The truth is that we learned from João forever to be out of tune." -- Caetano Veloso
Re: Struts2, tiles2 and character encoding problem
Thank you for your reply. I upgraded from struts 2.0.4 to 2.0.5 but with the same result. I use maven to build the project which gives me the tiles version tiles-core-2.0-20070130.184344-3.jar. It seems to be the latest snapshot. Is this the version where the bug you mentioned is fixed? Or do you mean that it is fixed in the next build? Monitoring the response with fiddler shows that there is no content-type header. I use a tiles definition file and the insertAttribute tag to build the tiles result. Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8841954 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts2, tiles2 and character encoding problem
Are you using the newest version of Tiles? There was a bug in which the content types were not being set in some cases; I was using a JSP page attribute to set the content type, not the other options, but it may be related. For everyone who is using Tiles 2, note that very soon now, the SNAPSHOT version of Tiles will be changing the URI for the TLD from http://struts.apache.org/tags-tiles to http://tiles.apache.org/tags-tiles so you will need to update the taglib declarations in your JSPs. (We use a JSP include directive like this <%@ include file="/WEB-INF/tiles/_boilerplate.jsp" %> so that we only have to change it in one place. If you don't do something like that, then I hope you have a good global search/replace option... I will probably build a new Maven SNAPSHOT in the next few days unless another developer does it first. (Note that if you're using Tiles 2, you probably ought to monitor the [EMAIL PROTECTED] list in case no one mentions things like this to the Struts user list. In general, Apache projects expect discussion of pre-release software to occur on dev lists, not user lists.) For reference, the bug to which I refer is https://issues.apache.org/struts/browse/TILES-28 Joe On 2/6/07, elin <[EMAIL PROTECTED]> wrote: Hi, I use struts2 and tiles2 in my web application. When my tiles result contains data with åäö and I write the data using el, the characters are not displayed correctly. If I write the data with a struts tag, for example the characters are displayed correctly. If I do not to use a tiles result, just a simple jsp, the characters are displayed correctly when I use el. I have specified struts.i18n.encoding=UTF-8. I use a CharacterEncodingFilter to set encoding to UTF-8. I specify on the page. Any ideas? /Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8828883 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "The truth is that we learned from João forever to be out of tune." -- Caetano Veloso
Struts2, tiles2 and character encoding problem
Hi, I use struts2 and tiles2 in my web application. When my tiles result contains data with åäö and I write the data using el, the characters are not displayed correctly. If I write the data with a struts tag, for example the characters are displayed correctly. If I do not to use a tiles result, just a simple jsp, the characters are displayed correctly when I use el. I have specified struts.i18n.encoding=UTF-8. I use a CharacterEncodingFilter to set encoding to UTF-8. I specify on the page. Any ideas? /Elin -- View this message in context: http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8828883 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart/form-data and character encoding
Good Morning Antonisis- If you are sending data which is of UTF-8 characterset then you need to configure the request e.g. request.setCharacterEncoding("UTF-8") e.g. http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#setCharacterEncoding(java.lang.String) If you are receiving data from a UTF-8 configured server then set the response as in response.setCharacterEncoding("UTF-8") e.g. http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#setCharacterEncoding(java.lang.String) Martin - * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: "Martin Gainty" <[EMAIL PROTECTED]> Cc: "Struts Users Mailing List" Sent: Monday, May 29, 2006 8:14 PM Subject: Re: multipart/form-data and character encoding > Martin, > > I' m not sure what you mean. In my Action's execute() method I get a > request, a response and an ActionForm object. Whatever I do to the > request or response objects, the values from the html form are already > in the actionForm (encoded in a false way). The only way to alter the > Strings in the actionForm is to change the method > > getMyString() { > return this.myString; > } > to > getMyString() { > return new String(this.myString.getBytes(), "UTF-8"); > }, > > which I already tried and miserably failed :) > > Antonis > > On 5/30/06, Martin Gainty <[EMAIL PROTECTED]> wrote: >> Antonis- >> >> Did you set the characterEncoding for the response e.g. >> res.setCharacterEncoding("UTF-8") >> ??? >> Martin -- >> >> This email message and any files transmitted with it contain confidential >> information intended only for the person(s) to whom this email message is >> addressed. If you have received this email message in error, please notify >> the sender immediately by telephone or email and destroy the original >> message without making a copy. Thank you. >> >> ----- Original Message - >> From: "Antonis Lebesis" <[EMAIL PROTECTED]> >> To: "Struts Users Mailing List" ; "Martin Gainty" >> <[EMAIL PROTECTED]> >> Sent: Monday, May 29, 2006 7:26 PM >> Subject: Re: multipart/form-data and character encoding >> >> >> > Hello Martin, >> > I tried your suggestion but there is a difference in my case: The >> > enctype in my form's declaration is "multipart/form-data" (I have to >> > support file upload). If I leave it that way, I get the same results >> > (no greek characters). If I change it to "multipart/form-data; >> > charset=iso-8859-7", I get a nice exception :( >> > >> > javax.servlet.ServletException: BeanUtils.populate >> > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) >> > org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) >> > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) >> > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) >> > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) >> > javax.servlet.http.HttpServlet.service(HttpServlet.java:709) >> > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >> > >> > root cause >> > >> > java.lang.IllegalArgumentException: argument type mismatch >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> > java.lang.reflect.Method.invoke(Method.java:585) >> > org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789) >> > org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684) >> > org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713) >> > org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) >> > org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) >> > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) >> > org.apa
Re: multipart/form-data and character encoding
Martin, I' m not sure what you mean. In my Action's execute() method I get a request, a response and an ActionForm object. Whatever I do to the request or response objects, the values from the html form are already in the actionForm (encoded in a false way). The only way to alter the Strings in the actionForm is to change the method getMyString() { return this.myString; } to getMyString() { return new String(this.myString.getBytes(), "UTF-8"); }, which I already tried and miserably failed :) Antonis On 5/30/06, Martin Gainty <[EMAIL PROTECTED]> wrote: Antonis- Did you set the characterEncoding for the response e.g. res.setCharacterEncoding("UTF-8") ??? Martin -- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" ; "Martin Gainty" <[EMAIL PROTECTED]> Sent: Monday, May 29, 2006 7:26 PM Subject: Re: multipart/form-data and character encoding > Hello Martin, > I tried your suggestion but there is a difference in my case: The > enctype in my form's declaration is "multipart/form-data" (I have to > support file upload). If I leave it that way, I get the same results > (no greek characters). If I change it to "multipart/form-data; > charset=iso-8859-7", I get a nice exception :( > > javax.servlet.ServletException: BeanUtils.populate > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) > org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) > javax.servlet.http.HttpServlet.service(HttpServlet.java:709) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > root cause > > java.lang.IllegalArgumentException: argument type mismatch > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > java.lang.reflect.Method.invoke(Method.java:585) > org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789) > org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684) > org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713) > org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) > org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) > org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) > javax.servlet.http.HttpServlet.service(HttpServlet.java:709) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > Any ideas? > > Thanks, > Antonis > > On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: >> Good Afternoon Antonis- >> >> This character encoding issue has been addressed >> http://issues.apache.org/struts/browse/STR-2117 as follows >> >> Set your page to use correct character encoding >> <%@ page ;contentType="text/html" charset=UTF-8"%> >> >> Set form to use correct form encoding >> >> >> Instruct web container to use selected charset when creating request (in >> server.xml) >> >> >> HTH, >> Martin -- >> - Original Message - >> From: "Antonis Lebesis" <[EMAIL PROTECTED]> >> To: >> Sent: Monday, May 29, 2006 2:07 PM >> Subject: multipart/form-data and character encoding >> >> >> Hi, >> I 've searched the archives but haven't found any solution to my >> latest problem. I have with a input and a >> input. The problem is that request.getCharacterEncoding() returns null >> and the text input is considered to be in iso-8859-1 encoding. In the >> corresponding ActionForm's reset(), I have added the following line: >> request.setCharacterEncoding("ISO
Re: multipart/form-data and character encoding
Antonis- Did you set the characterEncoding for the response e.g. res.setCharacterEncoding("UTF-8") ??? Martin -- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" ; "Martin Gainty" <[EMAIL PROTECTED]> Sent: Monday, May 29, 2006 7:26 PM Subject: Re: multipart/form-data and character encoding Hello Martin, I tried your suggestion but there is a difference in my case: The enctype in my form's declaration is "multipart/form-data" (I have to support file upload). If I leave it that way, I get the same results (no greek characters). If I change it to "multipart/form-data; charset=iso-8859-7", I get a nice exception :( javax.servlet.ServletException: BeanUtils.populate org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.IllegalArgumentException: argument type mismatch sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684) org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713) org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Any ideas? Thanks, Antonis On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: Good Afternoon Antonis- This character encoding issue has been addressed http://issues.apache.org/struts/browse/STR-2117 as follows Set your page to use correct character encoding <%@ page ;contentType="text/html" charset=UTF-8"%> Set form to use correct form encoding Instruct web container to use selected charset when creating request (in server.xml) HTH, Martin -- - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: Sent: Monday, May 29, 2006 2:07 PM Subject: multipart/form-data and character encoding Hi, I 've searched the archives but haven't found any solution to my latest problem. I have with a input and a input. The problem is that request.getCharacterEncoding() returns null and the text input is considered to be in iso-8859-1 encoding. In the corresponding ActionForm's reset(), I have added the following line: request.setCharacterEncoding("ISO-8859-7"); In forms that don't have a input, the character set is correct. The problem occurs only in this form and from what I 've found it is caused by the fact that in the form declaration I have added enctype="multipart/form-data". Has anyone solved this problem? Thanks, Antonis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart/form-data and character encoding
Antonis, I`m glad to know that your problem is solved. If you find a more official solution, please let me know. But, as you, I spent many hours looking for it, and I didn`t find anything at all. []s miguel On 5/29/06, Antonis Lebesis <[EMAIL PROTECTED]> wrote: Miguel, If you ever come to Greece, remind me to offer you some ouzo and mousaka ;) It worked just fine! I' ll keep looking for a more "official" solution, but until then you' ve saved me... Thank you very very much, Antonis On 5/29/06, Miguel Galves <[EMAIL PROTECTED]> wrote: > Antonis, > > we had the same problem with multi part forms. We tried everithing, > including enctype in the > form tag, URIEncoding, and request.setEncoding...in reset() method. All > theses solutions worked > fine with all kinds of requests, except for the mulipart, which is handled > in a different way. > > The only solution that really worked for us was to create a subclass of > TilesRequestProcessor, > and override the handleRequest method as follows: > > public class ScyllaRequestProcessor extends TilesRequestProcessor { > > public void process(HttpServletRequest request, HttpServletResponse > response) throws IOException, > > ServletException { > try { > request.setCharacterEncoding("UTF-8"); > } catch (UnsupportedEncodingException e) { > e.printStackTrace(); > } > > super.process(request, response); > } > > To use this processor, just change the controller entry in struts-config.xml > > []s > > Miguel > > > On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: > > > > Good Afternoon Antonis- > > > > This character encoding issue has been addressed > > http://issues.apache.org/struts/browse/STR-2117 as follows > > > > Set your page to use correct character encoding > > <%@ page ;contentType="text/html" charset=UTF-8"%> > > > > Set form to use correct form encoding > > > > > > Instruct web container to use selected charset when creating request (in > > server.xml) > > > > > > HTH, > > Martin -- > > - Original Message - > > From: "Antonis Lebesis" <[EMAIL PROTECTED]> > > To: > > Sent: Monday, May 29, 2006 2:07 PM > > Subject: multipart/form-data and character encoding > > > > > > Hi, > > I 've searched the archives but haven't found any solution to my > > latest problem. I have with a input and a > > input. The problem is that request.getCharacterEncoding() returns null > > and the text input is considered to be in iso-8859-1 encoding. In the > > corresponding ActionForm's reset(), I have added the following line: > > request.setCharacterEncoding("ISO-8859-7"); > > > > In forms that don't have a input, the character set is > > correct. The problem occurs only in this form and from what I 've > > found it is caused by the fact that in the form declaration I have > > added enctype="multipart/form-data". > > > > Has anyone solved this problem? > > > > Thanks, > > Antonis > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Miguel Galves - Engenheiro de Computação > Já leu meus blogs hoje? > Para geeks http://log4dev.blogspot.com > Pra pessoas normais > http://miguelgalves.blogspot.com > > "Não sabendo que era impossível, ele foi lá e fez..." > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Miguel Galves - Engenheiro de Computação Já leu meus blogs hoje? Para geeks http://log4dev.blogspot.com Pra pessoas normais http://miguelgalves.blogspot.com "Não sabendo que era impossível, ele foi lá e fez..."
Re: multipart/form-data and character encoding
Miguel, If you ever come to Greece, remind me to offer you some ouzo and mousaka ;) It worked just fine! I' ll keep looking for a more "official" solution, but until then you' ve saved me... Thank you very very much, Antonis On 5/29/06, Miguel Galves <[EMAIL PROTECTED]> wrote: Antonis, we had the same problem with multi part forms. We tried everithing, including enctype in the form tag, URIEncoding, and request.setEncoding...in reset() method. All theses solutions worked fine with all kinds of requests, except for the mulipart, which is handled in a different way. The only solution that really worked for us was to create a subclass of TilesRequestProcessor, and override the handleRequest method as follows: public class ScyllaRequestProcessor extends TilesRequestProcessor { public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { try { request.setCharacterEncoding("UTF-8"); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } super.process(request, response); } To use this processor, just change the controller entry in struts-config.xml []s Miguel On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: > > Good Afternoon Antonis- > > This character encoding issue has been addressed > http://issues.apache.org/struts/browse/STR-2117 as follows > > Set your page to use correct character encoding > <%@ page ;contentType="text/html" charset=UTF-8"%> > > Set form to use correct form encoding > > > Instruct web container to use selected charset when creating request (in > server.xml) > > > HTH, > Martin -- > - Original Message - > From: "Antonis Lebesis" <[EMAIL PROTECTED]> > To: > Sent: Monday, May 29, 2006 2:07 PM > Subject: multipart/form-data and character encoding > > > Hi, > I 've searched the archives but haven't found any solution to my > latest problem. I have with a input and a > input. The problem is that request.getCharacterEncoding() returns null > and the text input is considered to be in iso-8859-1 encoding. In the > corresponding ActionForm's reset(), I have added the following line: > request.setCharacterEncoding("ISO-8859-7"); > > In forms that don't have a input, the character set is > correct. The problem occurs only in this form and from what I 've > found it is caused by the fact that in the form declaration I have > added enctype="multipart/form-data". > > Has anyone solved this problem? > > Thanks, > Antonis > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Miguel Galves - Engenheiro de Computação Já leu meus blogs hoje? Para geeks http://log4dev.blogspot.com Pra pessoas normais http://miguelgalves.blogspot.com "Não sabendo que era impossível, ele foi lá e fez..." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart/form-data and character encoding
Hello Martin, I tried your suggestion but there is a difference in my case: The enctype in my form's declaration is "multipart/form-data" (I have to support file upload). If I leave it that way, I get the same results (no greek characters). If I change it to "multipart/form-data; charset=iso-8859-7", I get a nice exception :( javax.servlet.ServletException: BeanUtils.populate org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.IllegalArgumentException: argument type mismatch sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684) org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713) org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Any ideas? Thanks, Antonis On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: Good Afternoon Antonis- This character encoding issue has been addressed http://issues.apache.org/struts/browse/STR-2117 as follows Set your page to use correct character encoding <%@ page ;contentType="text/html" charset=UTF-8"%> Set form to use correct form encoding Instruct web container to use selected charset when creating request (in server.xml) HTH, Martin -- - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: Sent: Monday, May 29, 2006 2:07 PM Subject: multipart/form-data and character encoding Hi, I 've searched the archives but haven't found any solution to my latest problem. I have with a input and a input. The problem is that request.getCharacterEncoding() returns null and the text input is considered to be in iso-8859-1 encoding. In the corresponding ActionForm's reset(), I have added the following line: request.setCharacterEncoding("ISO-8859-7"); In forms that don't have a input, the character set is correct. The problem occurs only in this form and from what I 've found it is caused by the fact that in the form declaration I have added enctype="multipart/form-data". Has anyone solved this problem? Thanks, Antonis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multipart/form-data and character encoding
Antonis, we had the same problem with multi part forms. We tried everithing, including enctype in the form tag, URIEncoding, and request.setEncoding...in reset() method. All theses solutions worked fine with all kinds of requests, except for the mulipart, which is handled in a different way. The only solution that really worked for us was to create a subclass of TilesRequestProcessor, and override the handleRequest method as follows: public class ScyllaRequestProcessor extends TilesRequestProcessor { public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { try { request.setCharacterEncoding("UTF-8"); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } super.process(request, response); } To use this processor, just change the controller entry in struts-config.xml []s Miguel On 5/29/06, Martin Gainty <[EMAIL PROTECTED]> wrote: Good Afternoon Antonis- This character encoding issue has been addressed http://issues.apache.org/struts/browse/STR-2117 as follows Set your page to use correct character encoding <%@ page ;contentType="text/html" charset=UTF-8"%> Set form to use correct form encoding Instruct web container to use selected charset when creating request (in server.xml) HTH, Martin -- - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: Sent: Monday, May 29, 2006 2:07 PM Subject: multipart/form-data and character encoding Hi, I 've searched the archives but haven't found any solution to my latest problem. I have with a input and a input. The problem is that request.getCharacterEncoding() returns null and the text input is considered to be in iso-8859-1 encoding. In the corresponding ActionForm's reset(), I have added the following line: request.setCharacterEncoding("ISO-8859-7"); In forms that don't have a input, the character set is correct. The problem occurs only in this form and from what I 've found it is caused by the fact that in the form declaration I have added enctype="multipart/form-data". Has anyone solved this problem? Thanks, Antonis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Miguel Galves - Engenheiro de Computação Já leu meus blogs hoje? Para geeks http://log4dev.blogspot.com Pra pessoas normais http://miguelgalves.blogspot.com "Não sabendo que era impossível, ele foi lá e fez..."
Re: multipart/form-data and character encoding
Good Afternoon Antonis- This character encoding issue has been addressed http://issues.apache.org/struts/browse/STR-2117 as follows Set your page to use correct character encoding <%@ page ;contentType="text/html" charset=UTF-8"%> Set form to use correct form encoding Instruct web container to use selected charset when creating request (in server.xml) HTH, Martin -- - Original Message - From: "Antonis Lebesis" <[EMAIL PROTECTED]> To: Sent: Monday, May 29, 2006 2:07 PM Subject: multipart/form-data and character encoding Hi, I 've searched the archives but haven't found any solution to my latest problem. I have with a input and a input. The problem is that request.getCharacterEncoding() returns null and the text input is considered to be in iso-8859-1 encoding. In the corresponding ActionForm's reset(), I have added the following line: request.setCharacterEncoding("ISO-8859-7"); In forms that don't have a input, the character set is correct. The problem occurs only in this form and from what I 've found it is caused by the fact that in the form declaration I have added enctype="multipart/form-data". Has anyone solved this problem? Thanks, Antonis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multipart/form-data and character encoding
Hi, I 've searched the archives but haven't found any solution to my latest problem. I have with a input and a input. The problem is that request.getCharacterEncoding() returns null and the text input is considered to be in iso-8859-1 encoding. In the corresponding ActionForm's reset(), I have added the following line: request.setCharacterEncoding("ISO-8859-7"); In forms that don't have a input, the character set is correct. The problem occurs only in this form and from what I 've found it is caused by the fact that in the form declaration I have added enctype="multipart/form-data". Has anyone solved this problem? Thanks, Antonis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with character encoding.
Hi Dan, Both are on Windows. With best regards, Anjishnu. -Original Message- From: Dan Jas [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 9:45 PM To: Struts Users Mailing List Subject: Re: Problem with character encoding. Are you using WSAD on Windows and Tomcat on Unix/Linux? - Original Message - From: "Anjishnu Bandyopadhyay" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Tuesday, March 21, 2006 5:51 AM Subject: Problem with character encoding. Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as "application/msword;". The ".doc" that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment & final testing. In WSAD, the ".doc" file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: <%@ page language="java" contentType="application/msword; charset=UTF-8" pageEncoding="UTF-8" %> <% String fileName = "abc.doc"; response.setContentType("application/msword"); response.setLocale(java.util.Locale.FRENCH); response.setHeader("Content-Disposition","attachment;filename="+ fileName); %> Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with character encoding.
Anjishnu Bandyopadhyay wrote: > I am generating a MS Word document through a JSP, by setting the JSP's > content type as "application/msword;". > I really don't understand why you persist in thinking that _calling_ something a Word document _makes_ it a Word document. As I have stated several times a Word document is a _binary_file_format_. What are you using to generate the Word document? If you're just outputting an HTML template (e.g. a standard JSP template) you are NOT generating a Word document. If you are using a particular library to properly generate a Word document you'll probably want to ask on a list for that library. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with character encoding.
Are you using WSAD on Windows and Tomcat on Unix/Linux? - Original Message - From: "Anjishnu Bandyopadhyay" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Tuesday, March 21, 2006 5:51 AM Subject: Problem with character encoding. Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as "application/msword;". The ".doc" that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment & final testing. In WSAD, the ".doc" file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: <%@ page language="java" contentType="application/msword; charset=UTF-8" pageEncoding="UTF-8" %> <% String fileName = "abc.doc"; response.setContentType("application/msword"); response.setLocale(java.util.Locale.FRENCH); response.setHeader("Content-Disposition","attachment;filename="+ fileName); %> Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with character encoding.
Anjishnu Bandyopadhyay ha scritto: Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as "application/msword;". Are you using a particular library to generate the file? Anyway generating an MS Word file through JSP seems odd to me... The ".doc" that is generated contains accentuated French characters (special French characters). ... In WSAD, the ".doc" file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). Maybe I am missing something. Does WSAD have something native that handles MS Word files? Because Tomcat doesn't! Anyway, the character set (UTF-8) has nothing to do with the final generated file (for the browser it should be a binary file, that must be handled by a plugin or an external application). Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with character encoding.
Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as "application/msword;". The ".doc" that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment & final testing. In WSAD, the ".doc" file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: <%@ page language="java" contentType="application/msword; charset=UTF-8" pageEncoding="UTF-8" %> <% String fileName = "abc.doc"; response.setContentType("application/msword"); response.setLocale(java.util.Locale.FRENCH); response.setHeader("Content-Disposition","attachment;filename="+ fileName); %> Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: So boring issues about character encoding in action ......
At 1:44 PM +0800 10/18/05, Tony Lu wrote: I need to create an internationalized Web application by struts,mysql and hibernate. Each component Character Encoding is utf8. It runs well when I run a pure servlet to save 'Chinese Character' to database and load it from database. But when I implement it with struts action, the application can not save Chinese correctly. I really don't know why struts action can not work well. I am sure there is no difference between them. By the time that your action class is executing, Struts has already read from the request input stream (to populate the ActionForm). In any web application, if you want to set the request character encoding, you must arrange to do it before any code will read from the request input stream. The best way to do this in a Servlet 2.3 or later web environment is to use a ServletFilter. In fact, most of the worked examples of writing ServletFilters on the web are to solve this problem. You could also do it by extending RequestProcessor (or TilesRequestProcessor, if you use Tiles) and overriding the processPreprocess method. However, in Struts 1.3 the processPreprocess method is no longer used. Using a ServletFilter will apply to any application you write in any Struts version, or with a non-Struts approach. Joe Is there anywhere to set character encoding for action? Please help! --Pure Servlet ( It runs well) - public class UtfTest extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String description = request.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); }catch(Exception e){ e.printStackTrace(); } response.sendRedirect("test.jsp"); } } --Action for struts public class TestAction extends Action{ public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res) throws Exception { req.setCharacterEncoding("UTF-8"); String description = req.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); // Determine which action forward should be returned return mapping.findForward("success"); }catch(Exception e){ } } } -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: So boring issues about character encoding in action ......
I don't think so. I have set '' in struts-config.xml So the action don't need to specially add statement ' res.setCharacterEncoding("UTF-8")'. I also have tested it like this. But it seems it's no use. On 10/18/05, Deepesh Nandal <[EMAIL PROTECTED]> wrote: > > Hi, > In the struts action you are setting character encoding on 'request' > object req ,it however needs to be on 'response' ie res. > > Deepesh. > > > public class TestAction extends Action{ > public ActionForward execute(ActionMapping mapping, > ActionForm form, > HttpServletRequest req, > HttpServletResponse res) throws Exception { > > req.setCharacterEncoding("UTF-8"); // this should be > res.setCharacterEncoding("UTF-8"); > > String description = req.getParameter("description"); > description = (description == null?"":description.trim()); > try{ > ItemDAO itemDao = ItemDAO.getInstance(); > Item item = new Item(); > > > > - Original Message - > From: "Tony Lu" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, October 18, 2005 11:14 AM > Subject: So boring issues about character encoding in action .. > > > I need to create an internationalized Web application by struts,mysql and > hibernate. > Each component Character Encoding is utf8. > It runs well when I run a pure servlet to save 'Chinese Character' to > database and load it from database. > But when I implement it with struts action, the application can not save > Chinese correctly. > I really don't know why struts action can not work well. I am sure there > is > no difference between them. > Is there anywhere to set character encoding for action? Please help! > --Pure Servlet ( It runs well) > - > public class UtfTest extends HttpServlet { > protected void doPost(HttpServletRequest request, HttpServletResponse > response) > throws ServletException, IOException { > > request.setCharacterEncoding("UTF-8"); > String description = request.getParameter("description"); > description = (description == null?"":description.trim()); > > try{ > ItemDAO itemDao = ItemDAO.getInstance(); > Item item = new Item(); > item.setDescription(description); > itemDao.save(item); > }catch(Exception e){ > e.printStackTrace(); > } > response.sendRedirect("test.jsp"); > } > } > > --Action for struts > > > public class TestAction extends Action{ > public ActionForward execute(ActionMapping mapping, > ActionForm form, > HttpServletRequest req, > HttpServletResponse res) throws Exception { > > req.setCharacterEncoding("UTF-8"); > String description = req.getParameter("description"); > description = (description == null?"":description.trim()); > try{ > ItemDAO itemDao = ItemDAO.getInstance(); > Item item = new Item(); > > item.setDescription(description); > itemDao.save(item); > // Determine which action forward should be returned > return mapping.findForward("success"); > }catch(Exception e){ > } > } > } > > > > > > > > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: So boring issues about character encoding in action ......
Hi, In the struts action you are setting character encoding on 'request' object req ,it however needs to be on 'response' ie res. Deepesh. public class TestAction extends Action{ public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res) throws Exception { req.setCharacterEncoding("UTF-8"); // this should be res.setCharacterEncoding("UTF-8"); String description = req.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); - Original Message - From: "Tony Lu" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 18, 2005 11:14 AM Subject: So boring issues about character encoding in action .. I need to create an internationalized Web application by struts,mysql and hibernate. Each component Character Encoding is utf8. It runs well when I run a pure servlet to save 'Chinese Character' to database and load it from database. But when I implement it with struts action, the application can not save Chinese correctly. I really don't know why struts action can not work well. I am sure there is no difference between them. Is there anywhere to set character encoding for action? Please help! --Pure Servlet ( It runs well) - public class UtfTest extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String description = request.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); }catch(Exception e){ e.printStackTrace(); } response.sendRedirect("test.jsp"); } } --Action for struts public class TestAction extends Action{ public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res) throws Exception { req.setCharacterEncoding("UTF-8"); String description = req.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); // Determine which action forward should be returned return mapping.findForward("success"); }catch(Exception e){ } } } No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
So boring issues about character encoding in action ......
I need to create an internationalized Web application by struts,mysql and hibernate. Each component Character Encoding is utf8. It runs well when I run a pure servlet to save 'Chinese Character' to database and load it from database. But when I implement it with struts action, the application can not save Chinese correctly. I really don't know why struts action can not work well. I am sure there is no difference between them. Is there anywhere to set character encoding for action? Please help! --Pure Servlet ( It runs well) - public class UtfTest extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String description = request.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); }catch(Exception e){ e.printStackTrace(); } response.sendRedirect("test.jsp"); } } --Action for struts public class TestAction extends Action{ public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest req, HttpServletResponse res) throws Exception { req.setCharacterEncoding("UTF-8"); String description = req.getParameter("description"); description = (description == null?"":description.trim()); try{ ItemDAO itemDao = ItemDAO.getInstance(); Item item = new Item(); item.setDescription(description); itemDao.save(item); // Determine which action forward should be returned return mapping.findForward("success"); }catch(Exception e){ } } }
Re: Character encoding...
I had problem with character encoding in my web application. I was trying to display Polish characters using UTF-8 but data from forms was not getting in proper format to the business layer. I managed to solve this by setting filter which does request.setCharacterEncoding(encoding); But the question is: WHY it didn't work when I was using request.setCharacterEncoding() in Action's execute() method?? The request's character encoding can only be set before the input values are read. By the time the Action executes, the ActionForm has already been populated, which means that the request has already deserialized the request parameters from bytes on the wire into Java Strings. Thus, a ServletFilter is the best way to make sure that this value is set at the earliest possible time. Hope this helps, Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Character encoding...
Hi, I had problem with character encoding in my web application. I was trying to display Polish characters using UTF-8 but data from forms was not getting in proper format to the business layer. I managed to solve this by setting filter which does request.setCharacterEncoding(encoding); But the question is: WHY it didn't work when I was using request.setCharacterEncoding() in Action's execute() method?? Wojtek
Re: How to set character encoding of the incoming request in Struts 1.2.4
I use a servlet filter to set the encoding before it reaches struts souravm wrote: Hi All, I want to set the chracter encoding of incoming http request by using HttpServletRequest.setCharacterEncoding() api. How do I do it using Struts 1.2.4 ? Does it provide any configuration parameter to do the same ? Or one has to subclass the RequestProcessor class to do the same ? Or is there any other way ? Regards, Sourav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jason Lea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to set character encoding of the incoming request in Struts 1.2.4
Hi All, I want to set the chracter encoding of incoming http request by using HttpServletRequest.setCharacterEncoding() api. How do I do it using Struts 1.2.4 ? Does it provide any configuration parameter to do the same ? Or one has to subclass the RequestProcessor class to do the same ? Or is there any other way ? Regards, Sourav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
J.Patterson Waltz III writes: > Yep. That was it. > I commented out the filter definition for ResponseOverrideFilter and > everything displayed as expected. > I then reinstated it, placing it *after* the > SetCharacterEncodingFilter in web.xml, and all was still well. Great! > Really, really annoying to bang one's head on such arcana, but > oh-so-satisfying when you finally get to the bottom of it. On to the > next obscure issue... There is one big technical advantage using tomcat over a proprietary servlet container: if this mystery was still happening after everything you tried, you could dive into tomcat's code, instrument/debug it and understand what was going on. Hopefully, the internet and mailing-lists era makes this not mandatory most of the time (still I had to go into tomcat code to understand that I needed useBodyEncodingForURI when upgrading from tomcat4 to tomcat5 and using UTF8 encoded GET parameters). -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
On 6 janv. 05, at 18:13, Guillaume Cottenceau wrote: I also have another filter, the ResponseOverrideFilter used by displaytag, which appears before the SetCharacterEncodingFilter in my web.xml. I wonder if it could be interfering with the SetCharacterEncodingFilter? Yes, if it reads the request parameters or request stream (by servlets specs). The SetCharacterEncodingFilter should be put first. I think this might be your problem. Yep. That was it. I commented out the filter definition for ResponseOverrideFilter and everything displayed as expected. I then reinstated it, placing it *after* the SetCharacterEncodingFilter in web.xml, and all was still well. Really, really annoying to bang one's head on such arcana, but oh-so-satisfying when you finally get to the bottom of it. On to the next obscure issue... Thanks for your help, Guillaume - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
J.Patterson Waltz III writes: > On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote: > > > J.Patterson Waltz III writes: > > > >> Notice in the third line of the form data: > >> &personTO.comments=%C3%A9t%C3%A9 > >> That's 'été' URLencoded as UTF-8. > >> > >> So I'm still stumped. :-( > > > > But that's exactly what you want. The SetCharacterEncodingFilter > > will set the character encoding of the HttpServletRequest before > > data is retrieved from it, and when it's retrieved it should be > > correctly decoded. Are you sure the filter is up and running? > > > > I agree that that encoding is what I want. It's just that it's not > getting decoded upon display. Or rather, it's getting URL-decoded, but > not UTF-8 decoded. Display is different from decoding. Double check the decoding first with log4j or anything. But beware that the JVM default charset and console charset may interfer so you might make use of my char decoder: byte[] b = querystring.getBytes( "UTF-8" ); String bytes = ""; for ( int i = 0; i < b.length; i++ ) { int val = b[i]; if ( val < 0 ) { val += 256; } bytes += Integer.toHexString( val ) + " "; } > I'm sure the filter is up and running because I added logging > statements to the Apache example code. So in my log, I see: > > 2005-01-06 17:30:34,706 DEBUG > [com.cerenit.sage.util.web.SetCharacterEncodingFilter] ignore = true, > encoding = utf-8, request encoding is null > 2005-01-06 17:30:34,706 DEBUG > [com.cerenit.sage.util.web.SetCharacterEncodingFilter] setting > encoding to utf-8 Yep. > I have the filter set to match the url-patterns *.do and *.jsp. > > I'm wondering if the fact that the form fields are all defined in > subtiles could make any difference: I'd guess not, since it's the > outermost tile which defines the page encoding. Your previous email seems to show that browser->tomcat is ok since you're really receiving URL encoded UTF8 strings, which is what you want. There is something with url decoding and/or decoding of byte content. > I also have another filter, the ResponseOverrideFilter used by > displaytag, which appears before the SetCharacterEncodingFilter in my > web.xml. I wonder if it could be interfering with the > SetCharacterEncodingFilter? Yes, if it reads the request parameters or request stream (by servlets specs). The SetCharacterEncodingFilter should be put first. I think this might be your problem. -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote: J.Patterson Waltz III writes: Notice in the third line of the form data: &personTO.comments=%C3%A9t%C3%A9 That's 'été' URLencoded as UTF-8. So I'm still stumped. :-( But that's exactly what you want. The SetCharacterEncodingFilter will set the character encoding of the HttpServletRequest before data is retrieved from it, and when it's retrieved it should be correctly decoded. Are you sure the filter is up and running? I agree that that encoding is what I want. It's just that it's not getting decoded upon display. Or rather, it's getting URL-decoded, but not UTF-8 decoded. I'm sure the filter is up and running because I added logging statements to the Apache example code. So in my log, I see: 2005-01-06 17:30:34,706 DEBUG [com.cerenit.sage.util.web.SetCharacterEncodingFilter] ignore = true, encoding = utf-8, request encoding is null 2005-01-06 17:30:34,706 DEBUG [com.cerenit.sage.util.web.SetCharacterEncodingFilter] setting encoding to utf-8 I have the filter set to match the url-patterns *.do and *.jsp. I'm wondering if the fact that the form fields are all defined in subtiles could make any difference: I'd guess not, since it's the outermost tile which defines the page encoding. I also have another filter, the ResponseOverrideFilter used by displaytag, which appears before the SetCharacterEncodingFilter in my web.xml. I wonder if it could be interfering with the SetCharacterEncodingFilter? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
J.Patterson Waltz III writes: > Notice in the third line of the form data: > &personTO.comments=%C3%A9t%C3%A9 > That's 'été' URLencoded as UTF-8. > > So I'm still stumped. :-( But that's exactly what you want. The SetCharacterEncodingFilter will set the character encoding of the HttpServletRequest before data is retrieved from it, and when it's retrieved it should be correctly decoded. Are you sure the filter is up and running? -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
On 6 janv. 05, at 17:17, Guillaume Cottenceau wrote: J.Patterson Waltz III writes: On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote: Now, I guess I'll just have to try using the character encoding filter Guillaume recommended. Ack! I'm about to pull my hair out over these encoding issues. I added the SetCharacterEncodingFilter from the Tomcat 5 distribution to my web application, with just enough mods to get some logging output from it so I'd know it was doing its thing. So now I have the following in place to ensure incoming and outgoing UTF-8 encoding: - A <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" language="java" %> directive - an acceptCharset="UTF-8" attribute on tags - an enctype="application/x-www-form-urlencoded;charset=UTF-8" attribute on tags - the SetCharacterEncodingFilter, configured to interpret UTF-8 no matter what and yet I'm *still* getting non-decoded UTF-8 displayed in my pages (i.e. été is été). Guillaume, did you actually get UTF-8 to work using the filter solution? If so, can you (or anyone) think of anything else I might have missed? Thanks in advance. Yes, it works. First, verify `tomcat->browser': please try to render your page with "wget -S" to see precisely the headers (Content-Type must specify UTF-8) and the contents (double-check the output is UTF-8) (to verify your browser is not bugged). Here's the tomcat->browser headers of the page which contains the form: HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Language: en X-Transfer-Encoding: chunked Date: Thu, 06 Jan 2005 16:30:08 GMT Server: Apache-Coyote/1.1 Content-length: 16401 Second, verify `browser->tomcat': use a proxy (or netcat in listen mode) to precisely see what headers your browser is sending (if you will use the filter to force UTF-8, that doesn't matter much) and the encoding of the data. Typically, browsers will encode in UTF-8 if the page containing the form was using UTF-8 itself, but accept-charset can do no harm, but as you noticed they don't set the charset in the Content-Type header they use (according to mozilla's bugzilla, it's because it breaks too many servers); but you have to double-check that (in my experience, mozilla and MSIE do work). And here's the POST response from Firefox, including the form data (sensitive data manually replaced with x's): POST http://127.0.0.1:8080/SAGE/correspondent.do HTTP/1.1 Host: 127.0.0.1:8008 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: fr-fr,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://127.0.0.1:8008/SAGE/correspondent.do?retrieve=&per=1 Cookie: lang=en; JSESSIONID=035AC799FB05BE35FE9B9E96D0664930 Content-Type: application/x-www-form-urlencoded Content-Length: 841 personTO.type=correspondent&personTO.subtype=&correspondentTO.correspond entID=174&personTO.personID=1&personTO.salutation=mr&personTO.lastName=W altz&personTO.firstName=J.+Patterson&personTO.status=active&personTO.com ments=%C3%A9t%C3%A9&personTO.address=&personTO.city=&personTO.postalCode =&personTO.region=&personTO.country=&personTO.telephone1Label=&personTO. telephone1=&personTO.telephone2Label=&personTO.telephone2=&personTO.fax= &personTO.email=x%40xxx.com&personTO.secondaryEmail=&personT O.contactLanguage=en&personTO.orgSummaryTO.organizationID=161&personTO.e mployeeID=&personTO.position=&personTO.department=&personTO.managerName= &personTO.accountTO.login=x%40xxx.com&personTO.accountTO.pas sword=&personTO.accountTO.loginEnabled=on&personTO.accountTO.con nectionAttempts=0&ID=174&ID=1&update=Save+Changes Notice in the third line of the form data: &personTO.comments=%C3%A9t%C3%A9 That's 'été' URLencoded as UTF-8. So I'm still stumped. :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
J.Patterson Waltz III writes: > On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote: > > > > > > Now, I guess I'll just have to try using the character encoding > > filter Guillaume recommended. > > Ack! I'm about to pull my hair out over these encoding issues. I added > the SetCharacterEncodingFilter from the Tomcat 5 distribution to my > web application, with just enough mods to get some logging output from > it so I'd know it was doing its thing. > > So now I have the following in place to ensure incoming and outgoing > UTF-8 encoding: > - A <%@ page pageEncoding="UTF-8" > contentType="text/html;charset=UTF-8" language="java" %> directive > - an acceptCharset="UTF-8" attribute on tags > - an enctype="application/x-www-form-urlencoded;charset=UTF-8" > attribute on tags > - the SetCharacterEncodingFilter, configured to interpret UTF-8 no > matter what > > and yet I'm *still* getting non-decoded UTF-8 displayed in my pages > (i.e. été is été). > > Guillaume, did you actually get UTF-8 to work using the filter > solution? If so, can you (or anyone) think of anything else I might > have missed? Thanks in advance. Yes, it works. First, verify `tomcat->browser': please try to render your page with "wget -S" to see precisely the headers (Content-Type must specify UTF-8) and the contents (double-check the output is UTF-8) (to verify your browser is not bugged). Second, verify `browser->tomcat': use a proxy (or netcat in listen mode) to precisely see what headers your browser is sending (if you will use the filter to force UTF-8, that doesn't matter much) and the encoding of the data. Typically, browsers will encode in UTF-8 if the page containing the form was using UTF-8 itself, but accept-charset can do no harm, but as you noticed they don't set the charset in the Content-Type header they use (according to mozilla's bugzilla, it's because it breaks too many servers); but you have to double-check that (in my experience, mozilla and MSIE do work). -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote: Now, I guess I'll just have to try using the character encoding filter Guillaume recommended. Ack! I'm about to pull my hair out over these encoding issues. I added the SetCharacterEncodingFilter from the Tomcat 5 distribution to my web application, with just enough mods to get some logging output from it so I'd know it was doing its thing. So now I have the following in place to ensure incoming and outgoing UTF-8 encoding: - A <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" language="java" %> directive - an acceptCharset="UTF-8" attribute on tags - an enctype="application/x-www-form-urlencoded;charset=UTF-8" attribute on tags - the SetCharacterEncodingFilter, configured to interpret UTF-8 no matter what and yet I'm *still* getting non-decoded UTF-8 displayed in my pages (i.e. été is été). Guillaume, did you actually get UTF-8 to work using the filter solution? If so, can you (or anyone) think of anything else I might have missed? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
On 5 janv. 05, at 13:30, J. Patterson Waltz III wrote: in article [EMAIL PROTECTED], Josh Cronemeyer at [EMAIL PROTECTED] wrote on 4/01/05 18:02: J. Patterson Waltz III wrote: Merci Guillaume, I had actually seen the references to the Filter solution in the comments of Struts bug 16191 in Bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=16191 I will try that out and see if it improves my results. I remain perplexed at what changes between versions 1.1 and 1.2.4 of Struts caused it to become susceptible to this problem. Any ideas on that? Patterson P.S. - I know how to view the headers of replies sent from the server to the browser, but am not sure how to get at those sent from the browser to the server, to make sure that they are indeed UTF-8. Any suggestions? in article [EMAIL PROTECTED], Guillaume Cottenceau at [EMAIL PROTECTED] wrote on 4/01/05 16:40: Most probably the browser is sending data in UTF-8 but doesn't say so with charset= in the Content-Type header. If you're confident enough that the browsers will send UTF-8 (which should be the case if they are encoded in UTF-8 and you use accept-charset in the forms), you can use a filter which forces the HTTP request to be seen as UTF-8 in input (for example filters/SetCharacterEncodingFilter which is bundled with tomcat)[1]. One way woulb be to set up a proxy that your browser uses to connect to the web. I used to use web scarab. http://www.owasp.org/software/webscarab.html -josh I still haven't figured out the solution to my problem, but I have figured out one *cause* of it. After using web scarab at Josh's suggestion to eavesdrop on the conversations between my browser and app server, I've figured out what has changed between Struts 1.1 and 1.2.4: Struts 1.1 in spite of the the <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" language="java" %> directive, Struts was in fact sending back pages encoded in ISO-8859-1, and the resulting form submissions were URL-encoded (and decoded) in the same format. Struts 1.2.4 the directive is now being followed, and pages are sent out in UTF-8 encoding. However, for some reason, the form data is not being decoded as UTF-8, but still as ISO-8859-1. This suggests to me that if I were to remove the contentType directive in Struts 1.2.4, it would fall back to the default ISO-8859-1 encoding, and all would work as before: except that my web application would then be constrained to using only characters representable in that encoding. More results of my testing: I was indeed able to restore the proper encoding of characters submitted to my web application by removing both the @ page contentType directive *and* the corresponding element from the struts-confix.xml file. However, as predicted, this only enabled proper encoding of characters within the ISO-8859-1 range: double-byte languages such as Japanese were munged into a series of question marks. I also determined that neither adding acceptCharset="UTF-8" nor enctype="application/x-www-form-urlencoded;charset=UTF-8" attributes to the tags in my JSPs seemed to make any difference with the encoding problems. The resulting Content-Type header returned by the browser never includes the character set information. This is not particularly surprising, as the html 4.0 spec (see http://www.w3.org/TR/REC-html40/interact/forms.html#submit-format) specifies: the "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set. Adding enctype="multipart/form-data;charset=UTF-8" worked even less well however, as Struts did not appear able to interpret form data submitted in this format: it displayed validation errors saying that required form fields were missing (although they had been submitted with complete information and were visible in the response returned by the browser). Now, I guess I'll just have to try using the character encoding filter Guillaume recommended. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
in article [EMAIL PROTECTED], Josh Cronemeyer at [EMAIL PROTECTED] wrote on 4/01/05 18:02: > J. Patterson Waltz III wrote: > >> Merci Guillaume, >> >> I had actually seen the references to the Filter solution in the comments of >> Struts bug 16191 in Bugzilla: >> http://issues.apache.org/bugzilla/show_bug.cgi?id=16191 >> >> I will try that out and see if it improves my results. >> >> I remain perplexed at what changes between versions 1.1 and 1.2.4 of Struts >> caused it to become susceptible to this problem. Any ideas on that? >> >> Patterson >> >> P.S. - I know how to view the headers of replies sent from the server to the >> browser, but am not sure how to get at those sent from the browser to the >> server, to make sure that they are indeed UTF-8. Any suggestions? >> >> in article [EMAIL PROTECTED], Guillaume Cottenceau at [EMAIL PROTECTED] >> wrote on 4/01/05 16:40: >> >>> Most probably the browser is sending data in UTF-8 but doesn't say so with >>> charset= in the Content-Type header. If you're confident enough that the >>> browsers will send UTF-8 (which should be the case if they are encoded in >>> UTF-8 and you use accept-charset in the forms), you can use a filter which >>> forces the HTTP request to be seen as UTF-8 in input (for example >>> filters/SetCharacterEncodingFilter which is bundled with tomcat)[1]. >>> >>> >> > One way woulb be to set up a proxy that your browser uses to connect to the > web. I used to use web scarab. http://www.owasp.org/software/webscarab.html > > -josh > I still haven't figured out the solution to my problem, but I have figured out one *cause* of it. After using web scarab at Josh's suggestion to eavesdrop on the conversations between my browser and app server, I've figured out what has changed between Struts 1.1 and 1.2.4: Struts 1.1 in spite of the the <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" language="java" %> directive, Struts was in fact sending back pages encoded in ISO-8859-1, and the resulting form submissions were URL-encoded (and decoded) in the same format. Struts 1.2.4 the directive is now being followed, and pages are sent out in UTF-8 encoding. However, for some reason, the form data is not being decoded as UTF-8, but still as ISO-8859-1. This suggests to me that if I were to remove the contentType directive in Struts 1.2.4, it would fall back to the default ISO-8859-1 encoding, and all would work as before: except that my web application would then be constrained to using only characters representable in that encoding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
"J. Patterson Waltz III" writes: > P.S. - I know how to view the headers of replies sent from the server to the > browser, but am not sure how to get at those sent from the browser to the > server, to make sure that they are indeed UTF-8. Any suggestions? I usually temporarily modify the URL where to post the form to something like http://localhost:/ then a simple `nc -l -p ' in a console listens to the connection and dumps received data. -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
J. Patterson Waltz III wrote: Merci Guillaume, I had actually seen the references to the Filter solution in the comments of Struts bug 16191 in Bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=16191 I will try that out and see if it improves my results. I remain perplexed at what changes between versions 1.1 and 1.2.4 of Struts caused it to become susceptible to this problem. Any ideas on that? Patterson P.S. - I know how to view the headers of replies sent from the server to the browser, but am not sure how to get at those sent from the browser to the server, to make sure that they are indeed UTF-8. Any suggestions? in article [EMAIL PROTECTED], Guillaume Cottenceau at [EMAIL PROTECTED] wrote on 4/01/05 16:40: Most probably the browser is sending data in UTF-8 but doesn't say so with charset= in the Content-Type header. If you're confident enough that the browsers will send UTF-8 (which should be the case if they are encoded in UTF-8 and you use accept-charset in the forms), you can use a filter which forces the HTTP request to be seen as UTF-8 in input (for example filters/SetCharacterEncodingFilter which is bundled with tomcat)[1]. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] One way woulb be to set up a proxy that your browser uses to connect to the web. I used to use web scarab. http://www.owasp.org/software/webscarab.html -josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
Merci Guillaume, I had actually seen the references to the Filter solution in the comments of Struts bug 16191 in Bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=16191 I will try that out and see if it improves my results. I remain perplexed at what changes between versions 1.1 and 1.2.4 of Struts caused it to become susceptible to this problem. Any ideas on that? Patterson P.S. - I know how to view the headers of replies sent from the server to the browser, but am not sure how to get at those sent from the browser to the server, to make sure that they are indeed UTF-8. Any suggestions? in article [EMAIL PROTECTED], Guillaume Cottenceau at [EMAIL PROTECTED] wrote on 4/01/05 16:40: > Most probably the browser is sending data in UTF-8 but doesn't > say so with charset= in the Content-Type header. If you're > confident enough that the browsers will send UTF-8 (which should > be the case if they are encoded in UTF-8 and you use > accept-charset in the forms), you can use a filter which forces > the HTTP request to be seen as UTF-8 in input (for example > filters/SetCharacterEncodingFilter which is bundled with > tomcat)[1]. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character encoding problems after 1.1 to 1.2.4 upgrade
"J. Patterson Waltz III" writes: > Hello, > > I recently upgraded a J2EE/Struts web application I'm working on to the > 1.2.4 version of Struts, and ever since I made this change, I've been > encountering a problem with the encoding of non-ascii character data > submitted in forms. All my pages are set to use UTF-8 encoding (via a <%@ > page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" > language="java" %> directive in my master Tiles layout), and this worked > fine with Struts 1.1, with respect to data submission and display. However, > since I upgraded to 1.2.4, data entered is now stored and redisplayed in its > "encoded" form rather than its decoded form: i.e. été becomes été Most probably the browser is sending data in UTF-8 but doesn't say so with charset= in the Content-Type header. If you're confident enough that the browsers will send UTF-8 (which should be the case if they are encoded in UTF-8 and you use accept-charset in the forms), you can use a filter which forces the HTTP request to be seen as UTF-8 in input (for example filters/SetCharacterEncodingFilter which is bundled with tomcat)[1]. Note: if you also use GET parameters encoded in UTF-8, with tomcat-5 you have to set `useBodyEncodingForURI="true"' in the Connector or else tomcat will always consider it ISO-8859-1 (or you can force the URI to be always decoded as UTF-8, but I think this is more elegant and versatile that way). Ref: [1] this is very surprising, I can't seem to be able to find stuff in struts archives... for example, searching gmane archives with google with "struts SetCharacterEncodingFilter site:gmane.org", I get only one answer; however, I verified that archives can be accessed on gmane by clicks only (no form post), so google should crawl them I guess. the search on gmane itself is extremely slow but gives answers. then, searching marc.theaimsgroup.com has similar errors with google: 0 answer from google, however articles are also available by clicks, no form post needed. and then it's even worse, searching for SetCharacterEncodingFilter seems to trigger a bug in their search engine, no answer is shown, only the list of all archives sorted by month -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Character encoding problems after 1.1 to 1.2.4 upgrade
Hello, I recently upgraded a J2EE/Struts web application I'm working on to the 1.2.4 version of Struts, and ever since I made this change, I've been encountering a problem with the encoding of non-ascii character data submitted in forms. All my pages are set to use UTF-8 encoding (via a <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" language="java" %> directive in my master Tiles layout), and this worked fine with Struts 1.1, with respect to data submission and display. However, since I upgraded to 1.2.4, data entered is now stored and redisplayed in its "encoded" form rather than its decoded form: i.e. été becomes été I have been searching through Apache's bugzilla and the struts-user list archives for some indication of how to fix this issue. One thing I've tried is to set the acceptCharset attribute of the tag to "UTF-8," but this did not change the results I get. In another attempt, I set the enctype attribute of the tag to "text/plain; charset=UTF-8", but this results in Struts returning a whitescreen upon submission of the form. Thanks in advance for any suggestions you can provide. Patterson Waltz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: character encoding
> I have added an acceptCharset attribute to the FormTag. > Should be available in the next nightly build - 22/07/2004 Hooray :) Thanks a lot, this is going to be very useful. Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: character encoding
I have added an acceptCharset attribute to the FormTag. which will generate something as Should be available in the next nightly build - 22/07/2004 Niall - Original Message - From: "Carl-Eric Menzel (bitFORCE media)" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Cc: "Larry Young" <[EMAIL PROTECTED]> Sent: Wednesday, July 21, 2004 8:36 PM Subject: Re[2]: character encoding > > Carl-Eric, > > > Yes, I tried the charset on the form but found it didn't do any good. > > > But what do you force the Encoding to in your Filter? How can you > > know with any certitude how the browser encoded the data values before > > sending it to you?? It probably works well if the browser is setup to > > "auto-select" the encoding, but what do you do if they have it explicitly > > set to something other than what you are assuming? > > Then I'm out of luck. That's the biggest problem with Strut's lack of > support for the accept-charset attribute. *Most of the time* it works > that if you send the response in UTF-8 the next request will come in > as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms > and assume that I get the same back. It's an ugly hack, but the only > way that seems to work at the moment. > > I asked a few weeks ago if there was any way for me to extend the form > tag to support this attribute, or whether there is any good reason why > it is not implemented. So far I haven't received an answer. > > Carl-Eric > -- > Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel > Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E > Antwort: Antworten oben zu schreiben. | Bitte keine HTML- > Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: character encoding
Hi, to get the encoding right the outgoing encoding (JSP-page) and the incoming encoding have to bet he same. You should define the enconfig of the JSP by: 1. Setting the content-type in the HTML Page 2. Defining the contentType;charset for the JSPC <[EMAIL PROTECTED] contentType="test/html:charset=UTF-8"%> 3. Defining The encoding type and charset of the form: The Opera and Firefox Browsers provide better informations about the content encoding than the IE. You should check the encoding in one of those. The browser may choose a different charset for displaying the page (and form) and you won't get UTF-8 data back. This procedure worked fine on at least two major projects. Regards, Niclas -Original Message- From: Larry Young [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:39 PM To: Struts Users Mailing List Subject: Re: character encoding Carl-Eric, Yes, I tried the charset on the form but found it didn't do any good. But what do you force the Encoding to in your Filter? How can you know with any certitude how the browser encoded the data values before sending it to you?? It probably works well if the browser is setup to "auto-select" the encoding, but what do you do if they have it explicitly set to something other than what you are assuming? --- regards --- Larry At 12:07 PM 7/21/04, you wrote: > > I'd like to hear how others have solved this problem. I can see > > that one solution is to replace the RequestProcessor and hardcode the > > "setEncoding" on the Request to UTF-8, or subclass the whole > > ActionServlet. Are there any cleaner solutions? I can't believe I'm the > > only one to have run across this problem! I'm not THAT unlucky! :) > >I am using a Filter (from the Servlet API) that gets the request >before anything else in the chain and calls setEncoding() on it before >passing it on. > >What would be great, just to get a little more consistency into this, >would be if the html:form-tag would finally support the accept-charset >attribute as specified in HTML4.01. > >HTH >Carl-Eric >-- >Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel >Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E >Antwort: Antworten oben zu schreiben. | Bitte keine HTML- >Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[3]: character encoding
The new JSF spec does allow for Content-Type lookup, here's a bit of code that I used in my implementation to find the content type out of that header, it might be of some use to you or whoever: protected static final Pattern PATTERN_CHARSET = Pattern.compile(".*charset\\s*=\\s*([\\w\\-]+)(\\s*|;).*"); /** * Grab the character encoding from the request, if not found, check the * stored value. Finally, set the character encoding on the request * * @param context * @param stored * @throws FacesException */ protected void setCharacterEncoding(FacesContext context) throws FacesException { ExternalContext extCtx = context.getExternalContext(); Object request = extCtx.getRequest(); if (request instanceof ServletRequest) { String contentType = (String) extCtx.getRequestHeaderMap().get("Content-Type"); String charset = null; if (contentType != null) { Matcher match = PATTERN_CHARSET.matcher(contentType); if (match.lookingAt()) { charset = match.group(1); } } if (charset == null) charset = (String) extCtx.getSessionMap().get(CHARACTER_ENCODING_KEY); if (charset != null) { try { ((ServletRequest) request).setCharacterEncoding(charset); } catch (UnsupportedEncodingException uee) { extCtx.log("Error Encoding: " + charset, uee); } } } } Note, this required J2SE 1.4. Cheers, Jacob Hookom -Original Message- From: Carl-Eric Menzel [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 2:44 PM To: Larry Young Cc: Struts Users Mailing List Subject: Re[3]: character encoding > Then I'm out of luck. That's the biggest problem with Strut's lack of > support for the accept-charset attribute. *Most of the time* it works > that if you send the response in UTF-8 the next request will come in > as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms > and assume that I get the same back. It's an ugly hack, but the only > way that seems to work at the moment. > I asked a few weeks ago if there was any way for me to extend the form > tag to support this attribute, or whether there is any good reason why > it is not implemented. So far I haven't received an answer. PS: While searching for a solution I found that the HTTP spec actually provides the browsers with a way to *specify* the encoding they're sending, which would completely solve this issue. It appears that the only browser that supported it *was* Mozilla. They found out that this extended (but conforming to the spec!) Content-Type header made so many broken CGI-scripts puke that they removed this feature again. *sigh* Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[3]: character encoding
> Then I'm out of luck. That's the biggest problem with Strut's lack of > support for the accept-charset attribute. *Most of the time* it works > that if you send the response in UTF-8 the next request will come in > as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms > and assume that I get the same back. It's an ugly hack, but the only > way that seems to work at the moment. > I asked a few weeks ago if there was any way for me to extend the form > tag to support this attribute, or whether there is any good reason why > it is not implemented. So far I haven't received an answer. PS: While searching for a solution I found that the HTTP spec actually provides the browsers with a way to *specify* the encoding they're sending, which would completely solve this issue. It appears that the only browser that supported it *was* Mozilla. They found out that this extended (but conforming to the spec!) Content-Type header made so many broken CGI-scripts puke that they removed this feature again. *sigh* Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: character encoding
> Carl-Eric, > Yes, I tried the charset on the form but found it didn't do any good. > But what do you force the Encoding to in your Filter? How can you > know with any certitude how the browser encoded the data values before > sending it to you?? It probably works well if the browser is setup to > "auto-select" the encoding, but what do you do if they have it explicitly > set to something other than what you are assuming? Then I'm out of luck. That's the biggest problem with Strut's lack of support for the accept-charset attribute. *Most of the time* it works that if you send the response in UTF-8 the next request will come in as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms and assume that I get the same back. It's an ugly hack, but the only way that seems to work at the moment. I asked a few weeks ago if there was any way for me to extend the form tag to support this attribute, or whether there is any good reason why it is not implemented. So far I haven't received an answer. Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: character encoding
Carl-Eric, Yes, I tried the charset on the form but found it didn't do any good. But what do you force the Encoding to in your Filter? How can you know with any certitude how the browser encoded the data values before sending it to you?? It probably works well if the browser is setup to "auto-select" the encoding, but what do you do if they have it explicitly set to something other than what you are assuming? --- regards --- Larry At 12:07 PM 7/21/04, you wrote: > I'd like to hear how others have solved this problem. I can see > that one solution is to replace the RequestProcessor and hardcode the > "setEncoding" on the Request to UTF-8, or subclass the whole > ActionServlet. Are there any cleaner solutions? I can't believe I'm the > only one to have run across this problem! I'm not THAT unlucky! :) I am using a Filter (from the Servlet API) that gets the request before anything else in the chain and calls setEncoding() on it before passing it on. What would be great, just to get a little more consistency into this, would be if the html:form-tag would finally support the accept-charset attribute as specified in HTML4.01. HTH Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: character encoding
> I'd like to hear how others have solved this problem. I can see > that one solution is to replace the RequestProcessor and hardcode the > "setEncoding" on the Request to UTF-8, or subclass the whole > ActionServlet. Are there any cleaner solutions? I can't believe I'm the > only one to have run across this problem! I'm not THAT unlucky! :) I am using a Filter (from the Servlet API) that gets the request before anything else in the chain and calls setEncoding() on it before passing it on. What would be great, just to get a little more consistency into this, would be if the html:form-tag would finally support the accept-charset attribute as specified in HTML4.01. HTH Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
character encoding
Hello, I've run into a bit of a problem and I'd like to know how others have solved it. It's basically a character encoding issue. I post my struts-based JSP page to the user, they enter some data, and then submit the page back to my Action. The data they enter may contain multi-byte characters. If I pull the data out of the parameter list (using PropertyUtils), I'm getting a whole bunch of extra characters for each multi-byte character (ASCII works just fine). If I set the encoding value in the Request to UTF-8 before calling PropertyUtils, it seems to work great for non-Form data values. However, the since the Form is populated before my Action is called, these String values have already been decoded and are wrong. I'd like to hear how others have solved this problem. I can see that one solution is to replace the RequestProcessor and hardcode the "setEncoding" on the Request to UTF-8, or subclass the whole ActionServlet. Are there any cleaner solutions? I can't believe I'm the only one to have run across this problem! I'm not THAT unlucky! :) Any help is most gratefully appreciated. --- regards --- Larry -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts response character encoding.
man, 19.07.2004 kl. 14.58 skrev Emmanouil Batsis: > There this system property you can set but I can't remember it, it's > used as the encoding to use when reading files... > > Anyway, I always edit my .jsp and .properties using UTF-8, then pass > them through the native2ascii ant task during my build. It's just a > wrapper for the same-named JDK binary; you can use that directly if you > dont use Ant. Works great. Yes, I know. I am using that one for my resource files. But In my opinion, it should not be necessary to convert the encoding for that file(s) either. Somewhere behind the scenes there is a java.util.Properties class used, and that class assumes iso-8859-1. http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html#encoding Encodings should be as transparent as possible, not the assumptions of some developers. Since I am developing and deploying on utf-8 encoding platforms, everything should be smooth, but it is not. I discovered that Struts use iso-8859-1 as default (same as java.util.Properties), and in order to override this setting I have to put a <% @page ... %> directive on every jsp. Ant can really native2ascii'ify all of this, but what about the one who have to administer this mess? When I am on my way to the next job, and they find a misspelling or they have to change some stuff in either the jsp or a resource file lokking like this (arbitrary Norwegian text): Sp\u00f8rsm\u00e5lsgruppen slettet, tilh\u00f8rende sp\u00f8rms\u00e5l eksisterer fortsatt I wish encodings were as simple as they could be (everyone used utf-8) ;-) -- Olve SÃther Hansen <[EMAIL PROTECTED]> Intermedia/Aksis - Unifob AS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts response character encoding.
There this system property you can set but I can't remember it, it's used as the encoding to use when reading files... Anyway, I always edit my .jsp and .properties using UTF-8, then pass them through the native2ascii ant task during my build. It's just a wrapper for the same-named JDK binary; you can use that directly if you dont use Ant. Works great. hth, Manos Olve SÃther Hansen wrote: I have some problems using struts/tiles and UTF-8 characters embedded in an jsp page. How can I make struts/tiles respect the system default encoding, and not use iso-8859-1 for all jsp pages? This problem occurs in tomcat 4.1.29, 5.0.19 and 5.0.27. I have a struts version bundled with Appfuse, all I know is that it is from 2003-12.02 (that is 2. december). It seems like struts is hard-coding the response encoding to be ISO-8859-1, although the response-encoding is set to be UTF-8 for all requests.. In a struts-action I execute this code: log.debug("res encoding: " +response.getCharacterEncoding()); log.debug("req encoding: " +request.getCharacterEncoding()); resulting in: res encoding: ISO-8859-1 req encoding: UTF-8 I use the SpringFramework characterEncodingFilter to force utf-8. My web-browser reports the page to be encoded in utf-8. If I use iconv (a Linux program for converting files from one encoding to another) to convert a file containing utf-8 characters (norwegian characters à à Ã) to iso-8859-1, the pages displays correctly. My web-browser still reports the page as being encoded in utf-8. If I write the same Norwegian letters in a jsp page outside of struts/tiles control, the page displays without problems.. So, is there a way to make struts/tiles respect the system default encoding, and not use iso-8859-1 for all jsp pages? Hope someone can help me solve this problem, I have looked through most email archives I can find without any solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts response character encoding.
sÃn, 18.07.2004 kl. 22.23 skrev Jason Lea: > Olve SÃther Hansen wrote: > > >Now I am saying false things. I thought my baseLayout.jsp had this > >entry.. It didn't. > > > >So it is enough specifying > ><%@ page contentType="text/html; charset=UTF-8"%> > >in the base tiles file if that architecture is used. > > > > > > > I think it that should work. > > But I think I ran into a problem when pre-compiling the JSP pages when > using the 2.3 spec. If you don't pre-compile I think it should be ok. > If you do pre-compile, each JSP is passed to the compiler and the > compiler does not know the encoding, so it uses the default. This is > why I ended up adding it to all pages. I ended up using the directive for all jsp's containing non-ascii utf-8 characters.. Most messages are retrieved through the resource properties, but when I am lazy, I write things directly in the jsp. Thanks for the help! -- Olve SÃther Hansen <[EMAIL PROTECTED]> Systems developer - National english reading tests Intermedia/Aksis - Unifob http://www.intermedia.uib.no - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts response character encoding.
Olve SÃther Hansen wrote: Now I am saying false things. I thought my baseLayout.jsp had this entry.. It didn't. So it is enough specifying <%@ page contentType="text/html; charset=UTF-8"%> in the base tiles file if that architecture is used. I think it that should work. But I think I ran into a problem when pre-compiling the JSP pages when using the 2.3 spec. If you don't pre-compile I think it should be ok. If you do pre-compile, each JSP is passed to the compiler and the compiler does not know the encoding, so it uses the default. This is why I ended up adding it to all pages. -- Jason Lea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts response character encoding.
Now I am saying false things. I thought my baseLayout.jsp had this entry.. It didn't. So it is enough specifying <%@ page contentType="text/html; charset=UTF-8"%> in the base tiles file if that architecture is used. -- Olve SÃther Hansen <[EMAIL PROTECTED]> Intermedia/Aksis - Unifob AS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]