multipart/form-data, was ist der Standard-Zeichensatz für Felder?

Question

Wie lautet die Standardcodierung, die zum Entschlüsseln von mehrteiligen/Formulardaten verwendet werden soll, wenn kein Zeichensatz angegeben wird? RFC2388 heißt es:

4,5 Charset von Text in Formulardaten

Jeder Teil eines multipart/form-data soll eine inhalts- Typ haben. Wenn ein Feldelement Text ist, zeigt der Zeichensatz Parameter für den Text die verwendete Zeichencodierung an.

Zum Beispiel kann ein Formular mit einem Textfeld, in dem ein Benutzer eingegeben 'Joe schuldet <eu> 100', wo <eu> das Euro-Symbol ist möglicherweise Formulardaten zurück wie hat:

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

Joe owes =80100. 
--AaB03x 

In meinem Fall ist der Zeichensatz nicht festgelegt und ich weiß nicht, wie Sie die Daten in diesem Text/normalen Abschnitt dekodieren. Da ich etwas, das kein Standardverhalten ist, nicht durchsetzen möchte, frage ich, was das erwartete Verhalten in diesem Fall ist. Der RFC scheint das nicht zu erklären, also bin ich irgendwie verloren.

Vielen Dank!

Answer 1

Der Standard-Zeichensatz für ist ISO-8859-1 (Latin1), ich würde vermuten, dass dies auch hier gilt.

3.7.1 Canonicalization und Text Defaults

--snip--

Die "Zeichensatz" Parameter mit einigen Medientypen verwendet, um den Zeichensatz (Abschnitt 3.4) zu definieren, der Daten. Wenn vom Absender kein expliziter Zeichensatzparameter bereitgestellt wird, werden Mediensubtypen vom Typ "Text" mit einem Standardzeichensatzwert von "ISO-8859-1" definiert, wenn sie über HTTP empfangen werden. Daten in anderen Zeichensätzen als "ISO-8859-1" oder ihren Untergruppen MÜSSEN mit einem entsprechenden Zeichensatzwert gekennzeichnet werden. Siehe Abschnitt 3.4.1 für Kompatibilitätsprobleme.

Answer 2

Dies hat sich anscheinend in HTML5 geändert (siehe http://dev.w3.org/html5/spec-preview/constraints.html#multipart-form-data).

Für die Teile der generierten multipart/form-data-Ressource, die Nicht-Dateifeldern entsprechen, darf kein Content-Type-Header angegeben werden.

Wo ist der Zeichensatz angegeben? Soweit ich das mit dem Kodierungsalgorithmus feststellen kann, ist der einzige Platz in einem Formulardatensatzeintrag mit dem Namen _charset_.

Wenn Ihr Formular keine versteckte Eingabe namens _charset_ hat, was passiert? Ich habe dies in Chrome 28 getestet, indem ich ein in UTF-8 und eins in ISO-8859-1 codiertes Formular sendete und die gesendeten Header und Nutzdaten untersuchte. Ich sehe keinen Zeichensatz irgendwo (auch wenn sich die Textcodierung definitiv ändert)). Wenn ich ein leeres Feld _charset_ in das Formular einfüge, füllt Chrome das mit dem korrekten Zeichensatztyp. Ich denke, jeder serverseitige Code muss dafür _charset_ Feld suchen, um es herauszufinden?

Ich habe dieses Problem beim Schreiben einer Chrome-Erweiterung, die XMLHttpRequest.send eines FormData Objekts verwendet, das always gets encoded in UTF-8 no matter what the source document encoding is.

Lassen Sie den Entity-Body der Anforderung das Ergebnis der Ausführung des Multipart/Form-Data-Codierungsalgorithmus mit Daten als Formulardatensatz und mit utf-8 als explizite Zeichencodierung.

Lassen Sie Mime-Typ die Verkettung von "multipart/form-data;", ein U + 0020 Leerzeichen, "boundary =", und die multipart/form-Daten-Grenze Zeichenfolge durch die multipart/Form-Datencodierung generiert Algorithmus.

Wie ich bereits gefunden, charset = utf-8 ist nicht überall auf der POST-Anfrage angegeben, es sei denn Du ein leeres _charset_ Feld in der Form enthalten, die in diesem Fall werden automatisch mit „UTF- bevölkerte erhalten 8 ".

Dies ist mein Verständnis des Zustandes der Dinge. Ich begrüße Korrekturen meiner Annahmen!

Answer 3

Dank der detaillierten Erklärung von @owlman.

Nur ein paar mehr Infos hier:

hochladen Anfrage Nutzlast Fragment:

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

Wenn "xxx.txt" in ihm einig UNICODE char hat UTF-8-Codierung, Harz (Stand 4.0. 40) kann es nicht richtig dekodieren, aber Jetty (9.x) kann.

Ich denke, der Grund für Resins Verhalten ist, dass der Content-Typ keine Codierung angibt, also Resin dekodieren Dateinamen mit "ISO8859-1", was zu unleserlichen Zeichen führen kann.

habe ich einige googeln:

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

Es scheint, dass das Verhalten Harzes ist nach Servlet Spec 2.3

Und ich kann alle Einstellungen von http://www.caucho.com/resin-4.0/reference.xtp nicht finden, die dieses Verhalten ändern können Harz.