Mysql4.1编码详解及WordPress编码完善

转载时请标明文章原始出处和作者信息, 作者: lostsnow.
http://www.lsproc.com/blog/mysql-encode-wordpress/

下面要写的是一篇非常无聊的东西,充斥了大量各式各样的编码、转换、客户端、服务器端、连接……呃,我自己都不愿意去看它,但想一想,写下来还是有点意义的,原因有四:

1. MySQL 4.1 对多语言的支持有了很大变化 (这导致了问题的出现);
2. 尽管大部分的地方 (包括个人使用和主机提供商),MySQL 3 仍然占主导地位;但 MySQL 4.1 是 MySQL 官方推荐的数据库,已经有主机提供商开始提供并将会越来越多;
3. 许多 PHP 程序以 MySQL 作为默认的数据库管理软件,但它们一般不区分 MySQL 4.1 与 4.1 以下版本的区别,笼统地称“MySQL 3.xx.xx 以上版本”就满足安装需求了;
4. 因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集,成功的蒙蔽了许多 PHP 程序的开发者和用户,掩盖了在中文等语言环境下会出现的问题;

简单的说,MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略,导致了问题的出现和复杂化,而由于大部分用户使用的是英文,使这种问题不被重视。这里提到的 PHP 程序,主要就 WordPress 而言。
MySQL 4.1 字符集支持的原理

MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL,其中的一个数据库,其中的一张表,其中的一栏,应该用什么字符集。但是,传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置,它们用的是默认的配置,那么,默认的配置从何而来呢?

1. 编译 MySQL 时,指定了一个默认的字符集,这个字符集是 latin1;
2. 安装 MySQL 时,可以在配置文件 (my.ini) 中指定一个默认的的字符集,如果没指定,这个值继承自编译时指定的;
3. 启动 mysqld 时,可以在命令行参数中指定一个默认的的字符集,如果没指定,这个值继承自配置文件中的;
4. 此时 character_set_server 被设定为这个默认的字符集;
5. 当创建一个新的数据库时,除非明确指定,这个数据库的字符集被缺省设定为 character_set_server;
6. 当选定了一个数据库时,character_set_database 被设定为这个数据库默认的字符集;
7. 在这个数据库里创建一张表时,表默认的字符集被设定为 character_set_database,也就是这个数据库默认的字符集;
8. 当在表内设置一栏时,除非明确指定,否则此栏缺省的字符集就是表默认的字符集;
9. 这个字符集就是数据库中实际存储数据采用的字符集,mysqldump 出来的内容就是这个字符集下的;

简单的总结一下,如果什么地方都不修改,那么所有的数据库的所有表的所有栏位的都用 latin1 存储,不过我们如果安装 MySQL,一般都会选择多语言支持,也就是说,安装程序会自动在配置文件中把 default_character_set 设置为 UTF-8,这保证了缺省情况下,所有的数据库的所有表的所有栏位的都用 UTF-8 存储。

Continue reading

-- EOF --

wordpress 2.0.2 Security Release

转载时请标明文章原始出处和作者信息, 作者: lostsnow.
http://www.lsproc.com/blog/wordpress-202-security-release/

An important security issue has been brought to the attention of the WordPress team and we have worked diligently to bring you a new stable release that addresses it. Our latest version 2.0.2 contains several bugfixes and security fixes.

The problems addressed are unannounced XSS issues privately discovered and reported to the WordPress team. Thanks to Mark Jaquith, Robert Deaton, and David House for assisting with this release.

Just a quick note: this is different than the snake-oil reports that went out on some security lists a few days ago. There were a couple, but they were either not actual security problems, too small to warrant a release, or just patently false. Remember: just because you read it on a mailing list doesn’t mean that it’s true. We’d be the first people to panic if there was an actual problem.

As always, when something serious crosses our desks we jump on it and get a well-tested release out as soon as possible.
Continue reading

-- EOF --