深入理解php中的ini配置(1)
這篇文章不會詳細敘述某個ini配置項的用途，這些在手冊上已經講解的面面俱到。我只是想從某個特定的角度去挖掘php的實現機制，會涉及到一些php核心方面的知識:-) 使用php的同學都知道php.ini配置的生效會貫穿整個SAPI的生命週期。在一段php指令碼的執行過程中，如果手動修改ini配置，是不會啟作用的。此時如果無法重啟apache或者nginx等，那麼就只能顯式的在php代碼中調用ini_set介面。ini_set是php向我們提供的一個動態修改配置的函數，需要注意的是，利用ini_set所設定的配置與ini檔案中設定的配置，其生效的時間範圍並不相同。在php指令碼執行結束之後，ini_set的設定便會隨即失效。 因此本文打算分兩篇，第一篇闡述php.ini配置原理，第二篇講動態修改php配置。 php.ini的配置大致會涉及到三塊資料，configuration_hash，EG(ini_directives)以及PG、BG、PCRE_G、JSON_G、XXX_G等。如果不清楚這三種資料的含義也沒有關係，下文會詳細解釋。 1，解析INI設定檔由於php.ini需要在SAPI過程中一直生效，那麼解析ini檔案並據此來構建php配置的工作，必定是發生SAPI的一開始。換句話說，也就是必定發生在php的啟動過程中。php需要任意一個實際的請求到達之前，其內部已經產生好這些配置。 反映到php的核心，即為php_module_startup函數。 php_module_startup主要負責對php進行啟動，通常它會在SAPI開始的時候被調用。btw，還有一個常見的函數是php_request_startup，它負責將在每個請求到來的時刻進行初始化，php_module_startup與php_request_startup是兩個標識性的動作，不過對他們進行分析並不在本文的探討範圍內。 舉個例子，當php掛接在apache下面做一個module，那麼apache啟動的時候，便會啟用所有這些module，其中包括php module。在啟用php module時，便會調用到php_module_startup。php_module_startup函數完成了茫茫多的工作，一旦php_module_startup調用結束就意味著，OK，php已經啟動，現在可以接受請求並作出響應了。 在php_module_startup函數中，與解析ini檔案相關的實現是： /* this will read in php.ini, set up the configuration parameters, load zend extensions and register php function extensions to be loaded later */if (php_init_config(TSRMLS_C) == FAILURE) { return FAILURE;}可以看到，其實就是調用了php_init_config函數，去完成對ini檔案的parse。parse工作主要進行lex&grammar分析，並將ini檔案中的key、value索引值對提取出來並儲存。php.ini的格式很簡單，等號左側為key，右側為value。每當一對kv被提取出來之後，php將它們儲存到哪兒呢？答案就是之前提到的configuration_hash。 static HashTable configuration_hash;configuration_hash聲明在php_ini.c中，它是一個HashTable類型的資料結構。顧名思義，其實就是張hash表。題外話，在php5.3之前的版本是沒法擷取configuration_hash的，因為它是php_ini.c檔案的一個static的變數。後來php5.3添加了php_ini_get_configuration_hash介面，該介面直接返回&configuration_hash，使 得php各個擴充可以方便的一窺configuration_hash全貌...真是普大喜奔... 注意四點： 第一，php_init_config不會做除了詞法文法以外的任何校正。也就是說，假如我們在ini檔案中添加一行 hello=world，只要這是一個格式正確的配置項，那麼最終configuration_hash中就會包含一個鍵為hello、值為world的元素，configuration_hash最大限度的反映出ini檔案。 第二，ini檔案允許我們以數組的形式進行配置。例如ini檔案中寫入以下三行： drift.arr[]=1drift.arr[]=2drift.arr[]=3那麼最終產生的configuration_hash表中，就會存在一個key為drift.arr的元素，其value為一個包含的1,2,3三個數位數組。這是一種極為罕見的配置方法。 第三，php還允許我們除了預設的php.ini檔案（準確說是php-%s.ini）之外，另外構建一些ini檔案。這些ini檔案會被放入一個額外的目錄。該目錄由環境變數PHP_INI_SCAN_DIR來指定，當php_init_config解析完了php.ini之後，會再次掃描此目錄，然後找出目錄中所有.ini檔案來分析。這些額外的ini檔案中產生的kv索引值對，也會被加入到configuration_hash中去。 這是一個偶爾有用的特性，假設我們自己開發php的擴充，卻又不想將配置混入php.ini，便可以另外寫一份ini，並通過PHP_INI_SCAN_DIR告訴php該去哪兒找到它。當然，其缺點也顯而易見，其需要設定額外的環境變數來支援。更好的解決辦法是，開發人員在擴充中自己調用php_parse_user_ini_file或zend_parse_ini_file去解析對應的ini檔案。 第四，在configuration_hash中，key是字串，那麼值的類型是什嗎？答案也是字串（除了上述很特殊的數組）。具體來說，比如下面的配置： display_errors = Onlog_errors = Offlog_errors_max_len = 1024 那麼最後configuration_hash中實際存放的索引值對為： key: "display_errors"val : "1" key: "log_errors"val : "" key: "log_errors_max_len"val : "1024"注意log_errors，其存放的值連"0"都不是，就是一個實實在在地Null 字元串。另外，log_errors_max_len也並非數字，而是字串1024。 分析至此，基本上解析ini檔案相關的內容都說清楚了。簡單總結一下： 1，解析ini發生在php_module_startup階段 2，解析結果存放在configuration_hash裡。 2，配置作用到模組php的大致結構可以看成是最下層有一個zend引擎，它負責與OS進行互動、編譯php代碼、提供記憶體託管等等，在zend引擎的上層，排列著很多很多的模組。其中最核心的就一個Core模組，其他還有比如Standard，PCRE，Date，Session等等...這些模組還有另一個名字叫php擴充。我們可以簡單理解為，每個模組都會提供一組功能介面給開發人員來調用，舉例來說，常用的諸如explode，trim，array等內建函數，便是由Standard模組提供的。 為什麼需要談到這些，是因為在php.ini裡除了針對php自身，也就是針對Core模組的一些配置（例如safe_mode，display_errors，max_execution_time等），還有相當多的配置是針對其他不同模組的。 例如，date模組，它提供了常見的date， time，strtotime等函數。在php.ini中，它的相關配置形如： [Date];date.timezone = 'Asia/Shanghai';date.default_latitude = 31.7667;date.default_longitude = 35.2333;date.sunrise_zenith = 90.583333;date.sunset_zenith = 90.583333除了這些模組擁有獨立的配置，zend引擎也是可配的，只不過zend引擎的可配項非常少，只有error_reporting，zend.enable_gc和detect_unicode三項。 在上一小節中我們已經談到，php_module_startup會調用php_init_config，其目的是解析ini檔案並產生configuration_hash。那麼接下來在php_module_startup中還會做什麼事情呢？很顯然，就是會將configuration_hash中的配置作用於Zend，Core，Standard，SPL等不同模組。當然這並非一個一蹴而就的過程，因為php通常會包含有很多模組，php啟動的過程中這些模組也會依次進行啟動。那麼，對模組A進行配置的過程，便是發生在模組A的啟動過程中。 有擴充開發經驗的同學會直接指出，模組A的啟動不就是在PHP_MINIT_FUNCTION(A)中嗎？ 是的，如果模組A需要配置，那麼在PHP_MINIT_FUNCTION中，可以調用REGISTER_INI_ENTRIES()來完成。REGISTER_INI_ENTRIES會根據當前模組所需要的配置項名稱，去configuration_hash尋找使用者佈建的配置值，並更新到模組自己的全域空間中。 2.1，模組的全域空間要理解如何將ini配置從configuration_hash作用到各個模組之前，有必要先瞭解一下php模組的全域空間。對於不同的php模組，均可以開闢一塊屬於自己的儲存空間，並且這塊空間對於該模組來說，是全域可見的。一般而言，它會被用來存放該模組所需的ini配置。也就是說，configuration_hash中的配置項，最終會被存放到該全域空間中。在模組的執行過程中，只需要直接存取這塊全域空間，就可以拿到使用者針對該模組進行的設定。當然，它也經常被用來記錄模組在執行過程中的中間資料。 我們以bcmath模組來舉例說明，bcmath是一個提供數學計算方面介面的php模組，首先我們來看看它有哪些ini配置： PHP_INI_BEGIN() STD_PHP_INI_ENTRY("bcmath.scale", "0", PHP_INI_ALL, OnUpdateLongGEZero, bc_precision, zend_bcmath_globals, bcmath_globals)PHP_INI_END()bcmath只有一個配置項，我們可以在php.ini中用bcmath.scale來配置bcmath模組。 接下來繼續看看bcmatch模組的全域空間定義。在php_bcmath.h中有如下聲明： ZEND_BEGIN_MODULE_GLOBALS(bcmath) bc_num _zero_; bc_num _one_; bc_num _two_; long bc_precision;ZEND_END_MODULE_GLOBALS(bcmath) 宏展開之後，即為： typedef struct _zend_bcmath_globals { bc_num _zero_; bc_num _one_; bc_num _two_; long bc_precision;} zend_bcmath_globals;其實，zend_bcmath_globals類型就是bcmath模組中的全域空間類型。這裡僅僅聲明了zend_bcmath_globals結構體，在bcmath.c中還有具體的執行個體化定義： // 展開後即為zend_bcmath_globals bcmath_globals;ZEND_DECLARE_MODULE_GLOBALS(bcmath) 可以看出，用ZEND_DECLARE_MODULE_GLOBALS完成了對變數bcmath_globals的定義。 bcmath_globals是一塊真正的全域空間，它包含有四個欄位。其最後一個欄位bc_precision，對應於ini配置中的bcmath.scale。我們在php.ini中設定了bcmath.scale的值，隨後在啟動bcmath模組的時候，bcmath.scale的值被更新到bcmath_globals.bc_precision中去。 把configuration_hash中的值，更新到各個模組自己定義的xxx_globals變數中，就是所謂的將ini配置作用到模組。一旦模組啟動完成，那麼這些配置也都作用到位。所以在隨後的執行階段，php模組無需再次訪問configuration_hash，模組僅需要訪問自己的XXX_globals，就可以拿到使用者設定的配置。 bcmath_globals，除了有一個欄位為ini配置項，其他還有三個欄位為何意？這就是模組全域空間的第二個作用，它除了用於ini配置，還可以儲存模組執行過程中的一些資料。 再例如json模組，也是php中一個很常用的模組： ZEND_BEGIN_MODULE_GLOBALS(json) int error_code;ZEND_END_MODULE_GLOBALS(json)可以看到json模組並不需要ini配置，它的全域空間只有一個欄位error_code。error_code記錄了上一次執行json_decode或者json_encode中發生的錯誤。json_last_error函數便是返回這個error_code，來協助使用者定位錯誤原因。 為了能夠很便捷的訪問模組全域空間變數，php約定俗成的提出了一些宏。比如我們想訪問json_globals中的error_code，當然可以直接寫做json_globals.error_code（多線程環境下不行），不過更通用的寫法是定義JSON_G宏： #define JSON_G(v) (json_globals.v)我們使用JSON_G(error_code)來訪問json_globals.error_code。本文剛開始的時候，曾提到PG、BG、JSON_G、PCRE_G，XXX_G等等，這些宏在php原始碼中也是很常見的。現在我們可以很輕鬆的理解它們，PG宏可以訪問Core模組的全域變數，BG訪問Standard模組的全域變數，PCRE_G則訪問PCRE模組的全域變數。 #define PG(v) (core_globals.v)#define BG(v) (basic_globals.v)2.2，如何確定一個模組需要哪些配置呢？模組需要什麼樣的INI配置，都是在各個模組中自己定義的。舉例來說，對於Core模組，有如下的配置項定義： PHP_INI_BEGIN() ...... STD_PHP_INI_ENTRY_EX("display_errors", "1", PHP_INI_ALL, OnUpdateDisplayErrors, display_errors, php_core_globals, core_globals, display_errors_mode) STD_PHP_INI_BOOLEAN("enable_dl", "1", PHP_INI_SYSTEM, OnUpdateBool, enable_dl, php_core_globals, core_globals) STD_PHP_INI_BOOLEAN("expose_php", "1", PHP_INI_SYSTEM, OnUpdateBool, expose_php, php_core_globals, core_globals) STD_PHP_INI_BOOLEAN("safe_mode", "0", PHP_INI_SYSTEM, OnUpdateBool, safe_mode, php_core_globals, core_globals) ......PHP_INI_END()可以在php-src\main\main.c檔案大概450+行找到上述代碼。其中涉及的宏比較多，有ZEND_INI_BEGIN 、ZEND_INI_END、PHP_INI_ENTRY_EX、STD_PHP_INI_BOOLEAN等等，本文不一一贅述，感興趣的讀者可自行分析。 上述代碼進行宏展開後得到： static const zend_ini_entry ini_entries[] = { .. { 0, PHP_INI_ALL, "display_errors",sizeof("display_errors"),OnUpdateDisplayErrors,(void *)XtOffsetOf(php_core_globals, display_errors), (void *)&core_globals, NULL, "1", sizeof("1")-1, NULL, 0, 0, 0, display_errors_mode }, { 0, PHP_INI_SYSTEM, "enable_dl", sizeof("enable_dl"), OnUpdateBool, (void *)XtOffsetOf(php_core_globals, enable_dl), (void *)&core_globals, NULL, "1", sizeof("1")-1, NULL, 0, 0, 0, zend_ini_boolean_displayer_cb }, { 0, PHP_INI_SYSTEM, "expose_php", sizeof("expose_php"), OnUpdateBool, (void *)XtOffsetOf(php_core_globals, expose_php), (void *)&core_globals, NULL, "1", sizeof("1")-1, NULL, 0, 0, 0, zend_ini_boolean_displayer_cb }, { 0, PHP_INI_SYSTEM, "safe_mode", sizeof("safe_mode"), OnUpdateBool, (void *)XtOffsetOf(php_core_globals, safe_mode), (void *)&core_globals, NULL, "0", sizeof("0")-1, NULL, 0, 0, 0, zend_ini_boolean_displayer_cb }, ... { 0, 0, NULL, 0, NULL, NULL, NULL, NULL, NULL, 0, NULL, 0, 0, 0, NULL }};我們看到，配置項的定義，其本質上就是定義了一個zend_ini_entry類型的數組。zend_ini_entry結構體的欄位具體含義為： struct _zend_ini_entry { int module_number; // 模組的id int modifiable; // 可被修改的範圍，例如php.ini，ini_set char *name; // 配置項的名稱 uint name_length; ZEND_INI_MH((*on_modify)); // 回呼函數，配置項註冊或修改的時候會調用 void *mh_arg1; // 通常為配置項欄位在XXX_G中的位移量 void *mh_arg2; // 通常為XXX_G void *mh_arg3; // 通常為保留欄位，極少用到 char *value; // 配置項的值 uint value_length; char *orig_value; // 配置項的原始值 uint orig_value_length; int orig_modifiable; // 配置項的原始modifiable int modified; // 是否發生過修改，如果有修改，則orig_value會儲存修改前的值 void (*displayer)(zend_ini_entry *ini_entry, int type);};2.3，將配置作用到模組——REGISTER_INI_ENTRIES經常能夠在不同擴充的PHP_MINIT_FUNCTION裡看到REGISTER_INI_ENTRIES。REGISTER_INI_ENTRIES主要負責完成兩件事情，第一，對模組的全域空間XXX_G進行填充，同步configuration_hash中的值到XXX_G中去。其次，它還產生了EG(ini_directives)。 REGISTER_INI_ENTRIES也是一個宏，展開之後實則為zend_register_ini_entries方法。具體來看下zend_register_ini_entries的實現： ZEND_API int zend_register_ini_entries(const zend_ini_entry *ini_entry, int module_number TSRMLS_DC) /* {{{ */{ // ini_entry為zend_ini_entry類型數組，p為數組中每一項的指標 const zend_ini_entry *p = ini_entry; zend_ini_entry *hashed_ini_entry; zval default_value; // EG(ini_directives)就是registered_zend_ini_directives HashTable *directives = registered_zend_ini_directives; zend_bool config_directive_success = 0; // 還記得ini_entry最後一項固定為{ 0, 0, NULL, ... }麼 while (p->name) { config_directive_success = 0; // 將p指向的zend_ini_entry加入EG(ini_directives) if (zend_hash_add(directives, p->name, p->name_length, (void*)p, sizeof(zend_ini_entry), (void **) &hashed_ini_entry) == FAILURE) { zend_unregister_ini_entries(module_number TSRMLS_CC); return FAILURE; } hashed_ini_entry->module_number = module_number; // 根據name去configuration_hash中查詢，取出來的結果放在default_value中 // 注意default_value的值比較原始，一般是數字、字串、數組等，具體取決於php.ini中的寫法 if ((zend_get_configuration_directive(p->name, p->name_length, &default_value)) == SUCCESS) { // 調用on_modify更新到模組的全域空間XXX_G中 if (!hashed_ini_entry->on_modify || hashed_ini_entry->on_modify(hashed_ini_entry, Z_STRVAL(default_value), Z_STRLEN(default_value), hashed_ini_entry->mh_arg1, hashed_ini_entry->mh_arg2, hashed_ini_entry->mh_arg3, ZEND_INI_STAGE_STARTUP TSRMLS_CC) == SUCCESS) { hashed_ini_entry->value = Z_STRVAL(default_value); hashed_ini_entry->value_length = Z_STRLEN(default_value); config_directive_success = 1; } } // 如果configuration_hash中沒有找到，則採用預設值 if (!config_directive_success && hashed_ini_entry->on_modify) { hashed_ini_entry->on_modify(hashed_ini_entry, hashed_ini_entry->value, hashed_ini_entry->value_length, hashed_ini_entry->mh_arg1, hashed_ini_entry->mh_arg2, hashed_ini_entry->mh_arg3, ZEND_INI_STAGE_STARTUP TSRMLS_CC); } p++; } return SUCCESS;}簡單來說，可以把上述代碼的邏輯表述為： 1，將模組聲明的ini配置項添加到EG(ini_directives)中。注意，ini配置項的值可能在隨後被修改。 2，嘗試去configuration_hash中尋找各個模組需要的ini。 如果能夠找到，說明使用者叜ini檔案中配置了該值，那麼採用使用者的配置。如果沒有找到，OK，沒有關係，因為模組在聲明ini的時候，會帶上預設值。3，將ini的值同步到XX_G裡面。畢竟在php的執行過程中，起作用的還是這些XXX_globals。具體的過程是調用每條ini配置對應的on_modify方法完成，on_modify由模組在聲明ini的時候進行指定。 我們來具體看下on_modify，它其實是一個函數指標，來看兩個具體的Core模組的配置聲明： STD_PHP_INI_BOOLEAN("log_errors", "0", PHP_INI_ALL, OnUpdateBool, log_errors, php_core_globals, core_globals)STD_PHP_INI_ENTRY("log_errors_max_len","1024", PHP_INI_ALL, OnUpdateLong, log_errors_max_len, php_core_globals, core_globals)對於log_errors，它的on_modify被設定為OnUpdateBool，對於log_errors_max_len，則on_modify被設定為OnUpdateLong。 進一步假設我們在php.ini中的配置為： log_errors = Onlog_errors_max_len = 1024具體來看下OnUpdateBool函數： ZEND_API ZEND_INI_MH(OnUpdateBool) { zend_bool *p; // base表示core_globals的地址 char *base = (char *) mh_arg2; // p表示core_globals的地址加上log_errors欄位的位移量 // 得到的即為log_errors欄位的地址 p = (zend_bool *) (base+(size_t) mh_arg1); if (new_value_length == 2 && strcasecmp("on", new_value) == 0) { *p = (zend_bool) 1; } else if (new_value_length == 3 && strcasecmp("yes", new_value) == 0) { *p = (zend_bool) 1; } else if (new_value_length == 4 && strcasecmp("true", new_value) == 0) { *p = (zend_bool) 1; } else { // configuration_hash中存放的value是字串"1"，而非"On" // 因此這裡用atoi轉化成數字1 *p = (zend_bool) atoi(new_value); } return SUCCESS;}最令人費解的估計就是mh_arg1和mh_arg2了，其實對照前面所述的zend_ini_entry定義，mh_arg1，mh_arg2還是很容易參透的。mh_arg1表示位元組位移量，mh_arg2表示XXX_globals的地址。因此，(char *)mh_arg2 + mh_arg1的結果即為XXX_globals中某個欄位的地址。具體到本case中，就是計算core_globals中log_errors的地址。因此，當OnUpdateBool最後執行到 *p = (zend_bool) atoi(new_value); 其作用就相當於 core_globals.log_errors = (zend_bool) atoi("1"); 分析完了OnUpdateBool，我們再來看OnUpdateLong便覺得一目瞭然： ZEND_API ZEND_INI_MH(OnUpdateLong){ long *p; char *base = (char *) mh_arg2; // 獲得log_errors_max_len的地址 p = (long *) (base+(size_t) mh_arg1); // 將"1024"轉化成long型，並賦值給core_globals.log_errors_max_len *p = zend_atol(new_value, new_value_length); return SUCCESS;}最後需要注意的是，zend_register_ini_entries函數中，如果configuration_hash中存在配置，則當調用on_modify結束後，hashed_ini_entry中的value和value_length會被更新。也就是說，如果使用者在php.ini中配置過，則EG(ini_directives)存放的就是實際配置的值。如果使用者沒配，EG(ini_directives)中存放的是聲明zend_ini_entry時給出的預設值。 zend_register_ini_entries中的default_value變數命名比較糟糕，相當容易造成誤解。其實default_value並非表示預設值，而是表示使用者實際配置的值。 3，總結至此，三塊資料configuration_hash，EG(ini_directives)以及PG、BG、PCRE_G、JSON_G、XXX_G...已經都交代清楚了。 總結一下： 1，configuration_hash，存放php.ini檔案裡的配置，不做校正，其值為字串。2，EG(ini_directives)，存放的是各個模組中定義的zend_ini_entry，如果使用者在php.ini配置過（configuration_hash中存在），則值被替換為configuration_hash中的值，類型依然是字串。3，XXX_G，該宏用於訪問模組的全域空間，這塊記憶體空間可用來存放ini配置，並通過on_modify指定的函數進行更新，其資料類型由XXX_G中的欄位聲明來決定。
http://www.bkjia.com/PHPjc/892830.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/892830.htmlTechArticle深入理解php中的ini配置(1) 這篇文章不會詳細敘述某個ini配置項的用途，這些在手冊上已經講解的面面俱到。我只是想從某個特定的角度去挖...
