Sergiu Dumitriu <[email protected]>:
the container adds automatically the charset, and I think that this explains the behavior:
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletResponse....
"The charset for the MIME body response can be specified with setContentType(java.lang.String). For example, "text/html; charset=Shift_JIS". The charset can alternately be set using setLocale(java.util.Locale). If no charset is specified, ISO-8859-1 will be used."
Despite Paul's complaint that my suggestions didn't help, wouldn't the omission of an explicit locale/charset setting for the container cause Tomcat to get an inappropriate default charset from the environment? The locale settings in Tomcat include the charset, e.g. setLocale(java.util.Locale)<http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)> "Sets the locale of the response, setting the headers (including the Content-Type's charset) as appropriate" I'm currently not experiencing such problems, and my Tomcat config has environment variable settings like: LANG="en_US.UTF-8" (english/US locale with UTF-8 content encoding) JAVA_OPTS="-server -Xms160m -Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintCompilation -XX:+PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/usr/lib64" I'm pretty sure the LANG setting with encoding is the setting that does the trick. You might try dropping an "env(1)" (unix: "man 1 env") into your tomcat launch script to see what environment vars are actually being inherited from the environment (or just launch a subprocess out of java and run "env(1)"). Sometimes you might be surprised by unexpected environment variables that are being set, or having different variables set depending on whether the script is launched as a service or just run out of the user's shell. To avoid environmental dependencies, how about just using, e.g., $response.setContentType("text/xml; charset=UTF-8")? --Niels http://nielsmayer.com PS:
It's added automatically. If we do: response.setContentType("application/octet-stream"),
I agree that setContentType is extremely useful part of Xwiki API. As example, I have a ClassSheet that displays the same doc three different ways: #if( "$!request.xpage" == "plain" )##{ #if( "$!request.json" != "" )##{ $response.setContentType("text/javascript")## ... #else##}{ $response.setContentType("text/xml")## ... #end##} #else##}{ -- xpage=plain parameter not given, do "normal wikipage" ... #end##}