有时候我们会遇到这样的情况：在一些前端控件要提交数据到服务器端的数据验证过程中，需要判断提交的数据是否为空。如果是普通表单的字符串数据，只需要在 trim 后判断 length 即可，而这里需要的数据可以是各种不同的类型(数字、字符串、数组、对象等等)，通过 JSON.stringify(data) 进行序列化后再传递。

在这里定义如下的数据值为“空值”：

• undefined
• null
• 空字符串及纯空白字符串：''、'    ' 等。
• 空数组：[]
• 空对象：{}

对于除此以外的数据值，均认为不为空。

其中 null 和 undefined 很容易识别，但对于其他类型，我们须要得到其数据类型才能用相应的方法去检测数据是否为空。最容易想到的方法就是利用 typeof 操作符：

1
2
3

if(typeof data === 'number') {
  //deal with numbers
}

但 typeof 返回的类型字符串只有 'object'、'function'、'number'、'boolean'、'string'、'undefined' 这六种，很多原生对象如 Date、RegExp 对象无法与用 {} 创建的对象进行区分。另外，typeof 对于一些基本数据类型如 (String、Number、Boolean) 与其对应的基本包装类型数据会分别返回不同值，如：

1
2
3
4
5
6

console.log(typeof false); //'boolean'
console.log(typeof new Boolean(false)); //'object'
console.log(typeof 1); //'number'
console.log(typeof new Number(1)); //'object'
console.log(typeof ''); //'string'
console.log(typeof new String('')); //'object'

这对我们的判断也有一定的影响。

用 instanceof？这只能判断对象，而且存在多 frame 时多个同类对象不共享 prototype 的问题，从其他 frame 中取得的对象无法正确判断。

还好，还有一个最简单也最可靠的方法：Object.prototype.toString。对于不同类型的数据，这个方法可以返回 '[object Object]'、'[object Array]'、'[object String]' 这样的字符串，非常方便判断。需要注意的是，在 IE8 及其以下浏览器中，这个方法对于 null、undefined、window 等都会返回 '[object Object]'，不过还好，这并不影响我们使用它判断空对象。

下面直接上代码，说明就看注释吧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// with jQuery
var isEmptyValue = function(value) {
    var type;
    if(value == null) { // 等同于 value === undefined || value === null
        return true;
    }
    type = Object.prototype.toString.call(value).slice(8, -1);
    switch(type) {
        case 'String':
            return !!$.trim(value);
        case 'Array':
            return !value.length;
        case 'Object':
            return $.isEmptyObject(value); // 普通对象使用 for...in 判断，有 key 即为 false
        default:
            return false; // 其他对象均视作非空
    }
};

对于不同 value 值，我做了个测试，看看对于不同值分别取 Object.prototype.toString、typeof、isEmpty 的结果。测试结果可以到下面这个地址围观：
http://jsfiddle.net/Justineo/hFKRt/

除了 IE8 及其以下浏览器外，其他浏览器结果基本一致，下面就贴下主要的 2 种结果吧。下图为 Firefox 下的结果，而在 Chrome 下，window 字符串化后的结果是 'object global'，和 Firefox 下稍有不同，但在判断空值时问题不大。

Firefox 下的结果

IE8 及以下唯一会误判的是 alert，不过这对于数据验证来说应该也可以接受。

IE8 及以下的结果

这几天在项目中遇到的问题，稍微整理一下。

HTML 表单是我们常用来进行浏览器与服务器数据交互的途径，除了传递普通的文本数据，通过 type="file" 的 input 控件，我们还可以向服务器发送文件。但在目前的实际使用中，基于 HTML 表单的文件选择框有着下面两个不尽人意之处：

1. 一次只能选择一个文件
2. 上传过程中，不能获取文件上传的进度

对于文件选择的数量，事实上在 HTML4.01 规范中对文件选择框的描述虽然没有明确提出可以同时选择多个文件，但从其用词可以看出，文件选择控件事实上是应该支持同时选择多个文件的：

This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control.

可以看见，“文件”一词使用的是复数形式。同时，RFC 1867: Form-based File Upload in HTML 的 3.3 节中，也有这样的描述：

If multiple files are selected, they should be transferred together using the multipart/mixed format.

说明文件选择框应当能够处理同时选择多个文件的情况。但需要注意的是，这个描述出现在这篇规范文档的 3. Suggested implementation 章节中，仅仅是建议的实现方式，所以除了以前有几个版本的 Opera 曾经支持过多文件选择，其余浏览器都仅仅实现了单个文件的选择功能。

为了解决这个问题，HTML5 中进行了明确，带有 multiple 属性的 input 控件将可以有多个取值，自然也包括文件选择框。但这不是今天说的重点，目前的困境还是摆在我们眼前的。

对于文件上传的进度，就更不好办了：一是文件上传本身就无法使用 AJAX 来进行页内无刷新上传，需要使用隐藏 iframe 来实现。而获取上传进度还得依靠 AJAX 向服务器端发送请求来获取，利用的手段可以是 AJAX 轮询、iframe + htmlfile 甚至是 WebSocket，但本质上做的事情都有违常理：浏览器自己发送了多少内容，却需要一遍遍地请求服务器来进行告知。其次，由于文件上传和进度查询采用的是不同的数据通道，还得使用额外数据来维护两者之间的联系，显得非常繁复。

好了，说了那么一大段就是为了引出目前使用 Flash 来进行文件上传的原因。目前我们项目采用的是 SWFUpload 这个 Flash 文件上传工具，支持文件批量选择，并且可以方便地进行上传进度的查询。但是在我们的项目的之前版本中，当页面需要使用 session 中的用户信息时，却无法在 Firefox 下使用它进行正常的文件上传。

在 IE 下，上传工具能够工作，而一到 Firefox 下，SWFUpload 就会提示错误 302。通过从 Fiddler 抓包，发现上传文件的请求被 302 重定向到了登陆页面，所以无法正常上传文件。也就是说，之前用户登陆后的 session 信息在 Flash 发送的上传请求中丢失了。再一看请求的 header，当中没有可以用来标识当前 session ID 的 cookie 值(对于 J2EE 为 JSESSIONID，PHP 为 PHPSESSID 等)。这是什么原因呢？经过一番搜索，找到了 Adobe 官方的一篇文章，说道：

A FileReference.upload() currently does not use the same cookies as your browser session if you are using Firefox (on Windows). In such cases, cookie information has to be inserted manually.

好吧，这个解释虽然很清楚地表明，Flash 在 Firefox 下进行文件上传不会使用浏览器 cookie 中的 session ID，但是貌似并没有回答文章标题当中的“为什么”，即为什么不使用和浏览器中的 session ID 来进行通信。

看来 cookie 是指望不上了，那只能像上面说的那样“手工”传递 session ID 了。于是我们可以在 URL 中拼接一个如 ";jsessionid=blahblah" 的字符串(注意要拼在路径之后，参数之前)，像下面这样：

http://example.com/app;jsessionid=blahblah?q=blah

按Servlet 规范 7.1.3 节中的规定，当客户端不接受 cookie 时，Servlet 容器应当能解析出这类 URL 中的 JSESSIONID，来维持当前 session 的状态。其他服务器端环境中也有类似的机制。于是我们对文件上传功能做了一定的修改：在用户进入上传页面时，就把当前的 session ID 写到页面中，作为 JavaScript 变量拼接到 SWFUpload 上传文件的目标 URL 中，Flash 就可以利用我们人工传入的 JSESSIONID 来维持登陆状态了。当开始上传时，Flash 通过自己的连接通道向服务器发送数据，但是因为请求的路径中包含了 session 信息所以可以和浏览器的 session 状态保持同步，服务器可以通过 URL 中的 session ID 来获取用户登录的信息。

于是，302 错误被解决了，看起来一切都 OK 了。可是，不久我们又发现了新的问题：当用户打开上传页面后较长时间没有操作，服务器端的 session 超时了，这个时候进行文件的上传用的还是超时的那个 session ID，所以会失败也是应该的。但是当这个时候用户重新进行了登录，再次进入上传页面上传，却仍然会失败，只有重新启动浏览器才能再次进行上传。这是为什么呢？从服务器端错误来看，还是用户的登陆信息丢失的问题，也就是说，Flash 在上传文件时，还是没能将用户进行过登陆的这个 session ID 成功传递给服务器端。通过在 Fiddler 中抓包分析，终于找到了原因。下面几张示意图大致描述了这个问题产生的过程：
登陆后 Flash 第一次进行上传时，自身没有 JSESSIONID 这个 Cookie，所以使用手工拼接到请求 URL 中的浏览器 JSESSIONID 即 XXX 进行提交，服务器解析出了 JSESSIONID 并且在内存中找到了其对应的 session 信息，成功进行了身份验证，最后返回上传成功的信息。

然而当 XXX 这个 session ID 超时以后，Flash 仍然以刚才重写过的 URL 发送请求(图中[1])，服务器解析出 JSESSIONID 后发现已经没有 XXX 这个 session 了，于是重新创建了一个 ID 为 YYY 的 session(图中[2])，并且在返回的响应中除了登陆失败的信息外还加入了 SET-COOKIE:JSESSIONID=YYY 的请求头(图中[3])。于是这时在 Flash 的 LSO (“Flash cookies”) 中却把这个不带用户登录信息的 session ID 保存了下来。

发现登陆超时后，用户重新登陆，在新的 ID 为 ZZZ 的 session 中留下了有效的登录信息，进入上传页面后，生成了新的拼接 JSESSIONID 的 URL 传递给 Flash 控件，此时进行上传时， Flash 发送的请求既包含了 URL 中的 JSESSIONID，也带了 Cookie 请求头中的 JSESSIONID(图中[1])。按 Servlet 规范，当请求有 Cookie 头中的 JSESSIONID 时，URL 中的就被忽略了，于是服务端判断此请求应该在 YYY 这个 session 中进行处理(图中[2])，于是导致了用户看似已登录，Flash 请求却使用了另一未登录的 session 导致上传失败。

所以，要让 Flash 能够正确使用 URL 中指定的 session，就必须防止 flash cookies 中记录 JSESSIONID 值。如果 Set-cookie 头是 Web 服务器或 Servlet 容器自动加上的，那就需要我们在 Web 应用中将对应的 Cookie 值删除。下面以 Java 代码为例，我们可以通过添加一个名称同样为 JSESSIONID 的立即失效(通过设置 Max-Age=0，参见RFC 2109: HTTP State Management Mechanism 的 4.3.3 节)的 Cookie 来覆盖之前的值：

1
2
3

Cookie cookie = new Cookie("JSESSIONID", "");
cookie.setMaxAge(0);
response.addCookie(cookie);

这样在 session 超时时，上传文件失败返回的请求中会带这样的头：

Set-cookie:JSESSIONID=YYY;
Set-cookie:JSESSIONID="";Max-Age=0

于是在 flash cookie 中 YYY 这个 JSESSIONID 刚刚被设置就被清除了，在重新登陆后 Flash 发送的请求就不会带有 Cookie 头，不会覆盖 URL 中设置的值了。

总结一下，虽然这个过程说起来挺复杂，但解决方法还是比较简单明了的：

1. 在上传文件的目标 URL 中显式传递 session ID；
2. 在处理上传的应用代码中，当发现无登录信息的 session ID 时，不发送 Set-cookie 头或在应用代码中将其用一个立即失效的同名 cookie 覆盖。

在 Web 应用中，最常用的服务器端与客户端的数据交互是通过提交 HTML 表单实现的。以 HTML 4.01 为例，规定当表单提交时，会将 <form> 元素中的 Successful controls 的当前取值提交到服务器。所谓成功控件需要有以下几个条件(但不仅限于此)：

1. 必须有控件名字，即必须包含 name 属性
2. 如果表单中有多个提交按钮，只有被点击的那个按钮可以是成功的
3. 不能是禁用状态，即不含 disabled 属性
4. 不是 Reset button

现在我们考虑一下这样的场景，在某个表单中我们需要用到多个提交按钮(Submit button)，就如同 WordPress 后台写文章那样的表单，我们在编辑完文章内容后，可以选择保存草稿或是直接发布。下面图中所示是一个简化的发布页面，可以填写文章标题、内容之后选某一种提交形式：

对应的 HTML 片段可以是这样：

1
2
3
4
5
6

<form action="http://localhost/blog/new-post" method="POST">
    <input type="text" name="title" id="title" /><br />
    <textarea name="content" id="content" cols="30" rows="10"></textarea><br />
    <input type="submit" id="save-post" value="Save Draft" />
    <input type="submit" id="publish" value="Publish" />
</form>

为了在提交时能区分是保存还是发布，需要通过 JavaScript 来为不同的按钮绑定不同的操作：

1
2
3
4
5
6
7
8

//using jQuery
$('#save-post').click(function() {
    //按保存草稿方式提交
});
 
$('#publish').click(function() {
    //按发布方式提交
});

那么提交的数据中如何来区分是保存草稿还是发布？通常我们会在 <form> 中添加一个隐藏的控件来保存这个状态，像这样：

<!-- value 可以是 publish 或 draft，默认为 publish -->
<input type="hidden" name="post-status" id="post-status" value="publish" />

这样在 JS 中就只需要为按保存方式提交作相应处理：

1
2
3
4

//using jQuery
$('#save-post').click(function() {
    $('#post-status').val('draft');
});

这样如果按 Save Draft，那么 POST 出去的数据就应该是：

title=blah&content=blahblah&post-status=draft

OK，这样的确已经可以正常工作了，但是总觉得让人有些不爽：这么简单的工作为什么还要通过脚本来实现？有没有想过为什么要这样实现呢？事实上，因为在文章开始的地方提到的 HTML 规范中定义了一个表单中有多个提交按钮的情况下，只有一个可以是成功控件从而提交自己的数据值，也就是说，我们给提交按钮加上相同的 name 属性，只有一个按钮会提交相应的数据。那何必还需要隐藏控件？应该只需要这样：

1
2
3
4
5
6

<form action="http://localhost/blog/post" method="POST">
    <input type="text" name="title" id="title" /><br />
    <textarea name="content" id="content" cols="30" rows="10"></textarea><br />
    <input type="submit" name="post-status" id="save-post" value="Save Draft" />
    <input type="submit" name="post-status" id="publish" value="Publish" />
</form>

像这样把两个提交按钮的 name 属性都设为 post-status，就可以像服务器发送唯一的 post-status 值了，但有一个问题：post-status 的值只能和按钮上的文字一样了，给 Web 应用的 i18n 带来了很大的不便。其实 HTML 规范也考虑到了这个问题，这就是为什么我们会有 <button> 元素。HTML 中的按钮共有三种类型：

• submit buttons
• reset buttons
• push buttons

前两个不用说，第三种按钮没有默认的数据交互行为，需要依赖脚本才能起到作用。一般情况下我们使用的都是 type 属性分别为 submit / reset / button 的 <input> 元素，而 <button> 元素就是用来为这三类 <input> 提供更多渲染可能性的，<button> 中可以插入其他的 HTML 元素，比如可以加入 <img> 来给按钮增加一个图标，所以显然也可以使用任何你想使用的文本作为按钮上显示的文字。这个文字和按钮的取值 value 应当是分离的：

<button type="submit" name="post-type" id="save" value="draft">Save Draft</button>
<button type="submit" name="post-type" id="publish" value="publish">Publish</button>

看上去很不错，不是么？可是很不幸，我们又遇到麻烦了：在 IE6/7 下，这样的方法完全不能工作。在 IE6 下，用这样的方式按 Save Draft 按钮，POST 出的参数值为：

title=blah&content=blahblah&post-status=Save+Draft&post-status=Publish

在 IE7 下，则是：

title=blah&content=blahblah&post-status=Save+Draft

可以看到，IE6/7 错误地把 <button> 的 innerHTML 当作了 value 发送出去了，而 IE6 甚至把没有点击的按钮也看作成功。WTF！本来很优雅的代码在现实中却是无法完美工作的。有人写了个针对 IE6/7 的 hack 来解决这个问题，即在 <button> 的点击事件中，disable 同一表单内的其他 <button> 并且用其 value 替换 innerHTML，但这样在网速比较慢的情况下(就是大多数情况下)会出现下面这样的画面：

这显然也是不能让人接受的。就是没有一个完美的方案，就是这样，所以又回到我们开头的地方了。用隐藏控件来 hold 住提交方式参数，用脚本来给它赋值，又变成了看起来最通用最简单的方案了。

另外有一种观点认为，一个表单就不该有多个提交按钮，提交按钮不该携带任何参数值，完全可以换成单选框、下拉菜单等等等等方式来实现。但实际上多个提交按钮在很多时候可以减少用户的交互操作，并且更为直观，绝对是有其存在价值的。拿 WordPress 的文章发布方式来说，现在就是多提交按钮的：

如果改成下面这样，就感觉十分别扭了：

总结一下：如果你可以抛弃 IE6/7，那么恭喜你，用最简单优雅的方式去实现吧！如果不能，那么，还是老老实实地用隐藏控件吧，慢慢等着 IE6/7 入土为安吧。

很久没写东西了，有点虎头蛇尾，其实没多少内容，发发牢骚而已。

Update: 欲了解更多关于按钮数据交互行为的浏览器差异可以阅读这篇文章。

上一篇里面我们介绍了怎么增加任务，这一篇里面将介绍怎么在IE9中增加缩略图控件。

完成之后的效果会是这个样子。


首先要介绍几个API，

• window.external.msIsSiteMode 判断是否是站点模式
• window.external.msSiteModeAddThumbBarButton 加缩略图按钮
• window.external.msSiteModeAddButtonStyle 给缩略图按钮增加样式
• window.external.msSiteModeShowButtonStyle 显示已定义的缩略图按钮样式
• window.external.msSiteModeUpdateThumbBarButton 更新缩略图按钮状态

首先在初始化的时候把缩略图的按钮给加上，代码如下：

document.addEventListener('msthumbnailclick', onButtonClicked, false); //事件响应
 
btnPrev = window.external.msSiteModeAddThumbBarButton(path + 'images/prev.ico', 'Previous');
btnPlay = window.external.msSiteModeAddThumbBarButton(path + 'images/play.ico', 'Play');
btnNext = window.external.msSiteModeAddThumbBarButton(path + 'images/next.ico', 'Next');
stylePlay = window.external.msSiteModeAddButtonStyle(btnPlay,  path + 'images/play.ico', 'Play');
stylePause = window.external.msSiteModeAddButtonStyle(btnPlay, path + 'images/pause.ico', 'Pause');
 
window.external.msSiteModeShowThumbBar();

这样子的话就能把bar给加到缩略图上去了，在这之后，我们加上几个html5新增的audio的tag，组成一个playlist，那么在这里，我选择的是Kelly Clarkson的Because of you和Beatles的Let it be。

简单的说一下audio这个对象的几个API，

• canPlayType() 是否能播放该编码格式
• play() 播放
• pause() 暂停
• paused 一个bool值记录表示是否已暂停
• currentTime 当前音频已播放的时间

所有的控制函数都是加在上文代码中定义的事件响应函数onButtonClicked中的，通过对事件的监听，可以判断是哪个按钮被按下并执行相关的逻辑。

最后播放的效果就会是这样：

JavaScript文件的source在这里，如有需要可以自行查看，另因为这一系列的东西只是IE9特有的，而且是站点模式所特有的，所以在别的浏览器下不会有这样的效果了。

IE9是个好东西，但更好的一点是Win7和IE9的组合把Web应用app化实现得更彻底了。在接下来的几篇中会简单描述下怎么做这么个事情。

首先我们将在页首的meta里面填加一点东西，比如在Lync.in里面，我们加上这么几行。

<meta name="msapplication-task" content="name=About; action-uri=http://lync.in/about/; icon-uri=favicon.ico" />
<meta name="msapplication-task" content="name=Projects; action-uri=http://lync.in/projects/; icon-uri=favicon.ico" />

在这样的一个tag里面一共是有2个参数，其中content的部分可以有4个参数可以配置，并且是用分号来进行分隔。

然后我们把网站拖到任务栏上面。

然后当我们右键打开的时候就能看到我们刚才加的那两行代码的效果了。

在Web应用中，客户端的AJAX技术已经非常普遍也非常深入人心了，但与此同时，另一些应用，诸如在线监控，实时数据显示，即时通讯等需要将后台数据变化情况实时显示到前台，这样的由服务器push的行为（也许会让你想到blackberry）则需要另一种方案来解决，也就是本文所要介绍的Comet —— 无需安装插件，保持http长连接的服务器推方案。
以下两点是方案中必须顾及到的。

1. 浏览器通用性，对各种不同实现结构模型的支持。
2. 长连接对于服务器资源的占用，以及服务器的承受能力。

Comet的客户端与服务端交互流

业界对于Comet实现有两种主要的解决方案：

1. 基于AJAX的轮询(long polling)方式

   这种方式就是由客户端发出AJAX请求，然后服务端阻塞请求直至有响应或超时。客户端在接收到服务端的指令之后会进行响应并发出新的请求。

   从实现层面上来说，当XMLHttpRequest的状态为4也就是load的状态时会进行客户端处理，而Gecko（Firefox）和Webkit（Chrome，Safari）目前支持在readystate为3的时候读取（当然只能读取到所有该请求已返回的串内容，所以需要自行确定指令边界），Trident（IE）目前如果中途去读取会抛出错误，IE8中使用XDomainRequest可以适当解决这个问题（参见Eric Law的COMET Streaming in Internet Explorer）。

   目前，开心网采用的是这一种方式。

2. 基于iframe及htmlfile的流(streaming)方式

   这种方式是使用了iframe的机制，然后使得这个iframe请求一个特定的URL，并通过对这个页面的加载不断的从服务端抓回数据，这里从服务端抓回的数据大多是对页面当前JavaScript函数的引用和操作。

   这个方案的一个明显不足之处是页面会一直显示正在加载，而这在IE上会更明显。Google的天才们想到了用htmlfile的ActiveX控件来解决这个问题的方案，详细描述可以参见Alex Russell的What else is burried down in the depth's of Google's amazing JavaScript?

   目前，人人网和GTalk采用的是这种方式。

除了文首所提到的通用性和性能之外，还有几点是需要列入考量范围的。

1. 数据交换的格式。由于数据交换的形式是推送，所以不可避免的会有指令队列的存在，于是数据结构是需要前后台详细约定的，执行指令和数据指令都需要有严格的界定，一般来说，JSON的方案比较普遍。
2. 浏览器本身的连接数限制。HTTP 1.1规范中声明客户端不应该与服务器端建立超过两个的 HTTP 连接，而IE又严格遵守了这一点，所以前台在处理请求的时候需要谨慎控制请求的数量。

其实，Comet技术在AJAX大红大紫的2005年之后的2006年时是业界一个很热的讨论点，目前的这两种方式非常成熟，在dojo，dwr等前端框架中都已经有这样的实现，而Bayeux协议的出现也已经在实质上订下了一种业界的标准。

Comet的框架前端有Pushlet，dwr和dojo等，服务端有Jetty，Meteor，Orbited，Glassfish，Alpha，实现的产品语言也覆盖了Java，C++，Python，Perl，Ruby，Erlang，.Net等。

下一代HTML5中的WebSocket会是Comet的一个新起点，但在那之前，在非插件的web层面应该不会有更进一步的讨论与技术出现。

本文只是对Comet这个技术进行大体的概述，粗陋不明之处难免，在后续的文章中将会对WebSocket进行一定的解释和演示。

参考资料：

• 这里有一个php的comet的例子How to implement COMET with PHP。
• 这是developerWorks上对于Comet的介绍。
• 这是当前Comet的服务器端的一些产品及介绍。
• 当然，Wikipedia上面对Comet的解释也是非常详尽。
• 还可以看看AjaxPatterns上面的一些介绍。
• 最后，CometDaily是个值得去了解最新Comet新闻和知识的地方。

今天下午Justice兴致勃勃的贴出一个jQuery的插件，jQuery Crash。
插件的地址在这里。
其实就代码来说这个脚本就只有一行。

jQuery.crash=function(x){for(x in document.open);};

调用这个函数之后的话，在IE6下你会得到这样一个结果。

进一步的，其实不止document.open，很多函数都会产生类似的结果，比如getAttribute，setAttribute等等。
在调用$.crash()之后，等于是for (undefined in document.open)，有些人说，是因为在document.open这样的一个对象中寻找可迭代的对象时发生了错误所造成的。ECMAScript规范中定义的算法指出for...in是要把对象的每一个可迭代属性依次设进x中，而某一个属性可能就在此时发生了问题。那么这又是为何？有人说可能是在调用内部的[[get]]方法时出现的。
也许只有IE的开发人员才知道这个问题究竟是什么，但无可质疑的是，发现这个JScript bug的人是一个天才。而且他成功的杀掉了IE6。

本文所描述的场景并不是常见，如果你的脚本并没有很多层嵌套，如果你的脚本不是以动态载入的形式来执行，那么这个很复杂很纠结很麻烦的事情你应该也不会遇到。

很不幸的，在我的工作中，不但会有一个很深层的递归，会动态的载入JS，而且还有eval这样的global code。哦，对了，还有多frame的操作。

好的，让我们开始这个很棘手的事情。

也许你很经常会看到这样的场景。

是的，这是一个脚本异常，在IE中非常常见的一个脚本异常。那么如果这里的Line是一个9位数呢？比如152345279或者512369027，是不是有点抓狂了呢？

S同学也不是什么超人，做不了这等亿万行代码的工作，入行至今写的代码也不及这个零头。那么为什么会那么多行呢？因为这个已经是内存中的行数了。再之后进去调试，调试器会告诉你，source code is not accessible，的确，这些代码都不是明文写在网页中，并没有document.write()之类或者直接写在<script>中。正如前文所述，这些脚本是用动态加载技术读入的（相关内容可以看这篇博客《动态载入脚本和CSS》），所以其内容是完全载入在内存之中，而在文本的表现中是缺失的。也正是因为如此，其调试才显然相对困难。

当然也有办法。

在调试中，你也许会碰到许许多多层的anonymous function，然后你会对这是哪个函数而迷惑不已。当然，通过local variables，通过去看this的具体内容，你可以大致猜测到具体是哪个函数，但如果用以下这句话，也许会更容易一些。
arguments.callee().toString()

其实这句的目的就是打印出当前调用的函数的内容。当你通过函数的内容来找到对应的代码，事情就容易得多了。在那以后，根据错误消息的提示及对变量的观察，就可以找到问题的根源了。

还有些场合，比如weblogic这样的application server之上，会对脚本文件的长度进行cache，如果你的文件被改动过，那很有可能真正你的浏览器下载的脚本文件并不完全。并极有可能带来一些JS解析执行时的错误。所以，如果碰到错的时候，不妨先看看你到手的JS到底长得啥样。

通过XUL来制作的Firefox在调试的时候，特别是一些比较精确的调试的时候，效果反而不如IE系的几个东西来得舒服。而Opera和Webkit东西在调试的时候，就显得更不方便了。虽然在一般调试的时候，Firebug，DragonFly和Web Inspector依然是非常强大非常好用的工具。

如果有错，还望各位不吝指正。

注：其实媒体文件的播放都可以采用本文的方法，这里仅以音乐为例。

很多喜欢音乐的朋友都喜欢在自己的站点中分享自己喜欢的音乐。通常除了直接给出音乐文件下载地址，还可以在文章内容中嵌入播放器，使读者可以在阅读内容的时候很方便地播放。可以使用Flash或者JavaScript的播放器。Yahoo! Media Player 和 JW FLV Media Player 都是不错的选择。但是在播放一首曲目的时候，如果用户想切换到别的页面浏览别的内容，播放就会终止。那如何做到在用户切换页面的时候，使音乐继续播放呢？

其实只要遵循一个原则就可以做到——播放器所在的页面不进行跳转。也就是说，要么将其他内容与播放器分离，要么整个站点的内容都在一个页面内，采用动态加载。

播放器与内容分离

有两种方法：弹出新窗口进行播放和使用框架。

弹出新窗口

这个很容易理解，谷歌音乐就是采取的这个方式。这个方式使得播放器完全分离在另一个窗口，感觉上和使用本地播放器进行播放效果类似，比较之下其优势在于可以在播放窗口安排更多的个性化功能。但是这个方法要多开一个浏览器窗口，总让人感觉不那么自然。

使用框架

这个方法和上一个其实没有本质的区别，最大的不同就是将独立的窗口放在一个frame中，这样就可以在同一个视图中进行播放器的控制和站点其他内容的浏览了。上一次的测试文章就是使用的这个方法。

稍微介绍一下我使用的这个方法。将frameset分为上下两个frame，上面的主窗口就放站点原来的页面，在下面的frame中嵌入包含JW Player的player.html。包含frameset的网页代码大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<html>
<head>
<title>My Website</title>
</head>
<!-- 下面rows="*, 20px"表示，页面上部自适应高度，下部固定20px高，可自己调整 -->
<frameset id="f" rows="*, 20px" border="0">
    <!-- 下面这个frame指向你的网站路径 -->
    <frame src="http://www.my-website.com" frameborder="0" noresize="true" />
    <!-- 下面这个frame指向播放器路径 -->
    <frame src="player.html" frameborder="0" scrolling="no" noresize="true" />
</frameset>
<noframes>
    <body>
        <!-- 如果浏览器不支持框架，显示如下内容 -->
        Sorry, your browser does not support frameset.
    </body>
</noframes>
</html>

下载JW Player后将其包含的播放器Flash文件及swfobject.js均解压到站点相应目录。可以去JW Player的官网使用其设置向导进行代码生成，直接copy到player.html中。生成的代码包含这样一句：

var so = new SWFObject('player-viral.swf','mpl','100%','19','9');

其中的'mpl'是生成的播放器对象的id和name，之后还会用上。当然也可以自己起别的名字。

现在播放器只能播放初始化时预设的那个曲目，已经可以实现跨页播放，不过还需要进一步的改进。我们可能在站点内多处提供了音乐资源，希望用户可以根据喜好选择播放器内播放的曲目。接下来可以使用JS来控制播放器播放的曲目。由于这些功能在不使用frameset时不需要，我们可以在页面初始化时，通过检查是否存在frameset来判断是否需要动态加载实现这些功能的JS代码。我使用的是jQuery的动态加载方法，如果顶层窗口内存在2个frame，就进行加载：

if(top.frames[1]) {
    $.getScript('http://lync.in/frame.js');
}

首先，我们希望在音乐文件的链接后给出一个播放按钮。在发布需要支持跨页播放的音乐链接时，我们可以给相应的<a>标签添加class="play"，然后使用jQuery来完成按钮的添加：

$('a.play[href]').each(function () {
    $(this).after('<span>[<a class="play_button" href="javascript:playAudio(\'' + $(this).attr('href') + '\');">Play</a>]</span>');
});

接下来就是完成playAudio这个函数的功能。首先，在player.html的JS代码中添加：

1
2
3
4
5
6
7
8

function thePlayer() {
    if(navigator.appName.indexOf("Microsoft") != -1) {
        return window['mpl'];
    } else {
        return document['mpl'];
    }
}
var player = thePlayer();

这就取得了播放器的JS对象，在主页面中可以使用top.frames[1].player对其进行引用。注意上面'mpl'需要和在SWFObject对象初始化时设定的id相同。然后只要在点击Play按钮时给播放器发送相应事件就可以更新其播放的内容：

1
2
3
4
5

function playAudio(src) {
    player.sendEvent('STOP');
    player.sendEvent('LOAD', src);
    player.sendEvent('PLAY');
}

这样，整个站点内class="play"的音乐链接都会动态加上Play按钮，并可以在站内实现跨页面播放了。

还有几个小细节需要完善。在带框架的页面内再点击导航向框架页面会导致框架嵌套，可以使用JS处理页面内所有链接，在遇到导航向框架页的链接时，在顶层窗口进行跳转。在这里我带框架的页面地址为http://lync.in/go.php：

$('a[href^="http://lync.in/go.php"]').click(function() {
    top.window.location.href = $(this).attr('href');
});

除此之外，当点击站外链接时，也应该在顶层窗口进行跳转。在使用框架时，点击某个frame中的链接并不会改变顶层窗口的title和地址栏链接。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$('a').click(function() {
    top.document.title = 'Loading...'; //点击链接时先将title设为"loading..."
}).filter(function() {
    var href = $(this).attr('href');
    if(href) {
        //经过滤选出站外链接
        return !(href.indexOf('http://') == -1 || href.indexOf('http://lync.in/') == 0);
    }
    return true;
}).click(function() {
    top.window.location.href = $(this).attr('href');
    return false;
});
top.document.title = document.title; //让顶层窗口的title和主窗口title相同

用上面的方法，可在新页面加载的时候用JS将title更新。而对地址栏的链接就没有什么完美的方法了，可以采取Billboard的解决方案，后面会说。

全站动态加载

整个站点都不刷页，点击链接都以AJAX的方式进行加载，或者直接全站Flash/Flex。

这个方法有一个很好的例子是Billboard。它所有的音乐都使用页面左侧的JS播放器进行播放，并有调整播放列表等功能，而页面的跳转全部都使用JS来处理。而地址栏URL它采用了页内链接的方式，点击后不刷页，但是可以更新地址栏URL。这样，用JS将普通的链接在点击时转换为页内链接，就可以不刷新页面而且更新地址栏了。如果我们应用到框架方法中，那就可以在点击站内链接时，先将顶层窗口定向到相应页内链接，然后return true就行了。同时，如果用户使用带有'#'的链接进行直接访问，也应该在服务器端做相应处理，给出相应的frame源地址。但Wordpress站点一般都含有带页内锚点的链接，比如http://lync.in/how-to-play-music-across-pages/#comments，这样处理起来就比较麻烦了。

个人不太喜欢全站Flash/Flex的站点，虽然效果够炫，但是这样屏蔽了浏览器的不少功能，可能会与用户长期养成的使用习惯发生冲突。比如在访问Flash站点时，就无法使用浏览器的返回按钮进行回退了，更别说鼠标手势等等功能了。

就这点体会了，如果大家有更好的方法来实现这个效果，希望不吝赐教。

好的工具能帮助你事半功倍，至少你能很快的解决问题。或许你对于Visual Studio和Eclipse的调试器印象深刻，而对于JavaScript这样完全基于浏览器的调试无所适从（其实JavaScript的应用场景远远不止于浏览器），那么这篇简介或许能帮到你。

Internet Explorer

Microsoft Script Editor

这是Microsoft自己的一个调试器，要使用它以前确保你有Office。安装方法很简单，Word或别的Office组件中，工具->宏->Microsoft脚本编辑器，安装完以后记得安装web调试。然后在IE的高级选项中记得清除“禁用Internet Explorer调试”前的勾。

Internet Explorer Developer Toolbar

对于IE的样式而言这个实在是太关键的工具了。[下载地址]
另外要注意的是，IE8里面内置了这一款工具，而且也提供了一个非常好的调试环境，所以你完全可以信赖。

IETester

每一个Web Designer都非常痛恨IE6，与此同时，IE7与IE8之间也有着一些细小的区别。在当前IE6任然占据相当市场份额的现状之下，调试多个IE版本任然是需要的。曾经用过MultipleIE，但发现这款软件的稳定性不佳，直到后来找到这款软件。[下载地址]

Firefox

Firebug

不解释，在Firefox下这个便是王道，唯一可能比较差的就是在面对相当复杂的脚本操作的时候可能在调试脚本中会碰到一些困难。

YSlow和Page Speed

互联网大亨Yahoo!和Google的开发人员他们对于Web的经验在这两个小插件中绝对的体现，如果你想提升你的网站的性能（不是UI），那么，你最好听取他们的建议。

Safari

用Safari自己的吧，也没什么别的选择。

Chrome

同Safari，现在Chrome的插件机制并不成熟，而且，请相信Google工程师的技术能力。

Opera

Opera的DragonFly调试器也是很强大的，只是国内的O粉不多。

HTTP工具

Fiddler

Fiddler是一款Proxy，不是用来给你翻墙的，只是为了监控你的web行为，它可以看你的web请求，仿造request和response，看网页加载过程中的timeline等等。[下载地址]
注：Fiddler需要.NET Framework 2.0支持。