在使用ultimate tag warrior的时候,其他功能都还好,但是在自己添加tag的时候出现了乱码问题,添加进去的tag显示出来都不成样子。上网大概查了一下,估计是字符集的问题。

有人说WordPress2.2全新安装时不能先编辑wp-config.php再用/wp-admin/install.php来安装了,而需要index.php来生成wp-config.php。前几天装WordPress Mu的时候的确是这样,看来WordPress现在慢慢“Windows”化了。Window

s化也没什么不好,Linux不也出个桌面什么的。但是可别“Windows杂乱化”,这次WP2.2还真是“Windows杂乱化”了。(之前说WP2.2要加入Tag功能,但是最后取消了)

在天佑的“WordPress 2.2 與 plugins 的 collation 問題”已经比较明确地提到这一点,具体说一下,从MySQL4.1起,数据库加入了字符集这个概念,它有5个环节定义字符集:服务器环境所用的字符集、数据库字符集、表或者字段所用的字符集、数据库连接用的字符集、数据库返回结果用的字符集和客户端用的字符集。总得来说这是一个好东西,能够适应各种字符集需要。

WP2.2之前的WordPress运用于非英文字符时需要在wp-db.php里增加一句
$sql = “SET NAMES ‘UTF-8′”;
mysql_query($sql);

来把读取的数据转为UTF-8,而WordPress2.2希望全面支持UTF-8来“国际化”,不过这好事也带来一点小毛病,它在wp-config.php里加了两句:

define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);

从而不必在wp-db.php里增加语句了。但是像DreamHost的数据库本身定义为latin_swedish_ci(好奇怪),我现在用的CPH数据库定义为utf8_unicode_ci(也是CBN的人为了方便)。而WP2.2定义的DB_COLLATE为空,即为utf8默认的utf8_general_ci。关键的问题在于,在保存数据的时候产生了字符集错误,WP2.2自己建立的表使用utf8_general_ci,自动强行转换,而WP2.2之前的插件不知道这一点,只是按照数据库的字符集来建立表,自然出了错。

赵明亮在“Wordpress 2.2全新安装后提交中文的乱码问题”里居然把WP2.2的那句强制转换去掉,或许他所用的数据库自己的定义合适,对于其他数据库,可能存在乱码风险。所以这种方法不适合推广,有点因噎废食的意思。

修改时进入需要修改的表,如wp_tags,然后在Operations(操作)里的Table options(表选项)的Collation(整理)里把utf8_unicode_ci修改为utf8_general_ci。如果希望今后不必麻烦,可以再把该数据库的字符集改为utf8_general_ci(在该数据库的“操作”菜单里)。(如果您的问题解决了,就不必往下看了。)


可是我发现自己使用时发现即使我没有修改,后台也可以顺利正确添加tag,在编辑文章时也可以,估计是CPH数据库采用的utf8_unicode_ci和utf8_general_ci有一定兼容性,但是在前台添加却常是乱码。我做了以下试验,全新安装WP2.2,这时我的phpmyadmin里设