HTML email and European Characters

blackhorse

I have a script grab the data from database and email it in html format to the recipients.

The problems are when the data inputter input the data to the database, they may cut and paste the data from resource with different characters set.

For example, word "Flügel" may be in different character sets when input to the database.

Now when I grab data and email out. Depends on the recipient's client site email software character set up.

I can read all the "Flügel" in the content. But some people can only read some ""Flügel" and some "Flügel" turn to "Fl?gel"

Questions:

1) Say the data is input to the database from php web pages only, how can I control the character sets of data inputted to the database when the data inputter can copy and pate from any character sets resource to form's textarea?

2) If the database already have the "Flügel" in different character sets, then when I emal html, to make sure all of "Flügel" work in the html email, what should I do? htmlentities the email content before email out? (but the data inputter may already copy and paste the data being htmlentities already, then I would solve one problem here but all these data being htmlentities before would be htmlentites again, new problem!)

How do you handle it?

Thanks!

djjjozsi

i'm often make databases for central and eastern european codes.

then i use utf8_general_cyric coding for the tables, and on selects i use the

mysql_query("SET NAMES latin2");

this is the closest character sets to use
úőűáóüöí characters.

And in the mail headers you can set the same character set:

                $headers  = 'MIME-Version: 1.0' . "\r\n";
                $headers .= 'Content-type: text/html; charset=iso-8859-2' . "\r\n";

blackhorse

Thanks!

I use the same

$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-2' . "\r\n";

The database, the web pages display are all fine.

Just when email sent out, some recipients got email cannot display the "úőűáóüöí". But gmail, hotmail, my own outlook express are all fine.

I think it is due to the character set up of their desktop computer.

Is this a client side issue that no way to satisfy all of them until all the data and every one is on unicode?

blackhorse

djjjozsi

Two questions:

1) so you use utf8 for the tables, but use latin2 for the col "NAME" in that table?

How these characters "úőűáóüöí" in the "NAME" field which is latin2 display on your web page if your web page is on utf8? Will that be displayed OK?

I think if your data is saved in latin1 but then displayed on the utf8 web pages, you will have some troubles with "úőűáóüöí" etc. in your web pages.

2) so your database is utf8, your web site is utf8, when you send your email, you use "charset=utf8" or you use "charset=iso-8859-2"? I will assume you use "charset=utf8" when you send email. Does your email recipients have troubles if their email client software are on some other set ups except utf8?

blackhorse

Plus, a related question, the database tables are latin1. will that be possible the data inputter cut and paste "úőűáóüöí" from different characters set resource and save these data with its original character set in the same table?

I did see a few times the same character "ü" in the content, some of the "ü"s were fine in the web pages, although some of the "ü" were shown like "?" in the web pages. Even these "ü" are from same database table. After I copied the good "ü" and replaced the bad "ü", then they were all fine in the web pages.

How could that be possible?

Roger_Ramjet

The good and bad "ü" in the db are caused by the different encoding of the original sources: some were utf8 and some were not.

The display problem on the client is down to their client settings and there is nothing you can do about that.

blackhorse

I figured out a solution

$value=htmlspecialchars_decode(htmlentities($value));

htmlentities will Convert all applicable characters to HTML entities.
htmlspecialchars_decode — Convert special HTML entities back to characters. So the html format tags will be turned back as the html tags, but the special European characters will still be in htmlentities.

So far it is working in the email sent out.