Finally, I solved the problem. The solution is integrating a
CharacterEncodingFilter as a filter in the application's web.xml.
1. Add "input.encoding=UTF-8" and "output.encoding=UTF-8" to the
velocity.properties file.
2. Download mmbase.jar from http://www.mmbase.org and insert it into
WEB-INF/lib.
3. Add the following to the application's web.xml:
<filter>
<filter-name>Set Character Encoding</filter-name>
<filter-class>org.mmbase.servlet.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
4. In the Java backend, any UTF-8 converting like "new
String(original.getBytes(), "UTF-8");" must be removed.
I must admit, that I didn't really locate the exact cause of the
problem. Anyway, I'm happy to have found this workaround.
I hope it will help in case someone should have the same problem.
>
>There can be components whose behavior is possibly buggy (e.g. some of
>the early Jetty 5 betas or alphas had bugs regarding input charsets, or
>MySQL JDBC can be absolutely mad), so it would be important to cleanly
>identify with some carefully chosen tests what charset is actually used
>in the *individual* steps... what does the browser believe about the
>charset (which influences the charset used for sending the form field
>values), the ServletRequest, and the ServletResponse... and, what Writer
>does Velocity use anyway. And, if a database is involved as well, then
>that's yet another component with at least two more points of failure
>(the JDBC connection, and the actual storage).
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
|