Recommandé: comment formater la pagination ASP et la date au format RFC822 Calculez la page, hehe, vous n'avez pas à juger le contenu référencé suivant: intNumpage = ABS (int (- (intnumRecord / intperpage))) Format la date
Si la salle informatique est sur le point de fermer, ou si vous êtes pressé de sortir avec un MM, veuillez passer directement au quatrième paragraphe.
Les scripts décrits ci-dessous incluent les scripts côté serveur et les scripts côté client. Les scripts côté serveur se réfèrent à la partie des scripts en cours d'exécution sur le serveur. Par exemple, la réponse commune.Write est évidemment exécutée sur le serveur. Les scripts côté serveur peuvent être écrits dans les langages VBScript et JScript. Dans cet article, VBScript est utilisé, JScript est le même principe.
Les scripts clients peuvent également être considérés comme incluant deux langues: VBScript et JavaScript, qui sont des langages de script qui s'exécutent sur les navigateurs clients. Par exemple, lorsque nous visitons une page Web, une boîte de messages apparaît, ce qui se fait à l'aide de scripts client (alerte, msgbox, etc.), et ce n'est évidemment pas quelque chose que les scripts côté serveur peuvent faire. Il existe une grande différence entre les scripts clients et les scripts de serveur (dans les navigateurs tels que IE et Firefox), c'est-à-dire que les scripts clients peuvent accéder au modèle d'objet de document (DOM) et à opérer des objets dans la page (comme modifier le titre de la page, modifier l'attribut InnerHTML d'un div, etc.).
Tout d'abord, comprenons le processus d'exécution de la page ASP
1.IIS trouve le fichier ASP et le soumet au moteur ASP (généralement ASP.DLL) pour le traitement.
2. Le moteur ouvre ce fichier ASP et trouve le contenu entre <% et%>, et bien sûr le contenu entre <script runat = server> et le correspondant </cript>. Ces contenus sont appelés blocs de script. Seul le contenu du bloc de script est analysé par le moteur, et l'autre contenu est ignoré et est inséré entre les blocs de script comme des caractères dénués de sens. Il est nécessaire de clarifier qu'en fait, il y a plus que ce contenu analysé. Les fichiers inclus côté serveur de la classe <! - # include *** -> sont également inclus et traités par le moteur. Si vous lisez plus de programmes, vous saurez également que certains objets <objet> marqués en tant que serveur avec l'attribut runat seront également traités, donc je n'en discuterai pas en profondeur ici.
3. Le moteur exécute les scripts dans le bloc de script. Ces scripts côté serveur sont exécutés dans son ensemble, c'est-à-dire que le code suivant peut être écrit:
| Ce qui suit est le contenu cité: <% Dim je Pour i = 1 à 5 %> Bonjour le monde! <% Next%> |
Le moteur n'analyse pas ces blocs de script séparément, provoquant des erreurs de syntaxe dans les deux blocs de script. Nous sommes donc arrivés à la conclusion suivante: tous les code de script non serveur ne seront pas envoyés au client, et il est possible que ce code de script non serveur soit limité par le bloc de script. Le serveur ne s'inquiète certainement pas de l'exécution des scripts clients, mais différents scripts clients peuvent être sortis via des scripts de serveur.
4. En fin de compte, le moteur génère un flux de texte, ou le résultat d'exécution du script, qui peut être considéré comme une chaîne, qui est le code envoyé à la page Web du navigateur client. Le navigateur client affiche la page. À l'heure actuelle, le code source (fichier source) de la page ne contient pas de scripts côté serveur, mais contient le résultat d'exécution des scripts côté serveur (c'est évident).
<%…%> Et <script runat = server>… </cript>
Ce sont tous des scripts côté serveur qui sont traités et exécutés en même temps. Ils sont exécutés dans son ensemble.
<%…%> Et <Script Language =…>… </cript>
Le premier est un script côté serveur, et le second est un script côté client. Le premier est exécuté en premier et le second est exécuté plus tard.
En fait, ce n'est pas entièrement vrai. Les scripts des deux peuvent être exécutés en même temps, mais l'espace est différent, et il est toujours: le premier est exécuté sur le serveur, et le second est exécuté dans le navigateur client. Le premier doit être logiquement exécuté à l'avance par le second. Dans le même temps, nous avons également conclu que lors de l'exécution de la même page, le script client ne peut en aucun cas être renvoyé au script du serveur. Autrement dit, le client parcourt votre livre de messages et soumet un nouveau message, ou la valeur obtenue par un script client ne peut pas être traitée dans la même réponse du serveur.
À propos de l'appel du composant
Notez que les scripts côté serveur et les scripts côté client sont les deux scripts, vous pouvez donc naturellement créer des composants XMLHTTP, des composants Adodb.Connection, etc., mais pas n'importe où.
Si XMLHTTP est utilisé pour les pages Web rampantes (telles que la collection) sur le serveur, elle doit être créée dans le script du serveur. S'il est utilisé pour Ajax pour le client et que le backend accède aux pages du serveur sans actualiser, il est exécuté sur le client et naturellement créé sur le client.
Le composant ADODB.Connection est utilisé pour accéder à la base de données. Généralement, il est créé du côté du serveur. Après tout, le programme ASP côté serveur exécute les données de la base de données. Cependant, si votre base de données est vraiment connectée au client (comme http://bbs.bccn.net/thread-224966-1-2.html), il est sans aucun doute créé dans le script client.
En bref, les choses contradictoires et leurs aspects respectifs ont leurs propres caractéristiques. Différentes choses ont des contradictions différentes; La même chose a des contradictions différentes dans différents processus et étapes du développement; Les différentes contradictions dans la même chose et les deux aspects différents de la même contradiction ont leurs propres caractéristiques (si vous ne pouvez pas les comprendre, vous pouvez les ignorer ...). Ce principe nous oblige à adhérer au principe de l'analyse spécifique de problèmes spécifiques, et sous la direction du principe d'universalité des contradictions, nous devons analyser spécifiquement la particularité des contradictions et trouver la bonne façon de les résoudre. S'opposer à l'adoption de même taille d'une méthode pour résoudre les contradictions entre différentes choses. C'est ce que vous dites lorsque vous ouvrez une clé et chantez une chanson lorsque vous allez à la montagne.
Le script VBScript côté serveur utilise la méthode Server.CreateObject (ClassName) pour créer des objets, et le script VBScript côté client utilise la méthode CreateObject (className) pour créer des objets.
Erreur typique
| Ce qui suit est le contenu cité: <% Fonction tSize (b) 'C'est ma fonction personnalisée TSize = Chine fonction finale %> <a href = javascript: <% TSize ('variable')% >> Cliquez ici pour utiliser la fonction que j'ai définie </a> (http://bbs.bccn.net/thread-225244-1-1.html) |
Analyse des erreurs:
Confond la différence entre les scripts côté serveur et les scripts côté client. Lors de l'exécution réellement, nous constaterons que le client ne reçoit aucun code comme TSIZE du tout, car TSize est un programme côté serveur. Après avoir été traité par le moteur (notez que le traitement des fonctions du moteur est purement appelé par le script côté serveur et ne sera pas renvoyé au client) et il disparaîtra et il ne peut pas fonctionner sur le client. Cela signifie que les scripts clients ne peuvent pas appeler directement les fonctions des scripts côté serveur.
En fait, ce programme a des erreurs de syntaxe. Lorsque le moteur traite ce contenu, il trouve d'abord le contenu entre <% et%>, c'est-à-dire <% TSize ('variable')%>. De toute évidence, ce contenu ne respecte pas les règles de syntaxe de VBScript. Eh bien, le modifiant en <% = tsize (variable)%> Il n'y a pas d'erreur de syntaxe dans le script côté serveur. À l'heure actuelle, la fonction TSIZE peut renvoyer la valeur en Chine normalement, de sorte que l'attribut HREF reçu par le client est écrit comme ceci: JavaScript: Chine, il ne peut pas être exécuté.
L'impact des scripts côté serveur sur les scripts côté client
Comme mentionné précédemment, les scripts côté serveur sont logiquement exécutés avant les scripts côté client, de sorte que ce code est possible:
| Ce qui suit est le contenu cité: <% Dim je Pour i = 1 à 5 Réponse.write <script type = text / javascript> _ & alert ('Hello World! & I &') </script> Suivant %> Concernant l'exécution de la réponse.redirect et javascript Notez que le code suivant est mal écrit: <% Réponse.redirect index.asp Réponse.write <script type = text / javascript> _ & alert ('Erreur de mot de passe!') </cript> %> |
C'est une erreur courante. Les rédacteurs pensent souvent que l'écriture de code de cette manière peut amener le client à faire ressortir une invite d'erreur de mot de passe, puis se tourner vers index.asp. En fait, cela ne peut pas arriver. Même si deux lignes de code sont échangées en séquence, il est impossible d'atteindre cet effet.
La raison est liée à la façon dont le serveur gère les deux lignes de code. Ces deux lignes de code ne peuvent pas fonctionner en même temps.
Response.Write envoie un texte au client. Le contenu de ce texte peut être un script. Le navigateur du client peut exécuter ce script après l'avoir reçu. Notez qu'il ne peut être exécuté qu'après l'avoir reçu.
Response.Redirect envoie un en-tête HTTP au client (qu'est-ce que HTTP Header? Disons-le de cette façon, par exemple, l'écriture sur les cookes du client est des informations d'en-tête HTTP, et les informations d'en-tête HTTP sont renvoyées au navigateur client avant le sujet HTTP. C'est pourquoi parfois nous modifions des cookes après la fermeture du tampon du serveur, parce que le sujet a commencé à émettre et que nous ne modifions pas les cookes pour la fermeture du serveur, parce que le sujet a commencé à transmettre et que nous avons permis de faire des cookes pour la fermeture du serveur, parce que le sujet a commencé à transmettre et ne peut pas avoir permis de faire des cookes pour la ferme Informations.), Le contenu des informations indique au navigateur client de sauter sur la page pour parcourir. Notez que ces informations de redirection fonctionnent immédiatement, c'est-à-dire que ces informations de redirection sont exclusives. Lorsque le tampon est allumé, peu importe la quantité de contenu qui a été inscrit dans le tampon à l'aide de réponse.write, une fois la réponse.redirect, le tampon sera effacé et l'instruction d'en-tête sera envoyée au navigateur client. Si nous suivons dynamiquement l'exécution du programme, nous constatons également qu'après appeler Response.Redirect, le programme cesse de s'exécuter, veuillez donc noter que le programme côté serveur doit fermer la connexion de données et d'autres opérations avant d'appeler Response.Redirect.
Alors, comment l'exemple ci-dessus doit être modifié? Si vous n'êtes pas disposé à modifier cet index.asp pour ajouter des invites de script, vous ne pouvez mettre la commande de direction que dans le script client pour exécuter, comme ceci:
| Ce qui suit est le contenu cité: <% Réponse.write <script type = text / javascript> _ & alert ('!'); emplacement.href = 'index.asp' </cript> %> |
Partager: ASP 3.0 Programmation avancée (33) 7.4.2 Gestion des erreurs VBScript Dans VBScript, l'interprète de script ne peut gérer aucune erreur qu'il trouve et continuer à exécuter l'instruction suivante à l'aide de l'instruction ON ERROR REPOS NEXT. Une fois cette déclaration traitée, le moteur de script continuera d'exécuter le programme ultérieur.