String Handling Opportunities with split(), indexOf() and RegExp

[Atli]

The following small HowTo is a compilation of an original problem in getting some cookie-values through different methods of string-handling.

The original Problem was posted as follows:

Hi.

Thought I'd share with you a little problem I had.
Check out this code.

[CODE=javascript]
var ca = document.cookie .split(';');
var value = "";

for (var x = 0; x < ca.length; x++) {
if (ca[x].indexOf(name) == 0) {
var start = ca[x].indexOf('=') + 1;
var length = ca[x].length - start;

value = ca[x].substr(start, length);
}
}
[/CODE]

This code basicly takes the entire document.cookie string and splits it at every ';' and then searches for the 'name' at the start of each one.

This worked fine in IE, but it failed in all other browsers I checked (Firefox, Opera, Netscape).

Turns out everybody except MS decided to but a space(ascii nr 32) before each part of the split command, wich made the indexOf return 1 in stead of 0.

Now I've got to ask.. WTF?!?

Anyways be carefull with the split command.

-- Atli Þór

As you can see, there could have been a problem with the split-method. The following short article handles ways around this possible problem, that we couldn't reproduce, but someone may possibly encounter it too sometimes. If nothing else, the shown adaptations will be helpful in understanding how to retrieve cookie-values or handle string-values with different js-methods.

First we test the split-method, since Atli guessed it could have a problem:

The split-command works well in FF 2.0.0.9:

I've used the following code:

[CODE=javascript]
var val = 'a=1;b=2;c=3'

var arr = val.match(/[^;]+/g);

// arr is ["a=1", "b=2", "c=3"] now

arr = val.split(';');

// arr is ["a=1", "b=2", "c=3"] now
[/CODE]
so it works as expected and I simply used the regEx to show another way to create an array from the string 'val'. Both methods are equivalent.

Next I checked the indexOf code ... that worked as expected too:

[CODE=javascript]
// lets assume we want to alert the value of c
var name = 'c';

for(var x = 0; x < arr.length; x++) {
if (arr[x].indexOf(name) == 0) {
var start = arr[x].indexOf('=') + 1;
var length = arr[x].length - start;

var value = arr[x].substr(start, length);
alert(value);
}
}
[/CODE]
but we may use the regEx here too:

[CODE=javascript]
for (var x = 0; x < arr.length; x++) {
if ((new RegExp('^' + name)).test(arr[x])) {
var value = arr[x].match(/[^=]+$/);
alert(value);
}
}[/CODE]
so I couldn't find anything wrong with indexOf or split ... but we have options to work around their use in cases where there would be a problem :)

So now we found that the problem could be another one than with the split-method. Atli responded with:

The regEx trick will definitely come in handy.

Looking back at this now, I see that I only tested this problem using data from cookies. Knowing how loosely M$ follows standards, and how much they like being different than everybody else, I think it more likely that the problem is with the cookie data rather than the split command.

It could very well be that IE creates cookies in one white-space free string, while the other browsers add a space between values, thus causing there to be an extra space when I split it on every semi-colon.

So we could use the regExp again to handle that in case that would be the real problem:

[CODE=javascript]
var value = ' c=1';
value = value.replace(/^\s+/, '');

// now value has 'c=1' assigned
[/CODE]
that simply would remove any whitespaces at start of a string-value.

Now acoder jumped in and brought us back to the original problem with providing a getCookie function derived from w3schools:

[CODE=javascript]function getCookie(name) {
if (document.cooki e.length > 0) {
start = document.cookie .indexOf (name + "=");
if (start != -1) {
start += name.length + 1;
end = document.cookie .indexOf(";",st art);
if (end == -1) end = document.cookie .length;
return unescape(docume nt.cookie.subst ring(start,end) );
}
}
return "";
}[/CODE][Adapted from W3Schools JavaScript Cookies]

So this HowTo is a little case study on how to encounter a problem and how we could workaround and/or come back to the basic-problem ... :) and it shows again that working on code together is much more efficient then doing it alone, since we could learn that problems may not be quite clear at the first look we always may find a way around one special code-usage and having an eye on the original problem is always an advantage :)

[acoder]

and it shows again that working on code together is much more efficient then doing it alone, since we could learn that problems may not be quite clear at the first look we always may find a way around one special code-usage and having an eye on the original problem is always an advantage :)

I agree. Sometimes, you can miss a basic error which someone else can pick up. Other times, someone may have a better idea to solve a problem.