multipart/form-data, qual è il set di caratteri predefinito per i campi?

Question

qual è la codifica predefinita da utilizzare per decodificare multipart/form-data se non viene fornito alcun set di caratteri?RFC2388 afferma:

4.5 Insieme di caratteri del testo nei dati del modulo

Ogni parte di un multipart/forma di forma dovrebbe avere un tipo di contenuto.Nel caso in cui un elemento di campo sia testo, il parametro di chatset per il testo indica la codifica dei caratteri utilizzata.

Ad esempio, un modulo con un campo di testo in cui un utente ha digitato "Joe deveu003Ceu> 100 'doveu003Ceu> è il simbolo euro potrebbe avere i dati del modulo restituiti come:

--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable>>

Joe owes =80100.
--AaB03x

Nel mio caso, il set di caratteri non è impostato e non so come decodificare i dati all'interno di quella sezione di testo/semplice.Poiché non voglio imporre qualcosa che non sia un comportamento standard, chiedo quale sia il comportamento previsto in questo caso.La RFC non sembra spiegarlo, quindi sono un po' perso.

Grazie!

Answer 1

Il set di caratteri di default per HTTP 1.1 è ISO-8859-1 (Latino 1), direi che questo vale anche qui.

  

3.7.1 canonica e delle impostazioni predefinite di testo

- snip -

  

Il parametro "charset" è usato con alcuni tipi di supporto per definire il set di caratteri (sezione 3.4) dei dati. Quando nessun parametro esplicito charset è fornito dal mittente, sottotipi multimediali di tipo "testo" sono definiti per avere un valore charset di default di "ISO-8859-1" quando ha ricevuto via HTTP. I dati nel set di caratteri diverso da "ISO-8859-1" o dei suoi sottoinsiemi devono essere etichettati con un valore charset appropriata. Vedere la sezione 3.4.1 per problemi di compatibilità.

Answer 2

Questo apparentemente è cambiato in HTML5 (vedi http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data).

Le parti della risorsa multipart/form-data generata che corrispondono a campi non file non devono avere un'intestazione Content-Type specificata.

Allora dove è specificato il set di caratteri?Per quanto ne so dall'algoritmo di codifica, l'unico posto è all'interno della voce del set di dati del modulo denominata _set di caratteri_.

Se il tuo modulo non ha un input nascosto denominato _set di caratteri_, che succede?L'ho testato in Chrome 28, inviando un modulo codificato in UTF-8 e uno in ISO-8859-1 e controllando le intestazioni e il payload inviati, e non vedo il set di caratteri fornito da nessuna parte (anche se la codifica del testo cambia decisamente ).Se includo un file vuoto _set di caratteri_ campo nel modulo, Chrome lo popola con il tipo di set di caratteri corretto.Immagino che qualsiasi codice lato server debba cercarlo _set di caratteri_ campo per capirlo?

Ho riscontrato questo problema durante la scrittura di un'estensione di Chrome che utilizza XMLHttpRequest.send di a FormData oggetto, che viene sempre codificato in UTF-8, indipendentemente dalla codifica del documento sorgente.

Lascia che il corpo dell'entità della richiesta sia il risultato dell'esecuzione dell'algoritmo di codifica multipart/form-data con i dati come set di dati del modulo e con utf-8 come codifica dei caratteri esplicita.

Lascia che il tipo mime sia la concatenazione di "multipart/form-data;", un carattere SPAZIO U+0020, "boundary=" e la stringa di confine multipart/form-data generata dall'algoritmo di codifica multipart/form-data.

Come ho scoperto in precedenza, charset=utf-8 non è specificato da nessuna parte nella richiesta POST, a meno che non si includa un campo vuoto _set di caratteri_ campo nel modulo, che in questo caso verrà automaticamente popolato con "utf-8".

Questa è la mia comprensione dello stato delle cose.Accetto volentieri eventuali correzioni alle mie ipotesi!

Answer 3

Grazie alla spiegazione dettagliata da @owlman.

Basta un po 'di informazioni qui:

Carica frammento richiesta payload:

------WebKitFormBoundarydZAwJIasnBbGaUqM
Content-Disposition: form-data; name="file"; filename="xxx.txt"
Content-Type: text/plain

Se "xxx.txt" abbia qualche char UNICODE in utilizzando codifica UTF-8, resina (come del 4.0.40) non può decodificare correttamente, ma Jetty (9.x) can.

Penso che la ragione per il comportamento di resina è che il Content-type non specifica alcuna codifica, in modo da resina nome del file decodifica usando "ISO8859-1", che può tradursi in caratteri incomprensibili.

ho fatto qualche googling:

https : //mail-archives.apache.org/mod_mbox/struts-user/200310.mbox/%3C3FA0395B.1080209@kumachan.net.nz%3E

Sembra che il comportamento di resina è in base alle Servlet Spec 2.3

E non riesco a trovare alcuna impostazione da http://www.caucho.com /resin-4.0/reference.xtp che può cambiare questo comportamento per resina.