Hallo Nico, Nico Grubert schrieb:

Hallo zusammen,

unser OTRS (2.1.1) läuft mit default encoding "utf-8". Config.pm -> $Self->{DefaultCharset} = 'utf-8';

Als Backend kommt Postgres 8.1.4 zum Einsatz. Nachdem ich die 3 SQL Scripte ausgeführt habe, wie es in der Installations-Doku von OTRS beschrieben ist, sehe ich, dass alle Einträge in der DB Table "auto_response" als charset 'iso-8859-1' haben. Dies führte dazu, dass in den verschickten Emails die Umlaute nicht richtig dargestellt werden, was ja logisch ist, da die Daten in utf-8 vorliegen, aber der Mailheader iso-8859-1 verwendet. Daher habe ich mit dem SQL Statement update auto_response set charset = 'utf-8'; allen Einträge in der DB Table "auto_response" das charset "utf-8" gegeben. Danach werden die Umlaute in den Emails auch richtig angezeigt.

Ist es gewollt, dass man dies manuell machen muss, obwohl das Default Charset in Config.pm auf "utf-8" gesetzt ist? Ich habe gesehen, dass auch noch in anderen Tabellen (notifications->notification_charset) "iso-8859-1" verwendet wird. Ist das gewollt?

Ich sehe da zunächst keinen Widerspruch. In der DB sind gewisse Notificationtexte in iso-8859-1 gespeichert. Diese werden vom OTRS verwendet, wobei jedoch OTRS dann zwingend eine Zeichensatztransformation durchführen muss, falls der Zeichensatz der Vorlage nicht mit dem zu verwendenden Zeichensatz überieinstimmt. Unser OTRS läuft auch unter utf-8 (unter MySQL 4.1), die Notifications verbleiben im Original-Zeichensatz (iso). Die von Dir oben beschriebenen Probleme treten bei uns jedoch nicht auf! Den Hinweis von Andre, dass durch kurzes "Modifizieren" sprich nur Speichern der Notification im WebGUI deren Zeichensatz geändert wird, kann ich bestätigen.

Kleiner Hinweis noch am Rande: Im DB Design unter ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png steht in der DB Table "auto_response" übrigens "charset_id" als smallint und nicht "charset" als varchar wie es in OTRS 2.1.1 erstellt wird.

Besten Dank im voraus, Nico

Ciao, Alexander