向大家表示歉意，2月10日～3月5日期间的评论，有大约一半会丢失。另一半，是我在服务器宕机的当天，从百度缓存里复制的，然后手工一条一条复原。百度缓存对每篇博客，有个时间节点，所以声明：有时候会出现某一楼之后的评论会全部丢失，并非是我删除了。

有必要说一下这家国人的VPS商(主要做香港/日本/韩国/美国的服务器)，是史上最便宜的香港VPS。从去年8月到今年3月5日事发前，一直相当稳定。1个多月前，已经有网友反映日本服务器已经宕机多天还没处理。

3月5日，我的VPS突然不能访问，然后去他们的网站看通知。通知是请在明天以前做备份，服务器要迁移。也就是3月5日是可以做备份的，但是3月5日已经彻底宕机，无法拿到数据。

等不了他们了
已经等了7天，现在等不了了，当天给他们发的工单、QQ消息，至今未回。他们的网站，以前的联系方式，是国内的136手机号，还能联系到。3月5日，发现他们唯一的电话是+1的国外号码。已经完全失联，看来跑路无疑，已经凉透了。

我的2个空间还剩余4个月的使用时间。剩下的钱不可退回来，也不做这个要求，只希望拿回数据。

倒闭前的人文(人性)处理方式
但是这一家，连给用户备份数据这一点都做不到。只要稍微有一点人性，可以事先发邮件通知，我的邮箱里没有邮件通知。而且因为垃圾邮件、催费邮件多，所以我平时也不看邮箱。

或者他们可以提前一天关闭客户的服务器一段时间，然后客户肯定会去看他们的网站上的通知，提醒用户在约定的时间里，备份数据。

这样的事情，同样发生在去年的一家便宜VPS。之前都较稳定，然后突然跑路，数据也拿不回来。

这一家，在日本服务器宕机的期间，编造日本地(隔开)震的谎(隔开)言：地(隔开)震影响了他们的服务器。

最近很忙
因为最近很忙，加上博客丢失了将近一个月的数据，所以更不想写博客了，写博客也“耽误”不少时间。因为受疫(隔开)情的影响，孩子每天的网课，我需要花更多的时间参与。

现在我已经把2月写的10篇博客都复原了，是宕机的当天，从百度缓存里复制的。但是，有2篇没有被收录，只能从本机里找了。因为我每次发博客之后，都需要编辑至少10-20次，本机的文章都是编辑之前的文章，这2篇要复原基本不可能了。

分布式论坛
独立微博程序还没有时间开工，却又萌生一个编写开源的分布式论坛的想法。写开源程序，是我的一个人生使命──必须有作品，哪怕是0收入。独立微博程序的开发周期，从0开始编写直到上线，约为4-6个月的全天工作日，约900-1500小时以上的编程时间，我的眼睛……分布式论坛的开发工作量，估计与此不相上下。

这决不是重复开发wheel。虽然有一部分名词听起来并不是新词，或者是老掉牙了。但是，确实有其存在的重要意义，有刚需的新功能。这种分布式论坛，也是我设想中的一个新玩法，国内外应该还尚未有这种玩法，就是架设在用户虚拟主机、或VPS上的论坛/讨论组，域名由我方提供，或者由用户申请备用域名(为了数据安全，不要用博客的域名)。

或许有人说，国内外论坛程序，已经有很多很多了。

但这种程序有所不同，类似于Web版的微信群、QQ群的功能，想做什么样的形式，都能做出来，只是开发者工作时间长短的问题。2009年初我从0开发的t(隔开)g(隔开)for论坛，就是这种形式，既能当论坛、也能当讨论组使用。

但是，当时的这个论坛，并非现在设想中的分布式。这个分布式的含义，是虚拟主机/VPS，由用户自己提供。

而且，可以随着用户的需求，将多个论坛关联起来，使服务器之间产生数据上的互动。

分布式的优点是：数据并非集中，分布广泛，所以相对安全很多。

铁血算法
“铁血”，我暂时想不出来有更恰当的词语。因为wall是一年比一年高了，导致我越来越多地使用“隔开”体。铁血算法，就是将数据进行加密，用户看到时再还原。

被几乎所有人认为现在最安全的HTTPS，其实早晚有一天是会失去其安全意义的，也就是原先的安全功能在某种情况下会形同虚设。而且就是在HTTPS刚出来不久，实时传输中就可以破解其安全级别。

思路是，虽然HTTPS在路由服务器当中是加密传输，但是URL本身是明文的，在路由服务器中，URL都是可见的。某个路由服务器获取URL后，在服务器上设计一个客户端软件，甚至用wget，就可以获取这页的内容。除非这些web，是使用需要Cookies才能访问的页面，那么路由服务器，才无法获取这页的内容。

所以，实质上，对于不需要Cookies就能访问的大多数web页，HTTPS早晚会形同虚设。而且，HTTPS开发者在开发之初，没有考虑到150ms以上跨国间的服务器，https访问会很慢。

最好的解决办法，就是web开发者自行将文字进行加密。效率最高、最节省客户端CPU资源的办法，就是将文字在(程序语句产生的)HTML页的数据中，将正文内容的文字的顺序打乱，然后用JavaScript还原，称为“铁血算法”。

这种打乱文字顺序的方式，在实时传输中，是不可能被路由服务器获取原文信息的，除非使用一个高度通用的相同公式，路由服务器用此公式进行还原，这个机率无限无限接近0。

但是，这种打乱文字顺序、再用JavaScript还原的方式，怕搜索引擎。因为在大约10年前的搜索引擎，是忽略JavaScript产生的数据的。如今的搜索引擎，JavaScript产生的数据，只要用户看到的是什么数据，搜索引擎抓取到的数据，就是和JavaScript产生的数据是一样的。(CSS的display:none里的内容，暂时可当“隔开”体使用。)

因此，还需要用更高级的办法，来避开搜索引擎。

2020-03-14 09:25更新：
今天服务器又恢复了，赶紧下载了备份，2月10日～3月5日的数据都已恢复。