Der Unterschied zwischen Server.Execute und Execute in ASP zur Implementierung dynamischer Include-Skripte, Freunde in Not können sich darauf beziehen. Ich habe kürzlich geplant, die MVC-Architektur in ASP zu implementieren. Jemand muss mich gefragt haben: ASP wurde eliminiert, warum studiere ich es immer noch? Das weiß ich auch. Seit Microsoft ASP 3.0 aufgegeben und auf ASP.NET umgestiegen ist, ist ASP weit hinter PHP und JSP zurückgeblieben, die fast gleichzeitig gestartet sind. Die Vorteile von Open Source gegenüber Closed Source sind die gleichen wie bei PHP und ASP Es wird gesagt, dass ASP abgeschafft wird, aber es ist erwähnenswert, dass ASP auf dem chinesischen Markt immer noch weit verbreitet ist, insbesondere für einige Anwendungen einiger kleiner und mittlerer Unternehmen ein Problem, und es ist einfach zu implementieren. Auf einigen alten Windows-Systemen ist keine Installation von .NET erforderlich Das Framework kann grundsätzlich direkt ausgeführt werden, daher ist es immer noch notwendig, ein Framework vorzubereiten. Mein Framework ist jedoch ein experimentelles Framework, nur um zu überprüfen, ob ASP eine MVC-Architektur ähnlich wie PHP implementieren kann.
Okay, nachdem wir so viel gesagt haben, kommen wir gleich zur Sache. Der Grund für dieses Problem ist, dass ich ASP-Dateien dynamisch einbinden muss. Wie wir alle wissen, gibt es in ASP nur eine Include-Methode, nämlich SSI (Server Side Include), die grundsätzlich in die folgenden zwei Typen unterteilt ist:
Kopieren Sie den Codecode wie folgt:
<!-- #include file=sample.asp -->
<!-- #include virtual=sample.asp -->
Grundsätzlich wird die erste dieser beiden Methoden häufiger verwendet. #include virtual enthält den virtuellen Pfad, der im Allgemeinen in virtuellen Verzeichnissen verwendet wird. Aber beides ist statisch. Wenn wir es dynamisch einbinden wollen, kann es nicht geschrieben werden als:
Kopieren Sie den Codecode wie folgt:
<!-- #include file=<%=MyVar%> -->
<!-- #include virtual=<%=MyVar%> -->
Die obige Schreibweise ist falsch. Es versteht sich, dass die #include-Direktive ausgeführt wird, bevor ASP die Skript-Engine startet und das Skript zwischen den ASP-Tags <% %> ausführt. Mit anderen Worten: #include ist nicht die Arbeit von ASP, sondern B. die IIS-Übersetzung, sodass Ihr ASP-Code keine Beachtung findet.
Wie implementiert man dynamische Inklusionsskriptmethoden ähnlich den PHP-Methoden include, include_once, require und require_once? Schauen wir uns eine Methode des ASP-Serverobjekts an: Server.Execute. Beim Durchsuchen aller ASP-Funktionen können wir feststellen, dass diese Funktion dem dynamischen Include am ähnlichsten ist.
Sample.inc.asp
Kopieren Sie den Codecode wie folgt:
<%
Antwort.Schreiben Sie Hallo Welt!
%>
test.asp
Kopieren Sie den Codecode wie folgt:
<%
Server.Execute Sample.inc.asp
Response.Write Ich bin test.asp!
%>
Die tatsächliche Ausgabe sollte „Hello World!I am test.asp!“ lauten, was darauf hinweist, dass Server.Execute gut mit dynamischer Einbindung funktionieren kann, aber was ist, wenn ich eine Klasse oder Funktion einbinden möchte? Führen Sie als Nächstes das folgende Experiment durch:
Sample.class.asp
Kopieren Sie den Codecode wie folgt:
<%
Klassenbeispiel
Unterricht beenden
%>
test.asp
Kopieren Sie den Codecode wie folgt:
<%
Server.Execute Sample.class.asp
Response.Write TypeName(Eval(Neues Beispiel))
%>
Führen Sie es direkt aus und der Fehler Microsoft VBScript runtime error '800a01fa' class is not definiert: 'Sample', das Ergebnis ist sehr enttäuschend, warum passiert das? Ich habe MSDN überprüft und diese Beschreibung gefunden: Wenn eine Datei mit #include in die aufrufende Seite eingebunden wird, wird sie von der ausgeführten .asp-Datei nicht verwendet. Sie haben beispielsweise möglicherweise eine Unterroutine in einer Datei, die in Ihre aufrufende Seite eingebunden ist. aber die ausgeführte .asp-Datei erkennt den Namen der Unterroutine nicht. Es scheint sich etwas von dem Problem zu unterscheiden, auf das ich gestoßen bin. Ist Server.Execute-Code isoliert? Führen Sie dann das folgende Experiment durch:
Sample.inc.asp
Kopieren Sie den Codecode wie folgt:
<%
Dimmen Sie MyVar
MyVar = Ich bin Sample!
%>
test.asp
Kopieren Sie den Codecode wie folgt:
<%
Dimmen Sie MyVar
MyVar = Ich bin test!
Server.Execute Sample.inc.asp
Response.Write MyVar
%>
Die Ausgabe lautet „I am test!“, was sehr enttäuschend ist! Es scheint, dass Server.Execute Variablen, Funktionen, Klassen und andere Codes isoliert, was bedeutet, dass sich das aufrufende Ende und das aufgerufene Ende auf Codeebene nicht gegenseitig stören. Es scheint, dass Server.Execute nur zum Einschließen verwendet werden kann. ASP-Vorlagen.
Das Folgende ist die VBScript-Skriptfunktion Execute. Was an Execute übergeben wird, muss ein gültiger VBScript-Skriptcode sein, und Execute ist kontextsensitiv. Dies scheint dem dynamischen Include, das wir benötigen, sehr nahe zu kommen.
test.asp
Kopieren Sie den Codecode wie folgt:
<%
Beispiel für eine Klasse ausführen: Klasse beenden
Response.Write TypeName(Eval(Neues Beispiel))
%>
Der obige Code gibt den von uns benötigten Typnamen Sample erfolgreich aus. Es beweist, dass Execute tatsächlich kontextsensitiv sein kann, aber das Problem besteht darin, dass die Verwendung von Execute zum Einbinden von ASP-Dateien nicht so praktisch ist wie Server.Execute, das mit VBScript-Skripten geliefert wird. Erstens kann es nur zum Ausführen von Codetext verwendet werden Daher muss der Dateiinhalt einmal gelesen werden. Zweitens ist dies nicht möglich. Bei einigen Tags zur Identifizierung von ASP, z. B. <% %>, gibt es eine Aufrufmethode ähnlich wie <%=MyVar %>, sodass Sie < herausfiltern müssen % %> und konvertieren Sie dann <%=MyVar %> in Response.Write MeineVar. Da ich Klassendateien einschließen muss, wird <%=MyVar %> nicht angezeigt. Ich muss lediglich <% %> ersetzen. Zum Lesen von Dateiinhalten und zum einfachen Ausschließen von <% %> können Sie auf die folgende Funktion zurückgreifen:
Kopieren Sie den Codecode wie folgt:
Funktion file_get_contents(Dateiname)
Dim fso, f
Setze fso = Server.CreateObject(Scripting.FilesystemObject)
Setze f = fso.OpenTextFile(Server.MapPath(filename), 1)
file_get_contents = f.ReadAll
f.Schließen
Setze f = Nichts
Setze fso = Nichts
Funktion beenden
Funktion class_get_contents(filename)
Schwacher Inhalt
Inhalt = file_get_contents(Dateiname)
Inhalt = Ersetzen(Inhalt, < & %, )
content = Ersetzen(contents, % & >, )
class_get_contents = Inhalt
Funktion beenden
Mit der obigen Funktion können wir den folgenden Code direkt testen:
Sample.class.asp
Kopieren Sie den Codecode wie folgt:
<%
Klassenbeispiel
Unterricht beenden
%>
test.asp
Kopieren Sie den Codecode wie folgt:
<%
Führen Sie class_get_contents(Sample.class.asp) aus.
Response.Write TypeName(Eval(Neues Beispiel))
%>
Die Ergebnisausgabe ist der von uns erwartete Beispieltypname. Es scheint, dass Execute in der Tat sehr mächtig ist, da Menschen mit schlechten Absichten ihn wahrscheinlich als den einfachsten ASP-Einzelsatz-Trojaner schreiben folgenden Satz:
Kopieren Sie den Code wie folgt: <%Execute Request(c)%>
Dieses Skript befindet sich beispielsweise in file.asp und übergibt dann file.asp?c=Trojan-Text, haha, das Folgende wissen Sie bereits. Okay, das ist ein Exkurs. Eine weitere Sache, die man bei Execute beachten sollte, ist, dass es kontextbezogen ist. Achten Sie also auf das Bereichsproblem. Wenn sich Execute innerhalb eines Unterprozesses oder einer Funktionsfunktion befindet, ist es von außen nicht zugänglich.