博客讨论了在ASP.NET2.0中通过GET参数传递BASE64编码的字节数组遇到的问题，包括特殊字符的URL编码和解码后可能出现的错误。作者发现GET参数在接收到时已经自动解码，导致“+”变为空格，并且百分号可能导致编码混乱。为了解决这个问题，需要对获取的参数进行额外处理。总结了URL编码的复杂性和需要注意的事项，强调在处理编码和解码时要格外谨慎。
最近在 ASP.NET 2.0 中，需要将一组字节(byte[])用 GET 参数传递到另一个 .aspx 页面，采取的办法是进行 BASE64 编码。首先将 byte[] 进行 BASE64 编码(Convert.ToBase64String)，然后调用 Server.UrlEncode 进行 % 转换，因为 BASE64 里有“+”、“=” 等特殊字符。
在传递过去之后，发现转码后有百分号出现的请求都会失败。于是检查，最后发现有两个“意外”：一、获取到的 GET 参数，已经是 % 解码后的了；二、解码后的“+”进一步被解成了空格“ ”。不得以，只有对获取的 GET 参数字符串进行空格到“+”的替换，然后用 Convert.FromBase64String 解码正常。
对 URL 中的 % 进行处理，需要几分小心，因为很难知道编码前的 % 是否需要再次编码，同时也很难知道解码后的 % 是否需要再次解码。这里有一个缺陷就是，百分号本身并不能指示它是数据还是转义字符。一个编码过的百分号，经过再次编码，就可能变成“%25”，而解码的时候，就需要两次解码才行。
这样的问题在各种“转义字符”中都存在，HTML 中的表示字符“&”的“&”，可能变成 &。二次编码可能是需要的，但是却不能避免二次编码一定是正确的，尤其当编码前字符串来路不明的时候。
转义似乎是必须的，但是也是麻烦的，无赖，只有小心。
阅读(10248) | 评论(0) | 转发(0) |
230
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
