Once的PHP个人博客
$_SERVER是一个包含诸如头信息(header),路径(path)和脚本位置(script locations)的数组.这是PHP手册的原话.
有一些头信息是系统本身就存在的,且不能更改,比如说HOST,USER_AGENT等等,注意我们常用到的是$_SERVER['HTTP_HOST'],$_SERVER['HTTP_USER_AGENT'],这里面都有HTTP前缀,实现上在 header信息里面是没有HTTP前缀的,信息名称只是HOST之类的,$_SERVER自动的为他们加上HTTP前缀,1是为了防止与本身的其它信息相冲突,2是为了表示他们是header头部的信息.所以$_SERVER中的变量凡是带有HTTP前缀的均是header信息,没有的则不是, 如:$_SERVER['QUERY_STRING'], $_SERVER['PHP_SELF']等.
最近(貌似是28号)从国外(地址：http://nikic.github.com/2011/12/28/Supercolliding-a-PHP-array.html)爆出了一个关于Array的新PHP冲突，可以利用调用hash表的冲突对服务器进行拒绝服务攻击。 原理：目前很多语言, 使用hash来存储key – value数据，包括常用的来自用户的POST数据，攻击者可以通过构造请求头，并伴随POST大量的特殊的”key”值(根据每个语言的Hash算法不同而定制)，使得语言底层保存POST数据的Hash表因为”冲突”(碰撞)而退化成链表。
首先说个题外话: Vim发布7.3了.. 在翻看Vim插件的时候, 发现了一个比较有意思的应用(非插件): 把PHP的手册融如Vim中, 在Vim中, 按”K”, 就可以跳转到光标下函数的手册说明… 1. 首先, 下载特殊定制的PHP手册(包含PHP5.3的所有函数) : vim-php-manual.tar.gz 2. 把下载的文件解压缩, 放置到一个目录, 比如/tmp/phpmuanul(windows下比如:”d:/phpmanual”). 3. 配置vimrc(linux下是.vimrc,windows下是_vimrc), 把phpmanual目录添加到runtimepath(稍后解释为什么). 4. 配置vimrc, 使得keywordprg=”help”. 在我的机器上, keywordprg默认是!man, 大多数时候, 我还是希望可以直接man到linux下的标准函数库, 所以我使用(在vimrc文件中): autocmd BufNewFile,Bufread *.ros,*.inc,*.php set keywordprg=”help” 或者也可以写在vim目录下的ftplugin下的php.vim(如果没有新建), 这样在ft为php的时候,这个配置脚本就会被加载. 至于说, 为什么要把phpmanual目录添加到runtimepath, 是因为: When no argument is given to :help the file given with the ‘helpfile’ optionwill be opened. Otherwise the specified tag is searched for in all “doc/tags”files in the directories specified in the ‘runtimepath’ option. 意思就是说, 在vim中, 调用help的时候, help会去所有的runtimpath下的doc目录中寻找tags文件, 来寻找要查找的帮助关键字. 在我们下载的vim-php-manual.tar.gz文件中, 就包含了doc/tags这样的文件目录结构, 所以只要把phpmanual目录加入runtimepath, 并且设置keywordprg为vim的help, 就可以实现在光标处按”K”跳转到函数手册了.
在以前的PHP中, 我们并不能直接去操作一个对象实例化的结果: show(); //PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR 我们只能, 把实例化结果先保存起来, 然后再调用: $a = new Foo();$a->show(); 关于这个改进, 已经有很多人提出过request, 但是因为实现的问题, 一直没有加入PHP. 这点上, 我解释下, PHP的语法分析系统, 是一个历史悠久的系统, 在这个蛮长的的历史中, 不停的修修补补, 或多或少的会造成一些特定的特性. 而如果要重写, 继耗时, 又耗力, 并且很难做到和现在的完全兼容, 所以我想, 要完全重写, 那也只能是PHP6了(替开发组宣布一下, PHP6目前已经停止开发, 也暂时不会有这种提法) 而, 如果采用修补的方式, 就会引入一个无法解决的移近/归约冲突, 我之前也尝试过实现这个特性, 但是因为遇到这个问题, 所以没有提交.. 不过, 随着对这个特性要求的增多, 慢慢的, 大家觉得, 即使多一个移近/归约冲突,,,, 也没啥吧. 嘿嘿, 所以呢: 现在, 这个特性终于在Felipe(Instance and method call/property access)的工作下, 得到了支持, 现在我们就可以书写如下的语法了: bar()(new $foo())->bar(new $bar->y)->x(new foo)[0] 你也许注意到了, 所有的实例化式都需要用括号括起来, 是的, 如果不这样, 那么首先, 会有如下的冲突语法: new $bar->y->x; 此时, 就会有矛盾, 到底是(new $bar)->y呢, 还是(new $bar->y)->x呢. 另外一个原因, 也是因为PHP目前的语法系统, 如果采用不加括号的做法, 那么就会更多的引入一个移近/归约冲突. 不过我相信这个括号也没什么, 起码看起来也更清晰一些. 说到这里, 插个题外话, 我很好奇, C++的语法分析, 那得有多少已知的无法解决的”移近/归约”冲突啊, 有知道的朋友么? 呵呵. 目前, 5.4RC1已经发布, 大家有兴趣的, 可以提早试用, 也帮PHP做做测试:) PHP 5.4RC1, enjoy! 不过, 还是要提醒下: PHP 5.4还处于开发阶段, 在最终release之前, 任何新特性都可能被调整或者更改. 如果大家有任何建议, 也欢迎反馈, 帮助我们使得PHP变得更好. 谢谢
分页是目前在显示大量结果时所采用的最好的方式。有了下面这些代码的帮助，开发人员可以在多个页面中显示大量的数据。在互联网上，分?页是一般用于搜索结果或是浏览全部信息(比如：一个论坛主题)。几乎在每一个Web应用程序都需要划分返回的数据，并按页显示。下面的这个列表给出的代码可以让你的开发很有帮助。学习这些代码，对于初学者也很有帮助。1) 使用Ajax分页下面这个示例使用了jQuery + PHP。 Demo link
2) MySql 分页数据库的分页处理。
日志在计算机系统中是一个非常广泛的概念，任何程序都有可能输出日志：操作系统内核、各种应用服务器等等。日志的内容、规模和用途也各不相同，很难一概而论。 本文讨论的日志处理方法中的日志，仅指Web日志。其实并没有精确的定义，可能包括但不限于各种前端Web服务器——apache、lighttpd、tomcat等产生的用户访问日志，以及各种Web应用程序自己输出的日志。 在Web日志中，每条日志通常代表着用户的一次访问行为，例如下面就是一条典型的apache日志： 211.87.152.44 – – [18/Mar/2005:12:21:42 +0800] “GET / HTTP/1.1″ 200 899 “http://www.baidu.com/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)” 从上面这条日志中，我们可以得到很多有用的信息，例如访问者的IP、访问的时间、访问的目标网页、来源的地址以及访问者所使用的客户端的UserAgent信息等。如果需要更多的信息，则要用其它手段去获取：例如想得到用户屏幕的分辨率，一般需要使用js代码单独发送请求;而如果想得到诸如用户访问的具体新闻标题等信息，则可能需要Web应用程序在自己的代码里输出。 为什么要分析日志 毫无疑问，Web日志中包含了大量人们——主要是产品分析人员会感兴趣的信息，最简单的，我们可以从中获取网站每类页面的PV值(PageView，页面访问量)、独立IP数(即去重之后的IP数量)等;稍微复杂一些的，可以计算得出用户所检索的关键词排行榜、用户停留时间最高的页面等;更复杂的，构建广告点击模型、分析用户行为特征等等。 既然这些数据是如此的有用，那么当然已经有无数现成的工具可以帮助我们来分析它们，例如awstats、Webalizer，都是专门用于统计分析Web服务器日志的免费程序。 另外还有一类产品，它们不分析直接日志，而是通过让用户在页面中嵌入js代码的方式来直接进行数据统计，或者说我们可以认为它是直接让日志输出到了它们的服务器。典型的代表产品——大名鼎鼎的Google Analytics，另外还有国内的cnzz、百度统计等。 很多人可能会说，既然如此，我们为什么还需要自己来分析日志，有必要吗?当然有。我们的用户(产品分析人员)需求是无穷尽的，上面说的这几类工具虽然很好很强大，但显然没办法满足全部的需求。 无论是本地分析的工具，还是在线的分析服务，它们虽然提很丰富的的统计分析功能，可以做一定程度的配置，但是依然很有限的。要进行稍复杂点的分析，或者要做基于日志的数据挖掘，依然需要自己来完成。 另外绝大多数日志分析工具都是只能用于单机的，数据量稍大就没辙了。同时那些提供在线分析的服务对于单个站点通常也都有最大流量的限制——这是很容易理解的，他们也需要考虑服务器的负载。 所以，很多时候还是得靠自己。 怎么进行日志分析 这并不是一个简单的问题。即使我们把“日志”限定为Web日志，依然包含了成千上万种可能的格式和数据，而是“分析”更是难以定义，也许是简单的统计值的计算，也许是复杂的数据挖掘算法。 下面并不打算讨论这些复杂的问题，而只是笼统的讨论如何构建进行日志分析工作的基础。有了这些基础会让基于日志的简单统计分析变得很简单，并让复杂的分析挖掘等变得可行。 少量数据的情况 先考虑最简单的情况，在数据规模比较小的时候，也许是几十MB、几百MB或者几十GB，总之就是在单机处理尚能忍受的时候。一切都很好办，现成的各种Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器，如果仅仅是想知道某个页面的PV，一个wc+grep就能搞定。如果有稍复杂的逻辑，那就使用各种脚本语言，尤其是perl，配合伟大的正则表达式，基本就可以解决所有的问题。 例如，我们想从上面提到的apache日志中得到访问量最高前100个IP，实现很简单： cat logfile | awk ‘{a[$1]++} END {for(b in a) print b”\t”a[b]}’|sort -k2 -r|head -n 100 不过当我们需要频繁去分析日志的时候，上面的做法在一段时间之后可能就会让我们头疼如何进行各种日志文件、用于分析的脚本文件、crontab文件等等的维护，并且可能会存在大量重复的代码来做数据格式的解析和清洗，这个时候也许就需要更合适的东西，比如——数据库。 当然，要使用数据库来进行日志分析还是需要一些代价的，最主要的就是如何将各种异构的日志文件导入的数据库中——这个过程通常称为ETL(Extraction-Transformation-Loading)。幸好依然有各种现成的开源、免费的工具来帮助我们做这件事情，并且在日志种类不太多的时候，自己写几个简单的脚本来完成这项工作也并不困难。例如可以将上面的日志去掉不必要的字段，然后导入如下的数据库中：
PHP代码: $img = ImageCreate(180,50); $ip = $_SERVER['REMOTE_ADDR']; ImageColorTransparent($img,$bgcolor); $bgColor = ImageColorAllocate($img, 0x2c,0x6D,0xAF); // 背景颜色 $shadow = ImageColorAllocate($img, 250,0,0); // 阴影颜色 $textColor = ImageColorAllocate($img, oxff,oxff,oxff); // 字体颜色 ImageTTFText($img,10,0,78,30,$shadow,”c:/windows/fonts/Tahoma.ttf”,$ip); //显示背景 ImageTTFText($img,10,0,25,28,$textColor,”c:/windows/fonts/Tahoma.ttf”,”your ip is”.$ip); // 显示IP ImagePng($img); imagecreatefrompng($img); ImageDestroy($img); ?>
