来看看为什么要进行urlencode

本文主要是介绍来看看为什么要进行urlencode，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

       web客户端通过http post提交数据到web服务端，其中一个字段名是content, 部分js代码如下：

    	var xmlHttp = new XMLHttpRequest();xmlHttp.open('post', 'http://localhost:8080/heheda')xmlHttp.setRequestHeader("Content-type","application/x-www-form-urlencoded")xmlHttp.send('content=' + str)

       go gin做web服务端， 一切工作的好好的。

 

      可是，实际发现，web服务端概率取不到content的内容，快速确认了一下， 比如当str="abc%"的时候，web服务端就取不到这个值。 然而，tcpdump抓包的内容显示有这个字段啊：

content=abc%

       也就是说，"abc%"的确传递到了web服务端,  怎么就取不出这个值呢？

 

       要注意：content参数在传递后， web服务端默认content参数进行了urlencode, 所以接受到"abc%"后， web服务端的gin框架对"abc%"进行urldecode,  很显然，独立的"%"服务解析出错（特殊字符）， 所以在web服务端的代码中取不到"abc%"

       那如果确实要传递"abc%"， 怎么办呢？先进行urlencode吧，对应的串是"abc%25",  此时"content=abc%25",  tcpdump抓包也能看到这个串"content=abc%25"， 而在web服务端解析出来的content的内容abc% (web服务端自动进行了urldecode后)

       

        回到题目那个问题， 为什么要urlencode呢？

        假设我们在http post请求中要传递的内容为"name1=xxx&name2=yyy", 如果xxx的内容为"lucy&key=hehe", 那么整个串就成了"name1=ucy&key=hehe&name2=yyy", 很显然，明明是两个字段，却变成了3个字段, 任何人都无法把原来的正确字段提取出来，一切都是"lucy&key=hehe"在捣鬼，所以，要对"lucy&key=hehe"进行转化，进行urlencode, 免得与"&"，"="产生冲突。

      想一下， 不进行urlencode， 而进行base64编码可以吗？当然可以，只不过，需要自己去base64解码。相比较而言，urlencode就要好很多， web服务端会自己去进行urldecode, 更爽。

 

      最后，要注意html form表单的post请求会默认进行urlencode, 可以抓包试试看。想一想，为什么要怎么做？

      简单东西， 不多说。

 

这篇关于来看看为什么要进行urlencode的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---