Hallo Alexander, Danke für Dein Feedback! Nach weiteren Tests mit einer anderen Installation (MySQL und SQL Server 2000 parallel) kann ich nun mit Sicherheit sagen, daß dies ein Problem mit dem MS SQL Server ist (- dabei ist die Version offensichtlich egal: sowohl 2000 als auch 2005 sind betroffen): Mit utf-8 als DefaultCharset werden (meiner Erfahrung nach) alle Anhänge, die per E-Mail ins System kommen zerstört (Ausnahme sind die HTML-Teile einer E-Mail, hier werden nur die Sonderzeichen fehlerhaft dargestellt). Mit iso-8859-? funktionieren die E-Mail-Anhänge einigermaßen, einzelne werde aber auch hier zerschrotet. Auffällig bleibt, daß alle Dateien, die von intern kommen (z.B. als Notiz-Anhang), ok sind, völlig unabhängig vom eingestellten DefaultCharset. Ich versuche nun herauszufinden, wie man OTRS beibringen kann, die E-Mail-Anhänge genauso zu behandeln (werden die vielleicht gar nicht mit einem Zeichensatz en-/decodiert?). In meiner naiven Vorstellung müßte dies das Problem lösen. Leider fehlt mir hierzu ein bißchen der Überblick über die Modularchitektur und das nötige Perl-Wissen. Ach ja: Was mich völlig verwirrt, ist die Tatsache, daß nach dem Umstellen des ArticleStorage auf Filesystem ausnahmslos alle Anhänge kaputtgehen. Verwende ich allerdings MySQL, funktioniert auch das. Ich könnte mir vorstellen, daß gar nicht die Dateien kaputt gehen, sondern die Meta-Daten in der SQL-DB falsch abgelegt werden. Das muß ich mir noch genauer ansehen. Grüße Jan
Deine Problembeschreibung hat mich aufschrecken lassen, darum habe ich auf meinem System Test durchgeführt:
Systemcharakteristiken: * OTRS v2.1.4 im UTF-8-Modus auf SuSE 9.3 * StorageFS mit ISO-Dateinamenskodierung (nicht UTF8!) * MySQL 4.1.x mit DB auf UTF-8
Beachte: Damit der UTF-8-Modus korrekt fkt. musste ich OTRS patchen: bei jedem Verbindungsaufbau zur DB gebe ich zusätzlich explizit die Angabe mit das der Perl-DB-Client unter utf-8 läuft, da sonst fälschlicherweise angenommen wird das der Perl-DB-Client unter ISO läuft. Resultat wären dann ene doppelt-UTF-8-encodede Speicherung in MySQL.
Test: Versand eines Mails ink. Umlauten im Body und Word-Attachment (1 Seite mit Screenshot). Beide Varianten funktionieren - korrekte Umlaute-Darstellung und Attachment fkt.
#####
Variante 1 - UTF-8-Mail:
Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable
Attachment:
Content-Type: application/msword; name="Dok1.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Dok1.doc"
#####
Variante 2 - ISO-Mail:
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Attachment:
Content-Type: application/msword; name="Dok1.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Dok1.doc"
#####
Soviel zur Info.
Ciao, Alexander
Jan Dielewicz schrieb:
Ein bisschen bin ich weitergekommen:
leider habe ich ein sehr ernstes Problem: Alle Anhänge die per Mail den Weg ins System finden werden zerstört (getestet habe ich jpg, pdf, doc, xls). Anhänge, die aus dem System verschickt werden oder einer Notiz beigefügt werden, sind ok. Ich habe noch nicht versucht die Article im Filesystem zu speichern, da dies den Backup/Restore-Prozeß verkompliziert. Könnte das helfen?
Hier die 'technischen Daten': OTRS 2.1.4 (ursprünglich mit Win-Installer installiert) (DefaultCharset: utf-8) Win2003 Server (Codepage: SQL_Latin1_General_CP1_CI_AS) MSSQL 2005
Meine Vermutung, dass das Ganze eine Zeichensatzproblematik sein könnte, hat sich bestätigt: Ich habe jetzt, den DefaultCharset nacheinander auf iso-5589-1, iso-5589-2 und iso-5589-15 umgestellt - und siehe da, die Anhänge sind intakt!
Allerdings, werden jetzt die Texte in den Tickets nicht mehr alle richtig dargestellt (Sonderzeichen). Dies ließe sich beheben, in dem man dem IE, die Unicode utf-8 Codierung vorgibt. Allerdings bleibt dann die Sonderzeichenproblematik z.B. bei Antworten auf Mails, die in anderen Zeichensätzen erstellt worden. Hier werden dann die Sonderzeichen in den Inlinezitaten falsch dargestellt. Außerdem sind dann die Sonderzeichen in den Label der OTRS-Elemente (also die z.B. Links) auch wiederum falsch dargestellt.
Weiß jemand, ob utf-8 generell mit Anhängen nicht klarkommt, oder ob ich beim SQL-Server etwas ändern muß? Oder anders gefragt: Gibt es eine Kombination, in der sowohl die Anhänge heile bleiben und auch die Sonderzeichen gut aussehen?
Ein Ansatz könnte sein: Die DB dumpen -> UTF-8 konvertieren, die DB des SQL-Servers auf UTF-8 umstellen und dann importieren.
Daß dies ein generelles Problem der DB ist glaube ich eigentlich nicht, da alle Dateien, die nicht als Anhang einer externen Mail angekommen sind, intakt sind (z.B. FAQ-Artikel, Anhänge an Notizen oder Anhänge an Antworten die vom System aus verschickt werden). Im Augenblick sieht es für mich nach einem Problem 'in der Nähe von' \Kernel\System EmailParser.pm und Encode.pm aus. So wie sich mir die Sache darstellt, wird immer der DefaultCharset zum Encodieren der Mails verwendet. Das entspricht nicht meiner Erwartung. Eigentlich müssten in Abhängigkeit des jeweiligen E-Mail-Teils unterschiedliche Zeichensätze verwendet werden - so sieht zumindest die Logik in den beiden genannten Dateien für mich auf den ersten und zweiten Blick aus. Das Ganze führt dazu, dass utf-8-Mails (also der Mail-Body) richtig dargestellt werden, wenn der DefaultCharset auf utf-8 steht. Dann allerdings sind die Anhänge kaputt. Wenn der DefaultCharset auf iso- 8859-1 oder iso-8859-15 steht, wird der Text von utf-8-Mails falsch dargestellt, aber die Anhänge sind intakt.
Ich werde mich weiter mit dem Problem befassen und meine Lösung, so ich sie denn finde, mitteilen.
Ich bin natürlich weiterhin für jeden Hinweis dankbar...
Grüße Jan