Cgeek’s blog

今天一台linux服务器上遭遇Zend加密的php文件无法加密，可是我记得已经安装过Zend Optimizer的啊，phpinfo();查看了一下。发现没有Zend Optimizer;
打开php.ini，看到最后明明有zend扩展配置啊：
[Zend]
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
zend_optimizer.version=3.3.0a
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
找了好久，终于在运行完php -v的命令后找到了原因，提示：
[root@locoy 5_2_x_comp]# /usr/local/webserver/php/bin/php -v
Failed loading /usr/local/Zend/lib/Optimizer-3.3.0/php-5.2.x/ZendOptimizer.so: /usr/local/Zend/lib/Optimizer-3.3.0/php-5.2.x/ZendOptimizer.so: cannot restore segment prot after reloc: Permission denied
PHP 5.2.10 (cli) (built: Dec 6 2009 01:35:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
with [...]

今天在配置一台nginx的web服务器时，参考张宴(blog.s135.com)大师的《Nginx 0.8.x + PHP 5.2.10（FastCGI）搭建胜过Apache十倍的Web服务器（第5版）》
安装php（fastcgi模式）的时候，常常有这样一句命令：/usr/local/webserver/php/bin/phpize
一、phpize是干嘛的？
phpize是什么东西呢？php官方的说明：
http://php.net/manual/en/install.pecl.phpize.php
phpize是用来扩展php扩展模块的，通过phpize可以建立php的外挂模块
比如你想在原来编译好的php中加入memcached或者ImageMagick等扩展模块，可以使用phpize，通过以下几步工作。
二、如何使用phpize？
当php编译完成后，php的bin目录下会有phpize这个脚本文件。在编译你要添加的扩展模块之前，执行以下phpize就可以了；
比如现在想在php中加入memcache扩展模块：我们要做的只是如下几步
————————————————————————
tar zxvf memcache-2.2.5.tgz
cd memcache-2.2.5/
/usr/local/webserver/php/bin/phpize
./configure –with-php-config=/usr/local/webserver/php/bin/php-config
make
make install
————————————————————————
注意./configure 后面可以指定的是php-config文件的路径
这样编译就完成了，还需要做的是在php.ini文件中加入extension值
extension = “memcache.so”

也许FastCGI早就不陌生，但是FastCGI到底是什么？我倒真没太理解，只知道用FastCGI就对了，快！
FastCGI的官网：http://www.fastcgi.com/
FastCGI is simple because it is actually CGI with only a few extensions. 很谦虚的说他只是CGI的一点点扩展而已;
一、FastCGI是什么？
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要 行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存 中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over特性等等。
FastCGI的工作原理是：
1、Web Server 启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module）;
2、FastCGI进程管理器自身初始化，启动多个CGI解释器进程 (在任务管理器中可见多个php-cgi.exe)并等待来自Web Server的连接。
3、当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi.exe。
4、FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器（运行在 WebServer中）的下一个连接。 在正常的CGI模式中，php-cgi.exe在此便退出了。
在上述情况中，你可以想象 CGI通常有多慢。每一个Web请求PHP都必须重新解析php.ini、重新载入全部dll扩展并重初始化全部数据结构。使用FastCGI，所有这些 都只在进程启动时发生一次。一个额外的好处是，持续数据库连接(Persistent database connection)可以工作。
二、为什么要使用FastCGI，而不是多线程CGI解释器？
这可能出于多方面的考虑，例如：
1、你无论如何也不能在windows平台上稳定的使用多线程CGI解释器，无论是IIS ISAPI方式还是APACHE Module方式，它们总是运行一段时间就崩溃了。奇怪么？但是确实存在这样的情况！
当然，也有很多时候你能够稳定的使用多线程CGI解释器，但是，你有可能发现网页有时候会出现错误，无论如何也找不到原因，而换用FastCGI方式时 这种错误的概率会大大的降低。我也不清楚这是为什么，我想独立地址空间的CGI解释器可能终究比共享地址空间的形式来得稳定一点点。
2、性 能！性能？可能么，难道FastCGI比多线程CGI解释器更快？但有时候确实是这样，只有测试一下你的网站，才能最后下结论。原因嘛，我觉得很难讲，但 有资料说在Zend WinEnabler的时代，Zend原来也是建议在Windows平台下使用FastCGI而不是IIS ISAPI或Apache Module，不过现在Zend已经不做这个产品了。
三、不使用FastCGI的理由
1、多进程比多线程消耗更多的服务器内存，php-cgi.exe解释器每进程消耗7至25兆内存，将这个数字乘以50或100试试。
2、性能。确实有时候多线程CGI解释器更快，呵呵，而且有时候，它也很稳定。
3、CGI？听起来就很土，呵呵
http://blogme.cn/node/6529
其他资源：
扶凯：http://www.php-oa.com/2008/03/22/php-fastcgi.html

上一篇把题目写成《iconv函数的小bug》怪吓人的~~~华晨同学的回复使我感到自己的不求甚解.正所谓知错能改，善莫大焉。于是我重新查了一遍：php官方的说明：http://cn.php.net/manual/en/function.iconv.php
函数原型：string iconv ( string $in_charset , string $out_charset , string $str )
特别是第二个参数说明：
The output charset.
If you append the string //TRANSLIT to out_charset transliteration is activated. This means that when a character can’t be represented in the target charset, it can be approximated through one or several similarly looking characters. If you append the string //IGNORE, [...]

昨天在做ajax调用的时候，发现调用出来的文章内容有的缺少一些内容，搞了半天，原来是iconv函数在作怪~~~
网上说这是php的iconv函数的一个小bug：
原来 iconv( “UTF-8″, “gb2312″ , $string) 应该在第二个参数后面加个参数：
iconv( “UTF-8″, “gb2312//IGNORE” , $string)
ignore的意思是忽略转换时的错误，发现iconv在转换字符”—”到gb2312时会出错，如果没有ignore参数，所有该字符后面的字符串都无法被保存。
在此记录一下~~~

最近在开发视频收藏功能时候，需要根据视频网站如优酷、酷6、土豆网的一个视频链接，能自动获取该视频的真实链接和相对应视频的截图。类似与校内的分享视频的功能~~~~
下面以优酷为例：
假设我们给任意一个优酷视频网址：http://v.youku.com/v_show/id_XMTA0NTM2MzI4.html
要注意一点：优酷网上的视频地址较早些的是：http://v.youku.com/v_show/id_XNTM3MDg2ODA=.html
注意上面的一点点区别，最后有个“=”。
通过分析优酷视频网站的页面内容特点，利用php结合正则表达式，过滤获取我们想要的信息。具体参见下面功能函数。

//优酷视频地址，如http://v.youku.com/v_show/id_XMTA0NTM2MzI4.html
$link = ’http://v.youku.com/v_show/id_XMTA0NTM2MzI4.html‘；
$host = ‘youku.com’;
function getVideoInfo($link, $host) {
$return = array();
if(’youku.com’ == $host) {
//分析视频网址，获取视频编码号
preg_match_all("/id\_(\w+)[\=|.html]/", $link, $matches);
if(!empty($matches[1][0])) {
$return[’flashvar’] = $matches[1][0];
}
//获取视频页面内容，存与$text中
$text=file_get_contents($link);
//获取视频标题
preg_match("/<title>(.*?) – (.*)<\/title>/", $text, $title);
[...]

好几天前写的，发现放在草稿箱里好几天了，没发出来。
前短时间看到ecshop出现了一个注射漏洞~~《ECShop注射漏洞》
漏洞产生的原因是goods_script.php里未对$sql变量进行初始化。我到ECSHOP的官网下了个最新版的程序包。果然发现了这个漏洞非常明显，
我把goods_script.php里的代码全贴上来吧：

<?php
 
/**
* ECSHOP 生成商品列表
* ============================================================================
* 版权所有 (C) 2005-2007 康盛创想（北京）科技有限公司，并保留所有权利。
* 网站地址: http://www.ecshop.com
* —————————————————————————-
* 这是一个免费开源的软件；这意味着您可以在不用于商业目的的前提下对程序代码
* 进行修改、使用和再发布。
* ============================================================================
* $Author: testyang $
* $Date: 2008-01-28 18:33:06 +0800 (星期一, 28 一月 2008) $
* $Id: goods_script.php 14079 2008-01-28 10:33:06Z testyang $
*/
 
define(’IN_ECS’, true);
define(’INIT_NO_USERS’, true);
 
require(dirname(__FILE__) . ‘/includes/init.php’);
 
if ((DEBUG_MODE & 2) != 2)
{
[...]

昨天在网上看到一份php程序员面试题里问:谈谈php的优缺点？
我发现用php这么久了，却不能非常好的回答这个问题~~只感觉php简单、快速，和java比性能上差一些~~~感觉这些理解挺肤浅的。今天在javaeye社区上看到《PHP框架的繁荣是正确的发展方向吗？》的讨论，很有意思。而且rabin大哥的观点非常深刻。
原来从根本上说PHP和Python/Ruby的运行机制有一个本质区别：PHP是每次HTTP请求过来以后，初始化全部资源（例如创建数据库链接、加载系统类库，创建缓存等等），处理完毕，释放全部资源，这不像Python/Ruby之类带有GC的脚本语言，Python/Ruby是初次启动的时候初始化资源，随后的请求就不必再次初始化资源了。
这种机制的差异带来的区别就是：
1、PHP极难出现严重的内存泄露问题，随便你代码写的多烂，反正每个请求一执行完毕，所有资源统统释放光。而Python/Ruby则需要依赖GC来回收内存，因此稍有不慎，还是会出现GC无法释放的内存泄露问题。
2、PHP每次请求都要初始化资源，这个开销非常大。所以尽管PHP解析器本身的运行速度是极快的，但是一旦使用复杂的PHP框架，那么由于需要每次请求的时候初始化整个框架，性能的下降非常厉害，你用一个很复杂的PHP框架的结果就是整体性能被Ruby远远甩开。这也是为什么PHP社区这么多年来，并不怎么倾向于使用框架的原因之一。
3、由于PHP这种每请求初始化资源的机制，也造成了PHP添加跨请求的高级特性相当困难，这是PHP本身一个很大的限制，但是反过来说，正是这种限制使得PHP始终保持在一个比较简单的web语言上面，而正是这一点才是PHP得以成为互联网第一Web编程语言的原因，因此也未必就不好。
这样就从运行机制上说明了php在性能方面的优点和缺点~~~
当然，php的最大的优点当然还是他的“简单”，一个有点编程背景的普通人，只需要学习PHP半天时间，就可以上手开始开发web应用了，这就是PHP最大的优势。
koalant同学的概括非常有意思，我觉得也挺有道理的：
PHP 就是： Quick and Dirty
Java 就是： Beauty and Slowly
Ruby 就是： Quick and Beauty
python 就是： Quick and Simple
老左在
《PHP沉思录之六：Drupal的性能问题》提到的观点也不能忽略：
但是，当用户并不是仅仅进行浏览，而是需要频繁地和网站进行互动时，PHP的性能不但无法比拟C和Java，甚至无法与同为脚本语言的Python和Ruby相比。也就是说，PHP更适合于新闻门户这样的内容发布站点，而不是web 2.0应用的首选。