I want to send an email with special characters (like cyrillic) from a swf. To make sure it will be displayed correctly in the mail client, I use
encodeURI()
It works fine in Apple Mail, but in Outlook I only see gibberish. I learned that Outlook uses iso-8859-1 for "mailto:"-mails (at least by default). So two questions arise:
is there a way to encode the mailto: string in iso-8859-1?
would this break the correct display of characters in other mail clients?
I am sure that the second question can not have a definitive answer, nevertheless I would be thankful for any advise.
EDIT: unfortunately, html email and php is not an option for me.
You are using the wrong tech my friend. Just post your email data to some php script and use php to send a html email.
Related
This question may sound like stupid but I tried all possible HTML entities and the subject line for the email I send is still not showing the heart on Apple devices (iPhone, iPad, etc).
It may be just the software I use for testing (MaxBulk Mailer, ExactTarget).
I also tried different charset (UTF-8, ascii, etc).
Does anybody know how to make a heart appear as a heart into the subject line of an email for Apple devices?
The subject line is part of the email headers. The email headers may only contain ASCII characters. The subject line is not being interpreted as HTML or anything else, it's plain text. You need to embed the character as Unicode character, but you cannot do this since the headers must be in ASCII. To embed any non-ASCII characters in a header, you need to use a MIME Encoded-Word.
See mb_encode_mimeheader, read its examples.
The resulting header will need to look something like this:
Subject: =?utf-8?B?4p2k?=
Which decodes to this in the mail client:
❤
With regards to your question here: you may have picked the wrong heart. Try ♥ instead of ❤. The first one should render on a BlackBerry (and Android 2.2), too, as this test shows. The latter one, however, doesn't.
I've seen all these emails that include pictures, divs, paragraphs and what-not inside an email.
How do I actually go about doing that?
Can anyone give me a rough explanation on how these things work? I am pasting my HTML code inside my email and it only shows text. Is there anything I should enable/disable?
(I know I will need a mailing list, but that's probably a different topic.)
The body of the message should be formatted as Multipart MIME (with the email header stating that it is formatted that way) with at least two parts: A text/html part and a text/plain part (for email clients that don't support HTML and to reduce the number of This Is A Spammer flags given the email).
Most graphical email clients will only allow HTML to be entered using their WYSIWYG tools. Custom HTML requires specialist software.
We are sending out newsletters. The format used is html as far as i know, but on some clients accented letters don't render just there code can be seen. For example: " " or "é" etc.
Unfortunately i don't know more details yet, because my friend asked me to help him with this. What would be the proper email header for these kind of emails? I suspect the problem lies there.
Thanks for helping.
update:
I got more information now. The thing is that they are using a service provided by a third party. It's web based using TinyMCE for editing mails(unfortunately i doubt that i can get access to settings). Anyway they managed to send me a header of the mail:
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Shouldn't be "text/html" instead of "text/plain"? Because if it's plain then it's obvious that it's not rendering, right? Or is it possible that the email header sent is "text/html" but the mail software on the client can't handle html mails and changes it to "text/plain" ? Thanks for your help, Alex
If things work for some clients and don’t work for others, it is probable that the charset parameter in the Content-Type MIME header in the email is wrong or missing (forcing programs to guess) or some email programs do not support the character encoding used or there is a similar problem with transfer encodings.
It would be (in some sense at least) simplest to circumvent such problems by encoding all non-ASCII data using entity or character references, such as ´ for é (see e.g. a list of references for the Latin-1 Supplement). This would work on all programs that can deal with HTML format and would not depend on character or transfer encoding issues.
I have phpmailer setup to send emails from the contact form. I have the page set to UTF-8 character encoding and specify the email encoding as UTF-8 as well within PHPMailer. This all works fine and allows me to send emails with foreign/special characters. I also store the submission in a mysql database and use htmlentities with UTF-8 encoding to convert the special characters to html entities before storing them in the db. Would it be better to use htmlentities on the email text before including it in the email i'm sending out (at least on the HTML part of it, maybe not the plain text) to ensure all characters are accessible on as many email clients as possible or will it make no difference? Additionally I am using enctype="multipart/form-data" for the form, which works fine and makes sense to me, I just wanted to make sure this was correct?
Cheers!
Dave
Most email clients will automatically understand special characters, but if you are truly interested in making it compatible with all interfaces that you should use the standard HTML entities.
You can use something like this in your header
<meta http-equiv="Content-Type" content="text/html charset=UTF-8" />
This link provides a simple and elegant solution.
Is there some sort of formatting protocol for html email? We have an automated system that sends reports via email, when I look at the source I see them delimited by line length with an "=" breaking the line. That is, I get something like :
<html><body>some text some text some text some=
some text some text some text some text som<ta=
ble>some text some text some text some text <t=
r><td...
Does anyone have any more information on what this is?
You have to send the message as multi-part MIME. Best practices are:
Always send an HTML and a pure text version this way for mail clients that don't support HTML or some people just turn off HTML in emails (there are security/spam isssues with images although a lot of clients won't auto-download images from non-trusted sites anyway);
Images can be included in the message instead of as straight links. Straight links save on bandwidth but are a spam or even security issue (eg Internet Explorer had a buffer overrun bug with PNG images). Embedded images are references with cid values; and
Only use the most basic HTML. Browser HTML support varies from the primitive to the bizarre. When I looked into doing this we just couldn't get a consistent (or even acceptably different) look and feel on the handful of mail clients we investigated leading us to send our reports as attached PDFs, which are, in a lot of ways, preferable (they can easily be saved, for one).
As to your garbled message, it looks to me that your message isn't being correctly identified as HTML so the mail client is wrapping lines of text at 70 or so characters.
Your message is being translated somehow to "quoted printable" encoding. This is probably an issue with the mail headers you're creating.
Looks like it could be quoted-printable.
How do equals symbols in the HTML look, are they replaced by =3E?
Technically there's nothing wrong with this, but it would be nice to include an alternate plain text,
for those people who can't or don't want to read HTML mail (like me).
The email RFC enforces line length limits, specifically each line should be no longer than 78 characters, excluding CRLF. The equal symbols at the end of each line is just a line delimiter, which will be correctly parsed by any email reader that supports HTML, as long as the necessary headers are in place (Content-Text: text/html). More details on HTML in email conventions can be found here.