Le 14-mars-09 à 19:53, Vincent Massol a écrit : Actually no. My experience is that there's no "encoding mismatch" even with a mysql which is set to iso-8859-1 while xwiki and jdbc is set to utf-8. The only mismatch we endured until we moved to a mysql that's parametrized for utf-8 is the storage inability for high-bytes characters (my test cases was lambda λ and leq ≤) which simply got garbled after the persist and read cycle happened (may take one hour sometimes on xwiki). It was in my MacOSX MySQL which I downloaded (from mysql.org) about a year ago. Same for my colleague on Windows. Same for our sysadmin with a Linux MySQL downloaded from there. But it was not the case with the mysql coming from a 3-years old SuSE installation. Many many many times the platform encoding is used rather than the containers' encoding. So that's MacRoman on mac! (enjoy!) The re-encoding happens transparently though, there's no commonality between that back-end and front-end. One thing that has bitten me more often than not is that Apache Httpd defaults to iso-8859-1 set explicitly on files with suffix html (so the mime-type is text/html;charset=iso-8859-1 instead of leaving to the meta head element the luxury of specifying that). I believe it should not affect normal XWiki though. paul PS: I think that a sane admin that does an update will diff xwiki.cfg and will see the difference!

Sergiu Dumitriu wrote: And now it's fixed, so there's no other problem for switching to utf8, except latin1 databases. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Sergiu Dumitriu wrote: http://n2.nabble.com/LANG-property-in-startup-script-in-standalone-version-… -- Sergiu Dumitriu http://purl.org/net/sergiu/

Niels Mayer wrote: This sets the charset/encoding to use as a default whenever strings (which are always UTF-16, see http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html) are converted to bytes and vice versa: - String.getBytes - new String(byte[]) - InputStream vs. Reader - OutputStream vs. Writer Fortunately, all these allow manually specifying an encoding to use, and if we want to be independent of the JVM encoding, we should always do that. There are still a few places where we use the JVM encoding, but a recent trunk is safe to use without taking care of the -Dfile.encoding. I can't find anything about this, so I doubt it does something. The servlet specification (2.5) states that when determining the encoding used to parse a request, either it is specified in the request itself in a HTTP Header, or the default encoding of ISO-8859-1 is used. Maybe some containers allow to change this default, but it's not standard. This auto-detection can be overridden by a call to request.setCharacterEncoding("enc"). I also can't find anything about this. Could be a mistaken name for -Dfile.encoding? There is a Jetty setting named javaEncoding, which affects the encoding used by the JSP compiler to generate Java source files, but we don't have any JSP pages. This sets an environment variable that is read by the JVM to determine the right value for file.encoding and the default locale. Setting -Dfile.encoding takes precedence, so this makes no sense for XWiki. It still influences the default locale, though, but the OS/JVM must have support for it. This is set in web.xml, or directly in the Java file if you modify the source and recompile it. This influences how the request is parsed, since request.getParameter transforms bytes into Strings. See the explanation for (2), this always forces our encoding to be used for reading requests. In the future this should be merged with the setting in xwiki.cfg, but this is not possible yet because the servlet filter does not have access to the XWiki object (to call xwiki.getEncoding()), and XWiki does not have access to the filter config. The ugly solution is to manually parse one of these files, but it really is Ugly. This is the main setting that we use for determining the encoding. This allows us to be independent of the system settings, since hosted users cannot always alter these settings, but they can change their application. There are a few more settings for various containers. For example, Tomcat users must use these (http://tomcat.apache.org/tomcat-6.0-doc/config/http.html): (7) URIEncoding - Tomcat treats different parts of the request differently: - URL path using UTF-8 - URL query using ISO-8859-1 - request body using the specified encoding (see 2 and 5) Previous versions of Tomcat (4.1) used the body encoding also for the query string, but they fixed this (this is in accordance with the specs). So, in order for request.getParameter to work fine, this setting must be specified. (8) useBodyEncodingForURI - see above, this makes tomcat use the body encoding also for the query string. Either (7) or (8) should be set. (9) For Jetty, -Dorg.mortbay.util.URI.charset=UTF-8 can influence the encoding used for parsing the query string. The difference is that by default they use UTF-8 in recent versions. -- Sergiu Dumitriu http://purl.org/net/sergiu/