2

我目前正在为我的 ASP .NET 应用程序使用 Visual Studio 2008。我正在尝试通过 Response 对象提供一个 excel 文件。问题是我似乎无法将文件的标题设置为日语。如果我将其设置为日文文件名，它将作为垃圾字符返回。我在日文 WinXP 中使用日文 IE 浏览器。

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

或者

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

我已经尝试将编码更改为 Shift-JIS

Response.Charset = "Shift_JIS";

或者

Response.Charset = "sjis";

有任何想法吗？顺便说一句，我对 Visual Studio 2005 也有同样的问题。

4

3 回答 3

4

我不是 ASP 专家，但您是否尝试过使用 UrlEncode 重新编码文件名？

Response.AddHeader("Content-Disposition",
    System.Web.HttpUtility.UrlEncode(String.Format("attachment; filename=\"{0}\"", "日本語.xls")));
于 2009-09-16T11:49:54.743 回答
2

Response.Charset仅涉及 HTTP 请求的主体。根据HTTP 规范，标头被隐式编码为 ISO-8859-1 - 编码之外的字符必须经过MIME 编码。

这只是合乎逻辑的 - 毕竟，设置的正文编码Response.Charset本身是在标头中指定的。

于 2009-09-16T13:21:53.767 回答
2

我得到它的工作，终于... :)

使用System.Web.HttpUtility.UrlPathEncode解决了垃圾问题，但是当您打开文件时，它在文件名中显示 unicode 未编码的名称，而不是实际的日文字符。（嗯，这是 IE7 和 IE6 中的问题，UrlPathEncode 在 IE8 中工作正常。）

因此，System.Web.HttpUtility.UrlPathEncode您应该使用用于响应标头的编码来解码文件名，而不是使用。

在 .NET 中，默认情况下 Response 标头的编码为 utf-8，将其更改为 iso-8859-1。修改web.config为相同，如下图，

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

代码是，

    //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()

现在，更重要的一件事，我因此浪费了很多时间，这在 ASP.NET 开发服务器（即用于在本地计算机上测试/调试 Web 应用程序的服务器）上不起作用。因此，在 IIS 上部署解决方案并从那里进行测试。它在 IIS 上运行良好。（而 IIS 是每个 ASP.NET 应用程序的命运；）所以它是否在 ASP.NET 开发服务器上工作并不重要）

于 2010-06-03T12:57:44.103 回答