报错还好，怕的就是没有报错，而当项目上线后，在某些特定环境下，它才执行异常，这时候来查错才真的要人老命。所以，我们不能留下任何黑洞，我们必须清楚，浏览器端的Javascript到底有哪些命名禁区。

两次的教训，我觉得有必要整理一份Javascript命名禁区表了，不可能完全记住，但至少有一个大体印象。

一、标识符允许的字符集。
在ECMAScript V3中，标识符除首字母外，允许使用除 (./=?:&#\{}()<>[]|~!’”\*^) 等特殊字符外所有的unicode字符集。

二、变量名、函数名、循环标记命名禁区。
1、保留字
break delete function return typeof case do if switch var catch else in this void continue false instanceof throw while debugger finally new true with default for null try
2、未来保留字
abstract double goto native static boolean enum implements package super byte export import private synchronized char extends int protected throws class final interface public transient const float long short volatile
3、扩展列表
as is namespace use arguments encodeURI Infinity Object String Array Error isFinite parseFloat SyntaxError Boolean escape isNaN parseInt TypeError Date eval Math RangeError undefined decodeURI EvalError NaN ReferenceError unescape decodeURIComponent Function Number RegExp URIError

三、属性方法命名禁区。
1、保留字
break delete function return typeof case do if switch var catch else in this void continue false instanceof throw while debugger finally new true with default for null try
2、未来保留字
super export import extends const class

一、最精典的方法。
思路：遍历字符串，逐个取出字符，用replace将目标字符替换为空，用原字符串长度减去新字符串长度，获取目标字符出现次数，最终取出出现频繁最高的字符。

这是最常用、最传统的办法。
走套路可不带劲，开始探索新的方法，于是有了下面的改进版 －

二、最取巧的办法。
思路：
1、先将字符串转换成JSON数据。eg.‘波rr波’ -> {’波’: 2, ‘r’: 2} 。
2、再以JSON数据的值为索引转换成数组。eg.{’波’: 2, ‘r’: 2} ->[2]:’波’,'r’。
3、这样数组的最后一项即出现最多的字符。

探索是无止境的，方法二确实以精简的代码完成了同样的功能，但是这种取巧的方式，代码的可读性似乎不是太好。有没有第三种方式，两者兼顾呢，继续改进 -

三、最精简的办法。
思路：充分利用数组的sort方法根据出现频繁排序，首先将重复的字符全部放在一起并分别用正则匹配为数组，再根据数组长度排序。
PS：这里重在重新排列数据，最终取值不全（多个字符并列最多时只能取一个）。

从近20行代码压缩到3行代码，代码得到了进一部精简，并且保持了清晰的逻辑，大功告成!

真的大功造成了吗？
当然不是，相信不少童鞋已经注意到了，上面优化的过程中，性能问题我只字未提，而这恰恰又是优化的主旋律。
好了，我们开始性能测试 -

性能测试：
将测试数据放大，比较查找时间。

测试结果：（运行上面的代码查看详情）

测试结论：
当重复字符较多时 - 各浏览器均“方法一”速度最快；
当重复字符较少时 - IE6下“方法二”速度最快，FF3.6下“方法三”速度最快。
从适用性和性能角度纵使考虑，最终推荐 方法二。

原因分析：
当目标字符串重复字符较多时 -
方法一性能损耗主要在replace方法，但由于循环次数大大减少，从而取胜；
重复字符较少时 -
方法二虽然进行了两次循环，但每次循环计算量较少，从而取胜；
方法三在FF3.6中小胜，虽然进行了两次循环，两次数组转换，但由于调用内置的sort方法，从而取胜。

总结：
整篇文章虽然以精简为主线，其实我之前对性能就有所预料，本想借此唤起大家对性能的重视，不要为了精简而精简，小心当我们欢呼雀跃时，潜在的风险正在徐徐袭来。
但整个过程出现了一段插曲，给了我一记警钟，在将文章发表到经典论坛后，hutia对我的测试结果表示了异议，于是重新测试，发现由于我原来数据取样不够，而导致测试结果有所偏颇。
幸亏有一这么一段插曲，才让我更意识到，测试环节照样需要谨慎，感谢hutia。
真的只有在交流中才会发现自己的不足，以后也会经常把自己的东西晒出来，给大家评论，指点。

你有更优的解决办法吗？你对测试结果表示怀疑吗？欢迎大家拍砖。
你有什么疑点吗？你曾碰到过类似的场景吗？欢迎大家跟帖一起交流。

一、为什么会出现乱码？
　　在计算机中，我们储存的信息都是用二进制码表示的。我们文字和符号用的二进制代码的互相转换，就是编码，转换需要一种规则，就是字符集（charset），我们常用的字符集例如：ascii，gb2312，unicode。
不同的字符集所存储的内容不同， 比如“太平洋”三个字采用gb2312对应的值为4411 3829 4983，utf-8对应为E5 A4 AA E5 B9 B3 E6 B4 8B，这样，当一个gb2312的文件嵌入一个utf-8的文件的时候，问题就来了。

二、ANSI, Unicode, UTF-8, Encode, Charset, HTML实体… 我快疯了
疯完了没，没昏就行了，别着急，听我一一道来。其实这只是同一样东西在不同场合的应用。
A. ANSI, Unicode, UTF-8
这几个归为一类，它们是文件编码。
ANSI指当地编码，比如在大陆它指GB2312，在台湾它指GBK（Win中记事本保存文件的时候的默认选项就是它）。
Unicode是一个通用字符集，它是一个编码标准，这个和GB2312是对应的，但因为字符集过大，Unicode有它的特殊性，在不同应用场合，有不同的具体实现手法，比如应用于互联网传输，采用的存储与传送格式是UTF-8，Windows应用UTF-16，Linux 应用UTF-32。
B. Charset
HTML中的Charset，CSS中的@charset，XML中的encoding等，这几个归为一类。
它们是告诉浏览器如何解码。比如psd后缀是告诉系统这是Photoshop源文件，同样charset设为gb2312是告诉浏览器这是一个简体中文的网页。

C. Encode
Encode和encodeURI,encodeURIComponent归为一类。
这在下一节中进行比较详细的介绍。当浏览器提交数据给服务器时，特殊字符中文一般浏览器会自动编码，但存在部分保留字符，比如”# /”等，这时候需要encode等进行转换。
D. HTML实体
当网页中需要插入某些特殊字符时，需要用到HTML实体，比如插入<，可以使用&lt;或者实体编码&#60;。

三、Javascript URI编码/解码
A.为什么需要URI编码？
通常来说，之所以URI需要进行编码，是因为URI中有些字符可能会引起歧义或者有隐私的数据。
B. 编码与解码的函数？
JS对文字进行编码涉及3个函数：escape,encodeURI,encodeURIComponent，相应3个解码函数：unescape,decodeURI,decodeURIComponent
C. 如何选择？
首先，范围不同。Escape不能编码的字符有: @ * / +；encodeURI：! @ # $& * ( ) = : / ; ? + ‘ ； encodeURIComponent：! * ( ) 。
其次，编码类型不同。encodeURI、encodeURIComponent采用utf-8进行编码；而Escape采用系统编码。
所以，怎么选择？例如内容中要存在URI标识，则用encodeURI，如果想把”#，/”也要编码用escape或encodeURIComponent。

四、Ajax加载的文件中不能用中文？
　　这一直是让开发人员很头疼的问题之一，也是常见的编码问题，原因很简单，你非得拿羊城通往ATM上插，结果当然是读不出来或者读错。编码问题也是一样，通常出错的情况是，文档编码是GB2312，而浏览器以UTF-8(Ajax默认解码方式)来解码，自然乱码。
怎么解决呢？
1、文档采用UTF-8编码，不会产生任何问题。
2、如果不能用UTF-8，XML文档可以指定它的Encoding，JS文件和JSON数据目前没有好的解决办法。

五、GB2312，UTF-8都可以显示中文，如何选择？
　　可以显示中文的编码有GB2312、GBK、GB18030、Unicode。前三个保持向后兼容，比如“太平洋”这几个字在这几个编码规则中内码是一样的。它们的不同之处在于字符集不同，GB2312只包括简体中文，GBK还包括繁体，GB18030再加入了少数民族语言，比如藏文。那如果显示简体中文可以任意选择？据我目前测试了解，应该都是可以的，至于速度上是否有差异，还未深究，但GB2312肯定更为通用，而且据我测试已经包含了相当部分繁体。至于Unicode，应用在网页中的UTF-8，中文一般需要占据3个字节(前三种2个字节)，所以当中文较多的网页用UTF-8文件将变得更大(我们公司大部分网页4%左右)。

六、UTF-8、UTF-16、UTF-32什么区别？
　　Unicode所做的是为每个字符定义了一个相应的数字表示。比如，“a“的Unicode值是0×0061,“一”的 Unicde值是0×4E00，这是最简单的情况，每个字符用2个字节表示。 Unicode定义了百万个以上的字符，如果将所有的字符用统一的格式表示，需要的是4个字节。“a“的Unicode表示就会变成 0×00000061，而“一“的Unicode值是0×00004E00。实际上，这就是UTF32，Linux操作系统上所使用的Unicode方案。但是，仔细分析可以发现，其实绝大部分字符只使用2个字节就可以表示了。英文的Unicode范围是0×0000-0×007F，中文的Unicode范围是0×4E00-0×9F**，真正需要扩展到4个字节来表示的字符少之又少，所以有些系统直接使用2个字节来表示Unicode。比如Windows 系统上，Unicode就是两个字节的。对于那些需要4个字节才能表示的字符，使用一种代理的手法来扩展(其实就是在低两个字节上做一个标记，表示这是一个代理，需要连接上随后的两个字节，才能组成一个字符)。这样的好处是大量的节约了存取空间，也提高了处理的速度。这种Unicode表示方法就是 UTF16。一般在Windows平台上，提到Unicode,那就是指UTF16了。 而UTF-8更有意思，它的字节数1-4个不等，如果纯英文的应用环境，自然用它更加节省。

七、CSS、JS的编码可以和HTML不一致吗？
　　可以。但最好在引用时手动设置Charset，值得注意的是IE、FF默认根据当前页面编码，而Chrome默认是UTF-8。

八、我这人比较懒，直接给点建议吧。
懒得够可以的，好吧，那我想到几条写几条：
1、框架页不受父页面编码影响；
2、关于浏览器编码纠错。
测试：创建utf-8文件，更改meta charset属性为gb2312（文件本身数据编码不变），外链gb2312的JS文件，结论：
IE&Chrome自动以utf-8解析，外链JS乱码；
FF以gb2312解析，外链JS中文显示正常。Demo: 测试自动解析编码.html
3、Ajax加载，如果目标文档文件编码非UTF-8，需指定encoding，否则中文乱码；
XML是可以指定编码的，但如果是JSON，Script之类的数据，无法指定编码，要显示中文只有用UTF-8的编码；
4、外链的js，IE、FF默认根据当前页面编码，Chrome默认是Utf-8。如果JS文件为Unicode编码，给文件加上bom比较保险(IE、FF的智能识别)
5、Get数据，IE678，ff3 GBK编码，Chrome utf-8编码。
6、想完全避免它，如果条件允许，网站前后台数据库全部统一用utf-8吧，万事大吉，想碰到编码问题都难。
全部统一用gb2312？不行，问题照出，原因在上文中。

如蒙转载，请注明出处 cnwander.com

　　不知道大家是否玩桌球，常玩桌球的童鞋肯定知道，打好桌球，母球的控制最重要，当然要控制好它，这需要日积月累的练习，但是，如果你深入地分析过，你击球的位置和角度，对母球旋转，碰撞后路线变化的影响，了解了整个物理过程后，这将会让你事半功倍。

　　废了这么多话，其实还只说了文章第一句，你应该了解真相（轻点砸，嘿嘿）。每天与浏览器打交道的我们，如果对浏览器内核的实现了如指掌，那无疑，你将可以做出最优秀的页面。有童鞋可能要喷我了，能达到这水平我直接去开发浏览器了。是的，我们不可能了解到它的每一个细节，但是我们可 以大体地了解它，把握她的性情，摸清他的脾气。

　　目前，除了市场占有率最高性能最糟糕的Trident（IE内核），性能最棒市场占有最低（相对）的 Webkit（Chrome&Safari），常见的还有Gecko（FireFox）、Presto(Opera)。我们没这么多时间和精力， 也没必要逐个了解，因为它们干的都是同一件事，实现的手法大体一致。

　　下图还原了从请求页面到渲染完毕整个浏览器大体工作过程，可能有很多陌生的名字，Tokenizer、Parser、DOM Builder，没关系，我们只需要知道它是其中一个功能模块，我们只需要了解它干了什么。

名词解释：
　　JS宿主环境 - 如果JS运行在浏览器中，那宿主环境指浏览器相关的应用环境；如果运行在WSH（Windows Scripting Host）中，则是宿主为WScript。

如上图，从我们在地址栏输入url开始，浏览器的工作流程为：
1、DNS查找。通过DNS服务器，把你输入的域名转换成为网络可以识别的ip地址。
2、浏览器发起一个到指定端口的HTTP请求。
3、服务器响应后，开始资源加载。
4、解析获取到的文档流，并进行分析。
5、构建DOM模型。之后的大部分工作都基本围绕着DOM Tree进行。
6、合并已经读取到的样式，进行语法分析，合并，然后渲染引擎开始渲染。
7、如果期间碰到Script标签，或者由事件触发的，需要执行Javascript片断，渲染暂停，调用JS引擎分析并执行JS代码，执行结束，返回宿主环境数据。
8、OVER.

PS：上图中演示流程是一个反复循环的过程，浏览器在加载完一个代码片断之后即可以开始构建并渲染。

PS2：渲染与Javascript的执行也是一个反复交递的过程。

PS3：流程的分析相关知识，大部分来源浏览器相关开发者博客，以及Javascript开发资深人士书籍，和自己的实践总结归纳，大家有什么疑点大家一起研究探讨。

二、Javascript执行过程与运行期间环境。

　　常见JS引擎：SpiderMonkey（Firefox）、JavascriptCore（Safari）、V8（Chrome）、Jscript（IE）。
严格来说这里说的只是Javascript执行的流程，具体的Javascript执行过程，需另起篇幅与大家一起探讨。
　　先引用《Javascript语言精髓》上的一句话，可能更能加深理解。
　　”Javascript是一门设计得相对’原始’的语言……JS是一种通用的、跨平台和跨环境的语言，并不特指某种特定的宿主环境或者运行环境”

注：

本文参考文献：
周爱民《JAVASCRIPT语言精髓与编程实践》
李嘉昱 《Webkit 内核探究》

如蒙转载，请注明出处 cnwander.com

突发奇想的效果，主要突出构思，效果还比较粗糙，好好创意一下，应该可以引申出一些比较有新意的图片切换效果。
没什么特别的东西，思路自己看DEMO吧。

如蒙转载，请注明出处 cnwander.com

注：接受一些朋友意见，滚动事件绑定在“豆单”上了，有需要绑定在document或去掉滚轮事件的修改这段代码即可：

function attachWheel() {
if(document.all) ctrlBar.onmousewheel = thumbWheel; //将ctrlBar改为document即绑定滚轮事件到整个页面。
else ctrlBar.addEventListener("DOMMouseScroll", thumbWheel, false);
}


TIPs:
1、绑定滚轮事件
IE: document.onmousewheel = fuc;
FF: document.addEventListener(”DOMMouseScroll”, fuc, false);
2、图片加载
当图片已经在缓存中时，图片的onload事件在IE中无效
所以我作了如下处理
if(img.width > 0) fuc();
else img.onload = fuc;
3、设置元素透明度
function setOpacity(obj,n) {
obj.style.cssText = “filter:alpha(opacity=”+ n*100 +”); -moz-opacity:”+ n +”; opacity:”+ n;
}
4、Elements finder元素查找器
允许的格式：
$(”#id tag”)
$(”#id tag.classname”)
$(”#id .classname tag”)
$(”.classname .classname tag”)
$(”.classname tag”,domElement)
有兴趣的可以去看看DEMO这个函数 function $(s,wrap) {}
5、IE中的onmouseleave在FF中的解决办法
obj.onmouseout = thumbOut;
function thumbOut(e){
e = e || event;
var relatedTarget = e.toElement || e.relatedTarget;
while(relatedTarget && relatedTarget != this){
relatedTarget = relatedTarget.parentNode;
if(!relatedTarget){
slideTo(obj,”marginTop”,-toY);
}
}
}

坐标旋转的公式：
x1 = Math.cos(angle) * x - Math.sin(angle) * y;
y1 = Math.cos(angle) * y + Math.sin(angle) * x;

反坐标旋转：
x1 = Math.cos(angle) * x + Math.sin(angle) * y;
y1 = Math.cos(angle) * y - Math.sin(angle) * x;

稍作注意就会发现还存在很多问题，与真实桌球还有相当差距，慢慢改善吧，以后改用flash来作或许来得更流畅吧，欢迎大伙多提意见。

Tips:
1、IE: element.innerText = FF: element.textContent；
2、setAttribute(”cellpadding”,”0″)在IE中无效，正确写法cellPadding (一不小心就犯错了)；
3、FF中，使用绑定在某元素上的键盘事件前，先让它获得焦点，document也不例外，这容易疏忽；
4、在IE中create table element，记得加tbody；
5、想到再来编辑

“write less, do more.” JQuery的出现确实带给了我们太多的惊喜，它引发的是一场变革，把我们从过去那种繁琐和混乱不堪的局面中解救出来，让我们能够有更多精力专注于算法和功能本身。
　　但愈发强大的JQuery体积也不再小巧，55k(Minified)的大小虽然不能说很大，但如果用在一些小型项目或网站上，也不算小，那么我们何不根据自己项目特点，简化或改写JQuery呢，Follow me!

JQuery的核心代码：

以下是我简化的一个版本，供大家参考 (虽说是简化，但只是应用了Jquery这种模式，具体功能都是采用自己的方式去实现)
你可以转载此文，但请注明出处，谢谢 - wander