multipart/form-data, quel est le jeu de caractères par défaut pour les champs ?

Question

quel est le codage par défaut à utiliser pour décoder les données multipart/form si aucun jeu de caractères n'est donné ?La RFC2388 déclare :

4.5 Jeu de caractères de texte dans les données du formulaire

Chaque partie d’un multipart/form-data est censée avoir un type.Dans le cas où un élément de champ est du texte, le jeu de caractères indique l’encodage des caractères utilisé.

Par exemple, un formulaire avec un champ de texte dans lequel un utilisateur a tapé « Joe doit » <eu>100' où <eu> est le symbole de l’euro peut avoir des données de formulaire renvoyées comme:

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

Joe owes =80100.
--AaB03x

Dans mon cas, le jeu de caractères n'est pas défini et je ne sais pas comment décoder les données dans cette section texte/plaine.Comme je ne veux pas imposer quelque chose qui n'est pas un comportement standard, je demande quel est le comportement attendu dans ce cas.La RFC ne semble pas expliquer cela donc je suis un peu perdu.

Merci!

Answer 1

Le jeu de caractères par défaut pour HTTP 1.1 est ISO-8859-1 (Latin1), Je suppose que cela vaut aussi ici.

  

3.7.1 et Canonicalisation texte par défaut

- snip -

  

Le paramètre « charset » est utilisé avec certains types de médias pour définir le jeu de caractères (section 3.4) des données. Lorsque aucun paramètre charset explicite est fourni par l'expéditeur, les sous-types de médias du type « texte » sont définis pour avoir une valeur charset par défaut de « ISO-8859-1 » lors de la réception via HTTP. Les données de jeux de caractères autres que « ISO-8859-1 » ou ses sous-ensembles doivent être étiquetés avec une valeur charset appropriée. Voir la section 3.4.1 pour des problèmes de compatibilité.

Answer 2

Cela a apparemment changé dans HTML5 (voir http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data).

Les parties de la ressource multipart/form-data générée qui correspondent à des champs non-fichiers ne doivent pas avoir d'en-tête Content-Type spécifié.

Alors, où le jeu de caractères est-il spécifié ?Pour autant que je sache d'après l'algorithme de codage, le seul endroit est dans une entrée d'ensemble de données de formulaire nommée _charset_.

Si votre formulaire n'a pas d'entrée masquée nommée _charset_, ce qui se produit?J'ai testé cela dans Chrome 28, en envoyant un formulaire codé en UTF-8 et un en ISO-8859-1 et en inspectant les en-têtes et la charge utile envoyés, et je ne vois aucun jeu de caractères donné nulle part (même si l'encodage du texte change définitivement ).Si j'inclus un vide _charset_ champ du formulaire, Chrome le remplit avec le type de jeu de caractères correct.Je suppose que tout code côté serveur doit rechercher cela _charset_ terrain pour le comprendre ?

J'ai rencontré ce problème lors de l'écriture d'une extension Chrome qui utilise XMLHttpRequest.send d'un Données de formulaire objet, qui est toujours encodé en UTF-8, quel que soit l'encodage du document source.

Supposons que le corps de l'entité de requête soit le résultat de l'exécution de l'algorithme de codage multipart/form-data avec data comme ensemble de données de formulaire et avec utf-8 comme codage de caractères explicite.

Soit le type MIME la concaténation de "multipart/form-data;", d'un caractère ESPACE U+0020, de "boundary=" et de la chaîne de limite multipart/form-data générée par l'algorithme de codage multipart/form-data.

Comme je l'ai trouvé plus tôt, charset=utf-8 n'est spécifié nulle part dans la requête POST, sauf si vous incluez un champ vide _charset_ champ du formulaire, qui dans ce cas sera automatiquement renseigné avec "utf-8".

C'est ma compréhension de l'état des choses.Je suis ouvert à toute correction de mes hypothèses !

Answer 3

Merci à l'explication détaillée par @owlman.

Juste un peu plus d'info ici:

Télécharger fragment de charge utile de la demande:

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

Si "xxx.txt" a un certain caractère dans UNICODE à l'aide de l'encodage UTF-8, résine (au 4.0.40) ne peut pas décoder correctement, mais la jetée (9.x) peut.

Je pense que la raison du comportement de résine est que le type de contenu ne spécifie aucun codage, de sorte que la résine decode nom de fichier en utilisant « ISO8859-1 », ce qui peut entraîner des caractères altérés.

je l'ai fait googling:

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

Il semble que le comportement de résine est selon Servlet Spec 2.3

Et je ne peux pas trouver les paramètres de http://www.caucho.com /resin-4.0/reference.xtp qui peut changer ce comportement pour la résine.