Fri, 10 Apr 2026 09:21:05 +0000 https://bugs.horde.org/ticket/5972 MIME encoding of multibyte JP characters Jan Schneider asked me to submit this bug report. Imp does not always encode the Subject line correctly when a non-default encoding is selected. I was able to replicate the error by typing Japanese characters into both the Subject and the body and selecting ISO-2022-JP encoding. The body of the message was sent correctly, but the Subject was garbled like so: =?UNKNOWN?Q?=1B$BF|K=5C8l=1B=28B?= This is what should have been sent: =?iso-2022-jp?b?GyRCRnxLXDhsGyhC?= Mailing list threads on this issue begin with these messages: http://marc.info/?l=imp&m=119695412415121&w=2 http://article.gmane.org/gmane.comp.horde.imp/24146 Note: Gmane seems to display the Japanese test characters correctly, Marc does not. Thu, 06 Dec 2007 17:06:40 +0000 https://bugs.horde.org/ticket/5972#t39521 Please note that current MIME::encode() is not able to encode iso-2022-jp string. Please fix this first. Thu, 13 Dec 2007 13:48:23 +0000 https://bugs.horde.org/ticket/5972#t39764 This one is easy. None of our MIME:: functions work with multibyte characters. And it may be difficult to fix this in PHP since we need a multibyte character-aware regular expression engine, and mb_ereg() doesn't seem to accept ISO-2022-JP as a valid charset - I get 'Warning: mb_regex_encoding() [function.mb-regex-encoding]: Unknown encoding "ISO-2022-JP"' errors. It *is* possible to use mb_encode_mimeheader() to encode multibyte headers properly, but mb_encode_mimeheader() is much much too greedy to use on everyday, non multi-byte messages (it apparently will encoding everything, even if the string is ASCII). So this is a viable solution only if we can restrict use of this function to multibyte charsets only. is there an easy way to determine if a charset is multibyte or not (without maintaing a static list)? Fri, 14 Dec 2007 08:44:36 +0000 https://bugs.horde.org/ticket/5972#t39890 > multibyte charsets only. is there an easy way to determine if a > charset is multibyte or not (without maintaing a static list)? No, that's why we *have* that list in nls.php already, but only for the charsets we use in the translations. Fri, 14 Dec 2007 11:13:52 +0000 https://bugs.horde.org/ticket/5972#t39904 I've search the net and get a solution. This code works for me both php-4.4 and php5.1. Line-folding OK too. function mbencode ($text,$charset) { $sav_enc = mb_internal_encoding(); mb_internal_encoding($charset); $ret = mb_encode_mimeheader($text,$charset,'B'); mb_internal_encoding($sav_enc); return $ret; } Mon, 17 Dec 2007 14:31:28 +0000 https://bugs.horde.org/ticket/5972#t39988 > I've search the net and get a solution. > This code works for me both php-4.4 and php5.1. > Line-folding OK too. > > function mbencode ($text,$charset) > { > $sav_enc = mb_internal_encoding(); > mb_internal_encoding($charset); > $ret = mb_encode_mimeheader($text,$charset,'B'); > mb_internal_encoding($sav_enc); > return $ret; > } Please read the previous comments. I already said mb_encode_mimeheader() works when using multibyte charsets. The problem is that mb_encode_mimeheader() doesn't properly work for non-multibyte charsets. Tue, 18 Dec 2007 04:37:49 +0000 https://bugs.horde.org/ticket/5972#t40016 >> I've search the net and get a solution. >> This code works for me both php-4.4 and php5.1. >> Line-folding OK too. >> >> function mbencode ($text,$charset) >> { >> $sav_enc = mb_internal_encoding(); >> mb_internal_encoding($charset); >> $ret = mb_encode_mimeheader($text,$charset,'B'); >> mb_internal_encoding($sav_enc); >> return $ret; >> } > > Please read the previous comments. I already said > mb_encode_mimeheader() works when using multibyte charsets. The > problem is that mb_encode_mimeheader() doesn't properly work for > non-multibyte charsets. Sorry confusion. My point is that mb_encode_mimeheader() doesn't work well without calling mb_internal_encoding(). Attached file is my japanese-aware patch for horde-3.1.5 and imp-4.1.5. Tue, 18 Dec 2007 06:16:23 +0000 https://bugs.horde.org/ticket/5972#t40017 That patch uses mb_* functions directly without checking for their existence, which is not acceptable. Mon, 24 Dec 2007 21:10:18 +0000 https://bugs.horde.org/ticket/5972#t40260 > That patch uses mb_* functions directly without checking for their > existence, which is not acceptable. Horde-3.1.3 INSTALL document says; Prerequisites c. UTF-8 support ``--with-iconv --enable-mbstring=all --enable-mbregex` Wed, 26 Dec 2007 05:04:13 +0000 https://bugs.horde.org/ticket/5972#t40351 >> That patch uses mb_* functions directly without checking for their >> existence, which is not acceptable. > Horde-3.1.3 INSTALL document says; > Prerequisites > c. UTF-8 support ``--with-iconv --enable-mbstring=all --enable-mbregex` ...and the header for that sections says: The following PHP options are **RECOMMENDED** to enable advanced features in Horde: So mb* functions are not required to exist to run Horde. Wed, 26 Dec 2007 06:40:51 +0000 https://bugs.horde.org/ticket/5972#t40357 >>> That patch uses mb_* functions directly without checking for their >>> existence, which is not acceptable. You are right. So, I update my patch. Fri, 28 Dec 2007 02:06:41 +0000 https://bugs.horde.org/ticket/5972#t40463 This looks very hackish to me. But I give Michael the final call. Wed, 16 Jan 2008 22:46:44 +0000 https://bugs.horde.org/ticket/5972#t41213 > This looks very hackish to me. But I give Michael the final call. This patch is not correct. It breaks some things and doesn't fully fix the problem. This issue is very complicated and is not something that can be adequately fixed for Horde 3.2. Thu, 17 Jan 2008 07:30:02 +0000 https://bugs.horde.org/ticket/5972#t41263 Duplicate of Ticket #1621. Fri, 25 Jul 2008 21:34:46 +0000 https://bugs.horde.org/ticket/5972#t47794