rbitdd
Returning Responder

Nach Umzug Umlaute defekt

Jump to solution

Hallo Community,

ich musste gestern abend das Projekt von unserem Entwicklungsserver auf den Server des Kunden übertragen, damit diese Contents pflegen können.

Jetzt ist mir aber leider aufgefallen, dass die Umlaute alle defekt sind.

Das Projekt ist in UTF-8 aufgesetzt (Definition in HTML-Template und Projekteinstellungen gesetzt).

Zu erst dache ich, dass es an falschem Encoding der Datenquellen liegt. (Diese waren tatsächlich in ISO)

Jedoch nach dem ich diese Umgebogen habe, haben auch Tests mit neuen Einträgen leider nicht den gewünschten Erfolg gebracht. Smiley Sad

Ein Kollege hat sich mit mir dann die Header angeschaut und wir mussten feststellen, das beim Ausliefern auf dem Kundensystem explizit ISO übertragen wird:

Content-Type    text/html; charset=iso-8859-1
Content-Length    17759
Server    Jetty(6.1.10)

auf unserem System steht bei Content-Type nur text/html.

Hat jemand ne Idee, wo ich das umstellen kann bzw. ob ich etwas anderes falsch gemacht habe. 😞

Thanks in advance!

0 Kudos
1 Solution

Accepted Solutions
rbitdd
Returning Responder

Ich habe das Problem gestern mehr oder weniger gelöst:

Ich habe in jeder Text-Eingabe-Komponente convert="standard" gesetzt und an den Stellen, bei denen das nicht gereicht hat (z.B. Navigation) habe ich bei der Ausgabe noch ein .convert dran gehangen (z.B. #nav.label.convert)

Ich frage mich, wenn ein Parameter schon "standard" heißt, warum dieser explizit angegeben werden muss Smiley Sad

Kann man das irgendwo einstellen, oder darf ich hierzu einen FR öffnen?

Ich frage mich aber trotzdem, warum es auf unserem Server funktioniert und auf dem vom Kunden nicht.

View solution in original post

0 Kudos
14 Replies
hoebbel
Crownpeak employee

Geht es um JSP Seiten?

Wenn ja, ist das Encoding sowohl für jsp als auch html gesetzt?

Beispiel:

<%@ page contentType="text/html; charset=UTF-8" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8">
</head>
<body>
</body>

</html>

0 Kudos
rbitdd
Returning Responder

Ach so, Verzeihung, nein, es geht nicht um JSP-Seiten.

Es handelt sich hier um PHP bzw. statischen HTML-Seiten.

Ich könnte aber analog versuchen einen PHP-Header zu senden.

Ich wundere mich halt, wo der Unterschied in den Konfigurationen ist, das mal der eine Header vom Jetty gesendet wird und mal der andere. 😕

0 Kudos
hoebbel
Crownpeak employee

Vergleichen Sie bitte mal die beiden

<FirstSpiritROOT>/conf/fs-webapp.xml

Dateien. Finden Sie da unterschiedliche Encodings?

Wenn nicht, wie sieht es mit

<FirstSpiritROOT>/server/jetty/webdefault.xml

aus?

0 Kudos
rbitdd
Returning Responder

Bis auf einen Unterschied bzgl. einer auskommentierten fehlenden/vorhandenen Klammer sind die Dateien identisch.

0 Kudos
rbitdd
Returning Responder

OK, jetzt wird es ganz verwirrend:

Nachdem ich in dem PHP-Header folgendes hinzugefügt habe

"header('content-type: text/html; charset: utf-8');"

erhalte ich jetzt diesen Header:

Content-Typetext/html; charset: utf-8; charset=ISO-8859-1
Content-Length17759
ServerJetty(6.1.10)

Das wird ja immer schlimmer.

0 Kudos

Haben Sie in Ihren Seiten auch ein entsprechendes Html Metatag gesetzt?

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

oder auch so

<meta http-equiv="Content-Type" content="text/html; charset=$CMS_VALUE(#global.encoding)$" />

Hier muss dann das entsprechende Sprachencoding "UTF-8" sein.

0 Kudos
rbitdd
Returning Responder

Ja, das ist gesetzt

0 Kudos
aVogt
Returning Creator

Ich hatte das Problem auch mal, aber keine Ahnung, wass ich damals gemacht habe Smiley Sad

Zumindest habe ich keinen "Aktiven-Web-Server" in den Projekteinstellungen->Web-Komponenten->Vorschau

Das Encoding unter Sprachen ist sicher auf UTF-8 gesetzt

0 Kudos
rbitdd
Returning Responder

Ich habe das Problem gestern mehr oder weniger gelöst:

Ich habe in jeder Text-Eingabe-Komponente convert="standard" gesetzt und an den Stellen, bei denen das nicht gereicht hat (z.B. Navigation) habe ich bei der Ausgabe noch ein .convert dran gehangen (z.B. #nav.label.convert)

Ich frage mich, wenn ein Parameter schon "standard" heißt, warum dieser explizit angegeben werden muss Smiley Sad

Kann man das irgendwo einstellen, oder darf ich hierzu einen FR öffnen?

Ich frage mich aber trotzdem, warum es auf unserem Server funktioniert und auf dem vom Kunden nicht.

0 Kudos