本文是一则硬广告。

上大学时跟同学一起办过一份音乐小报，名为《白桦林》，虽然只办了一期就夭折了，不过在这期小报上试图排版朴树那首《白桦林》的简谱（附带吉他和弦）的经历让人难以忘怀。我那时坚信自己用Word排版复杂版面的水平已经到了出神入化的程度，但还是被这个简谱排版工作打败了。Word虽然是“所见即所得”，但是那排版好的谱子打印出来时，总是会有那么些对不齐或者走样。那时学校打印店打印一页A4纸的价格是1.5元，不舍得反复打印试验，最终还是通过剪刀胶水才把这个排版任务搞定的。

《白桦林》小报第三版。由于Word版本和字体的原因，现在看到的跟当年排出来的效果有差别。

上大学时，经常玩一个叫HappyEO的电脑键盘模拟电子琴的软件——强势插入，再打个广告，HappyEO是用电脑键盘（也可以接MIDI键盘）模拟电子琴的最好的软件，没有之一。因为对这个软件的喜爱，我跟HappyEO的作者有着较多的交流，一路见证着HappyEO电子琴和后来的iDreamPiano模拟钢琴等软件的诞生。2003年时，他告诉我他做了一个简谱排版软件，叫JP-Word。

实话说，1.0的JP-Word一点也不诱人，粗糙的界面、鸡肋的图片输出和打印功能、封闭专有的文件格式实在不能让我提起太大的兴趣。加上对于我来说，平时几乎没有简谱排版的需求，所以对这个软件并没有太高的热情。接下来两三年时间，JP-Word慢慢升级到了3.0，功能丰富了一些，但没有什么本质的变化。

一下过了十年，JP-Word的作者突然告诉我，JP-Word出了4.0的新版本。这个脱胎换骨的新版本，着实可以用“惊艳”来形容。

JP-Word 4.0界面预览

不像五线谱打谱有自由的Lilypond，还有Overture、Encore等强大的商业软件。市面上简谱音乐软件并不多，优秀打谱软件更是少之又少。之所以我敢在文章标题上把JP-Word说成是“最好的”，个人认为主要有以下几点：

独创的的“切换音符时值组合”功能。常见音符的时值组合不用一个个手工调整，音符输入后按几下空格键就自动组合好了。
强大的歌词编辑功能。支持歌词自动对位，谱打完，歌词一打上去就自动对齐到它该去的地方。
支持矢量PDF的输出。而且排版结果不管是布局还是字体，都非常美观，放到专业环境下用也毫无压力。
开放的JPW-ABC格式。一改以前用专有格式的方式，新版本用了开放的纯文本来描述乐谱，为二次开发提供了便利。

JP-Word简谱编辑软件不是完全免费的，免费的版本只提供了部分主要的功能集，但折腾党可以通过手工写JPW-ABC的方式实现几乎全部收费版本的功能。

缺点也是有的，比如目前不支持直接播放乐谱和MIDI导出。不过Thanks to开放的JPW-ABC格式，完全可以写个简单的脚本，把JPW-ABC文件转换为MIDI文件。我正在尝试写个简单Python脚本，把JPW-ABC转换为Lilypond格式，然后借助Lilypond，可以直接生成对应的五线谱和MIDI文件。有兴趣可以关注我的Github项目jpw2lilypond，不过目前上面还只有一个很垃圾的Prototype（对象建模建错了，虽然基本功能在，但已经没办法往下写了），而且现在每天的时间都不够用，开发进度一定不会很快。

JP-Word 4.0的功能介绍与使用说明：http://www.happyeo.com/intro_jpw.htm

下载JP-Word 4.0免费版的地址：http://www.happyeo.com/downloads_jpw.htm

注册JP-Word的方法：http://www.happyeo.com/register_jpw4.htm

赶个时髦，把自己的博客进行了全站HTTPS改造，并升级支持了HTTP/2，总结在此，当作备忘。

很惭愧，虽然曾经做过几年Web安全产品，其实我自己并没有非常深入的去理解和思考Web安全更多内在的东西，所以可能文中的部分描述并不完全准确。很多内容参考了Jerry Qu的博客上的内容，都以参考文献的方式列在文章中，我这里只写结论，技术细节可以参考他的原文。

动因

HTTPS改造的好处当然是更安全。虽然对于一个博客网站来说，“安全”似乎并不是一个非常重要的因素，但是以国内现实的情况来说，使用HTTPS提供网站服务有一个好处就是可以避免网络运营商篡改网页内容（比如插入弹出广告）——其实吧，HTTPS以后，Chrome浏览器地址栏显示的绿色小锁才是吸引我迁移的真正原因，挺好看的。

HTTP/2从协议层面消除了传统HTTP的一些不足和缺陷，对我来说，直接的好处就是可以大幅度提高网页载入的速度。有关HTTP/2的前世今生，可以参考以下文章[1]。

HTTPS改造

证书

HTTPS改造的一个基本要素就是证书，在传统上有很多认证机构（CA）可以收费签发证书，比如大名鼎鼎的Verisign。现在也有很多公司可以提供免费或者廉价的证书，比如有名的StartSSL，以及最近很火的Let’s Encrypt。

我先是尝试了StartSSL的免费证书，但是它只能签发有效期一年的免费证书，每年都得手动去更新证书是一件很让人头痛的事情。所以后来选定了使用Let’s Encrypt，虽然Let’s Encrypt的证书有效期只有三个月，但是可以方便的通过脚本来实现自动更新。

使用Let’s Encrypt的证书有两种方式，一种是使用他的提供的工具脚本，另一种是使用ACME协议。我目前使用的是ACME协议方式，参考[2]。如果用Let’s Encrypt的工具，参考[3]。我个人比较喜欢ACME协议方式，因为很轻量级，Let’s Encrypt自己的工具太过“全家桶”了，不够简洁明了。

主要的步骤如下：

生成一个帐号私钥
$ openssl genrsa 4096 > account.key
生成一个域名私钥
$ openssl genrsa 4096 > domain.key
生成证书签名请求CSR文件，通常至少包含祼域名和带www主机名的两个域名。
$ openssl req -new -sha256 -key domain.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:yoursite.com,DNS:www.yoursite.com")) > domain.csr
在自己网站上配置一个可以从外部访问的目录，用来完成challenge。Let’s Encrypt会生成一个文件，你把它放在这个目录里，然后Let’s Encrypt如果能访问到这个文件，就证明了这个域名是属于你的。nginx配置类似于如下，配在80端口的Server里面：
location ^~ /.well-known/acme-challenge/ { alias /home/xxx/www/challenges/; try_files $uri =404; }
下载acme_tiny脚本，并运行，里面用到了帐号私钥（account.key）、域名私钥（domain.key）、CSR文件（domain.csr）和ACME challenge的路径，生成签发的证书（signed.crt）。
$ wget https://raw.githubusercontent.com/diafygi/acme-tiny/master/acme_tiny.py $ python acme_tiny.py --account-key ./account.key --csr ./domain.csr --acme-dir /home/xxx/www/challenges/ > ./signed.crt
最后合并Let’s Encrypt的中间证书和我们自己的证书：
$ wget -O - https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem > intermediate.pem $ cat signed.crt intermediate.pem > chained.pem

Web服务器

我使用nginx作为Web服务器，启用HTTPS服务，只需要在原来的HTTP服务上加几行配置就可以了：

listen 443 ssl; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft: EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256: EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; ssl_certificate /home/user/path/to/your/chained.pem; ssl_certificate_key /home/user/path/to/your/domain.key; ssl_session_timeout 5m;

其中需要用到你自己网站的私钥domain.key，还有Let’s Encrypt给你签发并合并了中间证书的证书文件chained.pem。

SSL协议版本与加密算法

我上面的配置用的是CloudFlare推荐的配置，详细的讨论可以参考[4]。我这么配基本上放弃了对Windows XP + IE6的支持，但可以让Qualys SSL Labs给出的评分提高到A级。

WordPress

我的博客是用WordPress构建的，WordPress在很多地方都会把带协议的网站URL给存下来，造成无法透明的把HTTP改成HTTPS。暴力解决方法就是去它的数据库做全文替换[5]。

先把WordPress设置->常规中的两个URL设置改为https，然后去WordPress的数据库对已有的文章进行全局字符串替换：

UPDATE `<wordpress_prefix>_posts` SET post_content= (REPLACE (post_content, 'http://[domain name]', 'https://[domain name]'));

其它页面嵌入内容

如果在HTTPS的页面上嵌入了非HTTPS的内容，比如跨站的HTTP图片，浏览器上的绿色小锁就会变成灰色了。如果是跨站的CSS或者JavaScript，在现代浏览器上可能会直接被禁止加载[6]。

解决的方案就是把src的协议去掉，直接写成//domain.com/path/to/image这样的形式，可以兼容HTTP和HTTPS。

但是有些源站根本就不支持HTTPS，或者虽然提供了HTTPS服务，但证书不合法，这么做就行不通了。比如我的页面右侧的饭否的图片，虽然饭否有HTTPS服务，但证书过期了，直接嵌入就会有问题。

我的解决方案也是简单粗暴的，直接在nginx里为这些网站相关URL做一个反向代理。比如，为了解决饭否图片的问题，我在我的nginx里加了以下配置，然后把饭否图片的域名换成我自己的域名：

location /u { proxy_pass http://b.fanfou.com; proxy_set_header Host b.fanfou.com; proxy_redirect off; }

自动重定向HTTP请求

至此，HTTPS改造已经准备好了，重启nginx后就可以用HTTPS协议来访问网站，检查是否工作正常。主要检查证书是不是正常，另外还有看看有没有混杂非HTTPS资源造成页面加载不正常的。Chrome的Developer Tools可以帮助你排查这些问题。

如果一切正常，就可以考虑自动重定向所有的HTTP请求了，301跳转通常是最理想的方式。在nginx的80端口http服务器配置中添加以下的内容：

location / { return 301 https://$server_name$request_uri; }

其它要考虑的问题

SNI：如果在nginx用server_name实现了单主机的多虚拟站点，那就会出现一个IP地址上对应多个域名的情况，这时服务器和客户端都需要支持SNI，才能在HTTPS的情况下正常工作。较新版本的nginx版本服务器都是支持SNI的，但IE6之类的老旧浏览器不支持。所以如果放弃老旧浏览器支持的话，SNI不是个问题。否则就只能保证在同一个IP上只启用一个域名的HTTPS网站，才能确保客户访问无障碍。

HSTS：虽然启用了HTTPS，但是用户在访问时如果没有显式输入https协议，现在的浏览器默认还是会先选用http协议，再由服务器进行301/302跳转，这时就有可能被劫持。目前的解决方案是在自己的网站上输出HSTS头，并把自己的域名加入HSTS Preload List列表里[6]。我没有启用HSTS，因为一但启用没办法撤销，万一以后不能提供HTTPS服务了，想降级为HTTP都没有机会了。

其它：对于个人小网站来说，也许前面的讨论基本够用。但对稍大的网站来说，要考虑的问题还有更多。比如：CDN支持、各子域名证书的管理模式、SHA1不安全证书与老版本浏览器兼容性、大量非HTTPS外部资源的处理、特殊客户端不支持302引流等等。