[PATCH] encode mail address when passing via KApplication::invokeMailer
kloecker at kde.org
Sat Jan 8 16:18:39 GMT 2005
On Saturday 08 January 2005 16:25, Oswald Buddenhagen wrote:
> On Sat, Jan 08, 2005 at 04:02:43PM +0100, Ingo KlÃ¶cker wrote:
> > > i don't care about the details, but if you break %u for mutt,
> > > i'll make you a head shorter. ;)
> > Can you then please test this with Mutt? Attached is a tiny
> > HTML-test file.
> the url is bad (should be & not &)
RFC 2368 - "The mailto URL scheme" reads:
Because the "&" (ampersand) character is reserved in HTML, any mailto
URL which contains an ampersand must be spelled differently in HTML
than in other contexts. A mailto URL which appears in an HTML
document must use "&" instead of "&".
Of course it's unclear whether they refer to mailto URLs which are
inserted literally into an HTML document (why would anyone do this?) or
whether they refer to mailto URLs as href parameters. What I definitely
know is that validator.w3.org complains about any '&' which are not
encoded as '&' in any href's of your XHTML document.
> and doesn't cover all cases by far (multiple to/cc/bcc).
See next comment.
> the changed composer does not permit multiple to=s, a thing i do
> pretty often (not in urls, though, but that's because i don't do much
I didn't touch the code which rips mailto: URLs apart (and thus it's
irrelevant that I didn't test with multiple to/cc/bcc). I just changed
the code of invokeMailer( to, cc, bcc, ... ), i.e. the code which
creates a new mailto URL from the given to, cc and bcc. According to
the above mentioned RFC the value after to=, cc= or bcc= has to be the
value of a RFC 822 message header encoded as URL. In particular,
multiple addresses are allowed per to=, cc= or bcc=.
> the encoding is strange/bust - konq shows the utf8 as "source"
> (latin1, i suppose), and the url passed to mutt is utf8, too. maybe
> that's just the url.
Yeah, I shouldn't have added a non-ASCII char to the example. The mailto
URL is indeed wrong. A correct URL for the email address
Jörg Test <joerg.test at test.test>
The problem now is what does invokeMailer( to, cc, bcc, ... ) expect?
IMO invokeMailer can't expect to, cc and bcc to be RFC 2047 encoded
email header values. Thus invokeMailer has to do the RFC 2047 encoding
and that's what it does now in the special case for KMail. Adding a RFC
2047 codec to KCodecs would be the right solution, but moving the codec
we have in kdepim is currently not possible. The downside is that we
have to forget about correct handling of non-ASCII chars in email
addresses (unless KMail is used). If all non-ASCII chars can be encoded
in local encoding then it should still work in most cases.
But what we can care for is email addresses of the form "Test, Joerg"
<joerg.test at test.test>. And that's what my patch does and what
QStringList( ',', x ) does not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel