Unfortunately, none of the below suggestions have helped.
Note, contrary to the mails of Jerome and Niels below, it's about the /
download/ action here.
I still get this with Curriki 1.8 branch (based on xwiki 1.8).
This now breaks at least one user.
Since there's no single possible thinkable way of knowing the
character set of an attachment unless reading it, I insist it is a bug
to add this charset to the header!
So guys, any way to remove this addition?
paul
Le 17-mars-09 à 13:42, Niels Mayer a écrit :
2008/12/28 Paul Libbrecht <paul(a)activemath.org>
can someone explain me what is the strategy to define the mime-type
of an attachment?
I see not configurable map nor any setter on the attachment types.
Is there any way I can enrich this or is it simply taking over the
mime-type provided the browser (which, too often, ends up being
application/octet-stream) ?
... [sergiu suggests "web.xml. Search for css, and do something
similar for your mimetypes."] ...
worked well to one point: the mime-type is added with a charset
parameter which is even iso-8859-1 although everything in my
environment is set to be utf-8.
Do I have a way to remove that charset for such downloads?
That would be the most sensible one.
Perhaps this is relevant:
to jerome(a)xwiki.com, XWiki Users <users(a)xwiki.org>
date Fri, Mar 13, 2009 at 5:48 PM
subject Re: [xwiki-users] [xwiki-devs] support for google sitemaps
and webmaster tools? (and why do xwiki RDF's give "unsupported file
format"?)
...
No matter what I did in my setup, I was getting
<?xml version="1.0" encoding="ISO-8859-1" ?>
The roller blog atom feed that *does* work correctly w/ google
sitemaps
returns:
<?xml version="1.0" encoding='utf-8'?>
I fixed this issue by running java with -Dfile.encoding=UTF-8 (note
the lowercase setting suggested in
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances
seems incorrect?). When that alone didn't work, I also added "-
Djavax.servlet.request.encoding=UTF-8-DjavaEncoding=UTF-8" which had
been suggested in solving this problem for other Tomcat users.
(Now I run java with the following options:-server -Xms160m -
Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -
Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -
DjavaEncoding=UTF-8 -Djava.awt.headless=true)
I also saw other suggestions to set LANG="en_US.UTF-8" in the
tomcat launching script... however, I'm not sure which of my changes
"did" it, but i believe that following two steps I'd forgotten||
skipped in
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Encoding
caused the correct encoding to be used:
(1) WEB-INF> diff web.xml.~1~ web.xml
23c23
< <param-value>ISO-8859-1</param-value>
---
<param-value>UTF-8</param-value>
(2) WEB-INF> diff xwiki.cfg.~2~
xwiki.cfg
29c29
< xwiki.encoding=ISO-8859-1
---
xwiki.encoding=UTF-8
With all of the above now reconfigured, I now get the correct output
for
http://nielsmayer.com/xwiki/bin/view/Main/WebRss?xpage=rdf :
<?xml version="1.0" encoding="UTF-8" ?>
...
-- Niels
http://nielsmayer.com
PS: Why not just have xwiki.cfg's default be:
'xwiki.encoding=UTF-8' ; likewise have web.xml's default for
com.xpn.xwiki.web.SetCharacterEncodingFilter's 'encoding' be UTF-8.
These encoding errors that oft go unnoticed are probably resulting
in a number of configuration errors, and perhaps other bug-reports
that aren't entirely valid, should they depend on encoding issues.