I was told today that a page is garbled. As a result, the Chinese characters are passed in through URL parameters. server. urlencode () encoding is used before the input. It seems that there is no problem.
A little strange. When a breakpoint is set, I wrote the following statement for testing during monitoring:
Server. urldecode (server. urlencode ("in "))
It's garbled ......
No! I felt lost for a moment, but soon I guessed the problem. It must be the impact of some encoding command. So I opened the front-end of the page and checked its page command, see a codePage = "936", delete it, and try again.
For this phenomenon, I guess they all use UTF-8 encoding by default, but if other encoding methods are explicitly specified on the front end, the characters are encoded in the manually specified encoding method. However, UTF-8 is still used in decode, leading to garbled characters.
To verify this guess, I decompiled system. Web. dll and looked at its implementation. Unfortunately, I only guessed the correct half. The encode code is as follows:
Encoding E = (this. _ context! = NULL )? This. _ context. response. contentencoding: encoding. utf8;
Return httputility. urlencode (S, e );
Decode code:
Encoding E = (this. _ context! = NULL )? This. _ context. Request. contentencoding: encoding. utf8;
Return httputility. urldecode (S, e );
It seems that the mandatory UTF-8 is only a backup. In monitoring, check the contentencoding of request and response when codePage is 936:
+ Request. contentencoding {system. Text. utf8encoding}
+ Response. contentencoding {system. Text. dbcscodepageencoding}
No wonder there will be garbled characters. After codePage is specified, the request and response encoding are different ......