| 

.NET C# Java Javascript Exception

3mal Codierungsprobleme :-(

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


3mal Codierungsprobleme :-(

slyfox1972 - 18.08.2010 20:53
Hallo!

Programmieren und in Grails macht ja eigentlich Spaß, aber wenn ständig unerwartete Probleme auftreten, und die meiste Zeit an Fehlersuche und Problemlösungen hängen bleibt, wird's eher frustierend.

Bei einem Projekt treten gleich an 3 Stellen Probleme mit Codierung/Charset auf:

In allen 3 Fällen wird UTF-8 verwendet, sowohl die Datenbank enthält UTF-8-Text, die message.properties, und auch die HTTP-Header und HTML-Metatags geben dem Browser die entsprechenden Infos.

Fall 1:

Beim Aufruf von "[(url)]ünchen" funktionierte es ohne Probleme, wenn ich das Projekt mit "grails run-app" starte...

println params gibt aus:

[q:München, action:index, controller:search]

Beim Installieren der App in Tomcat wird aber ausgegeben:

[q:München, action:index, controller:search]

Fall 2:

Ich habe mit "grails generate-all <class>" die Views für eine Klasse erzeugt.

Nun steht da auf dem Löschen-Button "Löschen" statt "Löschen", hat der Codierfehlerteufel wieder zugeschlagen. Bei anderen Views jeodch nicht.

Fall 3:

In einem anderen View wird bei value="${fieldValue(bean: placeInstance, field: 'name')}" die Methode encodeAsHTML() doppelt ausgeführt, aus "Straße" wurde "Stra&amp;szlig;e".
Bei Ändern durch "${placeInstance?.name}" wird encodeAsHTML() einmal aufgeführt.

Dabei wird "placeInstance" ganz normal dem View übergeben:

def editPlace = {
  def placeInstance = Place.get(params.id)
  ...
  render(view: "editPlace", model: [placeInstance: placeInstance])
}

Wie kann es sein, dass encodeAsHTML() manchmal generell bei ${...} ausgeführt wird, manchmal nicht?

Viele Grüße

Egon Schmid


Re: 3mal Codierungsprobleme :-(

milkyman - 19.08.2010 14:08
Zu 1:
Schau mal in der Tomcat Config, da kann man auch charset usw. einstellen. KA welche Tomcat Version du hast und wie die eingestelt ist. Ich meine mich zu entsinnen, dass wir alle Tomcats mal auf Latin1 umgestellt hatten, um die Umlaute zu bekommen. Evtl. ist das die Stellschraube die dir fehlt.

zu 2:
Wenn bei *einem* generate-all * auf einer View das Löschen ok und auf der anderen kaputt ist, finde ich das in der Tat sehr verwunderlich. Versuch es mal mit einem clean vorneweg und schau was dann passiert.

zu 3:
Es gibt in der Config.groovy ein paar Parameter zu dem Thema:
// The default codec used to encode data with ${}
grails.views.default.codec = "none" // none, html, base64
grails.views.gsp.encoding = "UTF-8"
grails.converters.encoding = "UTF-8"

Das sind die Default-Einstellungen bei 1.3.3, was hast du da stehen?

fieldValue encoded automatisch in HTML, wenn du den fieldValue in ${} stehen hast und oben als Default Codes "html", dann encoded es zweimal. Auch dein einmaliges Encoding bei nur {$variable} deutet darauf hin.


Insgesamt ist das Encoding allerdings in der Tat extrem unüberschaubar. Es wird langsam Zeit, dass es nur noch UTF-8 gibt und sonst nichts mehr. ;-)

Bei meinen glossy-templates habe ich mich schon mehrfach damit rumgeschlagen und finde auch jetzt immer wieder stellen, wo ich unsicher bin, ob richtig encoded wird. Neverending story...

Bye,
Horst


Re: 3mal Codierungsprobleme :-(

slyfox1972 - 19.08.2010 21:59
Danke, Horst, für die Tipps und Antwort.

Zu 3) muss ich sagen, es stehen in der Grails.config die Default-Werte wie angegeben drin.

Trotz
grails.views.default.codec = "none"
wird der Wert doppelt codiert. Ich hab mal testweise es mit
grails.views.default.codec = "html"
probiert, und - entgegen den Erwartungen - wird hier der Text im <input> richtig dargestellt.
Mir wird das ganze immer merkwürdiger, ich vermute einen Bug in Grails (1.3.3) oder einem Plugin.

Gruß

Egon Schmid


Re: 3mal Codierungsprobleme :-(

slyfox1972 - 25.08.2010 17:26
Zu 1)

Der Fehler liegt nicht an Tomcat, sondern am mod_jk.
Da ich dachte, mod_jk sei nur eine reine (Port-)Weiterleitung von Apache zu Tomcat und die Daten unverändert weiter geben würde, vermutete ich da keinen Fehler.

Manche Internet-Quellen sagen, man müsse in der Apache-Conf die Zeile
JkOptions +ForwardURICompatUnparsed
hinzufügen, doch das löst das Problem bislang noch nicht.

Zu 2) + 3)

Ein erneutes Erzeugen der Dateien mittels "grails generate-all" löste das Problem bei beidem.
Merkwürdig dabei ist nur, dass die Views vor- und nachher ziemlich verschieden sind...

Gruß

Egon Schmid


Re: 3mal Codierungsprobleme :-(

milkyman - 25.08.2010 17:38
bei uns isser so eingestellt, kA was es bedeutet, aber es funktioniert :-)
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

Bye,
Horst


Re: 3mal Codierungsprobleme :-(

slyfox1972 - 31.08.2010 12:54
Genau die Optionen waren bei mir auch eingestellt, scheint wohl die Default-Einstellung zu sein.

Also ich habe sämtliche Optionen probiert, keine brachte eine Änderung.

Beim Testen einer Seite mit URL-Parameter "?q=ÄÖÜäöüß" stellte ich fest, dass sowohl über Apache als auch direkt über Tomcat ein
request.getQueryString()
dasselbe Ergebnis liefert:
q=%C3%84%C3%96%C3%9C%C3%A4%C3%B6%C3%BC%C3%9F

Trotzdem ist params.q verschieden:

Bei Tomcat ist es richtig:
println params.q.encodeAsHTML()
// -> &Auml;&Ouml;&Uuml;&auml;&ouml;&uuml;&szlig;

Über Apache und Mod-JK bekomme ich:
&Atilde;&Atilde;&Atilde;&Atilde;&curren;&Atilde;&para;&Atilde;&frac14;&Atilde;

Kann ich irgendwie den Request-Header der HTTP-Anfrage anzeigen, um zu sehen, wo hier der Unterschied ist?

Gruß

Egon Schmid


Re: 3mal Codierungsprobleme :-(

milkyman - 31.08.2010 15:15
Echt dubios, was da passiert.

Request und Response kannst du dir komfortabel mit Firefox Live Http Headers anzeigen lassen. Alternativ manuell mit curl.

Bye,
Horst


Re: 3mal Codierungsprobleme :-(

slyfox1972 - 31.08.2010 21:20
milkyman schrieb:
-------------------------------------------------------
> Request und Response kannst du dir komfortabel mit
> Firefox Live Http Headers anzeigen lassen.
> Alternativ manuell mit curl.

Danke, aber das bringt mich hier nicht weiter, das zeigt mir nicht an, was das mod_jk am Request verändert.

Gruß

Egon


Re: 3mal Codierungsprobleme :-(

milkyman - 01.09.2010 12:07
Du willst sehen, was für ein Request am Tomcat ankommt?
Dann versuch es mal mit dem
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
in der Tomcat server.xml. KA was da ausgegeben wird, ist schon Jahre her, dass wir das mal benutzt haben. Aber vielleicht kannst du damit was anfangen.

Bye,
Horst


Re: 3mal Codierungsprobleme :-(

slyfox1972 - 01.09.2010 20:24
Danke, es gibt im Catalina.out sowas aus:

INFO: REQUEST URI       =/search/index
INFO:           authType=null
INFO:  characterEncoding=null
INFO:      contentLength=-1
INFO:        contentType=null
INFO:        contextPath=
INFO:             header=user-agent=Wget/1.12 (linux-gnu)
INFO:             header=accept=*/*
INFO:             header=host=localhost:8080
INFO:             header=connection=Keep-Alive
INFO:             locale=de_DE
INFO:             method=GET
INFO:          parameter=q=MÃ&#188;nchen
INFO:           pathInfo=null
INFO:           protocol=HTTP/1.0
INFO:        queryString=q=M%C3%BCnchen
INFO:         remoteAddr=192.168.178.10
INFO:         remoteHost=192.168.178.10
INFO:         remoteUser=null
INFO: requestedSessionId=null
INFO:             scheme=http
INFO:         serverName=localhost
INFO:         serverPort=8080
INFO:        servletPath=/search/index
INFO:           isSecure=false
INFO:           authType=null
INFO:      contentLength=-1
INFO:        contentType=text/html;charset=utf-8
INFO:            message=null
INFO:         remoteUser=null
INFO:             status=200

Was dabei höchst seltsam ist:
Wenn ich diese Zeile im server.xml hinzufüge, sind auch beim Aufruf direkt über Port 8080 die Zeichen falsch, genauso falsch wie über mod_jk, sowohl im Logals auch in der HTML-Ausgabe. Nehme ich die Zeile raus, stimmen sie wieder.
Klingt komisch, ist aber wirklich so.

Ich weiss nimmer, was ich machen soll, bin völlig ratlos.

Gruß

Egon Schmid


Re: 3mal Codierungsprobleme :-(

saurier - 01.09.2010 21:10
Hast du mal probiert mod_proxy statt mod_jk zu benutzen? Also nur um
sicherzugehen, dass es an mod_jk liegt.

Gruß,
Christian


Re: 3mal Codierungsprobleme :-(

christian - 01.09.2010 22:45
Hast du eine Kodierung bei der Konfiguration von mod_jk angegeben?

Gruß
Christian


Re: 3mal Codierungsprobleme :-(

klaus - 10.09.2010 13:11
Hallo,

ich hatte mal ähnliche Probleme mit UTF-8 im Tomcat. Bei mir hat's geholfen, in der "server.xml" in allen Connectoren, die für die Anwendung zuständig sind, Folgendes zu ergänzen:
<Connector port=bla... blablabla... URIEncoding="UTF-8"/>

Vielleicht hilft das ja weiter?

Viele Grüße,
Klaus.


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "3mal Codierungsprobleme :-(" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.