ASP: Garbled code occurs from the utf8 page to the gb2312 page.

Yesterday I made two ASP pages, one for UTF-8 and the other for gb2312.
So there was a strange thing (mainly because I met it for the first time). Opening these two pages alone won't cause any problems,
However, garbled characters appeared when utf8 was connected to gb2312. It took two hours to get rid of it,
Open again today, Baidu has the following results.
Later I found two solutions
First, set session. codePage = 936 on each gb2312 page.
This solves the problem...
Second, do not use <A> connection when converting from utf8 to gb2312. Use response. Redirect to redirect.

In summary
Set the codePage for each page so that the encoding of each page is independent and is no longer affected by the connected page.
Secondly, <A> the tag connection will pass the page encoding attribute to the next page, but this will not happen when redirect is used.
Use the environment variables obtained by asp to get request. servervariables ("http_referer"), and the latter will not be available.

Attached
In-depth research on ASP coding and final solutions
 
Which materials are not as authoritative as official materials. Today, I finally selected a solution to the ASP encoding problem from msdn.

The following is a passage in msdn.

Setting @ codePage explicitly affects literal strings in a single response. response. codePage affects dynamic strings in a single response, and session. codePage affects dynamic strings in all responses in a session.
 

This sentence clearly explains the roles of @ codePage, response. codePage, and session. codePage.

@ CodePage acts on all static strings, such as const blogname = "my home" in a file"

Response. codePage, session. codePage act on all dynamic output strings, such as <% = blogname %>

The key to this statement is that the scope of response. codePage is a single response, and the scope of the Session. codePage declared in sxna is all responses in a session.

Let's look at another sentence.

If response. codePage is not explicitly set in a page, it is implicitly set by session. codePage, if sessions are enabled. if sessions are not enabled, response. codePage is set by @ codePage, if @ codePage is present in the page. if there is no @ codePage in the page, response. codePage is set by the aspcodepage metabase property. if the aspcodepage metabase property is not set, or set to 0, response. codePage is set by the system ANSI code page.
 

At first glance, I understand the meaning as follows: when sessions is enabled, if response. codePage is not declared, response. codePage will be assigned a value by session. codePage. If sessions are not enabled, if @ codePage has been declared, response. codePage will be assigned a value by @ codePage, and so on .............

This sentence explains why some other pages such as oblog and Z-blog are prone to garbled characters After sxna is released, because other programs do not declare response. codePage, and sxna declares the session. codePage, so when you enter sxna, session. codePage is immediately assigned a value (different versions, some versions assigned 936 and some versions assigned 65001), and then response when entering other programs. codePage is immediately session. codePage value. If response. if codePage is not encoded with the page itself, the page will be garbled. So I checked the session when I entered the Z-blog with garbled characters. codePage and response. all codepages are 936, and when the oblog is garbled, the session. codePage and response. all codepages are 65001. that is to say, to ensure that the leaves are not garbled, we should declare response. codePage, otherwise it will follow the session. codePage to interpret the webpage (instead of interpreting the webpage according to @ codePage ).

I am actually confused if I just follow the above explanation, because we all use a Chinese operating system. Every time you enter the browser, you can try to output the session. codePage, we can see that all of them are 936! Why didn't he assign 936 of the default session. codePage to response. codePage when entering Z-blog? Instead, I gave @ codePage to response. codePage? Under what circumstances will session. codePage be assigned to response. codePage? In the original article, how should sessions are enabled be understood?

Perhaps the above should be understood as follows:

When session. codePage is declared by any program, if response. codePage is not declared, response. codePage is assigned a value by session. codePage. If the session. when codePage is not declared by any program, if @ codePage has been declared, then response. codePage will be assigned a value by @ codePage ,...., the dynamic content part of the final page follows response. codePage value explanation.
 

Because zblog and oblog both declare @ codePage, when the user just starts the machine and then enters the browser to browse zblog and oblog, the response. codePage will be assigned a value by @ codePage, so the foliar display is normal.

This sentence further explains the cause of garbled characters.

If you set response. codePage or session. codePage explicitly, do so before sending non-literal strings to the client. if you use literal and non-literal strings in the same page, make sure the code page of @ codePage matches the code page of response. codePage, or the literal strings are encoded differently from the non-literal strings and display incorrectly.
 

One useful sentence is that if response. codePage is different from @ codePage, garbled code will be generated. That is to say, when the @ codePage of the Z-blog is 65001 and the response. codePage of the Z-blog is assigned to session. codePage as 936, garbled characters will occur, and the oblog and vice versa.

I don't know whether the above explanation is clear-_-|

The following explains why sxna sometimes assigns session. codePage to 936. One of my versions is written like this:

<% Originalcodepage = session. codePage %>

.......

<% Session. codePage = originalcodepage %>
 

Session when the user enters the browser. codePage is 936 by default. At this time, the default 936 is not declared by the program, so it will not be assigned to response. codePage: When sxna is entered, session. the code above changes codePage into a session declared by the program. codePage = 936. Therefore, when you enter zblog, the 936 message is sent to response. codePage.

So far, all the reasons have been clearly analyzed.

Therefore, to ensure that ASP leaves will not appear garbled code should be like this: (assuming it is the UTF-8 leaves)

<% @ CodePage = 65001%>

<% Response. codePage = 65001%>

<% Response. charset = "UTF-8" %>
 

Further explain why response. charset should be added, because msdn says it should be added...

If the code page is set in a page, then response. charset shoshould also be set.
 

In addition, the file encoding format should be the same as @ codePage:

The file format of a Web page must be the same as the @ codePage used in the page.
 

This is why zblog, pjblog, and other programs want to save files in utf8 encoding format.

In summary, if all programs declare response. codePage, it will not be disturbed by session. codePage and garbled characters will occur. So session. codePage cannot be used easily!

 

References:

Http://msdn.microsoft.com/library/default.asp? Url =/library/en-US/iissdk/html/268f1db1-9a36-4591-956b-d4249aeadcb0.asp

Http://msdn.microsoft.com/library/default.asp? Url =/library/en-US/iissdk/html/582e6f47-52eb-413e-8b5d-c99145cb61d8.asp