for循環檢測字符串的字節長度方法一：
復制代碼代碼如下:
var lenFor = function(str){
var byteLen=0,len=str.length;
if(str){
for(var i=0; i<len; i++){
if(str.charCodeAt(i)>255){
byteLen += 2;
}
else{
byteLen++;
}
}
return byteLen;
}
else{
return 0;
}
}
使用方法
var strlength=lenFor(str)
for循環檢測字符串的字節長度方法二：
復制代碼代碼如下:
function LEN(str){
var i,sum=0;
for(i=0;i<str.length;i++){
if((str.charCodeAt(i)>=0) && (str.charCodeAt(i)<=255))
sum=sum+1;
else
sum=sum+2;
}
return sum;
}
正則表達式檢測字符串的字節長度方法三：
有點代碼比較精簡，根據下面的測試，效率卻不高，大家可以用上面的函數。
復制代碼代碼如下:
var lenReg = function(str){
return str.replace(/[^/x00-/xFF]/g,'**').length;
};
var strlength2=lenReg(str)
我用以下代碼段對以上兩個函數進行測試，主要是測試其運行時間：
復制代碼代碼如下:
var s = '......';//一個很長的字符串，這里不羅列
function a(){
var timeStart,timeEnd;
timeStart = new Date();
var s1 = lenReg(s);
timeEnd = new Date();
var t1 = (timeEnd - timeStart)*1000;
timeStart = new Date();
var s2 = lenFor(s);
timeEnd = new Date();
var t2 = (timeEnd - timeStart)*1000;
alert('lenReg: ' + s1 + ' time: ' + t1 + '/nlenFor: ' + s2 + ' time: ' + t2);
}
window.onload = function(){
a();
};
以上代碼在瀏覽器載入完畢的時候彈出一個警示窗口，窗口上有兩行信息：第一行是用正則表達式檢測的字符串字節長度和所用時間（×1000）；第二行是用for循環檢測字符串字節長度和所用時間（×1000）。
我得到兩種答案：
第一種：
lenReg: 25824 time: 20000
lenFor: 25824 time: 10000
第二種：
lenReg: 48795 time: 15000
lenFor: 48795 time: 25000
需要說明的是，兩次測試所用的字符串為同一字符串。
為什么會相差那么大呢？我到底偷偷改了什么？？以上我提過，“中文字符占用2個字節（與編碼有關）”（本文第三段），中文字符占用多少個字節是與編碼有關的，一般情況下，GB-2312和UTF-8編碼中，中文字符占用2個字節，但是在iso-8859-1編碼中，中文字符占用5個字節。
是的，問題就在于文檔的編碼。以上第一種情況的編碼為：charset=UTF-8，第二種情況的編碼為charset=iso-8859-1。
在中文網頁中，我們一般都不會用charset=iso-8859-1進行編碼（中文亂碼），而是用charset=UTF-8或GB-2312進行編碼。問題就在這里，比較一下以上的第一種情況吧：
lenReg: 25824 time: 20000
lenFor: 25824 time: 10000
如上所示，用正則表達式檢測所用的時間竟然是for循環的兩倍！！！！（其實，測試多次之后也不全部都是兩倍，但大部分測試都是兩倍）
為什么呢？
str.replace(/[^/x00-/xFF]/g,'**').length;
看看以上語句（lenReg函數中的語句）。就我個人理解，問題就出現在這里——replace的時候要遍歷一次字符串，在調用length的時候又要遍歷一次字符串，所以整個運算過程需要遍歷兩次字符串。而for循環只需要遍歷一次——這應該就是問題所在了，但是我不是非常確定。
我不太確定以上的理解是否確切，但是從表面上分析應該是這樣的。
那么，用正則表達式檢測真的使算法更加復雜嗎？還是以上沒有充分利用正則表達式的優勢？現在我還沒有意義的想法，需要進一步去推敲。先保持著懷疑吧^_^……
