IIS encuentra el archivo ASP y lo envía al motor ASP (generalmente ASP.DLL) para su procesamiento, etc. Los amigos que lo necesiten pueden consultarlo Primero, comprendamos el proceso de ejecución de la página ASP.
1. IIS busca el archivo ASP y lo envía al motor ASP (normalmente ASP.DLL) para su procesamiento.
2. El motor abre el archivo ASP y encuentra el contenido entre <% y %> y, por supuesto, el contenido entre <script runAt=server> y el </script> correspondiente. Estos contenidos se denominan bloques de script. El motor solo analiza el contenido del bloque de secuencia de comandos, y el resto del contenido se ignora y se inserta entre los bloques de secuencia de comandos como caracteres sin sentido. Es necesario explicar que, de hecho, el contenido que se analiza es más que esto. Los archivos de inclusión del lado del servidor de la clase <!--#include ***--> también son incluidos y procesados por el motor. Si lee muchos programas, también sabrá que algunos objetos <object> cuyos atributos runAt están marcados como Servidor también se procesarán. No los discutiremos en profundidad aquí.
3. El motor ejecuta los scripts en el bloque de script. Estos scripts del lado del servidor se ejecutan en su conjunto, es decir, se puede escribir el siguiente código:
Copie el código de código de la siguiente manera:
<%
Yo tenue
Para i=1 a 5
%> ¡Hola mundo!
<% Siguiente %>
El motor no analiza estos bloques de script por separado, lo que provoca errores de sintaxis en ambos bloques de script. Entonces llegamos a la siguiente conclusión: no todo el código de script que no es del servidor se enviará al cliente. Es posible que este código de script que no sea del servidor esté restringido por el bloque de script. El servidor definitivamente no se preocupará por la ejecución de los scripts del cliente, pero puede generar diferentes scripts del cliente a través de scripts del lado del servidor.
4. Finalmente, el motor genera un flujo de texto, o el resultado de la ejecución del script, que puede considerarse como una cadena, que es el código de la página web enviada al navegador del cliente. El navegador del cliente muestra la página. En este momento, el código fuente (archivo fuente) de la página no contiene el script del lado del servidor, pero contiene el resultado de la ejecución del script del lado del servidor (esto es obvio).
<%… %> y <script runat=servidor>…</script>
Todos son scripts del lado del servidor que se procesan y ejecutan al mismo tiempo. Se desempeñan como una unidad.
<% … %> y <script language=…>…</script>
El primero es un script del lado del servidor y el segundo es un script del lado del cliente. El primero se ejecuta primero y el segundo después.
De hecho, este no es necesariamente el caso. Es posible que los dos scripts se ejecuten al mismo tiempo, pero los espacios siguen siendo diferentes: el primero se ejecuta en el servidor y el segundo se ejecuta en el. navegador del cliente. Lógicamente, los primeros deben ejecutarse antes que los segundos. Al mismo tiempo, también llegamos a la conclusión: durante la ejecución de la misma página, el script del lado del cliente no puede retroalimentar al script del lado del servidor en cualquier caso, es decir, el cliente busca su libro de visitas y lo envía. Los mensajes nuevos o cualquier valor obtenido por el script del lado del cliente tampoco se pueden procesar en la misma respuesta del servidor.
Acerca de las llamadas a componentes
Tenga en cuenta que los scripts del lado del servidor y los scripts del lado del cliente son scripts. Naturalmente, puede crear componentes xmlhttp, componentes ADODB.Connection, etc., pero no se pueden colocar en ningún lugar.
Si xmlhttp se usa para rastrear páginas web (como colecciones) desde el servidor, debe crearse en el script del servidor. Si se usa para que el ajax del cliente acceda a la página del lado del servidor en segundo plano sin actualizar, entonces se ejecuta. en el cliente y, naturalmente, en el cliente Creado al final.
El componente ADODB.Connection se utiliza para acceder a la base de datos. En términos generales, se crea en el lado del servidor. Después de todo, es el programa asp del lado del servidor el que ejecuta los datos de la base de datos. lado, entonces no hay duda de que se creará en el lado del cliente. Creado en el script del cliente.
En definitiva, cosas contradictorias y cada bando tiene sus propias características. Diferentes cosas tienen diferentes contradicciones; una misma cosa tiene diferentes contradicciones en diferentes procesos y etapas de desarrollo; diferentes contradicciones en una misma cosa y dos aspectos diferentes de una misma contradicción tienen cada uno sus particularidades (pueden omitir a los que no entiendan) Don No mires…). Este principio requiere que nos adhiramos al principio del análisis concreto de problemas específicos y, bajo la guía del principio de universalidad de las contradicciones, analicemos concretamente las particularidades de las contradicciones y encontremos el método correcto para resolverlas. Nos oponemos a utilizar un método para resolver las contradicciones de cosas diferentes. Esto es lo que significa abrir una cerradura con una llave y cantar cualquier canción que escuches en cualquier montaña.
Los scripts VBScript del lado del servidor utilizan el método Server.CreateObject(className) para crear objetos, y los scripts VBScript del lado del cliente utilizan el método CreateObject(className) para crear objetos.
Errores típicos
Copie el código de código de la siguiente manera:
<%
Función TTamaño(b)
'Esta es mi función personalizada
Tamaño T=China
función final
%>
<a href=javascript:<%TSize('Variable')%> >Haga clic aquí para usar la función que definí</a>
Análisis de errores:
Confundir la diferencia entre scripts del lado del servidor y scripts del lado del cliente. Durante la ejecución real, encontraremos que el cliente no recibe ningún código como TSize en absoluto, porque TSize es un programa del lado del servidor procesado por el motor (tenga en cuenta que el procesamiento de funciones del motor es puramente para scripts del lado del servidor). llamadas y no se enviará de vuelta al cliente) desaparece y no es posible que funcione en el cliente. Esto significa que los scripts del lado del cliente no pueden llamar directamente a funciones de los scripts del lado del servidor.
De hecho, este programa tiene un error de sintaxis. Cuando el motor procesa este contenido, primero encuentra el contenido entre <% y%>, es decir, <%TSie('variable')%>. con reglas de sintaxis de VBScript. Bueno, si lo cambia a <%=TSize(variable)%>, no habrá errores de sintaxis en el script del lado del servidor. En este momento, la función TSize puede devolver el valor China normalmente, por lo que el atributo href lo recibe. el cliente está escrito así: javascript: China, no se puede hacer cumplir.
Impacto de los scripts del lado del servidor en los scripts del lado del cliente
Como se mencionó anteriormente, los scripts del lado del servidor se ejecutan lógicamente antes que los scripts del lado del cliente, por lo que un código como este es factible:
Copie el código de código de la siguiente manera:
<%
Yo tenue
Para i=1 a 5
Respuesta.Escribir <tipo de script=texto/javascript> _
& alerta('¡Hola mundo! & i & ')</script>
Próximo
%>
Respecto a la ejecución de Response.Redirect y javascript
Tenga en cuenta que el siguiente código está escrito incorrectamente:
Copie el código de código de la siguiente manera:
<%
Respuesta.Redireccionamiento index.asp
Respuesta.Escribir <tipo de script=texto/javascript> _
& alert('¡Contraseña incorrecta!')</script>
%>
Este es un error común. Los escritores a menudo piensan que escribir código de esta manera hará que el cliente muestre un mensaje de error de contraseña y luego lo redirija a index.asp. De hecho, esto no puede suceder incluso si el orden de las dos líneas. Si se intercambia el código, no sucederá.
El motivo está relacionado con la forma en que el servidor maneja las dos líneas de código. Es imposible que estas dos líneas de código funcionen al mismo tiempo.
Response.Write es enviar un fragmento de texto al cliente. El contenido de este texto puede ser un script. Luego, el navegador del cliente puede ejecutar el script después de recibirlo.
Response.Redirect envía un encabezado HTTP al cliente (¿qué es el encabezado HTTP? Digámoslo de esta manera, por ejemplo, escribir en las cookies del cliente es información del encabezado HTTP, y la información del encabezado HTTP se envía de regreso al cliente antes del cuerpo HTTP Navegador , es por esto que a veces obtenemos un error al modificar las Cookies después de apagar el buffering del servidor, porque el cuerpo ya comenzó a transmitir y no se permite enviar encabezados HTTP. información.), el contenido de la información le dice al navegador del cliente que debe saltar a la página para navegar. Tenga en cuenta que esta información de redireccionamiento entra en vigor de inmediato, lo que significa que esta información de redireccionamiento es exclusiva cuando el búfer está activado, independientemente de. si se ha utilizado Response. Write escribe cuánto contenido se escribe en el búfer. Una vez que se llama a Response.Redirect, el búfer se borrará y esta instrucción de encabezado se enviará al navegador del cliente. Si rastreamos dinámicamente la ejecución del programa, también encontraremos que después de llamar a Response.Redirect, el programa deja de ejecutarse, así que tenga en cuenta que el programa del lado del servidor debe cerrar la conexión de datos y otras operaciones antes de llamar a Response.Redirect.
Entonces, ¿cómo debería modificarse el ejemplo anterior? Si no está dispuesto a modificar index.asp para agregar un mensaje de secuencia de comandos, solo puede ejecutar la instrucción de redirección en la secuencia de comandos del cliente, de esta manera:
Copie el código de código de la siguiente manera:
<%
Respuesta.Escribir <tipo de script=texto/javascript> _
& alerta('!');ubicación.href='index.asp'</script>
%>