base64作为url后的后果

问题是这样的，我将一串参数做了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字符串后，使用Replace将字符串中的空格替换成加号，然后再解码。  "

 

 

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

 

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

 

 

另外urlencoding实际上是为了防止服务端解析时候出错，即无法还原原始内容。

1. &，即参数本身带有&

2. 服务器要求处理utf8之类的

3. ie的地址栏一般也会做类似处理，比如空格被替换

 

但是一般来说只有情况1这种