Javascript 字符串字节长度计算函数代码与效率分析（for VS 正则）
程序员文章站
2022-06-22 15:04:59
先看看一下两段代码吧，它们分别用for循环和正则表达式来检测字符串的字节长度： for循环检测字符串的字节长度方法一： 复制代码 代码如下: var lenfor = fu...
先看看一下两段代码吧，它们分别用for循环和正则表达式来检测字符串的字节长度：
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循环只需要遍历一次——这应该就是问题所在了，但是我不是非常确定。
我不太确定以上的理解是否确切，但是从表面上分析应该是这样的。
那么，用正则表达式检测真的使算法更加复杂吗？还是以上没有充分利用正则表达式的优势？现在我还没有意义的想法，需要进一步去推敲。先保持着怀疑吧^_^……
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循环只需要遍历一次——这应该就是问题所在了，但是我不是非常确定。
我不太确定以上的理解是否确切，但是从表面上分析应该是这样的。
那么，用正则表达式检测真的使算法更加复杂吗？还是以上没有充分利用正则表达式的优势？现在我还没有意义的想法，需要进一步去推敲。先保持着怀疑吧^_^……