这个周末，俺再次升级了博客的评论系统。主要增加了2个新功能：
1. 简化评论中贴图的操作（【无需】再写 BBCode 语法）
2. 对读者在评论中的贴图，采用“图片代理”的方式加载，以防范潜在的隐私风险。
　　今天发这篇博文，除了跟大伙儿打个招呼，顺便也介绍一下上述两条的技术实现。

★新功能介绍——关于博客评论的【智能贴图】

◇原先的贴图方案——BBCode

　　俺在2012年为博客的评论系统增加了“BBCode 语法”。当时就支持了“评论嵌入图片”。语法是：

[img]图片网址[/img]

　　其实这个语法还是挺简单滴。但是很多读者（尤其是新来的）并不知道这个贴图的语法。另外，最近一年来，留言的读者越来越多，贴图的人也越来越多。所以俺就想简化一下贴图的操作。

◇新的贴图方案——智能识别图片网址

　　目前的“智能贴图”方案是：
　　你只需把图片的网址贴到评论中，就可以了。评论系统的 JS 脚本会智能地判断这个网址是否对应图片。如果是，就把图片嵌入到评论中。

　　那么，JS 脚本如何判断某个网址是否为图片捏？
　　首先，假如网址以如下扩展名结尾，俺就认为该网址是“图片网址”

.jpg .jpeg .png .gif

　　但是某些知名网站（比如 Twitter）的图床，其图片网址的结尾，并不是上述形式，咋办捏？
　　于是俺又补充了一个功能——对知名网站的图床进行识别。

◇原有的“图片 BBCode 语法”依然保留

　　有了新方案之后，大部分图片网址都可以识别出来。但是俺做不到 100% 的智能识别率。所以，原有的语法（[img]图片网址[/img]）还是继续保留。
　　万一你贴的图没有被智能识别出来，就继续用原先的贴图方式。

★关于“评论贴图”的【隐私问题】

　　由于俺博客的评论系统是开放的，任何人（包括匿名用户）都可以在评论中贴图。于是就引入了潜在的安全风险（隐私风险）。

◇产生隐私的技术原因

　　当某个读者在评论中贴图，评论内容只是包含了图片的链接（网址），图片文件本身仍然存储在原先的图片服务器上。
　　假设你访问了俺博客的页面，评论被加载，这时候，评论中的图片也会被加载。于是，你的浏览器就会向图片服务器发起一个 HTTP 请求（HTTP request），图片服务器收到请求，就把图片文件传输到你的浏览器（HTTP response）。这一来一回，图片服务器就能看到你的某些信息：
访问者IP
（如果你通过代理访问俺博客，“访问者IP”就是代理服务器的IP；如果没有走代理（比如墙外读者），“访问者IP”就是你的公网IP）
浏览器指纹（User Agent）
（何为“浏览器指纹”，请参见《如何保护隐私[5]：扫盲“浏览器指纹”》）
浏览器 cookie
（从技术上讲，图片服务器可以针对访问者的浏览器，读取或写入 cookie）
HTTP referer
（何为“HTTP referer”，可以参见维基百科的“这个页面”）
访问者的访问量
（图片服务器可以知道有多少“人次”查看了该图片，每次查看分别发生在哪些时间点）

◇上述风险如何被歹人利用？

　　假设某个朝廷的走狗，想要收集俺博客读者的信息，那么此人可以自己搭建一个图片服务器，把某个热门的图片放在自己的服务器上。然后把图片网址贴到俺博客的评论中。
　　由于该服务器是走狗自己搭建的，于是这个走狗就可以详细了解服务器上该图片的访问日志（哪些IP分别在哪些时间，访问了该图片，使用的是哪种浏览器、哪种操作系统）。

★上述隐私问题的【解决方法】

◇原先的防范措施——界面定制选项

　　去年10月份，俺进行过一次大规模的界面改版。当时也包括对评论系统的升级。在那次改版时，某个热心的香港读者向俺提出了上述隐私风险的警告。因为他在香港，无需翻墙代理就可以看俺博客。于是他就担心自己的“公网IP”被图片服务器收集。
　　当时俺采用的应对措施是：在博客的“界面定制选项”中，增加了一项“评论嵌入图片的显示方式”（自动显示、手动显示、不显示）。
　　对于有所顾忌的读者，可以设定为“不显示”。

　　但是这个措施不够完美——假如某个读者既想看别人的贴图，但是又担心隐私风险。咋办捏？

◇如今的防范措施——图片代理

　　上周五，又有一个读者在博客留言中提到了“贴图的隐私风险”。这迫使俺重新考虑更完美的防范措施。后来俺想到一个新的招数——通过“在线图片代理”。
　　所谓的“在线图片代理”有点类似于“Web 代理”，差别在于——“Web 代理”可以处理整个网页，而“在线图片代理”只能处理图片。
　　采用了这个方案之后，如果有读者在评论中贴图，俺博客的页面上【不会】直接加载该图片，而是通过图片代理【间接】加载。在这种模式下，读者的浏览器访问的是“图片代理的服务器”，然后由“图片代理的服务器”去访问“图片服务器”。
　　由此可见，你的浏览器【不会】直接跟“图片服务器”打交道——即使“图片服务器”有收集隐私的企图，也无法收集到你的隐私。

　　顺便说一下：
　　大约一年前（2013年12月），Gmail 也开始采用图片代理的方式，来显示邮件正文嵌入的图片。

★“图片代理”的【额外】好处——防“真理部的河蟹”

　　这次俺用的图片代理，应该是支持“缓存”的（由于这两天忙着改代码，尚未进行测试验证）。
　　如果确实有缓存，那会带来一个额外的好处（如下）。
　　比如经常有读者在俺博客评论中转贴新浪的长微博。这些转贴的长微博，很多都是政治敏感内容，有可能在将来会被新浪删除。一旦删除了，网友就无法再打开长微博的网址。假如俺用的“图片代理”具备缓存功能，那么即使原图已经被删除，你还是可以通过图片代理，把图片显示出来。

★两个“图片代理服务”的技术说明

　　（本章节面向 Web 开发人员。不懂技术的同学，可以略过）

◇使用说明

　　这次升级，一开始俺找到的是 CloudFlare 旗下的图片代理（使用说明参见其主页：https://images.weserv.nl/）。
　　后来某个热心读者推荐了 Google 的图片代理。Google 的这个图片代理，貌似没有对外公开，知道的人应该不多。有个老外写了一篇简单的使用说明（在“这里”）
　　经过权衡之后，俺最终用的是 Google 的图片代理。

◇两者的优缺点对比

　　下面说说这两个代理的优缺点对比。供有兴趣的开发人员参考。

Google 图片代理的相对优势
1.
因为俺博客本身就用的是 Google 的博客平台。Google 的服务器本来就可以收集到俺博客访问者的信息。
如今再使用 Google 的图片代理，【不会】增加额外的隐私泄露。
反之，如果用了 CloudFlare 的图片代理，CloudFlare 可以收集到俺博客访问者的信息（增加了泄漏量）。

2.
Google 的图片代理，对 TOR 用户是友好的。
反之，CloudFlare 的图片代理，如果碰到访问者是 TOR 用户，（有很大概率）会让你输入验证码。

3.
Google 的骨气比 CloudFlare 硬一些。
其实 CloudFlare 的骨气也不算太差——去年香港占中公投的网站遭遇朝廷御用骇客的 DDOS 攻击，就是由 CloudFlare 提供对抗手段。

CloudFlare 图片代理的相对优势

1.
CloudFlare 图片代理是对外公开的，应该会长时间提供服务。
而 Google 的图片代理不是对外公开的，仅仅是提供给 G+ 内部使用的。
俺不晓得 Google 的这个代理，将来是否会发生变化。

2.
CloudFlare 图片代理的功能比较全。
比如它支持：图片格式转换、裁边框、调整 JPEG 格式的 quality、等等。
上述这些功能，Google 的图片代理都没有。

★结尾

　　针对这次功能升级，欢迎大伙儿提出更多的建议 :)
　　另外，
　　有了智能贴图之后，俺也欢迎大伙儿把一些容易被河蟹的内容（政治敏感的长微博、热点事件照片），转贴在俺博客的评论区。


俺博客上，和本文相关的帖子（需翻墙）：
博客评论功能升级（“未读”状态、按时间过滤）——兼谈“为啥俺不用其它博客平台”
博客评论功能升级（增加“留言过滤”、“200条之后自动加载”等）
博客评论功能升级（引入 BBCode 语法），顺便分享一下实现方法