im sorry to interfere into this conversation but i must add something
im not going to argue whether outlook is buggy or not,
whether it follows the RFC or not, what matters to the simple user is 1 thing
that his email client will work and show him the correct content of an email
if a user tells me "but in outlook it shows it ok"
answering him that outlook is buggy and non standard will cause him to laugh at
me
for the above reason. and we can laugh on MS and outlook as much as we want,
but most people
use outlook (unfortunately) and still they compare every new thing to outlook.
i dont know how outlook does it and mayb he does it with wrong behaviour
but even with incorrect encoding of a subject for example, he knows how to show
it correctly
and the above is only 1 example.
again, im really not a fan of MS specially after the bug incident (of the
hebrew outlook) which they dont admit it is a bug (even though
the english version works differently), but still
i think we should understand the way it works
instead of saying unwillingly that it is bad, and to think with that we solved
the problem
i will take firefox for example which keeps saying the same about IE
and still as versions go up, more and more sites are shown ok in firefox (im
using FF for long time now)
so mayb there are some basic issues which should be compared to outlook
and see how it deals in such cases
just my 2 cents
______ 26/02/2007 18:18:30, Sasa Zeman - [EMAIL PROTECTED] ___:
On Monday 26 February 2007 09:22, Lukas Gebauer wrote:
> > 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.
Please reread quoted text. As wrote: 'In 38b4 you introduce a bug...'
> Any unicode document can have BOM in any place!
This is not correct. Essencial Byte Order Mark FAQ from www.unicode.org:
"Q: What is a BOM?
A: A byte order mark (BOM) consists of the character code U+FEFF at the
beginning of a data stream, where it can be used as a signature defining the
byte order and encoding form, primarily of unmarked plaintext files. Under
some higher level protocols, use of a BOM may be mandatory (or prohibited) in
the Unicode data stream defined in that protocol."
> And presence of BOM cannot break any correctly written unicode reader.
Unicode reader should be written correctly, unfortunately that is not always
the case. As such, it can be broken quite easely. With presence of BOM and
charset as well, decoding can be easy missguided. For example charset may be
be in Windows-1251, however raw encoding in utf-8 or 16 depending on BOM...
That mean, that charset in presence of BOM is not relevant at all. However,
charset exists and that is primary encoder/decoder guide.
> You must ask by reverse question: is here RFC what says: "you cannot
> use BOM in MIME part content"?
It is quite unlogical explicitly use BOM if charset cleraly say which unicode
encoder is used, as wrote upper.
> 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.
Outlook should not be a refference e-client at all. It is probably one of the
most buggy e-clients.
Sasa
--
www.szutils.net
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
