2009-09-16 12 views
2

J'utilise actuellement Visual Studio 2008 pour mon application ASP .NET. J'essaye de server un dossier d'Excel par l'intermédiaire de l'objet de réponse. Le problème est que je n'arrive pas à définir le titre du fichier en japonais. Si je le mets au nom de fichier japonais, il est renvoyé comme caractère poubelle. J'utilise un navigateur IE japonais dans un WinXP japonais.ASP .NET Télécharger le fichier avec le nom de fichier japonais

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

OU

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

Je l'ai déjà essayé de changer le codage Shift-JIS

Response.Charset = "Shift_JIS"; 

ou

Response.Charset = "sjis"; 

Toutes les idées? Btw, j'ai eu le même problème avec Visual Studio 2005 aussi.

Répondre

4

Je ne suis pas un expert ASP mais avez-vous essayé de recoder le nom de fichier en utilisant UrlEncode?

Response.AddHeader("Content-Disposition", 
    System.Web.HttpUtility.UrlEncode(String.Format("attachment; filename=\"{0}\"", "日本語.xls"))); 
+0

Je ne crois pas cela. ça a marché. – Nap

+0

J'ai vu cette solution pour Java pour empêcher le nom de fichier ouvert d'être défini sur un nom codé en Unicode dans le dossier temporaire. String fileName = "デ ー タ 出力 .txt"; Réponse HttpServletResponse = requestCondition.getResponse(); response.setContentType ("application/plain"); String dFilename = new Chaîne (nomFichier.getBytes ("Windows-31J"), "ISO-8859-1"); response.setHeader ("Content-Disposition", "pièce jointe; nomfichier =" + nomFichierD); response.setCharacterEncoding ("WINDOWS-932"); – Nap

2

Response.Charset ne concerne que le corps de la requête HTTP. Selon the HTTP spec, les en-têtes sont implicitement codés comme ISO-8859-1 - les caractères en dehors de ce codage doivent être MIME-encoded. Ceci est seulement logique - après tout, le codage corporel défini par Response.Charset est lui-même spécifié dans un en-tête.

2

Je l'ai travail, enfin ... :)

Utilisation de System.Web.HttpUtility.UrlPathEncode résout le problème des déchets, mais lorsque vous ouvrez le fichier, il affiche les noms UNICODE dans le nom du fichier non codé au lieu de caractères japonais réels. (Bien Donc, au lieu d'utiliser System.Web.HttpUtility.UrlPathEncode, vous devez décoder le nom de fichier en utilisant le codage utilisé pour l'en-tête de réponse.

Dans .NET, par défaut, le codage de l'en-tête de réponse est utf-8, remplacez-le par iso-8859-1. Modifier le fichier web.config pour le même, comme indiqué ci-dessous,

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

et le code serait,

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

Maintenant, une chose importante, j'ai perdu beaucoup de temps à cause de cela, est cela ne fonctionne pas sur ASP.NET Development Server c'est-à-dire le serveur que vous utilisez pour tester/déboguer les applications Web sur votre ordinateur local. Donc, déployez la solution sur l'IIS et testez à partir de là. Cela fonctionne parfaitement sur IIS. (et IIS est le destin de chaque application ASP.NET;) donc ce n'est pas grave si cela fonctionne sur ASP.NET Development Server ou non)