[Users] Questions regarding character encoding of text/plain attachments

[Ricardo Mones]

On Tue, Oct 02, 2012 at 02:47:44PM +0200, Michael Gmelin wrote:
> 
> 
> On Tue, 2 Oct 2012 14:28:25 +0200
> Ricardo Mones <ricardo at mones.org> wrote:
> 
> > On Mon, Oct 01, 2012 at 12:25:23AM +0200, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > I noticed the following issue:
> > > 
> > > When sending a text file attachment, claws uses content-type text
> > > plain, even if it is encoded in UTF-8 and ends up base64-encoded.
> > > 
> > > So the mime header of the attachment looks like this:
> > > 
> > > Content-Type: text/plain
> > > Content-Transfer-Encoding: base64
> > > Content-Disposition: attachment; filename=china.txt
> > > 
> > > In some cases it would be preferable to have a header like this:
> > > 
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: base64
> > > Content-Disposition: attachment; filename=china.txt
> > 
> >   Maybe it should be set to UTF-8 always for text/plain in the cases
> > where the current code does not add a charset. ASCII only attachments
> > would work anyway as that's a subset of UTF-8.
> >  
> 
> I just realized that this is more like a follow/duplicate of my earlier
> request, sorry for that. 

  No problem.

> > > Questions:
> > > 1. Is there a reasonable way to auto-detect and set the encoding?
> > 
> >   http://code.google.com/p/uchardet/
> > 
> > > 2. If not, is there a way to make this happen on user request (like,
> > >    selecting the encoding)?
> > 
> >   Not currently, but a patch is welcome :)
> 
> As I learned by checking the Properties dialog (which I never did
> before on an attachment, thanks for that), you can actually just add
> the encoding after the mime-type, like "text/plain; charset=UTF-8". Not
> nice, but it actually works.

  Yeah, a nice discovery for me too :)

> I would be willing to contribute a patch though, that allows:
> - Selecting the encoding of an attachment
> - Specifying a default based on various conditions
> 
> Not sure about a time line thought :)

  Well, there's no rush, I'd start for the first part. There's a complete
submenu for selecting the view encoding, maybe it can be reused to select
the attachment encoding in the attachment properties. If not, a simple
select can work.

> > > 3. If not, what is the rationale for not doing this. I could imagine
> > >    something like "the receiving system should assume UTF-8 in the
> > >    absence of a character encoding specification" or "the receiving
> > >    system should handle encodings transparently". In this case it
> > > would be good to get some reference supporting one or both of these
> > >    arguments (RFC anyone?)
> > 
> >   My response to your other mail has several RFC references, and UTF-8
> > is not the default assumption for text/plain without charset. Anyway,
> > since automatic charset detection is equally flawed on any side, I
> > don't think such transparent handling is possible.
> 
> My argument would be: If it's ascii, don't try to change it - this way
> UTF-8 can pass through transparently. But that can be hard on legacy
> systems. That's definitely not Claws responsibility though.

  Don't understand this. Passing through is already done thanks the
Content-Transfer-Encoding, regardless the charset of the content.

> > At most all the
> > MUAs can do would be a) suggest some encoding for sending, and b)
> > allow changing it, and c) suggest some encoding for reading, and d)
> > allow changing it.
> > 
> >   Claws Mail currently lacks b), and a) probably can be improved.
> >   AFAIK c) and d) are fully covered.
> 
> AFAIK b) is also there as well, but could be improved.

  Yep, agreed.
-- 
  Ricardo Mones 
  ~
  Absence of evidence is not evidence of absence.          Carl Sagan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20121002/7da70bb0/attachment.sig>