1、empty()用於判斷變數是否為空、0或false，變數的值如果是字串'0'時也返回true；
2、isset()用於判斷變數是否被設定，即：非陣列的變數是否被賦值，陣列中指定的key是否定義且對應的value不為null；
3、任意值和布林值比較時，非empty()的任意值都會被當成true處理，否則為false；
4、任意非布林值和數值比較時，任意非布林值都會先轉成數字，如果是字母等無法轉的字串，都被當成0處理；
5、echo列印false時什麼也不會輸出，echo列印true時則會輸出1，同理boolean型別的值與字串連線時，false不會輸出，true輸出1；
6、http_build_query()會將陣列中的false轉為0，true轉為1；
7、is_int()要求型別必須是整型的數字（包括0x開頭的十六進製制），is_numeric()不僅可以是數值（包括0x開頭的十六進製制），也可以是字串型別的數字，但不能是0x開頭的十六進製制字串；
8、ltrim()和rtrim()都會迴圈去除位元組串，也就是說經過第1次去除後剩餘的字串會繼續調同樣的方法去除，直到不能去除為止，所以漢字經過處理可能出現亂碼。另外如果指定的去除多個字元中有包含關係，那麼優先去除範圍更大的那個字元；
8、中文的正則是：
"/[\x-\x]/u""/^\/[,;:!=@&#~'()[$?+*\\w\-\.\/\]]+$/"函式說明
htmlspecialchars
將html中以下特殊字元轉成轉義字元，第二個引數預設是ent_compat，只轉義雙引號，不轉義單引號，除非設定成ent_quotes。
&（與符號）轉為&
"（雙引號）轉為"
'（單引號）轉為'
< （小於）轉為<
>（大於）轉為》
htmlentities
將所有具有html實體的字元進行轉義，不止htmlspecialchars轉義的5個字元
addslashes
addslashes可以在'（單引號）、"（雙引號）、\（反斜線）與 \0（空字元）前增加\（反斜線）
stripslashes
去掉\（反斜線）
quotemeta
將. \ + * ? [ ^ ] ( $ ) 前增加\（反斜線）
nl2br
將換行符轉成
strip_tags
去除html標籤和php標記，第二個引數可以指定不去除的標籤。如果第乙個引數中包含多餘的'<'而沒有相應的'>'配對，那麼該函式會將'<'之後的內容全部去除。
mysql_escape_string
mysql_real_escape_string
將\x00 \n \r \ ' " 和 \x1a前增加\（反斜線），mysql_real_escape_string會受當前連線的字符集的影響，mysql_escape_string則不受當前連線的字符集的影響
base64_encode
使用 mime base64 對資料進行編碼
base64_decode
使用 mime base64 對編碼的資料進行解碼
rawurlencode
將字串中除了 -_. 之外的所有非字母數字字元都將被替換成百分號（%）後跟兩位十六進製制數，即rfc 3986編碼。在 php 5.3.0 之前，rawurlencode 根據rfc 1738對~（波浪線）進行編碼
rawurldecode
對已進行rawurlencode編碼的 url 字串進行解碼
urlencode
將字串中除了 -_. 之外的所有非字母數字字元都將被替換成百分號（%）後跟兩位十六進製制數，即rfc 3986編碼，但是由於歷史原因，會將空格編碼為+（加號），與rawurlencode對空格的編碼處理不同
urldecode
對已進行urlencode編碼的 url 字串進行解碼
一不小心實現了RPC
隨著最近關注 cim 專案的人越發增多，導致提的問題以及 bug 也在增加，在修復問題的過程中難免 潔癖又上來了。看著一兩年前寫的東西總是懷疑這真的是出自自己手裡嘛？有些地方實在忍不住了便開始了漫漫重構之路。在開始之前先簡單介紹一下cim這個專案，下面是它的架構圖 簡單來說就是乙個 im 即時通訊系...
一不小心走上IT這條不歸路
博主已是畢業四年的工作者，回頭想想走過的路，感覺更多的是迷茫和漫無目的。現在是時候該認真考慮以後的路怎麼走，怎麼規劃了。踏進校園的第一天就開始迷茫了，大學的生活想必大多數人都深有體會吧 猶如高考之前煉獄般 缺少自由的困獸一下子脫了韁，回歸大自然。肆意的放縱，揮霍青春，好似對高考的報復。再加上對計算機...
一不小心，陷入TCP的效能問題
一 現象 在一次訪問請求nginx中，通常只需要幾毫秒的rt，但當請求資料達到某乙個數值時，rt明顯提高，甚至超過了300毫秒。二 問題的原因 大家都知道，tcp為了提高頻寬利用率和吞吐量，做了各種優化。比如delay ack和nagle演算法。就是這樣的一些優化使用不慎，導致陷入效能問題。接下來就...