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 davelnew...@gmail.com wrote: That defines the encoding of the web.xml file itself... On Oct 18, 2010 10:32 AM, Martin Gainty mgai...@hotmail.com wrote: Hi Zoran can you confirm the encoding attribute at the top of your web.xml e.g. ?xml version=1.0 encoding=UTF-8? 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: filter filter-namestruts-cleanup/filter-name filter-classorg.apache.struts2.dispatcher.ActionContextCleanUp/filter-c la ss /filter filter filter-namestruts/filter-name filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-c la ss /filter filter-mapping filter-namestruts-cleanup/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts/filter-name url-pattern/*/url-pattern /filter-mapping To filter filter-namestruts-prepare/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter /f ilter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-clas s /filter filter filter-namestruts-execute/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter /f ilter-class /filter filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping 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
Hi Zoran can you confirm the encoding attribute at the top of your web.xml e.g. ?xml version=1.0 encoding=UTF-8? 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: filter filter-namestruts-cleanup/filter-name filter-classorg.apache.struts2.dispatcher.ActionContextCleanUp/filter-cla ss /filter filter filter-namestruts/filter-name filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-cla ss /filter filter-mapping filter-namestruts-cleanup/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts/filter-name url-pattern/*/url-pattern /filter-mapping To filter filter-namestruts-prepare/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter/f ilter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-class /filter filter filter-namestruts-execute/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/f ilter-class /filter filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping 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: 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 mgai...@hotmail.com wrote: Hi Zoran can you confirm the encoding attribute at the top of your web.xml e.g. ?xml version=1.0 encoding=UTF-8? 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: filter filter-namestruts-cleanup/filter-name filter-classorg.apache.struts2.dispatcher.ActionContextCleanUp/filter-cla ss /filter filter filter-namestruts/filter-name filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-cla ss /filter filter-mapping filter-namestruts-cleanup/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts/filter-name url-pattern/*/url-pattern /filter-mapping To filter filter-namestruts-prepare/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter/f ilter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-class /filter filter filter-namestruts-execute/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/f ilter-class /filter filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping 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
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 zo...@sparecreative.com: I have a really strange character encoding error that is appearing when I attempt to change my struts2 filter configuration from: filter filter-namestruts-cleanup/filter-name filter-classorg.apache.struts2.dispatcher.ActionContextCleanUp/filter-cla ss /filter filter filter-namestruts/filter-name filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-cla ss /filter filter-mapping filter-namestruts-cleanup/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts/filter-name url-pattern/*/url-pattern /filter-mapping To filter filter-namestruts-prepare/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter/f ilter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-class /filter filter filter-namestruts-execute/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/f ilter-class /filter filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping 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
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 liying.cn.2...@gmail.com: 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 zo...@sparecreative.com: I have a really strange character encoding error that is appearing when I attempt to change my struts2 filter configuration from: filter filter-namestruts-cleanup/filter-name filter-classorg.apache.struts2.dispatcher.ActionContextCleanUp/filter-cla ss /filter filter filter-namestruts/filter-name filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-cla ss /filter filter-mapping filter-namestruts-cleanup/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts/filter-name url-pattern/*/url-pattern /filter-mapping To filter filter-namestruts-prepare/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter/f ilter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-class /filter filter filter-namestruts-execute/filter-name filter-classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/f ilter-class /filter filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping 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 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 head 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 head 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]
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/
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: user@struts.apache.org
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:
===
controller contentType=text/html;charset=UTF-8
processorClass=org.apache.struts.tiles.TilesRequestProcessor/
===
web.xml contains:
===
filter
filter-nameCharacter Encoding/filter-name
filter-classse.telia.kontaktamig.web.util.CharsetFilter/filter-class
/filter
filter-mapping
filter-nameCharacter Encoding/filter-name
url-pattern/*/url-pattern
/filter-mapping
context-param
param-namePARAMETER_ENCODING/param-name
param-valueUTF-8/param-value
/context-param
//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:
attribute
nameuseLocalEncoding/name
requiredfalse/required
rtexprvaluetrue/rtexprvalue
/attribute
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...
-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? controller contentType=text/html;charset=UTF-8 That looks good. context-param param-namePARAMETER_ENCODING/param-name param-valueUTF-8/param-value /context-param 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: attribute nameuseLocalEncoding/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute 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...
-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...
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? controller contentType=text/html;charset=UTF-8 That looks good. context-param param-namePARAMETER_ENCODING/param-name param-valueUTF-8/param-value /context-param 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: attribute nameuseLocalEncoding/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute 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...
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: 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...
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: 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...
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: 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...
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: === controller contentType=text/html;charset=UTF-8 processorClass=org.apache.struts.tiles.TilesRequestProcessor/ === web.xml contains: === filter filter-nameCharacter Encoding/filter-name filter-classse.telia.kontaktamig.web.util.CharsetFilter/filter-class /filter filter-mapping filter-nameCharacter Encoding/filter-name url-pattern/*/url-pattern /filter-mapping context-param param-namePARAMETER_ENCODING/param-name param-valueUTF-8/param-value /context-param //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: attribute nameuseLocalEncoding/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute 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...
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: user@struts.apache.org 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: === controller contentType=text/html;charset=UTF-8 processorClass=org.apache.struts.tiles.TilesRequestProcessor/ === web.xml contains: === filter filter-nameCharacter Encoding/filter-name filter-classse.telia.kontaktamig.web.util.CharsetFilter/filter-class /filter filter-mapping filter-nameCharacter Encoding/filter-name url-pattern/*/url-pattern /filter-mapping context-param param-namePARAMETER_ENCODING/param-name param-valueUTF-8/param-value /context-param //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: attribute nameuseLocalEncoding/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute 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...
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]
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 html:form tags - an enctype=application/x-www-form-urlencoded;charset=UTF-8 attribute on html:form 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
J.Patterson Waltz III lists 'at' cerenit.com 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 html:form tags - an enctype=application/x-www-form-urlencoded;charset=UTF-8 attribute on html:form 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 17:17, Guillaume Cottenceau wrote: J.Patterson Waltz III lists 'at' cerenit.com 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 html:form tags - an enctype=application/x-www-form-urlencoded;charset=UTF-8 attribute on html:form 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=correspondentpersonTO.subtype=correspondentTO.correspond entID=174personTO.personID=1personTO.salutation=mrpersonTO.lastName=W altzpersonTO.firstName=J.+PattersonpersonTO.status=activepersonTO.com ments=%C3%A9t%C3%A9personTO.address=personTO.city=personTO.postalCode =personTO.region=personTO.country=personTO.telephone1Label=personTO. telephone1=personTO.telephone2Label=personTO.telephone2=personTO.fax= personTO.email=x%40xxx.compersonTO.secondaryEmail=personT O.contactLanguage=enpersonTO.orgSummaryTO.organizationID=161personTO.e mployeeID=personTO.position=personTO.department=personTO.managerName= personTO.accountTO.login=x%40xxx.compersonTO.accountTO.pas sword=personTO.accountTO.loginEnabled=onpersonTO.accountTO.con nectionAttempts=0ID=174ID=1update=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 lists 'at' cerenit.com 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:44, Guillaume Cottenceau wrote: J.Patterson Waltz III lists 'at' cerenit.com 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 lists 'at' cerenit.com writes:
On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote:
J.Patterson Waltz III lists 'at' cerenit.com 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 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 pattersonw 'at' hotmail.com 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
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 pattersonw 'at' hotmail.com 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]
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 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
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]
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
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 META http-equiv=Content-type content=text/html;charset=UTF-8 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: html:form ... enctype=application/x-www-form-urlencoded; charset=UTF-8 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: character encoding
I have added an acceptCharset attribute to the FormTag. html:form action=abc.do acceptCharset=UTF-8 which will generate something as form action=abc.do method=post accept-charset=UTF-8 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 problem in struts
Here is a prebuilt filter that will do just what you are looking for .. http://www.anassina.com/struts/i18n/i18n.html Nathan On Apr 20, 2004, at 6:00 AM, brelagad the ent wrote: I cannot pass Turkish characters to the action servlet from a form. I read that I should use filters. I am wondering, is this a must or is there any other way to do this. Using Struts under tomcat 4.1.29 __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash - 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]
