有的时候，我们发现通过phpmyadmin在数据库中看到的内容是乱码，而wordpress依然能正常显示，但是一旦导出转移到新的数据库，却无法在新的web服务器中正常显示了。那么这个时候我们就需要解决乱码的问题，当然通用的转换方法是都向utf-8编码转换。

导出sql的方法至少有两种，第一种是直接在shell里面导出，另外一种就是通过phpmyadmin下载下来。不管怎样，我们都得面对这个乱码的sql文件。而乱码SQL文件又分真正的乱码和伪乱码。伪乱码的原因在于记事本或者其他等文本编辑器用ANSI的方式查看了utf-8编码，由于对bom的误处理或者bom丢失，导致我们看到乱码。这个问题解决起来比较简单，那就是用editplus等文本编辑器打开sql文件，然后保存的时候选择编码为utf-8即可。而另外一种真正的乱码这个办法就无效了，所以这个时候我就用php写了一个简单的sql备份工具，它在备份的同时也可以按用户需要将大的sql文件按照需要进行分割。

使用方法，下载这个php文件http://www.storyday.com/wp-content/uploads/2008/05/dump.zip（插几次链接都失败，难道是wp2.5编辑器的问题？），如果你需要设置分割文件的大小，那么就用文本编辑器打开这个文件，修改第4行，默认的2000表示每2000个SQL语句分割成一个文件，否则别管他。然后将其放在根目录下的一个文件夹中，如bak，设置bak的属性为0777。然后通过web访问http://storyday.com/bak/cos-dump.php即可。

采用第二个方法后如果发现还是乱码，请用第一个方式，如果都不行，请检查新的数据库设置是否正确！

备份完毕之后，请删除此文件，以免数据泄漏！

与本文无关，抓虾刮刮乐{ZHUAXIAd4897d0646546b51343164f4ed518a7eUnion}

有几位朋友都在问这个问题，因此不妨写下来。wordpress搬家最麻烦的就是两个问题，一个是数据库乱码，另外一个是域名自动跳转到原来的域名。数据库乱码问题多种多样，这个在后面的文章中将会描述，并且会提供解决办法。今天要解决就是域名自动跳转的问题，比如我们要将storyday.com搬家到5bird.com。下面是搬家的步骤：

1. 在storyday.com的服务上tar下所有的文件，上传到5bird.com目录下，然后解压；
2. 在phpmyadmin中导出数据库文件，然后到新的数据库管理器中导入；
3. 修改wp-config.php中的配置；
4. 进入phpmyadmin，将wp_options中原来的域名修改成新的域名；
   
   
5. 进入新的域名后台管理，然后进入全局设置，修改blog域名为你的新域名，如下图所示：

哇，竟然可以了！如果还是不能访问，请检查根目录下的.htaccess文件中是否有转向指令，如果有，请删除含有原来域名的那一行！

google其实不仅仅是一个内容的搜寻者，目前他还在不停的向内容的拥有者和创建者方向发展，这一点通过google提供的公共服务API可见一斑。gmail可以将非搜索用户紧紧的粘贴住，而blogger服务则能让用户自动创造内容。如果说前面的这两点是最基本基本的应用，那么google又提供了中级一点的web应用，你可以通过google page crator来创建静态web页面；如果需要在静态页面中展示动态内容那也相当的容易，因为google的gdata可以让你自由存取数据甚至可以只用javascript而不需要服务器端程序来实现；还有google的mashup能让你快速的完成小型web应用程序的建立。

前面的这些都不足以让我心动直到google的app engine的出现，app engine是一个很诱人的服务，可惜没有抢到最初的试用用户名额。按照我粗浅的理解，app engine可以认为这是google提供的虚拟主机服务。而这“虚拟主机”的大致配置如下：

1. 磁盘空间500M；
2. 支持语言：python（当前只支持python，今后可能会有其他语言的支持。要是能支持php，那些虚拟主机商还怎么活啊）
3. CPU限制：每个月5000,000PV（dreamhost的上限大约每月不到1000,000PV）；
4. 价格：基本用户免费；
5. 数据库，gdata，SQL语句采用GQL（类似SQL的语言，是google自己的企业标准）；
6. 用户认证（可以集成在google的用户认证中），当然也可以自己用python来实现；
7. uptime（没有明确的保证，估计和其他服务一样，收费用户将会有99.9%的uptime保证，免费用户就看你对google的信心了）

上面的配置是不是很诱人呢？并且还是免费的，但是如果要能使用上这个免费的平台，你还得要重新熟悉新的语言，新的数据库操作等等。但是能用上google稳定的服务器，那也值得一试的。要知道google在全球各地有n多的分布式数据中心，所以它的稳定性和负载能力是其他服务商无法比拟的，用它自己的话说就是：An App Engine application runs on many web servers simultaneously. Any web request can go to any web server, and multiple requests from the same user may be handled by different web servers. Distribution across multiple web servers is how App Engine ensures your application stays available while serving many simultaneous users.

希望这个服务能尽快被推出，到时候我们就可以用一系列google的API创建出丰富的应用了，不过吃人嘴短，互联网要是真被google统治了，那或许将会是一场灾难。

另外，在中国，使用google的服务还是有强大的风险的，要么冒着被封的危险使用google的服务，要么在那里左右为难，干巴巴的望着！

google code确实是一个好东西！

如果文件太多，请谨慎进行tar操作，bluehost会因为tar命令占用CPU而将你账户给停掉，今天帮一朋友压缩数据就遇到这样的问题。以前我也压缩过超过2G的数据，但是没有这样的问题。不知道是bluehost变态了还是tar的文件确实太多了？不管怎样，如果你的文件超过2G，压缩的时候得要注意了！

erick [7:56:32 AM]: Thank you for contacting support! Please give me moment to read through your question.
7tiger [7:56:32 AM]: Please contact the support department as soon as possible, and please have your site name ready.

7tiger.com with password **** ????
erick [7:56:49 AM]: Let me look it up
7tiger [7:58:16 AM]: and what’s wrong with this account please?
erick [7:59:13 AM]: The account was suspended because a very cpu intensive and large gzip process was running via SSH on the account and it was degrading the server’s performance
7tiger [8:00:02 AM]: I have cancelled that process and I promise this will never happen again! could you please reactive it for me?
erick [8:01:18 AM]: Yes, let me put in a request
7tiger [8:02:18 AM]: how long will it take ?
[8:04:10 AM]: ??
erick [8:05:19 AM]: It should not take more than a couple of minutes
7tiger [8:06:01 AM]: but now,the status is still suspended
[8:13:05 AM]: hello? I am waiting for the account reactivation
erick [8:13:36 AM]: I am still waiting for it to be re-activated

今天早上发现一些domain依然不能访问，原来BH恢复帐号之后依然将suspended的htaccess留在了每个域名的目录下面，昨天晚上承诺帮我删除的，居然那个家伙看到我退出了livechat就不管了，这点上来说bluehost比如hostgator好，所以今天早上只好再次livechat表达了我的愤怒，并且强烈要求赶快删除所有遗留下来的 htaccess文件！

Bluehost本次的反应让人很失望。首先是账户恢复了，但是他居然把错误的htaccess还留在那里，今天上午进行了3次livechat，第一次解决了htaccess的问题（还是没有彻底解决）；第二次解决了Cpanel的问题；第三次livechat是因为发现7tiger下所有的域名都出问题了，不过刚刚连接livechat的人却发现已经好了，如果有朋友账户还是无法访问，请到下面留言，或者自行处理一下，处理的方法是：删除web根目录下的htaccess文件，将.htaccess.suspended 重命名成.htaccess

补充：在sansky.net的blog上看到他对Bluehost的抱怨，看来bluehost确实由于人数爆增从而出现了瓶颈。而由于本人的blog静态化了，所以受mysql down掉影响小得多，没有注意到BH的数据库的问题！

另外我感觉中国用户应该是bluehost的最大客户，因为在晚上11点之后livechat一分钟内基本可以连接上，而中国白天时间，livechat几乎不可用，或者要等上20来分钟，我今天一上午就被BH的误操作给浪费掉了。

不整点圆角怎么能算是2.0呢，所以我在bloggermap的新版设计中全部采用了圆角。下图是正在孕育中的新版bloggermap界面截图
而那个圆角是采用google的圆形背景来作为转角实现的，具体的思路如下图所示： (read on …)

如果你能看到这篇文章，说明你的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给他！

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

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