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 | 12/06/2007 (6425 days ago) |
Due | |
Updated | 07/25/2008 (6193 days ago) |
Assigned | 01/16/2008 (6384 days ago) |
Resolved | 07/25/2008 (6193 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Duplicate
Ticket #1621.Priority ⇒ 1. Low
State ⇒ Stalled
Version ⇒ HEAD
Summary ⇒ MIME encoding of multibyte JP characters
fix the problem. This issue is very complicated and is not something
that can be adequately fixed for Horde 3.2.
Taken from
State ⇒ Assigned
New Attachment: horde-imp-ja2.diff
existence, which is not acceptable.
So, I update my patch.
existence, which is not acceptable.
Prerequisites
c. UTF-8 support ``--with-iconv --enable-mbstring=all --enable-mbregex`
The following PHP options are **RECOMMENDED** to enable advanced
features in Horde:
So mb* functions are not required to exist to run Horde.
existence, which is not acceptable.
Prerequisites
c. UTF-8 support ``--with-iconv --enable-mbstring=all --enable-mbregex`
State ⇒ Feedback
existence, which is not acceptable.
New Attachment: horde-imp-ja.diff
without calling mb_internal_encoding().
Attached file is my japanese-aware patch for horde-3.1.5 and imp-4.1.5.
mb_encode_mimeheader() works when using multibyte charsets. The
problem is that mb_encode_mimeheader() doesn't properly work for
non-multibyte charsets.
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;
}
charset is multibyte or not (without maintaing a static list)?
the charsets we use in the translations.
Assigned to
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)?
iso-2022-jp string. Please fix this first.
Assigned to Michael Slusarz
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Subject line encoding problem
Queue ⇒ IMP
State ⇒ Unconfirmed
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.