stdClass:__set_state()

以前用PHP做数据缓存的时候一直是将数据序列化(serialize)后存入文件,取出时再反序列化(unserialize),这样做除了效率低点没有其他问题。读取文件再解析,当然不如直接include来的快,这时候就要求缓存是以PHP代码的形式存储的,这里可以用到PHP的 var_export 函数,其返回的代码可以直接存储。这个方法貌似不错,但问题也来了:

Fatal errorCall to undefined method stdClass::__set_state() in xxx

__set_state()是PHP 5.1引入的一个魔术函数,接受一个数组作为参数,主要用在var_export的时候进行递归处理。可是使用的前提是得先定义啊~ 我习惯的数据存储方式都是用的stdClass,ezSQL默认从数据库取出来的数据结构也是以stdClass形式进行存储的……这下麻烦大了,stdClass本身是不存在__set_state()这个静态方法的……没辙了……只好改为数组……唉……

今天的牢骚没有结论,导出对象有除了序列化有没有更理想的方法呢?还是我真的就只能做数组的缓存了?

ps:有人已经向PHP提出申请了,哈哈~
http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3713102

备忘:完整ASCII字码表&中文正则

好不容易找到个完整的ASCII字码表

附PHP中文字符串判断正则:

$pattern_a '/^[' chr(161) . '-' chr(255) . ']+$/';
$pattern_b '/^[' chr(0xa1) . '-' chr(0xff) . ']+$/';
$pattern_c '/^[\x80-\xff]+$/';

// For GBK
$string '中文字符串';
var_dump(preg_match($pattern_a$string));
var_dump(preg_match($pattern_b$string));

// For UTF-8
$string iconv('GBK''UTF-8'$string);
var_dump(preg_match($pattern_c$string));

PHP面向对象编程及框架应用之我见

  php5问世已经好几年了,我的php历程是从php4开始的,之前的版本没经历过。php5在面向对象、异常处理方面做了若干改进(php5OOP参考),也使得php更像java了,搞得我有时候都迷茫了,到底是在写些什么乱七八糟的东西?

  php对我来说最大的吸引力是其简单易用和处理速度,然则现在国内出现了可以说是规模庞大的框架之争和面向对象之争。FleapPHP的作者很NB的说,你不用框架是因为你不愿意接受新事物,呵呵,我很欣赏自己的一句话,php框架是用来研究的,不是用来应用的,如果真的要用框架,我也就不是php的fans了,改行去搞MS的东西吧。

阅读全文 »

关于PHP性能优化的一些想法

  网络上有很多关PHP性能优化的文章,提到了很多优化的细节,譬如:

  • 使用str_replace比使用正则表达式要快
  • 使用echo比使用print结构要快
  • 使用require比require_once更有效率

  这些东西的确是一个做PHP开发的人员所必须知道的事情,但是我觉得自己有时候太注重这些东西而往往裹足不前。存在即真理,有一些更方便的实现途径,干嘛不用呢?难道使用命令行就一定比使用GUI高深?需要改变下思路。

  恰好昨天,还是周六呢,要去看一下客户的OA,据原OA的开发公司的人说,现在运行速度特别慢,现在根本都打不开。过去一看,页面执行超时,30秒都打不开个页面,最后抛出的错误是数据库链接超时。但是其他页面又正常。翻看下数据库,单表有6K多条数据,然后查看那个出错的文件,我的天,居然有这么个变态的思路在这个文件里:先取出所有这些数据,然后循环,在循环中嵌套30次的查询,这样一个页面下来,总查询次数=6000×30=180000。能有这样的思路,系统不死在那才怪呢。

  其后做了一些测试,比如给Wordpress一次插入10K条记录,然后查看执行时间,居然还不错,1秒多。当然,Sablog放在旁边不说,毕竟它的设计思想就不一样,例如WP的同一日值从属多个分类它就做不到。不得不说的是,Wordpress的很多查询也写的很垃圾。

  跑题了。总结一点,如果想要你的程序跑的更快,运行的更好,把思路放在数据库结构优化和程序优化上面吧。不要花太多功夫在选择echo和print上面,这划不来。

  BTW:PHP真不适合做OA,HTTP的无状态性决定了很多OA必备的功能不能实现,譬如即时通讯。

不包含图形验证码的安全表单?

  今天看到这篇文章:Safer Contact Forms Without CAPTCHA’s,仔细想了下,得出的结论是,如果你的网站对于机器人来说没有什么太大的利用价值,那么这种验证方式已经足够了,如果垃圾信息发送者认为你的网站很有价值,那么破解起来也很方便。

1、先说原理
  我们使用图形验证码(当然还有声音等其他方式),主要就是欺负机器人看不懂复杂的图片。上面这篇文章中提到的方法就是将验证信息隐藏在用Ajax生成的表单隐藏域中,说白了,也就是欺负机器人看不懂JS生成的隐藏域和cookie。其实这只是个掩耳盗铃的做法。我们来看一下原文代码:

$ct mktime();
setcookie('token',md5('secret salt'.$ct), 0'/');
# 'Expires' in the past
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

# Always modified
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");

# HTTP/1.1
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0"false);

# HTTP/1.0
header("Pragma: no-cache");
echo 
$ct

  首先给浏览器一个加密的cookie值,然后给表单一个时间戳,验证时对比下cookie和时间戳的编码规则是否匹配。如果机器人要破解,有这么个办法:首先人工获取cookie和时间戳,然后伪造这个cookie,让机器人同时发送到评论入口就行了。

阅读全文 »