I want to add image like company logo in email subject using php mail function i have added
$subject = "<img src=\"https://www.donndraper.com/images/logo.png\" width=\"50px\">");
$header = "From: $email\n Content-Type: text/HTML;";
What JerrySeeger was trying to say, in a fairly condescending manner, is that e-mail does not support images in the subject.
The SMTP protocol was designed 20 years before HTML was even invented.
What you desire is simply not possible.
You cannot include custom images (such as your company logo), however, there are a limited number of Unicode images that you can use in the header.
Some clients render them by using color images rather than treat them as characters in a font. The following article has a few images comparing how various mobile devices render them:
Symbols in Subject Lines: How to Get Your Email Noticed
And you can see Wikipedia for a long list of the available characters, and if for some reason your font does not support those characters, the second link are bitmap renders of those characters:
Wikipedia: Miscellaneous Symbols
Online Uniode Character Map
#GUS well said.. and you guys are all wrong.
You may use any unicode utf-8 or Base64 in mail subject and latest Trend in mass Mailers.
its pretty easy to implement .
Related
I'm trying to send an email programatically that has the images embedded, to eliminate dependency on access to our network, or hosting files externally (corporate security red tape etc. etc.)
I was able to do this by encoding the image to base 64. However, I'm having issues with specific clients. Most importantly, in Outlook, the image shows as a broken link. The same thing is happening in Windows (10) mail. The images render in several other clients (Blue Mail for Android, a non-stock iPhone client and the web based client for my ISP).
On a side it looks like Outlook is replacing "+" signs in the base64 to + , although I'm not sure if that's related or not. I can save the source of the outlook email (even with the + ) as an html file and view it in a browser fine.
I have tried encoding using different characters here : https://cryptii.com/pipes/hex-to-base64
...to avoid having "+" signs. None of the other variants worked, and in fact, they all broke the images in the other clients.
Any ideas?
Outlook (or rather Word, which renders HTML messages in Outlook), does not support embedded base64 encoded images. You would need to add image attachments, set their Content-id MIME header, and refer to images like that through the cid attribute (<img src="cid:xyz">)
When I read mails I sometimes would like to select one of the links in the mail's text to open it in a web browser.
Before you answer, I know there is urlview, but there are also BASE64-encoded (or other transfer encodings) mails from which urlview does not find any URLs. Then there are also HTML-only mails that can also be encoded with transfer encodings.
I wonder if there is a trivial and/or nice solution that I couldn't find. I cannot be the only one with this problem. It does not need to be based on urlview, of course.
urlview will work if you employ the "pipe_decode" setting. Example use in a macro, binding to "\u":
macro index,pager \\u "<enter-command>set pipe_decode = yes<enter><pipe-message>urlview<enter><enter-command>set pipe_decode = no<enter>" "view URLs"
with urlscan there exists a worthy successor to urlview.
Support for emails in quoted-printable and base64 encodings. [..] For HTML mails, a crude parser is used to render the HTML into text.
I saved the face "savouring delicious food emoji" to database, and read it in php json_encode which show "uD83D\uDE0B"。 but usually we use one <img /> label to replace it .
however,usually I just find this format '\uE056' not "uD83D\uDE0B",to replace with pic E056.png .
I don't know how to get the pic accroding to 'uD83D\uDE0B'.someone know ?
What the relation between 'uD83D\uDE0B' and '\uE056'， they both represent emoji "savouring delicious food"?
The Unicode character U+1F60B FACE SAVOURING DELICIOUS FOOD is a so-called Plane 1 character, which means that its UTF-16 encoded form consists of two 16-bit code units, namely 0xD83D 0xDE0B. Generally, Plane 1 characters cause considerable problems because many programs are not prepared to deal with them, and few fonts contain them.
According to http://www.fileformat.info/info/unicode/char/1f60b/fontsupport.htm this particular character only exists in DejaVu fonts and in Symbola, but the versions of DejaVu I’m using don’t contain it.
Instead of dealing with the problems of encodings (which are not that difficult, but require extra information), you can use the character reference 😈 in HTML. But this does not solve the font problem. I don’t know about iPhone fonts, but in general in web browsing, the odds of a computer having any font capable of rendering the character are probably less than 1%. So you may need to use downloadable fonts. Using an image is obviously much simpler and mostly more reliable.
U+E056 is a Private Use codepoint, which means that anybody can make an agreement about its meaning with his brother or with himself, without asking anyone else’s mind. A font designer may assign any glyph to it.
IMPORTANT: As of this posting, the only browser that doesn't automatically support emojis is chrome.
FOR CHROME:
Depending on what server side language you are using, you should be able to find a library that converts emojis for you. I recently needed to solve this issue with php and used this library:
https://github.com/iamcal/php-emoji
The creator essentially created a sprite and adjusts the css according to the unicode of the emoji. It isnt pretty, but luckily he/she did all the grunt work for you. If you're using a different language you should be able to find something similar.
how do I put those little boxes into a php file?
Same way as any other Unicode character. Just paste them and make sure you're saving the PHP file and serving the PHP page as UTF-8.
When I put it into a php file, it turns into question marks and what not
Then you have an encoding problem. Work it out with Unicode characters you can actually see properly first, for example ąαд™日本, before worrying about the emoji.
Your PHP file should be saved as UTF-8; the page it produces should be served as Content-Type: text/html;charset:UTF-8 (or with similar meta tag); the MySQL database should be using a UTF-8 collation to store data and PHP should be talking to MySQL using UTF-8.
However. Even handling everything correctly like this, PCs will still not show the emoji. That's because:
they don't have fonts that include shapes for those characters, and
emoji are still completely unstandardised. Those characters you posted are in the Unicode Private Use Area, which means they don't have any official meaning at all.
Each network in Japan uses different character codes for their emoji, mapped to different areas in the PUA. So even on another mobile phone, it probably won't display the correct character, unless you spend ages manually converting emoji codes for different networks. I'm guessing the ones you posted above are from SoftBank (iPhone?).
There is an ongoing proposal led by Google and Apple to collate the different networks' emoji and give them a proper standardised place in Unicode. Until then, getting emoji to display consistently across networks is an exercise in unhappiness. See the character overview from the standardisation work to see how much converting you would have to do.
God, I hate emoji. All that pain for such a load of useless twee rubbish.
We are currently sending our emails as HTML but it is not rendering properly on the blackberry. It add's extra blank lines. I assume that is because of the tag. Anyways when sending them as plain text they render correctly, but now the user wants some of the keywords to be bolded. Would rich text format be viable? Should it render properly in the blackberry and if so what would be the syntax for a new line \n.
Note: The HTML emails render correctly in Outlook.
We have had pretty good experiences with html mails on BB 4.5 and up (although not perfect). Try using paragraph tags instead of the new line character.
But you may need to fiddle around a bit with the email format to get it looking great.
I'm trying to generate email from my code that will read correctly for people using right-to-left-reading languages such as Arabic. My question is: what are my options for acheiving this?
I am aware that I can create a multipart email and encode the message body as "text/html", then specify a text direction in the <html> tag (e.g. <html dir="rtl">), but ideally I would like use plain-text email and not have to rely on HTML formatting, because not all users will have HTML support in their email client.
On the plain-text front, I have managed to encode Arabic text in UTF-8 using the "Content-Type" header as follows:
Content-Type: text/plain;charset=UTF-8
But as for the overall direction of the text, I am unsure how to explicitly specify this in the email, or even if this is necessary. How would an Arabic speaker typically work with plain-text email? Would they usually rely on the global text direction setting in their email client, or is there some other, generally accepted way of forcing the text direction in the email itself?
Any suggestions or general advice regarding right-to-left email would be much appreciated.
I am unsure how to explicitly specify this in the email, or even if this is necessary.
For plain-text unicode, you can add a right-to left mark inline, but it's not really needed.
I'd say why not add the RTL mark, but it's not really necessary
How would an Arabic speaker typically work with plain-text email?Would they usually rely on the global text direction setting in their email client, or is there some other, generally accepted way of forcing the text direction in the email itself?
Most users would be able to either switch the text direction to get a correct padding of the lines, or are used to a jagged-right Arabic text (the text itself will appear correctly if it doesn't contain any inline English characters, and users are used to reading it in chunks even if it does).
I am upvoting Osama's question, even tough I have a very different opinion then him. The reason is that unicode control characters are not used enough in the world, and they could fix a lot of problems.
Anyway, to my answer: use HTML. Really. Because even if you so s = RLE + s + PDF, the text will have right-to-left direction but not alignment.