如果你能看到这篇文章，说明你的DNS已经更新了，本站生活点滴又回到了祖国的怀抱。在犹豫了n久的情况下，我决定搬回来了。在CPH和Paveo的诱惑下，我终于没有把持住。今天上午在床上解决了Mysql乱码的问题。虽然此前本blog也搬家无数次，从IX到DH，从DH到BH，但是由于国外的服务器配置环境大多一样，mysqldump能搞定一切。此前通过phpmyadmin看到的数据库中的内容全部是乱码，但是既然blog能正常显示，我也就无所谓了。而当我打算搬回到CPH，却遇到了大麻烦，那就是无论怎么设置编码，始终无法正常显示。所以我只好搬出php来救命了。

照理说，旧版本的mysql没有编码的特殊处理，一切问题都没有发生过。因为php存入数据的时候没有做任何编码转换，仅仅是mysql自己无法认识该编码，当php再次取出数据的时候，php本身认识这个字符的编码，所以不会有乱码。而mysql4之后的版本就加入了强制编码的规范，所以一旦编码不对等，就会出现乱码，有兴趣的可以看看这篇转载的文章。

虽然我在phpmyadmin中看到的是乱码，而架设在bluehost上的wordpress能够正常显示，那么我就可以利用php来读取数据库中所有的数据，然后用utf8编码的方式输出成sql语句，不就可以搞定了？于是今天上午就写了这个php程序。结果导出的时候，由于数据量过大，导致了一次CPU超标，我不得不将输出的SQL进行切割，这个程序的完善版本将在最近两天发布，到时候你只需要将该程序上传到你的wp目录下，通过web就能顺利的完成数据库的备份和编码转换。

我口水了一大堆，有兄弟在期待这个东西么？？

前段时间说是路由调整，TMD调整了n久网络都还是这么慢，虽然中间有些时候会出现BH的ping延迟小于200ms的情况，但是这样的好现象基本不长久，现在ping的延迟居然是600ms，看来国外的虚拟主机在国内某种政策的围剿之下，只会越来越差了！所以我打算把本blog搬到CPH去了，各位BH合租的兄弟，我先行一步了哦！

一直没有搬家到CPH的原因有两点：1.本人比较懒，BH的速度+静态化，速度还很不错的；2.mysql乱码的问题，BH数据库中的连接采用的是Latin编码，所以转到CPH会显示乱码，我知道这个时候可能有朋友要告诉我用set names utf8，但是这都无济于事，毕竟数据通过phpmyadmin显示出来的都是乱码。昨天晚上我终于下定决心搬家了，乱码的问题只有出绝招了，那就是自己写php程序，读出数据库中内容，然后转换编码（目前已经搞定）。

当然这也不能说明BH一无是处，就在我今天决定搬家的时候，gtalk上的n多朋友告诉我说BH的速度在他们那里还是很快的。但是我这里广东电信一直有问题，所以我比较怀疑是广东电信的原因。昨晚去电信的一个朋友家中，谈到最近的ADSL的抽风现象，他们也深有同感。另外我仅仅是将storyday搬出BH，其他的网站还在BH上，所以合租的朋友尽管放心的续费下去，同时我会尽量慢慢的将三个合租帐户逐步减少到一个帐户，毕竟精力太有限了，另外本人的合租帐户也不吸纳新的成员了！

CPH搬家将在下周正式完成，到时候我会写一个完整的教程，同时会提供搬家中出现乱码的终极解决方案！并且提供sql编码转换的程序下载。

就说这么多，昨天报名学车了，去训练去了 ！

还是专门提出来说一下：本人做事有始有终，所有Bluehost可以续费，不会因为本人搬家了就把大家扔到一边，只是不招收新的人员罢了！

再次补充：刘同学开玩笑说我背叛了Bluehost，其实这个不叫背叛哈，毕竟广州电信访问BH越来越慢，ping的延迟居然达到了600ms，实在难以进入后台，所以把blog搬了。但是Bluehost也有不可取代的优势，我还有几个站点依然在Bluehost，对于做外贸的朋友，我依然强烈推荐Bluehost给他！

最近真的很奇怪，FF老是莫名其妙的关闭，如果用IE7也会无端的卡死，实在不清楚原因何在。不过我今天发现gmail多了一些功能，如下图。

再仔细一看，原来是继英文版本的gmail升级之后google将中文版本gmail也升级了，难道是因为这个原因所导致？暂且先将责任推在gmail的升级上吧！

ps：wp升级到2.5.1了，据说cookie的机制又做了调整，希望cos-html-cache能正常工作，否则又得跟着升级了！

传说中winxp sp3有很多优良的特性，系统会提高很多。在网上down了一个简体中文版本的winxp sp3，刚刚安装成功，不过发现除了winver显示的是sp3之外，其他倒是没有任何变化呢。这里是winxp sp3补丁包的迅雷下载地址，有兴趣的可以下载下来看看，不过据说微软官方目前还没有正式发布winxp sp3的包呢。

bluehost老是要是改来改去的，用四川话说就是x yan痒得很，以前的时候必须修改DNS才能绑定域名，而且域名只能绑定在主域名的一级目录下面。后来又进行了修改，支持n级目录绑定。然后又再次修改，此次修改之后，域名又只能绑定在一级目录了，而且依然必须修改dns，或者提供EPP Code（能提供EPP Code的地方一般都能修改DNS）。

现在好了，bluehost不再需要修改DNS了，只要需要将A记录修改到对应的主域名的IP地址即可完成绑定，各位使用bluehost而域名又在国内注册的兄弟们，这下爽了哈。

自从上次 bluehost账户被黑，请求 bluehost客服将我的数据恢复之后， bluehost居然就莫名其妙的把我账户上的weekly和daily备份的脚本给停了，正因为如此，所以上周周末，我的一个crontab计划任务错误的将一个朋友的数据库清空而无法再次恢复了，这里向这位盆友道歉，实在对不起，自动续费一年的补偿希望能小小的表达我的歉意。同时我也在这里呼吁各位合租伙伴，请一定要记得定期备份数据库，如果你使用的是wordpress，只需要安装一个数据库定期备份插件即可！

目前我已经将定期删除未续费账户的脚本给停止了，所以各位合租伙伴不要惊慌，此等事情不会再次发生。事情的原委是这样的，我在服务器上有一个文件保存着已经续费的名单，当到期之后如果合租伙伴没有续费，则该脚本将会自动删除该用户的所有文件和数据库。而islet8同学由于中途修改了域名，所以我在记录日志中将该域名去掉了，同时换上了新的域名。但是由于数据库的后缀依然保持着islet这个字符，于是脚本便认为此用户应该被删除，以至于“犯下弥天大错”。目前bluehost已经再次打开了他们的daily和weekly自动备份的脚本，但是希望你还是得自己备份，毕竟livechat也比较麻烦！

如果你是bluehost用户，如何才能知道自动备份脚本是否打开？SSH登陆到bluehost服务器，进入目录/home，然后你就会发现有几个文件夹username/  username.daily/  username.weekly/，weekly和daily目录下的文件就是周备份文件和日备份文件了。如果里面没有任何文件，请联系bluehost，要求他们做定期备份。

被该死的IE给搞惨了，耽误了很多时间，实在不划算。打开页面的时候，FF下一切正常，但是当我用IE6测试的时候，JS总执行不下去了，提示“尚未实现”，无论怎么搞就搞不定。在firebug中也没有看到任何错误提示。打开IE就遇到该死的“尚未实现错误”，根据IE中提示的位置找过去也没有发现任何错误，看来IE的报错定位也不太准确。万般无奈之下，google搜索，终于找到了错误所在的地方。原来错误在于window.onload= myFunc(var1,var2);IE的window.onload函数中不支持参数调用，虽然函数会照样执行，但是却会出现报错，影响后续脚本的继续执行，下面是两种简单而有用的解决办法：

1. 再写一个函数，譬如function loadFunc(){ myFunc(var1,var2) },然后window.onload = loadFunc;
2. 使用匿名函数。onload =function(){myFunc(var1,var2)}

足够了，就这两种方法。

幸亏当初设计的时候用了PEAR的 Cache_lite做了多级的缓存。结果今天进入google统计一看，没有想到今天居然飙升到13000多IP，实在不可思议，估计又是撞上了新的热门关键词语，看来改版的时候得更加注意考虑缓存了，缓存设计至关重要，否则很容易被拖垮的。目前新的版本已经完成了50%，希望能在6月之前发布出来！