Aller au contenu principal

5.1. Noms et valeurs de champs non ASCII

5.1. Non-ASCII Field Names and Values​

🇬🇧 英文原文​

Normally, MIME header fields in multipart bodies are required to consist only of 7-bit data in the US-ASCII character set. While [RFC2388] suggested that non-ASCII field names be encoded according to the method in [RFC2047], this practice doesn't seem to have been followed widely.

This specification makes three sets of recommendations for three different states of workflow.

🇫🇷 Traduction française​

Normalement, les champs d'en-tête MIME dans les corps multipart doivent être constitués uniquement de données 7 bits du jeu de caractères US-ASCII. Bien que [RFC2388] ait suggéré que les noms de champs non ASCII soient encodés selon la méthode de [RFC2047], cette pratique ne semble pas avoir été largement suivie.

Cette spécification formule trois ensembles de recommandations pour trois états différents de flux de travail.

5.1.1. Avoid Non-ASCII Field Names​

🇬🇧 英文原文​

For broadest interoperability with existing deployed software, those creating forms SHOULD avoid non-ASCII field names. This should not be a burden because, in general, the field names are not visible to users. The field names in the underlying need not match what the user sees on the screen.

If non-ASCII field names are unavoidable, form or application creators SHOULD use UTF-8 uniformly. This will minimize interoperability problems.

🇫🇷 Traduction française​

Pour une interopérabilité maximale avec les logiciels déployés existants, ceux qui créent des formulaires DEVRAIENT éviter les noms de champs non ASCII (SHOULD). Cela ne devrait pas être un fardeau car, en général, les noms de champs ne sont pas visibles pour les utilisateurs. Les noms de champs sous-jacents n'ont pas besoin de correspondre à ce que l'utilisateur voit à l'écran.

Si les noms de champs non ASCII sont inévitables, les créateurs de formulaires ou d'applications DEVRAIENT utiliser UTF-8 de manière uniforme (SHOULD). Cela minimisera les problèmes d'interopérabilité.

5.1.2. Interpreting Forms and Creating multipart/form-data Data​

🇬🇧 英文原文​

Some applications of this specification will supply a character encoding to be used for interpretation of the multipart/form-data body. In particular, HTML 5 [W3C.REC-html5-20141028] uses :

  • the content of a "charset" field, if there is one;
  • the value of an accept-charset attribute of the <form> element, if there is one;
  • the character encoding of the document containing the form, if it is US-ASCII compatible;
  • otherwise, UTF-8.

Call this value the form-charset. Any text, whether field name, field value, or ("text/plain") form data that uses characters outside the ASCII range MAY be represented directly encoded in the form-charset.

🇫🇷 Traduction française​

Certaines applications de cette spécification fourniront un encodage de caractères à utiliser pour l'interprétation du corps multipart/form-data. En particulier, HTML 5 [W3C.REC-html5-20141028] utilise :

  • le contenu d'un champ "charset", s'il en existe un ;
  • la valeur d'un attribut accept-charset de l'élément <form>, s'il en existe un ;
  • l'encodage de caractères du document contenant le formulaire, s'il est compatible US-ASCII ;
  • sinon, UTF-8.

Appelons cette valeur form-charset. Tout texte, qu'il s'agisse d'un nom de champ, d'une valeur de champ ou de données de formulaire ("text/plain") utilisant des caractères en dehors de la plage ASCII PEUT être représenté directement encodé dans le form-charset (MAY).

5.1.3. Parsing and Interpreting Form Data​

🇬🇧 英文原文​

While this specification provides guidance for the creation of multipart/form-data, parsers and interpreters should be aware of the variety of implementations. File systems differ as to whether and how they normalize Unicode names, for example. The matching of form elements to form-data parts may rely on a fuzzier match. In particular, some multipart/form-data generators might have followed the previous advice of [RFC2388] and used the "encoded-word" method of encoding non-ASCII values, as described in [RFC2047] :

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

Others have been known to follow [RFC2231], to send unencoded UTF-8, or even to send strings encoded in the form-charset.

For this reason, interpreting multipart/form-data (even from conforming generators) may require knowing the charset used in form encoding in cases where the charset field value or a charset parameter of a "text/plain" Content-Type header field is not supplied.

🇫🇷 Traduction française​

Bien que cette spécification fournisse des conseils pour la création de multipart/form-data, les analyseurs et interpréteurs doivent être conscients de la variété des implémentations. Les systèmes de fichiers diffèrent quant à savoir s'ils normalisent et comment ils normalisent les noms Unicode, par exemple. La correspondance des éléments de formulaire aux parties de données de formulaire peut reposer sur une correspondance plus floue. En particulier, certains générateurs multipart/form-data ont peut-être suivi le conseil précédent de [RFC2388] et utilisé la méthode « encoded-word » d'encodage des valeurs non ASCII, comme décrit dans [RFC2047] :

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

D'autres sont connus pour suivre [RFC2231], pour envoyer UTF-8 non encodé, ou même pour envoyer des chaînes encodées dans le form-charset.

Pour cette raison, l'interprétation de multipart/form-data (même à partir de générateurs conformes) peut nécessiter de connaître le charset utilisé dans l'encodage du formulaire dans les cas où la valeur du champ charset ou un paramètre charset d'un champ d'en-tête Content-Type "text/plain" n'est pas fourni.

Dernière mise à jour le