[imp] Subject line encoding problem

[Jan Schneider]

Zitat von Tim Bannister <Tim.Bannister at manchester.ac.uk>:

> 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.

No idea how you come to that conclusion. The only official e-mail  
message mime type is still text/plain which doesn't know about entities.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/