IIS findet die ASP-Datei und sendet sie zur Verarbeitung usw. an die ASP-Engine (normalerweise ASP.DLL). Freunde, die sie benötigen, können darauf zurückgreifen. Lassen Sie uns zunächst den Prozess der ASP-Seitenausführung verstehen.
1. IIS findet die ASP-Datei und übermittelt sie zur Verarbeitung an die ASP-Engine (normalerweise ASP.DLL).
2. Die Engine öffnet die ASP-Datei und findet den Inhalt zwischen <% und %> und natürlich den Inhalt zwischen <script runAt=server> und dem entsprechenden </script>. Diese Inhalte werden als Skriptblöcke bezeichnet. Nur der Inhalt im Skriptblock wird von der Engine analysiert, andere Inhalte werden ignoriert und als bedeutungslose Zeichen zwischen den Skriptblöcken eingefügt. Es muss erklärt werden, dass der analysierte Inhalt tatsächlich mehr ist. Die serverseitigen Include-Dateien der Klasse <!--#include ***--> werden ebenfalls von der Engine einbezogen und verarbeitet. Wenn Sie viele Programme lesen, wissen Sie auch, dass einige <object>-Objekte, deren runAt-Attribute als Server markiert sind, ebenfalls verarbeitet werden. Wir werden sie hier nicht näher besprechen.
3. Die Engine führt die Skripte im Skriptblock aus. Diese serverseitigen Skripte werden als Ganzes ausgeführt. Das heißt, der folgende Code kann geschrieben werden.
Kopieren Sie den Codecode wie folgt:
<%
Dim ich
Für i=1 bis 5
%> Hallo Welt!
<% Weiter %>
Die Engine analysiert diese Skriptblöcke nicht separat, was zu Syntaxfehlern in beiden Skriptblöcken führt. Wir kommen also zu folgendem Schluss: Es wird nicht der gesamte Nicht-Server-Skriptcode an den Client gesendet. Es ist möglich, dass dieser Nicht-Server-Skriptcode durch den Skriptblock eingeschränkt wird. Der Server kümmert sich definitiv nicht um die Ausführung von Client-Skripten, kann jedoch über serverseitige Skripte verschiedene Client-Skripte ausgeben.
4. Schließlich generiert die Engine einen Textstream oder das Ausführungsergebnis des Skripts, das als Zeichenfolge betrachtet werden kann, bei der es sich um den an den Client-Browser gesendeten Code der Webseite handelt. Der Client-Browser zeigt die Seite an. Zu diesem Zeitpunkt enthält der Quellcode (Quelldatei) der Seite nicht das serverseitige Skript, sondern das Ausführungsergebnis des serverseitigen Skripts (dies ist offensichtlich).
<% … %> und <script runat=server>…</script>
Dabei handelt es sich allesamt um serverseitige Skripte, die gleichzeitig verarbeitet und ausgeführt werden. Sie treten als Einheit auf.
<% … %> und <script language=…>…</script>
Ersteres ist ein serverseitiges Skript und letzteres ist ein clientseitiges Skript. Ersteres wird zuerst und Letzteres später ausgeführt.
Tatsächlich ist dies nicht unbedingt der Fall. Es ist möglich, dass die beiden Skripte gleichzeitig ausgeführt werden, aber die Leerzeichen sind immer noch unterschiedlich: Ersteres wird auf dem Server ausgeführt, und letzteres wird auf dem Server ausgeführt Client-Browser. Ersteres muss logischerweise früher ausgeführt werden als Letzteres. Gleichzeitig sind wir auch zu dem Schluss gekommen: Während der Ausführung derselben Seite kann das clientseitige Skript auf keinen Fall eine Rückmeldung an das serverseitige Skript geben. Das heißt, der Client durchsucht Ihr Gästebuch und übermittelt es Neue Nachrichten oder vom clientseitigen Skript erhaltene Werte können nicht in derselben Serverantwort verarbeitet werden.
Über Komponentenaufrufe
Beachten Sie, dass sowohl serverseitige als auch clientseitige Skripte Skripte sind. Natürlich können Sie xmlhttp-Komponenten, ADODB.Connection-Komponenten usw. erstellen, diese können jedoch nicht irgendwo platziert werden.
Wenn xmlhttp zum Crawlen von Webseiten (z. B. Sammlungen) vom Server verwendet wird, muss es im Serverskript erstellt werden. Wenn es verwendet wird, damit der Ajax des Clients im Hintergrund auf die serverseitige Seite zugreift, ohne sie zu aktualisieren, wird es ausgeführt auf dem Client und natürlich auf dem Client, der am Ende erstellt wurde.
Die ADODB.Connection-Komponente wird für den Zugriff auf die Datenbank verwendet. Im Allgemeinen wird sie auf der Serverseite erstellt. Wenn Ihre Datenbank jedoch wirklich auf dem Client verbunden ist Seite, dann besteht kein Zweifel, dass es auf der Client-Seite erstellt wird.
Kurz gesagt, widersprüchliche Dinge und jede Seite hat ihre eigenen Eigenschaften. Unterschiedliche Dinge haben unterschiedliche Widersprüche; das gleiche Ding hat unterschiedliche Widersprüche in unterschiedlichen Prozessen und Entwicklungsstadien, und zwei verschiedene Aspekte desselben Widerspruchs haben jeweils ihre eigenen Besonderheiten (Sie können diejenigen weglassen, die es nicht verstehen) Don schau nicht...). Dieses Prinzip erfordert, dass wir uns an das Prinzip der konkreten Analyse spezifischer Probleme halten und unter der Führung des Prinzips der Universalität von Widersprüchen die Besonderheit von Widersprüchen konkret analysieren und die richtige Methode zu ihrer Lösung finden. Wir sind dagegen, die Widersprüche verschiedener Dinge mit einer Methode zu lösen. Das bedeutet, ein Schloss mit einem Schlüssel zu öffnen und das Lied zu singen, zu dem man auf einem beliebigen Berg geht.
Serverseitige VBScript-Skripts verwenden die Methode „Server.CreateObject(className)“ zum Erstellen von Objekten, und clientseitige VBScript-Skripts verwenden die Methode „CreateObject(className)“ zum Erstellen von Objekten.
Typische Fehler
Kopieren Sie den Codecode wie folgt:
<%
FunctionTSize(b)
„Das ist meine benutzerdefinierte Funktion.“
TSize=China
Endfunktion
%>
<a href=javascript:<%TSize('Variable')%> >Klicken Sie hier, um die von mir definierte Funktion zu verwenden</a>
Fehleranalyse:
Der Unterschied zwischen serverseitigen und clientseitigen Skripten ist verwirrend. Während der tatsächlichen Ausführung werden wir feststellen, dass der Client überhaupt keinen Code wie TSize erhält, da TSize ein serverseitiges Programm ist, das von der Engine verarbeitet wird (beachten Sie, dass die Verarbeitung von Funktionen durch die Engine ausschließlich für serverseitige Skripte erfolgt). Anrufe und werden nicht an den Client zurückgesendet) verschwindet und kann möglicherweise nicht auf dem Client funktionieren. Das bedeutet, dass clientseitige Skripte Funktionen serverseitiger Skripte nicht direkt aufrufen können.
Tatsächlich weist dieses Programm einen Syntaxfehler auf. Wenn die Engine diesen Inhalt verarbeitet, findet sie zunächst den Inhalt zwischen <% und %>, also <%TSize('variable')%> mit VBScript-Syntaxregeln. Nun, wenn Sie es in <%=TSize(variable)%> ändern, treten im serverseitigen Skript keine Syntaxfehler auf. Zu diesem Zeitpunkt kann die TSize-Funktion den Wert China normal zurückgeben, also das von empfangene href-Attribut Der Client ist folgendermaßen geschrieben: Javascript: China, ist nicht durchsetzbar.
Auswirkungen serverseitiger Skripte auf clientseitige Skripte
Wie bereits erwähnt, werden serverseitige Skripte logischerweise vor clientseitigen Skripten ausgeführt, sodass Code wie dieser möglich ist:
Kopieren Sie den Codecode wie folgt:
<%
Dim ich
Für i=1 bis 5
Response.Write <script type=text/javascript> _
& alarm('Hallo Welt! & i & ')</script>
Nächste
%>
Bezüglich der Ausführung von Response.Redirect und Javascript
Beachten Sie, dass der folgende Code falsch geschrieben ist:
Kopieren Sie den Codecode wie folgt:
<%
Response.Redirect index.asp
Response.Write <script type=text/javascript> _
& alarm('Falsches Passwort!')</script>
%>
Dies ist ein häufiger Fehler, wenn das Schreiben von Code auf diese Weise dazu führt, dass der Client eine Kennwortfehlermeldung anzeigt und dann zu index.asp umleitet. Dies kann jedoch nicht passieren Code ausgetauscht wird, ist es nicht möglich, diesen Effekt zu erzielen.
Der Grund hängt mit der Art und Weise zusammen, wie der Server die beiden Codezeilen verarbeitet. Es ist unmöglich, dass diese beiden Codezeilen gleichzeitig funktionieren.
Response.Write besteht darin, einen Text an den Client zu senden. Der Inhalt dieses Textes kann dann ein Skript sein, nachdem er empfangen wurde.
Response.Redirect sendet einen HTTP-Header an den Client (was ist ein HTTP-Header? Sagen wir es so: Beim Schreiben in Client-Cookies handelt es sich beispielsweise um HTTP-Header-Informationen, und die HTTP-Header-Informationen werden vor dem HTTP-Body-Browser an den Client zurückgesendet Aus diesem Grund erhalten wir manchmal eine Fehlermeldung, wenn wir Cookies ändern, nachdem wir die Pufferung des Servers ausgeschaltet haben, da der Körper bereits mit der Übertragung begonnen hat und HTTP-Header nicht gesendet werden dürfen. Informationen.), Der Inhalt der Informationen teilt dem Client-Browser mit, dass er zur Seite zum Durchsuchen springen soll. Beachten Sie, dass diese Umleitungsinformationen sofort wirksam sind, was bedeutet, dass diese Umleitungsinformationen unabhängig davon exklusiv sind ob Response verwendet wurde, schreibt, wie viel Inhalt in den Puffer geschrieben wird. Sobald Response.Redirect aufgerufen wird, wird der Puffer gelöscht und diese Header-Anweisung an den Client-Browser gesendet. Wenn wir die Ausführung des Programms dynamisch verfolgen, werden wir auch feststellen, dass das Programm nach dem Aufruf von Response.Redirect nicht mehr ausgeführt wird. Beachten Sie daher, dass das serverseitige Programm die Datenverbindung und andere Vorgänge schließen muss, bevor Response.Redirect aufgerufen wird.
Wie sollte das obige Beispiel geändert werden? Wenn Sie index.asp nicht ändern möchten, um eine Skript-Eingabeaufforderung hinzuzufügen, können Sie die Umleitungsanweisung nur im Client-Skript ausführen, wie folgt:
Kopieren Sie den Codecode wie folgt:
<%
Response.Write <script type=text/javascript> _
& alarm('!');location.href='index.asp'</script>
%>