Version: (using KDE KDE 3.1.1) Installed from: SuSE RPMs OS: Linux My system is as follows: SuSE Linux 8.1 KDE 3.1.1 rpms from Linuks (SuSE Linux KDE Service) My System is configured to use UTF-8. The LANG variable is set to de_DE.UTF-8 as well as LC_ALL LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC and LC_TIME (all LC_* except for LC_COLLATE which is POSIX). In the AddressBook from KDE I exported a vCard file from a Person with a name containing characters with Unicode numbers beyond 255 containing the letters ą (a with ogonek, 0x0105) and ż (z with dot above, 0x017C). The vCard file was automatically encoded in UTF-8. I don't know wether that's okay according to the RFC about vCards but since it is possible to include a charset parameter in the Content-Type header that should be okay. Then I sent myself a mail from KDE. When I viewed the vCard, the characters were wrong. There were two errors: 1. The Content-Type kMail chose was text/x-vcard;charset="us-ascii". But it should be text/directory;charset="utf-8". (The text/directory is another issue reported in another bug). The problem is the wrong charset declaration. 2. The vCard contained non-ascii-characters but was labelled us-ascii, which is wrong independently of not honoring the system's encoding when creating the attachment. The complete attachment: Content-Type: text/x-vcard; charset="us-ascii"; name*=utf-8''XXXX_XX%C4%85%C5%BCXX%2Evcf Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*="utf-8''XXXX_XX%C4%85%C5%BCXX%2Evcf" Subject: BEGIN:VCARD VERSION:3.0 UID:ERQyouTNd =46N:Herr XXXX XX=C4=85=C5=BCXX EMAIL:XXXX.XXXXX@itcqis.com URL:http://www.itcqis.com/ N:XX=C4=85=C5=BCXX;XXXX;;Herr; ORG:ITCQIS GmbH ADR;TYPE=3Dwork:;;Johanneskirchnerstr. 132;M=C3=BCnchen;;D-81927;Deutschland TEL;TYPE=3Dwork:+49 (0)89 27 37 04 37 TEL;TYPE=3Dwork;TYPE=3Dfax:+49 (0)89 27 37 04 39 REV:2003-02-17T12:22:19Z CLASS:PRIVATE END:VCARD So kMail did the filename and name correct. But the charset of the Content is wrong. Bye
KMail uses the encoding that is selected for the message. So the workaround is to select utf-8 encoding before attaching the vCard. After attaching the vCard you can switch back to automatic encoding. The problem is that vCards don't have a charset entry. Instead the charset has to be provided in the attachment headers according to the RFC. But this makes it pretty much impossible to attach vCards which are stored in a file with the correct encoding because the vCard doesn't contain any information about the encoding. So it's impossible for KMail to know the charset which has been used to encode the vCard. AFAIK kaddressbook always uses utf-8 (which makes sense because then the difficult guessing of a suitable charset is unnecessary). But this means that using the default encoding of the OS won't work. AFAICS the only solution will be to add the charset selection box to the Attach File dialog. Then the user will have to select the correct charset manually. As you can see it's not really a bug in KMail. It's simply the result of the lack of a charset entry in the vCard. Therefore I changed subject and severity of this bug report.
*** Bug 71031 has been marked as a duplicate of this bug. ***
Verified as requested. It's still not done with 3.2.2. (Yes, I reported a duplicate of this. But why do I have to verify it if I'm not the reporter of this bug?)
Hi ! I have a similar problem receiving VCard written with another charset : the characters do not display correctly, it is simply unreadable. Here is an "example.mail" mail which contains such a VCard. Michel Nolard
The problem is not only with vcards, but with all text/... attachments. Re #1: If the mime spec (sensibly) requires adding a charset property to an attachment, and there is no reliable way to get the correct value for that property, it *is* a bug of kmail not to ask the user for it. Imho there are three possible solutions: (1) While adding an attachment, if kmail detects the mime-type to be something like text/..., pop up a dialog box, asking the user for the right charset. (2) Add a charset selector to the "open file" dialog (like kate does, for example). (3) Add a charset selector to the attachment property dialog. From (1) and (2), (1) does make more sense (but might be more difficult to implement), because there's no point in selecting a charset for binary attachments. Option (3) can (and probably should) be added independently of (1) or (2).
IMHO this rather should be a bug than a wish. When I add some text file all my umlauts are silently wrong encoded, so the recipient can hardly read the text. Is there a possibility to autodetect encoding of the textfile (among the values of options->composer->charsets) and set this header line correctly?
This problem will slowly vanish if everyone uses utf-8 only ... ;)
Closing, the charset is now auto-detected when a file of mimetpye text/* is attached.