| Summary | IMP4 japanese subject problem |
| Queue | IMP |
| Queue Version | FRAMEWORK_3 |
| Type | Bug |
| State | Resolved |
| Priority | 2. Medium |
| Owners | |
| Requester | hiromi (at) tac (dot) tsukuba (dot) ac (dot) jp |
| Created | 02/22/2005 (7519 days ago) |
| Due | |
| Updated | 03/07/2005 (7506 days ago) |
| Assigned | 03/06/2005 (7507 days ago) |
| Resolved | 03/07/2005 (7506 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Resolved
New Attachment: 1423.zip
1423.mail -- mail message
1423-ng.gif -- screen shot of current IMP (NO GOOD)
1423-ok.gif -- scrren shot (GOOD)(used my own patch)
State ⇒ Feedback
Priority ⇒ 2. Medium
Version ⇒ FRAMEWORK_3
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ IMP4 japanese subject problem
Queue ⇒ IMP
(in mailbox view and message view)
Reason:
Japanese mails uses iso-2022-jp(7 bit) encoding, for example;
Subject: =?ISO-2022-JP?B?GyRCJSYlIyVrJTk2bj18GyhC?=
This string is decoded by decode() in horde/lib/Horde/MIME.php;
(line 351)
case 'B':
case 'b':
$decoded = urldecode(base64_decode($encoded_text));
$decoded = String::convertCharset($decoded, $charset,
$to_charset);
The result string of base64_decode() is;
esc $ B % & % # % k % 9 6 n = | esc ( B (18 bytes total)
^ ^ ^
these '%9' and '6n' repesent japanese characters,
but urldecode() convert '%96' to another one !!
So, urldecode() is not need for iso-2022-jp encoding.