Encoding Probleme

Hi zusammen,

ich versuche eine Benutzereingabe über MySQL zu verarbeiten, im HTTP Header habe ich angegeben, dass alles per UTF-8 gesendet werden soll (MySQL ist auch auf UTF-8 eingestellt). Klappt soweit auch, wenn man allerdings den Browser manuell auf ISO-8859-1 umstellt stürzt MySQL mit einer Fehlermeldung ab (Illegal mix of collations (latin1_german1_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE)), bzw. in einem anderen Fall speichert MySql die Daten nur, bis zum ersten unbekannten Zeichen (z.B. ł wenn ISO-8859-2 im Browser eingestellt ist)

1. Jetzt habe ich versucht, über mb_detect_encoding($string) herauszufinden, in welchem Encoding die Daten gesendet werden. Dieser behauptet aber beispielsweise beim Text "après" immer es wäre UTF-8, was eine Konvertierung natürlich unmöglich macht. Wie bewerkstellige ich es, dass er erkennt, ob dieser String im Encoding UTF-8 oder ISO-8859-1 abgesendet wurde?

2. Oder gibt es ferner eine sichere Möglichkeit zu erzwingen, dass alles in UTF-8 gesendet wird?

3.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

ist mir bekannt, hilft aber leider in diesem Fall nicht.

<form name="formular"  accept-charset="UTF-8">

habe ich noch entdeckt, aber erkennt das jeder Browser?

Ich würde mich freuen wenn mir jemand ein paar Hinweise, Tutorials oder Funktionen aufzeigen kann, die diese Probleme behandeln.

Hallo,

wenn du den Browser manuell auf Latin-1 umstellst, übergehst du jegliche durch den Server oder den Seiteninhalt vorgeschlagene Codierungsangabe.

Was du machen kannst, ist, den Content-Type Request-Header auszulesen (dort steht drin, mit welchem Zeichensatz die Anfrage gesendet wurde) und die Anfrageentität mit mb_convert_encoding in jedem Falle zu UTF-8 umzuwandeln.

Gruß,

Amica

Zitat von sEeb

wenn man allerdings den Browser manuell auf ISO-8859-1 umstellt stürzt MySQL mit einer Fehlermeldung ab (Illegal mix of collations (latin1_german1_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE)),

Mach dir bitte klar, dass ein Absturz des MySQL-Servers und eine simple Fehlermeldung beim Durchführen einer Anfrage etwas ganz verschiedenes sind.

<form name="formular"  accept-charset="UTF-8">

habe ich noch entdeckt, aber erkennt das jeder Browser?

Sollte in aktuellen Browsern m.E. das gewünschte bewirken.
Selbst wenn es in veralteten Versionen oder Exotenbrowsern nicht funktioniert, dürfte der Vorteil überwiegen.

Zitat von wahsaga

Sollte in aktuellen Browsern m.E. das gewünschte bewirken.
Selbst wenn es in veralteten Versionen oder Exotenbrowsern nicht funktioniert, dürfte der Vorteil überwiegen.

Selbst, wenn es funktioniert, hat das genau gar nichts mit dem Problem zu tun. Das Accept-Charset ist eine Bitte an den Server, eine entsprechende Antwortentität in dieser Codierung auszuliefern und beeinflusst auf keinen Fall die Anfragecodierung.

Zitat von AmicaNoctis

Das Accept-Charset ist eine Bitte an den Server, eine entsprechende Antwortentität in dieser Codierung auszuliefern und beeinflusst auf keinen Fall die Anfragecodierung.

Oh doch, Gnädigste :-)

Wenn dir die Beschreibung in SELFHTML nicht reicht, dann kannst du es auch in der Spezifikation nachlesen.

(Du denkst hier gerade an Accept-Charset in einem anderen Zusammenhang, nämlich in der anderen Richtung.)

Zitat von wahsaga

Oh doch, Gnädigste :-)(Du denkst hier gerade an Accept-Charset in einem anderen Zusammenhang, nämlich in der anderen Richtung.)

Sorry, du hast natürlich vollkommen Recht - auch bezüglich dessen, woran ich gedacht habe. Asche auf mein Haupt.

OffTopic:

---

Zitat von AmicaNoctis

Asche auf mein Haupt.

Ihr Frauen immer mit eurem Haare Färben ...

---

schonmal danke für die antworten

Zitat von AmicaNoctis

Hallo,

wenn du den Browser manuell auf Latin-1 umstellst, übergehst du jegliche durch den Server oder den Seiteninhalt vorgeschlagene Codierungsangabe.

Was du machen kannst, ist, den Content-Type Request-Header auszulesen (dort steht drin, mit welchem Zeichensatz die Anfrage gesendet wurde) und die Anfrageentität mit mb_convert_encoding in jedem Falle zu UTF-8 umzuwandeln.

Gruß,

Amica

naja ich stell da auch nix um sonder x-beliebige benutzer und das muss ich abfangen wie frage ich denn den Content-Type Request-Header ab? wo in php taucht das auf? in $_SERVER habe ich nichts sinnvolles gesehen

und dann noch was im selfhtml link von wahsaga steht:
Verwenden Sie nur eine einzige Kodierungsangabe im Attribut, keine Liste von mehreren Alternativen. Ein Browser ist nicht gezwungen, die "passendste" Kodierung zu verwenden, er kann auch einfach die allererste verwenden. Da die meisten Browser nicht mitsenden, welche Kodierung tatsächlich verwendet wurde, wäre es Ihnen unmöglich zu erkennen, welche Kodierung verwendet wurde. Bei nur einer eingetragenen Möglichkeit sind keine Zweifel möglich.

ärgerlich, habe dann mal versucht google zu überlisten udn verschiedene kombinationen ausprobiert, aber die lassen sich nicht überlisten ... komisch finde ich auch, dass php denkt es handelt sich um utf-8 und mysql denkt es ist latin-1 ....

Zitat von sEeb

wie frage ich denn den Content-Type Request-Header ab? wo in php taucht das auf? in $_SERVER habe ich nichts sinnvolles gesehen

$_SERVER["CONTENT_TYPE"], aber bei Formularen senden die meisten Browser da keine charset-Angabe mit (Ich bin erst davon ausgegangen, dass jeder Browser das in jedem Fall tut, aber in meinem Projekt setze ich das ja mit AJAX selber, daher konnte ich auch darauf zugreifen.)

Zitat von sEeb

mysql denkt es ist latin-1 ....

Hast du mysql_set_charset() oder SET NAMES gesetzt, nachdem du die Verbindung geöffnet hast?

Moment mal! Das Problem tritt doch nur auf, wenn ein Benutzer seinen Browser (wie auch immer) dazu zwingt, die Daten nicht mit dem accept-charset zu senden. Das sollte unmöglich sein! Auf diesen Fall würde ich also überhaupt nicht hinprogrammieren. Den Knall in MySQL fängt die generelle Fehlerbehandlung ab, die man immer haben sollte.

Die Spec sagt über accept-charset "This attribute specifies the list of character encodings for input data that is accepted by the server processing this form."
Sendet ein Client die Daten mit einem anderen Charset, muss er also davon ausgehen, dass der Server diese Daten gar nicht akzeptiert. Sie trotzdem hinzuschicken ist definitiv ein Fehler des Clients. Browser die sowas machen sind schlichtweg kaputt. Punkt.

Die MySql Verbindung ist automatisch auf UTF-8 eingestellt, genauso wie alle Tabellen die Verwendet werden.

Moment mal! Das Problem tritt doch nur auf, wenn ein Benutzer seinen Browser (wie auch immer) dazu zwingt, die Daten nicht mit dem accept-charset zu senden. Das sollte unmöglich sein! Auf diesen Fall würde ich also überhaupt nicht hinprogrammieren. Den Knall in MySQL fängt die generelle Fehlerbehandlung ab, die man immer haben sollte.

Die Spec sagt über accept-charset "This attribute specifies the list of character encodings for input data that is accepted by the server processing this form."
Sendet ein Client die Daten mit einem anderen Charset, muss er also davon ausgehen, dass der Server diese Daten gar nicht akzeptiert. Sie trotzdem hinzuschicken ist definitiv ein Fehler des Clients. Browser die sowas machen sind schlichtweg kaputt. Punkt.

Das stimmt, aber leider kann ich mir das nicht leisten Wenn der Benutzer etwas abschickt, muss es auch im System landen, ganz gleich was er eingestellt hat

Also nochmal zurück zum Ursprung, eigentlich suche ich ja einen sicheren Weg für einen übergebenen String die Codierung herauszufinden, oder eine Funktion, die alles nach UTF-8 konvertieren kann, ohne dass man die Codierung kennt. Mit mb_convert_encoding() klappt das sehr gut, wenn ich das Encoding kenne, aber wie gesagt, wenn der String so einfach ist wie "après" kann mb_detect_encoding() nicht feststellen, ob es sich um ISO oder UTF handelt ... Spontan fällt mir ein, in einem hidden Feld verschiedene Zeichen mitzusenden, die man dann untersucht, um das Encoding herauszufinden, aber das ist auch irgendwie gehackt ...

Zitat von sEeb

Das stimmt, aber leider kann ich mir das nicht leisten Wenn der Benutzer etwas abschickt, muss es auch im System landen, ganz gleich was er eingestellt hat

Warum?

Mindestanforderungen an den Client bis auf knapp über Fussbodenhöhe herunterzuschrauben, wird oft serverseitig erheblichen Zusatzaufwand erfordern.

Spontan fällt mir ein, in einem hidden Feld verschiedene Zeichen mitzusenden, die man dann untersucht, um das Encoding herauszufinden, aber das ist auch irgendwie gehackt ...

Wenn du nicht akzeptieren kannst/darfst/willst, per (ausgehandelter) Definition fehlerhafte Daten als solche zurückzuweisen* - dann wird dir ausser Hacks vermutlich nichts anderes übrig bleiben.

Aber auch dazu noch mal, Vorsicht: Es gibt keinen Weg zweifelsfrei festzustellen, in welcher Kodierung Daten vorliegen.


* Wobei noch zu überlegen wäre, unter welchem HTTP Statuscode man das macht.

• 406 Not Acceptable
• 412 Precondition Failed (den könnte man verwenden, wenn der Client mitgeteilt hat, in welcher Kodierung er seine Daten sendet, und man diese nicht akzeptieren kann)
• 422 Unprocessable Entity (wenn die Kodierung nicht erkannt wurde, und es beim Speichern in der Datenbank wirklich deswegen Fehler gibt)

accept-charset wird vom IE auch dem achter? nicht unterstützt, soviel weiss ich noch

Wenn man den Zusatzaufwand aber betreiben will oder muss, weil man auf die Besucher angewiesen ist führt da kein Weg dran vorbei

Ich habe aber noch eine Möglichkeit gefunden. Über JavaScript kann man das im Browser eingestellte Encoding abfragen und dann die übergebenen Werte entsprechend konvertieren ...

Zitat von sEeb

Ich habe aber noch eine Möglichkeit gefunden. Über JavaScript kann man das im Browser eingestellte Encoding abfragen und dann die übergebenen Werte entsprechend konvertieren ...

Ich hätte Interesse zu erfahren, wie genau du das machst.

Bei vielen Seiten, die ich geprüft habe, war
theForm.acceptCharset == ""
theForm.encoding== ""
theForm.enctype== ""

Wo nimmst du es her?

Gruß,

Amica