views:

550

answers:

4

I am currently using Visual Studio 2008 for my ASP .NET application. I am trying to server an excel file via the Response object. The problem is I cannot seem to set the title of the file to Japanese. If I set it to Japanese file name, it gets returned as garbage character. I am using a Japanese IE browser in a Japanese WinXP.

Response.AppendHeader("Content-Type", "application/vnd.ms-excel");
Response.AddHeader("Content-Disposition", String.Format("attachment; filename=\"{0}\"", "日本語.xls"));

OR

Response.AddHeader("Content-Disposition", String.Format("attachment; filename=\"{0}\"", Server.HtmlEncode("日本語.xls")));

I already tried to change the encoding to Shift-JIS

Response.Charset = "Shift_JIS";

or

Response.Charset = "sjis";

Any ideas? Btw, I had the same problem with Visual Studio 2005 too.

+3  A: 

I'm not an ASP expert but have you tried recoding the filename using UrlEncode?

Response.AddHeader("Content-Disposition",
    System.Web.HttpUtility.UrlEncode(String.Format("attachment; filename=\"{0}\"", "日本語.xls")));
Joel Goodwin
I dont believe this. it worked.
Nassign
I saw this solution for java to prevent the opened file name from being set to unicode-encoded name in temporary folder.String fileName = "データ出力.txt";HttpServletResponse response = requestCondition.getResponse();response.setContentType("application/plain");String dFilename = new String(fileName.getBytes("Windows-31J"), "ISO-8859-1");response.setHeader("Content-Disposition","attachment; filename=" + dFilename);response.setCharacterEncoding("WINDOWS-932");
Nassign
+2  A: 

Response.Charset only concerns the body of the HTTP request. According to the HTTP spec, the headers are implicitly encoded as ISO-8859-1 - characters outside that encoding have to be MIME-encoded.

This is only logical - after all, the body encoding set by Response.Charset is itself specified in a header.

Michael Borgwardt
+1  A: 

Hi Nassign,

UrlPathEncode solved the garbage character issue, in my case, too.

But how did you fix the issue of opened file name being set to unicode-encoded name in temporary folder?

The solution you have mentioned is for Java, did it work in .NET?

It is not working in my case.

here is code

        'apply iso-8859-1 encoding

        Dim fileName as String = "在庫あり全商品を24時間以内に出荷.doc"
        Dim enc As Encoding = Encoding.GetEncoding("utf-8")
        Dim dec As Encoding = Encoding.GetEncoding("iso-8859-1")
        fileName = dec.GetString(enc.GetBytes(fileName))

        'Show Download Dialog box and Writting it on Client Side

        Response.ClearHeaders()
        Response.ContentType = corspBean.ContentType
        Response.AppendHeader("content-disposition", "attachment; filename=""" + fileName + """")
        Response.BinaryWrite(bytes)
        Response.End()
Vinod T. Patil
+1  A: 

I got it working, finally... :)

Use of System.Web.HttpUtility.UrlPathEncode solves the garbage problem but when you open the file, it shows unicode-uncoded names in the filename instead of actual japanese characters.(Well, this is the issue in IE7 and IE6, UrlPathEncode works fine with IE8.)

So, instead of using System.Web.HttpUtility.UrlPathEncode you should decode the filname using the encoding used for the Response header.

In .NET, by default the encoding of the Response header is utf-8, change it to iso-8859-1. Modify the web.config for the same, as shown below,

<globalization responseHeaderEncoding="iso-8859-1" .../>

And code would be,

    //apply Response header's encoding i.e. iso-8859-1 to the filename.
    Dim fileName as String = "在庫あり全商品を24時間以内に出荷.doc" 
    Dim enc As Encoding = Encoding.GetEncoding("shift_jis") 
    Dim dec As Encoding = Encoding.GetEncoding("iso-8859-1")
    fileName = dec.GetString(enc.GetBytes(fileName))

    //Show Download Dialog box and Writting it on Client Side.
    Response.ClearHeaders() 
    Response.ContentType = corspBean.ContentType 
    Response.AppendHeader("content-disposition", "attachment; filename=""" + fileName + """") 
    Response.BinaryWrite(bytes) 
    Response.End()

Now, one more important thing, I have wasted lot of time because of it, is this doesn't work on ASP.NET Development Server i.e the server you use to test/debug the web apps on your local machine. So, deploy the solution on the IIS and test from there. It works perfectly fine on IIS. (and IIS is the destiny of every ASP.NET app ;) so it doesn't matter if it works on ASP.NET Development Server or not)

Vinod T. Patil