+n- Flaw in IE

[Thomas 'PointedEars' Lahn]

OK, here a couple of more claims:
1) Internet Explorer is up to date

Despite numerous patches for it released over the years, Internet Explorer 6
is still 5 years(!) behind current Web development now, and we are yet to
see if there is ever a public release (meaning a release for pre-XP OS
versions as well) of a version 7 that fixes the numerous design flaws, both
regarding application and system security, and Web standards, in version 6.
It certainly fails badly to qualify as being application software that sets
Web standards, even if

is the most widely used browser.

Unfortunately, that appears to be still true. It is not only unfortunate
because it is from a monopolist in the operating systems market and is
Closed Source software, but also and particularly because it is such an
awfully bad example of software engineering.

2) CGI is the most widely used underlaying interchange format for HTTP

CGI is not an interchange format, it is an interface specification, the
Common Gateway Interface. The enclosing data interchange format used, if
you want to call it that, is HTTP itself.

[...]
I can give you a bunch of statements like this,

I am sure you can. However: By repeating false statements (over and over
again) they do not become more true. [psf 4.18]


PointedEars

 

[Java script Dude]

Namely, what is your proposed algorithm for such case? "No matter what
it is not UTF-7"? And why not?

I would propose that IE read the http-equiv meta tag in the body before
trying to figure out by itself what the encoding is by parsing the page
contents.

As I mentioned before, there are cases where there will be no
http-header such as when the file is served up from the local file
system. In these cases, there is the just the file header so the only
way to avoid this flaw in IE in these cases is to ensure that the files
are hard encoded in an encoding other that ASCII.

BTW - I have tried <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"> as well and on an ASCII file, IE still tries to
auto-detect utf-7.

 

[John W. Kennedy]

I would propose that IE read the http-equiv meta tag in the body before
trying to figure out by itself what the encoding is by parsing the page
contents.

Did you think about that at all before writing it?


--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"

 

[Robert]

OK, here a couple of more claims:
1) Internet Explorer is up to date is the most widely used browser.
2) CGI is the most widely used underlaying interchange format for HTTP
3) All people are mortal.

Besides that 2 is obviously wrong I'm sure that I could find a source
that supports the claim that Internet Explorer is the most widely used
browser.

All I ask you to do is find *ANY* source that your claim "UTF-8 is the
current standard encoding for Unicode characters".
I don't understand why you get this defensive about it. If it is so
obviously true then it must be easy for you to supply some source.

Now you already changed this claim to only those having to do with WWW.
But still..... have you even considered that there are languages where
UTF-16 files are smaller than those encoded in UTF-8?
Have you seen the list of Unicode encodings in the firefox Unicode submenu?

 

[VK]

I would propose that IE read the http-equiv meta tag in the body before
trying to figure out by itself what the encoding is by parsing the page
contents.

So it does! But if http-equiv Content-Type points to a non-existing
encoding like "Western" instead of the proper "iso-8859-1" then it's
still left alone with the crap to analize at the best of its
capabilities. And no one (AFAIK) claimed yet IE as a text recognizion
software.

As I mentioned before, there are cases where there will be no
http-header such as when the file is served up from the local file
system. In these cases, there is the just the file header so the only
way to avoid this flaw in IE in these cases is to ensure that the files
are hard encoded in an encoding other that ASCII.

Do not mix a God's gift with an omlet as my father used to say
It is not your preoccupation where your HTML/XHTML/XML file may appear
(it may appear in N places). But it is *your* preoccupation to make
sure that any place interested in your file's Content-Type could get a
clear and prompt answer from within the file. Content-Type and XML
equivalent give you such mechanics so please use it.

BTW - I have tried <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"> as well and on an ASCII file, IE still tries to
auto-detect utf-7.

Re-install your IE.