Summary | Incorrect encoding by MIME::encode() on some UTF-8 strings |
Queue | Horde Base |
Queue Version | 3.0.3 |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | jan (at) horde (dot) org, slusarz (at) horde (dot) org |
Requester | horde (at) ndn (dot) no |
Created | 03/22/2005 (7491 days ago) |
Due | |
Updated | 04/22/2005 (7460 days ago) |
Assigned | 03/25/2005 (7488 days ago) |
Resolved | 04/22/2005 (7460 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
I tried to apply the patch, but it didn't apply to the Horde version I
am using (3.0 and 3.0.2).
I will try the patch later, to solve the problem here I've just
hardcoded the use of UTF-8, as described earlier.
Kristian
State ⇒ Resolved
State ⇒ Feedback
Bug #1621. Could you try the patchthere and see if that fixes things for you. I was able to reproduce
your error, and that patch fixed it for me.
New Attachment: phpshell.php.html
processing headers when sending mail with the ISO-8859-1 charset -
perhaps MIME::encode() should somehow specify the character set in use
to enable the string to be split correctly (ie. not inside a
character. :)
I've included the output from the function when using the PHP shell.
MIME::_encode, which encodes a single word, gets the encoding right.
Assigned to Michael Slusarz
previously observed on the system i thought was OK without the fix,
but I am unable to reproduce it now.
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Incorrect encoding by MIME::encode() on some UTF-8 strings
Queue ⇒ Horde Base
"å"), causing incorrectly encoded headers when sending mail with UTF-8
(but not ISO-8859-1), i tracked it to line 142 in lib/Horde/MIME.php:
$size = preg_match_all('/([^\s]+)([\s]*)/', $text, $matches, PREG_SET_ORDER);
In my case, adding the Unicode option (/u) to the regex solved the problem:
$size = preg_match_all('/([^\s]+)([\s]*)/u', $text, $matches, PREG_SET_ORDER);
It seems preg_match_all does not always handle multibyte characters
(e.g. norwegian Å). On a system with PHP 4.3.10, Apache/1.3.33, and,
the bug appeared, as shown by this Amavis alert with "Åretur" as the
subject:
X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char 85 hex) in
message header 'Subject'
Subject: Re: =?utf-8?b?ww==?=\205retur\n
A var_dump of $matches would show the mangled first character as the
first entry in the array, with "retur" in the second entry.
On another system running PHP 4.3.9, Apache/1.3.31 the bug did NOT appear.
I'm not sure whether this is a bug with other character sets, or
whether turning on multibyte character support in PHP would solve the
problem.