(B
(BI've got a servlet that allows users to download files. I'm specifying (Bthe filename using the Content-Disposition header, and the charset using (Bthe Content-Type header. It all works lovely when the filename is English (B- but not with Japanese.
(B
(BI got the following to work with the latest version of IE:
(B
(B encodeFileName = URLEncoder.encode(fileName, "UTF-8");
(B response.setContentType("application/octet-stream"); // ie doesn't (Bseem to need the charset if it's utf-8
(B response.setHeader("Content-Disposition", "attachment; filename=\"" (B+ encodeFileName + "\"");
(B
(BThis, however, does not work with Netscape, nor does it work with older (Bversions of IE (the name displays as escaped unicode).
(BI need to support NE and IE (recent versions) on both Windows and Mac.
(B
(BI played around with the headers for Netscape and tried everything I could (Bthink of, to no avail.
(BI then used a packet sniffer to checkout the headers from a different (Bapplication (PHP based)
(Bthat works properly with Netscape - but even after I managed to get the (Bheaders for Content-Type AND Content-Disposition
(Bto match, it still didn't work (the action name shows up instead of the (Bjapanese file name).
(B
(BHere are the settings I used to get the headers to match - the file name (Bencoding matches byte for byte with the PHP app:
(B encodeFileName = new String(fileName.getBytes("Shift_JIS"), (B"ISO-8859-1");
(B response.setContentType("application/octet-stream; charset=Shift_JIS");
(B response.setHeader("Content-Disposition", "filename=" (B+ encodeFileName);
(B
(Bfor a file name PC$B4IM}(B.xls I get a filename=PC\212\307\227\235.xls in the (Bheader, which looks good to me.
(B
(BHere are the (relevant) headers from the PHP app, which works fine (it's (Bclosed source, so no luck there):
(BContent-Disposition: filename=PC\212\307\227\235.xls\r\n
(BContent-Type: application/octet-stream; charset=Shift_JIS\r\n
(B
(B
(B
(BI'm at a total loss. I've tried every charset, leaving OUT the charset, (Bsurrounding the filename in quotes, standing on my head... I stumbled (Bacross this tomcat bug (B(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24380) but the header (Bencoding appears to be coming out ok. I tried tomcat 4.0.6 for the hell (Bof it but that, of course, did not work either.
(B
(BIs it possible that NS is ignoring the specified charset, and trying to (Bget it from the data stream?
(BIf the headers are a match, what else could be happening? Are there other (Bheaders besides Content-Type and Content-Disposition that I should be (Bworrying about?
(B
(BOne (slightly) strange thing is that my packet sniffer seems to (Bautomatically recognize the PHP app's packets at HTTP, but not the servlet (Bapp's packets (have to click the "decode as html" button).
(B
(BAny help, ideas, suggestions, or prayers would be most welcome.
(B
(BThanks in advance,
(BDave
(B
(B
(B-- (B------------------------------------------------------------
(BADiRECT Corporation
$B%"%G%#%l%/%H3t<02q
(BITS$B3+H/K\It!!(B
(BDavid La France
(Bd.lafrance at adirect.jp
$B")(B103-0001$B!!El5~ETCf1{6hF|K\66>.EAGOD.(B12$BHV(B8$B9f!!(B
(BTEL $B!'(B03-5651-5700 $B!!(BFAX$B!'(B03-5651-5566
(BURL http://www.adirect.jp
(B
(B--PR----------------------------------------------------------------
$B!zJ*N.Hq:o8:$r$*9M$($J$i!V%"%G%#%l%/%H(B e3PL $B%*%Z%l!<%7%g%s%;%s%?! $B$/[EMAIL PROTECTED](B
(Bhttp://www.adirect.jp/logistics
$B!z1?DB!&5wN%7W;;$,B.$$!"4JC1!*!VEE;RA49q2_J*<+F0
$B!*(B
(Bhttp://www.adirect.jp/kilotei
(B
(B---------------------------------------------------------------------
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]
