• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/05/20/1495.html
• 转载请注明出处

现在普遍的Nginx + PHP cgi的做法是在配置文件中,　通过正则匹配(Nginx(PHP/fastcgi)的PATH_INFO问题)设置SCRIPT_FILENAME, 今天小顿发现了一个这种方式的安全漏洞.

比如, 有http://www.laruence.com/fake.jpg, 那么通过构造如下的URL, 就可以看到fake.jpg的二进制内容:

http://www.laruence.com/fake.jpg/foo.php

为什么会这样呢?

比如, 如下的nginx conf:

location ~ \.php($|/) {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;

	set $script    $uri;
	set $path_info "";
	if ($uri ~ "^(.+\.php)(/.*)") {
		set  $script     $1;
		set  $path_info  $2;
	}

	include       fastcgi_params;
	fastcgi_param SCRIPT_FILENAME   $document_root$script;
	fastcgi_param SCRIPT_NAME       $script;
	fastcgi_param PATH_INFO         $path_info;
}

通过正则匹配以后, SCRIPT_NAME会被设置为”fake.jpg/foo.php”, 继而构造成SCRIPT_FILENAME传递个PHP CGI, 但是PHP又为什么会接受这样的参数, 并且把a.jpg解析呢?

这就要说到PHP的cgi SAPI中的参数, fix_pathinfo了:

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting
; this to 1 will cause PHP CGI to fix it's paths to conform to the spec.  A setting
; of zero causes PHP to behave as before.  Default is 1.  You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
cgi.fix_pathinfo=1

如果开启了这个选项, 那么就会触发在PHP中的如下逻辑:

/*
 * if the file doesn't exist, try to extract PATH_INFO out
 * of it by stat'ing back through the '/'
 * this fixes url's like /info.php/test
 */
if (script_path_translated &&
	(script_path_translated_len = strlen(script_path_translated)) > 0 &&
	(script_path_translated[script_path_translated_len-1] == '/' ||
....//以下省略.

到这里, PHP会认为SCRIPT_FILENAME是fake.jpg, 而foo.php是PATH_INFO, 然后PHP就把fake.jpg当作一个PHP文件来解释执行… So…

这个隐患的危害用小顿的话来说, 是巨大的.

对于一些论坛来说, 如果上传一个图片(实际上是恶意的PHP脚本), 继而构造这样的访问请求…

所以, 大家如果有用这种服务器搭配的, 请排查, 如果有隐患, 请关闭fix_pathinfo(默认是开启的).

详细漏洞信息, 请移步小顿的BLOG: 80Sec

另: 我认为这个和Nginx没啥关系, 不属于Nginx的漏洞. 是配置的问题, 现在到处都在说是Nginx的Bug, 不妥不妥.

Comments

• 2010/05/20, [警示]Nginx + PHP CGI的安全漏洞：fix_pathinfo - 五四陈科学院-坚信科学,分享技术 writes: [...] 临近下班，见到鸟哥的一则php漏洞说明，具体说明在 http://www.laruence.com/2010/05/20/1495.html [...]
• 2010/05/20, Tweets that mention Nginx + PHP CGI的一个可能的安全漏洞 | 风雪之隅 -- Topsy.com writes: [...] This post was mentioned on Twitter by blogkid, 姚东旭, lqik2004, fantasy, Laruence and others. Laruence said: 请转发, 这个漏洞的影响范围挺大:Nginx + PHP CGI的一个可能的安全漏洞 , http://www.laruence.com/2010/05/20/1495.html [...]
• 2010/05/20, 王经 writes: 好呀
• 2010/05/20, nod32升级id » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 No tags for this [...]
• 2010/05/20, PHP中的PATH_INFO | 鸭嘴的blog writes: [...] PHP中的PATH_INFO 2010-05-20 14:00:22 | PHP 一直没有理解$_SERVER['PATH_INFO']这个变量的意义，今天看了风雪之隅的一篇文章Nginx + PHP CGI的一个可能的安全漏洞之后才关注一下这个变量。 [...]
• 2010/05/20, 雪候鸟 writes: 当当网发现此安全漏洞, 有谁认识当当的人么? 转发下, 让他们赶紧修复吧, 谢谢
• 2010/05/21, nginx文件类型错误解析漏洞 | 失光 記。 | 当 雙眼 都失去光芒 你还想留念什么?|it新闻|it咨询|it博客门户|我们都在IT|软件资讯|绿色软件|失光软件 writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, MoXie writes: 这让我想起Apache中FilesMatch的漏洞。 FilesMatch "\.php" 结果造成文件名中只要包含.php就当Php执行了。 FilesMatch "\.php$" 这样才正确。
• 2010/05/21, scotoma writes: 谢谢...这个转发到Nginx群里面的了,提醒各位SA修改下配置文件,确实有很大的危害. 感谢博主
• 2010/05/21, nginx文件类型错误解析漏洞 writes: [...] 或者 if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; } PS: 鸣谢laruence大 牛在分析过程中给的帮助转载自: [...]
• 2010/05/21, Anders writes: 其实，从这个常见的 nginx 配置上看，是有问题的，最好还是严格一些的好。。 # if ($uri ~ "^(\w+\.php)(/.*)") { # set $script $1; # set $path_info $2; # }
• 2010/05/21, SystemAdmin Blog » Blog Archive » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, nginx文件类型错误解析漏洞 - VPS侦探 writes: [...] 或者 if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; } PS: 鸣谢laruence大 [...]
• 2010/05/21, nginx紧急漏洞修复！nginx文件类型错误解析漏洞 | 流水理鱼|wwek writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, 猫の小屋 » Blog Archive » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大 [...]
• 2010/05/21, nginx文件类型错误解析漏洞 « zhoubing's blog writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, 收藏一点 » nginx文件类型错误解析漏洞 writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, [转]nginx文件类型错误解析漏洞 | 游侠海外岛 writes: [...] 鸣谢laruence大 [...]
• 2010/05/21, nginx文件类型错误解析漏洞 - Blinux writes: [...] jQuery(document).ready(function($){if(navigator.platform=="iPad")return;jQuery("img").lazyload({effect:"fadeIn",placeholder:"http://www.shocr.com/wp-content/plugins/jquery-image-lazy-loading/images/grey.gif"});});Blinux首页在线手册手机访问订阅RSS关于Englishnginx文件类型错误解析漏洞 Blinux Post in Linux的大杂烩，Tags: nginx, 安全 21 五月 2010 0 google_ad_client="pub-0521178536912504";google_ad_slot="8160586556";google_ad_width=468;google_ad_height=60; 热烈欢迎您来到Blinux!强烈推荐你订阅本博客 猛击此链接 .漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以location ~ .php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; }的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。 那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问http://www.80sec.com/80sec.jpg/80sec.php将会得到一个URI/80sec.jpg/80sec.php经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为/scripts/80sec.jpg/80sec.php而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为/scripts/80sec.jpg所以不存在此问题。 后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为/scripts/80sec.jpg和80sec.php最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：访问http://www.80sec.com/robots.txtHTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:05:30 GMT Content-Type: text/plain Content-Length: 18 Last-Modified: Thu, 20 May 2010 06:26:34 GMT Connection: keep-alive Keep-Alive: timeout=20 Accept-Ranges: bytes访问访问http://www.80sec.com/robots.txt/80sec.phpHTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:06:49 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=20 X-Powered-By: PHP/5.2.6其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。漏洞厂商：http://www.nginx.org解决方案：我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失关闭cgi.fix_pathinfo为0或者if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; }PS: 鸣谢laruence大牛在分析过程中给的帮助nginx文件类型错误解析漏洞:http://www.80sec.com/nginx-securit.html原创文章，转载请注明： 转载自Blinux本文链接地址: nginx文件类型错误解析漏洞No input file specified. (2)php安全设置之open_basedir (0)nginx windows发行已久 (0)nginx 301重定向 (4)给网站根目录添加sgid权限 (7)关闭Linux服务器ping响应 (0)nginx 自定义404 500 502 错误页面 (0)nginx 重启命令 (0)nginx 虚拟主机 (0) « Prev：SSH证书让Putty免密码登陆Linux Leave a Reply Name Mail (will not be published) Website [...]
• 2010/05/21, nginx文件类型错误解析漏洞 - Licess's Blog writes: [...] 鸣谢laruence大 [...]
• 2010/05/21, nginx文件类型错误解析漏洞 @ VPS实验室 writes: [...] 鸣谢laruence大 [...]
• 2010/05/21, Neaton writes: 应该跟php-fpm的版本有关系，0.6以下除0.6以外的版本才受这个漏洞的影响，可以测试下。
• 2010/05/21, nginx文件类型错误解析漏洞 - 书生博客 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 上一篇: 帝国网站管理系统之自定义系统模型 [...]
• 2010/05/21, Nginx暴安全漏洞，导致服务器被提权 writes: [...] 鸣谢laruence大 牛在分析过程中给的帮助   0 评论 Leave A [...]
• 2010/05/21, 两性解答 writes: 两性解答关注一下
• 2010/05/21, nginx文件类型错误解析漏洞 – kindle's blog writes: [...] 鸣谢laruence大 牛在分析过程中给的帮助 Posted on 2010-05-21 at 3:05 下午 | Filed: 网络文摘 | [...]
• 2010/05/21, Nginx/PHP 80sec 0day漏洞详细分析：fix_pathinfo « Hezll 博客 writes: [...] http://www.laruence.com/2010/05/20/1495.html [...]
• 2010/05/21, Bingo writes: http://wiki.nginx.org/NginxHttpFcgiModule#fastcgi_split_path_info 图片上传的路径加上这个配置可能就可以了 location ~ ^(.+\.jpe?g)(.*)$ { ... fastcgi_split_path_info ^(.+\.jpe?g)(.*)$; fastcgi_param SCRIPT_FILENAME /path/to/php$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; ... }
• 2010/05/21, Aggron的博客 » nginx php cgi漏洞 writes: [...] 从http://www.laruence.com/2010/05/20/1495.html看到的：nginx+fcgi+php可能会存在一个很严重的安全漏洞。使用nginx + fcgi跑PHP的童鞋注意了，据说已经有网站中招。 [...]
• 2010/05/21, nginx文件类型错误解析漏洞 | 0xf3sec'blog writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/21, IIS漏洞和nginx漏洞同时爆出，你的网站被爆了吗？ - 阿伉守候 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/22, nginx文件类型错误解析漏洞 - 二少's Blog writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 评论（0） [...]
• 2010/05/22, MIAO'BLOG » Blog Archive » nginx exp and 漏洞扫描器 writes: [...] 延伸阅读：laruence [...]
• 2010/05/22, nginx文件类型错误解析漏洞 | Linux之家 writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/22, Verdana DevNotes » PHP CGI 中 fix_pathinfo 引起的安全隐患 writes: [...] 关于这个问题，已有高手 laruence 做过详细的分析，这里再多啰嗦几句。 [...]
• 2010/05/23, nginx文件类型错误解析漏洞–（转） | 品味人生，享受生活 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助  转自：80sec.com [...]
• 2010/05/23, Free writes: This is ......(T)
• 2010/05/23, nginx文件类型错误解析漏洞 | Sudu's Blog writes: [...] ( $fastcgi_script_name ~ ..*/.*php ) { return 403; }  PS: 鸣谢laruence大 牛在分析过程中给的帮助转载自：http://www.80sec.com/nginx-securit.html日志信息 [...]
• 2010/05/24, 技术门户网站 writes: 好专业，不过很久没更新啦
• 2010/05/24, Nginx发现重大漏洞 | 袋鼠空间 - Just One Eximious Yelling! 超凡者的呐喊！ writes: [...] 鸣谢laruence大 [...]
• 2010/05/24, 乾亨网络工作室 » Blog Archive » nginx文件类型错误解析漏洞 writes: [...] 或者 if ( $fastcgi_script_name ~ ..*/.*php ) { return 403; } PS: 鸣谢laruence大牛在分析过程中给的帮助No related posts.以上关联文章由 Yet Another Related Posts [...]
• 2010/05/24, junjun的世界 » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 发表评论 | Trackback [...]
• 2010/05/26, 阿飞的博客 » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/05/31, 齐米优惠吧 » Blog Archive » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 转载自：http://www.80sec.com/nginx-securit.html Don't [...]
• 2010/06/01, nginx文件类型错误解析漏洞 | i-Mi-Yoo writes: [...] PS: 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/06/09, nginx文件类型错误解析漏洞 « 莫忘雪 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 评论（0） [...]
• 2010/06/09, PHPiis-坏孩子的天空 » Blog Archive » nginx文件类型错误解析漏洞 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 [...]
• 2010/06/10, 打听1下 writes: 很严重的安全漏洞。
• 2010/06/21, Bander writes: 弱弱问一句：关闭cgi.fix_pathinfo为0 可否解决噢？
• 2010/07/23, nginx文件类型错误解析漏洞 | 会跳舞的鞋子 writes: [...] 鸣谢laruence大牛在分析过程中给的帮助 这篇日志发表于 Jul 22nd, 2010 08:31 于分类 [...]
• 2010/07/27, SerranoMaritza33 writes: Following my own exploration, thousands of persons on our planet receive the personal loans from good banks. Therefore, there's great possibilities to receive a car loan in all countries.
• 2010/08/06, Trail's Blog » Nginx(PHP/fastcgi)的PATH_INFO问题 writes: [...] 最近发现的一个安全漏洞(Nginx + PHP CGI的一个可能的安全漏洞)和这个配置有关系, 请大家务必在使用第二种配置的时候,关闭cgi.fix_pathinfo. [...]
• 2010/09/07, Anonymous writes: if ($request_filename ~* (.*)\\.php) { set $php_url $1; } if (!-e $php_url.php) { return 403; } blog:blog.sina.com.cn/harleychen

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/05/18/1482.html
• 转载请注明出处

在PHP4以前, PHP并不支持面向对象, 到PHP4的时候, PHP引入了一些OOP的关键字, 请注意我用的”关键字”, 因为在PHP4中的对象, 不过就是一个数组(属性)加上一个函数数组(方法), 没有访问权限控制, 没有析构函数(当然可以模拟), 等等.

到PHP5以后, 随着Zend Engine 2的发布:

1. 访问权限控制
2. 接口的引入
3. 魔术方法(PHP4中可以通过overload来有限模拟)
4. 接口的应用
5. 内置接口
等等.

PHP5终于可以算是较完美的支持面向对象了.

而这些看似复杂的实现, 在根本上, 还是没有脱离属性数组+方法数组的基本, 接下来我就为大家揭开隐藏在源代码中的秘密.

对象的结构

在PHP5中, 一个对象, 还是以一个zval做为载体的, 还记得什么是Zval么(深入理解PHP原理之变量).

typedef union _zvalue_value {
    long lval;
    double dval;
    struct {
        char *val;
        int len;
    } str;
    HashTable *ht;
    zend_object_value obj;
} zvalue_value;

如果, 一个zval是对象, 那么zvalue_value中的obj, 就指向一个zend_object_value的实例.

一个zend_object_value包含俩个成员, 一个是标识符(整形序号), 表明了当前对象存储在全局对象列表的位置, 另外还有一个zend_object_handlers指针, 指向当前对象所属类的handlers(标准操作集合).

真正的对象实体, zend_object中, 保存了如下的关键信息入口:

1. ce, zend_class_entry 类入口
2. properties, hashTable 普通属性集

对象的属性

如上所述, 普通属性是一个的hashTable, 在PHP5以后, 引入了访问权限控制, 而访问权限属性, 是通过属性名进行区分的(为此Zend引入了zend_mangle_property_name).

1. public  属性名
2. private \0类名\0属性名
3. protected \0*\0属性名

PHP通过这种比较ugly但是简单高效的方法, 实现了对属性访问权限的标识.知道了这个, 我们就可以干一些不合常理的事请, 比如访问对象的私有/保护属性(见: Bug #44273 access to private and protected class variables allowed when casting to array):

class Foo {
    private $_name = "laruence";
    protected $_age = 28;
}
$foo = new Foo();
$arr = (array) $foo;
var_dump($arr["\0Foo\0_name"]);
var_dump($arr["\0*\0_age"]);
//output:
string(8) "laruence"
int(28)

既然我说到了普通属性, 那么也就有不普通的属性:Static/Constant, 因为静态属性和常量属性都是和类相关而不是和对象相关的, 那么想到然的, 这些属性也就应该保存在类的结构中, 也就是zend_class_entry中. 对象的方法同理也是和类绑定的.

在zend_class_entry, 有如下HashTable几个成员,

1. function_table, 方法集
2. default_static_members, 静态属性
3. default_properties, 默认的属性
4. constants_table, 常量表

属性如其名, 对象类型的属性, 存放在对象的成员中.

对象的方法

在zend_class_entry中的function_table是个hashTable, 这个函数表的结构和普通的函数表一样(深入理解PHP之函数), 也是以zend_op_array为最终载体, 所以和普通函数一样, 方法也是不区分大小写的, 也是可以附加arg_info的. 而不同的则是, 函数的访问权限则由zend_op_array的fn_flag属性表明.

我们知道, 在PHP内的函数, 都有统一的参数列表(遵守PHP函数约定开发的前提下),

#define INTERNAL_FUNCTION_PARAM_PASSTHRU ht, return_value, return_value_ptr, this_ptr, return_value_used TSRMLS_CC

在调用方法的时候, this关键字由函数参数中的this_ptr指明, 而对于用户定义的函数, this关键字则有Zend VM保证.

说到这里, 举个列子:

如下代码, 会得到Fatal

<?php
class Foo {
   public function Say() {
      $this = NULL;
   }
}
?>
//output:
PHP Fatal error:  Cannot re-assign $this in **

这是一个初级的保护措施, 防止this关键字被改写, 难道PHP就仅仅是做了这个保护? 不然, 让我们绕过这个保护措施看看, 如下:

<?php
class Foo {
    public $id  = "laruence";
    function Say($arr) {
        extract($arr, EXTR_OVERWRITE);
        var_dump($this);
        var_dump($this->id);
    }
}
$a = new Foo(); 

$a->sAY(array("this" => NULL)); //只是未来说明方法名不区分大小写.
?>
//output:
NULL
string(8) "laruence"

可见this关键字, 并不是简单的符号表中的item. 是在语法分析阶段, 就由ZEND Engine保证其正确性的, 并Attach在函数的结构体中.

对象的标准操作
我们对对象的操作, 比如获取属性, 设置属性, 获取对象的类, 等等, 这些常用的方法, 都是实现在对象的标准方法中的,PHP5中, 提供了23个标准方法.

在zend_object_value中的handlers指针, 就指向类常用操作的方法集合, 默认的, 这个指针指向:

ZEND_API zend_object_handlers std_object_handlers = {
    zend_objects_store_add_ref,             /* add_ref */
    zend_objects_store_del_ref,             /* del_ref */
    zend_objects_clone_obj,                 /* clone_obj */

    zend_std_read_property,                 /* read_property */
    zend_std_write_property,                /* write_property */
    zend_std_read_dimension,                /* read_dimension */
    zend_std_write_dimension,               /* write_dimension */
    zend_std_get_property_ptr_ptr,          /* get_property_ptr_ptr */
    NULL,                                   /* get */
    NULL,                                   /* set */
    zend_std_has_property,                  /* has_property */
    zend_std_unset_property,                /* unset_property */
    zend_std_has_dimension,                 /* has_dimension */
    zend_std_unset_dimension,               /* unset_dimension */
    zend_std_get_properties,                /* get_properties */
    zend_std_get_method,                    /* get_method */
    NULL,                                   /* call_method */
    zend_std_get_constructor,               /* get_constructor */
    zend_std_object_get_class,              /* get_class_entry */
    zend_std_object_get_class_name,         /* get_class_name */
    zend_std_compare_objects,               /* compare_objects */
    zend_std_cast_object_tostring,          /* cast_object */
    NULL,                                   /* count_elements */
};

默认的, 也是绝大多数的时候, 都是如上的这些标准方法.

需要指明的是, _dimension后缀的方法, 指的是通过数组($obj['name'])方式访问对象的属性.

魔术方法

魔术方法定义在class_entry中,

union _zend_function *constructor;
union _zend_function *destructor;
union _zend_function *clone;
union _zend_function *__get;
union _zend_function *__set;
union _zend_function *__unset;
union _zend_function *__isset;
union _zend_function *__call;
union _zend_function *__tostring;
union _zend_function *serialize_func;
union _zend_function *unserialize_func;

魔术方法没有默认值, 在类定义的时刻指定.

对于一些魔术方法, 比如__get/__set是被标准操作发起调用的, 所以如果我们自己编写扩展中定义的类, 如果不使用标准方法, 那么也需要在适当的时机, 主动调用这些魔术方法.

Comments

• 2010/05/18, Tweets that mention 深入理解PHP原理之对象(一) | 风雪之隅 -- Topsy.com writes: [...] This post was mentioned on Twitter by 姚东旭. 姚东旭 said: [推荐] 深入理解PHP原理之对象(一) http://goo.gl/gUMh [...]
• 2010/05/20, phppan writes: 之前由于一个纠结的私有变量的问题而看过php中类实现的一些代码，但也是粗略了解， 今天拜读鸟哥的文章，再次学习了！
• 2010/05/21, xingai writes: xingai再次学习了！
• 2010/05/26, 深入理解 PHP之require/include顺序 « 大熊猫 – konakona ——PHP程序员 writes: [...] 本文地址: http://www.laruence.com/2010/05/18/1482.html [...]
• 2010/06/18, abcasus writes: 辛苦。

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/05/14/1473.html
• 转载请注明出处

在读别人代码的时候, 在没有详细文档的时候, 如何快速的看清整个代码的结构(类结构), 就成为了一个现实的问题.

今天我就介绍一种, 自动生成UML图的方法.

假设, 我有一个项目文件夹:laruence, 在这个文件夹上有一个文件Root.php(事实上, 无论多级目录, 多个文件, 都可以).

<?php

abstract class Root {
    private $instance;
    abstract public function Hi();
}

interface Intro {
    public function Say();
}

class Sub extends Root implements Intro {
    private $instance;
    public function Say() {
        echo "I am Laruence";
    }
    public function Hi() {
        echo "Hello!";
    }
}
?>

首先, 我们要使用PHP_UML(PHP_UML)根据代码生成XMI.

使用方法比较简单, 在安装PHP_UML以后, 运行:

 phpuml laruence/ -o laruence.xmi -n laruence -f xmi  --pure-object --no-deployment-view  --no-component-view --no-docblocks

会得到一个laruence.xmi文件, phpuml的具体参数可以通过phpuml –help了解.

有了xmi以后, 如何转成UML图呢?

Visio2007不支持导入XMI, 我找到了另外的一个工具:Altova Umodel, 这个工具可以支持XMI到UML图的转换, 需要注册, 不过提供了30天的使用许可(大家要是有更好的替换方案, 欢迎补充).

在Umodel导入laruence.xmi以后 ,生成UML图, 就得到了如下的PNG:

UML图

是不是很方便呢?

另外PHP_UML还可以生成html格式, 做为一种doc gen工具也不错. 更可以通过xmi生成PHP文件.

Comments

• 2010/05/14, cc0cc writes: 哥学社不遗余力地顶起，有没有反向的办法，通过uml生成php代码？
• 2010/05/14, toms writes: 要是能进一步识别程序的调用关系就更好啦
• 2010/05/14, 雪候鸟 writes: @cc0cc 有, visio 03据说有个插件, 可以把UML图导出成XMI. PHP_UML就可以根据XMI生成PHP代码了, 当然, mapForce也可以导出XMI
• 2010/05/14, Tweets that mention 使用PHP_UML生成代码的UML图 | 风雪之隅 -- Topsy.com writes: [...] This post was mentioned on Twitter by 小白. 小白 said: 使用PHP_UML生成代码的UML图 - http://goo.gl/UAQp [...]
• 2010/05/18, 玉丰 writes: 哈哈，去试试。还有，建议换个验证码，现在这个太难用了。
• 2010/05/23, 網站製作學習誌 » [Web] 連結分享 writes: [...] 使用PHP_UML生成代码的UML图 [...]
• 2010/06/05, luckgo writes: 我折腾到深夜，装了Altova MapForce,但怎么也找不到导入xmi的菜单，倒是在google上找到Altova Umodel导入xmi的介绍，请问Laruence，是不是你搞错了耶？
• 2010/06/05, 雪候鸟 writes: @luckgo 正是, 正是, 多谢指正, 已经修改.
• 2010/07/16, lake writes: 好东西，谢谢，今晚有得折腾了。哈哈
• 2010/08/11, tirisfal writes: 如果是导出html，怎么支持utf-8呢？

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/04/15/1414.html
• 转载请注明出处

ob_flush/flush在手册中的描述, 都是刷新输出缓冲区, 并且还需要配套使用, 所以会导致很多人迷惑…

其实, 他们俩的操作对象不同, 有些情况下, flush根本不做什么事情..

ob_*系列函数, 是操作PHP本身的输出缓冲区.

所以, ob_flush是刷新PHP自身的缓冲区.

而flush, 严格来讲, 这个只有在PHP做为apache的Module(handler或者filter)安装的时候, 才有实际作用. 它是刷新WebServer(可以认为特指apache)的缓冲区.

在apache module的sapi下, flush会通过调用sapi_module的flush成员函数指针, 间接的调用apache的api: ap_rflush刷新apache的输出缓冲区, 当然手册中也说了, 有一些apache的其他模块, 可能会改变这个动作的结果..

有些Apache的模块，比如mod_gzip，可能自己进行输出缓存，
这将导致flush()函数产生的结果不会立即被发送到客户端浏览器。 

甚至浏览器也会在显示之前，缓存接收到的内容。例如 Netscape
浏览器会在接受到换行或 html 标记的开头之前缓存内容，并且在
接受到 </table> 标记之前，不会显示出整个表格。 

一些版本的 Microsoft Internet Explorer 只有当接受到的256个
字节以后才开始显示该页面，所以必须发送一些额外的空格来让这
些浏览器显示页面内容。

所以, 正确使用俩者的顺序是. 先ob_flush, 然后flush,

当然, 在其他sapi下, 不调用flush也可以, 只不过为了保证你代码的可移植性, 建议配套使用.

Comments

• 2010/04/16, Anonymous writes: 很好，尤其在comet等需要特别注意cache的场景，需要注意这些
• 2010/04/16, Tweets that mention 深入理解ob_flush和flush的区别 | 风雪之隅 -- Topsy.com writes: [...] This post was mentioned on Twitter by Angus Li. Angus Li said: 深入理解ob_flush和flush的区别 http://ff.im/-j5oDz [...]
• 2010/04/17, 網站製作學習誌 » [Web] 連結分享 writes: [...] 深入理解ob_flush和flush的區別 [...]
• 2010/04/17, xiaokai writes: 受教了, 能否加个友情链接. http://www.lacorey.com 贵站的已加了..
• 2010/05/19, Sun writes: 谢谢
• 2010/09/07, Lela22Stein writes: Every body remembers that our life is not cheap, nevertheless some people need cash for different stuff and not every one gets enough cash. Therefore to get fast mortgage loans and bank loan should be good way out.

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/04/12/1396.html
• 转载请注明出处

最近公司组织了个PHP安全编程的培训, 其中涉及到一部分关于Mysql的”SET NAMES”和mysql_set_charset (mysqli_set_charset)的内容:

说到, 尽量使用mysqli_set_charset(mysqli:set_charset)而不是”SET NAMES”, 当然, 这个内容在PHP手册中也有叙及, 但是却没有解释为什么.

最近有好几个朋友问我这个问题, 到底为什么?

问的人多了, 我也就觉得可以写篇blog, 专门介绍下这部分的内容了.

首先, 很多人都不知道”SET NAMES”到底是做了什么,

我之前的文章深入MySQL字符集设置中, 曾经介绍过character_set_client/character_set_connection/character_set_results这三个MySQL的”环境变量”, 这里再简单介绍下,

这三个变量, 分别告诉MySQL服务器, 客户端的编码集, 在传输给MySQL服务器的时候的编码集, 以及期望MySQL返回的结果的编码集.

比如, 通过使用”SET NAMES utf8″, 就告诉服务器, 我用的是utf-8编码, 我希望你也给我返回utf-8编码的查询结果.

一般情况下, 使用”SET NAMES”就足够了, 也是可以保证正确的. 那么为什么手册又要说推荐使用mysqli_set_charset(PHP>=5.0.5)呢?

首先, 我们看看mysqli_set_charset到底做了什么(注意星号注释处, mysql_set_charset类似):

//php-5.2.11-SRC/ext/mysqli/mysqli_nonapi.c line 342
PHP_FUNCTION(mysqli_set_charset)
{
    MY_MYSQL            *mysql;
    zval                *mysql_link;
    char                *cs_name = NULL;
    unsigned int        len;

    if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC, getThis()
		, "Os", &mysql_link, mysqli_link_class_entry, &cs_name, &len) == FAILURE) {
        return;
    }
    MYSQLI_FETCH_RESOURCE(mysql, MY_MYSQL*, &mysql_link, "mysqli_link"
        , MYSQLI_STATUS_VALID);

    if (mysql_set_character_set(mysql->mysql, cs_name)) {
		//** 调用libmysql的对应函数
        RETURN_FALSE;
    }
    RETURN_TRUE;
}

那mysql_set_character_set又做了什么呢?

//mysql-5.1.30-SRC/libmysql/client.c, line 3166:
int STDCALL mysql_set_character_set(MYSQL *mysql, const char *cs_name)
{
  struct charset_info_st *cs;
  const char *save_csdir= charsets_dir;

  if (mysql->options.charset_dir)
    charsets_dir= mysql->options.charset_dir;

  if (strlen(cs_name) < MY_CS_NAME_SIZE &&
     (cs= get_charset_by_csname(cs_name, MY_CS_PRIMARY, MYF(0))))
  {
    char buff[MY_CS_NAME_SIZE + 10];
    charsets_dir= save_csdir;
    /* Skip execution of "SET NAMES" for pre-4.1 servers */
    if (mysql_get_server_version(mysql) < 40100)
      return 0;
    sprintf(buff, "SET NAMES %s", cs_name);
    if (!mysql_real_query(mysql, buff, strlen(buff)))
    {
      mysql->charset= cs;
    }
  }
  //以下省略

我们可以看到, mysqli_set_charset除了做了”SET NAMES”以外, 还多做了一步:

sprintf(buff, "SET NAMES %s", cs_name);
if (!mysql_real_query(mysql, buff, strlen(buff)))
{
  mysql->charset= cs;
}

而对于mysql这个核心结构的成员charset又有什么作用呢?

这就要说说mysql_real_escape_string()了, 这个函数和mysql_escape_string的区别就是, 它会考虑”当前”字符集. 那么这个当前字符集从哪里来呢?

对了, 你猜的没错, 就是mysql->charset.

mysql_real_string在判断宽字符集的字符的时候, 就根据这个成员变量来分别采用不同的策略, 比如如果是utf-8, 那么就会采用libmysql/ctype-utf8.c.

看个实例, 默认mysql连接字符集是latin-1, (经典的5c问题):

<?php
    $db = mysql_connect('localhost:3737', 'root' ,'123456');
    mysql_select_db("test");
    $a = "\x91\x5c";//"慭"的gbk编码, 低字节为5c, 也就是ascii中的"\"

    var_dump(addslashes($a));
    var_dump(mysql_real_escape_string($a, $db));

    mysql_query("set names gbk");
    var_dump(mysql_real_escape_string($a, $db));

    mysql_set_charset("gbk");
    var_dump(mysql_real_escape_string($a, $db));
?>

因为, “慭”的gbk编码低字节为5c, 也就是ascii中的”\”, 而因为除了mysql(i)_set_charset影响mysql->charset以外, 其他时刻mysql->charset都为默认值, 所以, 结果就是:

$ php -f 5c.php
string(3) "慭\"
string(3) "慭\"
string(3) "慭\"
string(2) "慭"

大家现在很清楚了吧?

Comments

• 2010/04/12, qywyh writes: 看贴不回木jj，学习了,顶！
• 2010/04/12, felix021 writes: 1L真狠。。。
• 2010/04/13, Tweets that mention 深入理解SET NAMES和mysql(i)_set_charset的区别 | 风雪之隅 -- Topsy.com writes: [...] This post was mentioned on Twitter by 高春辉, Angus Li. Angus Li said: 深入理解SET NAMES和mysql(i)_set_charset的区别 http://ff.im/-iUWcK [...]
• 2010/04/13, kevin writes: addslashes(), str_replace()等等基于ascii编码的函数都会遇到这种问题。mysql_*系列有解决方案，别的有什么好的解决方案么？
• 2010/04/13, [转]深入理解SET NAMES和mysql(i)_set_charset的区别 - coder辉的it生涯 writes: [...] 本文地址: http://www.laruence.com/2010/04/12/1396.html [...]
• 2010/04/13, Anders writes: 之前
• 2010/04/13, Anders writes: 之前遇到这个问题，但是 使用的是PDO, 不知道如何解决。
• 2010/04/13, 雪候鸟 writes: @Anders pdo找不到类似的方法,,,,,
• 2010/04/13, cz writes: 所以这两年我一看到SET NAMES的代码就要破口大骂，虽然utf-8编码里不存在5c问题 另外对于PDO，可以用prepared statement来解决。这也是一个比字符串过滤更好的防止注入的方法
• 2010/04/13, 好黑啊 writes: 非常good的文章，我very like
• 2010/04/13, aleafs writes: 太清楚了
• 2010/04/17, 網站製作學習誌 » [Web] 連結分享 writes: [...] 深入理解SET NAMES和mysql(i)_set_charset的区别 [...]
• 2010/04/18, Yufeng writes: 学习了，呵呵。
• 2010/05/14, kazaff writes: thx
• 2010/07/03, OllieNoel writes: Have no enough cash to buy a car? Worry no more, just because that is achievable to get the credit loans to solve such problems. Thus get a small business loan to buy everything you need.
• 2010/09/03, blues writes: 新手参上 竟然深入到C中了,C语言没怎么学会,看了个不大懂,自学的时候也没注意到这些问题,见识了,你的博客都很有深度啊,会经常来看的.目前还只能做做应用,无法深入到C,你这篇文章改变了我对php的理解,本以为可以不学C了,现在发现要深入学习还是需要知其根源,希望2年后毕业的时候也能有这样的深度.

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/02/23/1310.html
• 转载请注明出处

Apache2开始引入了Hook方式, 对应的在PHP中也提供了apache2handler这种sapi.

和我之前介绍过的PHP lifecycle不同, 这种情况下的PHP, 通过注册handler钩子, 从而可以在handler hook阶段有机会处理请求, 通过判断请求的handler, 来确定是否需要处理, 如果需要就会调用自身的处理器.

那么, 这种情况下也就有了多种配置方法, 主要考虑如下俩种方式(第二种可以有多种变种):

第一种:  AddType application/x-httpd-php .php
第二种:
      <FilesMatch \.php$>
          SetHandler application/x-httpd-php
     </FilesMatch>

首先来说, 这俩中方式的起作用的时刻不同, 对于第一种方式来说, 他是在type_check钩子阶段起作用的, 也就是在apache2src/modules/http/mod_mime.c中, 通过注册type_checker钩子, 加入find_ct(content_type), 在find_ct中, 通过配置文件中的mime映射, 或者是通过addType指令增加的映射, 根据文件的扩展来填充请求中的handler字段:

而对于第二种方式, 是在fixup钩子阶段, 通过注册fixups钩子阶段加入core_override_type(apache2src/server/core.c)函数, 来将目录级的配置指令生效.

而fixups钩子是晚于type_checker钩子的, 也是handler钩子之前最后的一个可以利用的钩子. 所以如果同时采用1,2俩种方式, 那么第二种方式会覆盖第一种方式设置的handler.

其次, 俩种方式依赖的数据结构不同, 第一种方式依赖的是一个全局的mime对照表extension_mappings, 这个表由mime配置文件和AddType指令而来.

而对于第二种方式, 它是根据配置文件构造的dir_config而来:

....
  core_dir_config *conf =
        (core_dir_config *)ap_get_module_config(r->per_dir_config,
                                                &core_module);

    /* Check for overrides with ForceType / SetHandler
     */
    if (conf->mime_type && strcmp(conf->mime_type, "none"))
        ap_set_content_type(r, (char*) conf->mime_type);

    if (conf->handler && strcmp(conf->handler, "none"))
        r->handler = conf->handler;
.....

• 本文地址: http://www.laruence.com/2010/02/03/1283.html
• 文章转自: CSDN

评论: 从最早听说Facebook搞一个神奇的项目开始, 我就在猜测它会怎么做? 想APC一样编译成Opcode? 或者是象phc从Opcode再次加工. 但, 今天看到的介绍, 让我还是有点出乎意料…哪就是- HipHop提供编译器, 让你可以”用PHP的语法写C++代码”.

以下为转载原文:
Facebook神秘的PHP项目HipHop for PHP终于揭开面纱。这个项目由一个PHP到C++的转换程序，一个重新实现的PHP运行库，和许多常用PHP扩展的重写版本构成，目的是旨在加速和优化 PHP。

用Facebook 官方博客（无法直接访问）上项目负责人赵海平（北大1987届遗传与分子生物专业，普林斯顿计算机科学博士）的话说，HipHop项目对 Facebook影响巨大。它目前已经支撑了Facebook 90%的Web流量。由于HipHop，Facebook Web服务器上的CPU使用平均减少了50%，从而大大减少了服务器的需求。为了让这一改进也惠及社区，他们决定将之开源，希望能够进一步帮助提高更多大 型复杂PHP网站的可伸缩性。

PHP和Facebook的问题

众所周知，Facebook的前端主要是用PHP写的。赵海平说，过去六年Facebook从PHP语言的进展上获益良多。PHP非常简单，易学易 用，好读好调试，因此新工程师成长很快，有利地促进了Facebook的更快的创新。

PHP是一种脚本语言，其好处是编程效率高，能够支持产品的快速迭代。但是与传统的编译语言相比，脚本语言的CPU和内存使用效率不好。随着 Ajax技术的广泛采用，加上SNS对动态要求较高，这些缺点更显得突出。对于每月超过4000亿次PV的Facebook来说，如何实现扩展，尤其具有 挑战性。

常见的办法是直接用C++重写PHP应用中比较复杂的部分，作为PHP扩展。实际上，PHP就转变为一种胶水语言，连接前端HTML和C++应用逻 辑。从技术角度讲这也没有问题，但是增加了技能需求，能够在整个应用上工作的工程师数量就大大减少了。学习C++只是编写PHP扩展的第一步，接下来还要 理解Zend API。由于Facebook的工程团队较小，每个工程师要支持100万以上的用户。有些代码不是团队里每个人都能看懂，这对于Facebook是无法接 受的。

Facebook网站本身的可伸缩性更具挑战性，因为几乎每次页面浏览都是有个性化体验的登录用户发起。浏览主页 时，系统需要查询所有朋友、朋友最重要的状态更新、 根据隐私设置筛选结果，然后还要显示评论、照片等等动态，这一切都需要在一秒内完 成。

自2007年以来，Facebook曾写过几种不同办法解决这些问题。其中包括用另 一种语言重写Facebook，但是由于开发的复杂性和速度等原因，未能实现。他们还重写了PHP的核心部分Zend引擎，并提交给了PHP项目，但最终 还是没有获得所需的性能。最后，他们选择了HipHop，终于得偿所愿。

有了HipHop，工程师可以编写代码，用PHP编写组合最后页面的逻辑，并能够继续快速迭代，同时后端服务使用C++, Erlang, Java, Py thon编写，提供新闻提要、搜索、聊天和其他核心功能。

HipHop开发故事

赵海平透露，项目最初是来自几年前Facebook公司一次Hackathon活动（员工在一个晚上自由发挥，实验新的想法），他手工将PHP转换 为C++代码，虽然语法上很类似，但是无论是CPU还是内存使用，转换后的C++代码都大大优于PHP。于是他想，如果构建一个系统，编程实现转换，会怎 么样呢？

在此之前，已经有了不少改善PHP性能的方法。Zend引擎在运行时转换PHP源代码为运行在Zend虚拟机上的opcode。开源项目APC和 eAccelerator将输出缓存，为大多数PHP网站所使用。此外，还有Zend Server这样的商业产品，通过opcode优化和缓存，提高PHP速度。赵海平选择了另一条道路，将PHP直接转为C++，然后再变成本地机器码。当 然，有许多开源项目也是同样的思路，Roadsend和phc编译为C，Quercus编译为Java，而Phalanger编译为.NET。

Hackathon之后8个月，赵海平拿出了原型，足以说明这条路可以走通，编译后的代码的确更快。不久，Iain Proctor和Minghui Yang加入进来。接下来又开发了10个月，在生产服务器上测试了6个月。然后正式上线部署，6个月之后，Facebook 90%以上的Web流量都使用了HipHop。

按赵海平的说法，凭借HipHop，Facebook Web服务器上的CPU使用平均减少了50%，从而大大减少了服务器的需求。项目对Facebook影响巨大。为了让这一改进也惠及社区，他们决定将之开 源，希望能够进一步帮助提高更多大型复杂PHP网站的可伸缩性。

Hiphop for PHP transformation process

HipHop的原理

HipHop将PHP代码转换为高度优化的C++代码，然后再用g++编译器编译。它可以保持语义等效地执行源代码，但为了提高性能，牺牲了一些很 少用到的特性，比如eval()。

HipHop开发中的主要困难在于，在PHP和C++这两种很不一样的语言之间怎么实现转换。虽然PHP也可以写一些很巧妙的动态特性，但是大多数 PHP代码还是非常简单的。if (…) {…} else {..} 比foo($x) { include $x; } 肯定更常见。这为性能提高提供了机会。HipHop生成的代码尽可能地使用函数和变量的静态绑定。同时，还使用类型推演来选出变量最可能对应的某个类型， 从而节省内存。

转换过程分三步：

1. 静态分析。收集声明关系和依赖关系等信息。

2. 类型推演。选择最合适的类型，是C++的标量？还是String, Array, classes, Object或者Variant。

3. 代码生成。大部分直接将PHP语句和表达式对应为C++的语句和表达式。

在开发过程中，还有一个副产品：HPHPi，是一个实验性的解释器。通过它，不编译PHP源代码也可以运行。它已经用于HipHop自身的调试中。

HipHop在保持了PHP优点的同时，也兼得了C++的性能优势。项目总共有30万行代码，5000多个单元测试。所有这些都将以PHP开源许可 证形式发布到GitHub。

更多信息，可以申请加入HipHop的邮件列表：

http://groups.google.com/group/hiphop-php-dev

Comments

• 2010/02/04, 侯良 writes: 这个是个好东西。 一定要把它学会 。
• 2010/02/05, cnan writes: 感觉想不想google的用java写JavaScript
• 2010/02/10, yufeng writes: 前一阵子看到了，不过没有这篇文章详细，据说还要开源的。
• 2010/02/11, jimmy writes: 是 c++ 而不是 c 的原因是什么呢，laruence.
• 2010/02/21, Anonymous writes: 本来我想用的是C，而不是C++。 看来慢了一步了。

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/02/02/1272.html
• 转载请注明出处

在PHP5.2.6以前, json_decode一个字符串, 将会返回字符串本身.

php -r "var_dump(json_decode('laruence'));"
//输出
string(8)"laruence";

但是, 不知道是不是因为之前在php bug中, 有人提议对于这种情况, 因为字符串不是合法的json格式的串, 所以应该出错, 返回NULL(http://bugs.php.net/bug.php?id=45989). 所以在PHP5.2.11之后(具体是从哪个版本开始, 我回头再验证), 竟然返回NULL了.

php -r "var_dump(json_decode('laruence'));"
//输出
NULL

但值得注意的是, 对于numeric_string, 都是返回numeric_string的数值形式.

php -r "var_dump(json_decode('0x3f34'));"
//输出
int(16180)

另外, 在PHP5.3以后,可以通过json_last_error()来验证转换是否正确.

Comments

• 2010/02/02, 雪候鸟 writes: 因为之前把几个PHP版本的安装路径搞混了, 看错了5.3的实现, 误以为5.3中和5.2.6一致, 抱歉给大家造成误解.
• 2010/02/02, enjoy writes: 我在5.2.8下试了下。 php -r "var_dump(json_decode('laruence'));" //输出 string(8) "laruence"
• 2010/02/02, 雪候鸟 writes: @enjoy 我看到在5.2.9的release notes中有关于json_decode的, 但不是和这个相关的.
• 2010/02/02, Deepseath writes: 类似这样频繁改动的函数，我会重新写个函数。呵呵，虽然麻烦但兼容性相对好一些，而且一旦确定环境了，进行优化也相对容易一些^_^
• 2010/02/02, Anders writes: guoxiaod@guoxiaod>php -r 'var_dump(json_decode("\"abc\""));' string(3) "abc" guoxiaod@guoxiaod>php -v PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) (built: Jan 6 2010 22:41:56)
• 2010/02/02, 雪候鸟 writes: @anderson 不要"\"abc\"", 这里是指"abc", ;)
• 2010/02/23, darasion writes: json_encode 有没有类似这样的问题？
• 2010/03/07, RainChen writes: 一般都会把这些封装到一个类，用静态方法调用，如 JSON::decode() 这样一来可以方便管理（归类、增加相关的方法）， 二来可以避免PHP升级后的接口变异。 缺点是比直接调用原生的函数慢一点，但对比带来的可维护性的好处，这点效率牺牲完全可以忽略

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/01/20/1247.html
• 转载请注明出处

通过在nginx.conf中模拟PATH_INFO的方法会有一个bug. 那就是PATH_INFO不会被urldecode.

对于Apache+PHP(php2handler)来说, PATH_INFO来自Apache, 不会有问题, 对于Apache fastcgi也应该没有问题, 因为PATH_INFO也是由Apache生成.

但是对于nginx+fastcgi, 因为对于cgi来说PATH_INFO来自于ENV(fastcgi_params), 而php-cgi中的import_environment_variables不会对ENV中的变量做urldecode.

这样, nginx看到的url是urlencode以后的, 从url中分离出来的PATH_INFO也是urlencode后的, forward给php proxy以后, PHP看到的PATH_INFO也是urlencode的了.

所以, 如果在PATH_INFO中包含一些宽字符, 或者是”+”, 那就要注意了, 需要我们主动的urldecode一下再使用.

Comments

• 2010/03/01, verdana writes: 尝试一下 fastcgi_split_path_info

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2010/01/03/1225.html
• 转载请注明出处

一个想当然造成的错误.

需求是这样的, 我需要给一个二进制流加入一个签名串. 那么首先, 理所当然我的写了一个签名函数, 考虑到要判断签名操作是否成功, 所以我采用了传引用:

function sign(&$carrier, $fingerprint) {
	if (NULL === $fingerprint) {
		return FALSE;
	}
	//加入签名
	$carrier = 签名逻辑.
	return TRUE;
}

接下来, 考虑到, 如果签名失败, 那还是使用原来的字符串做为结果, 所以, 我想当然的写下了如下的代码:

$bin_str = **************;

$success = sign($after_signed = $bin_str, "laruence's fingerprint");
if ($success) {
	//使用$after_signed
} else {
	//使用$bin_str
}

考虑到简单变量是传值引用, 在bin_str赋值给after_signed以后, 我以为after_signed的引用会传递给carrier..
但, 结果是, after_signed并没有被加入签名串…

那为什么会错呢?

经过对opcode的分析, 发现原来, PHP在做二元赋值运算的时候, 返回值并不是左值,而是一个临时变量. 也就是说对于:

$a = $b;

它的返回值, 并不是$a, 而是一个临时变量, 假设是$2.
所以传递给sign函数的, 并不是$a的引用, 而是$2;

以下内容是对源码的分析范畴, 如果只是想知道结论的, 略过如下也可:

现在, 结合之前的文章深入理解PHP原理之变量分离/引用(Variables Separation)中介绍过的相关知识, 来做个详细是分析:

$a = "laruence";
function ch(&$p) {
    debug_zval_dump($p);
    $p = 'eve';
    debug_zval_dump($p);
}

debug_zval_dump($a);
ch($a);
ch($b=$a);

运行结果是:

//初始的a
string(8) "laruence" refcount(2)
//第一次调用change中的p
string(8) "laruence" refcount(1)
string(3) "eve" refcount(1)
//第二次赋值结果调用change中的a
string(3) "eve" refcount(3)
string(3) "eve" refcount(2)

首先, 最初的时候, $a的引用是2, 这是因为简单变量传值, 所以传给debug_zval_dump后, $a有一个copy的引用计数.

当第一次调用的时候, 我们直接传$a, 因为change函数的参数申明是传引用, 在change中调用debug_zval_dump时, $p是一个引用. 而要传值调用, 所以产生了一次分离, 得到计数为1.

重点看下第二次调用, 此时change中第一次debug_zval_dump的引用计数是3. 怎么会是3呢?.
此处要是3. 那也就是说$p是一个引用计数为2的非引用变量.

可是, 明明不是申明了change接受引用参数么?

没办法, 查看源代码. 在语法分析时刻, 看出了差别:

non_empty_function_call_parameter_list:
        expr_without_variable
		   { Z_LVAL($$.u.constant) = 1;
				zend_do_pass_param(&$1, ZEND_SEND_VAL, Z_LVAL($$.u.constant) TSRMLS_CC); }
    |   variable
			{ Z_LVAL($$.u.constant) = 1;
				zend_do_pass_param(&$1, ZEND_SEND_VAR, Z_LVAL($$.u.constant) TSRMLS_CC); }

对于第二次调用, 它将满足的是第一条规约规则, 也就是传给zend_do_pass_param的第二个参数是ZEND_SEND_VAL…

继续追查zend_do_pass_param:

if (op == ZEND_SEND_VAR && zend_is_function_or_method_call(param)) {
	//是否是函数或者方法的返回值
	/* Method call */
	op = ZEND_SEND_VAR_NO_REF;
	send_function = ZEND_ARG_SEND_FUNCTION;
} else if (op == ZEND_SEND_VAL && (param->op_type & (IS_VAR|IS_CV))) {
	op = ZEND_SEND_VAR_NO_REF;//在这里被改成了NO_REF
}

也就是, 因为第二次调用的时候传递给change的变量, 是一个”直接量”, 并且属于IS_VAR, 所以PHP会把传递方式改变为传值.

所以在change中第一次debug_zval_dump的时候, 引用计数就是3了. ~

其实, 分析到这里的时候, 我们可以类比函数的返回值做为参数的情形(第一个if判断条件). 想象赋值也和函数调用一样, 有返回值, 就容易理解多了.

Comments

• 2010/01/03, LANYE writes: ..嘿嘿
• 2010/01/03, Anders writes: 有些 trick 样的语句还是少用的好，呵呵。
• 2010/01/03, PeterYu writes: 5.3开始,直接禁止了引用一个"非明示的变量值". :-),你可以试试,
• 2010/01/03, 雪候鸟 writes: @PeterYu 在PHP 5.3.0 (cli)下, 关于这个问题的语法分析逻辑以及complie.c中的zend_do_pass_param逻辑和PHP5.2.x一样,经过我测试, 结论和本文的一致. 另外我没听过"非明示变量值"这个名词, 是指匿名变量(变量直接量)么?
• 2010/01/05, 小蔡 writes: $a = 'test'; $b = & $a; function ch(&$p) { debug_zval_dump($p); $p = 'eve'; debug_zval_dump($p); } debug_zval_dump($a); ch($a); ch($b=$a); 为什么这里输出的refcount全都是1呢？
• 2010/01/05, 雪候鸟 writes: @小蔡 b是a的引用, 调用的时候要传值, 所以就产生分离了啊.
• 2010/01/05, 小蔡 writes: 感觉还是有点乱，晚上回去看看源码
• 2010/01/07, shinezhou writes: $a = $b这个表达式的结果竟然不是左值$a... 让人郁闷了~
• 2010/01/16, erway writes: 博主：你好！ 我是机械工业出版社华章公司（www.hzbook.com，中国IT出版4强）的高级策划编辑杨福川，冒昧打扰了，还请见谅。 今天无意中从一位朋友的博客中链接到了你的博客中，顿时眼前一亮，原来又发现了一位高人。我一直想策划一本关于PHP源码剖析的书，苦于找不到作者，没想到今天无意中发现了一位大牛，庆幸哉！我仔细拜读了你撰写的关于PHP的文章，看得出来你对PHP颇有研究，似乎对PHP源码情有独钟，何不系统性地来分析一下PHP的源码呢？这不但能造福广大PHPer，也许能成为你人生的一个转折点，哈哈。 我准备策划一系列关于源码分析的书，目前已经出版和策划的有： 1. 《Spring技术内幕——深入解析Spring架构与设计原理》，最近刚出版，当当网2天就卖断货。 2. 《Struts技术内幕——深入解析Struts架构与设计原理》，正在策划中。 3. 《JVM技术内幕》，正在策划中。 4. 《MySQL技术内幕》，正在策划中。 《PHP技术内幕》也是我策划的这套书中非常重要的一本，一直还没有找到比较合适的朋友来写，今日认识了兄弟你，我想也许我找到了这个选题的主人，不知道是否有机会与你合作。为了便于联系，能否交换一下联系方式（MSN：erwa_yang@live.cn；QQ：15693352）？ 期待与你取得联系，期待与你合作。
• 2010/01/20, shiny writes: @erway 同期待laruence 如果写了必买

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2009/12/26/1198.html
• 转载请注明出处

对于PHP的中的数据来源, 不外乎有俩种:

1. 来自代码中
2. 来自外部(GET/POST/DB)

对于代码中的变量(也就是直接量)来说, 变量分配/赋值在编译期, 活跃在执行器, 在请求关闭期被销毁.对于这些变量来说, 使用APC进行Opcode缓存, 则会缓存这部分变量的值.

而对于来自外部的变量, 变量分配/赋值在编译器后, 执行期前, 在请求关闭期被销毁,对于这些变量来说, 使用APC进行OpCode缓存, 是不会被缓存的.

今天就着重关注下外部变量的一个部分,GET来的数据的整个生命周期.

假设, 有如下请求到来:

	GET /index.php?name=laruence&career[]=yahoo&career[]=baidu

而, 在index.php中:

<?php
	$name 	= $_GET['name'];
	$career = $_GET['career']; //array

我们知道, 在最后的执行期, $_GET数组必然包含如下片段:

	$_GET = array(
		'name'   => 'laruence',
		'career' => array(
			'yahoo', 'baidu',
		),
	)

那么, 我们今天就重点关注下, Query String是如何构建成_GET数组的(关于GET变量的生成, 请一并阅读我之前的文章: “PHP的GET/POST等大变量生成过程“):

在请求到来时刻,php_request_startup(定义在main.c)被调用,来做初始化现场. 在这个过程中包括设置超时值,调用各个模块的请求初始化函数. 当然也包括我们关心的, 创建变量环境.

php_hash_environment根据php.ini中的variables_order来依次初始化各个预定义大变量, 那么对于$_GET来说:

...
case 'g':
case 'G':
	if (!_gpc_flags[2]) {
		sapi_module.treat_data(PARSE_GET, NULL, NULL TSRMLS_CC);
		_gpc_flags[2] = 1;
		if (PG(register_globals)) {
			php_autoglobal_merge(&EG(symbol_table),
				Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_GET]) TSRMLS_CC);
		}
	}
break;
...

大体可以看出,这段逻辑,首先通过treat_data来生成变量hash(PG(http_globals)[TRACK_VARS_GET]), 如果打开了auto_register_globals,则再把$_GET数组中的变量加入到符号表中.

treat_data是属于sapi_module_struct中的一个成员:

 注意:	本文基于apache2handler方式的sapi, 这个启动过程和之前的文章sapi
原理中的启动过程略有不同, php5通过注册apache2的ap_hook_post_config挂钩,
在apache server启动的时候启动php(php_apache_server_startup,定义在
sapi/apache2hander/sapi_apache2.c中), 在这个函数中调用sapi_startup启动sapi,
继而通过调用php_apache2_startup来注册sapi module struct,
然后调用php_module_startup来初始化PHP, 其中又会初始化ZEND引擎,
以及填充zend_module_struct中的treat_data成员(通过php_startup_sapi_content_types)
为php_default_treat_data

现在回过头来继续看treat_data(也就是php_default_treat_data):

....
if (arg == PARSE_GET) {     /* GET data */
	c_var = SG(request_info).query_string;
	if (c_var && *c_var) {
		res = (char *) estrdup(c_var);
		free_buffer = 1;
	} else {
		free_buffer = 0;
	}
} else if (arg == PARSE_COOKIE) {       /* Cookie data */
....

在上面的逻辑中, 给res复制为query_string, SG(request_info)是一个代表了当前请求信息的结构体, 其中query_string是在php_apache_request_ctor中通过复制apache的reqeust_rec结构体中的args而来的.

对于本文的例子来说, 此时res即为”name=laruence&career[]=yahoo&career[]=baidu”,

继续在treat_data中, 随后的逻辑是:

var = php_strtok_r(res, separator, &strtok_buf);
...
while (var) {
	val = strchr(var, '=');

	if (arg == PARSE_COOKIE) {
		/* Remove leading spaces from cookie names,
			needed for multi-cookie header where ; can be followed by a space */
		while (isspace(*var)) {
			var++;
		}
		if (var == val || *var == '\0') {
			goto next_cookie;
		}
	}

	if (val) { /* have a value */
		int val_len;
		unsigned int new_val_len;

		*val++ = '\0';
		php_url_decode(var, strlen(var));
		val_len = php_url_decode(val, strlen(val));
		val = estrndup(val, val_len);
		if (sapi_module.input_filter(arg, var, &val, val_len, &new_val_len TSRMLS_CC)) {
			php_register_variable_safe(var, val, new_val_len, array_ptr TSRMLS_CC);
		}
		efree(val);
	} else {
...

首先, 通过php_strtok_r把res根据”&”分割成一个一个的”key=value”段, 接下来分别为var和val复制为key和value, 注意到这个过程中会分别对var和val做php_url_decode.

最后通过php_register_variable_safe, 给array_ptr(此时指向PG(http_globals)[TRACK_VARS_GET], 也就是$_GET)添加一个名为var值为val的成员.

到了这一步, 我们的$_GET数组中, 就包含了如下的成员:

'name'   => 'laruence',
'career' => array(
	'yahoo', 'baidu',
),

未完待续(变量的销毁过程)…

Comments

• 2009/12/26, Robin writes: Hi，麻烦问问，如果想去掉 "[]"，改成 name=laruence&career=yahoo&career=baidu $_GET数组还要不变，怎么改？ 谢谢了。
• 2009/12/26, 雪候鸟 writes: @robin 这样的话,最终career的值为baidu
• 2009/12/28, phppan writes: 在window下用vc看也比较舒服 抚琴居主人有一篇文章有相关介绍 http://www.yanbin.org/blog/commentary-on-php-chap1_1-prep.html
• 2009/12/28, 天缘 writes: 还没真的没深究过这些源码，佩服博主认真的研究
• 2009/12/28, phpcoder writes: 强悍的博主, 还有点不明白就是数组是怎么parse来的呢?
• 2009/12/28, 雪候鸟 writes: @phpcoder 呵呵,就是简单的字符串parse了, 遇到"[]", 就知道是个数组..
• 2009/12/30, eve writes: 楼主，求交往
• 2010/03/25, Anonymous writes: 怎么没有了，写完吧，大虾
• 2010/06/22, 库从志 writes: 博主 写得很深入
• 2010/07/25, 深入理解PHP原理之变量生命期(一) | haohtml's blog writes: [...] 本文地址: http://www.laruence.com/2009/12/26/1198.html [...]
• 2010/08/08, 美味分享1 | ichenkun writes: [...] 5: 深入理解PHP原理之变量 生命期(一) [...]

• 作者: laruence(http://www.laruence.com)
• 本文地址: http://www.laruence.com/2009/12/09/1180.html
• 转载请注明出处

今天有人问我isset和is_null啥区别,

看手册上讲的话, isset和is_null的功能几乎完全”相反的一样”..

是不是isset就是一个is_null的相反的别名?

诶, 要说区别, 那还真的是很多~

一切的不同都是因为: is_null是函数, isset是语句.

isset是语句, 和echo, print一样, 是PHP本身的一种语言结构.

而is_null是函数, 和我们一般的函数一样, 可以做为可变函数调用.

你也许会说, 好了,好了,我知道函数和语句的区别, 但到底是TMD什么区别?

诶, 所谓语句,语言结构, 就是说, 是语言本身支持的语句, 标识符.

比如, for, foreach, continue 等等, 它们在语法分析的时刻就被”抹掉”(逻辑上替代了)了.

让我们看看isset这个语句在语法分析的过程中, 是如何被”抹掉”的.

1. 首先, 在词法分析的时候, isset会被识别为T_ISSET标识符.

2. 而在语法分析阶段, isset($var)这个指令, 会被分析成一条Opcode:ZEND_ISSET_ISEMPTY_VARS.

你可以理解isset就想C语言里面的宏, 在编译/执行之前已经被展开了.

因为这个,　所以在表现上,　会有如下的不同:

因为is_null是函数, 所以它可以通过如下方式调用:

<?php
$var  = NULL;
$func = "is_null";
$func($var);
?>

而, isset因为是语句, 所以不能这样调用.

因为is_null是函数, 所以它可以接受函数返回值做为参数, 而isset不行(当然, 如果PHP想支持, 其实也是可以的, 只不过就要增加编译阶段的复杂度了):

<?php
is_null(intval("0x45"));
//OK
isset(intval("0x45"));
//PHP Fatal error:  Can't use function return value in write context
is_null(NULL);
//OK
isset(NULL);
//PHP Parse error:  syntax error
?>

说了这么多isset的缺点了, 说点它的优点吧:

因为isset是语句, 所以它快!

在一千万次的简单检测语句循环中, 对比结果如下:

<?php
$a="laruence":
isset($a);   //用时: 1.15s
is_null($a); //用时: 3.89s
?>

因为isset叫做isset, 所以它在检测未定义变量的时候, 不会产生NOTICE:

<?php
isset($laruence);
//OK
is_null($laruence);
//PHP Notice:  Undefined variable: laruence
?>

那么, 对于什么时候用isset什么时候用is_null, 我有什么建议呢?

诶, 我的建议是, 用函数做函数应该做的事情~, 听起来象废话?

isset => is set? => 变量有没有被赋值(声明)

is_null => is null? => 变量为NULL么?

另外,　如果要用is_null,　我建议使用 “=== NULL” 来代替,　它不仅语义和is_null一致,　结果一致,　速度还和isset差不多:

在一千万次的简单检测语句循环中, 对比结果如下:

<?php
$a="laruence":
isset($a);      //用时: 1.15s
is_null($a);    //用时: 3.88s
$a===NULL;     //用时: 1.22s
?>

Comments

• 2009/12/09, Platinum writes: 让他们直接看手册比较好些 http://www.php.net/manual/en/types.comparisons.php
• 2009/12/09, simaopig writes: 几乎没用过 is_null 都是 === NULL 不过mysql得用 isnull。。
• 2009/12/09, Willko writes: isset 是指变量是否声明了 isnull 是指变量的值是否为null
• 2009/12/16, hqlong writes: 这风格太黑了，没有以前的视觉效果好
• 2009/12/16, 雪候鸟 writes: 唉,我换了个国外的服务器,国内的老因为封黄网被连坐
• 2009/12/28, simaliu writes: 受教了
• 2010/02/01, xiaokai writes: 那empty是呢?
• 2010/05/26, konakona writes: 一般来讲，都是用===null这样子 另外is_null是函数，而isset是语句一看就知道前者要更慢一些。 而且用isset来判断null并不是最准确的。
• 2010/08/31, Audio writes: isset 是指变量是否声明了 is_null 是指变量的值是否为null,如果变量没声明，或报一个warning empty 也是判断变量的值是否为空，但是变量不存则返回false