近期給客戶發了一些調研的郵件，希望能借由郵件瞭解用戶對於網站一些重要功能的需求，後續還會對部分用戶進行進一步的調研，糾結的是該調研系統是外部系統，如果我們需要將調研結果精確到人的話就需要向它傳遞一個類似id的唯一標識，如果傳遞email或者用戶id會涉及到數據泄露和法律問題，如果傳遞一串數字id，就需要對每封郵件生成id並記錄下來，成本有點高，所以最終決定將用戶標識加密傳遞給外部系統，第一次調研後我根據調研結果文件解密一切正常，只有一個數據沒有解密成功，我也沒太在意。第二次調研後，我被告知，該結果需要當天完成好向高層彙報讓我趕緊弄出來，於是會沒開完我就離席了，本想應該很輕鬆，但這次居然只解析出40％左右的數據，其他數據都不太正常，具體表現就是部分數據雖然解析出來，但是頭尾會帶亂碼，或者就是完全亂碼。
理論上來說，如果在加密解密過程中出現問題，絕大多數的結果應該都是亂碼，問題出現，首先回顧一下整個數據流轉的過程
1. 數據被edm系統加密，然後對url encoding（utf-8），最終郵件通過發送系統推送到用戶郵箱
2. 用戶在客戶端打開郵件，看到調研鏈接，點擊鏈接，在客戶機瀏覽器打開鏈接，訪問到調研系統
3. 調研系統解析到傳遞過來的唯一標識，保存並記錄當前用戶調研結果
4. 調研結果導出到excel文件
5. 將excel文件中加密的唯一標識寫入txt文件，並讀取，解密
先考慮最簡單的情況，也就是第五步將excel中的唯一標識copy到txt文件的過程是否有額外字符的拷貝，或excel本身就加入了額外字符，經過排查，不是該原因，期間想通一件事，就是解析結果有40％的正確率是由於加密過程中撒了鹽，所以間接證明了祕文並未完全失真，可能只有很少的部分信息是錯誤的導致有部分數據能夠被解析出來，順着這個思路繼續想，把問題定位到第一步，url encoding部分，由於我們採用了utf-8作爲encoding參數，而調研系統的decoding charset未知，所以是否由於兩個字符集對於密文中部分字符的編碼結果不一致導致呢，結果發現除了utf16會導致結果不一致以外（ascii不兼容字符集），其他字符集decode都沒問題（都是ascii兼容字符集），於是我回過頭仔細分析了第一次的調研結果和第二次的調研結果，悲情的發現，第二次的調研結果裏唯一標識符居然出現了空格，而且第一次調研結果失敗的那條記錄裏也有空格，考慮到加密結果是base64編碼的基本模式，所以猜測應該將空格替換爲那個該死的加號，解密終於成功了。。。。問題是，爲啥會出現空格，對加密結果是做過url encoding的，加號會被替換爲％2B，根據相關的協議，是不會反解析爲空格的(http://www.w3.org/TR/html5/association-of-controls-and-forms.html#url-encoded-form-data)，如果沒有url encoding ，base64編碼後可能會在url裏出現加號，最後decoding的時候變成空格。。
爲啥正確的做法還是會有問題呢，問題出現在郵件客戶端的可能性很小，因爲客戶的郵箱各式各樣，更有可能的一種問題是double decoding造成，加號encoding一次，decoding兩次變成了空格，杯具～查了很久都沒注意到空格，要不應該可以很快恢復數據，現階段很難猜測對方服務器爲什麼在近期出現double decoding問題，如果後續繼續出現問題只能去聯繫對方問問看了。