資訊專欄INFORMATION COLUMN
摘要：中中特殊字符引起的問題前言，在做某個渠道的過程中，發(fā)現(xiàn)一個驗簽錯誤的問題。對已編碼的字符串進行解碼返回字符串，此字符串中百分號后跟兩位十六進制數(shù)的序列都將被替換成原義字符。
PHP中URL中特殊字符引起的問題(+,,=)
GET和POST前言，在做某個渠道的過程中，發(fā)現(xiàn)一個驗簽錯誤的問題。但是，當時驗簽在兩個地方表現(xiàn)不一致，同一套處理方法，想到了這是因為兩個地方請求方式是不同的一個get方法另外一個自然是post方法。當然，出問題肯定就是get。
GET請求方式，由于是將參數(shù)放在URL中，所以在進行傳遞的時候可能會受到瀏覽器端的一些策略問題，對參數(shù)進行urlencode處理。所以，當你在服務(wù)端拿到參數(shù)的時候可能并不是原始的數(shù)據(jù)。因此，在通過GET方式請求拿到數(shù)據(jù)，如果不做任何處理的話去驗簽可能會存在問題。這邊的可能就是當base64處理之后不含+這個特殊的字符，+在GET方式之后不做任何處理拿到的就是一個空白字符串。
POST請求方式，是將參數(shù)放在request body中，在進行http傳遞的過程中不會存在由于瀏覽器的一些策略問題對參數(shù)進行任何的處理。因此，通過POST請求進行參數(shù)驗簽的時候不會存在問題，能夠很順利的進行驗簽。但是，我們沒有辦法去要求渠道商將get請求變成post請求，因此我們只能自己想辦法。
urlencode和urldecodeurlencode:
(PHP 4, PHP 5, PHP 7) urlencode — 編碼 URL 字符串 string urlencode ( string $str ) 此函數(shù)便于將字符串編碼并將其用于 URL 的請求部分，同時它還便于將變量傳遞給下一頁。 return 返回字符串，此字符串中除了 -_. 之外的所有非字母數(shù)字字符都將被替換成百分號（%）后跟兩位十六進制數(shù)，空格則編碼為加號（+）。此編碼與 WWW 表單 POST 數(shù)據(jù)的編碼方式是一樣的，同時與 application/x-www-form-urlencoded 的媒體類型編碼方式一樣
urldecode:
(PHP 4, PHP 5, PHP 7) urldecode — 解碼已編碼的 URL 字符串 string urldecode ( string $str ) 解碼給出的已編碼字符串中的任何 %##。 加號（"+"）被解碼成一個空格字符。 返回解碼后的字符串。
好像我們看到了曙光，對+這個會變成空格的字符串的"完美處理方式"。那就是，對簽名字符串進行urlencode進行加密處理。然后，興高采烈的去驗證，fxxk，false。還是不通過，然后甩自己一個耳光。base64加密之后會出現(xiàn)=這個補位字符串，很蛋疼。于是我就想了一個臨時處理方式。
urlencode(substr($str,0,strlen($sign)-2)).substr($sign,strlen($sign)-2)
當時，考慮到base64最多出現(xiàn)兩個==，所以在最后兩個不進行urlencode處理。這個基本上能夠處理，但是可能存在一個問題，那就是在最后兩位出現(xiàn)+也是不行的，果然這個方案不能說服自己，推翻。并且在這個過程還發(fā)現(xiàn)一個問題就是，傳過來的簽名字符串還有可能會已經(jīng)經(jīng)過urlencode處理。這個還是一個小問題，先進行urldecode處理，因為decode不會引起誤會。
當時，小伙伴提出一個解決辦法，那就是直接替換+號不就可以了嗎？的確，這是一個辦法。但是我認為這個辦法很挫，如果以后加密算法改變了或者增加了其他特殊字符呢,比如@#￥%……&**（ 等這些，我們不可能都去匹配替換什么的。所以，我同意臨時方案處理，但是我繼續(xù)想。
rawurlencode和rawurldecoderawurlencode:
(PHP 4, PHP 5, PHP 7) rawurlencode — 按照 RFC 3986 對 URL 進行編碼 string rawurlencode ( string $str ) 根據(jù) ? RFC 3986 編碼指定的字符。
rawurldecode:
(PHP 4, PHP 5, PHP 7) rawurldecode — 對已編碼的 URL 字符串進行解碼 string rawurldecode ( string $str ) 返回字符串，此字符串中百分號（%）后跟兩位十六進制數(shù)的序列都將被替換成原義字符。
新的曙光出現(xiàn)了，理解rawurldecode,替換成原義字符。所以，解決方案呼之欲出了。
rawurldecode(urlencode(urldecode($sign))));
初看上去覺得還臃腫或者為什么要這么繞來繞去處理呢？其實你還真得這么處理，至于為什么，請看上上面的吹牛逼。
后記作為程序員，我們必須要有兩手準備，一手臨時方案，能夠快速修復現(xiàn)在問題。在生產(chǎn)環(huán)境恢復正常，但是從長遠來看必須要能夠一個穩(wěn)定可靠的方案。方案來源于你不斷的嘗試和php.net。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/25712.html
摘要：大部分需要編碼的原因是由于有特殊字符如等或者參數(shù)是中文形式。不會被此方法編碼的字符重點因此，對于中文字符串來說，如果不希望把字符串編碼格式轉(zhuǎn)化成格式的比如原頁面和目標頁面的是一致的時候，只需要使用。 一、為什么要 urlencode()？ 因為當字符串數(shù)據(jù)以url的形式傳遞給web服務(wù)器時,字符串中是不允許出現(xiàn)空格和特殊字符的。 也就是說，url的參數(shù)傳遞的時候，需要遵循一定的url...
摘要：大部分需要編碼的原因是由于有特殊字符如等或者參數(shù)是中文形式。不會被此方法編碼的字符重點因此，對于中文字符串來說，如果不希望把字符串編碼格式轉(zhuǎn)化成格式的比如原頁面和目標頁面的是一致的時候，只需要使用。 一、為什么要 urlencode()？ 因為當字符串數(shù)據(jù)以url的形式傳遞給web服務(wù)器時,字符串中是不允許出現(xiàn)空格和特殊字符的。 也就是說，url的參數(shù)傳遞的時候，需要遵循一定的url...
摘要：安全基礎(chǔ)常見的安全攻擊手段有很多，比如注入，，，頭攻擊，攻擊，重定向攻擊，上傳文件攻擊等，其中大多數(shù)都可以通過三種方法過濾代理轉(zhuǎn)義實體化來解決。個人趨向于安全狗，同時安裝服務(wù)器安全狗和網(wǎng)站安全狗可以有效地防護攻擊。 web安全基礎(chǔ) 常見的web安全攻擊手段有很多，比如SQL注入，XSS，CSRF，HTTP頭攻擊，cookie攻擊，重定向攻擊，上傳文件攻擊等，其中大多數(shù)都可以通過三種方法...
閱讀 2023·2021-09-30 09:46
閱讀 1428·2019-08-30 15:43
閱讀 1201·2019-08-29 13:28
閱讀 1985·2019-08-29 11:24
閱讀 1777·2019-08-26 13:22
閱讀 4097·2019-08-26 12:01
閱讀 1881·2019-08-26 11:33
閱讀 3293·2019-08-23 15:34
