深入理解php中的ini配置(2)，深入理解ini继续接着上一篇写。
1，运行时改变配置在前一篇中曾经谈到，ini_set函数可以在php执行的过程中，动态修改php的部分配置。注意，仅仅是部分，并非所有的配置都可以动态修改。关于ini配置的可修改性，参见：http://php.net/manual/zh/configuration.changes.modes.php
我们直接进入ini_set的实现，函数虽然有点长，但是逻辑很清晰：
php_function(ini_set){ char *varname, *new_value; int varname_len, new_value_len; char *old_value; if (zend_parse_parameters(zend_num_args() tsrmls_cc, ss, &varname, &varname_len, &new_value, &new_value_len) == failure) { return; } // 去eg(ini_directives)中获取配置的值 old_value = zend_ini_string(varname, varname_len + 1, 0); /* copy to return here, because alter might free it! */ if (old_value) { retval_string(old_value, 1); } else { retval_false; } // 如果开启了安全模式，那么如下这些ini配置可能涉及文件操作，需要要辅助检查uid#define _check_path(var, var_len, ini) php_ini_check_path(var, var_len, ini, sizeof(ini)) /* safe_mode & basedir check */ if (pg(safe_mode) || pg(open_basedir)) { if (_check_path(varname, varname_len, error_log) || _check_path(varname, varname_len, java.class.path) || _check_path(varname, varname_len, java.home) || _check_path(varname, varname_len, mail.log) || _check_path(varname, varname_len, java.library.path) || _check_path(varname, varname_len, vpopmail.directory)) { if (pg(safe_mode) && (!php_checkuid(new_value, null, checkuid_check_file_and_dir))) { zval_dtor(return_value); return_false; } if (php_check_open_basedir(new_value tsrmls_cc)) { zval_dtor(return_value); return_false; } } } // 在安全模式下，如下这些ini受到保护，不会被动态修改 if (pg(safe_mode)) { if (!strncmp(max_execution_time, varname, sizeof(max_execution_time)) || !strncmp(memory_limit, varname, sizeof(memory_limit)) || !strncmp(child_terminate, varname, sizeof(child_terminate)) ) { zval_dtor(return_value); return_false; } } // 调用zend_alter_ini_entry_ex去动态修改ini配置 if (zend_alter_ini_entry_ex(varname, varname_len + 1, new_value, new_value_len, php_ini_user, php_ini_stage_runtime, 0 tsrmls_cc) == failure) { zval_dtor(return_value); return_false; }}
可以看到，除了一些必要的验证工作，主要就是调用zend_alter_ini_entry_ex。
我们继续跟进到zend_alter_ini_entry_ex函数中：
zend_api int zend_alter_ini_entry_ex(char *name, uint name_length, char *new_value, uint new_value_length, int modify_type, int stage, int force_change tsrmls_dc) /* {{{ */{ zend_ini_entry *ini_entry; char *duplicate; zend_bool modifiable; zend_bool modified; // 找出eg(ini_directives)中对应的ini_entry if (zend_hash_find(eg(ini_directives), name, name_length, (void **) &ini_entry) == failure) { return failure; } // 是否被修改以及可修改性 modifiable = ini_entry->modifiable; modified = ini_entry->modified; if (stage == zend_ini_stage_activate && modify_type == zend_ini_system) { ini_entry->modifiable = zend_ini_system; } // 是否强制修改 if (!force_change) { if (!(ini_entry->modifiable & modify_type)) { return failure; } } // eg(modified_ini_directives)用于存放被修改过的ini_entry
// 主要用做恢复 if (!eg(modified_ini_directives)) { alloc_hashtable(eg(modified_ini_directives)); zend_hash_init(eg(modified_ini_directives), 8, null, null, 0); } // 将ini_entry中的值，值的长度，可修改范围，保留到orig_xxx中去
// 以便在请求结束的时候，可以对ini_entry做恢复
if (!modified) { ini_entry->orig_value = ini_entry->value; ini_entry->orig_value_length = ini_entry->value_length; ini_entry->orig_modifiable = modifiable; ini_entry->modified = 1; zend_hash_add(eg(modified_ini_directives), name, name_length, &ini_entry, sizeof(zend_ini_entry*), null); } duplicate = estrndup(new_value, new_value_length); // 调用modify来更新xxx_g中对应的ini配置 if (!ini_entry->on_modify || ini_entry->on_modify(ini_entry, duplicate, new_value_length, ini_entry->mh_arg1, ini_entry->mh_arg2, ini_entry->mh_arg3, stage tsrmls_cc) == success) { // 同上面，如果多次修改，则需要释放前一次修改的值 if (modified && ini_entry->orig_value != ini_entry->value) { efree(ini_entry->value); } ini_entry->value = duplicate; ini_entry->value_length = new_value_length; } else { efree(duplicate); return failure; } return success;}
有3处逻辑需要我们仔细体会：
1）ini_entry中的modified字段用来表示该配置是否被动态修改过。一旦该ini配置发生修改，modified就会被置为1。上述代码中有一段很关键：
// 如果多次调用ini_set，则orig_value等始终保持最原始的值if (!modified) { ini_entry->orig_value = ini_entry->value; ini_entry->orig_value_length = ini_entry->value_length; ini_entry->orig_modifiable = modifiable; ini_entry->modified = 1; zend_hash_add(eg(modified_ini_directives), name, name_length, &ini_entry, sizeof(zend_ini_entry*), null);}
这段代码表示，不管我们先后在php代码中调用几次ini_set，只有第一次ini_set时才会进入这段逻辑，设置好orig_value。从第二次调用ini_set开始，便不会再次执行这段分支，因为此时的modified已经被置为1了。因此，ini_entry->orig_value始终保存的是第一次修改之前的配置值（即最原始的配置）。
2）为了能使ini_set修改的配置立即生效，需要on_modify回调函数。
如前一篇文中所述，调用on_modify是为了能够更新模块的全局变量。再次回忆下，首先，模块全局变量中的配置已经不是字符串类型了，该用bool用bool、该用int用int。其次，每一个ini_entry中都存储了该模块全局变量的地址以及对应的偏移量，使得on_modify可以很迅速的进行内存修改。此外不要忘记，on_modify调用完了之后，仍需进一步更新ini_entry->value，这样eg(ini_directives)中的配置值就是最新的了。
3）这里出现了一张新的hash表，eg(modified_ini_directives)。
eg(modified_ini_directives)只用于存放被动态修改过的ini配置，如果一个ini配置被动态修改过，那么它既存在于eg(ini_directives)中，又存在于eg(modified_ini_directives)中。既然每一个ini_entry都有modified字段做标记，那岂不是可以遍历eg(ini_directives)来获得所有被修改过的配置呢？
答案是肯定的。个人觉得，这里的eg(modified_ini_directives)主要还是为了提升性能，酱直接遍历eg(modified_ini_directives)就足够了。此外，把eg(modified_ini_directives)的初始化推迟到zend_alter_ini_entry_ex中，也可以看出php在细节上的性能优化点。
2，恢复配置ini_set的作用时间和php.ini文件的作用时间是不一样的，一旦请求执行结束，则ini_set会失效。此外，当我们代码中调用了ini_restore函数，则之前通过ini_set设置的配置也会失效。
每一个php请求执行完毕之后，会触发php_request_shutdown，它和php_request_startup是两个相对应过程。如果php是挂接在apache/nginx下，则每处理完一个http请求，就会调用php_request_shutdown；如果php以cli模式来运行，则脚本执行完毕之后，也会调用php_request_shutdown。
在php_request_shutdown中，我们可以看到针对ini的恢复处理：
/* 7. shutdown scanner/executor/compiler and restore ini entries */zend_deactivate(tsrmls_c);
进入zend_deactivate，可以进一步看到调用了zend_ini_deactivate函数，由zend_ini_deactivate来负责将php的配置进行恢复。
zend_try { zend_ini_deactivate(tsrmls_c);} zend_end_try();
具体来看看zend_ini_deactivate的实现：
zend_api int zend_ini_deactivate(tsrmls_d) /* {{{ */{ if (eg(modified_ini_directives)) { // 遍历eg(modified_ini_directives)中这张表 // 对每一个ini_entry调用zend_restore_ini_entry_wrapper zend_hash_apply(eg(modified_ini_directives), (apply_func_t) zend_restore_ini_entry_wrapper tsrmls_cc); // 回收操作 zend_hash_destroy(eg(modified_ini_directives)); free_hashtable(eg(modified_ini_directives)); eg(modified_ini_directives) = null; } return success;}
从zend_hash_apply来看，真正恢复ini的任务最终落地到了zend_restore_ini_entry_wrapper回调函数。
static int zend_restore_ini_entry_wrapper(zend_ini_entry **ini_entry tsrmls_dc){ // zend_restore_ini_entry_wrapper就是zend_restore_ini_entry_cb的封装 zend_restore_ini_entry_cb(*ini_entry, zend_ini_stage_deactivate tsrmls_cc); return 1;}static int zend_restore_ini_entry_cb(zend_ini_entry *ini_entry, int stage tsrmls_dc){ int result = failure; // 只看修改过的ini项 if (ini_entry->modified) { if (ini_entry->on_modify) { // 使用orig_value，对xxx_g内的相关字段进行重新设置 zend_try { result = ini_entry->on_modify(ini_entry, ini_entry->orig_value, ini_entry->orig_value_length, ini_entry->mh_arg1, ini_entry->mh_arg2, ini_entry->mh_arg3, stage tsrmls_cc); } zend_end_try(); } if (stage == zend_ini_stage_runtime && result == failure) { /* runtime failure is ok */ return 1; } if (ini_entry->value != ini_entry->orig_value) { efree(ini_entry->value); } // ini_entry本身恢复到最原始的值 ini_entry->value = ini_entry->orig_value; ini_entry->value_length = ini_entry->orig_value_length; ini_entry->modifiable = ini_entry->orig_modifiable; ini_entry->modified = 0; ini_entry->orig_value = null; ini_entry->orig_value_length = 0; ini_entry->orig_modifiable = 0; } return 0;}
逻辑都蛮清晰的，相信读者可以看明白。总结一下关于ini配置的恢复流程：
php_request_shutdown--->zend_deactivate--->zend_ini_deactivate--->zend_restore_ini_entry_wrapper--->zend_restore_ini_entry_cb
3，配置的销毁在sapi生命周期结束的时候，比如apache关闭，cli程序执行完毕等等。一旦进入到这个阶段，之前所说的configuration_hash，eg(ini_directives)等都需要被销毁，其用到的内存空间需要被释放。
1，php会依次结束所有的模块，在每个模块的php_mshutdown_function中调用unregister_ini_entries。unregister_ini_entries和register_ini_entries对应，但是unregister_ini_entries并不负责模块全局空间的释放，xxx_globals这块内存放在静态数据区上，无需人为回收。
unregister_ini_entries主要做的事情，是将某个模块的ini_entry配置从eg(ini_directives)表中删除。删除之后，ini_entry本身的空间会被回收，但是ini_entry->value不一定会被回收。
当所有模块的php_mshutdown_function都调用unregister_ini_entries一遍之后，eg(ini_directives)中只剩下了core模块的ini配置。此时，就需要手动调用unregister_ini_entries，来完成对core模块配置的删除工作。
void php_module_shutdown(tsrmls_d){ ... // zend_shutdown会依次关闭除了core之外的所有php模块 // 关闭时会调用各个模块的php_mshutdown_function zend_shutdown(tsrmls_c); ... // 至此，eg(ini_directives)中只剩下了core模块的配置 // 这里手动清理一下 unregister_ini_entries(); // 回收configuration_hash php_shutdown_config();

// 回收eg(ini_directives)
zend_ini_shutdown(tsrmls_c);
...}
当手动调用unregister_ini_entries完成之后，eg(ini_directives)已经不包含任何的元素，理论上讲，此时的eg(ini_directives)是一张空的hash表。
2，configuration_hash的回收发生在eg(ini_directives)之后，上面贴出的代码中有关于php_shutdown_config的函数调用。php_shutdown_config主要负责回收configuration_hash。
int php_shutdown_config(void){ // 回收configuration_hash zend_hash_destroy(&configuration_hash); ... return success;}
注意zend_hash_destroy并不会释放configuration_hash本身的空间，同xxx_g访问的模块全局空间一样，configuration_hash也是一个全局变量，无需手动回收。
3，当php_shutdown_config完成时，只剩下eg(ini_directives)的自身空间还没被释放。因此最后一步调用zend_ini_shutdown。zend_ini_shutdown用于释放eg(ini_directives)。在前文已经提到，此时的eg(ini_directives)理论上是一张空的hash表，因此该hashtable本身所占用的空间需要被释放。
zend_api int zend_ini_shutdown(tsrmls_d){ // eg(ini_directives)是动态分配出的空间，需要回收 zend_hash_destroy(eg(ini_directives)); free(eg(ini_directives)); return success;}
4，总结用一张图大致描述一下和ini配置相关的流程：
php中ini的配置是怎做的
直接编辑php目录下的php.ini文件即可
有一个“register_globals = off”值，这个值是用来打开全局变量的，比如表单送过来的值，如果这个值设为“off”，就只能用“$_post['变量名']、$_get['变量名 ']”等来取得送过来的值，如果设为“on”，就可以直接使用“$变量名”来获取送过来的值，当然，设为“off”就比较安全，不会让人轻易将网页间传送 的数据截取。这个值是否改成“on”就看自己感觉了，是安全重要还是方便重要？
要用mysql，就要把“;extension= php_mysql.dll”前的“;”去掉。所有的模块文件都放在php解压缩目录的“ext”之下，用什么就把前面的“;”去掉就行了。
php怎读取ini配置文件并按要显示
您看这样符合您的要求吗？
http://www.bkjia.com/phpjc/893204.htmlwww.bkjia.comtruehttp://www.bkjia.com/phpjc/893204.htmltecharticle深入理解php中的ini配置(2)，深入理解ini 继续接着上一篇写。 1，运行时改变 配置 在前一篇中曾经谈到， ini_set函数可以在php执行的过程中，...