There are generally three methods:
1. Set the Web. config file
<System. Web>
......
<Globalization requestencoding = "gb2312" responseencoding = "gb2312" Culture = "ZH-CN" fileencoding = "gb2312"/>
......
</System. Web>
2. Before passing Chinese characters, encode the Chinese parameters to be passed and decode them upon receiving them.
> Transfer
String name = "Chinese parameter ";
Response. Redirect ("B. aspx? Name = "+ server. urlencode (name ));
> Receive
String name = request. querystring ["name"];
Response. Write (server. urldecode (name ));
3. If a Chinese parameter is transferred from the. html file to the. aspx file (that is, URL conversion is not performed using the Redirect () method from the background ). Similarly, the passed Chinese parameters must be encoded and decoded upon receiving.
> Transfer
<Script language = "JavaScript">
Function gourl ()
{
VaR name = "Chinese parameter ";
Location. href = "B. aspx? Name = "+ escape (name );
}
</SCRIPT>
<Body onclick = "gourl ()">
> Receive
String name = request. querystring ["name"];
Response. Write (server. urldecode (name ));
In general. Set the Web. config file. However, if you use JavaScript to call the WebService method (passing Chinese parameters to WebService ). The Web. config file is invalid.
Or use
Response. Redirect ("test1.aspx? 111 = "+ system. Web. httputility. urlencode (" People's Republic of China "); // recommended
Problems related to URL Chinese processing in ASP. NET Author: sand child 14:38:14
The character encoding problem of ASP. NET is really a headache. Chinese characters are prone to various garbled characters, and these garbled characters are ultimately caused by mismatched encoding methods.
Because Chinese characters are often required to pass parameters between different pages through URL strings, they must be encoded and decoded; otherwise, the transmitted parameters are incorrect.
Generally, server. urlencode and server. urldecode can be used to solve the problem, but some special situations may occur:
Set the following global configuration for a component.
<Configuration>
<System. Web>
<! -- Globalization This section sets the applicationProgramGlobal settings. -->
<Globalization
Fileencoding = "gb2312"
Requestencoding = "gb2312"
Responseencoding = "UTF-8"
/>
</System. Web>
</Configuration>
However, requestencoding = "gb2312" makes it impossible for the Chinese characters transmitted by the URL to be correctly encoded and decoded through server. urlencode and server. urldecode. Therefore, we had to use the custom encoding and decoding scheme:
/// <Summary>
/// Encoding
/// </Summary>
/// <Param name = "code_type"> </param>
/// <Param name = "code"> </param>
/// <Returns> </returns>
Static Public String encodebase64 (string code_type, string code)
{
String encode = "";
If (code_type = NULL)
{
Code_type = "Unicode ";
}
If (code! = NULL & code. length> 0)
{
Byte [] bytes = system. Text. encoding. getencoding (code_type). getbytes (CODE );
Try
{
Encode = convert. tobase64string (bytes );
}
Catch
{
// Encode = code;
}
}
Return encode;
}
/// <Summary>
/// Decoding
/// </Summary>
/// <Param name = "code_type"> </param>
/// <Param name = "code"> </param>
/// <Returns> </returns>
Static Public String decodebase64 (string code_type, string code)
{
String decode = "";
If (code_type = NULL)
{
Code_type = "Unicode ";
}
If (code! = NULL & code. length> 0)
{
Try
{
Decode = encoding. getencoding (code_type). getstring (convert. frombase64string (CODE ));
}
Catch (exception ex)
{
// Console. Write (ex. Message );
// Decode = code;
}
}
Return decode;
}
In this way, the Chinese character can be changed to base64 to avoid being ASP. net error conversion, but the problem is found after the actual operation: the base64 Code contains the plus sign + after ASP. after passing. net, the + will be converted to a space, resulting in the destruction of the base64 string.
Therefore, we consider using server. urlencode again After encoding with encodebase64 (matching decoding is also carried out). This solves the problem!
Although it has been encoded twice, the efficiency is very low, but it is also a special case :)
thanks: http://blog.csdn.net/zero8500/archive/2008/05/07/2411407.aspx