+n- Flaw in IE

Java script Dude

Give this a test in IE (verified in IE 6.0 sp2)

Has anybody else seen this and is there a workaround besides escaping
with html special chars and not using IE ;]

~ file 1 ~
<html>
<head>
<title>IE +n- Flaw Tester</title>
</head>
<body>
<script>
window.open("./_pitest.html")
window.focus()
</script>
</body>
</html>
~ file 1 end ~

~ file 2 ~
<html>
<head>
<title>Wacky IE Flaw :]</title>
</head>
<body>
+1-
<script>
var v="a"+"A"
</script>
</body>
</html>
~ file 2 end ~

Notes:
- Any instance of +n - (where n=integer) will cause JavaScript string
concatenations to blow up
- Loading in new window helps error to come out but is not always
necessary
- Now you say, but who will put in `+n-`?
- .[a] Think phone numbers in Europe :[

Jan 12 '06 #1

Subscribe Post Reply

1710

Zif

Java script Dude wrote:

Give this a test in IE (verified in IE 6.0 sp2)

Has anybody else seen this and is there a workaround besides escaping
with html special chars and not using IE ;]

~ file 1 ~
<html>
<head>
<title>IE +n- Flaw Tester</title>
</head>
<body>
<script>
window.open("./_pitest.html")
window.focus()
</script>
</body>
</html>
~ file 1 end ~

~ file 2 ~
<html>
<head>
<title>Wacky IE Flaw :]</title>
</head>
<body>
+1-
<script>
var v="a"+"A"
</script>
</body>
</html>
~ file 2 end ~
This 'test' does absolutely nothing - alerting the value of 'v' shows
'aA' as expected.

Notes:
- Any instance of +n - (where n=integer) will cause JavaScript string
concatenations to blow up
'blow up'? Too many Hollywood movies perhaps, where even a flat tyre
causes a car to explode... provided it's being driven by a baddie.

- Loading in new window helps error to come out but is not always
necessary

Makes no difference since nothing happens anyway.

--
Zif

Jan 12 '06 #2

Java script Dude

I have tested only two machines and both fail. Both are Corporate
images. Possibly a image issue...

Any other takers?

Jan 13 '06 #3

Java script Dude wrote:

I have tested only two machines and both fail. Both are Corporate
images. Possibly a image issue...

Any other takers?

There is no problem on IE6.0 SP1

That would help greatly to have a hint what "doesn't work" on your
site: script doesn't execute, window doesn't open, IE displays Firefox
logo on load? :-)

Jan 13 '06 #4

impaler

The only string concatenation I see is var v="a"+"A" and there is
nothing wrong with it.
I don't know what you mean by "Any instance of +n - (where n=integer)
will cause JavaScript string concatenations to blow up"
This is how you tell javascript that a variable is an integer. +n or
n-0 or something.
Didn't see any problem when surrounding +n with quotes.

you mean like something this?
var a = "+123";
var b = "+134";
alert(a+b);

it works fine.

Jan 13 '06 #5

Jim Ley

On 12 Jan 2006 15:19:39 -0800, "Java script Dude"
<de********@yahoo.ca> wrote:

Give this a test in IE (verified in IE 6.0 sp2)

Has anybody else seen this and is there a workaround besides escaping
with html special chars and not using IE ;]

The issue is likely a UTF-7 encoding issue, and your IE is recognising
it as a UTF-7 encoded file, ensure your content is correctly
identified its encoding information.

Jim.

Jan 13 '06 #6

Jim Ley wrote:

The issue is likely a UTF-7 encoding issue

Now I'm all curious, as there is not any ussue in the posted sample.

But I guess I understand now what OP had in mind (though failed to
say):

This must be about the "Korean issue" in IE
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d444d7077da80dd7/6b7880c6efe5397a>

That is not really Microsoft problem - Unicode had to think better
while planning UTF-7 standard.

That has no practical danger though, because in order to reproduce this
"encoding shift" one has to violate severely HTTP standards: the page
has to be served both without server-provided content encoding and
without http-equiv on the page.

So I would even consider it now not as a flaw but as a rather useful
penalization mechanics to bad web-developers (or server admins)
:-)

Jan 13 '06 #7

VK wrote:

This must be about the "Korean issue" in IE <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d444d7077da80dd7/6b7880c6efe5397a>
That is not really Microsoft problem - Unicode had to think better
while planning UTF-7 standard.

UTF-8 is the current standard encoding for Unicode characters. I cannot
think of a reason (besides pure sport) to serve a page in explicit
UTF-7 encoding. But even then there is the often forgotten option to
indicate charset for the script block itself:

<html>
<head>
<title>'round Korean issue</title>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-7">
</head>

<body>
+10-
<script type="test/javascript" charset="iso-8859-1">
var foo = "a" + "A";
</script>
</body>
</html>

- But I have to serve the script in UTF-7 too !
- Don't be boring silly now.

Jan 14 '06 #8

Robert

VK wrote:

UTF-8 is the current standard encoding for Unicode characters.

Do you have any source for this claim?

Jan 14 '06 #9

Robert wrote:

VK wrote:
UTF-8 is the current standard encoding for Unicode characters.

Do you have any source for this claim?

World Wide Web (starting from google.com and further until you get
tired to browse).

What are your sources for an opposite claim?

Jan 14 '06 #10

Java script Dude

Yes, you are exactly correct. I had an Idea that it may be an encoding
issue, but this is the first time I have seen IE encoding fail when
using 'Auto-Select'.

If the html does not explicitly specify the encoding, it appears that
the `Auto Select` feature in IE will auto set to UTF-7 and the page
dies miserably.

When I manually set the encoding to Western European, the page worked
fine.

I'll just have to hack up our n-tier vendors web app to ensure the
encoding is explicit on our pages. I will do some tests.

Thanks!
JsD

Jan 15 '06 #11

Java script Dude

Have tried both:

<META http-equiv="Content-Type" content="text/html;
charset=western">
<META http-equiv="Content-Type" content="text/html;
charset=western/iso">

.... without success. When loading these from my computer, so there is
no header to explicitly set the encoding so Auto-Select will do it's
job properly.

I have seen some wackiness with Encoding in IE and this one just takes
the cake. This is a good example of where the web developers must be
careful with the configuration of the web application to prevent these
issues.

Looks like I might as well just go down that utf-8 encoding path and be
done with it.

I hope that MS pulles up their socks and fixes this highly flawed
functionality in the upcoming IE 7.

Jan 15 '06 #12

Java script Dude

I agree, if the server is serving the file up with the encoding in the
http header properly, this will not be a problem. But as I have tested
and confirmed, IE ignores the http-equiv meta tag and when in pure
'Auto-Detect' mode and tries to figure itself which mode by reading
content. If the +n- is high enough in the source, IE will fail out by:
1) not properly rendering the content and
2) Causing JavaScript to fail miserably because a Western/iso encoded
file is interpreted as utf-7 causing `+` chars to be interpreted
differntly, hense concatenation issues I saw in javascript.

If all pages are served up by a web server, then this is not a flaw but
the problem is that there are times that an html file is served up
statically from a clients hard drive or network drive. In these cases,
IE will fail. Therefore this *is* a flaw in IE and it should be fixed.

IE must not ignore the http-equiv meta tags. But unfortunately it does.
Moral of the story - Use UTF-8 encoding and hard encode static content
and explicitly specify content encoding in http headers.

JsD

Jan 15 '06 #13

Java script Dude

The way to duplicate is as follows:

1) Save the following file to your hard drive in ASCII:
<html>
<META http-equiv="Content-Type" content="text/html;
charset=western/iso">
<head>
<title>Wacky IE Flaw :]</title>
</head>
<body>
+1-
<script>
var v="a"+"A"
</script>
</body>
</html>
2) Load the Web Page
3) Un-Check Auto-Select
4) Select Western European (windows)
5) Check Auto-Select
.. . IE will now auto-detect as utf-7, reload the page and fail very
miserably
.. . The page will now fail every time you load until you click on
Western European (windows) or Western European (ISO)
.. . IE will completely ignore
Notes:
- The above sounds convoluded but I two different developers machines
fail exactly the same way because of this without us hacking around
with encoding at all. Although a co-incedence, it will and I am sure
does happen.
- If file is saved in Unicode or utf-8, it will be auto detected
because of data in the file header.
- This problem only happens when file is saved as ASCII which is
unfortunately a very common format.

Jan 15 '06 #14

Thomas 'PointedEars' Lahn

Java script Dude wrote:

I agree, if the server is serving the file up with the encoding in the
http header properly, this will not be a problem. But as I have tested
and confirmed, IE ignores the http-equiv meta tag and when in pure
'Auto-Detect' mode and tries to figure itself which mode by reading
content. [...]
IE must not ignore the http-equiv meta tags. [...]
True, in _this_ case.[1]

HTTP/1.1 (RFC2616[2]) section 3.4.1 specifies that it MUST ignore them
if the server already sent a Content-Type header with a `charset' label.

[1]
<URL:http://www.w3.org/TR/1999/REC-html401-19991224/charset.html#h-5.2.2>
[2] <URL:http://www.rfc-editor.org/rfc/rfc2616.txt>
Moral of the story - Use UTF-8 encoding and hard encode static content
and explicitly specify content encoding in http headers.

No, moral of the story is to serve all text resources with
Content-Type header and `charset' label always, and remove
unconditional AddDefaultCharset directives from httpd.conf.
PointedEars

Jan 15 '06 #15

Java script Dude wrote:

Have tried both:

<META http-equiv="Content-Type" content="text/html;
charset=western">
<META http-equiv="Content-Type" content="text/html;
charset=western/iso">

... without success.

Well, you may get more success by stop inventing your own encodings and
by using existing ones (I did):

Western Latin:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">

Central European:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-2">

UTF-8
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Korean for this matter:
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">

Otherwise this so-called "flaw" is just a proof that if you feed the
browser with wrong parameters (or do not feed *required* ones) then
it's rendering behavior may be randomized. This may be an interesting
game, but one can play it with any existing browser, so why to pick up
on IE exclusively? ;-)

Also kill me if I understand why this particular behavior should be a
*flaw*. The mode called *Auto-Detect*, not *Use System Default*. So
instead of simply using system default or iso-8859-1 like wannabes do,
IE indeed tries to *auto* *detect* the encoding of the crap you fed
into it. If not a single hint provided from server or http-equiv (or
http-equiv provides a non-existing encoding) then IE studies the body
text for hints.
+n- is a valid UTF-7 character so what is your claim? Should IE connect
to ICANN to check if this domain appertains to an Asia domain? Or
submit the text to an online translator to see if UTF-7 variant can be
translated into any existing language (if not then use what?)

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

One should never depend on server headers and have used encoding
indicated on the page itself. HTTP, XML and even sorry a** XHTML have
all means for it.

Jan 16 '06 #16

Thomas 'PointedEars' Lahn

Java script Dude wrote:

Have tried both:

<META http-equiv="Content-Type" content="text/html;
charset=western">
<META http-equiv="Content-Type" content="text/html;
charset=western/iso">

... without success. [...]

<URL:http://www.iana.org/assignments/character-sets>

You will find no such names or aliases there.
PointedEars

Jan 16 '06 #17

Robert

VK wrote:

Robert wrote:
VK wrote:
UTF-8 is the current standard encoding for Unicode characters.

Do you have any source for this claim?

World Wide Web (starting from google.com and further until you get
tired to browse).

What are your sources for an opposite claim?

I have asked you a serious question, and this is not the reply I was
hoping for.
How can I possibly give a source for the non-existance of such a
standard?? You make the claim, so the burden of proof is on you.

Although not a good source, but when windows programs are specifying
Unicode as an output format, they usually mean the UTF-16 (Little
Endian) encoding.

Anyway I am not aware of a a claim that UTF-8 is the standard encoding
for Unicode characters.
So please show me a source, or admit that you have made a mistake.

Robert.

Jan 16 '06 #18

Robert wrote:

I have asked you a serious question, and this is not the reply I was
hoping for.
How can I possibly give a source for the non-existance of such a
standard?? You make the claim, so the burden of proof is on you.
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.

I can give you a bunch of statements like this, and please don't ask
from me a document signed by UN Council to prove it. If you don't
believe me, then don't. Sorry if I'm sounding irritated by I just hate
then you say some common knowledge fact and right away they are asking
from you the Big Final Letter Of Prove for it (besides it is unclear
who's supposed to be the issuer of such Letter: W3C, UN Council,
Congress, Lord Himself ?)

Although not a good source, but when windows programs are specifying
Unicode as an output format, they usually mean the UTF-16 (Little
Endian) encoding.

We are talking about *World Wide Web* and browsers and JavaScript. In
your own applications you can use UTF-21 (after you make it up first)
if you want to, but for WWW please be so kind to serve UTF-8 or use
your national encoding.

Jan 16 '06 #19

Thomas 'PointedEars' Lahn

VK wrote:

Robert wrote:
I have asked you a serious question, and this is not the reply I was
hoping for.
How can I possibly give a source for the non-existance of such a
standard?? You make the claim, so the burden of proof is on you.
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

Jan 16 '06 #20

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.

Jan 16 '06 #21

John W. Kennedy

Java script Dude wrote:

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"

Jan 16 '06 #22

Robert

VK wrote:

Robert wrote:
I have asked you a serious question, and this is not the reply I was
hoping for.
How can I possibly give a source for the non-existance of such a
standard?? You make the claim, so the burden of proof is on you.

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?

Jan 16 '06 #23

Java script Dude wrote:

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.

Jan 16 '06 #24

Similar topics