HTML5 <video>标签在不同浏览器中的表现

<video>是HTML5新增的一个标签，它使得用户可以在浏览器中，不借助任何第三方插件就可以播放服务器上的视频。同时，与<video>类似地，<audio>标签也可以在浏览器中直接播放音频。

使用i-jetty架设服务器及部署程序中的若干问题

由于索尼悄悄地在我的PS+会员到期后自动帮我续费，因此觉得不把《重力眩晕》白金了真是白白浪费一个月的会员费。1号深夜终于拿到了白金。随后而来的问题是：在我校恶劣的网络条件下，如何快速地向朋友们得瑟。

其来有自的音乐库（6）

今天暂且算是闲下来，填填坑。最近各种结课，各种写论文和看文献，真是令人烦躁。

WHITE ALBUM －綴られる冬の想い出－ Original Soundtrack CUE文件

在网上下载了 WHITE ALBUM －綴られる冬の想い出－ Original Soundtrack 这张专辑（flac），但却没有CUE。发现很多人都在求这个CUE，澄空的链接失效了，KFC上有人搞出来个，结果却没有共享。今天花了1个小时写了个生成CUE的小程序，把这张专辑的CUE生成出来了。

其来有自的音乐库（5）

导师一出差我就各种嗨，居然接连两天写博。那么今天继续我的大坑。

Smack 开发笔记（1）

上个月接到一个任务——开发一个XMPP客户端，准确地说来，是用XMPP协议实现在两台计算机之间互发消息。我建议用Java，因为我知道大Java不管什么东西，总有5个以上的开源解决方案。于是选了Openfire作服务器，Smack 3.3来开发客户端。

国庆参考了几篇博客文章[1][2][3]，写了个控制台下的客户端，可以实现简单地收发消息。
综合这几篇文章，为了实现一个XMPP客户端的消息收发功能，我封装了一个Client.java类，其成员变量及方法如下（省略了具体实现代码，后面会详细说明）：

Android差在哪儿？

前几天手机突然变砖，趁着这几天的假期，反反复复刷了3次。因此而带来的数次重装App、同步联系人等着实把我折腾得够呛。我也用过iOS，这里我尝试列举一些Android的缺点。

1. 缺少一个官方的管理软件。

   苹果有iTunes，可以方便地管理iOS设备、媒体文件、App。但Google却始终不愿意推出一个官方的、类似iTunes的同步软件，哪怕没有媒体文件管理功能。没有原生地支持，搞得每个第三方同步软件争先恐后地往手机上装自家的连接软件。通常这些连接App又申请了相当数量且与个人隐私密切相关的权限（例如读取联系人、读取短信、电话记录等），Google都身陷棱镜门，这些国内公司又有几个敢拍胸脯保证自己绝不窃取用户隐私？

其来有自的音乐库（4）

距离该系列上一篇文章已经过去很久了。功夫网的阻隔是个很大的问题。但我还是尽量坚持更新博文。

1. CHEMISTRY - regeneration
   

   CHEMISTRY，中文名称是化学超男子。《战场女武神2》的OP《Our Stroy》收录于这张专辑中。刚下载这张专辑的时候感觉还不错，现在常听的也就只有《Our Story》和《Life goes on ~Side D~》。战场女武神系列游戏都非常棒，一代和三代的难度都比较高。我还专门买了一张一代的游戏光碟用作收藏，这也是我唯一的一张PS3游戏光碟。最近听说一代汉化开坑，甚是高兴。

在IIS 7中使用HTTPS连接

做毕设的过程中，希望能使用Https安全连接。在网上查阅了相关资料，发现仅是以调试、测试目的而启用Https连接是相当简单的。

首先，需要解释一下Https,TSL,SSL以及证书的关系。我们知道，HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2，定义在RFC 5246中，暂时还没有被广泛的使用。

Date.parse()在Chrome，FireFox，IE中的差异

我翻了好几篇关于Javascript中Date.parse()方法的博文。它们着重讲的是日期格式的问题，需要以Date.parse("MM/dd/yyyy HH:mm:ss")这样的形式方能在3种浏览器中正确运行。最近在做一个需要实时绘图的项目，其时间精确到毫秒，这时Date.parse()在3个浏览器中就有了不同的表现。请看以下代码：

var now=Date.parse("05/12/2013 15:24:27.53");

这行代码在Chrome里可以正确运行时间的毫秒部分也能正确地被转换。但同样的代码到了FF和IE里就报错了。经过排除，确认是这两种浏览器的Date.parse()方法最多支持到秒级。后来我又尝试了"05/12/2013 15:24:27,53","05/12/2013 15:24:27 53","05/12/2013 15:24:27,530","05/12/2013 15:24:27 530"等形式的字符串，均无法正确地在FF和IE中转换。如果要想解决这个问题，只好采取一种很别扭的方法：把字符串从秒处截断，前面的部分在3个浏览器中都可以正确转换。转换完毕后把后一部分再加上。