IIS находит файл ASP и передает его механизму ASP (обычно ASP.DLL) для обработки и т. д. Друзья, которым он нужен, могут обратиться к нему. Сначала давайте разберемся в процессе выполнения страницы ASP.
1. IIS находит файл ASP и отправляет его на обработку механизму ASP (обычно ASP.DLL).
2. Механизм открывает файл ASP и находит содержимое между <% и %> и, конечно же, содержимое между <script runAt=server> и соответствующим </script>. Это содержимое называется блоками сценария. Механизм анализирует только содержимое блока сценария, а остальной контент игнорируется и вставляется между блоками сценария как бессмысленные символы. Необходимо объяснить, что на самом деле анализируемый контент — это нечто большее. Серверные включаемые файлы класса <!--#include ***--> также включаются и обрабатываются движком. Если вы читали много программ, вы также знаете, что некоторые объекты <object>, атрибуты runAt которых помечены как Server, также будут обрабатываться. Мы не будем обсуждать их здесь подробно.
3. Движок выполняет сценарии в блоке сценариев. Эти серверные сценарии выполняются целиком. То есть можно написать следующий код:
Скопируйте код кода следующим образом:
<%
Дим я
Для я = от 1 до 5
%> Привет, мир!
<% Следующий %>
Механизм не анализирует эти блоки скриптов по отдельности, что приводит к синтаксическим ошибкам в обоих блоках скриптов. Итак, мы приходим к следующему выводу: не весь несерверный код скрипта будет отправлен клиенту. Возможно, этот несерверный код скрипта ограничен блоком скрипта. Сервер точно не будет беспокоиться о выполнении клиентских скриптов, но может выводить разные клиентские скрипты через серверные скрипты.
4. Наконец, движок генерирует текстовый поток или результат выполнения скрипта, который можно рассматривать как строку, представляющую собой код веб-страницы, отправленный в клиентский браузер. Клиентский браузер отображает страницу. В это время исходный код (исходный файл) страницы не содержит серверного сценария, но содержит результат выполнения серверного сценария (это очевидно).
<% … %> и <script runat=server>…</script>
Все это серверные сценарии, которые обрабатываются и выполняются одновременно. Они действуют как единое целое.
<% … %> и <script Language=…>…</script>
Первый — это скрипт на стороне сервера, а второй — скрипт на стороне клиента. Первое выполняется первым, а второе — позже.
На самом деле это не обязательно так. Два сценария могут выполняться одновременно, но пробелы все равно разные: первый выполняется на сервере, а второй — на сервере. клиентский браузер. Первое логически должно быть выполнено раньше, чем второе. В то же время мы также пришли к выводу: во время выполнения той же страницы клиентский скрипт ни в коем случае не может связаться с серверным скриптом. То есть клиент просматривает вашу гостевую книгу и отправляет данные. новые сообщения или любое значение, полученное сценарием на стороне клиента, не могут быть обработаны в одном и том же ответе сервера.
О вызовах компонентов
Обратите внимание, что сценарии на стороне сервера и сценарии на стороне клиента являются сценариями. Естественно, вы можете создавать компоненты xmlhttp, компоненты ADODB.Connection и т. д., но их нельзя размещать где-либо.
Если xmlhttp используется для сканирования веб-страниц (например, коллекции) с сервера, он должен быть создан в серверном скрипте. Если он используется для ajax клиента для доступа к серверной странице в фоновом режиме без обновления, он запускается. на клиенте, и естественно на клиенте Создается в конце.
Компонент ADODB.Connection используется для доступа к базе данных. Вообще говоря, он создается на стороне сервера. В конце концов, это серверная программа asp, которая запускает данные базы данных. Но если ваша база данных действительно подключена на клиенте. стороне, то нет сомнений, что он будет создан на стороне клиента. Создан в клиентском скрипте.
Короче говоря, вещи противоречивые и каждая сторона имеет свои особенности. Разные вещи имеют разные противоречия; одно и то же имеет разные противоречия в разных процессах и стадиях развития; разные противоречия в одном и том же и два разных аспекта одного и того же противоречия имеют каждый свои особенности (можете опустить тех, кто не понимает) Дон. не смотрю…). Этот принцип требует от нас придерживаться принципа конкретного анализа конкретных проблем и под руководством принципа всеобщности противоречий конкретно анализировать особенность противоречий и находить правильный метод их разрешения. Мы против использования одного метода для разрешения противоречий разных вещей. Вот что значит открыть ключом замок и спеть любую песню, под которую ты пойдешь, в любой горе.
Серверные сценарии VBScript используют метод Server.CreateObject(className) для создания объектов, а клиентские сценарии VBScript используют метод CreateObject(className) для создания объектов.
Типичные ошибки
Скопируйте код кода следующим образом:
<%
ФункцияTSize(b)
'Это моя пользовательская функция
TSize=Китай
конечная функция
%>
<a href=javascript:<%TSize('Variable')%> >Нажмите здесь, чтобы использовать определенную мной функцию</a>
Анализ ошибок:
Запутанная разница между сценариями на стороне сервера и сценариями на стороне клиента. Во время фактического выполнения мы обнаружим, что клиент вообще не получает никакого кода, такого как TSize, поскольку TSize — это серверная программа, которая обрабатывается движком (обратите внимание, что обработка функций движком предназначена исключительно для серверного сценария). вызовы и не будут отправлены обратно клиенту) исчезает и не может работать на клиенте. Это означает, что клиентские сценарии не могут напрямую вызывать функции серверных сценариев.
Фактически, в этой программе есть синтаксическая ошибка. Когда механизм обрабатывает это содержимое, он сначала находит содержимое между <% и %>, то есть <%TSize('variable')%>. Очевидно, это содержимое не соответствует требованиям. с синтаксическими правилами VBScript. Что ж, если вы измените его на <%=TSize(variable)%>, в серверном скрипте не будет синтаксических ошибок. В это время функция TSize может возвращать значение China обычным образом, поэтому атрибут href получен. клиент пишется так: javascript: Китай, не имеет исковой силы.
Влияние серверных сценариев на клиентские сценарии
Как упоминалось ранее, серверные сценарии логически выполняются раньше клиентских, поэтому возможен такой код:
Скопируйте код кода следующим образом:
<%
Дим я
Для я = от 1 до 5
Response.Write <тип сценария=текст/javascript> _
& alert('Привет, мир! & i & ')</script>
Следующий
%>
Что касается выполнения Response.Redirect и javascript
Обратите внимание, что следующий код написан неверно:
Скопируйте код кода следующим образом:
<%
Response.Redirect index.asp
Response.Write <тип сценария=текст/javascript> _
& alert('Неверный пароль!')</script>
%>
Это распространенная ошибка. Авторы часто думают, что написание кода таким образом приведет к тому, что клиент выдаст сообщение об ошибке пароля и затем перенаправит на index.asp. На самом деле этого не может произойти, даже если порядок двух строк. код поменялся, такого эффекта добиться не получится.
Причина связана с тем, как сервер обрабатывает две строки кода. Эти две строки кода не могут работать одновременно.
Response.Write — это отправка клиенту фрагмента текста. Содержимым этого текста может быть скрипт. Затем браузер клиента может выполнить скрипт после его получения.
Response.Redirect отправляет клиенту HTTP-заголовок (что такое HTTP-заголовок? Скажем так, например, запись в файлы cookie клиента — это информация HTTP-заголовка, а информация HTTP-заголовка отправляется обратно клиенту перед браузером тела HTTP). , поэтому иногда мы получаем ошибку при изменении файлов cookie после отключения буферизации сервера, поскольку тело уже начало передачу, а HTTP-заголовки не могут быть отправлены. Информация.), содержимое информации сообщает клиентскому браузеру, что он должен перейти на страницу для просмотра. Обратите внимание, что эта информация о перенаправлении вступает в силу немедленно, что означает, что эта информация о перенаправлении является эксклюзивной, когда буфер включен, независимо от того. был ли использован Response. .Write записывает объем содержимого, записанного в буфер. После вызова Response.Redirect буфер будет очищен, и эта инструкция заголовка будет отправлена в клиентский браузер. Если мы динамически отслеживаем выполнение программы, мы также обнаружим, что после вызова Response.Redirect программа перестает выполняться, поэтому обратите внимание, что серверная программа должна закрыть соединение для передачи данных и другие операции перед вызовом Response.Redirect.
Так как же следует изменить приведенный выше пример? Если вы не хотите изменять index.asp для добавления приглашения сценария, вы можете выполнить инструкцию перенаправления только в клиентском сценарии, например:
Скопируйте код кода следующим образом:
<%
Response.Write <тип сценария=текст/javascript> _
& alert('!');location.href='index.asp'</script>
%>