Libre Office - Writer

...ich hatte vor langer Zeit schon mal gefragt...

Habt Ihr eine Idee warum meine Nachrichten hier in der Liste grundsätzlich ohne korrekte Umlaute dargestellt werden wie in meiner Mail vom 12.12.18 09:52 Uhr (Im "Gesendet-Ordner" natürlich noch in Ordnung). An sonstige Empfänger passiert das nicht. Habe deshalb diese als Text und nicht HTML formatiert.

Zur Info:
Nutze die GMX-E-Mail-Seite!

Danke für eine Antwort.

Stefan

Liebe Nutzer,
 
warum wird über die Menüführung nur "Format>Abstand>Zeilenabstand>1, 1,5, 2 angeboten. Über das Symbol "Zeilenabstand einstellen>Abstand 1, 1,15, 1,5, 2, Benutzerdefinierter Wert..."
 
Ich habe nur zufällig die letztgenannte Möglichkeit gefunden!
 
Schönen Tag und schon heute frohe Weihnachten für alle!
 
Lieber Gruß
 
Stefan Seifried
 
Stefan Seifried Redaktionsbüro
Finanz- und Wirtschaftspresse
Mainstraße 3
D-63329 Egelsbach
Tel: 06253/8605897
Mobil: 0157/80707059
E-Mail: S.Seifried@gmx.de

Insofern als der Inhalt base64-codiert ist (aber kein html...) und die
Umlaute bereits darin vollständig fehlen, wird das wohl am GMX-Mailer
liegen müssen. Ich nehme an, der kann utf-8 nicht nach base64 codieren.
Schick Dir doch mal selber ne Mail, dann siehst Du höchstwahrscheinlich,
dass diese Liste nicht das Problem ist.
Ich würde das base64 auch weglassen, wenn es keinen zwingenden Grund
dafür gibt.

Gruß, oo

...ich hatte vor langer Zeit schon mal gefragt...

Habt Ihr eine Idee warum meine Nachrichten hier in der Liste grundsätzlich ohne korrekte Umlaute dargestellt werden wie in meiner Mail vom 12.12.18 09:52 Uhr (Im "Gesendet-Ordner" natürlich noch in Ordnung). An sonstige Empfänger passiert das nicht. Habe deshalb diese als Text und nicht HTML formatiert.

Im ersten Moment war ich geneigt zu sagen, dass das an deinem Client
liege, denn dieser Fehler liegt definitiv bereits in der Email vor. Wenn
ich den Body mittels eines anderen Dekodierers dekodiere, fehlen dort
die Umlaute genauso.

Allerdings ist mir dabei aufgefallen, dass darin auch der erst vom
Listenserver zugefügte Footer enthalten ist, d. h. dieser muss deinen
Body dekodiert, den Footer hinzugefügt und wieder kodiert haben. Dabei
muss der Fehler aufgetreten sein.

Du schreibst, dass deine Originalemial in HTML verfasst wurde (ich bin
ein ausgesprochener Unfreund dieser HTML-Manie; wenn ich mit
jemandem kommuniziere, dann interessieren mich in erster Linie seine
Ideen und Gedanken, nicht seine Vorstellungen von dem, was er als schön
betrachtet o. ä.; außerdem gips bei Plain Text auch gar keine
Möglichkeiten, einen Schadode zu verstecken, ein weiteres Argument gegen
HTML). Die hier angekommene Email angekommenen Email ist aber definitiv kein
HTML, noch nicht mal als multipart (was, *wenn* überhaupt HTML, dann die
absolute Mindestanforderung sein sollte).

Daher vermute ich immer noch (oder wieder), dass es an dem von dir verwendeten
Client liegt, welcher irgend welche, hmm, ich will es mal als unkonventionelle
Tags bezeichnen, verwendet, die der Konverter nicht verarbeiten kann.

Zur Info:
Nutze die GMX-E-Mail-Seite!

Gmx ist nicht gerade bekannt dafür, dass es sich sehr eng an
Konventionen hält; die kochen gerne mal ihr eigenen Süppchen. Allerdings ist
mir ein solches Fehlerbild schon lange (überhaupt?) nicht mehr
untergekommen.

Ich habe nur zufällig die letztgenannte Möglichkeit gefunden!

Dabei solltest du bleiben; oder dir besser gleich einen richtigen Reader
wie Thunderbird o. ä. zulegen. Der kann auch multipart (d. h. HTML *und*
Plain Text in einem).

Schönen Tag und schon heute frohe Weihnachten für alle!

Du mich auch. :wink:

Wolfgang

Hallo Stefan,

Es wird schon daran liegen, dass diese Liste nur Text-Mails verträgt
und nicht HTML. Bei TExt Format werden die Umlaute abhängig vom Code als
Zeichen mit Code-abhängigem Hexadezimalwert dargestellt. Bei HTML als
Zeichenfolge, z.B. Ä als Ä

Helmut

Es wird schon daran liegen, dass diese Liste nur Text-Mails verträgt
und nicht HTML.

Seine Ursprungsmail kam hier auch schon als Textmail an. Zwar base64 kodiert,
aber ohne HTML-Formatierung.

Bei TExt Format werden die Umlaute abhängig vom Code als
Zeichen mit Code-abhängigem Hexadezimalwert dargestellt. Bei HTML als
Zeichenfolge, z.B. Ä als Ä

Kann - muss aber nicht so sein. Sofern die HTML-Datei selber im UTF-8 Format
gespeichert wurde und zu Beginn der Datei folgende Zeile steht:
<?xml version="1.0" encoding="UTF-8"?>

Dann kann man sich die alte &uml-Krücke sparen, wenn man will.

- --

MfG Richi

Musst du Google sagen (man "Nutze die GMX-E-Mail-Seite"); aber ob die
auf dich hören, wage ich doch gelinde [tm] zu bezweifeln.

Wolfgang

Ich hab mittlerweile einige Mails direkt erhalten, und es spricht
einiges dafür, dass

- wie Wolfgang schon beobachtet und belegt hat, die Liste eine
Recodierung vornimmt
- Der Listenprozessor alles nach base64 codiert, was utf8 ist (andere
Charsets kommen so durch)
- Und er ebenfalls vorher HTML strippt, und zwar ziemlich gnadenlos
alles in spitzen Klammern und alle &xuml; (die in den originalen
gmx-Mails verwendet werden) einfach entfernt.

Insofern ist tatsächlich anders, als ich zunächst dachte,
höchstwahrscheinlich der Listenprozessor der Schuldige.

Gruß, oo

Die Schuld lässt sich immer sehr leicht jemandem in die Schuhe schieben,
besonders wenn man nicht genug Fakten hat. Ich zum Bleistift kann mir
mindestens genauso gut vorstellen, dass die Deklarierung des
HTML-Formats in den Email-Headern fehlerhaft sein könnte.

Wolfgang, der aber grundsätzlich der Meinung ist, dass HTML in Emails
sowieso nix verloren hat, insofern ist das eh eine nur akademische
Diskussion