如：将一串参数做了base64后直接作为url的一部分发送出去了。
 

要知道base64的算法有pad，crcf的控制选项，而又很凑巧，发使用的是none，即pading部分带有crcf，

这样一个正常的参数输入，会产生类似于:
 

ancdfdsfdsfdsfsadfasfsafafdsafadsfsafasdfasdfsad

fadfdsfsd==
 

注意上面换行的地方被加了cr cf 即0a 0d.
 

这样的url通过ie出去后，ie将0a 0d 转化为%20 即空格的编码？ 这个为什么我现在还没有找到资料.
 
 

另外和我合作的服务端通知反映，他读到的参数是乱码，检查后发现是受到了+的干扰。
 

从具体来说base64中+ / 比较特殊，而/ 实际上并没有产生干扰，而+在服务端通知读取时候变成了空格，注意是空格不是%20.
 

“

 加号(+)是BASE64编码的一部分，而加号在QueryString中被当成是空格。    因此，当一个含有BASE64编码的字符串直接作为URL的一部分时，如果其中含有加号，则使用QueryString读取时，再使用BASE64解码就会发生错误。    解决的办法有两个：一是使用BASE64的字符串作为URL的一部分是，使用UrlEncode一类的函数进行编码；二是在接收BASE64字符串后，使用ReplaceAll将字符串中的空格替换成加号，然后再解码。  “
 

另外我从c端的抓包发现从c端发出的数据确实0a 0d 被替换为%20 %20发出，但是+ / 已然不变。
 

也就是说服务端必定有某个层次能够得到原始数据，而问题可能就像上面引用部分文字描述的那样，即+被querystring之类的API做了手脚比如urlencoding。