RFC 1738中对URL有明确规定，URL必须由英文字母、数字、和某些标点符号组成，不能使用其他文字，因此所有包含中文的URL都应当是非法的！其实，浏览器自作聪明的为我们做了很多人性化的hack，比如，浏览器会对地址栏中填入的url进行先编码再使用，因此，不论怎样，一个正确封装的http包中的URI字段一定不会出现中文字符。也就是说，实际发生作用的url也一定如RFC 1738中所言，非ascII码要先转换成ascII码序列，但RFC 1738没有规定具体的编码方法，而是交给应用程序（浏览器）和web程序作者自己决定。这导致“URL编码”成为了一个混乱的领域。也会导致一些奇怪的现象发生。
我们分别在firefox和ie用baidu和google搜索“淘宝”。
在firefox中百度“淘宝”，出现：
;)
实际发生请求的url为：
;)
同地址栏中显示是一致的，搜索结果也正确。在地址栏中直接输入“http://www.baidu.com/s?wd=淘宝”也是如此，在firefox中google“淘宝”：
;)
实际发生请求的url为：
;)
可以看到，实际发生请求的url和地址栏显示的url不一致，搜索结果正确。这时，重新请求地址栏的“url”（不是刷新），地址栏显示为：
;)
实际发生的请求为：
;)
这时，地址栏和实际发生的请求是一致的，搜索结果正确。进一步分析之前，先看看js里的两个运算
;)
我们知道escape()是计算unicode编码，传说中正统的URL编码encodeURI()则是进行utf-8编码，（简单讲，unicode编码是纯粹的编码方式，utf-8是unicode编码的一种实现，即将二进制unicode编码再编码，以一种比较节约空间的方式对unicode全集进行二次编码）。escape()的结果是将每个unicode字符以%u分割，encodeURI是每个字节以%分割，也就是说，“淘”和“宝”的unicode编码分别是“6DD8”和“5B9D”，他们的utf-8编码分别是“E6 B7 98”和“E5 AE 9D”，此外，他们的gbk编码分别为“CC D4”和“B1 A6”。
初步得到结论一：在firefox中的百度搜索，通过form提交的中文转换为gbk编码，参与http包的封装。在ff中google搜索，通过form提交的中文转换为utf-8编码，但显示在地址栏中的url是其中文映像（如果这时将地址栏复制下来，复制的实际是转码后的url，无法复制url中的中文字符）。如果直接在ff地址栏中输入中文url，这时，url里的中文字符一律进行gbk编码，不管百度还是google都是如此。
;)
复制不了里面的中文
如此看来，firefox默认处理url里的中文，都是通过gbk编码进行编码的，这里和网页编码无关（浏览器无法检测将要被访问的网页编码）。
那么，百度和google对unicode编码和utf-8编码的支持情况如何呢？
“淘宝”的unicode编码为“%6D%D8%5B%9D”，在ff中访问“http://www.baidu.com/s?wd=%6D%D8%5B%9D”
;)
搜索到乱码。“淘宝”的utf-8编码为（所谓正宗的“URL”编码）“%E6%B7%98%E5%AE%9D”，在ff中访问“http://www.baidu.com/s?wd=%E6%B7%98%E5%AE%9D”，得到，
;)
也是乱码。
再来看google能否解析utf-8编码，在ff中访问“http://www.google.cn/search?q=%E6%B7%98%E5%AE%9D”，得到，
;)
结果正确，google可以正确解析utf-8编码。再看google能否解析unicode编码，在ff中访问“http://www.google.cn/search?q=%6D%D8%5B%9D”，得到：
;)
是乱码。
初步得到结论二，所谓正统的URL编码encodeURI并不是万能的，要看每个网站的实现，百度搜索就不支持这个所谓正统，而是一律采用gbk系的编码作为自己的URL编码。google支持“正统URL编码”，也支持gbk系的编码，更健壮一些。
再来看IE中的情况，在ie中在百度和google中通过form搜索“淘宝”结果和ff中一致，但直接在地址栏中输入中文url就有些奇怪了，在ie中访问“http://www.baidu.com/s?wd=淘宝”，得到，
;)
结果当然正确，实际发生的请求为
;)
这里可以看到，ie发起的http请求甚至没有经过任何编码，硬生生的将“淘宝”当作原始gbk字符，这样，其他语言编码的操作系统就无法识别这个url，这里的“\314\324\261\246”是一种我也不知道是什么东西的编码，甚至连wireshark都不知道，因为“http://www.baidu.com/s?wd=\314\324\261\246”明显是一个错误的请求。
此外，unicode编码和utf-8编码后的url在ie下的表现和ff中一致。
由此，可得到结论：
1，RFC 1738文档很粗糙，导致了url编码标准缺失。实际url编码标准和操作系统、浏览器以及web应用有关；
2，ff对非ascII码的url进行编码，编码方式和操作系统默认编码一致
3，google支持“正统的URL编码”（即utf-8 URL编码：utf-8字节中间加上%），百度不支持
4，IE不对非ascII码的url进行编码，直接根据操作系统默认编码发送url请求，换句话说，ie甚至不遵循RFC 1738，或者说ie对URL的转码实现有bug。
5，ff在地址栏显示的url进行了hack，但hack的有bug，开发时要注意。
基于此，我们在web开发过程中要做到：
1，要单独处理编码问题，建议采用统一的URL编码，不论是gbk还是unicode还是URI（utf-8），必须要统一，鉴于大多数人稀里糊涂的认为URI是正宗的URL编码，因此建议还是在前后端都做URI编码和解码。
2，明智选择web app的编码，utf-8为最佳，gbk为最次。
3，编码问题要调试浏览器兼容性。
以上～
附：
中日韩unicode字符集
gbk字符集
[ view entry ] ( 1057 views ) | permalink |
( 2.9 / 220 )使用ie开发调试时，在有异步交互的时候，有时会遇到“Automation服务器不能创建对象”的错误，ie给出的错误消息是如此之模糊，以至于很难定位问题的真正原因。通常，这个问题的产生十有八九是ajax的问题，网上大多数的解释归咎于客户端和浏览器，说是要把ie的安全级别调低或者注册msxml组件什么的，其实windows中解析xml的组件在安装系统的时候已经安装，差别只是版本高低，而在js中创建ActiveX对象的时候则需要指定xml解析器的版本，指定版本错误就创建对象失败，再使用这个创建失败的对象的时候，就会出现“Automation服务器不能创建对象”的错误。
在yui2.x中，connection里对IE浏览器中使用的XML组件版本定义了三个而已，Microsoft.XMLHTTP、MSXML2.XMLHTTP.3.0和 MSXML2.XMLHTTP，这样基本可以涵盖大多数情况：
YUI2.x中定义的xml解析器版本
YAHOO.util.Connect = {
_msxml_progid:[
'Microsoft.XMLHTTP',
'MSXML2.XMLHTTP.3.0',
'MSXML2.XMLHTTP'
],
//...
}但这仍然不能包含所有可能情况（似乎在早期的盗版xp中会经常出现“Automation服务器不能创建对象”的错误，具体细节我没有考证过），在yui3的io组件中，只留下了一个'Microsoft.XMLHTTP'：YUI.add('io-base', function(Y) {
function _xhr() {
return (w.XMLHttpRequest) ?
new XMLHttpRequest() :
new ActiveXObject('Microsoft.XMLHTTP');
}
//...
};隐患仍然存在，应当将所有xml解析器的版本都补充上，才更加严谨一些，基于此，就可以写一个严谨的创建ajax对象的函数：var InitAjax = function(){
var ajax;
if(window.ActiveXObject){
var versions = ['Microsoft.XMLHTTP',
'MSXML.XMLHTTP',
'Microsoft.XMLHTTP',
'Msxml2.XMLHTTP.7.0',
'Msxml2.XMLHTTP.6.0',
'Msxml2.XMLHTTP.5.0',
'Msxml2.XMLHTTP.4.0',
'MSXML2.XMLHTTP.3.0',
'MSXML2.XMLHTTP'];
for(var i=0; i <versions.length; i++) {
try {
ajax = new ActiveXObject(versions[ i ]);
if(ajax) {
return ajax;
}
} catch(e) {}
}
}else if(window.XMLHttpRequest){
ajax = new XMLHttpRequest();
}
return ajax;
};如此，才能够确保ajax的万无一失。以上～
[ view entry ] ( 14046 views ) | permalink |
( 3 / 197 )上一篇jQuery Selector VS YUI Selector.
不得不承认，自从john将Sizzle从jquery抽离出来，性能得到了大幅度提升，这得益于分层设计所带来的重用率的提高。sizzle简洁曼妙的实现使得jquery有一个强劲的选择器核心，不同于jquery结构混乱的外衣，sizzle却出奇的整洁。然而这种不可避免的抽离一步步将jquery带进万劫不复——jquery羸弱的结构将不足以支撑更多层次的抽离。但sizzle近乎冲动的整洁，也使得dojo、prototype受益匪浅，但yui对于sizzle，却似乎一直在保持某种不必要的警惕。是什么导致yui team最终放弃sizzle来做yui的selector核心呢？
YUI3发布之日yuiblog概要低调的介绍了yui3的4个亮点：
1. Selector-driven: YUI 3 is built around one of the lightest, fastest selector engines available, bringing the expressive power of the CSS selector specification into actions that target DOM nodes.
2. Syntactically terse: 简洁。
3. Self-completing: 动态合并。
4. Sandboxed: 沙箱。
其实2，3，4的确言如其实，第一个，选择器驱动，很容易让大家误解，相比jquery，这个亮点一点也不亮？简单比较下yui3和jquery的选择器引擎。
;)
可以看到，yui把原本简单的事情搞的更加复杂，选择器就是选择器，还分什么css2、css3和native？相比更加认真仔细的sizzle，yui的selector engine却更难看粗心：不仅留下来上篇提到的那么多bug，性能还显而易见的不够优化（既然使用全局正则为什么不先编译再匹配呢？）。因此yui的selector engine只是为了让代码看上去更加“yui3”而强行拆分。倒不如一个hash table来的痛快。yui小组一直在理想的构思web app的宏伟蓝图，因此目前yui3这种模块拆分也一定不是最优，毕竟缺少复杂web app的实践积累，所以yui3在不断的使自己“面向未来”，也让自己一点点脱离实际。当下对web开发的迫切需求是速度、性能、扩展性、团队开发！yui3在扩展性和团队开发方面得了高分，jquery则着重优化前两方面。“面向未来”的无敌框架 vs “面向实际”的简洁快速，在选择器引擎的设计上，隐约可以窥见双方似乎不可调和的性格冲突：yui是一帮中老年人老学究式的理想寄托，外表朴实内心却充满着理想主义者的叛逆，固执古怪的把代码写的抽象，而从sizzle身上我们看到年轻的john已经长大，虽然在john年少的时候并未严谨构思jquery的结构导致目前jquery越发臃肿不堪，但jquery所蕴含着的冲动与活力依然感染者依然年轻的web开发领域和大量初学者。
如此看来，似乎比较选择器的树优孰劣已经意义不大，每个人都有选择的权利，但，明智的选择一定是在充分的了解基础上做出的。切忌人云亦云、随波逐流，别人说哪个好就用哪个。yui selector和sizzle都是基于特定的场景特定的理论的产物，也只有将其放在作者期望的上下文环境中，才能发挥各自的优势，我们要学习的则是他们的设计思想，以及设计思想背后的理论基础，这才是表象背后的本质所在。
[ view entry ] ( 504 views ) | permalink |
( 3.1 / 209 )第一讲，The Early Years
从史前社会讲到计算机的诞生，再到编程语言的进化，编程语言一直按照老道的进化论进化，直到javascript诞生，雷。。。
第二讲，And Then There Was Javascript
开始讨论javascript的生老病死，宇宙大爆炸->人类诞生->javascript诞生，再雷。。。
相当科普，相当精彩，更多演讲依然期待中。。。。
[ view entry ] ( 336 views ) | permalink |
( 3 / 220 )淘宝小说站终于赶在年前上线了,无大功也无大过：
;)
1，首页的幻灯应用了Cubee的Y.Slide，很顺手
2，cubee-js做了一些bug修复，只等taobao cdn的combo
此外并无亮点，且前端性能不怎么样。
第一次认真的做项目计划，发现做计划不难，费劲的是项目的适时跟踪，尤其是参与的人越多的时候，既要保证前后端工程师的demo一致性，也要适度控制需求变更的影响，以及在必要的需求变更后作出计划推迟调整。在前端方面，如果UI风格统一且确定、交互模式固定且设计完整、WD做demo的速度其实很快，后端工程师在逻辑和底层完成后即可将数据对应输出至demo上，如果数据正确，按照既定UI、交互逻辑和基本数据正确性进行测试，前端方面不会出现太多问题，顶多帮后端工程师解决一些套页面的问题，诸如丢标签，嵌套不对，a链接没有title，图片没有tip等等。如此项目应当十分顺利。实际情况中却出现了多次计划推迟的现象，尽管整个项目还是在预定日期内上线，但其间作出了用户体验上大量的牺牲和妥协，这些障碍主要在这些方面：
1，需求评审仓促：
从开发量上看，淘宝小说站不能算一个太大的项目，顶多算一个中型项目，一个迭代的周期也不超过1个半月，但产品和设计过于担心项目中后期的不确定性带来的延迟，迫切的希望尽早拿出需求草稿并进入设计和开发，在这样一个前提下，似乎都没有太多时间和精力去琢磨需求设计的细节，就已经进入开发了。
2，小问题滚成大问题：
很多从设计角度看起来很小的问题，如果不及时确定，会滚雪球一般，到最后滚成大问题。
3，无文档、无真相
其实不论是UI、还是demo都是和交互设计师和视觉设计师确认后才丢给后端工程师去套页面，但实际情况中，项目中后期和测试阶段，仍然有不少零碎的UI调整，很烦人。
需求的不确定、或者需求确定却修改频繁、UI的不确定、或者是UI的确定却修改频繁是导致项目延期的一个重要原因。严格的瀑布只会让开发成为瓶颈和关键路径、迭代和敏捷也是如此，但这种情况只有在可控的需求变更的基础上才可能实现。因此，如此看来，我们的cmm甚至连初级都达不到，那么。。。
或者在整个web行业，cmm规范一直都在初级晃悠。如此看来，互联网产品的开发甚至还不能算真正意义上的软件开发。
还是那句话，web领域很年轻，流程和规范从无到有总会有一个过程，高端的产品一定是在高级别的cmm等级中产生，这时，技术和需求已经不是主要的产品驱动力了,因为高端的产品需要高端的技术，高端的技术需要容纳高端技术的土壤。
以上YY～，切勿当真～
============================================
今天年前最后一天蹲班，仿照http://www.mushroomdigital.co.uk的cutter特效，自己做了一个demo，类百叶窗的特效，
demo here
[ view entry ] ( 750 views ) | permalink |
( 3 / 216 )
