In the ie 7 8 browser, if you use the trim() attribute to remove spaces, an error will be reported.
Therefore, there are the following solutions to this problem:
var aa = $("#id").val().trim() --- The trim() method cannot be parsed in IE
Solution:
[ var aa = $.trim($("#id").val()); ] This is not easy to use, so use the one introduced below. The first one has been tested.
The W3C group of people were kicked in the heads by donkeys, and they did not support trim functions (and trimLeft, trimRight) until Java script 1.8.1. Unfortunately, only firefox3.5 supports it now. Since removing blanks on both sides of strings is too common, all major libraries have their own shadows. In addition, foreigners have a lot of research energy and have made a lot of achievements.
Implement 1 OK. (Write this in js, and then follow the string you want to remove the space directly.trim())
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s/s*/, '' ).replace(//s/s*$/, '' );
}
It doesn't look very good, and I used two regular replacements. The actual speed is amazing, mainly due to the internal optimization of the browser. A famous example of string splicing, direct addition is faster than a StringBuffer made of Array. Base2 class library applies this implementation.
Implement 2
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s /, '' ).replace(//s $/, '' );
}
It's very similar to implementation 1, but a little slower, the main reason is that it first assumes that there is at least one whitespace. Prototype.js uses this implementation, but its name is strip, because the methods of Prototype try to rename it with Ruby.
Implementation 3
The code copy is as follows:
String.prototype.trim = function () {
return this .substring(Math.max( this .search(//S/), 0), this .search(//S/s*$/) 1);
}
The blank part is obtained by intercepting (of course, whitespace characters are allowed in the middle), and a total of 4 native methods are called. The preset is very clever, substring takes two numbers as parameters. Math.max uses two numbers as parameters, and search returns to one number. The speed is a little slower than the top two, but it is much faster than the bottom.
Implement 4
The code copy is as follows:
String.prototype.trim = function () {
returnthis .replace(/^/s |/s $/g, '' );
}
This can be called a simplified version of implementation 2, which is to use candidate operators to connect two regularities. But doing so will fail to achieve browser optimization opportunities, which is not as good as realization 3. Because it seems elegant, many library applications such as JQuery and mootools
Implement 5
The code copy is as follows:
String.prototype.trim = function () {
var str = this ;
str = str.match(//S (?:/s /S )*/);
return str ? str[0] : '' ;
}
match is to return to an array, and the part that meets the requirements of the original string becomes its element. In order to prevent the blank space in the middle of the string from being disconnected, we need to use non-capture grouping (?:exp). Since the array may be empty, we need to make further judgments later. It seems that the browser is less powerful in processing groupings, and one word is slower. So don't be superstitious about the rules, although it is basically omnipotent.
Implementation 6
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s*(/S*(/s/S )*)/s*$/, '$1' );
}
Provide the required part and put it in an empty string. But the efficiency is very poor, especially in IE6.
Implementation 7
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s*(/S*(?:/s /S )*)/s*$/, '$1' );
}
It is very similar to implementation 6, but it uses non-capture packets to provide advantages, and the performance efficiency is slightly improved.
Implementation 8
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s*((?:[/S/s]*/S)?)/s*$/, '$1' );
}
I improved the above two ideas, used non-capturing grouping and character sets, and replaced * with ?, which was amazing. Especially in IE6, madness can be used to describe this performance improvement, and directly kill Firefox in seconds.
Implement 9
The code copy is as follows:
String.prototype.trim = function () {
return this .replace(/^/s*([/S/s]*?)/s*$/, '$1' );
}
This time, I used lazy matching to replace non-capturing grouping, which was improved in Firefox, and IE was not as crazy as last time.
Realize 10
The code copy is as follows:
String.prototype.trim = function () {
var str = this ,
whitespace = ' /n/r/t/f/x0b/xa0/u2000/u2001/u2002/u2003/u2004/u2020 05/u2006/u2007/u2008/u2009/u200a/u200b/u2028/u2029/u3000' ;
for ( var i = 0,len = str.length; i = 0; i--) {
if (whitespace.indexOf(str.charAt(i)) === -1) {
str = str.substring(0, i 1);
break;
}
}
return whitespace.indexOf(str.charAt(0)) === -1 ? str : '' ;
}
I just want to say that the person who created this is no longer described as a cow, but is at the same level as a god. It first lists all possible blank characters, cuts off the front blank in the first traversal, and cuts off the back blank for the second time. The whole process only uses indexOf and substring, a native method specially designed for processing strings, and does not apply the regularity. The speed is amazingly fast, and it is expected to be close to the internal binary implementation, and it has outstanding performance in IE and Firefox (of course other browsers are undoubtedly). Speeds are all zero milliseconds in addition.
Implement 11
The code copy is as follows:
String.prototype.trim = function () {
var str = this ,
str = str.replace(/^/s /, '' );
for ( var i = str.length - 1; i >= 0; i--) {
if (//S/.test(str.charAt(i))) {
str = str.substring(0, i 1);
break;
}
}
return str;
}
Implementation 10 has told us that the normal string interception method that is originally unknown is far better than regular replacement, although it is a little more complicated. But as long as the regularity is not too complicated, we can use the browser to optimize the regularity to improve program execution efficiency, and achieve 8 performance in IE. I don't think anyone would normally apply implementation 10 in a project, because that whitespace implementation is too long and hard to remember (of course, if you are building a class library, it will definitely start). Implementing 11 can be said to be its improved version. The blanks in the front are cut off by regular replacement. They are treated with native methods later. The effect is not inferior to the original version, but the speed is amazing.
Implement 12
The code copy is as follows:
String.prototype.trim = function () {
var str = this ,
str = str.replace(/^/s/s*/, '' ),
ws = //s/,
i = str.length;
while (ws.test(str.charAt(--i)));
return str.slice(0, i 1);
}
The better improvement version of the implementation 10 and implementation 11 is written. Note that it is not about performance speed, but about ease of memory and application. And its two predecessors are zero milliseconds in addition, they will use this to work and scare people in the future.
The following is the comparison result given by foreigners. The execution background is to perform trim operations on this article (more than 27,600 characters).
Implement Firefox 2 IE 6
trim1 15ms trim2 31ms trim3 46ms 31ms
trim4 47ms 46ms
trim5 156ms 1656ms
trim6 172ms 2406ms
trim7 172ms 1640ms
trim8 281ms trim9 125ms 78ms
trim10 trim11 trim12 trim function implementation reveals your own ideas. If you want to understand what the original author said, please read the original text.
There are currently 12 methods for removing spaces in JS:
Implement 1
String.prototype.trim = function() { return this.replace(/^/s/s*/, '').replace(//s/s*$/, ''); }
Implement 2
String.prototype.trim = function() { return this.replace(/^/s+/, '').replace(//s+$/, ''); }
Implementation 3
String.prototype.trim = function() { return this.s string(Math.max(this.search(//S/), 0), this.search(//S/s*$/) + 1); }
Implement 4
String.prototype.trim = function() { return this.replace(/^/s+|/s+$/g, ''); }
String.prototype.trim = function() { var str = this; str = str.match(//S+(?:/s+/S+)*/); return str ? str[0] : ''; }
String.prototype.trim = function() { return this.replace(/^/s*(/S*(/s+/S+)*)/s*$/, '$1'); }
Implementation 7
String.prototype.trim = function() { return this.replace(/^/s*(/S*(?:/s+/S+)*)/s*$/, '$1'); }
String.prototype.trim = function() { return this.replace(/^/s*((?:[/S/s]*/S)?)/s*$/, '$1'); }
String.prototype.trim = function() { return this.replace(/^/s*([/S/s]*?)/s*$/, '$1'); }
String.prototype.trim = function() { var str = this, whitespace = ' /n/r/t/f/x0b/xa0/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/?/ '; for (var i = 0,len = str.length; i < len; i++) { if (whitespace.indexOf(str.charAt(i)) === -1) { str = str.s string(i); break; } } for (i = str.length - 1; i >= 0; i--) { if (whitespace.indexOf(str.charAt(i)) === -1) { str = str.s string(0, i + 1); break; } } return whitespace.indexOf(str.charAt(0)) === -1 ? str : ''; }
Implement 11
String.prototype.trim = function() { var str = this, str = str.replace(/^/s+/, ''); for (var i = str.length - 1; i >= 0; i--) { if (//S/.test(str.charAt(i))) { str = str.s string(0, i + 1); break; } } return str; }
Implement 12
String.prototype.trim = function() { var str = this, str = str.replace(/^/s/s*/, ''), ws = //s/, i = str.length; while (ws.test(str.charAt(--i))); return str.slice(0, i + 1); }
It doesn't look very good, and I used two regular replacements, and the actual speed is amazing, mainly due to the internal optimization of the browser. A famous example of string splicing, which is faster than StringB?r made of Array. The base2 class library uses this implementation.
It's very similar to implementation 1, but a little slower, mainly because it first assumes that there is at least one whitespace. Prototype.js uses this implementation, but its name is strip, because the methods of Prototype strive to have the same name as R y.
The blank part is obtained by intercepting (of course, the whitespace character is allowed in the middle), and a total of four native methods are called. It is designed very cleverly, and s string takes two numbers as parameters. Math.max takes two numbers as parameters, and search returns a number. The speed is a little slower than the two above, but faster than most below.
This can be called a simplified version of implementation 2, which is to use candidate operators to connect two rules. But doing so will lose the opportunity to optimize the browser, which is not as good as realization 3. Because it seems elegant, many class libraries use it, such as JQ ry and mootools
Implement 5
match returns an array, so the part of the original string that meets the requirements becomes its element. In order to prevent the whitespace in the middle of the string from being excluded, we need to use non-capturing grouping (?:exp). Since the array may be empty, we need to make further judgments later. It seems that the browser is weak in processing groupings, and one word is slow. So don't be superstitious about the rules, although it is basically omnipotent.
Implementation 6
Provide the required part and put it in an empty string. But the efficiency is very poor, especially in IE6.
It is very similar to implementation 6, but it uses non-capture packets to provide advantages, and the performance efficiency is slightly improved.
Implementation 8
I improved the above two ideas, used non-capturing grouping and character sets, and replaced * with ?, which was very amazing. Especially in IE6, madness can be used to describe this performance improvement, and directly kill Firefox in seconds.
Implement 9
This time, I used lazy matching to replace non-capturing grouping, which was improved in Firefox, and IE was not as crazy as last time.
Realize 10
I just want to say that the person who created this is no longer described as a cow, but is at the same level as a god. It first lists all possible blanks, cuts off the front blanks in the first traversal, and cuts off the back blanks for the second time. The whole process only uses indexOf and s string, a native method specially designed for processing strings, and does not use regularity. The speed is amazingly fast, probably close to the internal binary implementation, and it has good performance in IE and Firefox (of course, other browsers are undoubtedly). The speed is all at zero milliseconds.
Implementation 10 has told us that the normal native string interception method is far better than regular replacement, although it is a little more complicated. But as long as the regularity is not too complicated, we can use the browser to optimize the regularity to improve program execution efficiency, such as achieving 8 performance in IE. I don't think anyone would normally apply implementation 10 in a project, because that whitespace implementation is too long and hard to remember (of course if you're building a class library, it's definitely the first). Implementing 11 can be said to be its improved version. The blanks in the first part are cut off by regular replacement, and the later processing is done by native methods. The effect is not inferior to the original version, but the speed is very amazing.
The better improvement version of the writing method of Implementation 10 and Implementation 11 is not about performance speed, but about easy memory and use. And its two predecessors are at zero millisecond level, so I will use this to work and scare in the future.