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

Question

Qual è la codifica predefinita che si dovrebbe usare per decodificare multipart/form-data se non viene fornito alcun charset? RFC2388 afferma:

4,5 Set di caratteri di testo in dati dei moduli

Ogni parte di un/form-data multipart si suppone di avere un Content tipo. Nel caso in cui un elemento del campo sia testo, il parametro charset 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 deve <eu> 100' in cui <eu> è il simbolo dell'Euro potrebbe avere i dati dei moduli 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 quel testo/sezione normale. Poiché non voglio applicare qualcosa che non è un comportamento standard, mi chiedo quale sia il comportamento previsto in questo caso. La RFC non sembra spiegare questo quindi sono un po 'perso.

Grazie!

Answer 1

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

3.7.1 canonica e di testo predefiniti

--snip--

Il parametro "charset" è usato con alcuni tipi di supporto per definire il set di caratteri (sezione 3.4) dei dati. Quando nessun parametro di charset esplicito viene fornito dal mittente, i sottotipi di tipo media del tipo "text" sono definiti per avere un valore charset predefinito di "ISO-8859-1" quando ricevuto tramite HTTP. I dati in set di caratteri diversi da "ISO-8859-1" o dai relativi sottoinsiemi DEVONO essere etichettati con un valore di set di caratteri appropriato. Vedere la sezione 3.4.1 per problemi di compatibilità.

Answer 2

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

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

Quindi, dove è specificato il set di caratteri? Per quanto posso dire dall'algoritmo di codifica, l'unica posizione è all'interno di una voce del data set del modulo denominata _charset_.

Se il modulo non ha un input nascosto denominato _charset_, cosa succede? Ho provato questo in Chrome 28, inviando un modulo codificato in UTF-8 e uno in ISO-8859-1 e ispezionando le intestazioni e il carico utile inviati, e non vedo il set di caratteri fornito da nessuna parte (anche se la codifica del testo cambia decisamente). Se includo un campo vuoto _charset_ nel modulo, Chrome lo inserisce con il tipo di set di caratteri corretto. Immagino che qualsiasi codice lato server debba cercare il campo _charset_ per capirlo?

mi sono imbattuto in questo problema durante la scrittura di un'estensione Chrome che utilizza XMLHttpRequest.send di un oggettoformdata, che always gets encoded in UTF-8 no matter what the source document encoding is.

Let corpo dell'entità richiesta essere il risultato di esecuzione dell'algoritmo di codifica multipart/form-data con dati come dati di modulo impostati e con utf-8 come la codifica dei caratteri esplicito.

Il tipo mime è la concatenazione di "multipart/form-data;", un carattere U + 0020 SPACE, "boundary =" e la stringa di limite multipart/form-data generata dalla codifica multipart/form-data algoritmo.

Come ho scoperto in precedenza, charset = utf-8 non è specificato da nessuna parte nella richiesta POST, a meno che non si include un campo vuoto _charset_ nella forma, che in questo caso verrà automaticamente ottenere popolato da "UTF- 8" .

Questa è la mia comprensione dello stato delle cose. Accolgo con favore eventuali correzioni alle mie ipotesi!

Answer 3

Grazie alla spiegazione dettagliata di @owlman.

Basta un po 'di informazioni qui:

Upload richiesta payload frammento:

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

Se "xxx.txt" ha un certo carattere UNICODE in esso utilizzando codifica UTF-8, resina (come di 4,0. 40) non può decodificarlo correttamente, ma Jetty (9.x) può.

Penso che il motivo per il comportamento di Resin sia che il tipo di contenuto non specifica alcuna codifica, quindi Resin decodifica il nome del file usando "ISO8859-1", che potrebbe risultare in caratteri distorti.

ho fatto un po '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.