[The]asp.net URL contains a solution that causes garbled characters in Chinese parameters.

This article transferred from: http://www.jb51.net/article/22437.htm

Problem:
Some time ago, in the system to do a similar link to the function block, has been running well, until one day added a similar to the following link address: http://www.****.com/user.aspx?id= water days, there is a big problem:
1, from the IE Address bar directly enter this address, access is right; 2, do a static page, including this hyperlink, click to visit is also true;
3, is to add this link to this function block, click to access the received is garbled.
At first, by this problem also made a big head, after Google A, finally is the problem to figure out, in fact, as long as this link address without any code transfer is not a problem. But it is added to this function block, and then click, although this time in the IE Address bar display is still "http://www.****.com/user.aspx?id= water days", but really passed the parameters of the past "Water Day" In fact, has been similar to the operation of Server.URLEncode, of course, the default is Utf-8 encoding, it is for this reason, if the other system does not decode the corresponding, directly manipulate the parameter, the above error has occurred.
Solution: There are many solutions on the Internet, the most common is the following points: 1, in the Web. config <globalization requestencoding= "gb2312" responseencoding= "gb2312"/ This method is feasible, but I think a lot of people do not want to use this method to solve, the whole project request and response is set as gb2312, I think it is not a good way, a bit of putting the cart before the horse, after all, this will lead to a lot of other problems arise.
2. To include the ASPX document that contains the link, modify its CharSet property to gb2312. This method is also acceptable, but for the problem in this article is not the best way, because the function block can be dynamically added to any page, to modify all the pages? It's not quite right to think about it.
3, directly with Server.URLEncode and Server.decode for the overweight and decoding operation, this method for the sender and receiver are in a project is feasible, the problem is that we have to feel free to access other people's system, so we can only discard this method.
4, using Httputility.urlencode (query, System.Text.Encoding.GetEncoding ("GB2312")), the parameter values in the link gb2312 encoding, this method, The other side does not have any decoding operation, the direct receive parameter will not appear garbled.
The most commonly mentioned is the above 4 methods, the others are similar to these. After careful analysis, think the 4th method is the best solution to the current problem, the Chinese parameters such as 4 of the operation. But another problem arises, because this is a user can freely enter the link address of the function, so the first thing to do is to analyze the link URL, parse out the parameters, and then 4 of these parameters to operate, and then together to spell the original URL address.
Fortunately, the URL parameter resolution C # already has the support of the class library, no longer to write those complex regular expressions to match. Here I do not say in detail, directly post the original code:

 Public Static stringInitchineseurl (stringChineseurl) {Uri URL=NewUri (Chineseurl); System.Collections.Specialized.NameValueCollection NV= System.Web.HttpUtility.ParseQueryString (URL. Query, System.Text.Encoding.GetEncoding ("Utf-8")); stringquery ="";  for(inti =0; I < NV. Count; i++) { if(Query. Trim () = =string. Empty) {Query="?"+ NV. Keys[i] +"="+ Httputility.urlencode (Nv[i], System.Text.Encoding.GetEncoding ("GB2312")); } Else{Query+="&"+ NV. Keys[i] +"="+ Httputility.urlencode (Nv[i], System.Text.Encoding.GetEncoding ("GB2312")); } } stringU = chineseurl.split ('?')[0] +query;returnu;} 

Here I have all the parameters are gb2312 encoding operation, anyway, if the parameter is English or a number, after these operations are still unchanged.

[The]asp.net URL contains a solution that causes garbled characters in Chinese parameters.