遇到主要的問題是兩個：1. 發送訂單給支付寶接口，接口驗證簽名失敗。 2.支付寶付款結束後，發送信息給網站接收方進行二次驗籤，還是簽名過不了。驗籤的方式是RSA非對稱加密的驗證方式。
遇到的兩個問題都是一個原因：網站的數據編碼和支付寶的支付接口的編碼對不上。網站的編碼是GBK編碼，按理來說支付寶給出了編碼的配置項，也的確配置成了GBK編碼，結果數據發送過去簽名過不了。這個問題絆了很久，我舅舅一眼看出來這是發送過去的數據到了支付寶接口的url裏有少量亂碼，推測出來是編碼的問題。於是就在發送請求的時候，修改了編碼，第一次驗籤通過了。
後來我想清楚了問題出在了哪裏：咱們的網站是gb2312的編碼，不是gbk的編碼。gb2312是gbk的一個子集。支付寶只支持UTF-8 和 GBK的 編碼，不支持gb2312。所以在發送請求的時候把編碼改成GBK就簽名通過了。
這個gb2312屬於中國比較老的一種編碼，可能是咱們的這一套網站源程序比較老的原因，編碼就使用了gb2312.現在想換編碼風險也比較大。 比較新的項目大多都是採用utf-8的編碼格式，接口平臺，服務器，網站都默認採用utf-8編碼就不用擔心這個編碼的問題。
這個編碼的問題還是我第一次遇到，可以說是爲以後的工作漲姿勢了。
第二次驗籤不過我也想清楚了原因：同樣是編碼問題。接口返回的數據是gbk編碼，網站是gb2312編碼，編碼問題讓這個二次驗籤通過不了。最後是主管乾哥幫我解決了這個問題：拋棄支付寶的GBK編碼接口，使用utf-8的接口。 一次驗籤和二次驗籤都進行順利。
本週的經驗可以總結成以下幾條：
1.對接第三方接口的時候一定要確認好編碼，以及數據和類型等 是否正確。最好還是使用utf-8的編碼。
2. 當從頭開始一個新項目的時候， 編碼最好還是選擇utf-8這種主流的編碼格式。服務器，數據庫，web項目，第三方接口都使用默認的utf-8編碼，中間的卡殼問題就會減少。雖然utf-8的請求數據包會稍大一些，但現在的網絡帶寬也不是十年前的網絡帶寬了。
3.遇到問題多溝通多交流， 感謝主管，我的舅舅還有以前的同事給我在這個問題上的幫助。
關於編碼的問題可以戳資料：http://www.cnblogs.com/ahulovey/archive/2010/08/20/1804327.html