| Summary | Long attachment filenames with special charset displayed incorrectly |
| Queue | IMP |
| Queue Version | 4.1.3 |
| Type | Bug |
| State | Duplicate |
| Priority | 1. Low |
| Owners | slusarz (at) horde (dot) org |
| Requester | ditsa (at) ccf (dot) auth (dot) gr |
| Created | 08/28/2006 (6950 days ago) |
| Due | |
| Updated | 08/29/2006 (6949 days ago) |
| Assigned | 08/28/2006 (6950 days ago) |
| Resolved | 08/29/2006 (6949 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Duplicate
Bug 4348.State ⇒ Assigned
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Long attachment filenames with special charset displayed incorrectly
Queue ⇒ IMP
attachment filenames that contain greek (ISO-8859-7) characters are
not displayed correctly in IMP 4.1.3, when the length of the filename
exceeds a certain number of characters. Yet when downloaded, filenames
appear correct in OS save dialog window.
Example of a filename encoding that appears incorreclty in IMP:
--------------020001090103010501080506
Content-Type: application/msword;
name*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5%E9.doc
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename*0*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5%E9.d;
filename*1*=oc
Example of a filename encoding that appears correclty in IMP:
--------------080904060007010807050604
Content-Type: application/msword;
name*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename*=ISO-8859-7''%C4%EF%EA%E9%EC%E1%F3%F4%E9%EA%FC%E1%F1%F7%E5.doc
Obviously, when the filename exceeds 19 characters, Thunderbird brakes
up the filename in two parts (filename*0*, filename*1*) which IMP does
not handle or display correctly, but is able to deliver correctly for
download.
Could there be a fix for this to be displayed correctly on IMP?
Thanks.