mehrzeiligen Link in plain text mail

[Testerlein]

Hallöle,

wie muss ein Link in einer plain text mail eingegeben werden, damit er vom Mail-Client als Link erkannt wird, auch wenn der Links sehr lang ist und demnach in der Anzeige bei den 72 Zeichen umgebrochen wird(ich verwende KMail, aber ich denke es gibt eine Syntax, die gängig unterstützt wird für Linksi in plain text mails)

http://frog.isima.fr/cgi-bin/bruno/tex2png--10.cgi?\frac{1}{\sqrt[16]2}}%20\cdot%20e%20^%20{%20i%20(%20\frac{1}8}%20\cdot%20\frac{5%20\pi}{12}%20+%20k%20\cdot%20\frac{2%20\pi}{8}%20)%20}

Muss der Link in < und > oder in " " oder gibt's da was? Bisher habe ich keine Lösung gefunden..

Grüße

[Testerlein]

http://frog.isima.fr/cgi-bin/bruno/tex2png--10.cgi?\frac{1}{\sqrt[16]{2}}%20\cdot%20e%20^%20{%20i%20(%20\frac{1}{8}%20\cdot%20\frac{5%20\pi}{12}%20+%20k%20\cdot%20\frac{2%20\pi}{8}%20)%20}

Der Link bricht bei mir bei KMail immer nach cgi- um und Der Link wird dann nur über die URL bis cgi- gelegtt, bin/bruno in der nächsten Zeile wird als normaler Text erkannt und nicht mit zum Link übernommen..

[Der Martin]

Hi,

wie muss ein Link in einer plain text mail eingegeben werden, damit er vom Mail-Client als Link erkannt wird, auch wenn der Links sehr lang ist und demnach in der Anzeige bei den 72 Zeichen umgebrochen wird(ich verwende KMail, aber ich denke es gibt eine Syntax, die gängig unterstützt wird für Linksi in plain text mails)

es gibt in Plaintext keine Links. Es gibt aber Mailclients, die automatisch erkennen, wenn etwas so aussieht, als könnte es eine URL sein, und dann automatisch einen klickbaren Link daraus machen.
Voraussetzung dafür ist, dass dieser Teil nicht schon vom *sendenden* Mailclient durch einen Zeilenumbruch verstümmelt wird. Da liegt nämlich meist der Hase im Pfeffer.

Stelle also deinen Mailclient so ein, dass er nicht nach 72 Zeichen einen Zeilenumbruch einfügt, sondern den Text unverändert lässt und am Fensterrand *nur für die Anzeige* umbricht.

Ciao,
 Martin

[Deus F (noreg)]

Muss der Link in < und > oder in " " oder gibt's da was? Bisher habe ich keine Lösung gefunden..

Ja, da gibt es was. Wenn ich es richtig im Kopf habe schließt man es in das Pseudoelement <LINK>https://lange-url.example.org/example</LINK> ein. So jedenfalls meine grobe Erinnerung, es gibt zumindest genügend Clients, die das dann eben ohne Zeilenumbrüche (oder sogar ohne Whitespace?) lesen.
Und sollte ich mich irren ist es zumindest erkennbar was gemeint ist XD

Die Syntax mit https://example.org habe ich aber auch schon gesehen, jedoch nur von Apple-Mail IIRC.

[Der Martin]

Hallo,

Muss der Link in < und > oder in " " oder gibt's da was? Bisher habe ich keine Lösung gefunden..
Ja, da gibt es was. Wenn ich es richtig im Kopf habe schließt man es in das Pseudoelement <LINK>https://lange-url.example.org/example</LINK> ein. So jedenfalls meine grobe Erinnerung, es gibt zumindest genügend Clients, die das dann eben ohne Zeilenumbrüche (oder sogar ohne Whitespace?) lesen.

wo hast du das denn her? Das ist mir völlig neu.

Die Syntax mit https://example.org habe ich aber auch schon gesehen, jedoch nur von Apple-Mail IIRC.

Auch Outlook macht das gern - vor allem doppelt, also denselben Link einmal mit und einmal ohne die spitzen Klammern. Sieht immer wieder blöd aus, wenn man den Text dann mit einem Nicht-Outlook-Mailclient liest.

"Und besuchen Sie auch unseren Webshop unter http://www.example.org/shop http://www.example.org/shop!"

So long,
 Martin

[Alexander (HH)]

Moin Moin!

Wenn ich mich recht erinnere, empfiehlt irgendeine RFC, URLs in Plain Text links mit <URL: und rechts mit > einzuschließen, als deutlichen Hinweis darauf, die URL als Link darzustellen und keinen Umbruch einzufügen.

Du würdest also mittem im Fließtext URL:http://frog.isima.fr/cgi-bin/bruno/tex2png--10.cgi?\frac{1}{\sqrt[16]2}} \cdot e ^ { i ( \frac{1}8} \cdot \frac{5 \pi}{12} + k \cdot \frac{2 \pi}{8} ) } einfügen, so wie ich in diesem Satz. In gängigen Mailclients sollte das dann als klickbarer Link angezeigt werden.

Alexander

[Testerlein]

Das mag zumindest KMail nicht. Auch mit dieser Syntax wird nur der erste Teil als Link erkannt und umgesetzt..

Auch alle anderen Methoden hier.

Ich muss bei Erhalt von Mails in plain text mit Links immer den Link händisch kopieren..

Grüße

PS.
Hat jemand die RFC oder ähnlich für <URL: und > gefunden?

[Alexander (HH)]

Moin Moin!

Das mag zumindest KMail nicht. Auch mit dieser Syntax wird nur der erste Teil als Link erkannt und umgesetzt..

Thunderbird 8 erkennt die nackte URL bis zur ersten geschweiften Klammer als Link, in URL:... verpackt und in <...> verpackt die gesamte URL. Novell Groupwise 7 (*schauder*) erkennt alle drei Varianten.

Mal so am Rande: Ich finde es merkwürdig, dass in der URL geschweifte Klammern vorkommen, nach meinem Bauchgefühl müßten die escaped werden, d.h. %7B und %7D. RFC1718, Punkt 2.2, sieht das ähnlich:

Unsafe:

Characters can be unsafe for a number of reasons.  The space
   character is unsafe because significant spaces may disappear and
   insignificant spaces may be introduced when URLs are transcribed or
   typeset or subjected to the treatment of word-processing programs.
   The characters "<" and ">" are unsafe because they are used as the
   delimiters around URLs in free text; the quote mark (""") is used to
   delimit URLs in some systems.  The character "#" is unsafe and should
   always be encoded because it is used in World Wide Web and in other
   systems to delimit a URL from a fragment/anchor identifier that might
   follow it.  The character "%" is unsafe because it is used for
   encodings of other characters.  Other characters are unsafe because
   gateways and other transport agents are known to sometimes modify
   such characters. These characters are "{", "}", "|", "", "^", "~",
   "[", "]", and "`".

All unsafe characters must always be encoded within a URL.

Also ist das, was Du uns bislang als URL verkauft hast, nur Zeichensalat.

Korrekt encoded dürfte die URL http://frog.isima.fr/cgi-bin/bruno/tex2png--10.cgi?%5Cfrac%7B1%7D%7B%5Csqrt%5B16%5D2%7D%7D%20%5Ccdot%20e%20%5E%20%7B%20i%20%28%20%5Cfrac%7B1%7D8%7D%20%5Ccdot%20%5Cfrac%7B5%20%5Cpi%7D%7B12%7D%20%2B%20k%20%5Ccdot%20%5Cfrac%7B2%20%5Cpi%7D%7B8%7D%20%29%20%7D lauten.

Und so encodiert akzeptieren GW und TB alle drei Schreibweisen als Link.

Alexander

[Testerlein]

Danke für Deine Antwort.

Ich hatte den Link so aus der Adresszeile von Chromium kopiert. Ich weiß auch nicht, warum dieser dann nicht escaped war..?

Aber auch so vollständig escaped erkennt kmail den Link nur bis cgi-
Komisch, das ist ja schon ärgerlich..

Gibt es die RFC für <URL: > irgendwo? Habe nichts ergooglen können..

Grüße

[Alexander (HH)]

Moin Moin!

Ich hatte den Link so aus der Adresszeile von Chromium kopiert. Ich weiß auch nicht, warum dieser dann nicht escaped war..?

Schlecht kopierte schlechte Firefox-Idee? Der FF kopiert wenigstens noch die komplett kodierte URL, auch wenn er einige Sequenzen vor der Anzeige decodiert. Vielleicht kopiert Chromium stumpf, was angezeigt wird?

Aber auch so vollständig escaped erkennt kmail den Link nur bis cgi-
Komisch, das ist ja schon ärgerlich..

Vielleicht heißt kmail ja kaputt-mail ... ;-)

Gibt es die RFC für <URL: > irgendwo? Habe nichts ergooglen können..

Ich auch nicht, war wohl ein falsch verwachsenes Neuron. Das werd' ich dann mal veröden -- *brutzel*

Alexander

[Alexander (HH)]

Moin Moin!

Gibt es die RFC für <URL: > irgendwo? Habe nichts ergooglen können..

Das Format ist innerhalb der RFCs selbst relativ beliebt, erstmals taucht es in RFC1738 auf, dann gleich 30 mal. Das ist nicht weiter verwunderlich, denn RFC1738 beschreibt genau die URLs. Und *TADAA!*, im Anhang auf Seite 21  ist dann auch lang und breit diskutiert, wie man URLs in verschiedenen Kontexten (sprich: Plain Text) verpacken soll:

APPENDIX: Recommendations for URLs in Context

URIs, including URLs, are intended to be transmitted through
   protocols which provide a context for their interpretation.

In some cases, it will be necessary to distinguish URLs from other
   possible data structures in a syntactic structure. In this case, is
   recommended that URLs be preceeded with a prefix consisting of the
   characters "URL:". For example, this prefix may be used to
   distinguish URLs from other kinds of URIs.

In addition, there are many occasions when URLs are included in other
   kinds of text; examples include electronic mail, USENET news
   messages, or printed on paper. In such cases, it is convenient to
   have a separate syntactic wrapper that delimits the URL and separates
   it from the rest of the text, and in particular from punctuation
   marks that might be mistaken for part of the URL. For this purpose,
   is recommended that angle brackets ("<" and ">"), along with the
   prefix "URL:", be used to delimit the boundaries of the URL.  This
   wrapper does not form part of the URL and should not be used in
   contexts in which delimiters are already specified.

In the case where a fragment/anchor identifier is associated with a
   URL (following a "#"), the identifier would be placed within the
   brackets as well.

In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
   need to be added to break long URLs across lines.  The whitespace
   should be ignored when extracting the URL.

No whitespace should be introduced after a hyphen ("-") character.
   Because some typesetters and printers may (erroneously) introduce a
   hyphen at the end of line when breaking a line, the interpreter of a
   URL containing a line break immediately after a hyphen should ignore
   all unencoded whitespace around the line break, and should be aware
   that the hyphen may or may not actually be part of the URL.

Examples:

Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
      type=d> but you can probably pick it up from <URL:ftp://ds.in
      ternic.net/rfc>.  Note the warning in <URL:http://ds.internic.
      net/instructions/overview.html#WARNING>.

Die URL:...-Notation ist also "nur" die Kombination aus zwei Empfehlungen, und eben kein "echter" Standard. Man darf auch eine oder beide Empfehlungen weglassen, somit sollte ein ausreichend clever geschriebenes Programm mit allen vier möglichen Varianten (ohne alles, nur "URL:"-Prefix, nur "<...>", "URL:...") einer URL im Fließtext klarkommen. Freundliche Programme und freundliche Menschen, die es anderen Programmen leicht machen wollen, folgen beiden Empfehlungen, d.h. URL:....

So, dann kann ich mein Neuron ja wieder zusammenflicken ... ;-)

Alexander