POST-Request: enctype="multipart/form-data" und UTF-8

[Thomas Schenkeli]

Hallo,

ich habe es jetzt geschafft meine ganze Web-App auf UTF-8 umzustellen, lediglich an einer Stelle habe ich ein Problem:

ich habe eine FORM mithilfe derer ich ein Bild speichern kann, daher enctype="multipart/form-data". Dieser Enctype zerstört aber den Kommentar den man in einem Input-Feld angeben kann falls er UTF-8 Zeichen enthält (zB €). Lösche ich den encType, werden die Bilder nicht mehr gespeichert (Was zu erwarten war) aber der Kommentar wir dkorrekt versandt.

Weiß also jemand wie man enctype="multipart/form-data" und UTF-8 kombinieren kann?

Besten Dank und lg
Thomas

[迪拉斯]

Hey,

ich gehe davon aus, dass du im einfachsten Fall ein <input type="file"> und ein <input type="text"> hast. Lass das Attribut enctype einfach weg. Der Browser tut das richtige und liefert im HTTP-Header des POST-Request
    CONTENT_TYPE="multipart/form-data; boundary=----------tc2L[...]"

[Sven Rautenberg]

Moin!

ich gehe davon aus, dass du im einfachsten Fall ein <input type="file"> und ein <input type="text"> hast. Lass das Attribut enctype einfach weg. Der Browser tut das richtige und liefert im HTTP-Header des POST-Request
    CONTENT_TYPE="multipart/form-data; boundary=----------tc2L[...]"

Das widerspricht aber der Aussage von Thomas, der ja sagt, dass das Weglassen von enctype das Bild nicht mehr mitschickt. Und das entspricht auch meiner Beobachtung. "Automatisch" tut der Browser absolut nicht das Richtige, man muß es ihm schon explizit sagen.

Wäre auch schrecklich, wenn ein <input type=file> automatisch zu verschickten Dateien führen würde - es ist doch gerade ein Feature, dass ohne enctype-Angabe nur der gewählte Dateiname verschickt wird. In Intranets mit passendem Szenario durchaus ein brauchbares Feature.

- Sven Rautenberg

[Thomas Schenkeli]

Moin!

ich gehe davon aus, dass du im einfachsten Fall ein <input type="file"> und ein <input type="text"> hast. Lass das Attribut enctype einfach weg. Der Browser tut das richtige und liefert im HTTP-Header des POST-Request
    CONTENT_TYPE="multipart/form-data; boundary=----------tc2L[...]"

Das widerspricht aber der Aussage von Thomas, der ja sagt, dass das Weglassen von enctype das Bild nicht mehr mitschickt. Und das entspricht auch meiner Beobachtung. "Automatisch" tut der Browser absolut nicht das Richtige, man muß es ihm schon explizit sagen.

Genau die Vermutung, dass der Browser von selbst nix tut, habe ich nun auch. Ich habe wo anders aufgeschnappt, dass beim encType multipart/form-data die Handhabung der Parameter komplett dem Programmierer überlassen ist und da nix automatisch passiert. Kann das jemand bestätigen?

• Sven Rautenberg

lg
Thomas

[Sven Rautenberg]

Moin!

Genau die Vermutung, dass der Browser von selbst nix tut, habe ich nun auch. Ich habe wo anders aufgeschnappt, dass beim encType multipart/form-data die Handhabung der Parameter komplett dem Programmierer überlassen ist und da nix automatisch passiert. Kann das jemand bestätigen?

Hinsichtlich der Zeichencodierung würde ich das nicht unbedingt bestätigen.

Voraussetzung ist halt, dass du überall, wo es geht, "UTF-8" draufschreibst. Deine Liste in der Antwort zu wahsage enthält keine Aussage zum HTTP-Header. Der wäre am wichtigsten.

Und wenn es dann noch nicht funktioniert: HTML-Demo und Browserversion hier posten.

- Sven Rautenberg

[Thomas Schenkeli]

Moin!

Voraussetzung ist halt, dass du überall, wo es geht, "UTF-8" draufschreibst. Deine Liste in der Antwort zu wahsage enthält keine Aussage zum HTTP-Header. Der wäre am wichtigsten.

Also durch Punkt 3) (XSL-Files enthalten: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> als Teil des HTML-Head-Tags) steht nun in jedem HTML-File das dann im Browser ankommt "<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" /> drinnen, ich dachte das wäre die HTTP-Deklaration.

Wenn nein, wie sieht diese aus und wo kann ich sie vornehmen? Wie und wo kann ich die aktuelle Einsehen? (HTTP-Header bei Mitschnitt per Proxy? Da sehe ich zB. beim Repsonse Header das Name-Value-Paar "Content Type = text/html; charset=UTF-8")

• Sven Rautenberg

lg
Thomas

[Sven Rautenberg]

Moin!

Voraussetzung ist halt, dass du überall, wo es geht, "UTF-8" draufschreibst. Deine Liste in der Antwort zu wahsage enthält keine Aussage zum HTTP-Header. Der wäre am wichtigsten.

Also durch Punkt 3) (XSL-Files enthalten: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> als Teil des HTML-Head-Tags) steht nun in jedem HTML-File das dann im Browser ankommt "<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" /> drinnen, ich dachte das wäre die HTTP-Deklaration.

Nein, das ist nicht die HTTP-Deklaration. Das ist HTML. Und für den Browser nur dann entscheidend, wenn er keinen HTTP-Header erhält, in dem diese Information drinsteht.

Wenn nein, wie sieht diese aus und wo kann ich sie vornehmen? Wie und wo kann ich die aktuelle Einsehen? (HTTP-Header bei Mitschnitt per Proxy? Da sehe ich zB. beim Repsonse Header das Name-Value-Paar "Content Type = text/html; charset=UTF-8")

Dein Proxymitschnitt sieht etwas komisch aus, ist der original?

HTTP-Header können auf unterschiedliche Weise definiert werden:

• Im Webserver direkt. Stichwort für Apache wäre .htaccess, AddDefaultCharset bzw. AddCharset http://httpd.apache.org/docs/2.0/mod/core.html#adddefaultcharset
• Im Skript. In PHP beispielsweise mit header() http://www.php.net/header
• in sogenannten "asis"-Dateien, die sowohl HTTP-Header als auch (z.B.) HTML-Inhalt in einem enthalten http://httpd.apache.org/docs/2.0/mod/mod_asis.html
• und viele verschiedene weitere Methoden, die alle immer von den genutzen Programmen abhängen.

Wie gesagt: Wenn du in HTTP, HTML und accept-encoding von <form> immer "UTF-8" drinstehen hast, sollte der Browser alles korrekt erledigen.

Wenn das dennoch nicht klappt, mußt du mal etwas konkreter den Fehler beschreiben und ggf. auch mit Hexdumps erforschen. Bei Zeichensatzproblemen ist es immer unvorteilhaft, wenn man sich die Zeichen mit den Systemen, die die Zeichen verhunzen, wieder neu anzeigen läßt. Der Browser schickt was zum Server, der verarbeitet es, schickt es zum Browser zurück - auf der Strecke kann soviel schiefgehen. Wenn der Server aber die Hex- oder Dezimalcodes jedes empfangenen Zeichens zurückschickt, kann der Browser nur noch das auf dem Server empfangene Ergebnis unmißverständlich und ungewandelt darstellen.

- Sven Rautenberg

[wahsaga]

hi,

ich habe eine FORM mithilfe derer ich ein Bild speichern kann, daher enctype="multipart/form-data". Dieser Enctype zerstört aber den Kommentar den man in einem Input-Feld angeben kann falls er UTF-8 Zeichen enthält (zB €). Lösche ich den encType, werden die Bilder nicht mehr gespeichert (Was zu erwarten war) aber der Kommentar wir dkorrekt versandt.

Hast du auch accept-charset mit utf-8 angegeben?

gruß,
wahsaga

[Thomas Schenkeli]

hi,

Hast du auch accept-charset mit utf-8 angegeben?

Beschreibungen was ich alles getan habe um UTF-8 Tauglichkeit zu erreichen können den folgenden Threads in diesem Forum entnommen werden:

http://forum.de.selfhtml.org/archiv/2006/8/t134497/#m872657

Habe, kurz gesagt, folgendes gemacht:

1. XSL-Files beginnen mit <?xml version="1.0" encoding="UTF-8"?>
2. XSL-Files enthalten: <xsl:output encoding="UTF-8" [....] />
3. XSL-Files enthalten: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> als Teil des HTML-Head-Tags

Ist da das dabei was du meinst?

gruß,
wahsaga

lg
Thomas