공식 정보만큼 권위 있는 정보는 어디에도 없습니다. 오늘 마침내 MSDN에서 ASP 인코딩 문제에 대한 해결책을 찾았습니다.
다음은 MSDN에서 발췌한 내용입니다.
@CODEPAGE를 설정하면 단일 응답의 리터럴 문자열에 명시적으로 영향을 미치며, Response.CodePage는 단일 응답의 동적 문자열에 영향을 미치고 Session.CodePage는 세션의 모든 응답에 있는 동적 문자열에 영향을 줍니다.
이 문장은 각각 @CODEPAGE, Response.CodePage 및 Session.CodePage의 기능을 명확하게 설명합니다.
@CODEPAGE는 파일의 const blogname="my home"과 같은 모든 정적 문자열에 대해 작동하고
, Session.CodePage는 <%=blogname%>와 같은 모든 동적으로 출력 문자열에 대해 작동합니다
. 요점은 Response.CodePage의 범위가 단일 응답인 반면 SXNA에 선언된 Session.CodePage의 범위는 세션의 모든 응답이라는 것입니다.
다른 문장을 보세요.
Response.CodePage가 페이지에 명시적으로 설정되지 않은 경우 Session.CodePage에 의해 암시적으로 설정됩니다. 세션이 활성화되지 않은 경우 @CodePage가 페이지에 있으면 Response.CodePage는 @CodePage에 의해 설정됩니다. 페이지에 @CodePage가 없으면 AspCodePage 메타베이스 속성에 의해 Response.CodePage가 설정됩니다. AspCodePage 메타베이스 속성이 설정되지 않거나 0으로 설정되면 Response.CodePage는 시스템 ANSI 코드 페이지에 의해 설정됩니다.
언뜻 보기에 이 문장은 다음과 같은 의미로 이해되었습니다. 세션이 활성화되었을 때 Response.CodePage가 선언되지 않은 경우 Response.CodePage는 Session.CodePage에 의해 할당됩니다. 세션이 활성화되지 않은 경우 @CodePage가 선언된 경우 @CodePage에 의해 Response.CodePage가 할당됩니다.
이 문장은 SXNA에서 나온 후 이유를 설명합니다
.다른 프로그램에서는 Response.CodePage를 선언하지 않고 SXNA에서는 Session.CodePage를 선언하기 때문에 oblog, z-blog 등과 같은 다른 페이지에서는 SXNA를 입력하자마자 Session.CodePage에 즉시 값이 할당됩니다(다른 값). 어떤 버전은 936, 어떤 버전은 65001이 할당되어 있고, 다른 프로그램에 진입하면 Response.CodePage의 코드가 페이지 자체의 코드와 다를 경우에는 즉시 Response.CodePage가 할당됩니다. , 페이지가 깨집니다. 그래서 z-blog 진입시 깨진 문자가 나오는 경우 Session.CodePage, Response.CodePage가 모두 936인 것을 확인하였고, oblog 진입 시 깨져있는 문자가 나타나는 경우 Session.CodePage, Response.CodePage가 모두 65001인 것을 확인하였습니다. 즉, 리프 표면을 보장하려면 잘못된 코드가 없으면 Response.CodePage를 선언해야 합니다. 그렇지 않으면 @codepage에 따라 웹 페이지를 해석하는 대신 Session.CodePage에 따라 웹 페이지를 해석합니다
. 위의 설명을 따라가면 사실 매우 혼란스럽습니다. 왜냐하면 우리 모두가 중국 운영체제이기 때문입니다. 브라우저에 들어갈 때마다 Session.CodePage를 출력해 보면 936이라는 것을 알 수 있습니다. Z-blog에 들어갈 때 기본 Session.CodePage 936을 Response.CodePage에 할당하지 않은 이유는 무엇입니까? 대신 @CodePage를 Response.CodePage에 제공하시겠습니까? 어떤 상황에서 Session.CodePage를 Response.CodePage에 할당해야 합니까? "세션이 활성화되었습니다"라는 원문을 어떻게 이해해야 합니까?
아마도 위의 단어는 다음과 같이 이해되어야 합니다.
어떤 프로그램에서 Session.CodePage가 선언될 때 Response.CodePage가 선언되지 않으면 Session.CodePage에 의해 Response.CodePage가 할당됩니다. 어떤 프로그램에서도 Session.CodePage가 선언되지 않은 경우 @CodePage가 선언된 경우 Response.CodePage에는 @CodePage...에 의해 값이 할당되고 페이지의 최종 동적 콘텐츠 부분은 해당 값에 따라 해석됩니다. Response.CodePage.
Zblog와 Oblog는 모두 @CodePage를 선언하므로 사용자가 컴퓨터를 막 시작한 다음 브라우저에 들어가 Zblog와 Oblog를 탐색하면 Response.CodePage에 @CodePage에 의해 값이 할당되므로 리프 표시가 정상입니다.
이 문장에서는 잘못된 문자의 원인을 자세히 설명합니다.
Response.CodePage 또는 Session.CodePage를 명시적으로 설정한 경우 리터럴이 아닌 문자열을 클라이언트에 보내기 전에 이를 수행하십시오. @CODEPAGE의 코드 페이지가 Response.CodePage의 코드 페이지와 일치하거나 리터럴 문자열이 리터럴이 아닌 문자열과 다르게 인코딩되어 잘못 표시됩니다.
더 유용한 문장 중 하나는 Response.CodePage와 @CODEPAGE가 다르면 잘못된 문자가 생성된다는 것입니다. 즉, Z-blog의 @CODEPAGE=65001 및 Z-blog의 Response.CodePage가 Session.CodePage에 의해 936으로 할당되면 왜곡된 문자가 나타나고, oblog의 경우 그 반대가 됩니다.
위의 설명이 충분히 명확한지 모르겠습니다. -_-||
SXNA가 때때로 Session.CodePage를 936에 할당하는 이유를 설명하겠습니다. 다음과 같이 쓰는 버전이 있습니다:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
사용자가 브라우저에 들어가면 Session.CodePage의 기본값은 936입니다. 이때 기본값 936은 프로그램에서 선언되지 않으므로 Response.CodePage에 할당되지 않습니다. SXNA에 들어가면 위의 내용에 의해 Session.CodePage가 전달됩니다. 프로그램에서 선언한 Session.CodePage=936이 되기 때문에 다시 Zblog에 들어가면 Response.CodePage에 936이 주어집니다.
지금까지 모든 이유를 명확하게 분석했습니다.
따라서 asp 리프가 왜곡되어 표시되지 않도록 하는 코드는 다음과 같아야 합니다. (UTF-8 리프라고 가정)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. 문자 집합 ="UTF-8" %>
Response.Charset을 추가해야 하는 이유를 더 설명해주세요. MSDN에서 추가해야 한다고 하더군요... ㅎㅎ
페이지에 코드 페이지가 설정되어 있으면 Response.Charset도 함께 설정되어야 합니다.
또한
웹 페이지의 파일 형식은 페이지에 사용된 @CODEPAGE와 동일해야 합니다.
이것이 zblog 및 pjblog와 같은 일부 프로그램이 UTF8 인코딩 형식으로 파일을 저장해야 하는 이유입니다.
요약하면 모든 프로그램이 Response.CodePage를 선언하면 Session.CodePage의 방해를 받지 않고 문자가 깨질 수 있습니다. 따라서 Session.CodePage는 여전히 쉽게 사용할 수 없습니다!
참조 기사: