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
<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
