I am using phpmailer to send emails using php.
When i try to send special (Turkish) character within the subject, it displays html entity in the sent email. If I include the same variable in the body part, it works fine. Please see below:
$mail->Subject = $stuname."PhD Qualifying Exam Application";
I have tried html_entity_decode function but didnt work.
Also, if I type the Turkish character instead of getting from a variable, it works fine.
Finally, if I print the variable before sending the email, it prints fine without any encoding problem. But number of character is larger than it should be..
So, any idea why I am having encoding problem in subject are when getting the value from a variable?
Thank you!
PS:
i am also adding these headers:
$mail->SetLanguage("tr", "phpmailer/language");
$mail->CharSet ="utf-8";
$mail->Encoding="base64";
I found a solution, none of the html decoding functions were working so I wrote my own function for Turkish characters.
function replacehtml($inputText) {
$replace = array('İ','ı','Ö','ö','Ü','ü','Ç','ç','Ğ','ğ','Ş','ş');
$search = array('İ','ı','Ö','ö','Ü','ü','Ç','ç','Ğ','ğ','Ş','ş');
$outputText=str_replace($search, $replace, $inputText);
return $outputText;
}
Related
I've developed an email system on my own using php's imap and everything works fine, except for emails that are written in Arabic language, i've tried all the decoding functions and nothing seems to work. I got the subject to work perfectly by using imap_utf8 but not the email body.
This is what the email body looks like:
�
رحبا
هاي الرسالة �
This is my code:
$text = imap_fetchbody($imap, $uid, $partNumber, FT_UID);
switch ($structure->encoding) {
case 3:
return imap_base64($text);
case 4:
return imap_qprint($text);
default:
return $text;
}
If anyone can help with this issue. Thanks
I suggest you have a look at this: https://github.com/mantisbt-plugins/EmailReporting/blob/master/core/Mail/Parser.php
It uses the stuff you've used as well but it adds character encoding on top of it.
Subject character encoding can happen inline. For email bodies its one character set for the entire body
The script given uses a pear package, not the IMAP extension but based on your input it should be pretty equal
Hope this helps
Try to use quoted-printable-decode() function as stated here
I have seen this type of question asked multiple times and I've tried all the answers but had no luck so far;
The problem is when I try to send an email (I am using Zend Mail) with special characters in recipient name, it gets converted into html for e.g. A user is named Mateo Julián which gets replaced as Mateo Julián
I have tried html_entity_decode but had no success, added UTF-8 header and meta but they didn't work either. And one point to be noted is that I am facing this issue only while sending emails. Added UTF-8 also to mail object like this.
$mail = new Zend_Mail('UTF-8');
and it is called as
$mail->setBodyHtml($recipient_info['message'])
->setFrom($recipient_info["sender"]['email'],$recipient_info["sender"]['name'])
->addTo($recipient_info["receiver"]['email'],$blabla)// $blabla is the problem area where I send the name of recipient.
->setSubject($recipient_info['subject']);
I have a simple web page where I get some data from $_POST that users input: comments, usernames, etc. And I send them to email and save them on database. My problem is what when I send to email, doesn't matter what client is, I only see gibberish. I tried declaring the meta tag in the emails with all iso 88xx, utf8, windows, etc., but with no success. Also tried a million examples of htmlentities(), all leading to the same thing... plain gibberish. (Althought the source code shows different things sometimes, the plain text never changes).
Example code:
if (isset($_POST['name'])) {
$name = htmlentities($_POST['name'], ENT_QUOTES);
}
A result of mail() of $name (Don Quijóte) would be something like this "Don Quijóte".
Sorry if this is a repost but I just can't get this working.
Have you tried setting the headers, something like...
// Always set content-type when sending HTML email
$headers = "MIME-Version: 1.0" . "\r\n";
$headers .= "Content-type:plain/text;charset=UTF-8" . "\r\n";
mail($to,$subject,$message,$headers);
This sets the encoding to UTF-8. More here:
http://www.w3schools.com/php/func_mail_mail.asp
It is surprisingly hard to send a mail in the right way. The error you get with Don Quijote is due to the fact that your string is in utf8 but it is showed with ISO8859 encoding. (That is why you get that weird A and a small 3.
I would recomend using php mailer You can get it here
It is way simpler to setup and it will be more efficient if you at some time in the future need to send out a lot of emails. (Because mail() opens and closes the connection on each call)
Also be aware that if you are using utf-8 everything should be with utf-8. Your database should be set to utf-8. You outputs to html and so on. Every step of the way you should be sure it is utf8.
I'm using SwiftMailer to send emails but I have some codification problems with UTF-8 subjects. Swiftmailer uses QPHeaderEncoder as default to encode email headers and the safeMap looks like it has some problems with some UTF-8 French characters. One subject I use contains the word trouvé (found in French) and when the subject gets to the user it shows trouv.
I'd like to use something similar to the NativeQPContentEncoder that's available as content encoders but for headers there's only Base64 and Quoted Printable encoders.
Is there a way to fix this, maybe I'm doing something wrong so I paste the code I'm using here
$message = Swift_Message::newInstance()
// set encoding in 8 bit
->setEncoder(Swift_Encoding::get8BitEncoding())
// Give the message a subject
->setSubject($subject)
// Set the From address with an associative array
->setFrom(array($from => $niceFrom))
// Set the To addresses with an associative array
->setTo(array($to)) ;
Check if in your PHP configuration mbstring.func_overload option has any value other than 0. If yes, change it to 0, reload your webserver and try to send message again.
mbstring.func_overload overrides some string PHP functions and may lead to tricky bugs with UTF-8.
Personally I solved exactly this problem by disabling mbstring.func_overload.
First, make sure you know how is your subject string encoded. If it is not UTF-8 then utf8_encode() it.
Also, make sure you setCharset('utf-8') your message.
I am using Zend_Mail and want to customize the sender name.
I want the sender name to be FooBar爱你Ryan (where 'Ryan' gets replaced with the recipient name and 爱你 gets replaced with the translation for 'loves' in the language of the recipient, just like CD Baby does).
I've tried base64_encode and mb_encode_mimeheader() and other things like:
mb_internal_encoding('UTF-8');
mb_http_output('UTF-8');
iconv_set_encoding("input_encoding", 'UTF-8');
iconv_set_encoding("output_encoding", 'UTF-8');
iconv_set_encoding("internal_encoding", 'UTF-8');
header('Content-Type:text/html; charset=' . 'UTF-8');
It generates this as the sender: '=?UTF-8?B?RXh0cmFidXjniLHkvaByY3dhbHNoQGV4dHJhYnV4LmNvbQ==?= <email#example.com>'
And then that appears in my Gmail as (unknown sender).
Any ideas?
For me the only solution worked was the following:
As you'd set utf8 subject in a usual php sendmail case, you can make a utf8 noted base64 string like this:
$mail->addFrom($fromEmail, '=?utf-8?B?'.base64_encode($fromName).'?=');
With this solution every thing worked like a charm.
I wish I had tried this earlier: when I hard code the Chinese string as the sender name (using utf8 characters), it works fine. (I tested in Gmail only.)
So the path I'd been going down was mistaken.
I need to figure out why a dynamically-generated sender name consisting of utf8 characters doesn't work when a hard-coded Chinese string does. But that seems to be a different question.
This is a great question and the answers are good - but ZendFramework advanced and the interfaces referenced became unfortunately obsolete.
So here is the same solution, but tested to work fine as of June/2017:
private static function ecvt($string)
{
return mb_convert_encoding($string, 'ISO-2022-JP', 'UTF-8');
}
private static function hcvt($string)
{
return "=?iso-2022-jp?B?" . base64_encode( self::ecvt($string) ) . "?=";
}
private function sendMail( )
{
$mail = new Message();
$content = 'Message body 日本語も';
$mail->getHeaders()->addHeaderLine('Content-Type', 'text/plain; charset=ISO-2022-JP');
$mail->setFrom('sender#acme.com', self::hcvt('Sender 日本語も') );
$mail->addTo('receiver#acme.com', self::hcvt('Receiver 日本語も') );
$mail->setSubject(self::hcvt('Some subject 日本語も'));
$mail->setBody( self::ecvt($content) );
$mail->setEncoding('ISO-2022-JP');
// this is critical - it works around a bug in zendframework3 where
// MIME encoding is botched in headers. By switching headers to ASCII,
// I basically do the encoding myself.
$mail->getHeaders()->setEncoding('ASCII');
$this->mailTransport->send( $mail );
}
The basis for all this really is here - it is good to read so you know what is going on: RFC2047 https://www.ietf.org/rfc/rfc2047.txt