No information anywhere is as authoritative as official information. Today I finally found a solution to the ASP encoding problem from MSDN.
The following is a passage from 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 functions of @CODEPAGE, Response.CodePage, and Session.CodePage respectively.
@CODEPAGE acts on all static strings, such as const blogname="my home" in a file.
Response.CodePage, Session.CodePage acts on all dynamically output strings, such as <%=blogname%>.
This sentence is very The key point is that the scope of Response.CodePage is a single response, while the scope of Session.CodePage declared in SXNA is all responses in a session.
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 understood this sentence to mean this: when sessions are enabled, if Response.CodePage is not declared, Response.CodePage will be assigned by Session.CodePage. If sessions are not enabled, if @CodePage has been declared, Response.CodePage will be assigned by @CodePage, etc.......
This sentence explains why after coming out of SXNA It is easy to have garbled characters when entering some other pages such as oblog, z-blog, etc., because other programs do not declare Response.CodePage and SXNA happens to declare Session.CodePage. Therefore, as soon as you enter SXNA, Session.CodePage is assigned a value immediately (different versions, there are Some versions are assigned 936, some versions are assigned 65001), and then when entering other programs, Response.CodePage is immediately assigned by Session.CodePage. If the code of Response.CodePage is different from that of the page itself, the page will be garbled. So when garbled characters appeared when entering z-blog, I checked that Session.CodePage and Response.CodePage were both 936, and when garbled characters appeared when entering oblog, Session.CodePage and Response.CodePage were both 65001. That is to say, if I want to ensure the leaf surface If there is no garbled code, Response.CodePage should be declared, otherwise it will interpret the web page according to Session.CodePage (instead of interpreting the web page according to @codepage).
If I only follow the above explanation, I am actually very confused, because we all It is a Chinese operating system. You can try to output Session.CodePage every time you enter the browser. You can see that it is 936! Why didn't he assign the default Session.CodePage 936 to Response.CodePage when entering Z-blog? Instead, give @CodePage to Response.CodePage? Under what circumstances should Session.CodePage be assigned to Response.CodePage? How should we understand the original text "sessions are enabled"?
Perhaps the above words should be understood this way:
when Session.CodePage is declared by any program, if Response.CodePage is not declared, Response.CodePage will be assigned by Session.CodePage. If Session.CodePage has not been declared by any program, if @CodePage has been declared, Response.CodePage will be assigned a value by @CodePage..., and the final dynamic content part of the page will be interpreted according to the value of Response.CodePage.
Because both Zblog and Oblog declare @CodePage, when the user has just started the machine and then enters the browser to browse Zblog and Oblog, Response.CodePage will be assigned a value by @CodePage, so the leaf 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 of the more useful sentences is that if Response.CodePage and @CODEPAGE are different, garbled characters will be generated. That is to say, when Z-blog's @CODEPAGE=65001 and Z-blog's Response.CodePage is assigned 936 by Session.CodePage, garbled characters will appear, and vice versa for oblog.
I don’t know if the explanation above is clear enough -_-||
Let me explain why SXNA sometimes assigns Session.CodePage to 936. I have a version that writes like this:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
When the user enters the browser, Session.CodePage defaults to 936. The default 936 at this time is not declared by the program, so it will not be assigned to Response.CodePage. When entering SXNA, Session.CodePage is tossed by the above code. It becomes Session.CodePage=936 declared by the program, so when entering Zblog again, 936 is given to Response.CodePage.
So far, all the reasons have been analyzed clearly.
Therefore, the code to ensure that the asp leaf will not appear garbled should be like this: (assuming it is a UTF-8 leaf)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response.Charset ="UTF-8" %>
Further explain why Response.Charset should be added, because MSDN said it should be added... Haha
If the code page is set in a page, then Response.Charset should also be set.
In addition, the file format of a
Web page must be the same as the @CODEPAGE used in the page.
This is why some programs such as zblog and pjblog need to save files in UTF8 encoding format.
In summary, if all programs declare Response.CodePage, they will not be interfered by Session.CodePage and cause garbled characters. So Session.CodePage still cannot be used easily!
Reference article: