[imp] Subject line encoding problem

[Tim Bannister]

On Fri, Dec 07, 2007 at 12:00:04PM +0000, imp-request at lists.horde.org wrote:
> 
> > Also, why does Horde/Imp require the user to select the encoding in the
> > first place? Desktop clients usually select the most appropriate
> > encoding automatically. Kmail, for instance, usually uses either
> > US-ASCII or ISO-8859-1. But if i type some Japanese characters into an
> > e-mail, it automatically switches to ISO-2022-JP (the most common
> > encoding for Japanese e-mail). I'm sending this message from Kmail as
> > UTF-8.
> 
> PHP doesn't support automatic detecting of charsets, and it's even  
> much more complicated to detect it client-side, i.e. when typing the  
> message. We already do choose the most appropriate encoding though,  
> because we choose the encoding that matches the currently selected  
> interface language.

My desktop client, mutt, tries to find the best (ie smallest) encoding
for sending a part using iconv. US-ASCII normally wins if a message fits
in it.

Not all browsers send encoding information when POSTing form text in
multipart/form-data requests; I can't blame PHP for this, much less
Horde.
However, data outside IS0-8859-1 are usually sent as SGML entities.
That's enough to infer an encoding (UCS-2). If there aren't any entities
and no encoding was specified then it seems reasonable for Horde to
infer ISO-8859-1.

-- 
Tim Bannister
IT Services

e: Tim.Bannister at manchester.ac.uk
w: http://www.manchester.ac.uk/itservices