Re: [Stripes-users] UTF8 from form to mySQL
Hi Yee,
The right answer has already be given to you on previous mails.
1. Configure your LocalePicker:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest request,
Locale locale) {
return (UTF-8);
}
}
1. Add the parameter URIEncoding=UTF-8 to your HTTP connector in
server.xml.
2. Finally, add the following line to your JSPs:
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Tue, Feb 8, 2011 at 4:32 AM, Yee yeec...@gmail.com wrote:
Janne Jalkanen janne.jalkanen@... writes:
Simple solution: declare the accept-charset value on all your forms to be
UTF-8 (and *only* UTF-8), then
put up a simple Filter in front of your chain which says
request.setCharacterEncoding(UTF-8). This
should ensure that you get full unicodes to the ActionBean, and then you
only
have to deal with your DB encodings.
Works for me well.
I did just that - but then I found out that many users are still using
European
keyboards (or input programs) that output double byte characters.
This is still an unresolved problem for me. I have users using German,
Dutch,
French, Spanish spanning half the world - including Mexico.
Any suggestions?
Regards,
Yee
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Janne Jalkanen janne.jalkanen@... writes: Simple solution: declare the accept-charset value on all your forms to be UTF-8 (and *only* UTF-8), then put up a simple Filter in front of your chain which says request.setCharacterEncoding(UTF-8). This should ensure that you get full unicodes to the ActionBean, and then you only have to deal with your DB encodings. Works for me well. I did just that - but then I found out that many users are still using European keyboards (or input programs) that output double byte characters. This is still an unresolved problem for me. I have users using German, Dutch, French, Spanish spanning half the world - including Mexico. Any suggestions? Regards, Yee -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Basically, in addition to the other things I mentioned there indeed is one Stripes configuration that I set... by creating a custom LocalePicker subclass that picks the character encoding UTF-8... and dropping it the configured Stripes extensions folder... the relevant code is as follows: Ah, ok, thanks for the tip. I still don't mind putting in the extra filter, since all my projects seem to have a ton of them anyway, and dropping in one extra line isn't much bother :-) I imagine one could also put in a custom Interceptor, if we're in the process of listing different ways of enabling UTF-8 :-D /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Janne, Just curious why the need for the filter assuming all your requests go through Stripes. Do you have other non-Stripe traffic or perhaps the filter does other things as well. If not, the Stripes code is pretty clear... it effectively invokes exactly what your filter does... just curious what the benefit is... b/c I don't see the point and another filter... no matter how marginal the code is... is going to impact performance / scalability / resources unnecessarily... . No? Also, the OP wanted to know how to enable UTF-8 all the way to the DB... so it wasn't how many ways you could do this... so again I don't see the point about doing this in an interceptor... but sure if Stripes didn't have built-in support... I would consider a filter or interceptor but the case is moot IMO. Rather my point was about having missed including this in the list of things I did to enable UTF-8 support in reply to the OP. Cheers, --Nikolaos Janne Jalkanen wrote: Basically, in addition to the other things I mentioned there indeed is one Stripes configuration that I set... by creating a custom LocalePicker subclass that picks the character encoding UTF-8... and dropping it the configured Stripes extensions folder... the relevant code is as follows: Ah, ok, thanks for the tip. I still don't mind putting in the extra filter, since all my projects seem to have a ton of them anyway, and dropping in one extra line isn't much bother :-) I imagine one could also put in a custom Interceptor, if we're in the process of listing different ways of enabling UTF-8 :-D /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
It's easy to remember, fast, works across all containers and all frameworks. Not everyone has the luxury of working with a single framework, even one as awesome as Stripes. It is not uncommon to have mixed code too, especially if you have a considerable array of ready-made servlets and filters to work from. Not everything needs to be always written from ground up using whichever framework happens to be the word-du-jour. /Janne On 7 Feb 2011, at 06:29, Nikolaos Giannopoulos wrote: Janne, Just curious why the need for the filter assuming all your requests go through Stripes. Do you have other non-Stripe traffic or perhaps the filter does other things as well. If not, the Stripes code is pretty clear... it effectively invokes exactly what your filter does... just curious what the benefit is... b/c I don't see the point and another filter... no matter how marginal the code is... is going to impact performance / scalability / resources unnecessarily... . No? Also, the OP wanted to know how to enable UTF-8 all the way to the DB... so it wasn't how many ways you could do this... so again I don't see the point about doing this in an interceptor... but sure if Stripes didn't have built-in support... I would consider a filter or interceptor but the case is moot IMO. Rather my point was about having missed including this in the list of things I did to enable UTF-8 support in reply to the OP. Cheers, --Nikolaos Janne Jalkanen wrote: Basically, in addition to the other things I mentioned there indeed is one Stripes configuration that I set... by creating a custom LocalePicker subclass that picks the character encoding UTF-8... and dropping it the configured Stripes extensions folder... the relevant code is as follows: Ah, ok, thanks for the tip. I still don't mind putting in the extra filter, since all my projects seem to have a ton of them anyway, and dropping in one extra line isn't much bother :-) I imagine one could also put in a custom Interceptor, if we're in the process of listing different ways of enabling UTF-8 :-D /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Really??? A filter just to set character encoding??? Although I imagine it would work isn't that a little sledge hammer-ish ;-) I seem to recall it was the recommended practice. Why not just put the following at the top of each of your JSPs (or tweak as necessary): %@ page language=java pageEncoding=UTF-8 contentType=text/html;charset=UTF-8 % That will ensure your web page supports UTF-8. No, it will just ensure that it outputs UTF-8; it does not say anything about incoming request (which is what the request.setCharacterEncoding() does.) As far as Stripes is concerned you don't have to do anything for it to support UTF-8... and Java retains all Strings in unicode so no issue there either. The problem stems from the fact that servlet spec says that the default input encoding is ISO-8859-1. Especially older browsers do not send the character encoding correctly, so you're better off declaring the input encoding explicitly. Please see Servlet specification version 2.5 Section SRV.3.9. /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Hi Daniil, I've an old post about this topic at http://www.samaxes.com/2006/12/java-and-utf-8-encoding/. Hope it helps, -- Samuel Santos http://www.samaxes.com/ On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen janne.jalka...@ecyrd.comwrote: Really??? A filter just to set character encoding??? Although I imagine it would work isn't that a little sledge hammer-ish ;-) I seem to recall it was the recommended practice. Why not just put the following at the top of each of your JSPs (or tweak as necessary): %@ page language=java pageEncoding=UTF-8 contentType=text/html;charset=UTF-8 % That will ensure your web page supports UTF-8. No, it will just ensure that it outputs UTF-8; it does not say anything about incoming request (which is what the request.setCharacterEncoding() does.) As far as Stripes is concerned you don't have to do anything for it to support UTF-8... and Java retains all Strings in unicode so no issue there either. The problem stems from the fact that servlet spec says that the default input encoding is ISO-8859-1. Especially older browsers do not send the character encoding correctly, so you're better off declaring the input encoding explicitly. Please see Servlet specification version 2.5 Section SRV.3.9. /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Janne and Samuel,
Ok... I think there are some things that need to be clarified... b/c it
was a while since I set this up in Stripes... I hadn't realized I even
set it up.
Technically speaking yes - you are both correct -
request.setCharacterEncoding(UTF-8) is required and should be
performed if you are doing UTF-8 with a simple Servlet. However, as
StripesFilter is already in place one would hope you wouldn't have to
wrap yet another Servlet filter around it and clearly you don't.
Basically, in addition to the other things I mentioned there indeed is
one Stripes configuration that I set... by creating a custom
LocalePicker subclass that picks the character encoding UTF-8... and
dropping it the configured Stripes extensions folder... the relevant
code is as follows:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest
request, Locale locale) {
return (UTF-8);
}
}
And voila... all is well... and NO need for your additional Stripes
wrapper... why b/c the StripesFilter performs the following:
*String encoding =
this.configuration.getLocalePicker().pickCharacterEncoding(httpRequest,
locale);*
*if (encoding != null) {*
*httpRequest.setCharacterEncoding(encoding);*
log.debug(LocalePicker selected character encoding:
, encoding);
}
else {
log.debug(LocalePicker did not pick a character
encoding, using default: ,
httpRequest.getCharacterEncoding());
}
So, in fact we are golden via simple Stripes configuration vs. wrapping
a custom filter around the Stripes filter.
I had done this so long ago that I forgot I even did it. And yes,
technically the web browser should adhere to what its asked to use as
the encoding and sure older web browsers may have issues - problem is
what older means today is very unclear - so I agree this needs to be
done but let Stripes do it for you.
So the above should be added to my previous list :-)
Cheers,
--Nikolaos
Samuel Santos wrote:
Hi Daniil,
I've an old post about this topic at
http://www.samaxes.com/2006/12/java-and-utf-8-encoding/.
Hope it helps,
--
Samuel Santos
http://www.samaxes.com/
On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen
janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com wrote:
Really??? A filter just to set character encoding??? Although I
imagine it would work isn't that a little sledge hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top of each of your JSPs
(or tweak as necessary):
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
That will ensure your web page supports UTF-8.
No, it will just ensure that it outputs UTF-8; it does not say
anything about incoming request (which is what the
request.setCharacterEncoding() does.)
As far as Stripes is concerned you don't have to do anything for
it to support UTF-8... and Java retains all Strings in unicode so
no issue there either.
The problem stems from the fact that servlet spec says that the
default input encoding is ISO-8859-1. Especially older browsers do
not send the character encoding correctly, so you're better off
declaring the input encoding explicitly.
Please see Servlet specification version 2.5 Section SRV.3.9.
/Janne
--
The modern datacenter depends on network connectivity to access
resources
and provide services. The best practices for maximizing a physical
server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Hi Nikolaos,
My post was about Java EE in general and not about Stripes.
With Stripes, a custom LocalePicker implementation will correctly encode
POST parameters, but you still need to add the URIEncoding=UTF-8 attribute
to your connector configuration.
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Sun, Feb 6, 2011 at 3:11 AM, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Janne and Samuel,
Ok... I think there are some things that need to be clarified... b/c it was
a while since I set this up in Stripes... I hadn't realized I even set it
up.
Technically speaking yes - you are both correct -
request.setCharacterEncoding(UTF-8) is required and should be performed if
you are doing UTF-8 with a simple Servlet. However, as StripesFilter is
already in place one would hope you wouldn't have to wrap yet another
Servlet filter around it and clearly you don't.
Basically, in addition to the other things I mentioned there indeed is one
Stripes configuration that I set... by creating a custom LocalePicker
subclass that picks the character encoding UTF-8... and dropping it the
configured Stripes extensions folder... the relevant code is as follows:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest request,
Locale locale) {
return (UTF-8);
}
}
And voila... all is well... and NO need for your additional Stripes
wrapper... why b/c the StripesFilter performs the following:
*String encoding =
this.configuration.getLocalePicker().pickCharacterEncoding(httpRequest,
locale);*
*if (encoding != null) {*
*httpRequest.setCharacterEncoding(encoding);*
log.debug(LocalePicker selected character encoding: ,
encoding);
}
else {
log.debug(LocalePicker did not pick a character
encoding, using default: ,
httpRequest.getCharacterEncoding());
}
So, in fact we are golden via simple Stripes configuration vs. wrapping a
custom filter around the Stripes filter.
I had done this so long ago that I forgot I even did it. And yes,
technically the web browser should adhere to what its asked to use as the
encoding and sure older web browsers may have issues - problem is what
older means today is very unclear - so I agree this needs to be done but
let Stripes do it for you.
So the above should be added to my previous list :-)
Cheers,
--Nikolaos
Samuel Santos wrote:
Hi Daniil,
I've an old post about this topic at
http://www.samaxes.com/2006/12/java-and-utf-8-encoding/.
Hope it helps,
--
Samuel Santos
http://www.samaxes.com/
On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen
janne.jalka...@ecyrd.comwrote:
Really??? A filter just to set character encoding??? Although I
imagine it would work isn't that a little sledge hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top of each of your JSPs (or tweak
as necessary):
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
That will ensure your web page supports UTF-8.
No, it will just ensure that it outputs UTF-8; it does not say anything
about incoming request (which is what the request.setCharacterEncoding()
does.)
As far as Stripes is concerned you don't have to do anything for it to
support UTF-8... and Java retains all Strings in unicode so no issue there
either.
The problem stems from the fact that servlet spec says that the default
input encoding is ISO-8859-1. Especially older browsers do not send the
character encoding correctly, so you're better off declaring the input
encoding explicitly.
Please see Servlet specification version 2.5 Section SRV.3.9.
/Janne
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical
server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
Re: [Stripes-users] UTF8 from form to mySQL
Hey Samuel,
Samuel Santos wrote:
Hi Nikolaos,
My post was about Java EE in general and not about Stripes.
This mailing list is about Stripes not Java EE in general :-)
Sorry - couldn't resist - just joking with you :-)
But the OP was asking about UTF-8 with Stripes et al. and both Janne and
yourself made similar suggestions on writing custom filters which may
have been required once upon a time... and are definitely necessary if
you aren't using a web framework... but alas with Stripes are not required.
With Stripes, a custom LocalePicker implementation will correctly
encode POST parameters, but you still need to add the
URIEncoding=UTF-8 attribute to your connector configuration.
Two points here:
1) So... NOT everyone uses Tomcat... :-)
2) Incorrect on the POST comment. At least this is NOT an issue with
Glassfish v3 Final. Just tried the following and it worked fine:
http://www.local.ca:8080/ui-web/share/0/_?share.title=añadir un
título2share.brief=Increíble cómo las tortugas tienen un caparazón
brillante2share.modalityId=4001yes=tokenKeyTx=91db-25589690015563216-15nshrujm_sourcePage=vyJcD4BNJr9bCdvaD2RrnYpK04x6-Fot2_8vpBg6sVYHirKBhFKwog==__fp=vOPWJM_CB9-OCPxksbAYdekxq1M95vdE
Which resulted in this output:
We successfully added this new Share.
añadir un título2
Increíble cómo las tortugas tienen un caparazón brillante2
The output involves submitting Form via GET to add a share and persist
it in DB and then redirecting to the view handler that loads the share
and presents it from the DB.
Essentially demonstrating UTF-8 support through all the layers
Again, this doesn't mean that Tomcat doesn't have the issue that you
suggest it has with GET data but it clearly isn't something one needs to
add if they are using GlassFish v3 Final... who knows about other web
containers... .
--Nikolaos
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Sun, Feb 6, 2011 at 3:11 AM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Janne and Samuel,
Ok... I think there are some things that need to be clarified...
b/c it was a while since I set this up in Stripes... I hadn't
realized I even set it up.
Technically speaking yes - you are both correct -
request.setCharacterEncoding(UTF-8) is required and should be
performed if you are doing UTF-8 with a simple Servlet. However,
as StripesFilter is already in place one would hope you wouldn't
have to wrap yet another Servlet filter around it and clearly you
don't.
Basically, in addition to the other things I mentioned there
indeed is one Stripes configuration that I set... by creating a
custom LocalePicker subclass that picks the character encoding
UTF-8... and dropping it the configured Stripes extensions
folder... the relevant code is as follows:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest
request, Locale locale) {
return (UTF-8);
}
}
And voila... all is well... and NO need for your additional
Stripes wrapper... why b/c the StripesFilter performs the following:
*String encoding =
this.configuration.getLocalePicker().pickCharacterEncoding(httpRequest,
locale);*
*if (encoding != null) {*
*httpRequest.setCharacterEncoding(encoding);*
log.debug(LocalePicker selected character
encoding: , encoding);
}
else {
log.debug(LocalePicker did not pick a
character encoding, using default: ,
httpRequest.getCharacterEncoding());
}
So, in fact we are golden via simple Stripes configuration vs.
wrapping a custom filter around the Stripes filter.
I had done this so long ago that I forgot I even did it. And yes,
technically the web browser should adhere to what its asked to use
as the encoding and sure older web browsers may have issues -
problem is what older means today is very unclear - so I agree
this needs to be done but let Stripes do it for you.
So the above should be added to my previous list :-)
Cheers,
--Nikolaos
Samuel Santos wrote:
Hi Daniil,
I've an old post about this topic at
http://www.samaxes.com/2006/12/java-and-utf-8-encoding/.
Hope it helps,
--
Samuel Santos
http://www.samaxes.com/
On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen
janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com wrote:
Really??? A filter just to set character encoding???
Although I imagine it would work isn't that a little sledge
hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top of
Re: [Stripes-users] UTF8 from form to mySQL
Simple solution: declare the accept-charset value on all your forms to be
UTF-8 (and *only* UTF-8), then put up a simple Filter in front of your chain
which says request.setCharacterEncoding(UTF-8). This should ensure that you
get full unicodes to the ActionBean, and then you only have to deal with your
DB encodings.
Works for me well.
/Janne
On 4 Feb 2011, at 22:45, Daniil Sosonkin wrote:
Hi there,
So I'm sure there's someone out there who has met this problem and has found
a solution, therefore, let me ask the source. We are dealing with an
international web platform - many many languages. People submit forms in
different languages and it all stored in a mySQL database. Basically, I'm
having troubles getting UTF8 to work with said database. I have troubles at
all levels - stripes and database.
Here's my set up:
- mySQL 5.1
- mysql-jdbc 5.1 (driver)
- tables - utf8
- LocalePicker is always forcing charset to UTF-8 in stripes
Here's the problem:
- User enters some characters into the form (chinese, russian, hebrew)
- ActionBean sticks it into the database and sends email.
- Fields are declared as Strings and nothing is done to the values
- When sticking to the database it will contain - as values
- The output from the database obviously doesn't work
- When printing submitted value on page from ${actionBean.field} it
displays junk
I know that browsers send all forms to the servers in ISO-8859-1 encoding. In
the good old days, or with plain servlets, I would always have to convert
submitted values to UTF-8 with the following: new
String(rs.getString(1).getBytes(ISO-8859-1), UTF-8); From then on the
value is in UTF-8
In Stripes, I think that the values come to ActionBeans in ISO-8859-1 since
StringTypeConverter doesn't do anything. That's fine, I wrote my own
converter for UTF using the logic from above. This solves the problem with
printing submitted value on the page ${actionBean.field}; but if the value is
still displayed in the form it is all grumbled as if it was ISO-8859-1
representation of UTF-8. That I don't understand.
As for storing UTF8 into mySQL - well, if someone can help me out it would be
great since I can't get UTF8 string stored in the database without doing the
UTF8 to ISO-8859-1 and back conversion while keeping tables at latin1 I would
really appreciate it. The main question is Stripes.
I hope this whole rambling makes sense and someone has had this problem
previously. Hopefully there was a solution.
Sincerely,
Daniil
daniil.vcf--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Thanks, Janne. I got the Stripe's form to refill with a valid value! But
${actionBean.field} won't work now. I have a filter that sets
request.setCharacterEncoding(UTF-8); as you suggested. Then I print
on my JSP: Last: ${actionBean.test}
The action bean and the form are below. So stripes fills in fields fine,
but the HTML displays
s:form beanclass=web.actions.UTF8 method=post/get acceptcharset=UTF8
s:text name=test/
s:submit name=done/
/s:form
@UrlBinding(/test.action)
public class UTF8 extends MyActionBean
{
private String test;
public String getTest()
{
return test;
}
public void setTest(String test)
{
this.test = test;
}
public Resolution test()
{
return getContext().getSourcePageResolution();
}
}
On 2/4/2011 4:16 PM, Janne Jalkanen wrote:
Simple solution: declare the accept-charset value on all your forms to be UTF-8 (and *only*
UTF-8), then put up a simple Filter in front of your chain which says
request.setCharacterEncoding(UTF-8). This should ensure that you get full unicodes to
the ActionBean, and then you only have to deal with your DB encodings.
Works for me well.
/Janne
On 4 Feb 2011, at 22:45, Daniil Sosonkin wrote:
Hi there,
So I'm sure there's someone out there who has met this problem and has found a
solution, therefore, let me ask the source. We are dealing with an
international web platform - many many languages. People submit forms in
different languages and it all stored in a mySQL database. Basically, I'm
having troubles getting UTF8 to work with said database. I have troubles at all
levels - stripes and database.
Here's my set up:
- mySQL 5.1
- mysql-jdbc 5.1 (driver)
- tables - utf8
- LocalePicker is always forcing charset to UTF-8 in stripes
Here's the problem:
- User enters some characters into the form (chinese, russian, hebrew)
- ActionBean sticks it into the database and sends email.
- Fields are declared as Strings and nothing is done to the values
- When sticking to the database it will contain - as values
- The output from the database obviously doesn't work
- When printing submitted value on page from ${actionBean.field} it
displays junk
I know that browsers send all forms to the servers in ISO-8859-1 encoding. In the good old days, or
with plain servlets, I would always have to convert submitted values to UTF-8 with the following:
new String(rs.getString(1).getBytes(ISO-8859-1), UTF-8); From then on the
value is in UTF-8
In Stripes, I think that the values come to ActionBeans in ISO-8859-1 since
StringTypeConverter doesn't do anything. That's fine, I wrote my own converter
for UTF using the logic from above. This solves the problem with printing
submitted value on the page ${actionBean.field}; but if the value is still
displayed in the form it is all grumbled as if it was ISO-8859-1 representation
of UTF-8. That I don't understand.
As for storing UTF8 into mySQL - well, if someone can help me out it would be
great since I can't get UTF8 string stored in the database without doing the
UTF8 to ISO-8859-1 and back conversion while keeping tables at latin1 I would
really appreciate it. The main question is Stripes.
I hope this whole rambling makes sense and someone has had this problem
previously. Hopefully there was a solution.
Sincerely,
Daniil
daniil.vcf--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
attachment: daniil.vcf--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
Re: [Stripes-users] UTF8 from form to mySQL
Daniil --
We're doing all the same stuff and haven't encountered any problems. Here's a
few tidbits from our configuration.
In our mySQL connector we use:
Resource name=jdbc/xxx auth=Container type=javax.sql.DataSource
url=jdbc:mysql://localhost/x?autoReconnect=trueamp;useUnicode=yesamp;characterEncoding=UTF-8amp;jdbcCompliantTruncation=false
username=xxx
password=xxx driverClassName=com.mysql.jdbc.Driver maxActive=20
maxIdle=20 maxWait=1 defaultAutoCommit=true
validationQuery=SELECT 1
factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory /
In the tomcat container new add:
nano $CATALINA_HOME/conf/server.xml:
Connector executor=tomcatThreadPool
port=8080 protocol=HTTP/1.1 URIEncoding=UTF-8
connectionTimeout=2
Cheers -
Phil
On Feb 4, 2011, at 12:45 PM, Daniil Sosonkin wrote:
Hi there,
So I'm sure there's someone out there who has met this problem and has found
a solution, therefore, let me ask the source. We are dealing with an
international web platform - many many languages. People submit forms in
different languages and it all stored in a mySQL database. Basically, I'm
having troubles getting UTF8 to work with said database. I have troubles at
all levels - stripes and database.
Here's my set up:
- mySQL 5.1
- mysql-jdbc 5.1 (driver)
- tables - utf8
- LocalePicker is always forcing charset to UTF-8 in stripes
Here's the problem:
- User enters some characters into the form (chinese, russian, hebrew)
- ActionBean sticks it into the database and sends email.
- Fields are declared as Strings and nothing is done to the values
- When sticking to the database it will contain - as values
- The output from the database obviously doesn't work
- When printing submitted value on page from ${actionBean.field} it
displays junk
I know that browsers send all forms to the servers in ISO-8859-1 encoding. In
the good old days, or with plain servlets, I would always have to convert
submitted values to UTF-8 with the following: new
String(rs.getString(1).getBytes(ISO-8859-1), UTF-8); From then on the
value is in UTF-8
In Stripes, I think that the values come to ActionBeans in ISO-8859-1 since
StringTypeConverter doesn't do anything. That's fine, I wrote my own
converter for UTF using the logic from above. This solves the problem with
printing submitted value on the page ${actionBean.field}; but if the value is
still displayed in the form it is all grumbled as if it was ISO-8859-1
representation of UTF-8. That I don't understand.
As for storing UTF8 into mySQL - well, if someone can help me out it would be
great since I can't get UTF8 string stored in the database without doing the
UTF8 to ISO-8859-1 and back conversion while keeping tables at latin1 I would
really appreciate it. The main question is Stripes.
I hope this whole rambling makes sense and someone has had this problem
previously. Hopefully there was a solution.
Sincerely,
Daniil
daniil.vcf--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Janne,
Really??? A filter just to set character encoding??? Although I
imagine it would work isn't that a little sledge hammer-ish ;-)
Why not just put the following at the top of each of your JSPs (or tweak
as necessary):
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
That will ensure your web page supports UTF-8.
As far as Stripes is concerned you don't have to do anything for it to
support UTF-8... and Java retains all Strings in unicode so no issue
there either.
That leaves your MySQL database... and here I have found that I have
done multiple things and I'm sure I could trim this down but after
spending days on particular issues I just got fed up and set everything
I need to that I know will ensure things stay UTF-8... so be forewarned
this list should be able to be slimmed down and if you have the time to
test multiple scenarios then power to you ;-)
MySQL configuration (UTF-8 relevant pieces only...):
[mysqld]
skip-character-set-client-handshake
character-set-server=utf8
collation-server=utf8_general_ci
character_set_results=utf8
Starting MySQL (UTF-8 relevant pieces only...):
./bin/mysqld_safe --user=mysql --character-set-server=utf8
--collation-server=utf8_general_ci
And last but not least instead of trying to set the connection to UTF-8
we simply create a sub-classed dialect and set the table type AND
dialect in our Persistence.xml (we use JPA) as we really don't use
anything but InnoDB and UTF-8 in our databases:
public class UTF8MySQL5InnoDBDialect extends MySQL5InnoDBDialect {
public UTF8MySQL5InnoDBDialect() {
super();
}
public final String getTableTypeString() {
return ENGINE=InnoDB DEFAULT CHARSET=utf8;
}
}
Oh... and as a last warning if you are using an xterm then you'll be
able to see the characters in your DB properly but if you set the
encoding to UTF-8 (from its ASCII default) your going to see only
Latin-1 characters i.e. the spanish n is shown but not other non-Latin-1
characters. Screwy I know but caused a lot of grief.
So you have many suggestions... and feel free to pull the pieces from
other people's solutions that resonate better with you... but UTF-8
isn't really a Stripes problem per se because Java's unicode support
really makes localization within the webapp transparent... .
--Nikolaos
Janne Jalkanen wrote:
Simple solution: declare the accept-charset value on all your forms to be UTF-8 (and *only*
UTF-8), then put up a simple Filter in front of your chain which says
request.setCharacterEncoding(UTF-8). This should ensure that you get full unicodes to
the ActionBean, and then you only have to deal with your DB encodings.
Works for me well.
/Janne
On 4 Feb 2011, at 22:45, Daniil Sosonkin wrote:
Hi there,
So I'm sure there's someone out there who has met this problem and has found a
solution, therefore, let me ask the source. We are dealing with an
international web platform - many many languages. People submit forms in
different languages and it all stored in a mySQL database. Basically, I'm
having troubles getting UTF8 to work with said database. I have troubles at all
levels - stripes and database.
Here's my set up:
- mySQL 5.1
- mysql-jdbc 5.1 (driver)
- tables - utf8
- LocalePicker is always forcing charset to UTF-8 in stripes
Here's the problem:
- User enters some characters into the form (chinese, russian, hebrew)
- ActionBean sticks it into the database and sends email.
- Fields are declared as Strings and nothing is done to the values
- When sticking to the database it will contain - as values
- The output from the database obviously doesn't work
- When printing submitted value on page from ${actionBean.field} it displays
junk
I know that browsers send all forms to the servers in ISO-8859-1 encoding. In the good old days, or
with plain servlets, I would always have to convert submitted values to UTF-8 with the following:
new String(rs.getString(1).getBytes(ISO-8859-1), UTF-8); From then on the
value is in UTF-8
In Stripes, I think that the values come to ActionBeans in ISO-8859-1 since
StringTypeConverter doesn't do anything. That's fine, I wrote my own converter
for UTF using the logic from above. This solves the problem with printing
submitted value on the page ${actionBean.field}; but if the value is still
displayed in the form it is all grumbled as if it was ISO-8859-1 representation
of UTF-8. That I don't understand.
As for storing UTF8 into mySQL - well, if someone can help me out it would be
great since I can't get UTF8 string stored in the database without doing the
UTF8 to ISO-8859-1 and back conversion while keeping tables at latin1 I would
really appreciate it. The main question is Stripes.
I hope this whole rambling makes sense and someone has had this problem
previously. Hopefully there was a solution.
Sincerely,
Daniil
