Recently, the company has a Japanese project. Since it used to use the Chinese CMS developed by itself and did not separate the language packages, it encountered a headache-inducing garbled problem during the website construction and debugging process.
The reason for garbled code
Since the storage space of each character encoding is different, when different characters are used to read data, when the character space is too small, it cannot be displayed normally.
For example, the character set of Chinese characters is generally gb2312. If you use utf-8 to force read and change the characters of gb2312, there may be garbled code. Because the storage space of utf-8's character set is greater than gb2312, when reading using utf-8, some characters gb2312 do not exist in the encoding, and non-existent characters will naturally appear garbled. For static files, if the storage encoding of the file is inconsistent with the encoding settings (charset) in the web page, garbled code will occur due to the above reasons.
The above is a simple analysis of the garbled problem, which involves the support of Asp for internationalization when solving existing problems.
Three functions involved: @CODEPAGE, Response.CodePage, Session.CodePage
Below is a passage from MSDN.
Setting@CODEPAGEexplicitlyaffectsliteralstringsinasingleresponse.Response.CodePageaffectsdynamicstringsinasingleresponse, and Session.CodePageaffectsdynamicstringsinasingleresponse.
All three functions can set the encoding of asp, where @CODEPAGE is equivalent to the header in php and must be issued at the beginning of the document.
In the IIS of the Chinese operating system, the default is gb2312, the parameter value is: "936", and the Japanese document needs to be specified CODEPAGE:
<%@CODEPAGE=932%>
We use this function to set document encoding for the specific usage method: http://www.cloudward.net/techLife/article.asp?id=490
There should be no problem now, right? Wow, the problem still exists. Considering that all SEO company's asp programs need to generate static pages. The generated pages are all Windows' default ANSI, and they still have garbled codes containing Japanese characters. In this way, we need an asp function to generate utf-8 or Japanese-encoded files. We use the following code to complete it:
SetobjStream=Server.CreateObject("ADODB.Stream")
WithoutbjStream
.Open
.Charset="utf-8"//Encoding, here you can change it to any encoding
.Position=objStream.Size
.WriteText=pencat//pencat is the written data
.SaveToFilesserver.mappath("patch/flilename.html"), 2// Generate file path
.Close
EndWith
SetobjStream=Nothing
The problem of garbled code after testing was solved.