| Summary: | Character set for 8 Bit attachments is not set properly | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Rolf Eike Beer <kde> |
| Component: | mime | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bastian, fmp0d6sw, lemma, takumi |
| Priority: | NOR | Keywords: | triaged |
| Version: | SVN trunk (KDE 4) | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Rolf Eike Beer
2003-09-23 18:20:21 UTC
what makes you think so? us-ascii are 255 charachters, among them No, that's not correct. RFC 2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types) specifically states that "US-ASCII" is a 7-bit stream. The reporter is correct: the charset for the file is ISO-8859-1. ok, so we're doing that wrong about forever? Subject: Re: Charachter set for 8 Bit attachments is not =?iso-8859-1?q?set=09properly?= This problem will be easily resolved as soon as the file open dialog has a charset selection box (cf. the recent discussion on kde-core-devel). We might have been doing it wrong. But, then again, the charset for attachments isn't taken much into account, as long as the file is properly encoded (8bit, quoted-printable or base64). I've yet to see a MUA that will allow you to convert the file from one charset to another. (wishlist for KMail?) it's not about converting, it's about specifying it correctly. It doesn't matter for us-ascii, but it surely makes a difference if you distribute a UTF-8 file as latin1. But now that the file dialog got the encoding combo in kdelibs, we should be able to make the choice possible easily. And as the wrong encoding can surely be a loss of data, I'd not make this a wishlist. Agreed, but I meant a situation like this: I am on a fully UTF-8 environment and I receive a file from a friend encoded in Latin 1. KMail currently automatically reencodes the filename (since it gets converted to Unicode), but it doesn't change the contents. Not that I am complaining, but one might want the possibility to save the file in UTF-8. Subject: Re: Charachter set for 8 Bit attachments is not set properly
> Agreed, but I meant a situation like this: I am on a fully UTF-8 environment and I receive a file from a
> friend encoded in Latin 1. KMail currently automatically reencodes the filename (since it gets converted
> to Unicode), but it doesn't change the contents. Not that I am complaining, but one might want the
> possibility to save the file in UTF-8.
Ah, on saving. But this bug report is about attaching a file and there it's important. For saving
attachments, it's your own business :)
Greetings, Stephan
*** Bug 42053 has been marked as a duplicate of this bug. *** http://bugs.kde.org/show_bug.cgi?id=42053 is same bug. To save, I think charset is not important. But to view attachment text, charset is important. Many of I18N mailer converts attachment text to locale-codec(or internal-codec) to show it. (KMail doesn't. Because KRun::run() doesn't have charset option. So text viewer should detect attachment text's codec) If KMail set wrong charset to attachment text, receiver can't view attachment text correctly. Still present in Kontact 1.1/KDE 3.4.0 There is no charset selection in "attach file" dialog. Still present in KDE 3.5.3 *** This bug has been confirmed by popular vote. *** Bug 57093 is related to this one. BTW: 8bit encoding never makes sense with charset us-ascii. So chareset us-ascii should force encoding to 7bit. And a 7bit encoding with non-7bit characters should display a big fat warning. *** Bug 110037 has been marked as a duplicate of this bug. *** still present in KMail 1.10.1. charset is "quoted-printable" on the attachment, and 7-bit on everything else. At least it isn't set as us-ascii. If I'm attaching an ISO-8859-15 encoded textfile I still get us-ascii charset regardless of Content-Transfer-Encoding. I tried both 4.1.2 and trunk r887937. SVN commit 888149 by tmcguire: An attempt to repair the encoding mess a bit, when attaching files: - Don't set the charset to us-ascii if it couldn't be found - Give up on KEncodingProber, it doesn't work reliable enough. Instead, add an encoding combobox to the file dialog. Now it is the user's fault if the encoding is not correct :) - Don't attempt to set a charset for a non-textual mimetype - Don't show an empty string for the mimetype BUG: 64815 M +90 -63 kmail/kmcomposewin.cpp M +13 -7 kmail/kmmsgbase.cpp M +12 -2 kmail/kmmsgbase.h M +7 -23 libkdepim/kmeditor.cpp M +6 -1 libkdepim/kmeditor.h WebSVN link: http://websvn.kde.org/?view=rev&revision=888149 SVN commit 890890 by tmcguire: Backport r888149 by tmcguire from trunk to the 4.1 branch: An attempt to repair the encoding mess a bit, when attaching files: - Don't set the charset to us-ascii if it couldn't be found - Give up on KEncodingProber, it doesn't work reliable enough. Instead, add an encoding combobox to the file dialog. Now it is the user's fault if the encoding is not correct :) - Don't attempt to set a charset for a non-textual mimetype - Don't show an empty string for the mimetype CCBUG: 64815 M +78 -52 kmail/kmcomposewin.cpp M +13 -7 kmail/kmmsgbase.cpp M +12 -2 kmail/kmmsgbase.h M +7 -23 libkdepim/kmeditor.cpp M +6 -1 libkdepim/kmeditor.h WebSVN link: http://websvn.kde.org/?view=rev&revision=890890 |