539      技術社區[雲棲]

自上而下，逐步揭開PHP解析大整數的麵紗

遇到的問題

最近遇到一個PHP大整數的問題，問題代碼是這樣的

1. $shopId = 17978812896666957068;  
2. var_dump($shopId); 

上麵的代碼輸出，會把$shopId轉換成float類型，且使用了科學計數法來表示，輸出如下：

1. float(1.7978812896667E+19) 

但在程序裏需要的是完整的數字作為查找數據的參數，所以需要用的是完整的數字，當時以為隻是因為數據被轉換成科學計數法了，於是想到的解決方案是強製讓它不使用科學計數法表示：

1. $shopId= number_format(17978812896666957068);  
2. var_dump($shopId); 

這時候奇怪的事情出現了，輸出的是：

1. 17978812896666957824 

當時沒有仔細看，對比了前十位就沒有繼續往下看，所以認為問題解決了，等到真正根據ID去找數據的時候才發現數據查不出來，這時候才發現是數據轉換錯誤了。

這裏使用number_format失敗的原因在後麵會講到，當時就想到將原來的數據轉成字符串的，但是使用了以下方法仍然不行

1. $shopId= strval(17978812896666957068); 
2. var_dump($shopId); 
3.  
4. $shopId = 17978812896666957068 . ‘’; 
5. var_dump($shopId); 

輸出的結果都是

1. float(1.7978812896667E+19) 

最後隻有下麵這種方案是可行的：

1. $shopId = ‘17978812896666957068’; 
2. var_dump($shopId); 
3.  
4. // 輸出 
5. //string(20) "17978812896666957068" 

眾所周知，PHP是一門解釋型語言，所以當時就大膽地猜測PHP是在編譯期間就將數字的字麵量常量轉換成float類型，並用科學計數法表示。但僅僅猜測不能滿足自己的好奇心，想要看到真正實現代碼才願意相信。於是就逐步分析、探索，直到找到背後的實現。

剛開始根據這個問題直接上網搜“PHP大整數解析過程”，並沒有搜到答案，因此隻能自己去追查。一開始對PHP的執行過程不熟悉，出發點就隻能是一步一步地調試，然後

示例代碼：

1. // test.php 
2. $var = 17978812896666957068; 
3. var_dump($var); 

追查過程

1、查看opcode

通過vld查看PHP執行代碼的opcode，可以看到，賦值的是一個ASSIGN的opcode操作

接下來就想看看ASSIGN是在哪裏執行的。

2、gdb調試

2-1、用list查看有什麼地方可以進行斷點

2-2、暫時沒有頭緒，在1186斷點試試

結果程序走到sapi/cli/php_cli.c文件的1200行了，按n不斷下一步執行，一直到這裏就走到了程序輸出結果了：

2-4、於是猜測，ASSIGN操作是在do_cli函數裏麵進行的，因此對do_cli函數做斷點：break do_cli。

輸入n，不斷回車，在sapi/cli/php_cli.c文件的993行之後就走到程序輸出結果了：

2-5、再對php_execute_script函數做斷點：break php_execute_script，不斷逐步執行，發現在main/main.c文件的2537行就走到程序輸出結果了：

2-6、繼續斷點的步驟：break zend_execute_scripts，重複之前的步驟，發現在zend/Zend.c文件的1476行走到了程序輸出結果的步驟：

看到這裏的時候，第1475行裏有一個op_array，就猜測會不會是在op_array的時候就已經有值了，於是開始打印op_array的值：

打印之後並沒有看到有用的信息，但是其實這裏包含有很大的信息量，比如opcode的handler: ZEND_ASSIGN_SPEC_CV_RETVAL_CV_CONST_RETVAL_UNUSED_HANDLER ，但是當時沒注意到，因此就想著看看op_array是怎麼被賦值的，相關步驟做了什麼。

2-7、重新從2-5的斷點開始，讓程序逐步執行，看到op_array的賦值如下：

看到第1470行將zend_compile_file函數運行的結果賦值給op_array了，於是break zend_compile_file，被告知zend_compile_file未定義，通過源碼工具追蹤到zend_compile_file指向的是compile_file，於是break zend_compile

發現是在Zend/zend_language_scanner.l 文件斷點了，逐步執行，看到這行pass_two(op_array)，猜測可能會在這裏就有值，所以打印看看：

結果發現還是跟之前的一樣，但是此時看到有一個opcodes的值，再打印看看

看到opcode = 38，網上查到38代表賦值

2-8、於是可以知道，在這一步之前就已得到了ASSIGN的opcode，因此，不斷地往前找，從op_array開始初始化時就開始，逐步打印op_array->opcodes的值，一直都是null，

直到執行了 CG(zend_lineno) = last_lineno; 才得到opcode = 38 的值：

因為這一句：CG(zend_lineno) = last_lineno;是一個宏，所以也沒頭緒，接近放棄狀態。。。

於是先去了解opcode的數據結構，在 深入理解PHP內核書 裏找到opcode處理函數查找這一章，給了我一些繼續下去的思路。

引用裏麵的內容：

在PHP內部有一個函數用來快速的返回特定opcode對應的opcode處理函數指針：zend_vm_get_opcode_handler()函數：

知道其實opcode處理函數的命名是有以下規律的

1. ZEND_[opcode]_SPEC_(變量類型1)_(變量類型2)_HANDLER 

根據之前調試打印出來的內容，在2-6的時候就看到了一個handler的值：

是

1. ZEND_ASSIGN_SPEC_CV_CONST_RETVAL_UNUSED_HANDLER， 

找出函數的定義如下：

可以看到，opcode操作的時候，值是從EX_CONSTANT獲取的，根據定義展開這個宏，那就是

1. opline->op2->execute_data->literals 

這裏可以得到兩個信息：

1. 參數的轉換在opcode執行前就做好了
2. 賦值過程取值時是在op2->execute_data->literals，如果猜想沒錯的話，op2->execute_data->literals此時保存的就是格式轉換後的值，可以打印出來驗證一下

打印結果如下：

猜想驗證正確，但是沒有看到真正做轉換的地方，還是不死心，繼續找PHP的Zend底層做編譯的邏輯代碼。

參考開源的 GitHub項目 ，PHP編譯階段如下圖：

猜測最有可能的是在zendparse、zend_compile_top_stmt這兩個階段完成轉換，因為這個兩個階段做的事情就是將PHP代碼轉換成opcode數組。

上網搜索了PHP語法分析相關的文章，有一篇裏麵講到了解析整數的過程，因此找到了PHP真正將大整數做轉換的地方：

1. <ST_IN_SCRIPTING>{LNUM} { 
2. char *end; 
3. if (yyleng < MAX_LENGTH_OF_LONG - 1) { /* Won't overflow */ 
4.     errno = 0; 
5.     ZVAL_LONG(zendlval, ZEND_STRTOL(yytext, &end, 0)); 
6.     /* This isn't an assert, we need to ensure 019 isn't valid octal 
7.     * Because the lexing itself doesn't do that for us 
8.     */ 
9.     if (end != yytext + yyleng) { 
10.         zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0); 
11.         ZVAL_UNDEF(zendlval); 
12.         RETURN_TOKEN(T_LNUMBER); 
13.     } 
14. } else { 
15.     errno = 0; 
16.     ZVAL_LONG(zendlval, ZEND_STRTOL(yytext, &end, 0)); 
17.     if (errno == ERANGE) { /* Overflow */ 
18.         errno = 0; 
19.         if (yytext[0] == '0') { /* octal overflow */ 
20.             ZVAL_DOUBLE(zendlval, zend_oct_strtod(yytext, (const char **)&end)); 
21.         } else { 
22.             ZVAL_DOUBLE(zendlval, zend_strtod(yytext, (const char **)&end)); 
23.         } 
24.         /* Also not an assert for the same reason */ 
25.         if (end != yytext + yyleng) { 
26.             zend_throw_exception(zend_ce_parse_error, 
27.             "Invalid numeric literal", 0); 
28.             ZVAL_UNDEF(zendlval); 
29.             RETURN_TOKEN(T_DNUMBER); 
30.         } 
31.         RETURN_TOKEN(T_DNUMBER); 
32.     }     
33.     /* Also not an assert for the same reason */ 
34.     if (end != yytext + yyleng) { 
35.         zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0); 
36.         ZVAL_UNDEF(zendlval); 
37.         RETURN_TOKEN(T_DNUMBER); 
38.     } 
39. } 
40. ZEND_ASSERT(!errno); 
41. RETURN_TOKEN(T_LNUMBER); 
42. } 

可以看到，zend引擎在對PHP代碼在對純數字的表達式做詞法分析的時候，先判斷數字是否有可能會溢出，如果有可能溢出，先嚐試將其用LONG類型保存，如果溢出，先用zend_strtod將其轉換為double類型，然後用double類型的zval結構體保存之。

number_format失敗的原因

通過gdb調試，追查到number_format函數，在PHP底層最終會調用php_conv_fp函數對數字進行轉換：

函數原型如下：

1. PHPAPI char * php_conv_fp(register char format, register double num, boolean_e add_dp, int precision, char dec_point, bool_int * is_negative, char *buf, size_t *len); 

這裏接收的參數num是一個double類型，因此，如果傳入的是字符串類型數字的話，number_format函數也會將其轉成double類型傳入到php_conf_fp函數裏。而這個double類型的num最終之所以輸出為17978812896666957824，是因為進行科學計數法之後的精度丟失了，重新轉成double時就恢複不了原來的值。在C語言下驗證：

1. double local_dval = 1.7978812896666958E+19; 
2. printf("%f\n", local_dval); 

輸出的結果就是

17978812896666957824.000000

所以，這不是PHP的bug，它就是這樣的。

此類問題解決方案

對於存儲，超過PHP最大表示範圍的純整數，在MySQL中可以使用bigint/varchar保存，MySQL在查詢出來的時候會將其使用string類型保存的。

對於賦值，在PHP裏，如果遇到有大整數需要賦值的話，不要嚐試用整型類型去賦值，比如，不要用以下這種：

1. $var = 17978812896666957068; 

而用這種：

1. $var = '17978812896666957068'; 

而對於number_format，在64位操作係統下，它能解析的精度不會丟失的數，建議的最大值是這個：9007199254740991。參考鳥哥博客： https://www.laruence.com/2011/12/19/2399.html

總結

這個問題的原因看起來不太重要，雖然學這個對於實際上的業務開發也沒什麼用，不會讓你的開發能力“duang"地一下上去幾個level，但是了解了PHP對於大整數的處理，也是自己知識框架的一個小小積累，知道了為什麼之後，在日常開發中就會多加注意，比如從存儲以及使用賦值的角度。了解這個細節還是很有好處的。

回想整個解決問題的過程，個人感覺有點長，總共大約花了4個小時去定位這個問題。因為對PHP的內核隻是一知半解，沒有係統的把整個流程梳理下來，所以一開始也不知道從哪裏開始下手，就開始根據自己的猜測來調試。現在回想起來，應該先學習PHP的編譯、執行流程，然後再去猜測具體的步驟。

本文作者：佚名

來源：51CTO

最後更新：2017-11-02 15:04:46

  上一篇：  史上最全的Python麵向對象知識點疏理

  下一篇：  Python開發者2017應該關注的7個類庫