事實是這樣的，我有個介面，這個介面不能被篡改，于是想到了比較簡單的md5對url地址引數進行加密，把這個密碼當成是sign，然后服務端收到請求后，使用相同演算法也生成sign，兩個sign相同就正常沒有被篡改過，
問題的出現
- 介面中的引數包括userId,extUserId,時間，其中extUserId字符編碼，中間會有+這種符號
- 有些用戶使用簽名介面正常
- 有一些用戶總顯示簽名失敗
問題原因
- 因為有些用戶的extUserId中包括了url上的特殊字符，它不能正常在在url上傳輸，必須進行urlEncode編碼才行，這一點非常容易被忽略；程式中一般不需要手動urlDecode解碼，都是由框架幫我們實作的，
- 下面整理了一些url上需要編碼的字符：
+URL中+表示空格 十六進制： %2B/分離目錄和子目錄 十六進制 : %2F?分離實際的URL和引數 十六進制： %3F%特殊字符 十六進制： %25#表示書簽 十六進制： %23&URL中指定引數間的分隔符 十六進制： %26=URL中指定引數的值 十六進制：%3D空格URL中的空格可以用+號或者編碼 十六進制 : %20
url在簽名時一般這樣處理
sign=md5(userId+extUserId+simpleDateFormat.format(new Date()) + SECRET).toUpperCase();
?extUserId=URL.Encode(extUserId)&sign=sign
注意：sign中是接收的引數，它不需要Encode，應該框架已經幫我們做了；而向下傳遞的url引數extUserId是需要手動Encode的，
作者：倉儲大叔，張占嶺，
榮譽：微軟MVP
QQ：853066980
支付寶掃一掃，為大叔打賞!
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/550919.html
標籤：其他
上一篇：Java中代碼的執行順序
下一篇：返回列表