GNOME Bugzilla – Bug 208474
need to be able to override charset in attachments too
Last modified: 2001-10-11 17:05:49 UTC
All non-latin1 in attachment names and in bodies are converted to "__".
Forgot to add - I meant message view, not message sending.
can you attach the Content-* headers for the attachment here?
Here is an entire attachment that failed. JFYI it's VCARD attachment by OE. ------=_NextPart_000_002A_01C1319D.9292B840 Content-Type: application/octet-stream; name="=?koi8-r?B?6MHS3sXXIPfMwcTJ08zB1yD3zMHEyc3J0s/Xyd4udmNm?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?koi8-r?B?6MHS3sXXIPfMwcTJ08zB1yD3zMHEyc3J0s/Xyd4udmNm?=" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOtXg8Pfl4jvC6+Dk6PHr4OI7wuvg5Ojs6PDu4uj3 O01SDQpGTjrV4PD35eIgwuvg5Ojx6+DiIMLr4OTo7Ojw7uLo9w0KTklDS05BTUU6SFZWDQpOT1RF OuHl5yDq7uzs5e3y4PDo5eINCkVNQUlMO1BSRUY7SU5URVJORVQ6aHZ2QGhpcHBvLnJ1DQpSRVY6 MjAwMTA4MzBUMTc0ODU4Wg0KRU5EOlZDQVJEDQo= ------=_NextPart_000_002A_01C1319D.9292B840--
I agree content-type for it was not specified. Here are the headers of preceeding part Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Chances are high that Evo tried to treat the body as iso1. Could you try to use first part's charset as charset of the attachment if no charset is specified in headers (or better allow to select charset to treat attachment with)?
the problem is that parts do not know about other parts. This is just the way things *have* to work, they should not have to know about other parts' Content-* headers. With IMAP, you can request individual MIME parts (and we use this feature in Evolution). That said, the filename *should* be appearing correctly. Even though the name/filename params are encoded incorrectly, I added a special-hack for that a while ago when I added support for rfc2184 because Outlook's broken way of encoding parameters is somewhat common amongst the more commonly used mailers. The only possible solution to this that I would be willing to do is to use the charset given in the parameter encoding? Rhetoric question: remind me again why it's *our* job to fix brokenness in other mailers? especially when they are proprietary? argh... this is why writing a mail client is a PITA while at the same time being a thankless job.
> The only possible solution to this that I would be willing to do is to > use the charset given in the parameter encoding? Sorry, didn't understand that. What is 'charset given in parameter encoding'? Its name will be extracted from "=?koi8-r?" prefix in the headers I gave? I would strongly suggest to provide the user ability to select charset of such attachment as a dropdown list (but try to guess initial value intelegently). This is MUCH better than any other hacks! As for why it's your business to fix brokenness in other mailers: It's life. If you want to be best, you have to be best and most intelligent. Don't stop having done 95% of work since the fact that these 5% of work remain unimplemented makes Evo unusable for a lot of people - in quantities say 20 times larger than population of US. So either forget about world domination (and don't waste resources on this project) or do things properly. PS: I just added #8482 - please take a look at it too.
This is related to bug 200921. In addition to being able to override the charset in the main body, we apparently need to be able to override the charset in an attachment.
Well a part can find its parent part, perhaps? Well I dunno, sounds messy :(
this works now *** This bug has been marked as a duplicate of 200921 ***