加號與空格的故事

    近期給客戶發了一些調研的郵件，但願能借由郵件瞭解用戶對於網站一些重要功能的需求，後續還會對部分用戶進行進一步的調研，糾結的是該調研系統是外部系統，若是咱們須要將調研結果精確到人的話就須要向它傳遞一個相似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問題，若是後續繼續出現問題只能去聯繫對方問問看了。