昨天，即 2012 年 1 月 18 日，美国互联网行业各大站点组织了大规模黑屏抗议活动，以对抗可能被国会通过的 SOPA 和 PIPA 两项法案。

先看一下维基百科对这两项法案的简介：

SOPA和PIPA是美国众议院以及美国参议院所提出的两个重大议案，其中“SOPA”为《禁止网络盗版法案》（Stop Online Piracy Act）的英文简称，而“PIPA”则是《保护知识产权法案》（Preventing Real Online Threats to Economic Creativity and Theft of Intellectual Property Act of 2011）的英文简称。这两个法案在原本立意之下是要设法阻止有关外国网站对于版权的侵犯，但是在我们看来它实际上已经成为阻碍人民自由表达、破坏互联网价值观的工具。

简单来说，大致就是规定美国政府对封锁刊登没有专利权的内容的网站有了更大的权力，不管这些网站是否注册在美国。在该法案下，有了法庭的允许，美国司法部长能够要求搜索引擎，ISP 公司以及在线广告以及支付公司停止与那些国外的侵犯版权的网站合作，包括从网站链接以及该网站的 IP 地址来封锁该网站的名字。支持这项法案的主要是好莱坞和一些大唱片公司。而反对方主要是互联网公司。(via 百度百科)

这样做的后果，就是使得网站在提供内容时，特别是 UGC 时，不得不加大对内容的审查，严重影响互联网的知识共享和言论自由(参见我国的网络审查制度，当然审查的目的是不同的)。反对方认为，虽然知识产权理应得到保护，但是这样的法案只是把责任转嫁到了互联网企业头上，特别是那些需要发布大量 UGC 内容的站点，并不能够真正消灭盗版行为，却会让互联网的自由精神受到极大的伤害。

于是 Google 等美国互联网行业的各大站点选择在 1 月 18 日共同用行动来表达自己的愤慨。有些网站甚至是完全停止服务、首页黑屏发表申明来表达诉求。更有一些软硬件厂商、出版商为了自己产业上下游伙伴的利益，站出来进行声援。

下面就来看看，他们选择的抗议方式。

Google

Wikipedia

WordPress.org

WordPress.com

Mozilla

reddit

TechCrunch

Boing Boing

PHP

O'Reilly

Razer

其他还有很多，就到这里吧。

关于互联网版权保护这个问题，的确是个两难的问题，尤其是对于 UGC 站点：网站是否需要对可能出现用户发表的侵权内容负法律责任？如果是，那网站不得不在用户内容发表前进行审核，这必然大大降低信息流动的效率，也极大地限制了互联网自由；如果不是，即按现行的“避风港”原则，只要 ISP 或网站在接到投诉后及时删除了侵权内容，就不视为盗版同案犯，但是这样的确对人们提供盗版利用盗版留下了可乘之机。不过，即使是实现审查，也难以保证所有内容都没有侵权可能，因为世界上并没有一个统一的机制来查询某些内容的版权是否属于当前发表人，真的要实施审查也会遗漏大量的侵权行为，如果这样都要怪罪于网站或 ISP，那的确会使得他们无法生存，所以 SOPA 会激起他们如此强烈的反抗。

发一篇凑凑数，前几天在知乎看到一个问题：在你眼中 Web 3.0 是什么？恰好我对此稍微有些了解，于是组织了下语言尝试回答了一下。在这里也分享一下吧。

传统的 Web

以内容为核心，网站负责提供各种内容 (新闻、小说、视频等等) 吸引用户，用户主要是找到自己感兴趣的内容后较被动地接受信息。

Web 2.0

之所以加引号，因为毕竟没有所谓的 “Web 2.0 标准”。在广泛的共识中，Web 2.0 以用户为核心，用户自己共享内容 (User-generated content，比如发表微博、博客文章、podcast、上传视频、图片到 Youtube、Flickr 等等)，Web 服务商提供各类 Web 应用来承载用户的内容、组织他们之间的交互。相比传统 Web，Web 2.0 的各种服务更专注于用户，提供更好的交互体验，同时各种服务商提供不同的开放 API，使得一些个性化 Web 应用的实现成为可能。

Web 3.0

应该说 Web 3.0 这个说法究竟指什么还没能得到广泛的共识，大家对其定义有很多不同的理解。

其中，较多人把语义网 (Semantic Web) 看作 Web 3.0。这是 WWW 之父 Tim Berners-Lee 提出的，对当前的 Web 内容组织方式可以算是一种颠覆：目前互联网上的信息绝大多数都是以 HTML 格式承载的，是将各个网站背后数据库中隐藏着的结构化信息编码为浏览器能够渲染的 HTML 代码 (在这过程中浏览器并不知道网页内容的真正含义，只知道如何渲染)，最终渲染为人类可读的信息。这就有一个非常大的局限：真正在互联网上能够被共享的信息绝大多数都是半结构化的 HTML 内容，因为这些信息是海量的，要把它们整合利用必须通过自动化的手段，但机器又难以理解 HTML 中实际给人类阅读的内容。所以现在各种自然语言处理、人工智能的方法被广泛应用于互联网内容的处理，力图让机器能够还原各种数据之间的关系，更智能地加以组织利用 (这里说的不是小说等自然语言文本，而主要是一些原本结构化的信息，在转换为 HTML 的过程中丢失了原来的语义。例如电子商务网站上某个照相机的各项参数，机器很难准确识别一个网页中哪些部分是用来描述这个相机的，而哪些又是广告或是描述其他产品的)。

而语义网的概念是从另一个方向来解决这个问题：不用机器来做基于人工智能的识别，而是在提供内容的时候，就用明确的、机器可读、有标准语义可依的方式来将所提供内容的语义描述清楚，建立完善的机制来描述互联网上的各种资源。在资源的标准化描述之上，建立标准的语义推理以及信任体系，为各种智能代理 (intelligent agent) 提供可靠的信息、标准化的交互模式，从而改变人们访问 Web 的方式 (比如比 Siri 更为强大且智能得多的应用，记得有个例子是当你牙疼要看牙医，智能代理会自动检查你的日程安排、寻找合适的有空的牙医、与诊所的代理进行自动登记，为你安排出行)。

目前已经有几项技术成为了语义网的推荐标准，其中在 Unicode、URI、XML 等基础设施层之上已经成为标准的有：

• RDF/RDFS，资源描述框架及基于此的一套词汇集
• OWL，Web 本体语言，用来在 RDF 之上提供基于本体的词汇集
• SPARQL，用于查询 RDF 文档

在这些层次之上，还有推理、信任等层还没有确定的标准。

语义网能否最终发展成为其愿景所描述的状态，还很难说。因为从目前来看，各种开放 API 已经可以组织成甚为丰富的 Web 应用，而像语义网愿景中描述的可以自己搜寻识别可用服务进行组合完成用户需求的超级智能代理，显得有些遥遥无期。此外，语义网的标准的推动也有很大难度，率先“拥抱”这些标准短期内并不会给互联网公司带来多大的好处，且语义网的未来又被很多人看衰，最终结局会不会惨淡收场也尚未可知。批评语义网的观念太过理想化、认为其完全不可能成为现实的人大有人在。

回到 Web 3.0，语义网只是其中一种说法，也有人把语义网称为 “Web 4.0”。其它观点个人不太了解，也就留待其他人补充吧。

至于盈利模式，可以说目前互联网上的主要盈利模式还是广告。Web 不管是几点零，之前的模式也不是说就被取代了。比如说现在我们有那么多 Web 2.0 网站，但是提供内容服务的网站同样可以很红火，人们照样上新浪看新闻、上优酷看电视剧。只要用户能看得见的地方，都可以通过广告来获得利润。此外还有电子商务，不管 Web 几点零，通过交易总是可以获取利润的，只是交易的交互模式可能发生改变。另外一个途径是提供收费服务 (比如提供云计算服务、提供网游等娱乐服务)，这和电商类似，只是交易的内容不是实体。

欢迎探讨。

有时候我们会遇到这样的情况：在一些前端控件要提交数据到服务器端的数据验证过程中，需要判断提交的数据是否为空。如果是普通表单的字符串数据，只需要在 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 及以下的结果

简单介绍下这个命令行发送邮件的工具SendEmail，它的作用就是发送邮件。很多年前有一个流传很广的小工具bmail也是这个作用，只不过近些年来随着各个邮件ISP要求给发送服务器进行身份验证，bmail在停止开发后也就因此而失效。SendEmail包含了这个功能，通过一系列管道的方式，SendEmail也就能起到很多的功能。比如向139邮箱的发送邮件，利用139邮箱的免费短信提醒从而起到免费短信的作用。

这里是SendEmail的项目地址，有Linux版和Windows版，同样的项目目录之下还有很多别的小工具，也都是很好用的工具。

今天要介绍的东西已经不算什么新的玩意儿了，几年前就有人各种介绍了，最近已经冷下来了。不过在现在恶劣的网络环境当中，这样的工具变得越来越有实用价值了。

我们知道通过 Google Reader 订阅的 RSS 源只要有更新就会被 Google 记录，从而即使原文被删除，Reader 中还是有原文的记录，于是我们甚至还可以通过 Google Reader API 获取历史 RSS 条目。所以像韩寒那样的博客在 Reader 中总是能够读到原文。

但是最近我发现新浪博客的停止了全文 RSS 源输出，而仅仅输出摘要，导致一旦文章被删，Reader 里也只剩下摘要了，再要找原文看就比较麻烦了。这时候我想到了 Yahoo! Pipes 这个异常强大好用的数据整合工具，给博客来做个全文 RSS 源应该是轻而易举吧。结果在创建过程当中，发现新浪博客在博客文章源码中做了一些很恶心的处理(见下图)，会抽出文章中的几段文本，随即插入文章中，再设定样式将其隐藏，导致用普通的全文抓取的方法来制作 RSS 源会生成不少重复的文本块，插入文章中以后根本无法正常阅读。

幸好这“防御”措施还有规律可循，用正则替换就能轻松绕过，最后还是可以生成完美的全文 RSS 源的。下面就来分享一下这个过程吧，就以韩寒的博客为例：

1. 首先要注册个 Yahoo! ID (废话)，在 Pipes 主页 上方可以找到 “Create a pipe” 按钮，点之，就进入了 Pipe 编辑界面。左侧是模块选择区域，右侧是编辑区域。将一个个模块拖动到右侧相连接，控制模块的逻辑组合与输入输出，我们就可以对原始的数据进行一系列复杂的操作。
2. 从左边找到 Sources > Fetch Feed 拖动到右侧编辑区域，添加一个 Feed 模块。在 URL 输入框里填入博客的 RSS 源地址：
   http://blog.sina.com.cn/rss/1191258123.xml
   这样这个模块输出的就是这个 RSS 源的数据，一切顺利的话，底部的 Debugger 区域就能显示出文章标题列表了。
   
3. 找到 Operators > Loop 模块拖到右边，并将 Fetch Feed 模块的输出拖放到此模块的输入位置，表示对输入的列表元素进行循环处理。编辑具体处理的逻辑需要从左侧再拖动 Sources > Fetch Page 到 Loop 模块内，URL 选 item.link。下面的 Cut content from ... to ... 是用来截取需要的文本的。也就是把从上面 Feed 模块中得到的每个 item 的 URL 输入 Fetch Page 模块中，可以输出这个 URL 的源码，我们需要找到标志文章开始和结束的代码标记，从而程序可以将这之间的代码取出来作为输出数据。分析一下新浪博客的文章页源码，我们可以分别将开始和结束标记填为 “<div id="sina_keyword_ad_area2" class="articalContent ">” 及 “<INS>来源：”。Split using delimiter 这项只需留空即可，我们不需要再将内容进行分隔。最后，我们要将模块的输出重命名为 item.description。到这里我们已经用全文内容作为 description 将原来 feed 中的摘要覆盖了。接下来就要处理上面说到的新浪博客的重复文本问题了。
   
4. 通过观察，新浪博客的隐藏文本都是放在一个 class 属性值为 MASS + 12 位字母数字的 span 元素中，所以只要将这个元素中的内容都过滤掉，就可以得到“干净”的文章内容了。从左边找 Operators > Loop 拖到右边，将上面模块的输出绑定。左边找到 String > String Regex 模块拖入 Loop 模块。For each 后面选择 item.description，来对前面的输出中的每篇文章内容做循环处理。replace 后面填入这个正则表达式：<span class='MASS[a-zA-Z0-9]+'>[^>]*</span>，
   然后将最下方的 assign results to 选为 item.description。最后，把整个模块的输出连到 Pipe output 模块，编辑过程就大功告成了。
   
5. 点击右上角 Save 来保存配置，点击上方的 “Run Pipe...”，查看运行结果。在输出页面找到 Get as RSS 链接，这个链接的地址就是一个可用的 RSS 源了，在 Google Reader 中订阅吧！

这仅仅是对 Yahoo! Pipes 的一个简单应用，其实还有更多强大的功能我都没研究过，但仅仅利用这么一些初级的功能，我们已经可以得到一些实用的输出了。下面是我已经创建好的韩寒博客的全文 RSS 源，请自取。
Pipes 原始地址：
http://pipes.yahoo.com/pipes/pipe.run?_id=86b82a340ea9fa635fb4732e0e2819f1&_render=rss
Feedburner 烧制的源：
http://feeds.feedburner.com/twocoldfulltext

Enjoy~

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

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: 欲了解更多关于按钮数据交互行为的浏览器差异可以阅读这篇文章。

本想在 6 月份发布的，但是修修改改又拖了很久。

主要修改的部分如下：

• 表情选择菜单

增加了表情选择菜单，方便在评论中添加表情。


• 评论编辑

  增加了评论编辑功能，使未注册访客可以在前台快速编辑自己在之前 30 分钟内提交的评论。目前很多博客使用的是 Willin Kan 的 Ajax comments 来提供有关评论的 AJAX 功能，也包括快速编辑功能。但是这段代码实际上是有漏洞的，只要懂点 Web 技术的人可以很轻松地修改使用这段代码的站点上其他任何人的评论。而且经过沟通看样子 Willin 暂时不准备对这个问题进行处理，虽然我觉得这个问题还是需要解决的。我在这里采取的是用评论者发表评论时使用的 Email 地址和 IP 地址进行验证。除此之外，在关闭 AJAX 时，评论快速编辑功能依然有效。
  

• Post Format 功能支持

  自 3.1 后，WordPress 增加了 Post Format 功能，以提供类似 Tumblr 的“轻博客”效果。如果主题支持 Post Format 功能，用户可以通过在发表文章时选择相应的文章格式，从而使不同类型文章在页面中的显示效果不同。这次主题更新中，加入了对目前所有已定义的文章形式的支持，包括 Standard, Aside, Gallery, Link, Image, Quote, Status, Video, Audio, Chat 共 10 种。也许大家还不太明白这个功能有何具体作用，下面就来对各个类型文章的处理规则来作下简单介绍。

  Post Format 这个功能主要是用来让用户可以通过简单的操作，无需进行排版，就可以很轻松地创作一篇带有预定义格式的文章，其格式可以按文章的类型从预定义好的这 10 中形式中进行选择。下面是 SimpleDark 中的处理规则：

  Standard

  标准形式，与之前的普通文章没有区别。

  Aside

  短篇日志，不显示标题，内容与标准形式相同。

  Gallery

  相册，通常内容中包含较多图片。在列表页面显示最多 3 张图片的缩略图，在文章页面显示所有图片的缩略图。

  Link

  链接，通常可以用来分享一个站外网页。不显示文章标题。如果文章内容是一个合法的 URL 那么链接就指向该 URL，否则，解析出文章内容中第一个链接指向的 URL 来使用。链接的锚文字使用文章的标题，如果没有标题则使用 URL 本身作为锚文字。除了链接本身外，列表页用文章摘要作为链接的描述信息显示，文章页按标准形式现实文章内容。

  Image

  图片。如果文章内容是一个合法的 URL 那么将这个 URL 作为图片的地址，否则，解析出文章内容中第一个图片来使用。文章标题作为图片标题显示在图片上方。图片带一个指向文章页的链接，可供访客评论。

  Quote

  引语，用来摘录他人的言论。不显示文章标题。最终的引语内容会自动加上双引号样式。自动解析文章内容中的第一个 <blockquote> 或 <q> 标签中的内容作为引用内容，并按相应格式进行显示。如果没有解析到，则将文章内容全部作为引用内容。自动解析文章内容中的第一个 <cite> 标签中的内容作为引用来源显示在引语内容下方，如果没有则将文章标题作为引用来源。

  Status

  状态，类似一条 tweet。不显示文章标题，使用文章内容作为状态内容，以类似 tweet 方式输出，显示作者的 Gravatar，不给出指向文章的链接。

  Video / Audio

  视频/音频，自动解析文章内容中的第一个 <video> / <audio> / <object> / <embed> / <iframe> 等常用来嵌入多媒体内容的标签来作为文章内容。文章标题作为视频/音频标题显示在视频/音频上方。

  Chat

  聊天，用来分享一段聊天内容。文章内容按换行隔开，显示在一个 <table> 中的不同行内。

  下面是不同文章形式在列表页面中的表现形式：
  

可以查看在线演示同时也可以帮助我进行测试。

下载

从 Google Code 下载最新版 SimpleDark

2011-08-12: 本文评论已关闭，有相关问题请查看 主题介绍 并留言。

近日碰到个状况，在Office中，不管是Word还是Outlook里面，想要通过Ctrl+左键打开一个链接的时候都会被Office拒绝，弹出一个对话框显示。

由于本机的限制，该操作已被取消。请与系统管理员联系。

解决方案其实在注册表里面。方案如下。

打开注册表，找到HKEY_CURRENT_USER\Software\Classes这个项。

然后在其下的.htm，.html，.mhtm，.mhtml，.shtm，.shtml里面，把(默认)这个键的值从ChromeHtmlDocument和FirefoxHtml改成htmlfile就好了。

WordPress 2.7 以后便自带了评论分页功能，那些有很多评论的热门日志页面在开启了评论分页后加载速度就会大大加快，同时也节省了站点的不少流量。但是评论分页以后，WordPress 没有提供一个方法让我们来查询某一条评论位于它所在那篇文章所有评论分页的第几页，这样就带来了一些不便。WordPress 提供了一个 get_page_of_comment 函数，用来获取评论所在的分页数。但这个函数有一个 bug：当嵌套评论选项被关闭，但是数据库中却存在之前未关闭选项时留下的回复的情况下，分页数会计算错误。比如说，本站使用了 mg12 的插件 WP-RecentComments 来显示站内的最新评论，它会在每条评论的作者名字上加上一个指向该评论位置的链接，比如：

http://lync.in/projects/simpledark/#comment-1778

当评论没有分页或者这条评论位于最新的一页评论时，这样没有问题，因为在当前的页面就能找到这条评论。但是如果后面有了较多的新评论，使得这条评论在其他分页的时候，这个页内位置就失效了，上面的这个链接指向的页面也就无法。某篇文章的某个具体评论分页的地址一般还要加上 comment-page-n 或者加入参数 cpage=n，比如：

http://lync.in/projects/simpledark/comment-page-9/

所以如果可以得到评论所在的分页页码，就能通过 URL 直接找到那条评论的位置了，比如：

http://lync.in/projects/simpledark/comment-page-9/#comment-1680

那剩下的问题就是给定一个评论 ID 如何找到它所在的评论分页的页码了。在 WordPress 中，评论在数据库中存在 wp_comments 表中，和今天这个问题相关的几个字段如下所示：

• comment_ID - 评论 ID
• comment_post_ID - 评论所在文章 ID
• comment_approved - 评论是否已通过审核，1 为通过，0 为未通过
• comment_type - 评论类型，可能取值为 trackback、pingback 或留空，若为空则是普通评论
• comment_parent - 父评论的 ID，如果为 0 则没有父评论

首先，我这里考虑范围内的仅有已通过审核的普通评论 (对于没有做评论/引用通告分离的朋友来说可以忽略 comment_type 字段)。计算评论所在分页页码可以分为是否开启嵌套评论两种情况。如果没有开启嵌套评论，那只需要知道在同一篇文章下指定评论之前发表的评论数，除以每页显示的评论数就可以获得页码；而开启嵌套评论时，评论的分页是按一级评论 (没有子评论的评论) 的数量来计算，所以只要计算指定评论所在的一级评论之前的一级评论数，除以每页现实的评论数就可获得页码。

WordPress 的数据库操作是基于 ezSQL 库的，API 用起来还是很方便的。下面给出具体代码：

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

function get_comment_page_number($comment_id) {
    global $wpdb;
    $comment = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->comments WHERE comment_ID = %d", $comment_id)); // 获取指定评论
    if(!$comment) { // 没有取到指定评论
        return -1;
    }
    if($comment->comment_parent != 0 && get_option('thread_comments')) { // 开启了嵌套评论，且有父评论
        return get_comment_page_number($comment->comment_parent); // 递归获取父评论页码
    } else { // 没有父评论
        if(get_option('thread_comments')) { // 开启了嵌套评论，则仅计算本文一级评论数
            $comment_root_position = $wpdb->get_var($wpdb->prepare("SELECT count(*) FROM $wpdb->comments WHERE comment_post_ID = %d AND comment_parent = 0 AND comment_approved = 1 AND comment_ID <= %d", $comment->comment_post_ID, $comment_id));
            $page_number = ceil($comment_root_position / get_option('comments_per_page'));
        } else { // 未开启嵌套评论，计算本文之前所有评论数
            $comment_position = $wpdb->get_var($wpdb->prepare("SELECT count(*) FROM $wpdb->comments WHERE comment_post_ID = %d AND comment_approved = 1 AND comment_ID <= %d", $comment->comment_post_ID, $comment_id));
            $page_number = ceil($comment_position / get_option('comments_per_page'));
        }
        return $page_number;
    }
}

不过需要注意的是，如果嵌套的层次比较深，可能会做比较多的数据库操作，比如如果 WP_RecentComments 列出的评论都要计算页码，10 个 3 级评论就要做 40 次数据库查询，效率比较低，不过可能是我写的 SQL 代码不够高效吧，求优化。其实这样的需求其实也不是太多，仅属于锦上添花而已。另外一个可以应用的场合是，有很多主题都提供了 @ 回复的功能，在评论中自动插入原评论的链接，但当当前评论和原评论不在同一页内时，这个链接就失效了，但通过上面的方法利用原评论 ID 就可以将链接准确指向原始评论了。