Bug 57093

Summary: Add charset selection box to Attach File dialog
Product: [Unmaintained] kmail Reporter: Christian Wolfgang Hujer <Christian.Hujer>
Component: mimeAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: wishlist CC: avbidder+kde, thomas.moschny, tuju
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Christian Wolfgang Hujer 2003-04-10 18:28:25 UTC 
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
Comment 1 Ingo Klöcker 2003-04-11 10:59:47 UTC 
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.
Comment 2 Ingo Klöcker 2003-12-22 22:09:18 UTC 
*** Bug 71031 has been marked as a duplicate of this bug. ***
Comment 3 Adrian von Bidder 2004-05-11 08:38:05 UTC 
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?)
Comment 4 Michel Nolard 2004-08-12 19:58:19 UTC 
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
Comment 5 Thomas Moschny 2006-11-08 14:34:56 UTC 
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).
Comment 6 Frank Niethardt 2007-05-20 23:37:59 UTC 
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?
Comment 7 Thomas Moschny 2008-10-24 18:39:39 UTC 
This problem will slowly vanish if everyone uses utf-8 only ... ;)
Comment 8 Thomas McGuire 2008-11-23 20:24:00 UTC 
Closing, the charset is now auto-detected when a file of mimetpye text/* is attached.