The solution to the Chinese garbled code in js url value transfer

 

	function exportBasicInfo(){
			var name=$("#username").val();
			var area=$("#area").val();
				layer.confirm('Are you sure you want to export basic information?', {
					title:false,
				    btn: ['export', 'cancel']
					}, function(index, layero){
			window.location.href="<%=basePath%>../exportBasicInfo.jsp?name="+encodeURI(encodeURI(name))+"&area="+encodeURI(encodeURI(area));
						layer.close(index);
					});
		};

 Why do some people on the Internet propose to repeat the encoding of the string twice on the client side?

If it is not possible to specify which encoding rule the container uses to decode the submitted parameters due to project requirements, for example, when you need to receive parameter content that is not encoded in different pages. (Or the developers are confused by this somewhat complicated stuff and don't know how to do the job of receiving parameters correctly.)
At this time, the secondary encoding of the parameters on the client side can effectively avoid " Submitting Multibyte Characters ".
Because of the first encoding, your parameter content does not contain multi-byte characters and becomes a pure Ascii string. (Here, the result of the first compilation is called [ STR_ENC1 ] Okay. [STR_ENC1] does not contain multi-byte characters.)
After editing it again, submit it, and the container will automatically solve it once when receiving (the container will automatically solve this time , whether it is GBK or UTF-8 or ISO-8859-1, it can get [STR_ENC1] correctly)
and then implement decodeURIComponent in the program (usually java.net.URLDecoder(*** , "UTF-8")) to get the original value of the parameter you want to submit.

 

Receiving end:

	String area = request.getParameter("area");
	area = URLDecoder.decode(area,"UTF-8");
	String name = request.getParameter("name");
	name = URLDecoder.decode(name,"UTF-8");

 

Required packages <%@page import="java.net.URLDecoder"%>