We are on a production server which uses Tomcat 7, and for whatever reason, the administrators refrain from setting the CATALINA_OPTS="-Dfile.encoding=UTF-8" workaround for us.
This means that now when deploying the WAR file, Tomcat returns garbled characters instead of their Unicode counterparts.
We have also included this in our web.xml, to no avail:
<filter>
<filter-name>encoder</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encoder</filter-name>
<url-pattern>*</url-pattern>
</filter-mapping>
How do we manage this without sending a man to breach into the server room and modify the configuration?
First of all, it’s important to understand what the
-Dfile.encoding=UTF-8exactly does. It is a Sun/Oracle JVM-specific setting (which thus don’t necessarily work in all other JVMs!) which basically instructs the JVM to read the Java.classfiles using the given encoding instead of the platform default one. So, setting this would only solve any possible Mojibake problems which is caused by using "special characters" in Java class/variable names or hardcodedStringvalues in Java classes (yes, you read it right: only Java classes, not other files, thus definitely not properties files or JSF XHTML files, etc).In all honesty, I can hardly imagine that this is the right solution to your concrete problem. Why would one ever use special characters straight in Java classes? Class/variable names should be in all English and localized text should be placed in resource bundle files. Every self respected Java developer adeheres this convention.
Given that fact, and assuming that you are also not using special characters in Java classes at all, I thus believe that your concrete problem is caused by something else. The problem symptoms are not specific enough described (at which step exactly does it fail? which characters exactly do you expect and get instead? etc) to see the possible root cause of your concrete problem. I can at least tell that the URL pattern of your Spring filter is completely wrong. It must be mapped on
/*(by the way, you don’t necessarily need Spring for this, just a custom
Filterwith only 2 or 3 lines indoFilter()implementation is already sufficient)See also: