YOYO的最新BLOG文章

经过几天的努力，终于把Bo-blog2.0.3转移到wordpress2.3了，今天晚上把原来的 bo-blog程序也用最新版本的wordpress从服务器上替换了下来。

这次转移程序让我感触最深的就是细枝末节的东西太多，调整这些很细微的东西的时候最头痛了，写程序吧，有点不值得，不写吧，工作量也不算小。整个的 转移过程有很多的东西都是在不断的衡量中进行的。而且以前由于删除Bo-blog上面出现的大量垃圾链接而使很多的数据统计都是错误的，因为当时是在数据 库里面直接写sql改的（否则准累不清，都是上万条的）。

其实数据的转换程序我是先前早就写完了的，今天的时间主要花费在了调整原来的链接和现在的链接统一上面，本来这件事情是可以在.htaccess搞定的，但是后来考虑还是在404页面直接用PHP写好一点，于是写了以下程序：
阅读全文 ->

经过几天间断性的努力，Bo-blog已经成功转移到wordpress，这是我计划了很久的一件事情，今天终于完成了。整个程序包括两个部分，一个是帖子的转移程序，一个是评论的转移程序，当然仅仅这两个部分还是不够的，但是已经完成了大部分工作，其他的手工改一下就OK了。

程序分为服务器端和客户端两个部分（我的wordpress在本地），服务器端的程序负责检索数据并传递给客户端，客户端负责接受数据并写入数据库，整个过程分为若干个循环完成。

其实这里本应该还有一个用户的转移程序的，但由于我这个博客上面的用户比较少，所以都用手工添加了，如果有人需要，可以仿照帖子转移程序或评论转移程序自己写一个，整个转移程序将在我进一步测试之后公布出来，转移后的博客也会在随后的几天里放在网上。

这几天我一直在做从bo-blog转移到wordpress的尝试，昨天晚上遇到了转化后的乱码问题。遇到乱码并不郁闷，郁闷的是我不知道为什么，后来我是通过添加mysql_query(”SET NAMES UTF8″);解决了这个问题，我知道这句SQL的作用，但是我还是不知道为什么我原来的转换会出现乱码，因为之前我同样的操作都没有出现过乱码问题。

在百思不得其解的时候，我尝试在写入一条SQL语句后直接用我的页面把刚才写入的数据显示出来，让我兴奋的是这次不是乱码，而在wordpress的页面显示的还是乱码，于是我立即去wordpress文件里面找SET NAMES的SQL语句，最终我在wp-includes/wp-db.php里面找到了它，至此我彻底明白了。

对于解决MYSQL乱码的问题，总结如下几点：

第一、为你的链接数据库的页面增加SET NAMES语句，如：SET NAMES UTF8，它的作用是设置本次数据库联接过程中，数据传输的默认字符集是UTF8，同时在写入和展示数据的页面保证显示的是UTF8，这样你的页面就不会出现乱码问题了。
第二、你可以不用SET NAMES语句，但是请一定保证写入数据的页面和展示数据的页面要用同样的编码，并且数据库编码最好用UTF8，因为用其他编码容易在写入的时候出现错误。保证写入数据的页面和展示数据的页面用相同的编码也不会出现乱码问题，但是这个时候写入的数据的编码并不等于你页面的编码。
阅读全文 ->

如果你安装的blog系统是Bo-Blog，经常会发现根目录下面有core.×××的文件，而且有些文件特别大，core.×××是什么文件？

core文件是一种临时调试而生成的文件，它把运行程序出错时信息都保留下来，让你可以随时查询和调试出错的情况。所以对于不做程序调试的人来说，这些PHP生成的core.×××的文件就是垃圾文件，对待垃圾文件的方式只有一个——删除！

最近无意发现我在我的空间里面无法建立目录了，经过检查发现我的空间已经到了最大限额了，最终发现就是这些core.×××文件占用了我的磁盘，删除blog里面的这些文件之后，给我空出金300MB的空间，真有点让我吃惊。所以用Bo-Blog的朋友，磁盘不够用的时候检查一下你的blog目录下是不是有这样的文件啊，删除掉就给你腾出空间来了：）

今天无意中发现了bo-blog的验证码bug，竟然提示我输入不正确（输入肯定是对的，大小写我都试过了），查了一些资料后，有人说可以用应急恢复程序来实现，具体我没用，我不知道怎么用；还有一些人说是temp文件写入不了，我试了试，确实是写入不了，改为777权限也不行，于是把里面的session都删除了，竟然能写入了，登陆也正常了，原来是这里的问题，晕鸟~
建议所有用bo-blog 2.0程序的朋友还是不用验证码登陆的好，如果不闲烦的话，可以多清理一下temp文件夹。