AW: AW: [otrs-de] E-Mails mit Anhängen

2007-01-24 Diskussionsfäden Jan Dielewicz
Hallo List,

endlich habe ich eine für mich akzeptable Lösung gefunden. Der ursprüngliche
Gedanke, als Storage-Modul für die Artikel das Filesystem zu verwenden, war
die Lösung. Allerdings habe ich zunächst immer einfach nur das Modul
gewechselt, um dann wie beschrieben mit völlig zerstörten Anhängen
dazustehen. Mehr durch Zufall wurde die Test-Maschine dann einmal zwischen
dem Umstellen und weiteren Tests neugestartet: Und plötzlich ging alles!
Inzwischen weiß ich, daß es reicht, den Webserver einmal neu zu starten. Nun
habe ich zwar ein etwas kompliziertes Backup- und Restore-Szenario, kann
dafür aber auch utf-8 verwenden.

Grüße
Jan


> 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).

AW: AW: [otrs-de] E-Mails mit Anhängen

2007-01-22 Diskussionsfäden Jan Dielewicz
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.
> >
> >