| Summary: | Umlauts in the subject aren't displayed correctly in the message list | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Andreas Schneider <asn> |
| Component: | message list | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tokoe |
| Priority: | NOR | ||
| Version: | 2.0.89 | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | example with buggy 'ä' and correct 'Ü' | ||
|
Description
Andreas Schneider
2010-12-12 12:01:35 UTC
Created attachment 54513 [details]
example with buggy 'ä' and correct 'Ü'
Hej Andreas, the mail that is display 'wrong' in KMail message list is actually broken. The raw message is not allowed to contain 8-Bit values, they must be RFC2047 encoded like the second mail that is displayed correctly. So the real problem is the application that created the broken message. Ciao, Tobias If the header contains 8 bit values, KMail should use the fallback/override codec which is specified in the configuration. Looks like that happens in the messageviewer, but not in the messagelist. Hej Thomas, how shall the messageviewer/messagelist find out whether the header is stored in 8Bit? Ciao, Tobias Test mail at http://www.kdab.com/~thomas/stuff/8bitsubject.mbox Ok, the problem is that the mail is incorrectly stored in the Akonadi database. If you have a look at parttable, you'll see the ENVELOPE is stored as: > ("Thu, 23 Jul 2009 04:55:33 -0600" "****SPAM(20.2)**** =?UTF- > 8?B?UmU6UG9wdWzvv71yZW4gUHJvZ3JhbW1lIGbvv71y?= PC und MAC" (("Erfahrung der > Spezialisten" NIL "AnthonyLatham" "morelos.com")) NIL NIL ((NIL NIL "sa_fi" > "gmx.net")) NIL NIL NIL "<WH4076vcvmawr@omniscient.info>" NIL) Whereas the HEAD and RFC822 payloads are stored as: > [..] > Subject: ****SPAM(20.2)**** Re:Populären Programme für PC und MAC > [..] This is because SerializerPluginMail::serialize() actually parses the subject in the ENVELOPE case, but not in the HEAD and RFC822 cases. Parsing here is wrong, since it can't possible use the correct fallback charset. Not quite sure what to do here, we need some way to get the raw header field out of the mail, without any parsing. The mail is usually parsed before even passing it on to ItemCreateJob. We still have the raw head of the mail though, which we could use for parsing out the raw header field. Normally, headers are parsed in KMime::Types::parseHeaders(), but that interprets the header field already, while we need the raw value. We'd need something similar to that, which gives us a list of raw header fields, and use that in SerializerPluginMail::serialize() This is fixed with KMail 2.1.0 (kdepim 4.6.0) for me. Thanks. |