IIS는 ASP 파일을 찾아서 처리 등을 위해 ASP 엔진(보통 ASP.DLL)에 제출합니다. 먼저 ASP 페이지 실행 과정을 이해해 보겠습니다.
1. IIS는 ASP 파일을 찾아 처리를 위해 ASP 엔진(일반적으로 ASP.DLL)에 제출합니다.
2. 엔진은 ASP 파일을 열고 <%와 %> 사이의 내용을 찾습니다. 물론 <script runAt=server>와 해당 </script> 사이의 내용을 스크립트 블록이라고 합니다. 엔진은 스크립트 블록에 있는 내용만 파싱하고, 그 외의 내용은 무시하고 스크립트 블록 사이에 의미 없는 문자로 삽입합니다. 실제로 파싱되는 내용은 이보다 더 많다는 점을 설명할 필요가 있습니다. <!--#include ***--> 클래스의 서버측 포함 파일도 엔진에 포함되어 처리됩니다. 많은 프로그램을 읽어보면 runAt 속성이 Server로 표시된 일부 <object> 개체도 처리된다는 사실을 알 수 있습니다.
3. 엔진은 스크립트 블록의 스크립트를 실행합니다. 즉, 다음 코드를 작성할 수 있습니다.
다음과 같이 코드 코드를 복사합니다.
<%
나는 어둡다
i=1~5인 경우
%> 안녕하세요!
<% 다음 %>
엔진은 이러한 스크립트 블록을 별도로 구문 분석하지 않으므로 두 스크립트 블록 모두에서 구문 오류가 발생합니다. 따라서 우리는 다음과 같은 결론에 도달합니다. 모든 비서버 스크립트 코드가 클라이언트로 전송되는 것은 아닙니다. 이 비서버 스크립트 코드는 스크립트 블록에 의해 제한될 수 있습니다. 서버는 클라이언트 스크립트 실행에 대해 전혀 걱정하지 않지만 서버측 스크립트를 통해 다양한 클라이언트 스크립트를 출력할 수 있습니다.
4. 마지막으로 엔진은 클라이언트 브라우저로 전송되는 웹 페이지의 코드인 문자열로 간주될 수 있는 텍스트 스트림 또는 스크립트의 실행 결과를 생성합니다. 클라이언트 브라우저는 페이지를 표시합니다. 이때 페이지의 소스 코드(소스 파일)에는 서버 측 스크립트가 포함되어 있지 않지만 서버 측 스크립트의 실행 결과가 포함되어 있습니다(이것은 당연합니다).
<% … %> 및 <script runat=server>…</script>
이는 모두 동시에 처리되고 실행되는 서버측 스크립트입니다. 그들은 하나의 단위로 활동합니다.
<% … %> 및 <스크립트 언어=…>…</script>
전자는 서버측 스크립트이고 후자는 클라이언트측 스크립트입니다. 전자가 먼저 실행되고 후자가 나중에 실행됩니다.
실제로 두 스크립트가 동시에 실행될 수도 있지만 공백은 다릅니다. 전자는 서버에서 실행되고 후자는 서버에서 실행됩니다. 클라이언트 브라우저. 전자는 논리적으로 후자보다 먼저 실행되어야 합니다. 동시에 우리는 동일한 페이지를 실행하는 동안 어떤 경우에도 클라이언트측 스크립트가 서버측 스크립트에 피드백할 수 없다는 결론에 도달했습니다. 즉, 클라이언트는 방명록을 탐색하고 제출합니다. 새 메시지나 클라이언트 측 스크립트에서 얻은 값은 모두 동일한 서버 응답에서 처리될 수 없습니다.
구성 요소 호출 정보
서버 측 스크립트와 클라이언트 측 스크립트는 모두 스크립트이므로 당연히 xmlhttp 구성 요소, ADODB.Connection 구성 요소 등을 만들 수 있지만 어디에도 배치할 수는 없습니다.
xmlhttp가 서버에서 웹 페이지(컬렉션 등)를 크롤링하는 데 사용되는 경우 클라이언트의 Ajax가 새로 고치지 않고 백그라운드에서 서버 측 페이지에 액세스하는 데 사용되는 경우 서버 스크립트에서 생성되어야 합니다. 클라이언트에서, 자연스럽게 클라이언트에서 마지막에 생성됩니다.
ADODB.Connection 구성 요소는 데이터베이스에 액세스하는 데 사용됩니다. 일반적으로 이는 서버 측에서 생성됩니다. 그러나 데이터베이스가 실제로 클라이언트에 연결되어 있는 경우에는 서버 측 ASP 프로그램입니다. 클라이언트 측에서 생성된다는 것은 의심의 여지가 없습니다.
요컨대, 모순되는 것, 각 측면에는 고유한 특성이 있습니다. 서로 다른 사물은 서로 다른 모순을 가지고 있습니다. 동일한 사물은 서로 다른 프로세스와 개발 단계에서 서로 다른 모순을 가지며, 동일한 모순의 두 가지 다른 측면은 각각 고유한 특성을 가지고 있습니다. (이해하지 못하는 사람은 생략할 수 있습니다.) 보지마…). 이 원칙은 우리가 구체적인 문제에 대한 구체적 분석의 원칙을 견지하고, 모순의 보편성의 원칙에 따라 모순의 특수성을 구체적으로 분석하고 이를 해결하는 올바른 방법을 찾을 것을 요구합니다. 우리는 서로 다른 사물의 모순을 해결하기 위해 하나의 방법을 사용하는 것에 반대합니다. 이것은 열쇠로 자물쇠를 열고 어느 산에 가든지 어떤 노래를 부르든 뜻하는 바입니다.
서버측 VBScript 스크립트는 Server.CreateObject(className) 메서드를 사용하여 개체를 만들고, 클라이언트측 VBScript 스크립트는 CreateObject(className) 메서드를 사용하여 개체를 만듭니다.
일반적인 오류
다음과 같이 코드 코드를 복사합니다.
<%
함수TSize(b)
'이것은 내 맞춤 기능입니다.
T크기=중국
종료 기능
%>
<a href=javascript:<%TSize('Variable')%> >내가 정의한 함수를 사용하려면 여기를 클릭하세요</a>
오류 분석:
서버 측 스크립트와 클라이언트 측 스크립트의 차이점을 혼동합니다. 실제 실행 중에 클라이언트는 TSize와 같은 코드를 전혀 수신하지 않는다는 것을 알게 됩니다. 왜냐하면 TSize는 엔진에 의해 처리되는 서버 측 프로그램이기 때문입니다(엔진의 함수 처리는 순전히 서버 측 스크립트를 위한 것임을 참고하세요). 호출하고 클라이언트로 다시 전송되지 않음)이 사라지고 클라이언트에서 작동할 수 없습니다. 이는 클라이언트 측 스크립트가 서버 측 스크립트의 기능을 직접 호출할 수 없음을 의미합니다.
실제로 이 프로그램에는 구문 오류가 있습니다. 엔진이 이 콘텐츠를 처리할 때 먼저 <%와 %> 사이의 콘텐츠, 즉 <%TSize('variable')%>를 찾습니다. VBScript 구문 규칙을 사용합니다. 뭐, <%=TSize(variable)%>로 변경하면 서버측 스크립트에서는 구문 오류가 발생하지 않을 것입니다. 이때 TSize 함수는 정상적으로 China 값을 반환할 수 있으므로, 에서 받은 href 속성은 다음과 같습니다. 클라이언트는 다음과 같이 작성됩니다: javascript: China, is unenforceable.
서버측 스크립트가 클라이언트측 스크립트에 미치는 영향
앞에서 언급했듯이 서버측 스크립트는 클라이언트측 스크립트보다 먼저 논리적으로 실행되므로 다음과 같은 코드가 가능합니다.
다음과 같이 코드 코드를 복사합니다.
<%
나는 어둡다
i=1~5인 경우
응답.쓰기 <스크립트 유형=텍스트/자바스크립트> _
& Alert('Hello World! & i & ')</script>
다음
%>
Response.Redirect 및 javascript 실행에 대해
다음 코드는 잘못 작성되었습니다.
다음과 같이 코드 코드를 복사합니다.
<%
응답.리디렉션 index.asp
응답.쓰기 <스크립트 유형=텍스트/자바스크립트> _
& Alert('비밀번호가 틀렸습니다!')</script>
%>
이는 흔히 발생하는 실수입니다. 이러한 방식으로 코드를 작성하면 클라이언트에서 암호 오류 메시지가 표시되고 index.asp로 리디렉션될 것이라고 생각하는 경우가 많습니다. 코드가 교환되면 이러한 효과를 얻을 수 없습니다.
그 이유는 서버가 두 줄의 코드를 처리하는 방식과 관련이 있습니다. 이 두 줄의 코드가 동시에 작동하는 것은 불가능합니다.
Response.Write는 클라이언트에 텍스트를 보내는 것입니다. 이 텍스트의 내용은 스크립트일 수 있습니다. 그러면 클라이언트 브라우저는 이를 받은 후에만 스크립트를 실행할 수 있습니다.
Response.Redirect는 클라이언트에 HTTP 헤더를 보냅니다(HTTP 헤더란 무엇입니까? 이렇게 표현하겠습니다. 예를 들어 클라이언트 쿠키에 쓰는 것은 HTTP 헤더 정보이고, HTTP 헤더 정보는 HTTP 본문 브라우저보다 먼저 클라이언트로 다시 전송됩니다. , 서버의 버퍼링을 끈 후 쿠키를 수정할 때 때때로 오류가 발생하는 이유는 본문이 이미 전송을 시작했고 HTTP 헤더 전송이 허용되지 않기 때문입니다. 정보), 정보의 내용은 탐색할 페이지로 이동해야 함을 클라이언트 브라우저에 알려줍니다. 즉, 이 리디렉션 정보는 버퍼가 켜져 있을 때 배타적입니다. Response가 사용되었는지 여부. .Write는 버퍼에 기록되는 콘텐츠의 양을 기록합니다. Response.Redirect가 호출되면 버퍼가 지워지고 이 헤더 명령이 클라이언트 브라우저로 전송됩니다. 프로그램 실행을 동적으로 추적하면 Response.Redirect를 호출한 후 프로그램이 실행을 중지한다는 사실도 알 수 있으므로 서버 측 프로그램은 Response.Redirect를 호출하기 전에 데이터 연결 및 기타 작업을 닫아야 한다는 점에 유의하세요.
그렇다면 위의 예는 어떻게 수정되어야 할까요? 스크립트 프롬프트를 추가하기 위해 index.asp를 수정하고 싶지 않은 경우 다음과 같이 클라이언트 스크립트에서 리디렉션 명령만 실행할 수 있습니다.
다음과 같이 코드 코드를 복사합니다.
<%
응답.쓰기 <스크립트 유형=텍스트/자바스크립트> _
& 경고('!');location.href='index.asp'</script>
%>