故事背景：
前后端每次通訊的時候帜乞，需要驗證sign嗽测，這個sign經(jīng)過了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×tamp=1478081529&version=1.0.0}}")
print m.digest() // 這個方法出來的是二進(jìn)制數(shù)據(jù)
sign = base64.urlsafe_b64encode(m.digest())[:-2]
print sign
print m.hexdigest() //這個方法是16進(jìn)制數(shù)顯示的
這里先md5再經(jīng)過base64, 使用了一個urlsafe_b64encode的方法澳眷。
前端在實現(xiàn)以上邏輯的時候，當(dāng)然會首選現(xiàn)成的庫文件蛉艾，我所找到的代碼參見這里钳踊， 直接使用b64_md5這個方法皆可。
但是這樣生成的sign與python生成的sign有一些細(xì)微的區(qū)別勿侯，比如js生成的帶有+號拓瞪，而在python中則顯示為-號。這讓我想到應(yīng)該調(diào)查下python中urlsafe的處理方式助琐。
其中提到：
由于標(biāo)準(zhǔn)的Base64編碼后可能出現(xiàn)字符+和/祭埂，在URL中就不能直接作為參數(shù)，所以又有一種"url safe"的base64編碼弓柱，其實就是把字符+和/分別變成-和_
于是對b64_md5之后返回的字符串進(jìn)行替換：
var hash = b64_md5(newString);
hash = hash.replace(/\+/g, "-");
hash = hash.replace(/\//g, "_");
即可生成與python相同的sign沟堡。
