前端base64編碼的坑

故事背景:
前后端每次通訊的時候,需要驗證sign,這個sign經過了b64_md5兩步驟操作。
在python端,生成sign的代碼如下:

 import md5
 import base64
 m = md5.new("32438c62a70a4d4ebfb1730b262d4bea&POST&/voip/tpsn/sendsms&{bussiness={parameters=[Tom]&phone=18688721878&template=21}&system={appkey=580419120263&charset=UTF-8&timestamp=1478081529&version=1.0.0}}")
print m.digest()    // 這個方法出來的是二進制數據
 sign = base64.urlsafe_b64encode(m.digest())[:-2]
print sign

print m.hexdigest()  //這個方法是16進制數顯示的

這里先md5再經過base64, 使用了一個urlsafe_b64encode的方法。

前端在實現以上邏輯的時候,當然會首選現成的庫文件,我所找到的代碼參見這里, 直接使用b64_md5這個方法皆可。

但是這樣生成的sign與python生成的sign有一些細微的區別,比如js生成的帶有+號,而在python中則顯示為-號。這讓我想到應該調查下python中urlsafe的處理方式

其中提到:

由于標準的Base64編碼后可能出現字符+和/,在URL中就不能直接作為參數,所以又有一種"url safe"的base64編碼,其實就是把字符+和/分別變成-和_

于是對b64_md5之后返回的字符串進行替換:

var hash = b64_md5(newString);
hash = hash.replace(/\+/g, "-");
hash = hash.replace(/\//g, "_");

即可生成與python相同的sign。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容