Wenn der Computerraum kurz vor der Schließung steht oder Sie unbedingt mit einem Mädchen ausgehen möchten, springen Sie bitte direkt zum vierten natürlichen Absatz.
Die unten beschriebenen Skripte umfassen serverseitige Skripte und serverseitige Skripte, die sich auf den Teil des Skripts beziehen, der auf dem Server ausgeführt wird. Beispielsweise wird das allgemeine Response.Write offensichtlich auf der Serverseite ausgeführt Skripte können mit den Sprachen VBScript und JScript geschrieben werden. In diesem Artikel werden alle VBScript und Jscript verwendet.
Es kann auch davon ausgegangen werden, dass clientseitige Skripts zwei Sprachen umfassen: VBScript und JavaScript, bei denen es sich um Skriptsprachen handelt, die im Client-Browser ausgeführt werden. Wenn wir beispielsweise eine Webseite besuchen und ein Meldungsfeld angezeigt wird, erfolgt dies mithilfe von clientseitigen Skripten (alert, msgbox usw.), und serverseitige Skripte können dies offensichtlich nicht tun. Es gibt einen weiteren großen Unterschied zwischen clientseitigen und serverseitigen Skripten (in Browsern wie IE und Firefox): Clientseitige Skripte können auf das Document Object Model (DOM) zugreifen und Objekte auf der Seite bearbeiten (z. B B. das Ändern des Seitentitels, das Ändern des innerHTML-Attributs eines Div usw.).
Schauen wir uns zunächst den Prozess der ASP-Seitenausführung an.
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.
<%
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 verwendet, um auf die Datenbank zuzugreifen. Im Allgemeinen wird sie auf der Serverseite erstellt. Schließlich ist es das serverseitige ASP-Programm, das die Datenbankdaten ausführt, wenn Ihre Datenbank jedoch tatsächlich auf dem Client verbunden ist Seite (z. B. http://bbs .bccn.net/thread-224966-1-2.html), dann muss es im Client-Skript erstellt werden.
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. Ein Schlüssel öffnet ein Schloss, und das bedeutet es, jedes Lied zu singen, zu dem man auf jedem 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
<%
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>
(http://bbs.bccn.net/thread-225244-1-1.html)
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:
<%
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:
<%
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, wird dieser Effekt nicht erreicht.
Der Grund liegt in der Art und Weise, 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 bitte, 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:
<%
Response.Write <script type=text/javascript> _
& alarm('!');location.href='index.asp'</script>
%>
Kontaktinformationen
Wenn Sie Kommentare und Vorschläge haben, insbesondere Fehler und Mängel im Artikel, oder wenn Sie dem Artikel neues Material hinzufügen möchten, können Sie mich über das Programmierforum kontaktieren. Natürlich können Sie auch nach diesem Beitrag Fragen stellen.
Es ist erwähnenswert, dass Sie über diese Kontaktinformationen möglicherweise keine zeitnahe Antwort erhalten, wenn Sie Fragen zu Algorithmen und Datenstrukturen haben, z. B. wenn Sie nicht verstehen, warum Ihr Programm falsch ist, oder wenn Sie nach dem Quellcode eines bestimmten Algorithmus fragen. Bitte fragen Sie im Programmierforum nach.
-------------------------------------------------- ----------------------------------
Copyright
Copyright (c) 2008 multiple1902
Es wird die Erlaubnis erteilt, dieses Dokument gemäß den Bedingungen der GNU Free Documentation License Version 1.2 oder einer späteren, von der Free Software Foundation veröffentlichten Version zu kopieren, zu verbreiten und/oder zu ändern.