UTF-8 garbled problem in ASP

UTF-8 garbled problem in ASP
1, <% @ codePage = "65001" %>
2, <meta http-equiv = "Content-Type" content = "text/html; charset = UTF-8">
3, session. codePage = 65001
4, the file is saved as a UTF-8

After all the above attempts, the Information read from the database will still be garbled frequently (and sometimes it will be normal );
Why is it because all the information read from the database is garbled;
The Access database has been converted to traditional Chinese;

Searching...

========================================================== ======================

If there is a false message on the Internet, it cannot be solved ????

Or first let's talk about the solution, each external display of the screen must be added, especially for the UTF-8 encoding:
<% @ Language = "VBScript" codePage = "65001" %>
<% Response. charset = "UTF-8" %>
<% Session. codePage = 65001%>
<Meta HTTP-EQUIV = "Content-Type" content = "text/html; charset = UTF-8"/>

Files are saved as UTF-8 encoding formats;
========================================================== ======================

Solution to ASP coding problems in 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 assigned immediately (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!

 

In addition, UTF-8 encoding causes Chinese garbled characters output by Js.

 

If the encoding rules of the Web application are UTF-8, such:
<Meta http-equiv = "Content-Type" content = "text/html; charset = UTF-8"/>
If the JS file contains Chinese output, garbled characters will appear, to solve this problem, add charset = "gb2312" or charset = "big5" (assuming big5 traditional Chinese characters are output) to the reference of JavaScript output ).

Example:
<SCRIPT type = "text/JavaScript" Language = "JavaScript" src = "scripts/output. js" charset = "gb2312"> </SCRIPT>

PS: Another solution is to save the JS file as UTF-8 encoded.
If the encoding rules of the Web application are UTF-8, such:
<Meta http-equiv = "Content-Type" content = "text/html; charset = UTF-8"/>
If the JS file contains Chinese output, garbled characters will appear, to solve this problem, add charset = "gb2312" or charset = "big5" (assuming big5 traditional Chinese characters are output) to the reference of JavaScript output ).

Example:
<SCRIPT type = "text/JavaScript" Language = "JavaScript" src = "scripts/output. js" charset = "gb2312"> </SCRIPT>

PS: Another solution is to save the JS file as UTF-8 encoded.