> In 38b4 you introduce a bug encoding utf-8 byte order mark using > AddPartHTML method:
BOM is not added in 38b4, it exists in a few releases before. > Content-type: text/html; charset=UTF-8 > Content-Transfer-Encoding: Quoted-printable > Content-Disposition: inline > Content-Description: HTML text > > =EF=BB=BF<html><body>hello world</body></html> > > Is not necessary - charset already define utf-8 encoding. > After decoding, this may cause crash, freeze or may return empty > string on some email clients. Any unicode document can have BOM in any place! And presence of BOM cannot break any correctly written unicode reader. >From other side, presence of "=EF=BB=BF" BOM can help with identify of UTF-8 encoding by unicode reader, even you not have information from MIME header. (like when you save part content to file...) > Far as I remember, not of related RFCs define using Byte Order Mark in > composing mime message - it is usually widely used in XML documents. > Please quote related RFC source otherwise. You must ask by reverse question: is here RFC what says: "you cannot use BOM in MIME part content"? BTW: BOM for UTF-8 has been added long time ago for stupid Outlook, what ignoring charset information in part headers in some cases and detecting UTF-8 by BOM presence. Have you some unicode mailer, what have problem with BOM? :-O -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
