Null character and JavaScript strings
VK
a String?"
As it has very little to do with Date and FAQ I moved it into the new
thread.
Thomas Lahn is totally correct that in JavaScript the beginning and
the end of each string literal denoted by single or double quotes. \0
escape sequence (NUL char) is neither one so it cannot denote the end
of string. The logic is clear, straight and feasible
... yet naïve as a claim that while debugging a JavaScript program one
is exempted from electricity breakouts because ECMA 262 3rd says
nothing about electricity breakouts :-)
NUL character (a.k.a. NUL terminator) does terminate strings. And
JavaScript core engine handles strings as NUL terminated character
array. And every NUL byte in a character array is automatically the
end of the string. This outcome was and is simply overlooked in specs,
so till now each UA producer either let it go nuts or patches it on
its own discretion.
For the practical outcome these are easy ways to creatively crash IE,
Safari (except iOS) and Opera. For the peaсeful programming these are
such subtle cases as
http://www.remotesynthesis.com/post.cfm/Handling-Null-Characters-in-a-String
To facilitate the promised PointedEars job I am giving the test and
its behavior for 99.9% of the current desktop UA market.
<!DOCTYPE html>
<html>
<head>
<title>Demo</title>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<script>
var obj = {'f\0oo' : 'b\0ar'};
for (var x in obj) {
window.alert(''.concat(
'property name = ', x,
'\n',
'string length = ', x.length,
'\n\n',
'obj["f\0oo"] = ', obj['f\0oo']
));
}
</script>
</head>
<body>
<p>Demo</p>
</body>
</html>
Outcome:
[ Windows Vista SP2 ]
Firefox 3.6.13
property name: foo
string length: 4
obj["foo"] = bar
IE 8.0.6001
property name: f
(the rest of alert string is "swallowed" by NUL char, separate alerts
needed)
Safari 5.0.3
property name: f
(the rest of alert string is "swallowed" by NUL char, separate alerts
needed)
Google Chrome 10.0.648.127 beta
property name: f oo
string length: 4
obj["f oo"] = b ar
(NUL interpreted as BLANK SPACE ?)
Opera 11.01
property name: f
(the rest of alert string is "swallowed" by NUL char, separate alerts
needed)
Note: iOS Safari (iPhone, iPad)
property name: foo
string length: 4
obj["foo"] = bar
(so just like Firefox)
Thomas 'PointedEars' Lahn
> Thomas Lahn is totally correct that in JavaScript the beginning and
> the end of each string literal denoted by single or double quotes. \0
> escape sequence (NUL char) is neither one so it cannot denote the end
> of string. The logic is clear, straight and feasible
> ... yet naïve as a claim that while debugging a JavaScript program one
> is exempted from electricity breakouts because ECMA 262 3rd says
> nothing about electricity breakouts :-)
>
> NUL character (a.k.a. NUL terminator) does terminate strings.
That does not follow from your observations.
> And JavaScript core engine handles strings as NUL terminated character
> array.
How can you possibly know?
> And every NUL byte in a character array is automatically the
> end of the string.
Yes, but for this to be relevant here the premise must be true first.
> This outcome was and is simply overlooked in specs, so till now each UA
> producer either let it go nuts or patches it on its own discretion.
Your logic is flawed.
> For the practical outcome these are easy ways to creatively crash IE,
> Safari (except iOS) and Opera. For the peaсeful programming these are
> such subtle cases as
> http://www.remotesynthesis.com/post.cfm/Handling-Null-Characters-in-a
> String
>
> To facilitate the promised PointedEars job I am giving the test and
> its behavior for 99.9% of the current desktop UA market.
Your figures are wrong. Anyhow, assuming they were right, then you would
have proven yourself wrong in at least 33% of cases (2 out of 6) below.
> <!DOCTYPE html>
It would be best to start with an HTML 4.01 document. HTML5 is currently
experimental, and as HTML5 concerns both layout and script engine, through
the DOM, it would be best not to include that variable in the equation.
> <html>
> <head>
> <title>Demo</title>
> <meta http-equiv="Content-Type"
> content="text/html; charset=utf-8">
>
> <script>
See above.
> var obj = {'f\0oo' : 'b\0ar'};
>
> for (var x in obj) {
> window.alert(''.concat(
Why are you including String.prototype.concat() as yet another variable
in the equation? You should have used the concatenation operator, `+',
instead.
> 'property name = ', x,
> '\n',
> 'string length = ', x.length,
> '\n\n',
> 'obj["f\0oo"] = ', obj['f\0oo']
> ));
> }
But if you absolutely must call a method, you should have called
Array.prototype.join() to avoid having concatenate "\n".
> </script>
>
> </head>
> <body>
>
> <p>Demo</p>
>
> </body>
> </html>
>
>
> Outcome:
>
> [ Windows Vista SP2 ]
>
> Firefox 3.6.13
> property name: foo
> string length: 4
> obj["foo"] = bar
This disproves what you have stated above.
> IE 8.0.6001
> property name: f
> (the rest of alert string is "swallowed" by NUL char, separate alerts
> needed)
One wonders why you have not simply done so to make sure that it is not
U+0000 that merely causes problems with outputting the next characters.
Are you trying to conceal your misconception here?
> Safari 5.0.3
> property name: f
> (the rest of alert string is "swallowed" by NUL char, separate alerts
> needed)
See above.
> Google Chrome 10.0.648.127 beta
> property name: f oo
> string length: 4
> obj["f oo"] = b ar
> (NUL interpreted as BLANK SPACE ?)
You have still not understood that U+0000 is a Unicode character without a
glyph.
> Opera 11.01
> property name: f
> (the rest of alert string is "swallowed" by NUL char, separate alerts
> needed)
See above.
> Note: iOS Safari (iPhone, iPad)
> property name: foo
> string length: 4
> obj["foo"] = bar
> (so just like Firefox)
This also disproves what you have stated, if we assume in your favor that
there was a universal "JavaScript" language implemented everywhere. (There
is not: Firefox supports Mozilla.org JavaScript; Safari Mobile — which is
the correct name for the browser — supports Apple JavaScriptCore.)
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
VK
wrote:
> U+0000 that merely causes problems with outputting the next characters
Are you proposing a new PREVENT_DISPLAY Unicode char? It could be
possible (?) for a free code position, but we are dealing with U+0000
and its NUL character a.k.a. NUL terminator. Here is an updated case
with "sweet heart" text/javascript :-)
Use IE or Opera to watch this interesting case of "programmed
schizophrenia": the left hemisphere with quotes and the right
hemisphere with NUL both know exactly what a "string" is so making the
whole body moving convulsively :-)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>NUL in Javascript strings</title>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<script type="text/javascript">
var obj = {'f\0oo' : 'b\0ar'};
for (var x in obj) {
window.alert(x);
window.alert(x.length);
window.alert(x.charCodeAt(1));
window.alert(obj[x] + '|');
}
</script>
</head>
<body>
<p>NUL in Javascript strings</p>
</body>
</html>
Lasse Reichstein Nielsen
> Thomas Lahn is totally correct that in JavaScript the beginning and
> the end of each string literal denoted by single or double quotes. \0
> escape sequence (NUL char) is neither one so it cannot denote the end
> of string. The logic is clear, straight and feasible
> ... yet naïve as a claim that while debugging a JavaScript program one
> is exempted from electricity breakouts because ECMA 262 3rd says
> nothing about electricity breakouts :-)
>
> NUL character (a.k.a. NUL terminator) does terminate strings.
Sometimes it does, sometimes it doesn't. In C it does. In C++,
it might not (std::String isn't NUL-terminated). In ECMAScript
it doesn't.
> And JavaScript core engine handles strings as NUL terminated character
> array.
No. Since you say JavaScript, I'm guessing you're thinking of either
SpiderMonkey, JaegerMonkey or Rhino, which are JavaScript
implementations.
Neither of these use NUL-termination internally.
I doubt you can find any spec-compliant ECMAScript implementation that
does.
> And every NUL byte in a character array is automatically the
> end of the string.
In a C string, yes.
> This outcome was and is simply overlooked in specs,
> so till now each UA producer either let it go nuts or patches it on
> its own discretion.
The spec is quite clear. NUL charcaters have no special meaning in
any ECMAScript string operation.
> For the practical outcome these are easy ways to creatively crash IE,
> Safari (except iOS) and Opera. For the peaсeful programming these are
> such subtle cases as
> http://www.remotesynthesis.com/post.cfm/Handling-Null-Characters-in-a-String
It seems some browsers' host functions use NUL-termination internally.
That might be a silly choice, but it's got nothing to do with ECMAScript.
...
> var obj = {'f\0oo' : 'b\0ar'};
>
> for (var x in obj) {
> window.alert(''.concat(
...
If you check it, I think you'll find that the culprit is the alert
function. The concat function will create strings with embedded
NUL characters without any problem.
> Outcome:
>
> [ Windows Vista SP2 ]
>
> Firefox 3.6.13
> property name: foo
> string length: 4
> obj["foo"] = bar
Alert doesn't get confused by embedded NULs.
> IE 8.0.6001
> property name: f
> (the rest of alert string is "swallowed" by NUL char, separate alerts
> needed)
Alert does get confused by embedded NULs.
> Google Chrome 10.0.648.127 beta
> property name: f oo
> string length: 4
> obj["f oo"] = b ar
> (NUL interpreted as BLANK SPACE ?)
It's printed as a blank space. For a non-printable character, I guess
that's a valid choice. Sure beats ^@.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
VK
wrote:
> Alert does get confused by embedded NULs.
Sorry do disappoint you. To make things clearer I've made new demo -
see my answer to Thomas.
VK
Oh, "does get", affirmative. You mean other methods with string arg
don't?
Lasse Reichstein Nielsen
> On Mar 5, 4:28 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> U+0000 that merely causes problems with outputting the next characters
>
> Are you proposing a new PREVENT_DISPLAY Unicode char?
What makes you think so?
> It could be possible (?) for a free code position, but we are
> dealing with U+0000 and its NUL character a.k.a. NUL
> terminator.
It's not also known as NUL terminator. The code point is just the
NUL character.
> Here is an updated case with "sweet heart" text/javascript :-)
>
> Use IE or Opera to watch this interesting case of "programmed
> schizophrenia": the left hemisphere with quotes and the right
> hemisphere with NUL both know exactly what a "string" is so making the
> whole body moving convulsively :-)
SO you have figured out that the alert function calls into
non-Javascript code, and that code stops printing the string content
at the first NUL character?
And it has nothing to do with ECMAScript strings?
> var obj = {'f\0oo' : 'b\0ar'};
>
> for (var x in obj) {
> window.alert(x);
> window.alert(x.length);
> window.alert(x.charCodeAt(1));
> window.alert(obj[x] + '|');
> }
Yes, the alert truncates the output at the NUL character. The string
does not.
Lasse Reichstein Nielsen
I'm sure there are other *host* functions that does the same thing
(e.g., confirm), and probably some DOM functions too (a quick check
shows that
var d = document.createElement("div");
var s = "ab\0cd";
d.setAttribute("class", s);
alert([d.className == "ab", d.className == s, s.length]);
// alerts [true, false, 5] in Opera.
The language-specified string operations work on ECMAScript strings,
and they don't care about NUL-termination.
The external DOM functions (including DOM-0's alert) are not specified
in terms of ECMAScript strings, or (in HTML 5) doesn't say what to do
if the string argument contains non-printable characters.
I.e., the browser behaviors aren't in violation of any specification.
John G Harris
<snip>
>NUL character (a.k.a. NUL terminator) does terminate strings. And
>JavaScript core engine handles strings as NUL terminated character
>array. And every NUL byte in a character array is automatically the
>end of the string. This outcome was and is simply overlooked in specs,
>so till now each UA producer either let it go nuts or patches it on
>its own discretion.
<snip>
>Outcome:
>
>[ Windows Vista SP2 ]
>
>Firefox 3.6.13
> property name: foo
> string length: 4
> obj["foo"] = bar
>
>IE 8.0.6001
> property name: f
>(the rest of alert string is "swallowed" by NUL char, separate alerts
>needed)
<snip>
All you've proved for sure is that the Windows API for MessageBox uses
C-style strings, terminated by Nul, which we already knew. This is not
very interesting except when you are using alert for debugging or
testing.
Unless you inspect the numeric values of the characters in your strings
you cannot deduce anything about the browser's ECMAScript or DOM
behaviours.
The simplest explanation for the difference between Firefox and IE8 is
that Firefox edits text before sending it to a Windows display API and
IE does not. As there is no standard for alert this difference is not
surprising.
By the way, a simple way to test the Nul behaviour is to use the pseudo
URL :
javascript: var v = { 'fo\0o': 'hello' }; alert( v ['fo\0o' ] );
and appropriate variations on this.
John
--
John Harris
VK
> All you've proved for sure is that the Windows API for MessageBox uses
> C-style strings, terminated by Nul, which we already knew. This is not
> very interesting except when you are using alert for debugging or
> testing.
In such case not Windows API but IE, Safari and Opera for Windows
(equal behavior). Their window.alert are too different by LaF and
functionality so I would speculate that here are development teams
differences: some are using direct C calls (IE, Safari, Opera), come C+
+ tier (Firefox, Chrome).
<...>
VK
And at least Opera 11.02 shows lonely "f" on the page here, so it is
not about Windows API for MessageBox:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>NUL in Javascript strings</title>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<script type="text/javascript">
window.onload = function() {
var out = document.getElementById('out');
var obj = {'f\0oo' : 'b\0ar'};
for (var x in obj) {
out.innerHTML = x;
}
}
</script>
</head>
<body>
<p id="out">NUL in Javascript strings</p>
</body>
</html>
Sean Kinsey
...
> And at least Opera 11.02 shows lonely "f" on the page here, so it is
> not about Windows API for MessageBox:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <title>NUL in Javascript strings</title>
> <meta http-equiv="Content-Type"
> content="text/html; charset=utf-8">
> <script type="text/javascript">
>
> window.onload = function() {
> var out = document.getElementById('out');
> var obj = {'f\0oo' : 'b\0ar'};
> for (var x in obj) {
> out.innerHTML = x;
Again, you are calling into external code (not javascript) when setting the `innerHTML` property.
If you want to prove javascript does not handle your alleged NUL terminator, then you need to constrain your proof to only using javascript (eg no DOM and no BOM). Good luck with that though...
Sean
VK
> If you want to prove javascript does not handle your alleged NUL terminator,
> then you need to constrain your proof to only using javascript (eg no DOM and no BOM).
Javascript w/o any host methods is called ECMAScript - "not
computationally self-sufficient" core of the language (ECMA 262 3rd
ed, 4. Overview). As this not computationally self-sufficient core
layer doesn't have any own IO means, the task comes to measure smth w/
o measuring it. May sound challenging but I humbly skip on it :-)
As for the Web programming we are concerned about Javascript - if not
exclusively then at least primarely - it would be much more fruitful
to think about some logical and doable requirements for NUL-containing
strings passing between Javascript native methods and window/DOM host
object methods. Then choose the "right guy" and to file bugs to wrong
guys with explanations and suggestions. IMHO.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> U+0000 that merely causes problems with outputting the next characters
>
> Are you proposing a new PREVENT_DISPLAY Unicode char?
No. The original paragraph went:
>> One wonders why you have not simply done so to make sure that it is not
>> U+0000 that merely causes problems with outputting the next characters.
>> Are you trying to conceal your misconception here?
You really want to stop mutilating quotes. (In German-speaking Usenet
we call this inappropriate behavior "quotemardern", from the Steinmarder
[Beech/Stone Marten, Martes foina] that frequently mutilates our cars.)
> […] we are dealing with U+0000 and its NUL character
It is not. The name for the character U+0000 in the Unicode Character
Database is "NULL".
> a.k.a. NUL terminator.
There is no such thing. There is the NUL character, in US-ASCII and its
super-character sets.
> Use IE or Opera to watch this interesting case of "programmed
> schizophrenia": […]
You do not get it, do you? I am/we are not interested in your
fairy^Wtheories. I am/we are interested in your results, since I/some
cannot test on Windows (ATM). Presenting test code without presenting
results, and without saying where exactly the results can be reproduced,
goes a long way to have the statement ignored as yet another rubbish from
you.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Thomas 'PointedEars' Lahn
> VK wrote:
>> [ Windows Vista SP2 ]
>>
>> Firefox 3.6.13
>> property name: foo
>> string length: 4
>> obj["foo"] = bar
>>
>> IE 8.0.6001
>> property name: f
>> (the rest of alert string is "swallowed" by NUL char, separate alerts
>> needed)
> <snip>
>
> All you've proved for sure is that the Windows API for MessageBox uses
> C-style strings, terminated by Nul, which we already knew. This is not
> very interesting except when you are using alert for debugging or
> testing.
>
> Unless you inspect the numeric values of the characters in your strings
> you cannot deduce anything about the browser's ECMAScript or DOM
> behaviours.
>
> The simplest explanation for the difference between Firefox and IE8 is
> that Firefox edits text before sending it to a Windows display API and
> IE does not. As there is no standard for alert this difference is not
> surprising.
An even simpler explanation that is likely to be the correct one here is
that IE uses the Windows API for its chrome while Firefox uses Gecko
instead. Several other issues with IE/MSHTML that do not exist in
Firefox/Mozilla, like that in IE/MSHTML `select' elements always have the
highest z-index in their frame (and are CSS z-index ignorant) because they
are so-called "Windowed Controls", are caused by this difference.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> Lasse Reichstein Nielsen wrote:
>> Alert does get confused by embedded NULs.
>
> Sorry do disappoint you […]
I have suggested so several postings before, if you cared to notice.
Thomas 'PointedEars' Lahn
> Sean Kinsey wrote:
>> If you want to prove javascript does not handle your alleged NUL
>> terminator, then you need to constrain your proof to only using
>> javascript (eg no DOM and no BOM).
>
> Javascript w/o any host methods is called ECMAScript
No, there is no "Javascript". There is also no "javascript".
However, in order to reduce the number of host objects involved in the test
to a minimum, one can use a reference implementation. There is a
SpiderMonkey JavaScript shell that can be used for testing JavaScript in
particular. It is also not too far-fetched to retrieve the length of the
string and each single character according to the `length' property in a
browser.
> - "not computationally self-sufficient"
Your logic is flawed. The non-normative statement in section 4 is:
| ECMAScript as defined here is not intended to be computationally
| self-sufficient; indeed, there are no provisions in this specification
| for input of external data or output of computed results. Instead, it is
| expected that the computational environment of an ECMAScript program will
| provide not only the objects and other facilities described in this
| specification but also certain environment-specific host objects,
| whose description and behaviour are beyond the scope of this specification
| except to indicate that they may provide certain properties that can be
| accessed and certain functions that can be called from an ECMAScript
| program.
That is very far from saying that ECMAScript is "not computationally self-
sufficient".
> core of the language
In a sense.
> (ECMA 262 3rd ed, 4. Overview).
AISB: "This section contains a non-normative overview of the ECMAScript
language."
> [snip Non sequitur]
> ["implement \0", "file bugs against wrong guys" and other nonsense]
You really are a lost cause.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
VK
wrote:
> I/some cannot test on Windows (ATM).
Here a new test case w/o window.alert but with innerHTML and innerText/
textContent. Results are below the test. If you think of another test
case to run then I will do it. For tests I have default insts Windows
Vista SP2 and Windows XP SP3
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>NUL in Javascript strings</title>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<script type="text/javascript">
var text = (/*@cc_on true || @*/ false) ?
'innerText' : 'textContent';
window.onload = function() {
var out11 = document.getElementById('out11');
var out12 = document.getElementById('out12');
var out21 = document.getElementById('out21');
var out22 = document.getElementById('out22');
var obj = {'f\0oo' : 'b\0ar'};
for (var x in obj) {
out11.innerHTML = x;
out12.innerHTML = obj[x];
out21[text] = x;
out22[text] = obj[x];
}
}
</script>
</head>
<body>
<p><span id="out11"></span> = <span id="out12"></span></p>
<p><span id="out21"></span> = <span id="out22"></span></p>
</body>
</html>
Results:
[ Windows Vista SP2 ]
Firefox 3.6.13
[] for "no glyph char" on display
f[]oo = b[]ar
f[]oo = b[]ar
IE 8.0.6001
foo= bar
f= b
Safari 5.0.3
display:
foo = bar
foo = bar
copy-paste:
foo = bar
f
Anything prefixed by NUL is displayed, selectable but cannot be copied
(or can be copied but avoids pasting, God knows). Tried in different
way: a new bulletproof "copy-past protection" but for Safari only.
Google Chrome 10.0.648.127 beta
foo = bar
foo = bar
Opera 11.01
f = b
f = b
Richard Cornford
Is that last comment supposed to indicate that the task of sidestepping
output method issues would be difficult, or that you have realised that
if anybody is going to be incapable of achieving it that is going to be
VK?
Sidestepping the output method issues is trivial; if they have issues
with one or more non-printable characters then it is easy to substitute
those characters with something that those output methods are known to
handle correctly (a 'symbol' standing in for the character). So, for
example:-
<html>
<head>
<title></title>
</head>
<body>
<pre>
<script type="text/javascript">
var outputStringInfo = (function(){
var out1 = [], out2 = [];
out1.toString = out2.toString = function(){
return this.join(',\t');
};
var trans = {
'0':'[NUL]', //Null char
'1':'[SOH]', //Start of Heading
'2':'[STX]', //Start of Text
'3':'[ETX]', //End of Text
'4':'[EOT]', //End of Transmission
'5':'[ENQ]', //Enquiry
'6':'[ACK]', //Acknowledgment
'7':'[BEL]', //Bell
'8':'[BS]', //Back Space
'9':'[HT]', //Horizontal Tab
'10':'[LF]', //Line Feed
'11':'[VT]', //Vertical Tab
'12':'[FF]', //Form Feed
'13':'[CR]', //Carriage Return
'14':'[SO]', //Shift Out / X-On
'15':'[SI]', //Shift In / X-Off
'16':'[DLE]', //Data Line Escape
'17':'[DC1]', //Device Control 1 (oft. XON)
'18':'[DC2]', //Device Control 2
'19':'[DC3]', //Device Control 3 (oft. XOFF)
'20':'[DC4]', //Device Control 4
'21':'[NAK]', //Negative Acknowledgement
'22':'[SYN]', //Synchronous Idle
'23':'[ETB]', //End of Transmit Block
'24':'[CAN]', //Cancel
'25':'[EM]', //End of Medium
'26':'[SUB]', //Substitute
'27':'[ESC]', //Escape
'28':'[FS]', //File Separator
'29':'[GS]', //Group Separator
'30':'[RS]', //Record Separator
'31':'[US]' //Unit Separator
};
return (function(t){
var c, len, cc, ch;
out1.length = out2.length = 0;
document.write('String Length = \t'+t.length);
document.write('\n');
for(c = 0, len = t.length;c < len;++c){
cc = t.charCodeAt(c);
ch = (trans[cc] || String.fromCharCode(cc));
out1[out1.length] = cc;
out2[out2.length] = ch;
}
document.write('Character Codes = \t');
document.write(out1.join(',\t'));
document.write('\n');
document.write('Characters = \t');
document.write(out2.join(',\t'));
document.write('\n');
document.write('\n');
});
})();
var obj = {'f\0oo' : 'b\0ar'};
for (var x in obj) {
outputStringInfo(x);
outputStringInfo(obj[x]);
}
</script>
</pre>
</body>
</html>
Which, on IE 8, outputs:-
String Length = 4
Character Codes = 102, 0, 111, 111
Characters = f, [NUL], o, o
String Length = 4
Character Codes = 98, 0, 97, 114
Characters = b, [NUL], a, r
- showing that the javascript strings are themselves fine; the expected
lengths and containing the expected sequence of characters.
Like many misconceptions (and VK is all about misconceptions) there is a
tiny grain of truth behind this one. The misconception arises from
failing to fully understand the original issue, usually because of not
being capable of correctly analysing it. There once was an ECMAScript
bug in the C/C++ version of JavaScript(tm) where object property names
containing the null character where incorrectly resolves, such that
ith - obj = {'f\x00oo':'xxx') - would have the value 'xxx' resulting
from the property accessor - obj['f'] -. Whether this was an issue with
the storage of named properties of the process of resolving property
names was never announced, but it did not impact on string primitive
values at all, and it was reported and (almost certainly, quickly) fixed
some years ago. And VKs test code would not have highlighted this
particular issue even in the environments where the bug did exist.
Richard.
Leonardo Azpurua
mensaje news:KYGdnR7ENf2mn-7Q...@giganews.com...
> Sidestepping the output method issues is trivial; if they have
> issues with one or more non-printable characters then it is easy to
> substitute those characters with something that those output methods
> are known to handle correctly (a 'symbol' standing in for the
> character). So, for example:-
Sorry for the brutal snip.
I tested this:
...
<p><img id="laImagen" alt="" src="Bematech_Horizontal.gif"
onclick="testEmbeddedNull()"/></p>
...
function testEmbeddedNull() {
var aString = "a\0b\0c";
v = aString.split("\0");
aString = v.join(",");
document.write("<p>" + aString + "<p/>");
}
...
with IE8, FF3, Opera, Chrome and Safari, and all of them display
"a,b,c" when the image is clicked.
So, NUL is not used as a string terminator in the ECMA Script
implementation of any of these browsers.
--
Thomas 'PointedEars' Lahn
> "Richard Cornford":
>> Sidestepping the output method issues is trivial; if they have
>> issues with one or more non-printable characters then it is easy to
>> substitute those characters with something that those output methods
>> are known to handle correctly (a 'symbol' standing in for the
>> character). So, for example:-
>
> Sorry for the brutal snip.
>
> I tested this:
>
> ...
> <p><img id="laImagen" alt="" src="Bematech_Horizontal.gif"
> onclick="testEmbeddedNull()"/></p>
> ...
> function testEmbeddedNull() {
> var aString = "a\0b\0c";
> v = aString.split("\0");
> aString = v.join(",");
> document.write("<p>" + aString + "<p/>");
> }
> ...
>
> with IE8, FF3, Opera, Chrome and Safari, and all of them display
> "a,b,c" when the image is clicked.
Unfortunately, your test code proves nothing as you are effectively removing
the offending character before you display the string value (and your markup
is bogus at best). However, this does:
document.write("<p>a\0b\0c<\/p>");
See also <news:4267824.Z...@PointedEars.de>.
> So, NUL is not used as a string terminator in the ECMA Script
> implementation of any of these browsers.
I hate to break this to you, but everyone except VK knew this.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> I/some cannot test on Windows (ATM).
>
> Here a new test case w/o window.alert but with innerHTML and innerText/
> textContent. Results are below the test. If you think of another test
> case to run then I will do it.
No, although its methodology is unsurprisingly questionable, I think this
one suffices to prove you wrong. Thanks.
Leonardo Azpurua
"Thomas 'PointedEars' Lahn" <Point...@web.de> escribió en el
mensaje news:2967805.I...@PointedEars.de...
> Leonardo Azpurua wrote:
>> I tested this:
>>
>> ...
>> <p><img id="laImagen" alt="" src="Bematech_Horizontal.gif"
>> onclick="testEmbeddedNull()"/></p>
>> ...
>> function testEmbeddedNull() {
>> var aString = "a\0b\0c";
>> v = aString.split("\0");
>> aString = v.join(",");
>> document.write("<p>" + aString + "<p/>");
>> }
>> ...
>>
>> with IE8, FF3, Opera, Chrome and Safari, and all of them display
>> "a,b,c" when the image is clicked.
>
> Unfortunately, your test code proves nothing as you are effectively
> removing
> the offending character before you display the string value (and
> your markup
> is bogus at best). However, this does:
>
> document.write("<p>a\0b\0c<\/p>");
Hi,
As usual, doing your best effort to show how wrong the rest of us are.
The premise under discussion, as set by VK, was:
"NUL character (a.k.a. NUL terminator) does terminate strings. And
JavaScript core engine handles strings as NUL terminated character
array. And every NUL byte in a character array is automatically the
end of the string. This outcome was and is simply overlooked in specs,
so till now each UA producer either let it go nuts or patches it on
its own discretion."
If the NUL character does terminate strings, then
var aString = "a\0b\0c";
would be equivalent to:
var aString = "a";
in which case,
v = aString.split("\0");
aString = v.join(",");
would have had the same effect as
aString = "a";
and it didn't.
Since the actual value assigned to aString was "a,b,c" (yes, the NULs
had to be removed in order to test the actual contents of the string
independently of the browser's rendering), the original premise is
refuted for the mentioned implementations of ECMAScript.
The bogusness of my markup (taken from a general testing purpose file
that contains other things) doesn't have anything to do with the point
under discussion.
But I get your point: I am not you, so I must be wrong.
--
Thomas 'PointedEars' Lahn
> "Thomas 'PointedEars' Lahn" wrote:
>> Leonardo Azpurua wrote:
>>> I tested this:
>>>
>>> ...
>>> <p><img id="laImagen" alt="" src="Bematech_Horizontal.gif"
>>> onclick="testEmbeddedNull()"/></p>
>>> ...
>>> function testEmbeddedNull() {
>>> var aString = "a\0b\0c";
>>> v = aString.split("\0");
>>> aString = v.join(",");
>>> document.write("<p>" + aString + "<p/>");
>>> }
>>> ...
>>>
>>> with IE8, FF3, Opera, Chrome and Safari, and all of them display
>>> "a,b,c" when the image is clicked.
>>
>> Unfortunately, your test code proves nothing as you are effectively
>> removing the offending character before you display the string value
>> (and your markup is bogus at best). However, this does:
>>
>> document.write("<p>a\0b\0c<\/p>");
>
> […]
> If the NUL character does terminate strings, then
>
> var aString = "a\0b\0c";
> would be equivalent to:
>
> var aString = "a";
> in which case,
>
> v = aString.split("\0");
> aString = v.join(",");
>
> would have had the same effect as
>
> aString = "a";
>
> and it didn't.
ACK, I stand corrected.
(I leave your other comments to /dev/null. They are not worth further
consideration, and you should be ashamed.)
Leonardo Azpurua
>
> ACK, I stand corrected.
>
> (I leave your other comments to /dev/null. They are not worth
> further
> consideration, and you should be ashamed.)
I am not. Not even slightly.
But insisting on this would lead to a completely off-topic and
childish argument.
--
VK
> The premise under discussion, as set by VK, was:
>
> "NUL character (a.k.a. NUL terminator) does terminate strings. And
> JavaScript core engine handles strings as NUL terminated character
> array. And every NUL byte in a character array is automatically the
> end of the string. This outcome was and is simply overlooked in specs,
> so till now each UA producer either let it go nuts or patches it on
> its own discretion."
>
>
> var aString = "a\0b\0c";
> would be equivalent to:
>
> var aString = "a";
> in which case,
>
> v = aString.split("\0");
> aString = v.join(",");
>
> would have had the same effect as
>
> aString = "a";
>
> and it didn't.
>
> had to be removed in order to test the actual contents of the string
> independently of the browser's rendering), the original premise is
> refuted for the mentioned implementations of ECMAScript.
Tests shows that ECMAScript internally has no problems to handle NUL-
containing strings. My statement was about Javascript and a simple
testing shows that it does have huge problems on some wide-spread UAs
with such strings with [window] host object methods and DOM
interfaces.
A pleasurable resolution proposed here by Thomas and Mr.Cornford to
consider anything external to ECMA specs as not Javascript
(window.alert, document.getElementById). With such approach indeed
"Javascript" has no problem with NUL-containing string. It stores and
handles them just splendidly.
The little problem is that such "Javascript"===ECMAScript has no input-
ouput capabilities of any kind so cannot be practically used lesser
some conceptual solutions with Javascript engine running in a box of
another engine (say C or C++) with the latter directly grabbing/
plunging memory heaps of the first.
Norman Peelman
NUL terminated at the time of access/display, not creation.
--
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 8.04 64bit
Alter Ego
news:b36fbb1a-a0c3-4aa7...@q14g2000vbf.googlegroups.com...
<snip BS and nonsense>
People, for Christ's sake, stop this shit. What's the big issue if a fucking
string is NUL terminated or what? Are you nuts, guys? Hold your peace, have
some beer and stop bloating the Usenet with such crappy threads.
Alter Ego
> On Mar 6, 10:04 pm, "Leonardo Azpurua" <leona...@exmvps.org> wrote:
Andrew Poulos
In the words of a famous Australian musician, whose name escapes me,
"don't criticise what you don't understand".
Andrew Poulos
RobG
Completely OT, but what the heck...
> In the words of a famous Australian musician, whose name escapes me,
> "don't criticise what you don't understand".
You are thinking of the Bob Dylan song "Times they are a-chaingin'".
Bob is an American. 10 seconds on Google shows the quote is also
attributed to Elvis Presley.
As for the OP, I think it's pretty simply answered by:
alert('f\0oo'.length); // shows 4
VK's posts aren't worth the effort to decipher, though some of the
responses are good reading.
--
Rob
Leonardo Azpurua
"VK" <school...@yahoo.com> escribió en el mensaje
news:06025d4a-8ad0-4d1e...@y14g2000vbb.googlegroups.com...
>
> Tests shows that ECMAScript internally has no problems to handle
> NUL-
> containing strings. My statement was about Javascript and a simple
> testing shows that it does have huge problems on some wide-spread
> UAs
> with such strings with [window] host object methods and DOM
> interfaces.
I dont't think that the inability to properly render a subset of
characters which are often called "non-printable" really qualifies as
"huge problems".
In any case, it is a "standard" problem. If you need to present data
containing those characters, you need to perform some sort of
translation to a standardized representation, such as that proposed by
Mr. Cornford.
--
John G Harris
wrote:
<snip>
>What's the big issue if a fucking
>string is NUL terminated or what?
<snip>
Have you thought of the correct answer yet?
John
--
John Harris
Alter Ego
And does it matter anyway?
Andrew Poulos
> On Mar 7, 6:16 pm, Andrew Poulos<ap_p...@hotmail.com> wrote:
>
> Completely OT, but what the heck...
>
>> In the words of a famous Australian musician, whose name escapes me,
>> "don't criticise what you don't understand".
>
> You are thinking of the Bob Dylan song "Times they are a-chaingin'".
> Bob is an American. 10 seconds on Google shows the quote is also
> attributed to Elvis Presley.
I'm referring to a line in the song "Convict Streak" and not to anything
by Dylan.
Andrew Poulos
RobG
Released on the "Mugs Game" album by Dave Warner's "The Suburbs" in
1978.
Dave (born 1953) was about 11 years old when Dylan released "Times
they are a-chaingin'" (1964), so Dylan wins for now. :-)
--
Rob
Dr J R Stockton
t.com.au>, Mon, 7 Mar 2011 19:16:42, Andrew Poulos <ap_...@hotmail.com>
posted:
>In the words of a famous Australian musician, whose name escapes me,
>"don't criticise what you don't understand".
Well, if recent, it must have been either Dame Joan Sutherland or Sir
Charles Mackerras. One a singer, the other an arm-waver - easily told
apart.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Andrew Poulos
> In comp.lang.javascript message<ismdnRHPA9jnCenQnZ2dnUVZ_uKdnZ2d@westne
> t.com.au>, Mon, 7 Mar 2011 19:16:42, Andrew Poulos<ap_...@hotmail.com>
> posted:
>
>> In the words of a famous Australian musician, whose name escapes me,
>> "don't criticise what you don't understand".
>
> Well, if recent, it must have been either Dame Joan Sutherland or Sir
> Charles Mackerras. One a singer, the other an arm-waver - easily told
> apart.
You've never heard of Joe Dolce???
Andrew Poulos
Ross McKay
Or Bon Scott?
--
Ross McKay, Toronto, NSW Australia
"Look at the flock, they're all in shock, here comes that mutton fan"
- Weird Al Yankovic, "Dirty deeds, done with sheep"
Thomas 'PointedEars' Lahn
> On 9/03/2011 7:33 AM, Dr J R Stockton wrote:
>> Andrew Poulos posted:
>>> In the words of a famous Australian musician, whose name escapes me,
>>> "don't criticise what you don't understand".
>>
>> Well, if recent, it must have been either Dame Joan Sutherland or Sir
>> Charles Mackerras. One a singer, the other an arm-waver - easily told
>> apart.
>
> You've never heard of Joe Dolce???
Probably. He's got no title at all!!"
SCNR
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>