Разница между Server.Execute и Execute в ASP для реализации сценариев динамического включения, друзья, нуждающиеся в этом, могут обратиться к ней. Недавно я планировал попробовать реализовать архитектуру MVC в ASP. Кто-то, должно быть, спросил меня: ASP исключен, почему я все еще его изучаю? Я также знаю это. С тех пор, как Microsoft отказалась от ASP 3.0 и перешла на ASP.NET, ASP сильно отстал от PHP и JSP, которые появились почти одновременно. Преимущества открытого исходного кода перед закрытым такие же, как у PHP и ASP. Говорят, что ASP будет ликвидирован. Никто не может спасти его от ликвидации, но стоит отметить, что ASP все еще довольно широко распространен на китайском рынке, особенно для некоторых приложений некоторых малых и средних предприятий. проблема, и ее легко развернуть. В некоторых старых системах Windows нет необходимости устанавливать .NET. Фреймворк в принципе можно запускать напрямую, поэтому его все равно необходимо подготовить. Однако мой фреймворк является экспериментальным, просто для того, чтобы проверить, может ли ASP реализовать архитектуру MVC, аналогичную PHP.
Ладно, раз уж так много сказали, давайте сразу к делу. Причина этой проблемы в том, что мне нужно динамически включать файлы ASP. Как мы все знаем, в ASP есть только один метод включения — SSI (Server Side Include), который в основном делится на следующие два типа:
Скопируйте код кода следующим образом:
<!-- #include file=sample.asp -->
<!-- #include virtual=sample.asp -->
По сути, из этих двух чаще используется первый. #include virtual содержит виртуальный путь, который обычно используется в виртуальных каталогах. Но оба они статичны. Если мы хотим включить их динамически, их нельзя записать так:
Скопируйте код кода следующим образом:
<!-- #include file=<%=MyVar%> -->
<!-- #include virtual=<%=MyVar%> -->
Выше написанное неверно. Можно понять, что директива #include выполняется до того, как ASP запустит скриптовый движок и выполнит скрипт между тегами ASP<% %>. Другими словами, #include — это работа не ASP, а. серверная программа, такая как работа по переводу IIS, поэтому она не будет обращать внимание на ваш код ASP.
Как реализовать методы сценария динамического включения, аналогичные PHP include, include_once, require и require_once? Давайте посмотрим на метод объекта ASP Server: Server.Execute. Проведя поиск по всем функциям ASP, мы обнаружили, что эта функция наиболее похожа на динамическое включение. Мы можем провести эксперимент:
Образец.inc.asp
Скопируйте код кода следующим образом:
<%
Ответ.Напишите «Привет, мир!».
%>
test.asp
Скопируйте код кода следующим образом:
<%
Server.Execute Sample.inc.asp
Ответ.Напишите Я test.asp!
%>
Фактический результат должен быть Hello World!I am test.asp!, что указывает на то, что Server.Execute может хорошо работать с динамическим включением, но что, если я захочу включить класс или функцию? Далее проделайте следующий эксперимент:
Образец.class.asp
Скопируйте код кода следующим образом:
<%
Пример класса
Конечный класс
%>
test.asp
Скопируйте код кода следующим образом:
<%
Server.Execute Sample.class.asp
Response.Write TypeName(Eval(Новый образец))
%>
Запустите его напрямую, и появится ошибка Ошибка выполнения Microsoft VBScript «800a01fa». Класс не определен: «Пример», результат очень разочаровывает, почему это происходит? Я проверил MSDN и нашел следующее описание: Если файл включен в вызывающую страницу с помощью #include, исполняемый файл .asp не будет его использовать. Например, у вас может быть подпрограмма в файле, который включен в вашу вызывающую страницу. но исполняемый .asp не распознает имя подпрограммы. Кажется, это несколько отличается от проблемы, с которой я столкнулся. Изолирован ли код Server.Execute? Затем проведите следующий эксперимент:
Образец.inc.asp
Скопируйте код кода следующим образом:
<%
Тусклый MyVar
MyVar = Я Образец!
%>
test.asp
Скопируйте код кода следующим образом:
<%
Тусклый MyVar
MyVar = Я тест!
Server.Execute Sample.inc.asp
Response.Write MyVar
%>
Результат: «Я тест!», что очень разочаровывает! Похоже, что Server.Execute изолирует переменные, функции, классы и другие коды, а это значит, что вызывающая и вызываемая стороны не мешают друг другу на уровне кода. Кажется, что Server.Execute можно использовать только для включения . asp-шаблоны.
Ниже приведена функция «Выполнение» сценария VBScript. То, что передается в «Выполнение», должно быть допустимым кодом сценария VBScript, а «Выполнение» является контекстно-зависимым. Кажется, это очень близко к нужному нам динамическому включению.
test.asp
Скопируйте код кода следующим образом:
<%
Пример выполнения класса: конец класса
Response.Write TypeName(Eval(Новый образец))
%>
Приведенный выше код успешно выводит нужное нам имя типа Sample. Это доказывает, что Execute действительно может быть контекстно-зависимым, но проблема в том, что использование Execute для включения файлов asp не так удобно, как Server.Execute, который поставляется со сценариями VBScript. Прежде всего, его можно использовать только для выполнения текста кода. , поэтому содержимое файла необходимо прочитать один раз. Во-вторых, это невозможно. Для некоторых тегов, используемых для идентификации ASP, например <% %>, существует метод вызова, аналогичный <%=MyVar %>, поэтому необходимо отфильтровать <. % %>, а затем преобразуйте <%=MyVar %> в Response.Write. МояВар. Поскольку мне нужно включить файлы классов, <%=MyVar %> не появится, мне просто нужно просто заменить <% %>. Чтобы прочитать содержимое файла и просто исключить <% %>, вы можете обратиться к следующей функции:
Скопируйте код кода следующим образом:
Функция file_get_contents(имя файла)
Дим fso, f
Установите fso = Server.CreateObject(Scripting.FilesystemObject)
Установите f = fso.OpenTextFile(Server.MapPath(имя файла), 1)
file_get_contents = f.ReadAll
е.Закрыть
Установить f = Ничего
Установить fso = Ничего
Конечная функция
Функция class_get_contents(имя файла)
Тусклое содержимое
содержимое = file_get_contents (имя файла)
содержимое = Заменить(содержимое, < & %, )
содержимое = Заменить (содержимое, % & >, )
class_get_contents = содержимое
Конечная функция
С помощью приведенной выше функции мы можем напрямую протестировать следующий код:
Образец.class.asp
Скопируйте код кода следующим образом:
<%
Пример класса
Конечный класс
%>
test.asp
Скопируйте код кода следующим образом:
<%
Выполнить class_get_contents(Sample.class.asp)
Response.Write TypeName(Eval(Новый образец))
%>
Результатом является ожидаемое имя типа Sample. Похоже, что Execute по-прежнему очень мощный инструмент, потому что люди с плохими намерениями часто используют его для создания пони. Самый простой троян ASP, состоящий из одного предложения, вероятно, написан как. следующее предложение:
Скопируйте код следующим образом: <%Execute Request(c)%>
Например, этот скрипт находится в файле file.asp, а затем передается в file.asp?c=Trojan текст, ха-ха, вы уже знаете следующее. Хорошо, это отступление. Еще одна вещь, которую следует отметить в отношении Execute, — это то, что он связан с контекстом, поэтому обратите внимание на проблему с областью действия. Если Execute находится внутри подпроцесса или функции, он недоступен извне.