« Itpub技术丛书《Oracle数据库性能优化》重印 | Blog首页 | 传说中的彼岸花 »
升级MT到3.2Beta5版本
作者:eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接:https://www.eygle.com/archives/2005/08/emt32beta5.html
链接:https://www.eygle.com/archives/2005/08/emt32beta5.html
早就看到MT3.2的Beta版出来了,一直没有升级。
早晨起来看到Fenng写了一篇MT 3.2 upgrade failed才知道居然已经到了Beta5了,再不升级恐怕就落后了,所以下载下来开始升级。
1.首先是从官方站点下载安装包.
2.然后解压到原来的安装目录,覆盖所有文件。
3.修改mt-config.cgi-original为mt-config.cgi,这是3.2和以前版本的不同,正确配置mt-config.cgi文件。以前我们用的是mt.conf文件。
4.登陆mt,输入口令,这时候mt会自动监测到需要升级。
选择开始升级即可。
可是等了半天没动静,一直停留在以下界面:
看来我是和Fenng遇到了同样的问题。
5.开了个新窗口,重新登陆,这次看到如下界面:
选择再升级。
6.这时候看到了正常的进度显示
7.升级完成以后返回登陆就好了
我们可以看到全新的主界面了:)
接下来就可以看看3.2给我们带来了那些惊喜了:D
历史上的今天...
>> 2012-08-20文章:
>> 2007-08-20文章:
>> 2006-08-20文章:
By eygle on 2005-08-20 12:13 | Comments (8) | Web | 400 |
不晓得你见着了我给你留的message没
交换个blog链接吧
-by老狗
你的链接我已做:ananzeng.1m.cn
已经加入了你的链接:
http://www.eygle.com/index-links.htm
我用Firefox更新,总算找到了问题所在--丢了一个js 脚本
是哪一个脚本?源程序里漏掉的么?
哦,升级后的MT图标还是有beta字样啊
可能是静态文件没用更新,程序文件都已经升级了.
MySQL为解决并控制不同层次的不同字符编码问题,在4.1 以上版本对字符集的支持细化到四个层次:服务器(server)、数据库(database) 、数据表(table)和连接(connection) 。MySQL通过以下三个方面来控制各个层次的字符编码:MySQL 字符集(Character set)、MySQL连接校对 (Collation,整理)以及站点编码。
编译 MySQL 时,指定了一个默认的字符集,这个字符集是 utf8;
安装 MySQL 时,可以在配置文件 (my.ini) 中指定一个默认的字符集,如果没指定,这个值继承自编译时指定的;
启动 mysqld 时,可以在命令行参数中指定一个默认的字符集,如果没指定,这个值继承自配置文件中的;此时 character_set_server 被设定为这个默认的字符集;
当创建一个新的数据库时,除非明确指定,这个数据库的字符集被缺省设定为 character_set_server ;
当选定了一个数据库时,character_set_database 被设定为这个数据库默认的字符集;
在这个数据库里创建一张表时,表默认的字符集被设定为 character_set_database ,也就是这个数据库默认的字符集;
当在表内设置一栏时,除非明确指定,否则此栏缺省的字符集就是表默认的字符集;
这个字符集就是数据库中实际存储数据采用的字符集,mysqldump 出来的内容就是这个字符集下的;
简单的总结一下,如果什么地方都不修改,那么所有的数据库的所有表的所有栏位的都用 utf8 存储。
当一个程序与 MySQL 建立连接后,这个程序发送给 MySQL 的数据采用的是什么字符集?MySQL 无从得知 (它最多只能猜测),所以 MySQL 4.1 要求客户端必须指定这个字符集,也就是 character_set_client, MySQL 的怪异之处在于,得到的这个字符集并不立即转换为存储在数据库中的那个字符集,而是先转换为 character_set_connection 变量指定的一个字符集;这个 connection 层究竟有什么用我不大明白,但转换为 character_set_connection 的这个字符集之后,还要转换为数据库默认的字符集,也就是说要经过两次转换;当这个数据被输出时,又要由数据库默认的字符集转换为 character_set_results 指定的字符集。
MT 默认采用的浏览字符集是 UTF-8 ,所以 MT 从所有的表单中得到的数据都是 utf-8 编码的,都不加转换的直接把这些数据发送给 MySQL( MT 的 character set client 和 character set connection 都是 utf8)。
但由上表所示,MySQL 默认设置的 character_set_client 和 character_set_connection 都是 utf8,此时怪异的事情发生了,实际上是 utf-8 格式的数据,被"当作 utf8"转换成……居然还是转换成 utf8,然后还要转换成 utf8 ( character set database )存入数据库,最后按照 utf8 的编码进行储存。(实际的存储数据,character set results)
但这几次转换 (主要是把 utf8 当作utf8转换成 utf8的过程)就造成了乱码。(利用Mysql CC和 phpmyadmin等可以看到是乱码,mysqldump 出来无论当作 utf-8 还是当作 latiin1 来读也都是乱码)。但是这种格式最后按照 character_set_results 默认是 utf8输出的时候,居然又能变回 utf8,而且也不是乱码了。也就是 MT 用 utf8 显示为正常的原因。(这个和 WP 采用 GB2312 编码时的情况差不多。)
在WP中,解决方案是,query 之前先执行一下:SET NAMES 'utf8'。
要保证结果正确,必须保证数据表采用的格式是正确的,也就是说,至少能够存放所有的汉字。
因为配置文件设置的 default_character_set 是 utf8,数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以我们要保证的只是客户端与 MySQL 交互之间指定编码的正确。
客户端以 utf-8 格式发送 (WP 的默认情况),可以采用下述配置:
SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'
这个配置就等价于 SET NAMES 'utf8'。
所以对 WP 修改方式是这样的,在 wp_includes/wp- db.php 中增加:
function set_charset($charset)
{
// check mysql version first.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] dbh);
if (mysql_num_rows($result) dbh);
}
在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:
$wpdb->set_charset(get_bloginfo('charset'));
但是我的问题是,对 MT 系统来说,相同原理的方案应该是修改那里的设置或者代码呢???
ft,你的Blog居然都无法回复啊!