Zitat von Tim Bannister <[EMAIL PROTECTED]>: > On Fri, Dec 07, 2007 at 12:00:04PM +0000, [EMAIL PROTECTED] 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/ -- IMP mailing list - Join the hunt: http://horde.org/bounties/#imp Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: [EMAIL PROTECTED]
