I'm using the mail function on php to send a confirmation email. It actually works, but just for some mails. For example, if you recieve that on a gmail it's fine, but on a college mail it appears ? instead of special characters.
The problem is that that mail includes a validation link,which looks like www.myweb.com/confirmation.php?passkey=(passkey) and if the mail and the special characters aren't send properly this link is also wrong (the = doesn't appear).
I've already tried writting
iconv_set_encoding("internal_encoding", "UTF-8");
on top of the mail function, but it doesn't work. What can it be?
Thanks for your help!
Try utf-8 encoding in header
For example:
$headers .= "Content-Type: text/html; charset=utf-8\r\n";
Related
Character sets are driving me round the bend!
My database is utf8_general_ci and the tables within it are utf8_unicode_ci.
All my PHP pages have
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
in the head.
When I type a euro symbol (€) in the PHP page and input it to the database it appears in phpMyAdmin as €
When I use a PHP page to copy it from the database, it reappears as €
So far so good, but when I write am html email using PHP, no matter what I do it comes out in the email as €
I've tried specifying the character set in the html email but it doesn't work. Probably because email clients take their character set from the mail server and not the headers.
I've also got issues with accented letters and the like, but they are being written into the text so I could overcome them by using é for é, and so on. Messy, but not impossible.
Surely there's a better way!
MY SOLUTION (SORT OF)
Thanks to all who contributed. I have tried all ways to specify the character set to utf-8 (in the mail headers, in the html head, and both) but the message still arrives in iso. So it seems the information I got from elsewhere was right: character set is defined by the server.
I have had to settle for typing things like é each time I want é into the fixed text, which is cumbersome but at least it works.
For the euro symbol, I have wrapped the variable in the htmlentities function. It works, but I will have to remember to do it with any other variables taken from the database if I encounter similar problems in similar files. It would have been easier to wrap the function around the entire html body but that doesn't work, presumably because it does funny things with the .
Check the encoding in your text editor. Crazy things can happen if this is wrong!
For MySQL, see mysql_set_charset.
Emails actually get their character set from the Content-Type header, not from the email server. Make sure you set this header to an appropriate value, such as Content-Type: text/html; charset="UTF-8". See also this question.
And keep in mind that for HTML, you can use $encoded = htmlentities( $string, ENT_QUOTES, 'utf-8' ) so that all characters which have HTML character entity equivalents are translated into these entities.
I guess that the correct answer for you is just setting utf-8 charset for the e-mail:
$headers = "MIME-Version: 1.0\r\n";
$headers.= "From: =?utf-8?b?".base64_encode($from_name)."?= <".$from_a.">\r\n";
$headers.= "Content-Type: text/plain;charset=utf-8\r\n";
$headers.= "Reply-To: $reply\r\n";
$headers.= "X-Mailer: PHP/" . phpversion();
mail($to, $s, $body, $headers);
If you open the email source in your client (ctrl+u in thunderbird). You will see a Content-Type header. This should be something like:
Content-Type: text/html; charset=utf-8
If your email contains multiple parts your need to add that header to html part.
Header values need to be encoded separately (each line).
Subject: =?utf-8?B?...?=
For the html content you can just use htmlentities() but this will not work for the headers or a text email.
I need to send emails using PHP's mail() function. The code I am using is this:
$email_message = chunk_split(base64_encode($email_message));
$headers = "Content-Transfer-Encoding: base64\r\n\r\n";
mail($to, $subject, $email_message, $headers);
There is a pound sterling symbol in the email which is not handled properly, i.e. recipient receives incorrect symbol. As its to do with character encoding and I am not sure how to set it to tell the email client how the characters are being encoded and how to deal with the pound symbol correctly. Can this information be put in the headers?
Are you correctly setting the encoding on the email? This is done by setting
'Content-type: text/html; charset=utf-8'
in the message's headers.
Plenty of documentation here if you scroll down: http://php.net/manual/en/function.mail.php
If you have pound signs coming out as  then look below
$costsum = "£".$costsum; (Does not work)
$costsum = "£".$costsum; (Does not work)
$costsum = "#163;".$costsum; (Does not work)
One answer I found was this!
$costsum = "\243".$costsum;
The \243 is a pound sign in whatever encoding that is.
I tried all the pages with UTF-8 and that didn't work either.
It was used to email a spreadsheet.
Im sending a mail using php, and the subject of the mail has accents.
Im receiving weird characters in Outlook instead the accented chars. If i see the email in a web email client i see the subject perfect.
This is the code that im using to send the email:
$to = 'whateveremail#whatever.com';
$subject = '[WEBSITE] áccent – tésts';
$message = '<p>Test message</p>
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers.= 'From:equipothermomix#thermomix.com' . "\r\n";
$headers.= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
mail($to, $subject, $message , $headers);
How i could solve the issue, do i have to use another charset?
The only reliable way to send e-mail is using plain 7 bit ASCII so you need to encode strings properly when you want to use anything else. In your case, [WEBSITE] áccent – tésts should be encoded as (e.g.) =?windows-1252?B?W1dFQlNJVEVdIOFjY2VudCCWIHTpc3Rz?=, where the string splits as:
=?windows-1252?B?W1dFQlNJVEVdIOFjY2VudCCWIHTpc3Rz?=
^ ^ ^
| | |
Charset | Data
|
Base64
Check:
echo base64_decode('W1dFQlNJVEVdIOFjY2VudCCWIHTpc3Rz'); // [WEBSITE] áccent – tésts
This is just an example of one of the possible ways to encode non-ASCII strings.
When sending e-mail, there are many little details like this that need attention. That's why sooner or later you end up using a proper e-mail package like Swift Mailer or PHPMailer.
If there is a mix of encoding types, special characters are destroyed.
PHP messing with HTML Charset Encoding
PHP also has an option for encoding messages.
mb_language('uni'); // mail() encoding
PHP - Multibyte String
http://php.net/manual/en/mbstring.overload.php
http://php.net/manual/en/ref.mbstring.php
I am using an already written Mail class in php. Emails are mostly sent in spanish language. Following are the headers being passed to the php mail function -
MIME-Version: 1.0
Content-Type: multipart/mixed;
Also additional headers are being appended to the message (don't know what it does),
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Emails appear properly in browsers but in mail clients, accented characters are replaced by question marks
for eg:
Una nueva contraseña se solicito
appears
Una nueva contrase�a se solicito
have checked this in Thunderbird and outlook
How do I fix this to show these characters correctly in mail clients as well
I guess you have to change the character set to UTF-8 in Thunderbird and Outlook as well.
The email is probably being sent out as something other than UTF-8. Make sure to convert the text to UTF-8 before passing it to the class (or convert it to UTF-8 in the class).
Like Raffael say the client have to be in UTF-8 too, the better solution is to pass with htmlentities before sending the mail and display the mail as HTML
I've set up a local dev environment on snow leopard, and have set postfix up to send email via my isp mail server.
I eventually got postfix to work after much frustration, but now when my emails send the header information is bunged up!
I'm using the following php code:
$email = "me#mydomain";
$subject = "Email tester";
$body = "Simple test";
$header = "From: me#mydomain \r\n";
$header .= "MIME-VERSION: 1.0\r\n";
$header .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
$phpversion = phpversion();
$header .= "X-Mailer: PHP v$phpversion\r\n";
mail($email,$subject,$body,$header);
echo "message sent!";
The To: and Subject: headers display as they should, in the header!, but the rest display in the email body. This makes the email look like the from field in email client is empty.
I've tried a variety of php scripts, some very simple, but its the same thing, headers always displaying in the email body.
I'm thinking it could be a postfix problem, but not sure, anyone encountered this type of problem before?
Use PHP_EOL instead of \r\n in *additional_headers*, i.e. $header in your example. PHP_EOL will substitute the newline correspondingly to the OS you are running on.
Also, message should contain LN only i.e. \n. This is accordingly to PHP documentation.
Each line should be separated with a LF (\n). Lines should not be larger than 70 characters.
Make sure you meet both of criterias in your script - I've tried to achieve it and finally got it working with the default configuration of Postfix.
This is almost 100% not a Postfix problem, but something caused by your code. The body starts once a blank CRLF is seen after the headers.
You should dump out your email body text and see if you're not accidentally introducing an extra CRLF.
Investigating this problem further (basically because I didn't want to improve lots of scripts just because of that), I've come to the point that there is a strong conflict between PHP and Postfix developers, which is not fixed until now. You can read wide info here:
http://www.mail-archive.com/postfix-users#postfix.org/msg03226.html
Postfix expects EOL to be LF when picking up mail from sendmail on unix and
replaces that with CRLF when sending. When it gets CRLF it still replaces the
LF and we get CRCRLF.
It explains broken headers. To solve this, you must exactly know how your Postfix and PHP/mail system works. If you experience problems like described above, just use "\n" instead of "\r\n". If you program a complicated system which could run on both Windows/Unix, just introduce an extra param like $eeol="\r\n"; which will be put instead of direct "\r\n" tag and that way could be easily configured for any system.
I suppose that's the approach Postfix author recommends:
It would be really good if PHP application programmers formatted email messages in a consistent manner. For example, they could use a variable that contains the END-OF-LINE terminator, instead of hard-coding LF or CRLF line terminators all over the place.