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

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.

Related

Valid domain name registration for Unicode characters

I'm trying to figure out what is valid for domain name registration, apparently some Unicode characters are translated weirdly while others do not at all.
This address:
http://xn--ippleman-dmj.com/
Translates to:
http://Nippleman.com/
and
http://xn--ggle-0nda.com/
should translate to:
http://gοοgle.com/
but for some reason the browser prevents it.
How is the format for these domains determined, and what is or isn't blocked by the browser?
http://xn--ippleman-dmj.com/ is a valid URL, while http://www.gοοgle.com is not. Yet Chrome only replaces the Unicode on the second URL.
It appears that you're trying to do an IDN homograph attack. The Wikipedia page nicely explains what Chrome is doing to stop you.
First, to your question.
The valid domain name must conform to RFC1035 regardless of browser, i.e. the whole domain name must not exceed 255 valid ASCII character (in octet) and it is case insensitive. Even IDN must comply with this standard. So to display IDN, RFC evolve come out with the Punycode 'xn--' conversion idea.
Then there is proof of concept of IDN homograph attack. Currently, Unicode.org update and maintain a confusable list. You can download current version TR39 and play around with it.
Previously, Chrome and firefox will translate domain name start with xn-- to correspondence Unicode found inside the browser font cache. If the browser can't find the font, it will display the raw 'xn--' punycode domain name.
This is known issues. Firefox even has manual option to enable/disable the Punycode domain name display. Google decide to remove the conversion post version 58+, while Firefox 53 will follow to make display Punycode as default.
I don't know whether Google will show Unicode(s) not inside TR39 or just remove the Punycode to Unicode conversion for all.

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.

Mailto: Guideline and character limitation

I'm trying to code an application which will allow users to send emails from outlook using the mailto tag. I know with the mailto, there involves limitation of # of characters that may be passed, as well as encoding.
Does anyone know the exact count of characters I can use, and what guidelines to follow when it comes to encoding special characters? What is counted in the max number of characters you can use? Body and Subject or the whole line including mailto syntax?
For example I will have the following:
<a href='mailto:test#gmail.com?subject=Test Mail&body=Line one.%0D%0ALine two.'>Test Link</a>
Would this be 69 characters??
Forgot to mention, supported browser will be IE6.
Any help would be appreciated.
Thanks
As far as I know there is no limit.
The HTML 4 spec says nothing about a limit
Authors may create links that do not lead to another document but
instead cause email to be sent to an email address. When the link is
activated, user agents should cause a mail program to open that
includes the destination email address in the "To:" field.
To cause email to be sent when a link is activated, specify a MAILTO
URL as the value of the href attribute.
http://www.w3.org/TR/WD-html40-970917/struct/links.html#h-13.2.2
However, many sites report a 256 character limit.
You should test to be sure.
You may also find this question and answers illuminating: What is the email subject length limit?
Same problem here, so far no good. IE9 has a limit of around 505 characters per href="...", Chrome 21 is better - around 2000 chars.
Update! According to this guys there is a workaround, and it seems to work for me:
ClientScript.RegisterStartupScript(this.GetType(), "mailto",
"<script type = 'text/javascript'>parent.location='" + longMailtoText +
"'</script>") ;
This will launch the script and open MailClient window as soon as client gets the response. LongMailToText should follow all standard rules, except for length - so far i was able to send over 2000 chars through it.

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.

mailto special characters

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}`);