Servlet Umlaute

[HimBromBeere]

Malzzeit,

ich weiß, das Thema hat schon wer weiß was für ´nen langen Bart, nur wirklich schlauer bin ich nach stundenlangem Probieren und Studieren immer noch nicht, was das leidige Thema Encoding angeht.

Folgendes: ich hab eine HTML-Seite mit

<meta charset="UTF-8>

. Irgendwann wird nun über ein Skript die URL http://wasauchimmer:8080/test?ein=paar&parameter=mit&Umlauten=Düsseldorf aufgerufen. Im Netzwerkprotokoll vom Fuchs (FireBug) steht nun die umkodierte Schreibweise ...Umlauten=D%C3%BCsseldorf, soweit so gut. Nun will ich dieses Düsseldorf in ´ner Datenbankabfrage verwenden, welche ich mittels eines Servelts realsiere (in diesem Fall test). Und hier passiert jetzt, was passieren muss, die Abfrage geht nicht als Düsseldorf an die DB sondern als '

Düsseldorf

'.
Habe hierfür schon folgendes versucht:

String encoding = request.getCharacterEncoding();
if (encoding == null) encoding = "UTF-8";
logger.debug("Input param " + Umlauten+ " decoded to " + URLDecoder.decode(Umlauten, encoding) + " using " + encoding);

Es steht dann im log z.B. folgendes:

Input param Düsseldorf decoded to Düsseldorf using UTF-8

Auch die Antwort-Sprache hab ich fein auf UTF-8 gesetzt, was ja aber für die Request-Paramater erstmal Wurscht sein sollte.

response.setCharacterEncoding("UTF-8");

Wie bekomm ich nun mein Ü auch als Ü in die DB-Abfrage rein? Ich verzweifle langsam ein kleines bisschen;(

EDIT: Wenn ich nur die URL verwende und in den Browser eingebe (als Düsseldorf) kommt übrigens das gleiche Problem...

 

[deetee]

Die Datenbank Connection muss auch auf UTF8 konfiguriert werden. Ist das der Fall bei dir?

 

[HimBromBeere]

Meinst du die Connection oder die Locale-Einstellung der DB? Auf letzteres hab ich keinen Einfluss, bei Ersterem weiß ich gar nicht, wie das geht...

 

[SlaterB]

wenn du nichts weiter zur DB, zur Connection-Konfiguration usw. sagst, soll dann das Thema beendet sein
oder das auch noch erst mühsam nachgefragt werden wie hier von mir?

'jdbc connection utf8' in Suchmaschinen liefert bereits manches,
mit genauerer Einschränkung auf dein Framework, DB, Konfigurationsart usw. vielleicht schnell zu klären

 

[HimBromBeere]

Naja, die Info mit der DB hielt ich erstmal für nicht weiter notwendig. Die geposteten Ausgaben kommen nicht von der DB, sondern vom Servlet, weswegen ich den Fehler also erstmal auf dieser Seite gesucht hab (weil ja bereits die Ausgabe der später an die DB zu übergebenden Parameter fehlerhaft ist, jedenfalls laut Konsole), bis zur DB hab ich erstmal gar nicht gedacht...

Meine Connection-URL sieht so aus (hoffentlich bekomm ich´s noch zusammen):

this.url = "jdbc:postgresql://" + this.host + ":" + this.port + "/";
this.con = DriverManager.getConnection(this.url+ this.dbase, this.user, this.password);

. Dass man hier sogar ´n Encoding angeben kann, wusst ich nichtmal. Achja, das DBMS ist übrigens Postgres 9.0

 

[SlaterB]

nun gut, DB nicht beteiligt, nicht komplette Unschuld bei dir, einfach nicht erwähnen, schon gibt kein Problem
der Parameter sollte im System.out.println() gut aussehen, das darf man wohl erwarten

'java servlet umlaute' kann man wiederum in Suchmaschinen eintippen

da gibts manchen Code zum Umformen
Umlaute an Servlet übergeben @ Enterprise Java (JEE, J2EE, Spring & Co.) - tutorials.de: Tutorial, Forum, Anleitung & Hilfe
Kaputte Umlaute in Servlet (Tomcat/Linux) @ Enterprise Java (JEE, J2EE, Spring & Co.) - tutorials.de: Tutorial, Forum, Anleitung & Hilfe

und als Rückfragen wohl Konfiguration des Webservers

 

[deetee]

this.url = "jdbc:postgresql://" + this.host + ":" + this.port + "/";
this.con = DriverManager.getConnection(this.url+ this.dbase, this.user, this.password);

. Dass man hier sogar ´n Encoding angeben kann, wusst ich nichtmal. Achja, das DBMS ist übrigens Postgres 9.0

Versuch das mal:

this.url = "jdbc:postgresql://" + this.host + ":" + this.port + "/";
this.con = DriverManager.getConnection(this.url+ this.dbase + "?charSet=UNICODE", this.user, this.password);

 

[HimBromBeere]

Habe gerade festgestellt, dass beim Setzen des Encodings der HTML-Seite die Ausführungszeichen fehlten (vielen Dank an The W3C Markup Validation Service) was darin resultierte, dass meine Umlaute bereits in der HTML-Seite selbst nicht mehr richtig darsgetellt werden. Wie dem auch sei, auf die versendeten Paramater für´s Servlet hat das hin wie her keinen Einfluss.

da gibts manchen Code zum Umformen
Umlaute an Servlet übergeben @ Enterprise Java (JEE, J2EE, Spring & Co.) - tutorials.de: Tutorial, Forum, Anleitung & Hilfe

Von da hab ich das mit dem

request.setCharacterEncoding(encoding);

entnommen
Über den zweiten Link bin ich bereits gestolpert, aber irgendwie waren mir die dort verwendeten Klassen ein wenig suspekt

Webserver ist - wie vlcht. schon zu erwarten war - ein Tomcat, und zwar die Standardimplementierung wie sie von Eclipse EE mitgeliefert wird. Und wie ich gerade feststelle, ist das Encoding dort auf Cp1252 gesetzt. Ist das nicht UTF-8?

Versuch das mal:

this.url = "jdbc:postgresql://" + this.host + ":" + this.port + "/";
this.con = DriverManager.getConnection(this.url+ this.dbase + "?charSet=UNICODE", this.user, this.password);

Hab ich gemacht, hat aber nix gebracht...
[EDIT]Das DB-log hab ich leider nicht, sonst hätte ich ja mal da drin schauen können, was in der DB tatsächlich ankommt.[/EDIT]

 

[deetee]

Ok, ich dachte aufgrund dieser Aussage:

Und hier passiert jetzt, was passieren muss, die Abfrage geht nicht als Düsseldorf an die DB sondern als 'Düsseldorf '

läge es an der DB Connection.

Cp1252 ist nicht UTF-8, daher liegt es wahrscheinlich an dieser Konfiguration.

 

[SlaterB]

> und zwar die Standardimplementierung wie sie von Eclipse EE mitgeliefert wird

in Eclipse bietet sich auch die Umstellung des Workspaces an, generell wichtig,
wenn Dateien auch mit Nicht-Windows-Rechnern getauscht werden,
und gleiche zwei Beteiligte

 

[maki]

Webserver ist - wie vlcht. schon zu erwarten war - ein Tomcat, und zwar die Standardimplementierung wie sie von Eclipse EE mitgeliefert wird. Und wie ich gerade feststelle, ist das Encoding dort auf Cp1252 gesetzt. Ist das nicht UTF-8?

Standardencoding in Eclipse = Standardencoding der Plattform, unter Linux utf-8, unter einem dt. Windows eben zB. Cp1252

 

[HimBromBeere]

So, jetzt hab ich mal sowohl das Encoding vom Server als auch des des Workspaces auf UTF-8 umgestellt, leider ohne Erfolg. In meiner Konsole steht immer noch

Input param Düsseldorf decoded to Düsseldorf using UTF-8

Btw.: Wo stell ich denn das Encoding auf einem externen Tomcat ein? Der Eclipse-interne ist nur zum testen, das WAR-File wird dann auf ´nen anderen hochgeladen.
[EDIT]OK, zumindest letzteres hab ich gefunden und zwar hier[/EDIT]

 

[SlaterB]

> Btw.: Wo stell ich denn das Encoding auf einem externen Tomcat ein?

du meinst einmal mehr, ohne 'Tomcat Encoding' bzw. ähnliches in eine Suchmaschine einzutippen?
(edit: im edit dann ja doch)

FAQ/CharacterEncoding - Tomcat Wiki

das zu bedenkende Feld ist anscheinend weit,
gut möglich dass die bisherigen Tipps hier (zumindest von mir, wobei gar nicht so konkret) den Kern des Problems noch nicht erfassten,
hoffe vorerst dass der Link bzw. ähnlich weiterhelfen

 

[HimBromBeere]

den Kern des Problems noch nicht erfassten

Ich hatte eigtl. angenommen, dass das Problem nicht so groß ist, sodass der Kern schnell klar sein sollte. Darum nochmal ganz langsam:
Es gibt einen Tomcat (UTF-8 Encoding) mit Servlet.

String area = request.getParameter("area");
String encoding = request.getCharacterEncoding();
if (encoding == null) encoding = "UTF-8";
logger.debug("Input param " + area + " decoded to " + URLDecoder.decode(area, encoding) + " using " + encoding);
area = URLDecoder.decode(area, encoding);}

An dieses stell ich eine Anfrage: http://localhost:8082/GeoCharts/load?area=Düsseldorf
Nichts Atemberaubendes, dennoch kommt, wenn ich den Parameter nun mittels der oben beschriebenen Zeilen dekodiere, nur Käse raus:

Düsseldorf

Das gleiche passiwert, wenn ich händisch das ü als %C3&BC umkodiere, also http://localhost:8082/GeoCharts/load?area=Düsseldorf (ist ja witzig, der Browser macht das hier gleich mal automatisch beim Kopieren der URL in den beitrag ).
Ich hoffe, jetzt hab ich "den Kern" klar beschrieben.
Die Sache mit dem Skript lass ich erstmal außen vor.

du meinst einmal mehr

Was heißt hier einmal mehr?!

 

[maki]

In meiner Konsole steht immer noch Input param Düsseldorf decoded to Düsseldorf using UTF-8

Was genau ist denn deine "Konsole"?

cmd.exe "spricht" kein UTF-8, da sieht das immer so aus
Die Eclipse "Console View" spricht dagegen utf-8

 

[HimBromBeere]

Meine Konsole ist die Standardausgabe von Eclipse, welche mittels Log4J versendet wird.

 

[SlaterB]

Ich hoffe, jetzt hab ich "den Kern" klar beschrieben.

das Problem bzw. die Folge, ihr Erlebnis, ist klar,
aber der Kern der Lösung, der Kern des Fehlers, was umgestellt werden muss, evtl. weniger

zur Konsole:
war es da nicht so, dass Java-Strings eh Unicode sind?
egal woher sie stammen, von der Quelle in String muss richtig umgewandelt werden, aber wenn erstmal String, dann ist alles das gleiche,

teste, ob die Ausgabe funktioniert, indem du auch Umlaute im Programm definierst:

String dd1 = "Düsseldorf";
String dd2 = woher auch immer

System.out.println("dd1: "+dd1+", dd2: "+dd2);

sowie noch gegebenenfalls die beiden Strings dd1, dd2 intensiv vergleichen, Länge, einzelne Zeichen usw.

wie dd2 korrekt aus dem Parameter gewonnen werden kann, das wäre dann wiederum der 'Kern',
sofern Konsole kein Problem sein sollte

-----

wenn man in Textdateien schreibt, dann wird wiederum das Encoding interessant,
der lesende Editor wichtig

 

[HimBromBeere]

der lesende Editor wichtig

Das hab ich auch gerade festgestellt. Ich hab als Zeichensatz für meinen kleinen Notepad++ ANSI gehabt. Wenn ich nun in meiner HTML Umlaute geschrieben hab (bei HTML-Zeichensatz UTF-8), wurden diese falsch darsgetellt (wohingegen ISO-8859-1 ging). Nun hab ich Dden N++ auch mal auf UTF-8 umgestellt (und anschließend die fraglichen Stellen nochmal richtig eingegeben alös Umlaute), und dann ging zumindest die HTML-Darstelung. Erstes Problem erledigt, bleibt das mit dem Servlet.

Deinem Tip folgend, habe ich jetzt auch mal Folgendes probiert:

String area= "Düsseldorf";
String encoding = request.getCharacterEncoding();
if (encoding == null) encoding = "UTF-8";
logger.debug("Input param " + area + " decoded to " + URLDecoder.decode(area, encoding) + " using " + encoding);
area = URLDecoder.decode(area, encoding);}

Und - Wunder - es kommt tatsächlich Düsseldorf bei raus. Auch die anschließende Datenbankabfrage - vorhin noch als evtl. Fehlerquelle gehandelt - funktioniert tadellos. Es läuft also bei der Übertragung des URL-Paramaters an das Servlet was nicht so, wie es sollte...

 

[tröööt]

schon mal die klasse [japi]URLDecoder[/japi] angeguckt ? ... davon habe ich hier im ganzen thread nichts gefunden

 

[deetee]

Ist das Problem nun gelöst?

Noch als Hinweis: Ob die Daten wirklich korrekt in der DB ankommen kannst du nur zuverlässig testen indem du mit einem DB Query Tool in die Datenbank schaust. Die Prüfung über die Anwendung, ob die Daten richtig im Browser angezeigt werden reicht dafür nicht aus.

 

[HimBromBeere]

schon mal die klasse URLDecoder angeguckt ? ... davon habe ich hier im ganzen thread nichts gefunden

Hmmm?? Zeile 5 zum Bsp.?

Ist das Problem nun gelöst?

Nope

Noch als Hinweis: Ob die Daten wirklich korrekt in der DB ankommen kannst du nur zuverlässig testen indem du mit einem DB Query Tool in die Datenbank schaust. Die Prüfung über die Anwendung, ob die Daten richtig im Browser angezeigt werden reicht dafür nicht aus.

Der Schritt mit der DB kommt doch erst viel später... wenn meine Parameter nichtmal richtig bis zum Servlet kommen, brauch ich micht nich damit beschäftigen, wie diese (falschen) Daten korrekt von der DB behandelt werden. Die Anfragen selbst sind im Übrigen valide und liefern auch die gewünschten Ergebnisse. Wenn ich also z.B. an die DB einen Select für 'Düsseldorf' absende, bekomme ich die gewünschten Ergebnisse (unabhängig vom Browser oder dem Servlet).

[EDIT]Ich kann´s kaum glauben, es läuft. Hätte ich mal den Eclipse-internen Server von vornherein ignoriert, wäre das Probelm sehr viel schneller behoben gewesen. Ich hab dort zwar in der Konfiguration angegeben, dass der Zeichensatz vom Projekt geerbt werden soll (UTF-8), aber irgendwie schaffte es dieser Eintrag nicht in die zugehörige Server-XML. Aus mir unbegreiflichem Grund geht es jetzt aber, mal schauen, ob´s dann im Produktivsystem auch geht...[/EDIT]