[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-i18n
Subject:    [PHP-I18N] Re: Problems with mime encoding of Japanese Characters in Subject
From:       195.22.180.233
Date:       2008-05-13 8:11:03
Message-ID: 6D.A4.56987.82D49284 () pb1 ! pair ! com
[Download RAW message or body]

> (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

[prev in list] [next in list] [prev in thread] [next in thread]