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.

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.

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

o the content of a "_charset_" field, if there is one;

o the value of an accept-charset attribute of the

element, if there is one;

o the character encoding of the document containing the form, if it is US-ASCII compatible;

o 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.

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.