Duplicate of Ticket #1621.

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.

This looks very hackish to me. But I give Michael the final call.

You are right.

So, I update my patch.

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

Horde-3.1.3 INSTALL document says;

  Prerequisites

     c. UTF-8 support ``--with-iconv --enable-mbstring=all --enable-mbregex`

That patch uses mb_* functions directly without checking for their 
existence, which is not acceptable.

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.

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.

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;

}

No, that's why we *have* that list in nls.php already, but only for 
the charsets we use in the translations.

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)?

Please note that current MIME::encode() is not able to encode 
iso-2022-jp string. Please fix this first.

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.