javascript中的 encodeURIComponent() 方法很常用,MDN里在描述这个方法的时候,有提到这个异常: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent
在下面这个case中,node.js里被发现一个严重bug: http://cnodejs.org/topic/4fd6b7ba839e1e581407aac8
当时所有connect的app都紧急修复大伙们之前都没有意识到这个问题的存在,直到遇到这个可怕的0xDFFF
,实在是隐蔽,汗!
*上有人给出了一个详细的解答,大致翻译一下,大伙看看:
同样也是遇到这个问题,为了发现问题所在,@Brett Zamir 写了一个遍历方法,把ucs-2的字符集扫描了一遍:
for (var regex = '/[', firstI = null, lastI = null, i = 0; i <= 65535; i++) {
try {
encodeURIComponent(String.fromCharCode(i));
}
catch(e) {
if (firstI !== null) {
if (i === lastI + 1) {
lastI++;
}
else if (firstI === lastI) {
regex += '\\u' + firstI.toString(16);
firstI = lastI = i;
}
else {
regex += '\\u' + firstI.toString(16) + '-' + '\\u' + lastI.toString(16);
firstI = lastI = i;
}
}
else {
firstI = i;
lastI = i;
}
}
}
if (firstI === lastI) {
regex += '\\u' + firstI.toString(16);
}
else {
regex += '\\u' + firstI.toString(16) + '-' + '\\u' + lastI.toString(16);
}
regex += ']/';
alert(regex); // /[\ud800-\udfff]/
很快结果就出来了,ud800-udfff 这段的字符是有问题的,再写个脚本验证一下:
for (var i = 0; i <= 65535 && (i <0xD800 || i >0xDFFF ) ; i++) {
try {
encodeURIComponent(String.fromCharCode(i));
}
catch(e) {
alert(e); // Doesn't alert
}
}
alert('ok!');
上面的输出符合MSDN上说的:这些字符除了surrogates,即便是“non-characters”也都是合法的unicode序列。
surrogates就是上面扫描出来的危险字符集空间段,分为高位段,低位段
有了这个范围,你可以直接过滤掉这些危险字符,但是当这组字符成对出现的时候(高低位段的字符搭配),它们作为unicode扩展集字符又是合法的(utf-16)
alert(encodeURIComponent('\uD800\uDC00')); // ok
alert(encodeURIComponent('\uD800')); // not ok
alert(encodeURIComponent('\uDC00')); // not ok either
所以如果你只是想屏蔽这个段的字符
urlPart = urlPart.replace(/[\ud800-\udfff]/g, '');
如果你想屏蔽非法的字符,但是保留高低位合法组合的字符(utf-16字符,很少用到),可以这么搞:
function stripUnmatchedSurrogates (str) {
return str.replace(/[\uD800-\uDBFF](?![\uDC00-\uDFFF])/g, '').split('').reverse().join('').replace(/[\uDC00-\uDFFF](?![\uD800-\uDBFF])/g, '').split('').reverse().join('');
}
var urlPart = '\uD801 \uD801\uDC00 \uDC01'
alert(stripUnmatchedSurrogates(urlPart)); // Leaves one valid sequence (representing a single
如果js native处理了这个问题,就可以免了这个猥琐的修补,多好啊,哼!
====== 翻译完毕 ====
补充:
上诉的高低位端,实际上是 UCS-2中的保留字段。 unicode字符集分为很多端,看这里 http://baike.baidu.com/view/40801.htm
D800-DBFF:High-half zone of UTF-16 utf-16 高位
DC00-DFFF:Low-half zone of UTF-16 utf-16 低位
utf-16的参考资料:http://zh.wikipedia.org/wiki/UTF-16, 其中描述到:
Unicode的编码空间从U+0000到U+10FFFF,共有1,112,064个码位(code point)可用来映射字符. Unicode的编码空间可以划分为17个平面(plane),每个平面包含216(65,536)个码位。17个平面的码位可表示为从U+xx0000到U+xxFFFF,其中xx表示十六进制值从0016到1016,共计17个平面。第一个平面称为基本多语言平面(Basic Multilingual Plane, BMP),或称第零平面(Plane 0)。其他平面称为辅助平面(Supplementary Planes)。基本多语言平面内,从U+D800到U+DFFF之间的码位区段是永久保留不映射到Unicode字符。UTF-16就利用保留下来的0xD800-0xDFFF区段的码位来对辅助平面的字符的码位进行编码。
所以这个问题就清晰明了
补充: 感谢 @猎隼 的补充
decodeURIComponent()确实也是危险的存在, js的encodeURIComponent, decodeURIComponent 处理的都是utf-8编码的字符集。decodeURIComponent 一旦传入gbk的encode字符串,异常就会抛出,没有try catch就会搞死node进程。
参考:
http://*.com/questions/16868415/encodeuricomponent-throws-an-exception