再次踩到網址參數 UrlEncode() 的坑

這篇很明顯是個提醒文，提醒自己不要慌 ~ 

之前有寫一篇 UrlEncode() 特殊字元注意事項 文章，提到 .NET 中若需要網址編碼或解碼的情境，

請使用 Uri.EscapeDataString()、Uri.UnescapeDataString() 方法，這會讓特殊字元的編碼與解碼

都會跟上業界標準...

先說結論：

• 網址參數必須要編碼及解碼，一律使用Uri.EscapeDataString()、Uri.UnescapeDataString()

• 發現網址參數來的值有特殊字串，就是有貓膩，不是忘了編碼，就是忘了解碼

今天的情境是，有個加密過的字串，被當作網址參數(QueryString) 傳遞，但接收端收到參數後，

直接解密但卻不是當時加密前的值，一開始有點驚恐，但仔細比對字串後發現了其中的貓膩

網址參數：jj1vrrPstDFhD+Vz0du

後端取得：jj1vrrPstDFhD  Vz0du

有沒有發現，後端直接取得的值，原先的加號「+」號被換成了「空格」，有了上次的經驗後，

這應該是微軟先天的設計？查一下文件，說明某些 UrlEncode 方法，會將「空格」轉成(+)，

但沒想到，若只是取得參數的值就會直接變成「空格」

以下是使用直接透過 Request.QueryString() 方法取值

所以，當然解密還原舊不會是原本的值

故正確做法該參數應該要先UrlEncode，這樣特殊字元就會有對應的編碼值

如這次，我們將「jj1vrrPstDFhD+Vz0du」字串使用 Uri.EscapeDataString() 方法來編碼

編碼後「+」號會被替換成「%2B」

而在接收端，當下取到的值就會是正常的

這坑遇到了兩次，雖然情境稍稍不同，但是處理根源差不多，特此紀錄下