有几台服务器一直在跑PHP 5.4
而PHP 5.4 早在一年以前就End of Life了
换言之，PHP官方既不提供技术支持也不提供安全更新了

PHP当前的版本支持
http://php.net/supported-versions

所以应该在一年前或者更早些时候，就应该把PHP升级至5.5或者升级至5.6
由于PHP 5.4 到PHP 5.5 或者到 PHP 5.6 改动较大，一大堆函数都过时了。
而很多客户跑的还是10年以前的脚本，甚至有的是一路从PHP 4 迁移过来的，所以升级压力较大。
生怕一不小心，让客户的站点都奔溃了，那我岂不是成了千古罪人。

作为一个拖延症患者，我始终期待一个完美的时刻，我做好一切准备，然后平滑甚至完美的将PHP升级至当年支持的版本。但是这个时刻始终没有到来。曾经我在本地搭建环境，模拟迁移，然后发现好多站点一堆问题，先不说别人的，自己的站都是一堆乱码。有的客户的站甚至打印出无数条出错信息，直接导致浏览器崩溃。

但是眼看2016年已经过去，2017也已过了多半个月了，再过几天又到了农历的新年。
再拖延下去，不知会拖延到何年何月，虽说现在这块市场不景气，几乎没有新客户，但是也要对老客户负责啊。

于是下定决心，开始工作。
重新在本地搭建环境，对所有站点进行测试，然后针对出现的问题进行解决。
经过几天的奋战（当然，不是不眠不休的啦），终于把所有服务器上的PHP版本都更新到最新啦。

期间有几点问题，记录在此，方便以后查阅。

过时函数的问题

PHP 5.4 至 PHP 5.5 至 PHP 5.6
很多函数都过时了，不建议被使用，建议使用新的替代方式。
对于几百年不更新网站的用户而言，这种问题尤为严重
而这些年经济不景气，很多用户也没精力更新网站，指望他们把过时函数都改写，这不现实。
而我去改写客户站点的程序，这更不靠谱，是对客户的不负责任。

解决方法：
历史遗留问题，只能先如此了。
关闭掉网页上错误显示，同时关闭过时函数报错

同时提醒客户尽量更新。

网页乱码问题

因为客户大部分是英文站，到很少出现网页乱码的问题
即便部分中文页面，也因为人家设置正确，没有出现乱码
唯一出现乱码的反而是我的两个个站
一个是纯HTML，UTF8编码的中文页面
一个是13年前的DISCUZ 2.5论坛脚本（GB2312编码），因为特别清爽，所以一直以来我都没有抛弃，几次PHP升级，它都出过不大不小的问题，我都定位到代码并解决了。

但这是的问题是，升级过后，论坛就乱码的。
这不科学啊，貌似没啥函数会导致乱码的
于是把两个版本的PHP配置文件拿来比较一下，发现之前的default_charset是空的，而现在则是utf-8
看了一下文档，说空的默认值是iso-8859-1
于是改回iso-8859-1，论坛终于正常了！
还没来得及庆祝，回头一看另外一个纯HTML不正确了
然后看网页源文件，也指定编码了啊，为啥就不起作用呢，这十分不科学啊。
然后又百度学习了一下，说有：

• Apache的DefaultCharset
• PHP设置的HTTP Header
• 以及页面mata标签中的编码
• 还有页面保持的格式
  My God，我的头，这比唐僧的紧箍咒还要恐怖。
  然后看各种解决方案，晕头晕脑
  还是投机取巧一下，既然以前是空的，那么咱还改回空的试试吧。
  额，一切正常了。

客户程序的问题

感觉解决了这两大问题，应该差不多了啊
测试发现，绝大部分站点都没啥问题
唯一一个站点，打印出无数行出错信息啊

话说我都关闭网页显示出错信息，也禁止E_DEPRECATED错误
为何还显示一堆错误呢
各种尝试之后，发现出错信息是客户程序打印出来的，也就是说我关闭没用
那么两个思路就是一关闭客户程序中打印出错信息部分，二就是解决掉这部分问题

搜索后发现这篇文章：
http://www.sdtclass.com/3436.html

然后按文中说明测试，一切OK。
然后联系客户，告知此情况，并让客户测试，客户测试后表示正常。

其它问题

除了这几个主要的问题，其它的都显得不那么重要了
一些客户要求一些新功能模块，评估后发现没啥风险，也随手加上了

结论

拖了很久，让我焦虑万分的问题，终于被我解决了
尽管不是那么平滑，也不是那么完美，但结果总算还是不错的。
这次不用担心因为PHP版本过老的问题被黑了，虽然我们也有其它方面的防御，但是升级后至少被黑的概率更低了不是。

困难之所以称之为困难，是因为我们还没克服它。
把这个记录下来，一则鼓励自己不要拖延，迎难而上，二则以后备查。

This page is synchronized from the post: 拖了很久的事情终于完成了，将PHP 5.4 升级到 PHP 5.6