浏览模式: 标准 | 列表

今天写程序遇到一个非常棘手的问题,花了一天的时间终于搞定了。最后用了一个很长的 SQL 语句解决了这个问题。这个问题比较有代表性,后面的程序里还有好多相似的问题,在这里把它记下来,后面再遇到这种问题就容易解决了。

问题乍听起来不是很变态,就是合并一个 CMS 系统中的两个分类,假设要合并的两个分类的编号分别是 from_cat_id 和 to_cat_id,from_cat_id 将并入 to_cat_id,合并以后,from_cat_id 将不再存在。但是这个系统每个分类对每个用户有按天进行的日志统计。这些统计的项目有:用户编号(user_id),分类编号(cat_id),访问日期 (visit_date),当天最后访问时间(last_time),当天最后访问的 IP(last_ip),当天最初访问时间(first_time),当天最初访问的 IP(first_ip),当天点击数(hits),当天发布主题数(posts),当天评论回复数(comments),当天最后发布的主题编号 (last_post),当天最后回复的评论编号(last_comment)。因为要合并分类,因此这些统计也要合并。

» 阅读全文

用 MySQL 很久了,一直被 MySQL 中没有嵌套查询所困扰,虽然 MySQL 4.1 中支持这个特性,但是我的 PHP 的程序都使用的 MySQL 函数库,而不是 MySQLi 函数库,所以 4.1 的特性用不上。

以前遇到需要嵌套查询的地方,一般转化为两个表的连接查询来解决。可是最近做的一个程序里面,发现需要嵌套查询的地方是对同一个表进行的两次查询, 所以没法直接转化为两个表的连接查询。要转化为用 PHP 代替 MySQL 做这种事实在是太麻烦了(以前就干过这种傻事),于是一直想找个简单的替代法。也许是灵感突发,也许是最近天天再翻 MySQL 手册对 MySQL 的查询有了更深入的理解,今天忽然想到可以用表的别名来解决这个问题。

» 阅读全文

默认情况下,PHP会话(session)是通过文件来保存的。这样做有以下几个缺点:

  1. 会话文件一般都很小,但文件数却很多,在文件系统中保存许多这样的小文件非常浪费空间,且效率不高。
  2. 分布式的站点难以利用会话文件来共享会话。
  3. 会话文件方式不利于统计在线用户的会话信息。

为解决以上问题,我们可以考虑用数据库来保存会话信息。

» 阅读全文

昨天在调试 WAP 网站时发现,在增加了 GB2312 到 UTF-8 转化以后,有些页面显示不正常了——有些页面只有一半的内容,另一半被截掉了。因为被截掉的部分包含了<p>的后半个标签</p>,因此整个页面都显示不出来,而报告错误。经过猜测、尝试,最后终于把问题集中在了 iconv 函数上。在经过高人指点以后,发现这个函数的第二个参数,除了可以指定要转化到的编码以外,还可以增加两个后缀://TRANSLIT 和 //IGNORE,其中 //TRANSLIT 会自动将不能直接转化的字符变成一个或多个近似的字符,//IGNORE 会忽略掉不能转化的字符,而默认效果是从第一个非法字符截断。 但是我尝试了//TRANSLIT 和 //IGNORE 这两个后缀,效果还是不对。于是我想问题可能不是出在这里。从 GB2312 到 UTF-8 转化应该不会有不能转化的字符,因为 UTF-8 的字符集完全包含了 GB2312 中的字符,所以我想大概是前面要转化的字符集指定错了,于是我尝试着把 GB2312 改成 GBK,问题解决!虽然那两个后缀在这里没派上用场,不过也算学了一招,以后肯定会用到的。

» 阅读全文

前几天重装了 IIS,发现原来的 WAP 网站成乱码了。原来的 IIS 会自动将 WAP 页面中的 GB2312 编码转化为 UTF-8 的编码,而重装以后就不能自动转化了,没找到原因,所以只好把所有的页面都改成了 UTF-8 的。但是在修改 WAP 邮件系统时发现,原来的邮件标题、收件人等信息解析就不是很正确。经过这次修改终于好用了。

在PHP手册中有一个 imap_mime_header_decode 函数,但是它并不能总是正常工作……

» 阅读全文