Thinking for Fun » Browser http://jsfox.cn/blog 网络 ● 生活 ● 技术 Tue, 01 Jun 2010 01:52:41 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 理清URL编码 http://jsfox.cn/blog/learning/understand-url-encodin.html http://jsfox.cn/blog/learning/understand-url-encodin.html#comments Mon, 31 May 2010 11:05:23 +0000 yongbin http://jsfox.cn/blog/?p=187 URL中，什么字符需要编码？

关于URL编码，RFC1738做了如下的规定：

“Only alphanumerics [0-9a-zA-Z], the special characters “$-_.+!*’(),” [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.”

RFC继而说明了保留字、特殊符号、不安全字符的含义——也就是说，下面三类字符可以不经过编码，直接出现在URL上：

  • [0-9a-zA-Z]
  • 特殊字符：$-_.+!*’(),
  • 保留字符：&/:;=?@

为了让我们思路更清晰，我们再总结一下，哪些字符必须要编码：

  • ASCII表中没有对应可显示字符的，例如汉字
  • 不安全字符，包括：#”%<>[]{}|\^`~
  • 不当做保留字符来使用的保留字符，即&/:;=?@

详见这张图，一目了然（点击看大图）：

URL编码在ASCII表中的体现

URL编码在ASCII表中的体现

如何编码？

众所周知，字符是可由八位字节数（octet）来表示的，八位字节数可用十六进制来表示它的值。如字符“<”的八位字节数十六进制值是3C。在URL中，字符的编码方式为：“%”加上字符的两个十六进制数值。举几个例子：

  • “<”可以被编码为%3C，空格“SP”可被编码为“%20”
  • “田”的GB2312编码十六进制值是CC EF，这时“田”的URL编码为%CC%EF
  • “囧”的GBK编码十六进制值是87 E5，这时“囧”的URL编码为%87%E5
  • “田”的UTF-8编码十六进制值是E7 94 B0，这时“田”的URL编码为%E7%94%B0

URL中包含汉字时的更多话题

RFC1738没有规定汉字的编码方式，而是让浏览器自己去决定，因此造成了URL汉字编码的不统一。经过研究，对于URL中的“查询字符串”和“路径”中包含汉字，不同浏览器有不同的处理。

1. 查询字符串中包含汉字

在网址输入：http://www.baidu.com/s?wd=田囧 ，敲击回车，使用Fiddler观察浏览器发出的请求（以IE8和Firefox为例）：

查询字符串中含有中文

查询字符串中含有中文

IE8将汉字作为GBK编码，直接发往服务器（这其实是不符合RFC规范的）；Firefox则多了一次加%的操作。Windows操作系统是GBK编码。得到结论，地址栏直接访问URL，汉字作为查询字符串(Query string)时，IE和Firefox会使用系统编码发至服务器端，Firefox会按规矩编码。

注意1：不要用Google进行测试，Google的搜索URL（类似：http://www.google.com/#hl=en&source=hp&q=田囧 ），搜索关键词那里不是查询字符串，因为前面有个#……我开始没注意到，被搞迷茫了很久……

注意2：这只是对URL直接访问的规律。如果页面时从链接点击打开的，例如从A页面含中文的链接打开了B页面，那么浏览器对中文的编码取决于A页面的编码。

2. URL路径中包含汉字

在网址直接输入：http://www.hudong.com/wiki/田囧 ，敲击回车，观察请求：

路径中含有中文

路径中含有中文

IE8和Firefox都把汉字作为UTF8，按规范进行了URL编码，还好。

总结

什么字符应该编码，什么字符不用编码，URL编码的基本问题，到此已经解决啦。

]]> http://jsfox.cn/blog/learning/understand-url-encodin.html/feed 4 HTML5 历史、现状及未来 http://jsfox.cn/blog/others/html5-history-and-future.html http://jsfox.cn/blog/others/html5-history-and-future.html#comments Tue, 20 Apr 2010 11:31:38 +0000 yongbin http://jsfox.cn/blog/?p=179 分享一下HTML5的东西。

HTML5 历史、现状及未来

View more presentations from Yongbin Tian.

]]> http://jsfox.cn/blog/others/html5-history-and-future.html/feed 0 Even Faster Web Sites: 读书笔记(二) http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html#comments Sun, 24 Jan 2010 08:54:18 +0000 yongbin http://jsfox.cn/blog/?p=170 这次因为一个项目的原因，又重读了《Even Faster Web Sites》书里的第四章：Loading scripts without blocking，并且在Cuzillion里做了大量测试，又发现了很多有意思的细节。发现自己读书太糙，自责一下。结合实际工作，加上自己的理解，再把这一章的实用内容总结一下。

要解决的问题

页面的script标签引入外部js文件时，会阻塞后续外部资源的下载和加载，包括图片、CSS文件、iframe等等。

1. Script DOM Element比较常用

“Script DOM Element”方法是常见的方法，也就是createElement(“script”)的方法下载js文件，以此并行加载后续资源。这其实是很棒的一个方法，因为不需要担心跨域，而且我们在中文应用中，不用担心编码的问题（可以为<script>指定编码）。但这里需要注意的是，非IE浏览器下，这种方法会阻止window.onload事件，因此如果你的js文件很大，可能会带来用户体验不好。IE浏览器对这种贴script标签的行为是“无动于衷”的，不会在状态栏、光标和进度圈上做任何指示。看来IE也不是一无是处嘛，哈哈！测试地址。

2. 个人不提倡使用XHR Eval

XHR Eval方法我不提倡使用，首先是中文编码上会遇到麻烦，其次跨域问题。另外就是下面这句：

eval(xhrObj.responseText);

当js文件比较大的时候，用eval会相对较慢，并带来安全性隐患。

3. XHR Inject是个好东西

如果编码和跨域问题都不是问题，那么XHR Inject就是最好的方法了。这是XHR Eval和DOM Script的一个这种办法，实现机制就是：

var s = document.createElement('script');
s.text = xhrObj.responseText;

这种方法避开了evil eval，并且和DOM Script一样，可以按顺序加载js文件，当然，不会阻塞后续资源的加载。更为重要的是，在所有浏览器下，这种方法都不会阻止渲染和onload事件，体现了XMLHTTPRequest的本色。测试地址在此。

4. defer属性可以快速尝试

Script标签的defer属性，可以让后续资源并行加载。在实际的项目中，偶尔也可以尝试使用，因为比较快捷。Firefox 3.1以后，也开始支持script的defer属性啦。

5. document.write(“a.js”)的注意事项

注意：在<head>用document.write来插入js脚本，只能让浏览器并行加载<head>里的资源。也就是说，<head>里write脚本，会阻塞<body>的加载。测试地址。另外关于document.write，还有两个需要注意的问题。第一，它只能带来“并行加载js文件”的效果，对其他资源无效；第二，IE、Chrome支持，Firefox不支持。

6. Script in Iframe方法强烈不赞同

在iframe放js，来实现页面资源并行加载，无疑是得不偿失的行为。首先，iframe太沉重了；其次，你还得改你的js代码。反正我是不能接受的，哈哈。

结束语

在开发中，如果要加载数个js大文件，比较实际的做法还是插入script标签的方法。如果没有编码和跨域问题，用XHR Inject方法当然更好啦。

欢迎指正！

]]> http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html/feed 0 JavaScript调试技巧之：断点调试(1) http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html#comments Mon, 03 Aug 2009 16:26:00 +0000 yongbin http://jsfox.cn/blog/?p=77 如果您还没有阅读《JavaScript调试技巧之：快速定位》，建议先看看那篇。说不定，用快速定位就能解决问题了，呵呵。这次我会总结记录一下断点调试的笔记，希望也对大家有用，欢迎补充交流！

首先，在各个浏览器中，断点调试支持的最好的当然是Firefox，Firefox不仅可以使用Firebug调试页面js脚本，还可以用高级调试工具例如JavaScript Debugger (Venkman) 来调试Firefox扩展里的js。除此之外，Firefox还支持一些更为高级的断点调试、变量监视功能。

其他浏览器里，Opera、Chrome和Safari的调试功能也比较好用。Opera的DragonFly速度相对比较快，界面清爽，功能强大，但不如Safari等友好。相比来说，IE8的程序员工具简直没法用。

这次时间有限，先来总结一下Firefox下的调试技巧。

1. 使用Firebug进行断点调试

使用Firebug调试JavaScript非常方便。具体步骤：

a. 打开Firebug后，启用“脚本”调试，找到引用的脚本文件（或者行内js）；

用Firebug找到要调试的脚本（点击放大）

用Firebug找到要调试的脚本（点击放大）

b. 在适当的位置加入断点；

c. 如果断点已经执行过，则刷新页面，这时脚本就会在断点处中断。如果断点没有执行过，那可以直接执行页面上的动作（例如点击按钮等），然后代码会在断点处中断；

用Firebug进行断点调试

用Firebug进行断点调试（点击放大）

d. 观察函数调用栈，观察local变量，也可以进行单步执行，进行调试。

确实非常简单！用Firebug断点调试的优点总结如下：

  • 能加断点的行用绿色行号，非常直观；
  • call stack用两种方式显示出来，很方便；
  • 本地变量的显示非常清晰明了。

2. 使用JavaScript Debugger进行断点调试

这是老牌的调试工具，之前叫做Venkman，可以以扩展形式安装在Firefox上，我们在这里就称他为Venkman吧。它不仅能够调试页面脚本，还能调试Firefox扩展（extension）里的js。我们在做Firefox扩展开发时，Venkman是必不可少的工具，老田强力推荐！当然，Firefox本身的逻辑实现，也是用JavaScript来做到的。我们现在可以用Venkman来调试一下Firefox本身。Firefox的核心js是browser.js，在这个路径下：

chrome://browser/content/browser.js

我们打开Venkman之后，在Loaded Scripts里填入browser.js，这个js文件就会被过滤出来（如果没有看到browser.js，那么你可能需要查一下是否选上了Debug->Exclude browser files）。

Venkman：选择要调试的js文件

Venkman：选择要调试的js文件（点击放大）

我们找到让浏览器后退的代码，然后点击Firefox的后退按钮，这时Venkman就会停在BrowserBack方法上！让我们再一步一步地看一看，Firefox自己到底做了什么。btw，实现Firefox的js代码也不是很漂亮嘛~~~

用JavaScript Debugger调试Firefox

用JavaScript Debugger断点调试Firefox（点击放大）

Venkman当然也带有一个console，利用这个console，我们可以看一看浏览器层次的window和document都是什么东西。类似于Firebug和其他浏览器的console，只要直接输入js代码片段即可！

使用Venkman自带的console

使用Venkman自带的console（点击放大）

有兴趣的话，可以在这里发现更多有关Firefox开发（以及扩展开发）的好玩的东西！

3. 使用debugger在程序中加入断点

另外还有一个少为人知的断点加入方法。我们可以在程序中加入debugger语句，这样Firefox的调试工具会停留在这条语句上，代码也暂停执行，和加入断点的效果一样。例如：

var myfunc = {
    get_field_value_callback : function() {
        debugger;
        var ed = this, target = ed.currSpan;
        /* do something more */
    }
}

这时重新加载页面，断点就会停留在debugger语句上。这样，我们就可以在写代码时随心所欲地加入断点了。另外，其他浏览器（包括IE8！Surprise！）同样支持debugger语句！

]]> http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html/feed 2 Web应用程序的beta精神 http://jsfox.cn/blog/javascript/is-your-web-app-beta.html http://jsfox.cn/blog/javascript/is-your-web-app-beta.html#comments Thu, 09 Jul 2009 14:59:38 +0000 yongbin http://jsfox.cn/blog/?p=61 Gmail的logo上终于没有了Beta字样，于此同时，Google Calendar，Google Docs也脱离了beta。Gmail长达七年之久的开发与测试终于结束。

Gmail最初设计稿的其中一张

Gmail最初设计稿的其中一张（图片来源：TechCrunch）

从2004年的愚人节到现在，Gmail一直beta着。在此期间，Gmail小组又加入了很多创新性、革命性的东西在里面。例如加入了Gtalk，让大家在网页上聊天，甚至后来在网页上视频通话；加入了pop邮件的功能；使用long polling来实时获取新邮件；创新性地用标签，而不是文件夹来分类邮件。这些都是之前的网页开发者很难想象、很难做到的。

不过，更值得一提的是web应用程序的beta精神。Web App和桌面程序不同，有很多因素会影响其稳定性。例如网络环境，例如浏览器的兼容性和浏览器设置等等。事实上JavaScript本身就是一个设计上存在缺陷的语言，浏览器对它的支持也不尽相同，而CSS在不同浏览器下的差异更是让我们费尽脑子。这些因素都让我们无法理直气壮地说自己的web程序没有问题。一个复杂的网页程序，在Firefox下运行正常了，你敢说在IE5.5下运行也正常？你敢说在Konqueror下显示和运行都没有问题？大概正因如此，Gmail一直都没有脱离beta。也就是说，上个世纪的浏览器大战造成的兼容性问题，折磨了Gmail整整7年啊。

关于对浏览器的支持，Yahoo!有他的GBS表，也就是Graded Browser Support，很被国外的开发者认可（btw前一段时间刚刚drop掉了IE6 on Windows2000，让我倍感欣慰，说明XP下也不远了！）。

YUI Graded Browser Support Chart

YUI Graded Browser Support Chart

（ 图片来源，Yahoo! UI Library）

我认为可以用这个表格当作一个web程序可称为正式版的参考。不知道Google是不是也用的这个表格，或者有一个类似的chart。无论如何，Gmail beta 5年告诉我们，一个web应用程序，想要说自己是正式版，很难。

]]> http://jsfox.cn/blog/javascript/is-your-web-app-beta.html/feed 1