I have a strange issue with encoding, described as follows:
the ù is now shown as ù in the email subject. The email is sent through php mail function.
When viewing the e-mail in the mailbox, it is shown correctly. However, when anybody opens the e-mail, the ù is suddenly changed to ù.
Uw contact met Meeùs
should be
Uw contact met Meeùs
i have already used the encoding.
$emailsubject contains the above mentioned email subject.
$subject=$emailsubject;
$subject=$emailsubject;
$email_message=new email_message_class;
$email_message->SetEncodedEmailHeader("To",$to_address,$to_name);
$email_message->SetEncodedEmailHeader("From",$from_address,$from_name);
$email_message->SetEncodedEmailHeader("Reply-To",$reply_address,$reply_name);
$email_message->SetHeader("Sender",$from_address);
$email_message->SetEncodedHeader("Subject",$subject,"UTF-8");
In localhost it is working properly, but in the webserver it is not working properly. In webserver also encoding is set to utf-8 by default.
What i am doing wrong?
Thanks in advance.
Your code is correct absolutely there is no error in it but its other things failing encoding. As I need message source headers and message to tell you exactly what is happening? I have further no information about are you sending the email as plain text or HTML. But there are generally two issue which are:
Missing Mime-Version
Reason for showing the character wrongly is developers forget to describe the message as MIME Version. if the message is missing the "Mime-Version" header that Internet mail standards require, Webmail will ignore the "charset" header completely, garbling the message unless it's already in the UTF-8 character set.
Showing Subject with Special Characters
As you want to show the subject with utf-8 encoding then you must encode the subject as:
//Setting the Language as Japan
mb_language("ja");
//Converting the string into Japan Encoding
$subject = mb_convert_encoding($subject, "ISO-2022-JP","AUTO");
//Now convert the string to MIME Header type
$subject = mb_encode_mimeheader($subject);
If the above mentioned things doesn't resolve the problem then request you post the RAW Headers of the Email as it will help in better way to resolve issue.
Are you test to change the charset with .htaccess ?
AddDefaultCharset UTF-8
Since you indicate in the comments you are using Joomla 1.5, it seems there is an issue with the phpmailer() library in that version that forces the character set of the mailer—on the message—to send things out using the character set setting of iso-8559-1. To fix this open up the core phpmailer() libary here:
[path to your Joomla install]/libraries/phpmailer/phpmailer.php
Around line 50 there is a setting called $CharSet. Change that to utf-8 if it’s not set to that already:
/**
* Sets the CharSet of the message.
* #var string
*/
var $CharSet = 'utf-8';
You might also want to do search of your Joomla 1.5 codebase for iso-8559-1 to see if a component or library is forcing iso-8559-1 encoding somewhere in the chain of code.
And another setting I would recommend checking is $Encoding around line 63. The default setting seems to be 8bit, but I have had to adjust that in the past to either quoted-printable or base64 to solve some mailing issues on specific setups I was working on.
/**
* Sets the Encoding of the message. Options for this are "8bit",
* "7bit", "binary", "base64", and "quoted-printable".
* #var string
*/
var $Encoding = '8bit';
I suggest you to use joomla mailer class, the could would look like this:
$mailer = JFactory::getMailer();
$mailer->setSender(array($from_address,$from_name));
$mailer->addRecipient($to_address, $to_name);
$mailer->setSubject($subject);
$mailer->setBody("BODY MESSAGE STRING");
$mailer->Send();
It's utf8 by default, and i don't see any reasons for not to use it, if you're using Joomla.
Related
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 old web app that generates XML files in php. This XMLs are requested by XMLHttpRequest object (AJAX). Everything works correctly. But today there has been some server upgrade and web app breaks down a little.
The problem is that in code there are checks related to XMLHttpRequests.
1) if I have a response than I parse it properly based on it content type.
var contentType = xhr.getResponseHeader("Content-Type");
//build the json object if the response has one
if(contentType == "application/json") {
response = JSON.parse(xhr.responseText);
}
//get the dom element if the response is XML
else if(contentType == "text/xml") {
response = xhr.responseXML;
} else { //by default get the response as text
response = xhr.responseText;
}
And here is the problem cause server now returns:
text/xml;charset=UTF-8
instead of
text/xml
Ok I can just change this line and the error disappear. But I would like to know why server upgrade (bluehost) can have influance on this.
This is PHP/MySQL environment.
Both are valid content types. The content type can be set by the web server software (e.g. Apache) or the script (PHP). I'm assuming it's PHP because of the tag on your question.
If you control the script on the server and want to specify the content type, it's easy to do within PHP by adding the line:
header('Content-Type: text/xml');
This must occur before any other output is sent from the script because headers appear before content in http responses. If the header is not set within the PHP script, then the web server will choose one instead.
If you don't control the script that produces the XML or the server then you just need to accept that it is common for systems to be upgraded and this may impact on your own application.
Just to add to Steve E's answer, the "charset=UTF-8" portion is specifying a character set.
There is no better explanation of unicode (UTF-8 is an implementation of unicode) and character sets then the one on Joel on Software, here (incidentally Joel also created Stack Overflow). In short, character sets define the set of characters than can be used in text. Unicode, a character set, supports nearly all international languages. UTF-8 specifies how the Unicode character set is implemented in bytes (so with UTF-8, Unicode characters take anywhere from 1 - 4 bytes). When you see garbled text (for example ?s instead of characters) that is often because the document is not being interpreted in the correct character encoding.
It's actually best practice to include the encoding in the content-type header, so I would keep it as "text/xml;charset=UTF-8". Bluehost was likely updating their default settings (ie/ the default content-type they display for xml documents) which caused the change. Just as an aside, the terms character set and encoding are sometimes used interchangeably, but when you specify "charset=UTF-8" you are more correctly specifying the encoding (UTF-8 is the encoding, Unicode is the character set).
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