function prime(MAX) {
    var re = /^(11+?)\1+$/,
        n, C = '1', s = C,
        r = [], j = 0;

    while ((n = (s += C).length) < MAX) {
        !re.test(s) && (r[j++] = n);
    }
    return r;
}
alert(prime(10000).length);

作为前端，为了让上面的脚本能在实际页面中应用，还得考虑 脚本在浏览器中的耐心 以及 分时优化处理。

最后，请猛击测试页面：prime-number.html

注释里已经写得很清楚，不赘述。
特别有趣的是 img onload 方案，很 nice 的 hack, 在写原生小代码时可以派上用场。

KISSY 的解决方案：dom-create.js 里的 setHTML 方法。
应用范例：

KISSY.DOM.html('#container',
               'some html with script tags<script>alert("Hello, KISSY!");</script>',
               true);

文档：dom-create.html

alert(parseInt(0.000001));
alert(parseInt(0.0000001));

第一条语句输出 0, 第二条语句输出 1, 囧。

继续看代码：

alert(parseInt('0.000001'));
alert(parseInt('0.0000001'));

都输出 0, 这才符合预期。

查看 ECMA-262 规范，parseInt 会先调用 toString 方法。问题已逐渐清晰：

alert(0.000001);
alert(0.0000001);

第一条语句原样输出，第二条语句输出 1e-7.
继续翻查 ECMA-262 9.8.1 ToString Applied to the Number Type 一节，恍然大悟：

assertEquals("0.00001", (0.00001).toString());
assertEquals("0.000001", (0.000001).toString());
assertEquals("1e-7", (0.0000001).toString());
assertEquals("1.2e-7", (0.00000012).toString());
assertEquals("1.23e-7", (0.000000123).toString());
assertEquals("1e-8", (0.00000001).toString());
assertEquals("1.2e-8", (0.000000012).toString());

上面是 V8 引擎 number-tostring 的单元测试脚本, 很好地诠释了 ECMA 规范。

小结：对于小于 1e-6 的数值来说，ToString 时会自动转换为科学计数法。因此 parseInt 方法，在参数类型不确定时，最好封装一层：

function parseInt2(a) {
    if(typeof a === 'number') {
        return Math.floor(a);
    }
    return parseInt(a);
}

除了正常用法，slice 经常用来将 array-like 对象转换为 true array.

名词解释：array-like object – 拥有 length 属性的对象，比如 { 0: ‘foo’, length: 1 }, 甚至 { length: ‘bar’ }. 最常见的 array-like 对象是 arguments 和 NodeList.

查看 V8 引擎 array.js 的源码，可以将 slice 的内部实现简化为：

function slice(start, end) {
    var len = ToUint32(this.length), result = [];
    for(var i = start; i < end; i++) {
        result.push(this[i]);
    }
    return result;
}

可以看出，slice 并不需要 this 为 array 类型，只需要有 length 属性即可。并且 length 属性可以不为 number 类型，当不能转换为数值时，ToUnit32(this.length) 返回 0.

对于标准浏览器，上面已经将 slice 的原理解释清楚了。但是恼人的 ie, 总是给我们添乱子：

var slice = Array.prototype.slice;
slice.call(); // => IE: Object expected.
slice.call(document.childNodes); // => IE: JScript object expected.

以上代码，在 ie 里报错。可恨 IE 的 Trident 引擎不开源，那我们只有猜测了：

function ie_slice(start, end) {
    var len = ToUint32(this.length), result = [];

    if(__typeof__ this !== 'JScript Object') throw 'JScript object expected';
    if(this === null) throw 'Oject expected';

    for(var i = start; i < end; i++) {
        result.push(this[i]);
    }
    return result;
}

至此，把猥琐的 ie 自圆其说完毕。

关于 slice, 还有一个话题：用 Array.prototype.slice 还是 [].slice ? 从理论上讲，[] 需要创建一个数组，性能上会比 Array.prototype 稍差。但实际上，这两者差不多，就如循环里用 i++ 还是 ++i 一样，纯属个人习惯。

最后一个话题，有关性能。对于数组的筛选来说，有一个牺牲色相的写法：

var ret = [];
for(var i = start, j = 0; i < end; i++) {
    ret[j++] = arr[i];
}

用空间换时间。去掉 push, 对于大数组来说，性能提升还是比较明显的。

一大早写博，心情不是很好，得留个题目给大家：

var slice = Array.prototype.slice;
alert(slice.call({0: 'foo', length: 'bar'})[0]); // ?
alert(slice.call(NaN).length); // ?
alert(slice.call({0: 'foo', length: '100'})[0]); // ?

架构是把握问题的关键，平衡设计。

很认可。下面是我的理解：

1. 什么是把握？在武术届有一种器械训练方式是“抖大杆”：一条白蜡木做的大杆，杆长超过两米，训练者一手把杆，一手握住杆的底部，全身配合双手，将杆抖出各种样式。把和握是两个不同的动作，把的是方向，握的是基底。把握是一种掌控，武林高手能让大杆随心而动，随意而行，这就是把握。把握可以以把为主，以握为辅，随心所欲，花样百出。把握亦可以握为主，以把为辅，以气驭剑，天马行空。
2. 什么是问题？物理学家狄拉克有一个典故。有一天他到一个学校去演讲，讲完以后，主持人说：“大家有什么问题？可以问狄拉克教授。” 这时，有一个学生站起来说：“刚才你在黑板上写的那个方程式我不懂。” 狄拉克没有回答，好长时间都没有回答。于是主持人就问：“狄拉克教授，您可不可以回答这个问题呢？” 狄拉克说：“那不是一个问题。” 狄拉克为何拒绝回答？因为提问者看不懂方程式只是现象，而不是问题。什么是问题这个问题，推荐阅读杰拉尔德·温伯格的经典著作《你的灯还亮着吗 — 发现问题的真正所在》。
3. 什么是关键？关键的原始释义是门闩。关是关闭，把门合上，键指机械零件。放到现代，关键就是门上的锁。如何找出未知问题的关键所在？资深的盗墓者，遭遇一个前所未有的机关时，首先是观察，尽可能的获取信息。其次是分析，尽可能推断机关背后的机理。紧接着可能会联想和尝试，用已有的破解技巧，去尝试解决当前问题。反复以上步骤，不懈努力，等机关破解的那一刹那，盗墓者也就明白了该机关的关键所在。
4. 什么是平衡？Douglas 说，万事皆权衡。架构的好坏，是一个适不适合场景的问题。无论是类库的设计，还是某一行代码的书写方式，好坏与否，都要看这个类库或这行代码，使用在什么场景下。Google 首页可以省去 html 结束符，但并不意味着你的博客这么干也是妥当的。在前端界，table 布局也不是万恶不赦的。如果你的用户群里还有不少用户在使用非常旧式的浏览器，table 布局就是最合适的方式。

为了进一步阐释，下面举一个实例。

很喜欢看书，好几年前开始，喜欢从网络上收集各种书籍：

（几年前的详细分类已丢失，上面仅是模拟能想起来的几个类别）

按照上面的书籍整理方式，很快发现一个问题：有些书籍，会同时属于多个类别。比如《红楼梦》，放在“古典文学”里好呢，还是放在“精品小说”里好？很明显，这涉及图书管理学的经典问题：如果做一个合理有效的分类？

于是开始尝试从各种维度来重新分类，甚至跑到大型图书馆里去借鉴图书馆的分类方式。但很快我就崩溃了：中国文学 – 古典文学 – 小说 – 清朝 – 红楼梦。我不是图书管理员，我就是想收集点自己喜欢看的书而已。这种完美主义者的“科学”分类法立刻被我抛弃。

后来很长一段时间，我的书籍分类一直很混沌。经常隔上几个月，就要大动干戈全部调整一次，让自己追求“完美”的心灵临时安顿。

很漫长的一段时间，很纠结的一段折腾。

一直到大约一年前，忘了当时是什么触因，突然就找到了一个让自己非常满意的分类。在给出这个分类前，我们先“马后炮”一把，尝试从架构角度来进行分析：

这个例子中，什么是问题？表面上看，是如何找到一个合理的图书分类方式。但这真的是问题吗？显然不是。大型图书馆的书目，绝对是合理的。那问题在什么地方？稍一分析不难发现，问题不在于书目分类是否合理，而在于是否适合我的习惯，是否能满足我的需求。（初始的分类问题被转换成了需求问题，有关问题转换方面的话题，推荐阅读温伯格的书籍）

那么，什么是我的需求？我为何要对书籍进行分类？仔细思考，我将需求整理为：

1. 新下载的书籍有个固定的目录存放。能让自己想看时，快速找到。
2. 正在看的书籍能立马找到。
3. 已看完的书籍要归档，以后能比较方便的查阅。

从上面的描述中，可看出我的需求有时间线。我的需求是根据阅读书籍的时间来组织的！“时间”就是我寻找了很久的书目分类的维度！因此时间维度就是该信息架构问题的关键！这样，立刻就有了看似简单但能很好解决问题的分类方式：

一切就这么简单！按照这个方式重新整理书目后，立刻心旷神怡。

当然，这里也涉及到权衡：

1. 新下载的书籍太多怎么办？需要分类吗？
2. 已看完的书籍，归档时需要分类吗？

上面两个问题，不同的人有不同的方案。我的选择是：

1. 新下载的书籍不再分类，全部混杂放在一起。好处是能杜绝自己盲目收集书籍的“恶习”，并规定新下载的书籍不能超过 10 本。第 11 本入库时，必须删掉前 10 本中的一本。
2. 已看完的书籍会分类，但只做一级大分类，比如：小说/诗歌/摄影。并规定从“正在读”移动到“已阅读”时，要非常谨慎，必须有理由说服自己有保存价值时才归档，否则删无赦。这样，一年下来，真正有价值归档的书籍并不多。

这就是权衡！

最后再给一个案例，我的 Google Reader 订阅项分类：

必读 — 符合自己脾胃的精品订阅源
闲读 — 可看可不看的订阅源
待通读 — 新发现的一些相见恨晚的博客，想翻阅其所有文章
更新 — 软件更新提示等订阅源

自从采用这个分类后，信息筛选的时间大大减少，有效阅读的时间增加了很多。注意：这个分类适合我，但未必适合你。适合你的分类，可以从自己的真正需求出发，仔细的思考和分析，通过探索和实践去获得。

上面说的虽然是很小的生活中的分类问题，但往大里说就是信息架构，再类推开去，就是软件架构。道理是相通的。架构是个过程，是思考、实践，再次思考、再次实践的过程。在这过程中，下面三个问题经常遇到：

1. 问题是什么？
2. 什么是问题的关键？
3. 在当前应用场景下，如何设计，如何权衡？

架构就是在特定应用场景下，不断追问和寻求以上问题的过程。在这过程中，你的所有决策的集合，就是架构。

找好规律，代码就好写了：

var hash = {'32' : '\u3000'};
// 半角转全角
function sbc2dbc(str) {
    var ret = [], i = 0, len = str.length, code, chr;
    for (; i < len; ++i) {
        code = str.charCodeAt(i);
        chr = hash[code];
        if (!chr && code > 31 && code < 127) {
            chr = hash[code] = String.fromCharCode(code + 65248);
        }
        ret[i] = chr ? chr : str.charAt(i);
    }
    return ret.join('');
}

同理：

var hash = {'12288' : ' '};
// 全角转半角
function dbc2sbc(str) {
    var ret = [], i = 0, len = str.length, code, chr;
    for (; i < len; ++i) {
        code = str.charCodeAt(i);
        chr = hash[code];
        if (!chr && code > 65280 && code < 65375) {
            chr = hash[code] = String.fromCharCode(code - 65248);
        }
        ret[i] = chr ? chr : str.charAt(i);
    }
    return ret.join('');
}

上面的代码会将 33 - 126 中间的符号也转换。很多时候，这并不是我们需要的（比如将 @ 转换为 ＠）。下面的代码侵入性更小：

var hash = {};
// 半角转全角。仅转换 [0-9a-zA-Z]
function sbc2dbc_w(str) {
    var ret = [], i = 0, len = str.length, code, chr;
    for (; i < len; ++i) {
        code = str.charCodeAt(i);
        chr = hash[code];
        if (!chr &&
            (47 < code && code < 58 ||
             64 < code && code < 91 ||
             96 < code && code < 123)) {
            chr = hash[code] = String.fromCharCode(code + 65248);
        }
        ret[i] = chr ? chr : str.charAt(i);
    }
    return ret.join('');
}

详细测试页面：sbc2dbc-test.html

字符引用

在 html 中，有三种字符引用方式（参考 HTML5 规范）：

1. Named character references, 通过名称来引用。在 HTML 4.01 中称之为 Character entity references（字符实体引用）比如 < >   ", 这里有一份详细列表 named-character-references
2. Decimal numeric character reference, 通过十进制数值来引用。比如 å И
3. Hexadecimal numeric character reference, 通过十六进制数值来引用。比如 å 水

在 HTML 4.01 中，上面 2 和 3 归为一种：Numeric character references（字符数值引用）。
这里有份非常好的对照表：XHTML Character Entity Reference

在 javascript 中，特殊字符用反斜杠转义，比如 \t, \n, \u0020, 这个不必多说。
在 css 中，只支持 unicode 转义。比如 \0020.
注意：\u0020 在 js 中，必须有 u, 而且必须 4 位。在 css 中，u 必须省略，同时可以省略前导 0. 比如 \0020 在 css 中可以简化为 \20. 因此那个常见的 clearfix, 可以简化为 content: ‘\20′. 好友怿飞提到的兼容性和语义，应该指的是这个。content 后直接用空格或其它空白字符，会导致某些兼容性问题。

空白字符

说到字符引用，不得不提一下空白字符。在 JavaScript 的正则里，\s 是 unicode-aware 的，可以匹配 \u0020, \u0009 等空白字符。但各个浏览器的实现有差异，具体可以参见：JavaScript, Regex, and Unicode.

大部分情况下，JS 类库在实现 trim 方法时，使用 /^\s+|\s+$/g 即可。
在 jQuery 中，加入了对 \u00A0 的检测：/^(\s|\u00A0)+|(\s|\u00A0)+$/g
\u00A0 其实就是   代表 non-breaking space(不间断空白)

关于  , 严格语义上来说，使用场景是不希望自动换行时使用。
但现实中，绝大部分情况下，  就用来表示纯粹的空格。因为多个字符空格在 html 中会被当成一个空格，为了连续输出多个空格，只好用   （毕竟用 css 控制太麻烦）。按理说用多个   输出多个空格是最好的选择，但强大的 html 引擎依旧会把多个   转换成一个。

jQuery 的 trim 方法加入 \u00A0, 是种无奈，但也是一种对现实标准的认可。

一切皆权衡。

昨天搭建 taskspeed, 检查 jQuery 的测试代码时，突然明晓了一个也许大家都已知道的秘密：

jQuery 最出色最让人恋恋不舍的是它的 API 设计。

比如 dom-style 的 api, YUI3 和 MooTools 等框架采用的是传统方式：

el.setStyle(prop, val);
el.getStyle(prop);
el.setStyles({ propA: valA, propB: valB });
el.getStyles(propA, propB); // MooTools 支持

在 jQuery 里，一个 css 方法全部搞定：

el.css(prop); // 表示 getStyle
el.css(prop, val); // 表示 setStyle
el.css({ propA: valA, propB: valB }); // 表示 setStyles
el.css(prop, func); // func 是一个返回 val 值的函数

对比以上两种 API 设计，乍一看 jQuery 显得不那么“标准”。但从可记忆性和灵活性上讲，我觉得 jQuery 的设计都更人性化。jQuery 的 API 还符合学习上的渐进式思维：先学会最简单的情况el.css(prop), 再了解到还可以有两个参数，接着发现参数可以是 map, 更进一步发现 val 还可以是一个函数。func 参数甚至能带给学习者一种惊喜：居然还可以这样用！jQuery 把一种渐进和愉悦带进了学习和使用的过程中，实在漂亮！

YUI3 的 API 缺少这种乐趣。查询 jQuery 的 API, 会有一种探寻秘密的寻宝感觉。YUI 的文档查询则让人感觉就是份工作，有点 boring.

和 YUI2 相比，YUI3 的 API 做了些改变。在 YUI2 里，YAHOO.util.Dom 的方法名，严格以动词开头，虽然有些方法名长点，但总体规律性很强，可记忆性还不错。在 YUI3 里，则出现了 byId, elementByAxis 等方式命名的方法。纯粹为了省几个字符？这种不一致性很纳闷。还有一些以名词命名的方法：ancestor, docHeight, 乍一看很难以为是方法。

老婆说，要睡觉了，就不码字了。最后说一句：YUI3 的 API 整体还是挺不错的，比如 Node 的方法命名，就非常严谨。ancestor 也是为了对应 next, prev 等命名。也就是说：Y.Dom 其实已变成了内部 API, 不鼓励用户直接调用。

但是不知为什么，我还是觉得 jQuery 的 API 设计高出一个层次，套用一句流行话就是：
jQuery API 的用户体验更好。

测试页面：trim-test.html

感兴趣的几个方法：

function trim1(str) {
    return str.replace(/^\s\s*/, '').replace(/\s\s*$/, '');
}
function trim2(str) {
    return str.replace(/^\s+/, '').replace(/\s+$/, '');
}
function trim4(str) {
    return str.replace(/^\s+|\s+$/g, '');
}
function trim8(str) {
    return str.replace(/^\s*((?:[\S\s]*\S)?)\s*$/, '$1');
}

时至今日，有些结论已经发生变化：

1. trim1 中使用的正则优化：pre-check of required character and start of string anchor, 在最新的 JS 引擎中已经内置。trim4 也得到了非常好的优化，比 trim1, trim2 都快。

2. trim8 在 IE 中依旧非常有优势。这是因为 IE 对 \S\s (any character token) 有非常好的优化。另外 ?: (non-capturing group) 对性能也有提升。

3. trim10 是非正则实现方案，速度飕飕的。原文中指出关键点：正则在处理过程中无法直接跳转到字符串末尾，从而导致在处理长字符串时耗时稍长。于是有了混合版本 trim11 和 trim11 的改进版本 trim12:

function trim11(str) {
    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;
}

function trim12(str) {
    str = str.replace(/^\s\s*/, "");
    var ws = /\s/,
            i = str.length;
    while (ws.test(str.charAt(--i))) {}
    return str.slice(0, i + 1);
}

4. 在原文的回复中，还有利用空间换时间的 map 方案。

5. 对于普通应用，比如 JS 框架，原文作者推荐使用 trim1. 从上面的变化可以看出，目前更好的方案是 trim4. 这也正是当今流行 JS 框架中广泛采用的实现方案。对于特殊应用需要处理长字符串时，推荐采用 trim11.

6. 目前 Firefox 3 和 Chrome 4 中都已原生实现 String.prototype.trim, 对于这些浏览器，原生实现始终是最佳方案。

7. 原文作者的 final note 值得注意：许多开发者习惯用变量缓存正则，这可以避免正则的重复编译，但这对于简单如 trim 的正则来说意义不大。trim 的正则如此简单，编译时间是纳秒级的。而且不少浏览器自身已对最近使用的正则进行缓存，不会存在重复编译的问题。trim13 用来验证此观点，除了 IE, 其它浏览器下，当重复次数 times 变大时，trim13 反而比 trim12 略有优势。

8. 讨论一个有争议的点：对于 JS 类库来说，trim 方法究竟应不应该附加在 String.prototype 上呢？侵入 built-in 对象，会导致for...in产生某些非预期结果。但是，对于 String 来说，用for...in遍历 String 本就是非常不明智的行为。为了这些“愚蠢的”使用方法，而坚决不侵入 built-in 对象，是否真的值得？毕竟从用户角度讲，str.trim() ，比类似$.trim(str)这种写法自然多了。

最后给一个我的方案：

if(!String.prototype.trim) {
    var TRIM_REG = /^\s+|\s+$/g;
    String.prototype.trim = function() { return this.replace(TRIM_REG, ''); }
}