国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

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

qingshanli1988 / 792人閱讀

摘要:而這個類型的最終之所以輸出為,是因為進行科學計數法之后的精度丟失了,重新轉成時就恢復不了原來的值。此類問題解決方案對于存儲,超過最大表示范圍的純整數,在中可以使用保存,在查詢出來的時候會將其使用類型保存的。

遇到的問題

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

$shopId = 17978812896666957068;
var_dump($shopId);

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

float(1.7978812896667E+19)

但在程序里需要的是完整的數字作為查找數據的參數,所以需要用的是完整的數字,當時以為只是因為數據被轉換成科學計數法了,于是想到的解決方案是強制讓它不使用科學計數法表示:

$shopId= number_format(17978812896666957068);
var_dump($shopId);

這時候奇怪的事情出現了,輸出的是:

17978812896666957824

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

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

$shopId= strval(17978812896666957068);
var_dump($shopId);

$shopId = 17978812896666957068 . ‘’;
var_dump($shopId);

輸出的結果都是

float(1.7978812896667E+19)

最后只有下面這種方案是可行的:

$shopId = ‘17978812896666957068’;
var_dump($shopId);

// 輸出
//string(20) "17978812896666957068"

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

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

示例代碼:

// test.php
$var = 17978812896666957068;
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的賦值如下:

將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處理函數的命名是有以下規律的

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

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


ZEND_ASSIGN_SPEC_CV_CONST_RETVAL_UNUSED_HANDLER

找出函數的定義如下:

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

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真正將大整數做轉換的地方:

{LNUM} {
char *end;
if (yyleng < MAX_LENGTH_OF_LONG - 1) { /* Won"t overflow */
    errno = 0;
    ZVAL_LONG(zendlval, ZEND_STRTOL(yytext, &end, 0));
    /* This isn"t an assert, we need to ensure 019 isn"t valid octal
    * Because the lexing itself doesn"t do that for us
    */
    if (end != yytext + yyleng) {
        zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0);
        ZVAL_UNDEF(zendlval);
        RETURN_TOKEN(T_LNUMBER);
    }
} else {
    errno = 0;
    ZVAL_LONG(zendlval, ZEND_STRTOL(yytext, &end, 0));
    if (errno == ERANGE) { /* Overflow */
        errno = 0;
        if (yytext[0] == "0") { /* octal overflow */
            ZVAL_DOUBLE(zendlval, zend_oct_strtod(yytext, (const char **)&end));
        } else {
            ZVAL_DOUBLE(zendlval, zend_strtod(yytext, (const char **)&end));
        }
        /* Also not an assert for the same reason */
        if (end != yytext + yyleng) {
            zend_throw_exception(zend_ce_parse_error,
            "Invalid numeric literal", 0);
            ZVAL_UNDEF(zendlval);
            RETURN_TOKEN(T_DNUMBER);
        }
        RETURN_TOKEN(T_DNUMBER);
    }    
    /* Also not an assert for the same reason */
    if (end != yytext + yyleng) {
        zend_throw_exception(zend_ce_parse_error, "Invalid numeric literal", 0);
        ZVAL_UNDEF(zendlval);
        RETURN_TOKEN(T_DNUMBER);
    }
}
ZEND_ASSERT(!errno);
RETURN_TOKEN(T_LNUMBER);
}

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

number_format失敗的原因

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

函數原型如下:

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語言下驗證:

double local_dval = 1.7978812896666958E+19;
printf("%f
", local_dval);

輸出的結果就是

17978812896666957824.000000

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

此類問題解決方案

對于存儲,超過PHP最大表示范圍的純整數,在MySQL中可以使用bigint/varchar保存,MySQL在查詢出來的時候會將其使用string類型保存的。
對于賦值,在PHP里,如果遇到有大整數需要賦值的話,不要嘗試用整型類型去賦值,比如,不要用以下這種:

$var = 17978812896666957068;

而用這種:

$var = "17978812896666957068";

而對于number_format,在64位操作系統下,它能解析的精度不會丟失的數,建議的最大值是這個:9007199254740991。參考鳥哥博客:http://www.laruence.com/2011/...

總結

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

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

原創文章,文筆有限,才疏學淺,文中若有不正之處,萬望告知。

如果本文對你有幫助,請點下推薦吧,謝謝^_^

更多精彩內容,請關注個人公眾號。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/25845.html

相關文章

  • 原生JS揭秘—揭開數據類型轉換面紗

    摘要:可以將其他類型轉成字符串函數可以將任意類型的值轉為布爾值。提示空數組空對象轉換為布爾型也是。 在JS中數據類型轉換有兩種 相關資料參閱 官方ecma-5規范阮一峰老師類型轉換規范對相等==定義 強制類型轉換Number() Number函數將字符串轉為數值,要比parseInt函數嚴格很多,只要有一個字符是非數字(空格、+、-除外),那么就會被轉為NaN。 showImg(http...

    Moxmi 評論0 收藏0
  • 服務治理深入淺出(1)- 服務治理出現必要性探索

    摘要:服務化的出現假想一個京東的發展路程都是我虛構的。更多的服務的提取抽離,更多的團隊出現業務繼續發展,出現了京東大藥房,專門賣藥,需要調用京東目前的財務系統。 以下內容都是自己的理解,不保證正確,可能是對的,也可能把你帶溝里,自己甄別。 更多詳情請看直播 揭開她的神秘面紗 - 零基礎構建自己的服務治理框架 https://segmentfault.com/l/15... 很久之前聽別人分...

    Bryan 評論0 收藏0
  • 揭開面紗 踏足云世界 再猶豫該OUT了

    摘要:一般流程你可以通過良好的選擇一種構造來設計你自己的文件領域。 隨著云世界的日新月異,想進入云世界的您在面對大量的選擇時該何去何從?下面是一些關于知名云服務的使用和測試總結。當然在這之前,我們必須知道云是建立在托管您的應用程序上的服務。 Auto-Scalling — 當需求增加時,你可以自動的獲得更多資源(一般情況下是更多的虛擬機)來響應請求。這在一般的應用程序中很少用到,但能保證你的服...

    Shimmer 評論0 收藏0
  • 白話揭開Ajax長輪詢(long polling)神秘面紗

    摘要:在看這篇長輪詢之前可以先看看輪詢技術沒有長,有助于理解長輪詢屬于輪詢的升級版,在客戶端和服務端都進行了一些改造,使得消耗更低,速度更快。不間斷的通過查詢服務端。然后客戶端不間斷繼續發起請求數據不存在,繼續循環。 在看這篇Ajax長輪詢之前可以先看看Ajax輪詢技術(沒有長),有助于理解: Ajax長輪詢屬于Ajax輪詢的升級版,在客戶端和服務端都進行了一些改造,使得消耗更低,速度更快。...

    AlphaGooo 評論0 收藏0

發表評論

0條評論

qingshanli1988

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<