去年把Arsue Blog下线，有一个原因是能够持续维护的时间太少，所以转战到没有竞争的微博程序。从事这些超高工作量的工作，结果往往并不乐观，而且它本身是很难赢利的，所以变成了非赢利项目。创业中有一句话说“干得累，都不对”，几乎稍微有点工作量的程序，都会干得累，何况是超高工作量。

“干得累，都不对”的另一个含义是，作为创业人、老板，要把累的工作找别人干、花钱找别人干。所以对于工作量很高的事情，很少人愿意干。这就是独立开发者工作中的一个大背景。

这类日志类、发布版公用程序需要面临的挑战和(各种工作中的脏活儿、累活儿的)问题：

1. PHP 5和PHP 7的兼容性问题。
此问题已彻底解决。直接在PHP 7下开发，100%不使用PHP 7特殊语法，使用PHP 7、PHP 5都兼容的语法，这样可以在PHP 5、PHP 7平台下完美运行。

PHP 5优点：更省内存，安装方便。
PHP 7优点：运行速度更快。

如之前的详细测试，在服务器上，PHP 7.4速度约是PHP 5.3的10～12倍；PHP 7.4速度约是PHP 5.5、PHP 5.6的5倍。
Debian/Ubuntu下，PHP 7.4速度约是PHP 7.3的1.9～2.1倍。
PHP 7.0～PHP 7.3，速度差异很小。

虽然测试的结果，速度差异很大。但并不表示PHP 5速度慢，至今我仍然使用PHP 5，也有一些项目用了几个月的时间，已经改为PHP 7语法，运行在PHP 7.4。
PHP 5.3，其实也很快。

2. HTML 5和HTML 4、HTML兼容性问题。
HTML几乎可以支持所有浏览器，而且支持CSS 3。
HTML 5有很多浏览器不支持，但是HTML 5是很多使用者喜爱的。
因此，开发中，同时开发HTML、HTML 5两个版本，可供用户下载。

(注：HTML 5还有个问题是必须用.css的真静态文件，不支持动态页、不支持伪静态的.css，所以为开发带来麻烦。
比如动态的CSS，可以在程序文件里判断PC、手机浏览器，产生相应的CSS代码。HTML 5只能分别写成PC版、手机版2个静态的CSS文件。)

3. UTF-8、GBK编码的取舍。
随着国外开发者编写的程序在国内的广泛应用，UTF-8编码在国内的使用率越来越高，就连很多国内开发者编写的程序也使用UTF-8编码。

其实UTF-8编码目前并非是世界统一的编码，因为一些纯英文的操作系统如果没有安装中文包，UTF-8编码下的中文依然显示乱码，例如CentOS英文版+火狐60。

对于中文站点，将来流量大的站点，GBK编码(ANSI编码)还是可以提高不少性能。一个中文全角字符，UTF-8编码占3个字节，GBK编码占2个字节。能提高多少性能，较难估计，在高流量的环境里，也许速度影响不大，也许是N倍的差距。但是，数据库的存储体积的变化是很可观的。

由于UTF-8是很多使用者喜爱的，所以标准版均使用UTF-8编码。

开发中，同时推出一个GBK编码，可供用户下载。这类GBK编码，将有一个新的名称，用户都喜欢高端的东西，所以GBK编码版命名为“内部高级版”。其实GBK编码对于中文站点来说更加高端，因为它能提高不少主机性能。

什么情况下，非英文站点必须用UTF-8编码呢？韩文站点。因为每个韩文全角字符，如果在ANSI编码下，会占用8个字节，比如한字，以한这样的形式。
每个韩文全角字符，在UTF-8编码下占用3个字节。

日文站点的编码，全角字符同样占2个字节。
日文在UTF-8编码下，全角字符占3个字节。

而英文半角字符，无论是UTF-8还是ANSI编码，都占用1个字节。

因此，非英文站点，韩文必须使用UTF-8编码可节省很多字节，中文使用GBK编码可节省很多字节。

GBK编码版，我在项目中，在HTML代码中，把它伪装成了UTF-8编码，以满足用户的审美需求。看起来像是UTF-8编码，实际是GBK编码。例如Feedval的中文版网站 http://cn.feedval.com

HTML代码里有这样一句：
<meta http-equiv=Content-Type content=text/html;charcus=utf-8>

这句话的作用只用于美观，其实它并不起作用。因为正确的语句是charset，这里改为charcus。

改为在服务器端设置编码：
<?header('Content-Type:text/html;charset=gbk');?>

4. 删除HTML回行的问题
在开发中，一个回车符占用2个字节，所以这些年我写的HTML代码，都把回车符去掉了，这种方式习惯后其实完全不会降低可读性。这是因为，程序、HTML都不是用来读的，而用来分析前后的关联关系。

解决的方案是，我几年前在本机编写了一个代码的闭合分析工具，非常非常好用，将来会发布在Eonval平台，有了这个工具，可以瞬间分析出所有的<div>和</div>对应的位置，比很多传统的缩进还要快很多，一次的自动分析，至少可以节省人工分析5-30分钟。

同时，也能自定义任何标签，分析这些标签的起始位置。
对于PHP的花括号、Shell程序的if和fi的起始位置，同样能够瞬间分析出来。

对于不喜欢删除HTML回行的用户，在这类发布的公共版程序，标准版是没有删除HTML回行。而“内部高级版”，是删除了HTML回行的更高效运行的版本。

5. 浏览器的兼容性问题
现在主要是在Firefox下开发。另外，开发中大部分功能也在Chrome、安卓浏览器、IE、IOS的Safari下测试HTML、CSS、JavaScript的兼容性。目前大部分是兼容的，只遇到少量功能在IE中反而不支持。

总结：
大多用户并不怎么喜欢关注技术。因为研究技术，需要做大量的测试、实地开发，是一个非常花费时间的过程。
所以很多用户，流行什么，就用什么。

很多最新流行的平台，未必是最好的。就拿HTTPS为例，去年我写了《详解99.9%的网站没必要用https》，至今挂了一年多。写这篇博客，是为了呼吁挽回HTTP的尊严。这里做了HTTPS的多组站外响应测试，HTTPS的多路复用跑分测试。测试的结果，HTTP总是比HTTPS快。在多路复用中，HTTPS并没有传说中的快，反而是多图片加载中，HTTP比HTTPS稍快一点。

如果主机使用大陆、香港或者亚洲的机房，HTTPS基本上速度影响不大。但是使用美国主机在白天，或者美国主机在晚上的网络高峰，大家可以去掉301跳转，分别测试HTTP、HTTPS，HTTP明显比HTTPS快、稳定很多，而且不是一、两倍的差距，总体可能慢了四、五倍以上。

很多资深的开发者说HTTPS比HTTP多占用40%的CPU资源，我非常赞赏这种实事求是、勇于探索、不人云亦云、不随波逐流的精神。

实际运行中，即使多占用了10%、20%的资源，在流量稍微大一点的环境中，速度可能慢了不是10%、20%这样的比例关系，这个数值会一直变化，有可能会慢几倍，也可能会低于10%。

总之，如果不是涉及到金融系统、会员系统，一个博客，大多数的站点没有必要使用HTTPS。很多人使用HTTPS，有一个原因是防落伍、随大流、美观，也有的人是为了HTTPS而HTTPS。
当然，也有很多用户是出于不想在实时传输中被某些人截获数据。但是，对于已经生成的博客页面，某些人是可以通过搜索引擎等方法搜到敏(隔开)感(隔开)词的。
大多数的企业站点，没有必要使用HTTPS。

前年分享过的会员登录加密方案设计，今年已经在Eonval帐号里完成，例如这2个页面：

https://secure.eonval.com/user/signup/cn/feedval (注册)
https://secure.eonval.com/user/login/cn/feedval (登录)

这个方案是使用前后端双向加密，即：发送非明文、服务器存储前再次加密为非明文。前端的加密规则，写在JS文件里，JS文件在服务器端做了隐藏、不缓存到浏览器临时文件夹，无法被任何人读取、下载。即使有人用了更特殊的方法获取了JS文件，那么他还需要提前在用户的浏览器里放置病(隔开)毒来监(隔开)听用户发送的数据，没有5-10年的时间，是无法还原数据的，所以没有人会闲到去做这件事。

这类前后端双向加密的方法，即使没有HTTPS，也不会明文传输。

这两三年，国外很多大网站是被强制使用HTTPS，类似我们的ICP备(隔开)案。

比如我们常用的Let’s Encrypt，是直接安装后，瞬间就能用，不需要任何人工审核。因此，HTTPS并不具有权威。ICP备(隔开)案，有没有权威，大家都心里有数。(没有权威) 也类似于ICP证，只是多了一个资质、或者资格证书，在某种意义上体面一些而已，或者在某个行业里具有运营资格。

国外的很多成熟的社会运营方案，是直接让你去使用、运营，有了问题再停机、或者处罚，就像国外没有ICP备(隔开)案。怎么反而在他们国家里，要用HTTPS来约束很多企业呢？

当你的站点、二级域名(解析到不同IP的二级域名)多了之后，一个个安装、维护HTTPS，是个悲剧。
其中，SSL安装当中有一项是域名必须已经解析到当前空间、并且DNS已生效，因此SSL的泛域名仅支持解析到对应的泛域名解析的服务器。如果是非泛域名解析的二级域名(即每个二级域名指定不同的IP)，这时安装SSL还是需要一个一个域名去安装。

Eonval平台需要开发的版本总结：
1. PHP 7、PHP 5兼容；
2. 提供HTML 5、HTML版本；
3. 提供UTF-8、GBK(ANSI)版本；
4. 提供HTML带回行、不带回行的版本，提供超好用的代码闭合分析工具，一次的自动分析，至少可以节省人工分析5-30分钟。
5. 支持手机版、中英文版。

对于UTF-8、GBK(ANSI)版本，两者在技术上是可以彻底完全互转的，但是需要一定的开发工作量，所以在开发的初期不支持两者互转，只能选定一种。