玉伯的 TBCompressor 用于压缩 Javascript 和 CSS 文件非常的方便，不过虽然他提供了右键压缩的功能，但我还是希望在编辑文件的时候压缩，顺便就可以在编辑器中查看压缩结果。

于是就有了这个 Vim 小插件，主要的功能就是调用 TBCompressor，然后返回结果到 Vim 控制台中（以后的版本再考虑如何最优化的显示方案）。

在安装好玉伯的 TBCompressor 以后，再将这个插件扔到 Vim 的插件目录中即可。然后，在 VIMRC 中配置相应的选项

let g:tb_compressor_command = 'compressor.cmd'

如果觉得麻烦，就将 TBCompressor 目录扔到 PATH 中好了。批处理 compressor.cmd 中还有个 pause 命令，这个时候就可以注释掉啦。

调用方式就是在 normal 模式下按 \tc 就可以，当然也可以针对喜好自己定制下快捷键。最后，提供 插件下载 ，欢迎提供意见和建议。

此文刊登在《程序员》三月期，有删改

提到安全问题，首先想到应付这些问题的应该是系统管理员以及后台开发工程师们，而前端开发工程师似乎离这些问题很遥远。然而，在 2008 年发生在安全领域的一系列 Web 安全事件，改变了人们对于传统安全的观念。让我们在这里简要回顾下：

IE7 的 0day 漏洞以及 Chrome 崩溃事件

2008 年的年底， IE7 爆出了个很严重的安全漏洞 。与往期微软的漏洞不同，这次的漏洞是从 IE7 发布时起就存在（这也是称之为 0day 漏洞的原因）。

该漏洞的原理，就是通过解析某段精心构造的 XML 造成 IE7 内存溢出，进而可执行任意的代码。虽然官方很快发布了此漏洞的补丁，但此漏洞仍然影响至今。

另个类似的浏览器风波，就是 Google 在 08 年 Q3 发布 Chrome 浏览器。在 Chrome 发布当天，黑客们就发现只要在地址栏中输入构造好的字符就能导致浏览器崩溃。此后即便 Google 迅速的修复了该漏洞，但已经对用户造成了非常糟糕的印象。

感叹：浏览器平台的安全问题，直接影响着该浏览器日后的市场份额。好比当年 Firefox 起家时也正因着重打安全这张重牌，才有今日的收获。即将推出的 IE8 浏览器，微软已经在各种场合大肆宣扬该新浏览器的安全性能。由此，正说明各浏览器厂商对安全这块的重视程度。相信目前正酣的浏览器战场，对于安全这块必然是兵家必争之地。

各微博客的 CSRF 和 Clickjacking 漏洞

微博客的流行是 Web2.0 大潮中的奇葩，然而近期爆发的 饭否、叽歪、Twitter 等的安全漏洞，着实让前端开发工程师大开眼界。 饭否 和 叽歪 的 CSRF 漏洞 ，使得攻击者能通过段 Javascript 代码在用户不知情的情况下，向微博客服务器发布相应的消息，从而造成攻击。

感叹：客户端的 Javascript 脚本早已经摆脱仅仅是显示页面效果的「玩具」，它已经变成一把利刀。这把刀能帮前端解决问题的同时，也能伤害到用户。

同比，年初爆发的 Twitter Clickjacking 漏洞 ，它将 Twitter 的发布页面通过 iframe 嵌入到第三方页面，然后通过 CSS 使得并将 Twitter 的发布按钮与第三方页面的按钮重合。这样，当用户本意点击第三方页面的按钮时，实际上点击的是 Twitter 页面的发布按钮，进而造成攻击。

感叹：前端攻击方式也正逐渐的升级，防范前端代码的攻击不仅仅就是防范 Javascript 等前端脚本，CSS 甚至 HTML 也能构成攻击。

「精武门」安全峰会

「精武门」安全峰会是阿里巴巴集团组织的针对 Web 应用安全的研讨会。和往年讨论后台安全不同，今年重点着重讨论 Web 攻击的方式和防范。众多国内著名的安全小组集聚一堂，讨论目前国内 Web 应用的前端安全问题。

感叹：在见识了琳琅满目的攻击方式的同时，也引发了对于未来国内 Web 应用安全的思考。

后记

Web 2.0 以降，前端这个职位已从传统「美工」，蜕变成用户体验的实现者。然而随着浏览器提供的功能日益强大、各种 Web 应用的日趋复杂，安全这块被传统笼罩的「灰色地带」，也正进入每个前端开发工程师的视线。相信在不久的将来，前端开发工程师作为新生的安全力量，必占有十分重要的一席。

我们在编写 Javascript 时，Debug 是很痛苦的过程，而且有些语法问题虽使用 Firebug 能很快定位，但毕竟影响效率。

这里有个 Vim 插件，能使用 jsLint 帮助检查 Javascript 脚本中常见的语法错误，所以这篇文章可以帮助延长 F5 的寿命。

首先， 下载 jsLint ，解压缩到某个目录，然后将这个目录加入到 PATH 环境变量中。然后， 下载 Vim 的 jsLint 插件 ，将它扔到 Vim 的 plugin 目录中即可。

当保存编辑好的 Javascript 文件时，插件就会调用 jsLint 检查文件是否存在语法错误。当然可以配置相应的配置选项（更多的选项可以参考其 Vim 插件脚本内容），例如

" 指定 jsLint 调用路径，通常不用更改
let g:jslint_command = 'jsl'

" 指定 jsLint 的启动参数，可以指定相应的配置文件
let g:jslint_command_options = '-nofilelisting -nocontext -nosummary -nologo -process'

" 插件的主要调用方式
autocmd BufWritePost,FileWritePost *.js call JsonLint()

其实核心函数是 JsonLint() ，所以可以绑定快捷键，用于在任何时候检查错误。例如

map <C-s><C-j> :call JsonLint()<cr>

这样同时按 Ctrl + S、Ctrl + J 就可以检查 Javascript 语法有无问题了。

-- 更新 --

发现个不大不小的问题。就是在 Windows 环境中如果 Vim 本身设置了 utf-8 编码，由于与控制台编码不一致（控制台为 gbk 编码）造成 Javascript 文件在中文目录下不能正确启动 jsLint。

这里有个不完全的解决方案，更改对应的代码（从 34 行开始，加入判断）

  let jsl_command = g:jslint_command . ' ' . g:jslint_command_options . ' ' . current_file

  if has("win32") && v:lang == 'zh_CN.utf-8'
    let jsl_command = iconv(jsl_command, 'utf-8', 'gbk')
  endif

  let cmd_output = system(jsl_command)
  
  if has("win32") && v:lang == 'zh_CN.utf-8'
    let cmd_output = iconv(cmd_output, 'gbk', 'utf-8')
  endif

如果自行修改觉得麻烦， 就用我的修改后的插件吧 。