作者归档:admin

foreach的指针问题

在PHP中,foreach 语法结构提供了遍历数组的简单方式。 foreach 仅能够应用于数组和对象,如果尝试应用于其他数据类型的变量,或者未初始化的变量,将导致错误。 foreach每次循环时,当前单元的值被赋给 $value 并且数组内部的指针向前移一步(因此下一次循环中将会得到下一个单元)。

但是手册中提醒我们:

Note:
当 foreach 开始执行时,数组内部的指针会自动指向第一个单元。这意味着不需要在 foreach 循环之前调用 reset()。
在循环中修改 foreach 依赖其内部数组指针将可能导致意外的行为。

这里我们所要说的是foreach可能导致的意外情况。如代码1示例:

<?php
$arr = array(1,2,3,4,5);
 
foreach($arr as $key => &$row) {
echo key($arr), '=>', current($arr), "\r\n";
}

会输出什么?

如代码2示例呢?

<?php
$arr = array(1,2,3,4,5);
 
foreach($arr as $key => $row) {
echo key($arr), '=>', current($arr), "\r\n";
}

会输出什么?

代码1会依次输出变量,但是第一个元素并没有在输出结果中出现。

代码2只会输出数组的第二个元素。

为什么呢?

将代码2在VLD扩展中查看,

number of ops:  22
compiled vars:  !0 = $arr, !1 = $key, !2 = $row
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   INIT_ARRAY                                       ~0      1
         1      ADD_ARRAY_ELEMENT                                ~0      2
         2      ADD_ARRAY_ELEMENT                                ~0      3
         3      ADD_ARRAY_ELEMENT                                ~0      4
         4      ADD_ARRAY_ELEMENT                                ~0      5
         5      ASSIGN                                                   !0, ~0
   4     6    > FE_RESET                                         $2      !0, ->20
         7  > > FE_FETCH                                         $3      $2, ->20
         8  >   ZEND_OP_DATA                                     ~5      
         9      ASSIGN                                                   !2, $3
        10      ASSIGN                                                   !1, ~5
   5    11      SEND_REF                                                 !0
        12      DO_FCALL                                      1  $7      'key'
        13      ECHO                                                     $7
        14      ECHO                                                     '%3D%3E'
        15      SEND_REF                                                 !0
        16      DO_FCALL                                      1  $8      'current'
        17      ECHO                                                     $8
        18      ECHO                                                     '%0D%0A'
   6    19    > JMP                                                      ->7
        20  >   SWITCH_FREE                                              $2
   8    21    > RETURN                                                   1

从上面VLD扩展输出结果结合PHP的源代码可以知道,在foreach遍历之前, PHP内核首先会有个FE_RESET操作来重置数组的内部指针,也就是pInternalPointer, 然后通过每次FE_FETCH将pInternalPointer指向数组的下一个元素,从而实现顺序遍历。
并且每次FE_FETCH的结果都会被一个全局的中间变量存储,以给下一次的获取元素使用。

从这两个例子可以引申出三个问题:

1、为什么foreach循环体中执行key或current会显示第二个元素(非引用情况)?
以key函数为例,我们执行函数调用时,会执行中间代码SEND_REF,此中间代码会将没有设置引用的变量复制一份并设置为引用。当进入循环体时,PHP内核已经经过了一次fetch操作,相当于执行了一次next操作,当前元素指向第二个元素。因此我们在foreach的循环体中执行key函数时,key中调用的数组变量为PHP执行了一次fetch操作的数组拷贝,此时foreach的内部指针指向第二个元素。

2、为什么在foreach中执行end等操作,其循环过程不变?
在遍历的代码中通过end,next等操作数组的指针,数组的指针不会变化,这是因为在PHP内核进行FETCH操作时,会通过中间变量存储当前操作数组的内部指针,每遍历一个元素,会先获取之前存储的指针位置,获取下一个元素后,再恢复指针位置。

3、为什么$row的引用和非引用情况下输出结果不同?
如果是引用,PHP内核在reset数组时,会直接分裂数组,生成一个数组的拷贝,并将其设置为引用。
如果是非引用,PHP内核在reset数组时,当数组的引用计数大于1,并且不存在引用时,会拷贝数组供foreach使用,其它情况使用原数组,将其引用计数加1。

因为引用的不同,在循环体中给函数传递参数时其结果不同,导致看到的foreach数组内部指针变化的不同。对于非引用且引用计数大于1的情况,其本身就是两个不同的数组,在RESET时就不同了。

关于Cookie

Cookie是什么

在wiki中Cookie的定义为: Cookie(复数形态Cookies),中文名称为小型文本文件或小甜饼(貌似这只是一个中文翻译,平时还是直接读的英文),指某些网站为了辨别用户身份而储存在用户本地终端上的数据。

Cookie是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器,是客户端与服务器保持会话的主要手段,其内容总是保存在客户端中,按在客户端中的存储位置,可分为内存Cookie和硬盘Cookie。内存Cookie由浏览器维护,保存在内存中,浏览器关闭后就消失了,其存在时间是短暂的。硬盘Cookie保存在硬盘里,有一个过期时间,除非用户手工清理或到了过期时间,硬盘Cookie不会被删除,其存在时间是长期的。所以,按存在时间,可分为非持久Cookie和持久Cookie。

Cookie被浏览器默认发送到服务器,通过HTTP协议,请求头中以Cookie字段存储客户端的Cookie值,应答头中以Set-Cookie字段应答,当服务器需要有多个cookie字段写到客户端,则在应答头中将包含多个Set-Cookie字段。 Cookie的使用非常简单,以PHP为例,在脚本中使用setcookie函数设置对应的key,value值,通过全局变量$_COOKIE直接读取客户端发送过来的Cookie值。

Cookie简单,但是存在一些问题:

  1. 安全,明文传输内容,容易被篡改。和HTTP一样,只能说看如何使用了,看你存储的是什么了
  2. 增加网络流量,加重整个网络的负载。默认浏览器在发送请求时会将本地Cookie的内容通过Cookie字段传输到服务器。所以经常我们会独立静态图片或资源的域名,使其Cookie为空。
  3. 大小限制。各浏览器对于单个cookie的大小限制为4096个字节左右,超过大小的内容将被忽略。每个域名下可以存储有30~50个cookie,不同的浏览器,不同的版本这些值不同。为什么会有大小限制,因为cookie会默认发送,当cookie太大时,可能会导致服务器响应出错等。

Cookie的历史

1993年3月,这样一个春光明媚,面朝大海,春暖花开的时节,现在的网景公司前雇员,当时的NB的网景公司员工Lou Montulli灵光一闪,Cookie华丽丽的出生了。 Cookie第一次被正式定义是在RFC2109,嗯,这是1997年2月的一天,也许那时还有些冷。在RFC中,Cookie被称为HTTP State Management Mechanism(HTTP 状态管理机制)。  RFC2109在2000年10月被RFC2965过时,而在2011年4月,最新的刚刚火热出炉的RFC6265将RFC2965过时,可谓是长江后浪推前浪,前浪死在沙滩上。另外,RFC2964记录了使用Cookie的最佳实践。

换句话说:Cookie经过了Netscape标准、RFC2109、RFC2965和RFC26265四个标准:

  • Netscape标准:Netscape是最原始的Cookies规范,同时也是RFC2109的基础。尽管如此,还是在很多重要的方面与RFC2109不同,可能需要特定服务器才可以兼容。
  • RFC2109: RFC2109是W3C组织第一次推出的官方Cookies标准。理论上,所有使用版本Cookies的服务端都应该使用此标准。HttpClient已经将此标准设定为默认。遗憾的是,许多服务端不正确的实现了标准或者仍然使用Netscape标准。所有有时感到此标准太多于严格。
  • RFC2965:RFC2965定义了版本2并且尝试去弥补在版本1中Cookie的RFC2109标准的缺点。RFC2965是,并规定RFC2965最终取代RFC2109. 发送RFC2965标准Cookies的服务端,将会使用Set-Cookie2 header添加到Set-Cookie Header信心中,RFC2965 Cookies是区分端口的。
  • RFC6265:RFC6265主要是干掉了RFC2965,在9.3和9.4小节。另外,增加了HttpOnly字段,指定HttpOnly的Cookie不能被客户端读写,仅供HTTP传输使用,或者就服务器可以读写,浏览器作为客户端需要确保其不能读写。

Cookie和Seesion

Cookie和Session都用来保存状态信息,做会话处理,都是保存客户端状态的机制,它们都是为了解决HTTP无状态的问题而所做的努力。 Session存储在服务器,一般通过Cookie来存储其生成的唯一ID(seesionID),当Cookie被禁用时,通常用URL回写的机制来替换Cookie。

Cookie和Session有一些不同:

  1. 存储位置的不同:Cookie将状态保存在客户端,Session将状态保存在服务器端;
  2. 与HTTP协议的关系不同:Cookie需要通过网络传输,依赖于HTTP协议,Session并没有在HTTP的协议中定 义;
  3. 可用性不同:相对于Cookie,Session在客户端禁用Cookie后还可以通过URL回写机制实现Session会话机制。
  4. 安全性不同:因为存储的位置不同,Cookie更容易被篡改,存储在服务器的Session相对来说则安全一些,客户不能随意读取这些内容,除非获到其它用户的了sessionID,这也是XSS攻击会关注的地方。

同源策略

说到WEB的安全问题就不得不提同源策略。浏览器的同源策略是 Web 安全的基础,所有的主流浏览器都会有相应的实现。同源策略中“源”是一个包含主机名、协议和端口号的三元组,则同源表示:同协议,同域名和同端口,三者都相同。同源策略的出发点是它认为自任何站点装载的信赖内容是不安全的。在同源策略的限制下,浏览器只允许网页中的脚本(如 JavaScript 或 VBScript)访问与之同源的 HTTP 请求和 Cookie。对于Cookie来说,同源策略就限制了网站间的Cookie读写操作。即使在服务器使用setcookie(PHP)函数对其它域名执行Cookie写操作也是无效的。 setcookie的域名是用来指向当前域名或根域名之类的用的,设置Cookie时,如果不指定domain的值,默认就是本域。

参考资料:

  1. http://wiki.apache.org/HttpComponents/ReferenceMaterials
  2. http://www.cnblogs.com/shepherd2012/archive/2012/08/03/2621797.html
  3. http://zh.wikipedia.org/wiki/Cookie
  4. http://curl.haxx.se/rfc/cookie_spec.html
  5. http://tools.ietf.org/html/rfc6265

Bash之命令历史的存储和记录

在Bash中我们可以使用 history 命令回顾,修改和重用之前使用过的历史命令。去掉信号机制、去掉作业控制、去掉各种参数调用,今天我们只看下Bash中如何记录命令,如何存储历史命令。

在 Bash 的源代码中,history 命令的定义代码为 builtins/history.def , builtins 目录下存放的是内部命令的源代码,每个内部命令是一个def文件,如history.def,cd.def等。 Makefile中DEFSRC声明了所有内部命令的def文件。由 mkbuiltins.c 生成编译时辅助工具 mkbuiltins,mkbuiltins 处理 *.def 文件,生成命令的 *.c 源程序以及 builtins.c 、 builtext.h。 builtins.c 和 builtext.h 相当于各个内部命令的索引。

history.def 的作用是解析命令并将不同的参数分发命令到不同的功能实现,如读取命令、覆盖命令等。一些功能实现代码文件在 bashhist.c/bashhist.h,但是关于历史记录的基础操作并不在这两个文件中,它们在 lib/readline 中。这是因为 Bash 采用的GNU Readline函数库中。 Readline提供了统一的行编辑和历史记录功能的命令行交互方式。

history命令在显示时会显示所有的历史记录,这里的所有历史记录包括最开始从文件中读取的历史记录,还包括当前会话产生的记录。假设你的历史记录中已经有了500条命令,如果你用其它文档编辑器将历史日志文件写到1000条,打开终端,你会发现显示的还只有500记录。这是因为在打开终端初始化时,不仅仅有历史记录列表的读操作,还会有关于文件记录数限制的初始化操作,确保文件中的记录条数不会大于设定的最大值。这个初始化操作在 load_history 函数中实现,函数最开始就做了两次历史记录文件的截取操作,一次是默认500,一次是设置的最大值: HISTFILESIZE 。

在历史记录中有一个会话的概念,不同会话中的命令在没有保存到文件前是不会互相冲突的。比如,打开终端A如果你删除 .bash_history 的前10行命令,保存,在命令行中输入history,你会发现输出的命令历史记录并不是从1开始,而是从11开始的。如果此时,你再开一个终端B,输入若干条命令后,再输入history,你会发现历史记录中没有在终端A输入的命令。这是由于在一个终端会话中,历史记录从固化存储位置的读取操作只有一次,写入操作也只有一次,即在打开终端时读取,在关闭终端时写入。

除了文件存储,历史记录也可以记录在MMAP,对应的宏定义为 HISTORY_USE_MMAP。

如果以文件存储方式,命令记录以一行一条命令的方式存储在.bash_history(默认,如果有设置 HISTFILE 则优先使用 HISTFILE 中的值),虽然我们使用 history 命令时看到每条命令前都会有一个标号,我们可以使用 !标号 的方式重新执行命令,这个标号并不是唯一不变的,标号是在初始化时在读取文件时在程序操作中标记的,后续有命令加入时,标号会自增,这个自增并不会受历史记录的最大值限制。

当一次会话退出时保存历史记录文件,将历史数据固化存储,并将会话统计清零。当存储到文件时,Bash 会将此前会话中的命令直接存储到文件末尾,如果文件的记录数大于定义的最大记录数,则清空旧的历史命令,并且当下次再存储时会重写此前文件。代码示例如下:

      if (history_lines_this_session <= where_history () || force_append_history)
        append_history (history_lines_this_session, hf);
      else
        write_history (hf);
 
      sv_histsize ("HISTFILESIZE");

存储操作最终还是归集于存储介质的读写操作,如对文件的读写,增加的只是对业务逻辑规则的各种限制。命令可以在执行命令时记录,也可以在命令刚输入,但已经识别的情况下记录,Bash 属于后者。 Bash 在 yacc 做语法分析时将用户输入的命令通过 maybe_add_history 函数写入到当前会话的命令历史记录表中。在做语法分析时就已经记录了用户输入的命令,此时记录就不用管命令最终的结果是怎样,也不用管如果执行过程出了异常会怎样处理。它只是如实的在执行前记录用户输入的什么命令,由此,我们可以定义 Bash 的命令历史记录的定义为用户输入的命令历史记录。

参考资料: http://files.linjian.org/articles/techreport/bash_study.tar.gz