6.0.0-git
2019-03-19

[#5972] MIME encoding of multibyte JP characters
Summary MIME encoding of multibyte JP characters
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Duplicate
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester daniel.ramaley (at) drake (dot) edu
Created 2007-12-06 (4121 days ago)
Due
Updated 2008-07-25 (3889 days ago)
Assigned 2008-01-16 (4080 days ago)
Resolved 2008-07-25 (3889 days ago)
Milestone
Patch No

History
2008-07-25 21:34:46 Michael Slusarz Comment #14
State ⇒ Duplicate
Reply to this comment
Duplicate of Ticket #1621.
2008-01-17 09:35:42 Jan Schneider Version ⇒ HEAD
Queue ⇒ Horde Framework Packages
State ⇒ Stalled
Priority ⇒ 1. Low
 
2008-01-17 07:30:02 Michael Slusarz Comment #13
Summary ⇒ MIME encoding of multibyte JP characters
Reply to this comment
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.
2008-01-16 22:46:44 Jan Schneider Comment #12
Taken from Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment
This looks very hackish to me. But I give Michael the final call.
2007-12-28 02:32:02 Chuck Hagenbuch Deleted Original Message
 
2007-12-28 02:06:41 hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp Comment #11
New Attachment: horde-imp-ja2.diff Download
Reply to this comment
That patch uses mb_* functions directly without checking for their
existence, which is not acceptable.
You are right.

So, I update my patch.
2007-12-26 06:40:51 Michael Slusarz Comment #10 Reply to this comment
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.
2007-12-26 05:04:13 hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp Comment #9 Reply to this comment
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`


2007-12-24 21:10:18 Chuck Hagenbuch Comment #8
State ⇒ Feedback
Reply to this comment
That patch uses mb_* functions directly without checking for their 
existence, which is not acceptable.
2007-12-18 06:16:23 hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp Comment #7
New Attachment: horde-imp-ja.diff
Reply to this comment

[Show Quoted Text - 17 lines]
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.
2007-12-18 04:37:49 Michael Slusarz Comment #6 Reply to this comment

[Show Quoted Text - 12 lines]
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.
2007-12-17 14:31:28 hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp Comment #5 Reply to this comment
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;

}


2007-12-14 11:13:52 Jan Schneider Comment #4 Reply to this comment
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.
2007-12-14 08:44:36 Michael Slusarz Comment #3
Assigned to Horde DevelopersHorde Developers
Reply to this comment
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)?
2007-12-13 13:48:23 hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp Comment #2 Reply to this comment
Please note that current MIME::encode() is not able to encode 
iso-2022-jp string. Please fix this first.
2007-12-06 17:57:40 Jan Schneider Assigned to Michael Slusarz
State ⇒ Assigned
 
2007-12-06 17:06:40 daniel (dot) ramaley (at) drake (dot) edu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Subject line encoding problem
Queue ⇒ IMP
Reply to this comment
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.

Saved Queries