nicht angemeldet
LÖSUNG:
also so lächerlich es auch klingt, ich hab die Lösung für mein Problem gefunden: Es liegt daran, dass ich das Form per get und net per post abgeschickt habe. Wenn ich das ändere, tut es.
Hier der Link zur Quelle: klick!
"
Probleme mit GET-Anfragen
Leider funktioniert der im vorigen Abschnitt vorgestellte Filter nur mit per POST übertragenen Formular-Werten korrekt. Nutzt man GET als Absende-Methode oder hängt man an die URL Parameter-Werte, so stößt man auf Probleme mit der fehlenden Standard-Konformität der Browser. Diese sollten gemäß W3C-Spezifikation GET-Parameter immer im UTF-8-Format an die Adresse anhängen.9 Wieder mal ist auch hier auf die Browser-Hersteller kein Verlass. Anstelle des Standards ist hier leider das Verhalten weit verbreitet, die Parameter in dem Encoding an die Adresse anzuhängen, das gerade vom Browser verwendet wird. Ist also die Seite in ISO-8859-1 kodiert, senden die meisten Browser auch den Anfrage-String als ISO-8859-1-kodierten String und eben nicht im standard-konformen UTF-8-Format. Aufgrund dessen, dass nicht alle Browser sich an diesen Standard halten, kann es sein, dass bei GET-Anfragen die Methode setCharacterEncoding(String) nicht das gewünschte Ergebnis bringt.
Im Tomcat, genauer im Coyote-Connector, kann man daher an zwei Schrauben drehen, um das gewünschte Verhalten des Containers einzustellen. Dies sind zwei optionale Attribute des Connector-Elementes in der Datei server.xml im Verzeichnis conf unterhalb des Tomcat-Root-Verzeichnisses.
Das eine Attribut heißt useBodyEncodingForURI. Dieses legt fest, ob für URL-kodierte Werte der Wert genutzt werden soll, der per setCharacterEncoding(String) gesetzt wird. Was auf den ersten Blick wie die gewünschte Lösung aussieht, birgt allerdings ein Problem mit dem oben genannten Standard. Nutzt ein Browser diesen Standard bei Seiten, die nicht UTF-8-kodiert sind, funktioniert diese Einstellung nicht.
Das andere Attribut heißt URIEncoding. Dieses legt fest, welches Standard-Encoding für URL-kodierte Werte angenommen werden soll. Standardmäßig wird hier ISO-8859-1 angenommen. Dies entspricht dem Standard-Encoding, das gemäß Servlet-Spec genutzt werden soll, wenn setCharacterEncoding(String) nicht aufgerufen wird. Mit dem Standard-Wert ISO-8859-1 läuft man aber erneut Gefahr, dass die Seite bei Browsern, die sich standard-konform verhalten und die Werte mit UTF-8 kodieren, nicht korrekt funktioniert. Die Tomcat-Entwicklerinnen sitzen hier in einer Klemme zueinander inkompatibler Spezifikationen. Hier ist wünschenswert, dass die Servlet-Spezifikation dem W3C-Standard folgt und UTF-8 zum Standard URL-kodierter Werte macht. Leider ist dies auch im vorliegenden "Final Public Draft" der Servlet-Spezifikation 2.5 noch nicht der Fall!
Auch diese Problematik stärkt unser Argument für die durchgängige Verwendung von UTF-8. Setzt man das erste Attribut auf "false"10 und das zweite auf UTF-8, so funktioniert das mit allen Browsern, da diese sich - ob sie sich nun bei anderem Encoding standard-konform verhalten oder nicht - bei UTF-8 korrekt verhalten. Bei UTF-8 und den hier empfohlenen Werten im Connector-Element der Tomcat-Konfigurationsdatei funktioniert der obige Filter dann auch bei GET-Anfragen korrekt. Leider aber wirklich nur dann.
"
suit