Zum Hauptinhalt springen

5.1. Nicht-ASCII-Feldnamen und -Werte

5.1. Non-ASCII Field Names and Values​

🇬🇧 Englischer Originaltext​

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.

🇩🇪 Deutsche Übersetzung​

Normalerweise müssen MIME-Header-Felder in Multipart-Bodies nur aus 7-Bit-Daten im US-ASCII-Zeichensatz bestehen. Während [RFC2388] vorschlug, dass Nicht-ASCII-Feldnamen gemäß der Methode in [RFC2047] kodiert werden sollten, scheint diese Praxis nicht weit verbreitet zu sein.

Diese Spezifikation gibt drei Sätze von Empfehlungen für drei verschiedene Workflow-Zustände.

5.1.1. Avoid Non-ASCII Field Names​

🇬🇧 Englischer Originaltext​

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.

🇩🇪 Deutsche Übersetzung​

Für die größtmögliche Interoperabilität mit vorhandener eingesetzter Software SOLLTEN diejenigen, die Formulare erstellen, Nicht-ASCII-Feldnamen vermeiden (SHOULD). Dies sollte keine Belastung darstellen, da die Feldnamen im Allgemeinen für Benutzer nicht sichtbar sind. Die zugrunde liegenden Feldnamen müssen nicht mit dem übereinstimmen, was der Benutzer auf dem Bildschirm sieht.

Wenn Nicht-ASCII-Feldnamen unvermeidlich sind, SOLLTEN Formular- oder Anwendungsersteller UTF-8 einheitlich verwenden (SHOULD). Dies minimiert Interoperabilitätsprobleme.

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

🇬🇧 Englischer Originaltext​

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.

🇩🇪 Deutsche Übersetzung​

Einige Anwendungen dieser Spezifikation liefern eine Zeichenkodierung, die zur Interpretation des multipart/form-data-Body verwendet werden soll. Insbesondere HTML 5 [W3C.REC-html5-20141028] verwendet:

  • den Inhalt eines "charset"-Feldes, falls vorhanden;
  • den Wert eines accept-charset-Attributs des <form>-Elements, falls vorhanden;
  • die Zeichenkodierung des Dokuments, das das Formular enthält, falls es US-ASCII-kompatibel ist;
  • andernfalls UTF-8.

Nennen Sie diesen Wert form-charset. Jeder Text, ob Feldname, Feldwert oder ("text/plain")-Formulardaten, der Zeichen außerhalb des ASCII-Bereichs verwendet, KANN direkt im form-charset kodiert dargestellt werden (MAY).

5.1.3. Parsing and Interpreting Form Data​

🇬🇧 Englischer Originaltext​

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.

🇩🇪 Deutsche Übersetzung​

Während diese Spezifikation Anleitungen zur Erstellung von multipart/form-data bietet, sollten Parser und Interpreter sich der Vielfalt der Implementierungen bewusst sein. Dateisysteme unterscheiden sich beispielsweise darin, ob und wie sie Unicode-Namen normalisieren. Die Zuordnung von Formularelementen zu Formulardatenteilen kann auf einer unschärferen Übereinstimmung beruhen. Insbesondere könnten einige multipart/form-data-Generatoren dem früheren Rat von [RFC2388] gefolgt sein und die "encoded-word"-Methode zur Kodierung von Nicht-ASCII-Werten verwendet haben, wie in [RFC2047] beschrieben:

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

Es ist bekannt, dass andere [RFC2231] folgen, unkodiertes UTF-8 senden oder sogar im form-charset kodierte Zeichenfolgen senden.

Aus diesem Grund kann die Interpretation von multipart/form-data (selbst von konformen Generatoren) in Fällen, in denen der charset-Feldwert oder ein charset-Parameter eines "text/plain"-Content-Type-Header-Feldes nicht angegeben ist, das Wissen über den in der Formularkodierung verwendeten Zeichensatz erfordern.

Letztes Update am