為了這個問題,我仔細的看了自己的WebService的解密方式,也確認了與客戶當初所說的一致
但客戶給了SampleCode裡的加解密方式,當初是原封不動的加入程式再呼叫而已...問題出在哪?
為此問題找了一下解答,才發現,
是客戶"加密後的資料",雖用同一支SamlpeCode加密而成,但並未使用HttpUtility.HtmlEncode(),導致好死不死的,加密後的資料有20%3d%3d,
而在WebService裡又使用HttpUtility.HtmlDecode()先轉譯,導致20的部份轉譯成"空白",
傳入SamlpeCode裡解密時,造成64bit長度不符的Exception
(好笑的是我花了兩個小時才發現,之前用debug的方式在找,都看不出來,
直到貼到notepad上才看到~昏倒)
為此找個一些資料做整理,原始出處於URL Encoding
"Reserved characters" | |||||||
Why: | URLs use some characters for special use in defining their syntax. When these characters are not used in their special role inside a URL, they need to be encoded. | ||||||
Characters: |
|
"Unsafe characters" | |||||||||||||||||||||||||
Why: | Some characters present the possibility of being misunderstood within URLs for various reasons. These characters should also always be encoded. | ||||||||||||||||||||||||
Characters: |
|
看到了嗎?就是因為出現"20"導致Decode時,將之轉成"空白"~真是冤忘阿!!
哈哈~要來去跟客戶請錢了,竟然害我做白工~~
以上
沒有留言:
張貼留言