+n- Flaw in IE

J

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 :[
 
Z

Zif

Java said:
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 ~
Click to expand...

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
Click to expand...

'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
Click to expand...

Makes no difference since nothing happens anyway.
 
L

Lee

Java script Dude said:
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()
Click to expand...

That's going to set focus to the parent window, not the new one.
</script>
</body>
</html>
~ file 1 end ~

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

I added "alert(v)" here.

</script>
</body>
</html>
~ file 2 end ~

Notes:
- Any instance of +n - (where n=integer) will cause JavaScript string
concatenations to blow up
Click to expand...

I don't see any problem in IE6 under XP with sp2.
 
J

Java script Dude

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

Any other takers?
 
V

VK

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

Any other takers?
Click to expand...

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? :)
 
I

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.
 
J

Jim Ley

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 ;]
Click to expand...

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.
 
V

VK

Jim said:
The issue is likely a UTF-7 encoding issue
Click to expand...

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..._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)
:)
 
V

VK

VK said:
This must be about the "Korean issue" in IE
Click to expand...
That is not really Microsoft problem - Unicode had to think better
while planning UTF-7 standard.
Click to expand...

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.
 
V

VK

Robert said:
Do you have any source for this claim?
Click to expand...

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

What are your sources for an opposite claim?
 
J

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
 
J

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.
 
J

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
 
J

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.
 
T

Thomas 'PointedEars' Lahn

Java said:
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. [...]
Click to expand...

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>
Moral of the story - Use UTF-8 encoding and hard encode static content
and explicitly specify content encoding in http headers.
Click to expand...

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
 
V

VK

Java said:
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.
Click to expand...

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.
 
R

Robert

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

What are your sources for an opposite claim?
Click to expand...

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.
 
V

VK

Robert said:
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.
Click to expand...

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.
Click to expand...

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

In javascript, XML File Create, File Save 2
Can someone tell me if this a real tracker? Or is it one designed to show you a different message at certain times, ie. acting like one? 0
What is the error in this code , file not fetch and not fetched in the basemap, not vissible in the browser 1
Uncaught ReferenceError: item is not defined at HTMLButtonElement.onclick in the: <button onclick="item.inserir()">Inserir dados</button> 1
I want to Display Excel As HTML In js 2
Check forms With JavaScript 1
How to have two html audio players on one page? 0
Multi select options in a menu 1

Members online

No members online now.
Total: 41 (members: 1, guests: 40)
Robots: 85

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,282
Latest member
RoseannaBa

Latest Threads

Top