Verwenden von Text / Markdown in E-Mails

387
Crissov

Muss ich mit Problemen bei den Empfängern rechnen, wenn ich begonnen habe, einteilige E-Mails Content-Type: text/markdown; charset=UTF-8;gemäß den RFCs 7763 und 7764 zu versenden ? Ich glaube, es sollte sicher auf den Standard zurückfallen text/plain.

Es gibt verschiedene Möglichkeiten, wie E-Mail-Clients Markdown / Commonmark oder verwandte Sprachen unterstützen können . Ich spreche hier von Übertragung und der resultierenden Anzeige .

Eingang

  • Konvertieren Sie Sternchen, Unterstriche usw. die Benutzereingaben mit der Tastatur in HTML-Tags (oder theoretisch jedes andere Rich-Text-Format) und senden Sie die E-Mail als mehrteilige Nachricht mit text/plainund text/html.
  • Wie oben, bieten aber auch GUI-Buttons oder Tastenkombinationen (zB foo+ CtrlI⇒ _foo_) an, um die Eingabe dieser Formate zu erleichtern. Dies ist im Grunde ein Rich-Text-Editor, der einen besseren Klartext-Fallback als die meisten derzeit erzeugt.

Beide können keine, Inline-, Side-by-Side- oder Vorabgabe-Vorschauen des gerenderten Textes verwenden.

Das können Plugins wie Markdown Here und einige (Web-) Mail-Clients nativ unterstützen, z. B. Airmail, Mail Mate, Mailspring, Gmelius, Cypht . Einige Newsletter-, Admin-, Ticket- oder Shop-Systeme, die selbst E-Mails versenden, können auf diese Weise auch mit Markdown-Eingaben umgehen.

Getriebe

  • Senden Sie einteilige Nachrichten text/markdownanstelle des Standards text/plainund verlassen Sie sich auf den Rückfall auf den letzteren. Darum frage ich!
  • Senden Sie mehrteilige Nachrichten mit text/markdownanstatt text/htmlden text/plainNachrichtentext zu duplizieren .
  • Senden Sie mehrteilige Nachrichten mit generierter text/htmlund text/markdownanstelle der üblichen text/plainBasisversion.

Mail Mate und Groups.io können einen Header-Parameter wie folgt hinzufügen:

Content-Type: text/plain; format=flowed; markup=markdown

Anzeige

  • Empfangene einteilige E-Mails anzeigen, für die die entsprechende text/markdownKopfzeile als Text angegeben wurde text/plain. Dies ist der erwartete anmutige Rückfall.
  • Erhaltene einteilige oder mehrteilige E-Mails, deren Content-TypeKopf mit einem text/markdownTyp oder markup=markdownParameter festgelegt ist, als Rich-Text mit entfernten Formatierungszeichen anzeigen.
  • Zeigen Sie empfangene einteilige E-Mails an, die bestimmte Heuristiken bestehen, um zu bestimmen, dass sie gemäß Markdown oder anderen LML- Konventionen als Rich-Text geschrieben wurden und möglicherweise Formatierungszeichen enthalten.

Viele Clients, z. B. Apple Mail, unterstützen das Rich Text-Rendering einer einzelnen Markdown-Funktion: Blockieren Sie Zitate mit (möglicherweise verschachtelten) >am Anfang der Zeile.

1

2 Antworten auf die Frage

1
harrymc

Markdown wurde auf verschiedene Arten und Geschmacksrichtungen implementiert. Wikipedia listet Standard, CommonMark, GFM und Markdown Extra auf, aber jede Implementierung selbst desselben Standards kann unterschiedliche Ergebnisse für denselben Markdown-Text ergeben ( Beispiel ).

Trotz der neuen RFCs gibt es keinen offiziellen Standardtyp für E-Mails, text/markdownscheint jedoch der häufigste De-facto-Typ zu sein. Die meisten Browser und andere einigermaßen anspruchsvolle Clients werden den text/Teil und den Standardwert text/plainohnehin wahrscheinlich sehen. Es gibt also keinen großen Unterschied in Bezug auf E-Mail.

Wenn Sie sich die Liste der Markdown-Implementierungen ansehen, werden Sie feststellen, dass nicht einmal ein E-Mail-Client oder -Server darin enthalten ist.

Es gibt Websites, die Ihren Markdown in HTML umwandeln und Ihnen die E-Mail senden, zum Beispiel den kommerziellen Gmelius, und PHP verfügt auch über einige Markdown-Module. Konverter sind jedoch die meisten, die Sie erwarten können.

Laut den Kommentaren von @grawity gab es unter den getesteten E-Mail-Clients nur Thunderbird als Rohdaten, um angezeigt zu werden. Die anderen haben den Markdown einfach in einem Anhang gesammelt. Dies bedeutet, dass nur Thunderbird dem text/Teil in Content-Type Beachtung geschenkt hat, während die anderen nur die gesamte MIME-Spezifikation behandelten, die für sie unbekannt war, da sie Markdown nicht verstehen.

Ich glaube nicht wirklich, dass die Verwendung von Markdown aus heutiger Sicht eine gute Idee ist, da die Inkorporationswelle des Markdowns die E-Mail-Clients nicht erreicht hat und möglicherweise nie erreicht. In jedem Fall kann der w3.org E-Mail-Client gemäß dem obigen Link nicht korrekt damit umgehen. Es hat also keinen Sinn.

Den Kommentar von @grawity finden Sie in meiner Antwort. Anscheinend werden die meisten E-Mail-Clients * nicht * auf den Textmodus zurückgreifen, sondern den Markdown als Anhang anzeigen. Berend vor 5 Jahren 0
Sie geben eigentlich nur meine Bedenken an: Sie sollten sich anmutig zurückziehen, aber ist das wirklich so? Ich erwarte (noch) keine Kunden, die den Markdown-Code in Rich-Text-Formatierungen konvertieren. Crissov vor 5 Jahren 0
Ich habe vorsichtig versucht, die Nachricht weiterzuleiten, dass sich das Thema in der Evolution befindet, aber momentan nicht empfohlen wird. harrymc vor 5 Jahren 0
Der Betreff ist nicht wirklich Markdown - es ist das MIME-Handling der Mail-Clients im Allgemeinen. Wenn ein Client `text / *` Fallback unterstützt ("... wird sonst wegen des Textes / Teils in den Textmodus zurückgesetzt"), dann hätte es _regardless_ von Markdown unterstützt: mit `text hätte es dasselbe getan / rtf`, `text / angereichert`,` text / futhark`. grawity vor 5 Jahren 1
@ grawity: Meine Vermutung ist, dass ein strenger E-Mail-Client, der nur mit bekannten Inhaltstypen umgeht, diese in einem Anhang in der ursprünglichen Form enthält. Thunderbird ist möglicherweise der einzige Client, den Sie getestet haben, der den `text /` -Partikel intelligent betrachtet und entscheidet, dass der Inhalt für die Anzeige gut genug ist. harrymc vor 5 Jahren 0
Wenn @ grawitys Kommentare zu einer Antwort zusammengefügt würden, würde ich sie akzeptieren. Crissov vor 5 Jahren 0
Habe es getan und hoffe, dass @grawity zustimmt. harrymc vor 5 Jahren 0
0
Berend

Wenn die Mail einteilig sein muss, kann sie nicht auf Text / Plain zurückgreifen, da es nur den Markdown-Teil gibt. Sie sind vollständig von der Abschriftenunterstützung des E-Mail-Clients des Empfängers abhängig. Bei mehrteiligen Nachrichten, die sowohl Text / Markdown als auch Text / Plain enthalten, könnte dies wahrscheinlich funktionieren. Hast du das tatsächlich versucht?

Ich bin nicht sicher, welche Unterstützung Markdown derzeit für E-Mail-Clients bietet, aber ich habe das Gefühl, dass es noch nicht allgemein akzeptiert wird. Abgesehen von dieser eher alten Seite kann ich nichts finden.

Ich habe gerade versucht, diese Nachricht in Outlook zu öffnen (als .emlDatei gespeichert). Es wird als leere Nachricht mit einem Textanhang angezeigt:

From: John Doe <example@example.com> MIME-Version: 1.0 Content-Type: text/markdown  # this is the body text
Ich denke, das OP bedeutete eine andere Art von Fallback - nicht mehrteilig, sondern einfacher Fall, wenn der Inhalt (Quellcode) ohne Interpretation angezeigt wird, wenn der bestimmte Untertyp nicht erkannt wird. Wenn beispielsweise ein Client, der HTML nicht unterstützt, eine Nur-Text- / HTML-Nachricht erhält, wird er sie ohnehin (als unformatierte HTML-Tags) anzeigen. grawity vor 5 Jahren 1
@Grawity Ja, das ist mir auch eingefallen, aber wir können uns nicht sicher sein. Outlook tut das zumindest nicht. Berend vor 5 Jahren 0
(Schnelle Versuchsergebnisse: Thunderbird ist das einzige Programm, das Text / Markdown als Rohdatenquelle darstellt; die meisten anderen Clients zeigen es als Anhang.) grawity vor 5 Jahren 1
@grawity Ja, genau davor hatte ich Angst. Es sollte sich zurückziehen, aber bei einigen / vielen Kunden wird es nicht funktionieren. Schließlich komponiere ich meine schmerzenden Text-E-Mails bereits mit Markdown-Formatierung. Senden Sie sie einfach als "text / plain". Ich * möchte * nicht, dass sie auf meiner Seite in HTML konvertiert werden und als "Text / HTML" gesendet werden. Crissov vor 5 Jahren 0

Verwandte Probleme