Come codificare il parametro nome file dell'intestazione Content-Disposition in HTTP?

Le applicazioni Web che desiderano forzare il download di una risorsa anziché renderizzare direttamente in un browser Web emettono Content-Dispositionun'intestazione nella risposta HTTP del modulo:

Content-Disposition: attachment; filename=FILENAME

Il filenameparametro può essere utilizzato per suggerire un nome per il file in cui la risorsa viene scaricata dal browser. RFC 2183 (Content-Disposition), tuttavia, afferma nella sezione 2.3 (Il parametro Nome file) che il nome del file può usare solo caratteri US-ASCII:

La grammatica corrente [RFC 2045] limita i valori dei parametri (e quindi i nomi dei file di Content-Disposition) a US-ASCII. Riconosciamo la grande desiderabilità di consentire insiemi di caratteri arbitrari nei nomi dei file, ma è oltre lo scopo di questo documento definire i meccanismi necessari.

Esistono prove empiriche, tuttavia, che i browser Web più popolari oggi sembrano consentire caratteri non US-ASCII ma (per la mancanza di uno standard) non sono d'accordo sullo schema di codifica e sulla specifica del set di caratteri del nome del file. La domanda è quindi: quali sono i vari schemi e codifiche utilizzati dai browser più diffusi se il nome del file "naïvefile" (senza virgolette e dove la terza lettera è U + 00EF) deve essere codificato nell'intestazione Content-Disposition?

Ai fini di questa domanda, i browser più diffusi sono:

• Firefox
• Internet Explorer
• Safari
• Google Chrome
• musica lirica

Si discute di questo, compresi i collegamenti ai test del browser e la compatibilità con le versioni precedenti, nella proposta RFC 5987 , "Set di caratteri e codifica del linguaggio per i parametri del campo di intestazione HTTP (Hypertext Transfer Protocol)".

RFC 2183 indica che tali intestazioni dovrebbero essere codificate secondo RFC 2184 , che era obsoleto da RFC 2231 , coperto dal progetto RFC sopra.

So che questo è un vecchio post, ma è ancora molto pertinente. Ho scoperto che i browser moderni supportano rfc5987, che consente la codifica utf-8, codificata in percentuale (codifica url). Quindi Naïve file.txt diventa:

Content-Disposition: attachment; filename*=UTF-8''Na%C3%AFve%20file.txt

Safari (5) non supporta questo. Invece dovresti usare lo standard Safari per scrivere il nome del file direttamente nell'intestazione codificata utf-8:

Content-Disposition: attachment; filename=Naïve file.txt

IE8 e precedenti non lo supportano e devi usare lo standard IE di codifica utf-8, codificato in percentuale:

Content-Disposition: attachment; filename=Na%C3%AFve%20file.txt

In ASP.Net utilizzo il seguente codice:

string contentDisposition;
if (Request.Browser.Browser == "IE" && (Request.Browser.Version == "7.0" || Request.Browser.Version == "8.0"))
    contentDisposition = "attachment; filename=" + Uri.EscapeDataString(fileName);
else if (Request.Browser.Browser == "Safari")
    contentDisposition = "attachment; filename=" + fileName;
else
    contentDisposition = "attachment; filename*=UTF-8''" + Uri.EscapeDataString(fileName);
Response.AddHeader("Content-Disposition", contentDisposition);

Ho testato quanto sopra usando IE7, IE8, IE9, Chrome 13, Opera 11, FF5, Safari 5.

Aggiornamento novembre 2013:

Ecco il codice che attualmente uso. Devo ancora supportare IE8, quindi non posso liberarmi della prima parte. Si scopre che i browser su Android utilizzano il download manager Android integrato e non possono analizzare in modo affidabile i nomi dei file in modo standard.

string contentDisposition;
if (Request.Browser.Browser == "IE" && (Request.Browser.Version == "7.0" || Request.Browser.Version == "8.0"))
    contentDisposition = "attachment; filename=" + Uri.EscapeDataString(fileName);
else if (Request.UserAgent != null && Request.UserAgent.ToLowerInvariant().Contains("android")) // android built-in download manager (all browsers on android)
    contentDisposition = "attachment; filename=\"" + MakeAndroidSafeFileName(fileName) + "\"";
else
    contentDisposition = "attachment; filename=\"" + fileName + "\"; filename*=UTF-8''" + Uri.EscapeDataString(fileName);
Response.AddHeader("Content-Disposition", contentDisposition);

Quanto sopra ora testato in IE7-11, Chrome 32, Opera 12, FF25, Safari 6, usando questo nome file per il download: 你好 abcABCæøåÆØÅäöüïëëîâéíáóúýñ½§! # ¤% & () = `@ £ $ € {[]} + ´¨ ^ ~ '-_,;. txt

Su IE7 funziona per alcuni personaggi ma non per tutti. Ma a chi importa di IE7 al giorno d'oggi?

Questa è la funzione che utilizzo per generare nomi di file sicuri per Android. Nota che non so quali personaggi sono supportati su Android ma ho testato che questi funzionano sicuramente:

private static readonly Dictionary<char, char> AndroidAllowedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ._-+,@£$€!½§~'=()[]{}0123456789".ToDictionary(c => c);
private string MakeAndroidSafeFileName(string fileName)
{
    char[] newFileName = fileName.ToCharArray();
    for (int i = 0; i < newFileName.Length; i++)
    {
        if (!AndroidAllowedChars.ContainsKey(newFileName[i]))
            newFileName[i] = '_';
    }
    return new string(newFileName);
}

@TomZ: ho testato in IE7 e IE8 e si è scoperto che non avevo bisogno di sfuggire all'apostrofo ('). Hai un esempio di dove fallisce?

@Dave Van den Eynde: Combinando i due nomi di file su una riga secondo RFC6266 funziona tranne Android e IE7 + 8 e ho aggiornato il codice per riflettere questo. Grazie per il suggerimento

@Thilo: nessuna idea di GoodReader o di qualsiasi altro non browser. Potresti avere un po 'di fortuna usando l'approccio Android.

@Alex Zhukovskiy: non so perché, ma come discusso su Connect non sembra funzionare molto bene.

• Non esiste un modo interoperabile per codificare nomi non ASCII Content-Disposition. La compatibilità del browser è un casino .

• La sintassi teoricamente corretta per l'uso di UTF-8 in Content-Dispositionè molto strana: filename*=UTF-8''foo%c3%a4(sì, questo è un asterisco e nessuna virgoletta tranne una virgoletta singola vuota nel mezzo)

• Questa intestazione è un po 'non abbastanza standard (la specifica HTTP / 1.1 ne riconosce l'esistenza , ma non richiede ai client di supportarla).

Esiste un'alternativa semplice e molto robusta: utilizzare un URL che contiene il nome file desiderato .

Quando il nome dopo l'ultima barra è quello che desideri, non hai bisogno di intestazioni extra!

Questo trucco funziona:

/real_script.php/fake_filename.doc

E se il tuo server supporta la riscrittura degli URL (ad es. mod_rewriteIn Apache), puoi nascondere completamente la parte dello script.

I caratteri negli URL devono essere in UTF-8, codificati byte per byte:

/mot%C3%B6rhead   # motörhead

RFC 6266 descrive " Uso del campo di intestazione di disposizione del contenuto nel protocollo di trasferimento ipertestuale (HTTP) ". Citando da quello:

6. Considerazioni sull'internazionalizzazione

Il filename*parametro " " ( Sezione 4.3 ), utilizzando la codifica definita in [ RFC5987 ], consente al server di trasmettere caratteri al di fuori del set di caratteri ISO-8859-1 e di specificare facoltativamente la lingua in uso.

E nella loro sezione di esempi :

Questo esempio è uguale a quello sopra, ma aggiungendo il parametro "nome file" per la compatibilità con i programmi utente che non implementano RFC 5987 :

Content-Disposition: attachment;
                     filename="EURO rates";
                     filename*=utf-8''%e2%82%ac%20rates

Nota: quegli agenti utente che non supportano la codifica RFC 5987 ignorano " filename*" quando si verifica dopo " filename".

In Appendice D c'è anche una lunga lista di suggerimenti per aumentare l'interoperabilità. Indica anche un sito che confronta le implementazioni . I test all-pass correnti adatti per nomi di file comuni includono:

• attwithisofnplain : nome file ISO-8859-1 semplice con virgolette doppie e senza codifica. Ciò richiede un nome file che sia tutto ISO-8859-1 e che non contenga segni di percentuale, almeno non davanti a cifre esadecimali.
• attfnboth : due parametri nell'ordine sopra descritto. Dovrebbe funzionare per la maggior parte dei nomi di file sulla maggior parte dei browser, anche se IE8 utilizzerà il filenameparametro " ".

Quel RFC 5987 a sua volta fa riferimento a RFC 2231 , che descrive il formato effettivo. 2231 è principalmente per la posta e 5987 ci dice quali parti possono essere utilizzate anche per le intestazioni HTTP. Non confonderlo con le intestazioni MIME utilizzate all'interno di un corpomultipart/form-data HTTP , regolato da RFC 2388 ( in particolare la sezione 4.4 ) e dalla bozza HTML 5 .

Il seguente documento collegato dal progetto di RFC menzionato da Jim nella sua risposta affronta ulteriormente la domanda e merita sicuramente una nota diretta qui:

Casi di test per intestazione di disposizione del contenuto HTTP e codifica RFC 2231/2047

in asp.net mvc2 uso qualcosa del genere:

return File(
    tempFile
    , "application/octet-stream"
    , HttpUtility.UrlPathEncode(fileName)
    );

Immagino che se non usi mvc (2) potresti semplicemente codificare il nome del file usando

HttpUtility.UrlPathEncode(fileName)

Inserisci il nome del file tra virgolette. Risolto il problema per me Come questo:

Content-Disposition: attachment; filename="My Report.doc"

http://kb.mozillazine.org/Filenames_with_spaces_are_truncated_upon_download

Ho testato più opzioni. I browser non supportano le specifiche e agiscono diversamente, credo che le doppie virgolette siano l'opzione migliore.

Uso i seguenti frammenti di codice per la codifica (supponendo che fileName contenga il nome file e l'estensione del file, ovvero: test.txt):

PHP:

if ( strpos ( $_SERVER [ 'HTTP_USER_AGENT' ], "MSIE" ) > 0 )
{
     header ( 'Content-Disposition: attachment; filename="' . rawurlencode ( $fileName ) . '"' );
}
else
{
     header( 'Content-Disposition: attachment; filename*=UTF-8\'\'' . rawurlencode ( $fileName ) );
}

Giava:

fileName = request.getHeader ( "user-agent" ).contains ( "MSIE" ) ? URLEncoder.encode ( fileName, "utf-8") : MimeUtility.encodeWord ( fileName );
response.setHeader ( "Content-disposition", "attachment; filename=\"" + fileName + "\"");

Nell'API Web ASP.NET, url codifico il nome del file:

public static class HttpRequestMessageExtensions
{
    public static HttpResponseMessage CreateFileResponse(this HttpRequestMessage request, byte[] data, string filename, string mediaType)
    {
        HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
        var stream = new MemoryStream(data);
        stream.Position = 0;

        response.Content = new StreamContent(stream);

        response.Content.Headers.ContentType = 
            new MediaTypeHeaderValue(mediaType);

        // URL-Encode filename
        // Fixes behavior in IE, that filenames with non US-ASCII characters
        // stay correct (not "_utf-8_.......=_=").
        var encodedFilename = HttpUtility.UrlEncode(filename, Encoding.UTF8);

        response.Content.Headers.ContentDisposition =
            new ContentDispositionHeaderValue("attachment") { FileName = encodedFilename };
        return response;
    }
}

Ho testato il seguente codice in tutti i principali browser, inclusi gli Explorer più vecchi (tramite la modalità di compatibilità), e funziona bene ovunque:

$filename = $_GET['file']; //this string from $_GET is already decoded
if (strstr($_SERVER['HTTP_USER_AGENT'],"MSIE"))
  $filename = rawurlencode($filename);
header('Content-Disposition: attachment; filename="'.$filename.'"');

Ho finito con il seguente codice nel mio script "download.php" (basato su questo post sul blog e su questi casi di test ).

$il1_filename = utf8_decode($filename);
$to_underscore = "\"\\#*;:|<>/?";
$safe_filename = strtr($il1_filename, $to_underscore, str_repeat("_", strlen($to_underscore)));

header("Content-Disposition: attachment; filename=\"$safe_filename\""
.( $safe_filename === $filename ? "" : "; filename*=UTF-8''".rawurlencode($filename) ));

Questo utilizza il modo standard di nomefile = "..." purché vengano usati solo caratteri iso-latini1 e "sicuri"; in caso contrario, aggiunge il nome file * = UTF-8 '' codificato in url. Secondo questo specifico test case , dovrebbe funzionare da MSIE9 in su, e su FF, Chrome, Safari recenti; nella versione MSIE inferiore, dovrebbe offrire il nome file contenente la versione ISO8859-1 del nome file, con caratteri di sottolineatura sui caratteri non inclusi in questa codifica.

Nota finale: il massimo. la dimensione per ciascun campo di intestazione è 8190 byte su apache. UTF-8 può contenere fino a quattro byte per carattere; dopo rawurlencode, è x3 = 12 byte per un carattere. Abbastanza inefficiente, ma teoricamente dovrebbe essere possibile avere più di 600 "sorrisi"% F0% 9F% 98% 81 nel nome del file.

Se stai usando un backend nodejs puoi usare il seguente codice che ho trovato qui

var fileName = 'my file(2).txt';
var header = "Content-Disposition: attachment; filename*=UTF-8''" 
             + encodeRFC5987ValueChars(fileName);

function encodeRFC5987ValueChars (str) {
    return encodeURIComponent(str).
        // Note that although RFC3986 reserves "!", RFC5987 does not,
        // so we do not need to escape it
        replace(/['()]/g, escape). // i.e., %27 %28 %29
        replace(/\*/g, '%2A').
            // The following are not required for percent-encoding per RFC5987, 
            // so we can allow for a little better readability over the wire: |`^
            replace(/%(?:7C|60|5E)/g, unescape);
}

In PHP questo è stato per me (supponendo che il nome del file sia codificato UTF8):

header('Content-Disposition: attachment;'
    . 'filename="' . addslashes(utf8_decode($filename)) . '";'
    . 'filename*=utf-8\'\'' . rawurlencode($filename));

Testato su IE8-11, Firefox e Chrome.
Se il browser è in grado di interpretare il nome file * = utf-8 utilizzerà la versione UTF8 del nome file, altrimenti utilizzerà il nome file decodificato. Se il tuo nome file contiene caratteri che non possono essere rappresentati in ISO-8859-1, ti consigliamo di utilizzare iconvinvece.

Solo un aggiornamento dal momento che stavo provando tutte queste cose oggi in risposta a un problema del cliente

• Ad eccezione di Safari configurato per il giapponese, tutti i browser testati dai nostri clienti hanno funzionato meglio con nomefile = testo.pdf - dove testo è un valore cliente serializzato da ASP.Net/IIS in utf-8 senza codifica URL. Per qualche motivo, Safari configurato per l'inglese accetterebbe e salverebbe correttamente un file con nome giapponese utf-8 ma lo stesso browser configurato per il giapponese salverebbe il file con i caratteri utf-8 non interpretati. Tutti gli altri browser testati sembrano funzionare al meglio / bene (indipendentemente dalla configurazione della lingua) con il nome file utf-8 codificato senza codifica URL.
• Non riuscivo a trovare un unico browser attuazione Rfc5987 / 8187 a tutti . Ho provato con le ultime versioni di Chrome, Firefox, più IE 11 e Edge. Ho provato a impostare l'intestazione solo con il nome file * = utf-8''texturlencoded.pdf, impostandolo con entrambi i nomi file = text.pdf; filename * = utf-8''texturlencoded.pdf. Nessuna delle funzionalità di Rfc5987 / 8187 sembrava essere stata elaborata correttamente in nessuno dei precedenti.

PHP framework Symfony 4 ha $filenameFallbackin HeaderUtils::makeDisposition. Puoi esaminare questa funzione per i dettagli: è simile alle risposte sopra.

Esempio di utilizzo:

$filenameFallback = preg_replace('#^.*\.#', md5($filename) . '.', $filename);
$disposition = $response->headers->makeDisposition(ResponseHeaderBag::DISPOSITION_ATTACHMENT, $filename, $filenameFallback);
$response->headers->set('Content-Disposition', $disposition);

Soluzione ASP classica

La maggior parte dei browser moderni supporta il passaggio Filenamecome UTF-8adesso, ma come nel caso di una soluzione di caricamento file che uso basata su FreeASPUpload.Net (il sito non esiste più, il collegamento punta a archive.org ) non funzionerebbe come l'analisi del binario si basava sulla lettura di stringhe con codifica ASCII a byte singolo, che funzionava bene quando si passavano i dati con codifica UTF-8 fino ad arrivare ai caratteri che ASCII non supporta.

Tuttavia sono stato in grado di trovare una soluzione per ottenere il codice per leggere e analizzare il file binario come UTF-8.

Public Function BytesToString(bytes)    'UTF-8..
  Dim bslen
  Dim i, k , N 
  Dim b , count 
  Dim str

  bslen = LenB(bytes)
  str=""

  i = 0
  Do While i < bslen
    b = AscB(MidB(bytes,i+1,1))

    If (b And &HFC) = &HFC Then
      count = 6
      N = b And &H1
    ElseIf (b And &HF8) = &HF8 Then
      count = 5
      N = b And &H3
    ElseIf (b And &HF0) = &HF0 Then
      count = 4
      N = b And &H7
    ElseIf (b And &HE0) = &HE0 Then
      count = 3
      N = b And &HF
    ElseIf (b And &HC0) = &HC0 Then
      count = 2
      N = b And &H1F
    Else
      count = 1
      str = str & Chr(b)
    End If

    If i + count - 1 > bslen Then
      str = str&"?"
      Exit Do
    End If

    If count>1 then
      For k = 1 To count - 1
        b = AscB(MidB(bytes,i+k+1,1))
        N = N * &H40 + (b And &H3F)
      Next
      str = str & ChrW(N)
    End If
    i = i + count
  Loop

  BytesToString = str
End Function

Il merito va al puro caricamento di file ASP implementando la BytesToString()funzione include_aspuploader.aspnel mio codice sono stato in grado di far UTF-8funzionare i nomi dei file.

link utili

• Multipart / form-data e UTF-8 in un'applicazione ASP Classic

• Differenze di formato Unicode, UTF, ASCII, ANSI

Abbiamo riscontrato un problema simile in un'applicazione Web e abbiamo finito per leggere il nome file dall'HTML <input type="file">e impostarlo nel modulo con codifica URL in un nuovo HTML <input type="hidden">. Ovviamente abbiamo dovuto rimuovere il percorso come "C: \ fakepath \" restituito da alcuni browser.

Naturalmente questo non risponde direttamente alla domanda dei PO, ma può essere una soluzione per gli altri.

Normalmente codifico URL (con% xx) i nomi dei file e sembra funzionare in tutti i browser. Potresti voler fare comunque dei test.