Passa al contenuto principale

5.1. Nomi e valori di campo non ASCII

5.1. Non-ASCII Field Names and Values​

🇬🇧 Testo originale inglese​

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.

🇮🇹 Traduzione italiana​

Normalmente, i campi di intestazione MIME nei corpi multipart devono essere costituiti solo da dati a 7 bit nel set di caratteri US-ASCII. Mentre [RFC2388] suggeriva che i nomi di campo non ASCII fossero codificati secondo il metodo in [RFC2047], questa pratica non sembra essere stata seguita ampiamente.

Questa specifica fornisce tre serie di raccomandazioni per tre diversi stati del flusso di lavoro.

5.1.1. Avoid Non-ASCII Field Names​

🇬🇧 Testo originale inglese​

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.

🇮🇹 Traduzione italiana​

Per la massima interoperabilità con il software esistente distribuito, coloro che creano moduli DOVREBBERO evitare nomi di campo non ASCII (SHOULD). Questo non dovrebbe essere un onere perché, in generale, i nomi dei campi non sono visibili agli utenti. I nomi dei campi sottostanti non devono corrispondere a ciò che l'utente vede sullo schermo.

Se i nomi di campo non ASCII sono inevitabili, i creatori di moduli o applicazioni DOVREBBERO usare UTF-8 in modo uniforme (SHOULD). Questo ridurrà al minimo i problemi di interoperabilità.

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

🇬🇧 Testo originale inglese​

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.

🇮🇹 Traduzione italiana​

Alcune applicazioni di questa specifica forniranno una codifica dei caratteri da utilizzare per l'interpretazione del corpo multipart/form-data. In particolare, HTML 5 [W3C.REC-html5-20141028] utilizza:

  • il contenuto di un campo "charset", se presente;
  • il valore di un attributo accept-charset dell'elemento <form>, se presente;
  • la codifica dei caratteri del documento contenente il modulo, se è compatibile con US-ASCII;
  • altrimenti, UTF-8.

Chiama questo valore form-charset. Qualsiasi testo, che sia un nome di campo, un valore di campo o dati di modulo ("text/plain") che utilizza caratteri al di fuori dell'intervallo ASCII PUÒ essere rappresentato direttamente codificato nel form-charset (MAY).

5.1.3. Parsing and Interpreting Form Data​

🇬🇧 Testo originale inglese​

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.

🇮🇹 Traduzione italiana​

Sebbene questa specifica fornisca indicazioni per la creazione di multipart/form-data, i parser e gli interpreti dovrebbero essere consapevoli della varietà di implementazioni. I file system differiscono, ad esempio, sul fatto se e come normalizzano i nomi Unicode. La corrispondenza degli elementi del modulo alle parti dei dati del modulo può basarsi su una corrispondenza più sfumata. In particolare, alcuni generatori multipart/form-data potrebbero aver seguito il precedente consiglio di [RFC2388] e utilizzato il metodo "encoded-word" per codificare i valori non ASCII, come descritto in [RFC2047]:

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

È noto che altri seguano [RFC2231], inviino UTF-8 non codificato o addirittura inviino stringhe codificate nel form-charset.

Per questo motivo, l'interpretazione di multipart/form-data (anche da generatori conformi) può richiedere la conoscenza del charset utilizzato nella codifica del modulo nei casi in cui il valore del campo charset o un parametro charset di un campo di intestazione Content-Type "text/plain" non sia fornito.

Ultimo aggiornamento il