> In 38b4 you introduce a bug encoding utf-8 byte order mark using > AddPartHTML method:
1. This is not any bug 2. it is not introduced by 38b4 How many times I must say this? > 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. This is correct right UTF-8 headers and content. Even you think "it is not necessary", it can be present in this case, it not breaking any standard, RFC and unicode too! Say about this "bug" are very strong words, and I disagree with you. Charset is defined by headers until you extract document from MIME only. > After decoding, this may cause crash, freeze or may return empty string on > some email clients. I am asking you second time: what unicode capable mailer crashing, freezing or returning empty string on this mail? > 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. RFC-3629 allows include BOM with UTF-8 in case of MIME in this situations. What RFC dissallows it? Without contructive reply to this major question is next debate irrelevant. -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library ------------------------------------------------------------------------- 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
