mailto special characters - html

Is there a way to make the email client ( Outlook ) accept special characters coming from the mailto link in html? I'm trying to have a mailto link with german characters in the body, but in Outlook I get only strange characters.
Thanks

I just spent 2 days investigation this issue. Our issue was that mailto: links on our utf-8 encoded web pages did not work for Outlook users if the subject= string contained non-ascii characters, like e.g Norwegian characters. An example is:
"mailto:mail#coretrek.no?subject=julegløgg og fårikål"
From what I have learned so far, Outlook simply does not handle anything other than ASCII and iso-8859-1 characters. So when trying to click on the above mailto link (either from IE or Firefox), Outlook fails to decode the characters, leaving the subject broken and containing "weird" characters.
So the next step was to try to re-encode the pages in ISO-8859-1. What we did was to replace the original mailto link on the utf-8 page with a link to a "email-to-iso"-service, like this:
http://url.com/service.php?service=util.mailtoencode&mailto=mail%40coretrek.no%3Fsubject%3Demne+%C3%B8%C3%A6%C3%A5+emne
This page would convert the mailto characters to iso-8859-1 and then output the entire page content in iso-8859-1. A javascript on the page, containing "location.href='mailto:...'" was used to open the client's email client automatically.
So far everything seemed ok. This actually works in Internet Explorer, both with Thunderbird and Outlook (tested on IE7 on WinXP with Outlook express and TB 2).
BUT the problem now is actually Firefox. It seems like Firefox is unable to decode url-encoded urls containing characters found only in ISO-8859-1 but not in ASCII (like the norwegian å, represented by %E5 when encoded). The same å is handled correct if the page encoding is utf-8, but it seems like the Firefox developers have forgotten to test special characters together with the ISO-8859-1 charset.
The result is that Firefox passes an un-decoded string (still containing %E5 intstead of å) to the email client. And, amazingly, this is handled correct by Outlook (which manages to decode the string itself), but NOT by Thunderbird, which probably has the same bug as Firefox. If you DON't url encode the subject, the string is passed correctly to Thunderbird, but not to Outlook.
We have also been trying other encoding methods, like php's htmlentities, htmlspecialchars, base64 encoding etc, but all of them fails one way or the other.
So, summarized:
Pages encoded in utf-8:
IE fails always
FF -> Thunderbird: OK
FF -> Outlook: FAIL
Pages encoded in iso-8859-1:
IE: OK
FF -> Thunderbird: Fails if subject is url encoded, ok if not)
FF -> Outlook: Fails if subject is not url encoded, ok if encoded)
(this is Windows, on Ubuntu Linux FF and TB works OK always).
Hoping this was helpful for others having the same problem.

In PHP I think the function that works best with Outlook is rawurlencode()

I think using a urlencode method should do what you're looking for. JavaScript has .encodeURI() methods on string objects, and .NET has the HttpUtility.UrlEncode method.
What language are you using?

Actually, the solution is http://blogs.msdn.com/ie/archive/2007/02/12/International-Mailto-URIs-in-IE7.aspx and it is not nice.
Basically, in IE 7 and 8 the user must have enabled an advanced setting in Internet Options, something that 100% of the users will not know will not have enabled.

You need to enable UTF-8 support for the mailto: protocol
From the main outlook window, click Tools -> Options -> mail format -> international options -> "Enable UTF-8 support for mailto: protocol".

rawurlencode() function works best with outlook,
tested with Firefox, Chrome & IE

As yandr indicated, this issue is an ongoing problem with Outlook.
Microsoft has published documentation that states that properly configured Outlook 2003 and 2007 attached to a properly configured Exchange server will default to supporting Unicode, but that doesn't really help you with the general public.
For reference, the "standard" you want to refer to for this is RFC 2047.
The solution that I have implemented to get around this limitation (with Swedish, actually) is to use a web form instead of a mailto: link. It requires more setup on the server side, but gives you a lot more control over the contact process.
I'm sure this isn't what you wanted to hear, but until the world stops using broken software from Microsoft, we'll continue to need workarounds like this.

It sounds like you need the page containing the mailto link to be in the encoding that Outlook is expecting. Without knowing any more about the situation, I'd try encoding the page in UTF-8 and ISO-8859-1.
The relevant 'more about the situation' would be what weird characters appear and what the page's encoding is currently.

If one is using SharePoint 2010, it seems Microsoft has been aware of this issue, and has supplied some functions to solve this.
The following will properly escape the link to the current page
escapeProperly(escapeProperlyCoreCore($(location).attr('href'), false, false, true))

In JavaScript you can use encodeURIComponent function for subject and body. Then it will show all special characters in email.
const emailRequest = {
to: "abc#xyz.com",
cc: "abc#xyz.com",
subject: "Email Request - for <CompanyName>",
body: `Hi All, \r\n \r\n This is my company <CompanyName>
\r\n Thanks`,
};
const subject = encodeURIComponent(emailRequest.subject.replace("<CompanyName>", 'ABC & ** Company'));
const body = encodeURIComponent(emailRequest.body.replace("<CompanyName>", 'ABC & ** Company'));
window.location.href = (`mailto:${emailRequest.to}?cc=${emailRequest.cc}&subject=${subject}&body=${body}`);

Related

Which charset should I use in mailto body for maximum compatibilty?

I have UTF-8 page in which I have mailto links with template of body. But these template with data includes East Europian (Czech) characters. These characters messes up some email clients like Outlook 2007 and they are displayed like question marks or some other strange characters.
I know about "Enable UTF-8 support for mailto: protocol." setting in Outlook 2007, but from what I know about it's off by default.
Which charset-encoding should I use in mailto body for maximum compatibilty?
it clearly depends on client settings. in the company i work for we had a similar question. we ended up using ae for ä and so on.
we faced the problem that some clients running ms outlook 2003 were reading it as utf-8 while other clients running outlook 2003 were reading it as a defined ansi table.
another issue is involved in the usage of other mail clients. we also have a bring your own device program where employees could install linux or have mac books. they are using mozilla thunderbird, mutt and so on. other clients have set gmail as their prefered mailto: handler etc. so a global change of the outlook settings through a registry edit as in Rfilip's answer would not apply to us.
anyways.. you can only define the text body of the mail. sadly its impossible to define a html body through a mailto: link. if this would work, encoding could be defined through the body.
there also is no such a flag to set up the prefered encoding inside the mailto: link.
answer to this question: its impossible to detect or set the mail clients encoding so you should switch to characters that would work in every ansi table.
as alternative you could provide two links. one encoded with utf-8 with a note that, if it will display weird, the user might use the second mailto link.
or.. you provide one mailto link aswell as a drop down box to select encoding. (including a brief description of what encoding is as hover ontop of the dropdown)
It depends on the characters you want to use and your clients setups...
it may be Windows1250 ( http://en.wikipedia.org/wiki/Windows-1250 )
So, on G+ I was pointed to answer on other thread -https://stackoverflow.com/a/1831416/1190066. It seems like that different charsets fails on some combinations of browser/OS/email client. That nothing works on everything.
So I'll use the fact that it's intarnet app and it's Win 7, Chrome, Outlook 2007 setup and I'll convince admin to enable "Enable UTF-8 support for mailto: protocol." by registry key change on client company computers. - https://social.technet.microsoft.com/Forums/en-US/183b2442-6750-4e18-b61d-d87ce5f3aac3/outlook-2007-utf8-mailto-protocol-how-to-set-this-parameter-in-thousand-machines-?forum=officesetupdeploylegacy
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Protocols\Mailto
UTF8Encoding
The value “1” turn on the “Enable UTF-8 support for mailto: protocol”
The value “0” turn off
But this workround is viable only when you can modify settings of all client's computer.
So I was looking for posibilities that don't include that change. But I see that they arent.

HTML mailto subject and body display plus sign(+) instead of space in mail client

It's happening in
- Samsung Galaxy Note3 & 4
- Google Chrome browser V39.XX
I am using a link and when click it's launch the mail client
href="mailto:info#gmail.com?subject=Network%20issue"
result: subject=Network+issue
How to remove the plus(+) sign?
Your original approach should work... The only reason that comes to mind behind it not working is perhaps encodings are being mixed up along the way? Take a look at these threads to get a better idea of what I mean:
mailto special characters
Special characters in UTF8 mailto: subject= link and Outlook
I experimented with the base64 approach that is the answer in the second link but was unable to remedy the issue :-\ I tested this on Gmail, Inbox, and Mailbox - all with the same results as what you are describing above.
Maybe something is getting messed up at the Android layer in terms of how the link is being handed off to the mail client of your choice?
If you're rendering using Javascript, try encoding as a URL using encodeURIComponent
const urlEncoded = encodeURI(mailToLink);
before you pass the URL to the mailTo link. Otherwise encode it in the backend first.
This can be done with email addresses that contain special characters too.

Chrome form POST shows "(unable to decode value)" and database stores it as a question mark

I have a test site and test DB both set to windows-1252. When I type Alt+234 into Chrome it puts this symbol in the field: Ω. And when I submit the form it posts and stores it as Ω I'm assuming this is the browser saying "hey, this isn't in the specified charset but I do know of an html equivalent, so I'll post that instead". Fine. The symbol appears properly after saving, I can save, save, save, and it always appears fine. But if I try the same thing with Alt+230 the browser does not submit it's html entity value of µ. Instead I see "(unable to decode value)" when viewing the POST in the Chrome DevTool window. And it ends up being stored in the database as a question mark.
Why does it treat Alt+234 (Ω) differently than Alt+230 (µ)?
I know I should switch to UTF8 but I still would like to know why it is functioning this way. Thanks!
Using encodeURIComponent to wrap the value fixed the problem.
Broken:
`?value=${myValue}`
Working:
`?value=${encodeURIComponent(myValue)}`
U+03A9 Ω Greek capital letter omega is not part of Windows code page 1252.
U+00B5 µ Micro sign (which is not the exact same character as Greek mu) is part of 1252 (byte 181).
The Alt+keypad shortcut numbers don't align with code page 1252, or the current ANSI code page in general, so being able to type a character from that shortcut doesn't imply membership of those code pages. Instead they are from DOS code page 437.
And when I submit the form it posts and stores it as Ω I'm assuming this is the browser saying "hey, this isn't in the specified charset but I do know of an html equivalent, so I'll post that instead"
Yes, this is a long-standing weird unrecoverable mangling that HTML5 finally standardised, for when a character is not encodable in the encoding the page has requested.
Instead I see "(unable to decode value)" when viewing the POST in the Chrome DevTool window. And it ends up being stored in the database as a question mark.
The browser will be sending that character as code page 1252 byte 181. The devtools and whatever your application is aren't expecting to be dealing with code page 1252 bytes... probably they are expecting UTF-8. Because byte 181 on its own is not a valid UTF-8 sequence they can't keep it.

Garbled text in mail subject using mailto: under ASP.NET

This is my first question on StackOverflow so if I'm doing something wrong when asking this question I welcome any pointers as to how I should've posed it instead, or any further information needed.
I have developed a small ASP.NET/C# site which generates mailto-links with a preset subject/body. However for some reason my mailto:-links end up garbling non-standard letters (e.g. ååö) when opened in Outlook 2003. In Outlook 2010 it seems to work.
Sample code (apologize the Swedish):
<a href='mailto:" + emails + "?subject=Inflödning till " + language +
" för jobb nr " + projectID + " är klar. Tidsåtgång: " + time + "'>
Skicka mail till PL?</a>
(note that this happens on static links without C# variables as well)
Garbled text sample from Outlook 2003 mail window:
Inflödning till en för jobb nr 111111 är klar. Tidsåtgång: 1
I have specified UTF-8 encoding in the Web.config but I'm assuming this isn't the problem. I probably have to specify the encoding in the subject itself, but I am not sure about how to do that.
Edit: It would seem Outlook 2003 has a tough time handling UTF-8 mailto support. See for example this question. Outlook 2010 has an explicit "UTF-8 support for mailto protocol" switch under options. 2003 is missing this. Any ideas on how to get around this? UrlEncoding() doesn't seem to help.
Make sure you have the character encoding set
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Should appear at the top of your page - with charset= set to whatever character set Swedish use (Google has lead me to believe ISO-8859-1)
Take a look here which seems to use a javascript function to correctly escape the characters. I believe HttpUtility.UrlEncode(String) within the code behind will also have the same effect.
Does outlook perhaps have a different encoding specified?
EDIT:
Found this here
In versions of Outlook prior to the
2007 version, Outlook would assume the
system codepage had been used to
encode the URI. This means that this
scenario would only work with older
versions of Outlook, if the document
you’re viewing has the same character
encoding as your current system
codepage.
This would seem to point to the problem that the system code page is NOT using Swedish (ISO-8859-1) so the remedy to the situation appears to be:
Upgrade Outlook
Change System Encoding to ISO-8859-1 (the client thats running Outlook)

Chinese characters in mailto subject line of email

I'm looking to add some Chinese characters in a mailto: email link.
I've tried
Email
but when I click on the link the Outlook subject line shows:
调查亨德森 / Inquiry
I've also tried
Email
but I get the same result as above.
I realize this may be an Outlook issue but I'm interested in finding out the correct way to implement this functionality.
Raw URL Encode
To encode mailto links / standard links with special characters you can use the php function rawurlencode
If you are looking for an online tool try http://www.cafewebmaster.com/online_tools/rawurlencode
Using your example:
Email
would convert to:
Email
Since subject is in mail header, there is no way to know what encoding you are using. You need to use MIME Mail header extension defined in this RFC,
http://www.ietf.org/rfc/rfc2047.txt
The subject in Chinese would look like this,
Subject: =?GB2312?B?u7bTrbLOvNPDwLn61bm74Q==?=
But more and more clients assume UTF-8 encoding now. You might want try that also.
It's cumbersome but possible, here is a good article that discusses both the standard compliant way of an ideal world and real world scenarios with Internet Explorer.
For your text in comment #1, please enable the "Tool->options->mail format->International Options"->"Enable UTF-8 support for mailto: protocol"
I've been trying to put non-ASCII characters in subject lines for a while now. The bottom line is: it does not work reliably.
My (limited) understanding of why it does not work is that the standards say that email is 7-bit ASCII. The MIME standard gets around that by encoding the contents of the email differently. However: the subject line is not part of the contents. It's a header.
Because the default charset of outlook is gb2312, so when you encode the subject, you must translate the Chinese character to gb2313, then encode it.
In a word, the charset which you pass must be consistent with the default charset of outlook.