為了這個問題,我仔細的看了自己的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時,將之轉成"空白"~真是冤忘阿!!
哈哈~要來去跟客戶請錢了,竟然害我做白工~~
以上
沒有留言:
張貼留言