Paul Libbrecht wrote:
> 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?
>
It's added automatically. If we do:
response.setContentType("application/octet-stream"), 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.html
"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."
I think the only way to get rid of it is to provide your own
implementation of the ServletResponse class...
>
> Le 17-mars-09 à 13:42, Niels Mayer a écrit :
>
>> 2008/12/28 Paul Libbrecht <[email protected]>
>> 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 [email protected], XWiki Users <[email protected]>
>> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
