nohup

Linux的常识知道得太少了,需要不断累积一下。

最近有一些批量任务需要花费较多的时间来运行,但总不可能开着终端一种挂着吧?之前知道在命令后面再加个 & 就可以让任务在后台执行,本以为这样就OK万事大吉了,谁知道关掉终端后重新打开,发现任务居然中止了!

OMG,原来通过 & 并不能解决问题!断开终端后,通过 & 在后台运行的进程也会跟着中止,这时候就需要使用nohup(no hang up)这个命令了,通过nohup命令,可以让任务一直在后台运行,就算断开终端,任务仍然会继续执行。

又长见识了,哎,继续找出没有做完的任务重新跑吧,悲剧啊!

Content-Type 引发的血案

最近一个页面用到了my97datepicker日期控件,奇怪的是IE下控件很正常,但是在FF下控件死活出不来,点击没有任何反应,抓破头皮也想不出个所以然来。一时心血来潮想看看是不是JS有写错,打开FF的错误控制台调试了下,结果发现这么个错误:

错误: 样式表单 xxx 未载入,因为它的MIME类型 "text/html" 不是 "text/css"

奇怪啊,文件名明明是.css结尾的,怎么MIME类型是text/html呢?看了下服务器resin和apache的配置,MIME类型的映射关系配置项居然大部分给注释了!OMG!难怪MIME类型不对了!把映射关系加回去后果然在FF下一切正常了。

谨防IE缓存请求

最近写一块通过ajax请求验证码的代码时发现,在FF和Chrome下都可以正常更换验证码,但在IE下获取了一次验证码之后就无法再刷新验证码了。
后来抓包发现,IE获取了一次验证码后就没有再发请求到服务端了,之后的请求都通过缓存直接返回了。
缓存静态资源倒还说得过去,缓存.jsp、.do等也太恶心了点,不知道IE是否可以设置缓存策略。不过写这些代码的时候最好注意一下,在这些请求后面都带上一个随机数就OK了,这样确保每次请求都会发到服务端。

Javamail处理一些未知的编码

查看邮件信头的时候有时会看到x-gbk、hz-gb-2312等编码,然而这些编码javamail并不能识别出来。但是看名称感觉又似曾相识,尝试把x-gbk的编码改成gbk、hz-gb-2312改成gb2312后javamail又能解码出来。虽然并不知道x-gbk、hz-gb-2312是否和gbk、gb2312的标准有什么不同,或者仅仅只是这些编码的别名而已,但是的确可以通过把x-gbk映射成gbk来解决一些编码问题。那么一种便捷的做法便是通过往javamail的javamail.charset.map文件里添加x-gbk到gbk的映射关系,这样就可以对x-gbk进行解码了。

PS:通过findbugs发现,javax.mail.internet.MimeUtility里居然有一行代码是通过==来判断字符串是否相同。囧rz

Java添加UTF-7字符集支持

这段时间在做PushServer时,需要对编码过的邮件标题及发信人进行解码,然而开发的时候发现Javamail无法对UTF-7等编码解码,会抛出UnsupportedEncodingException。查看过JDK中rt.jar的部分代码,也看过javamail的部分代码,总结原因如下:JDK本身并不支持UTF-7字符集。关于这个bug(传送门),很早之前就有人反馈过给SUN了,但SUN已经明确表示不会修复这个bug,所以要想支持UTF-7字符集就必须自己写对应的Charset。

当然,秉承不重复发明轮子的精神,如果有人已经提供了这样的类的话我们就没必要再自己重新实现了。确实已经有人做了这样的事,jcharset(传送门)这个项目已经提供了UTF-7、UTF-7-OPTIONAL等字符集的实现方式,只需要下载jcharset.jar并将其放到${JAVA_HOME}/jre/lib/ext/下即可(这是SUN JRE的一个bug),这样就已经可以对UTF-7编码的字符串进行解码了。需要注意的是jcharset项目是在GPL许可下发布的,若只是需要添加UTF-7字符集的支持的话,可以考虑jutf7项目(传送门),这个项目是在MIT许可下发布的,这样做2次开发之类的都方便。若需要自己添加其他字符集的支持,可以参考jcharset、jutf7等项目。