> (This is a reply to a problem in the archives, from March: > http://marc.info/?l=php-i18n&m=120595161128203&w=2 ) > > As you obviously have the mb_string extension installed, have you tried > using mb_send_mail() instead of mail()? Then you shouldn't need to mess > around encoding your own mimeheaders. > > <minor rant> > Later in the thread Tomas suggested using UTF-8 instead of ISO-2022-JP, > and getting Docomo to change. The problem is all those handsets in > existence. Not to mention all the other legacy email clients that don't > work well with UTF-8, but real people still use. Docomo could convert > from UTF-8 to ISO-2022-JP at the gateway of course, which apparently is > what softbank and kddi actually do, but Docomo deal with a lot of email > so care about the cost of the extra CPU cycles, and you're going to need > better motivation for them than "PHP cannot write proper MIME headers" I > suspect. > </minor rant>
I missed mb_encode_mimeheader dependency on internal mbstring encoding. If internal mbstring charset is set, mb_encode_mimeheader should work correctly. Still using utf-8 instead of iso-2022-jp is better solution. "other legacy email clients" some day will face same situation Japanese had one and a half centuries ago when country could not defend itself from four steam ships. In modern world seclusion hurts only the ones are using it. iso-2022-jp is outdated charset. ISO-2022-JP does not support all characters that can be used in utf-8 html form and it is harder to parse than utf-8. -- Tomas -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
