Re: Problems with mime encoding of Japanese Characters in Subject and'From:' etc. fields.

> Hi, > > I try to send messages written in Japanese (Kana/Kanji) with php. > > Everything works fine - only when the subject (or the name of the > sender) becomes longer, there seems to be something wrong with the > encoding: Neither my nor the mail reader of other Japanese friends is > able to decode the mime string. At the place of the Japanese > Characters, the mime string itself is displayed. > > As this doesn't happen for other Japanese emails with even long > subjects, I suppose I did something wrong... > > When using the corresponding php mb_* functions to decode the string > back, sometimes the correct original string and sometimes meaningless > characters are shown. > > Here how I convert the subject (the name is converted using the same > method and the sources are saved in UTF-8 using emacs): > > $subjectJIS = mb_convert_encoding($subject, "ISO-2022-JP", "AUTO"); > $subjectMIME = mb_encode_mimeheader($subjectJIS, "ISO-2022-JP", "B"); > ...snip... > mail($to, $subjectMIME, $bodyJIS, $headers); > > Here part of the message as it is displayed by my mail program: > > From: > > =?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?==?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?=(B > <d.bollmann@tu-berlin.de> > ...snip... > Subject: > =?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?= > =?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?= (B > ...snip... ... > If anybody can explain me the problem I would be most gratefull :) Bug in mb_encode_mimeheader. Function does not follow rfc2047, chapter 3, second paragraph. I suspect that function base64 encodes string first and then splits it according to length argument or fails to add escapes when texts in iso-2022 charsets are folded. It breaks iso-2022 escapes. In http://bugs.php.net/bug.php?id=23192 moriyoshi@php.net wrote that issues should be reported on php-i18n first. Header posted on that bug report shows same issue with broken iso-2022 escapes, but Moriyoshi wrote that it is encoded correctly. Are things unchanged since 2003-04? Do I have to report bug here or on bugs.php.net? -- Tomas