O IIS encontra o arquivo ASP e o envia ao mecanismo ASP (geralmente ASP.DLL) para processamento, etc. Amigos que precisam dele podem consultá-lo. Primeiro, vamos entender o processo de execução da página ASP.
1. O IIS encontra o arquivo ASP e o envia ao mecanismo ASP (geralmente ASP.DLL) para processamento.
2. O mecanismo abre o arquivo ASP e encontra o conteúdo entre <% e %> e, claro, o conteúdo entre <script runAt=server> e o </script> correspondente. Esses conteúdos são chamados de blocos de script. Somente o conteúdo do bloco de script é analisado pelo mecanismo, e outros conteúdos são ignorados e inseridos entre os blocos de script como caracteres sem sentido. É necessário explicar que na verdade o conteúdo que está sendo analisado é mais do que isso. Os arquivos de inclusão do lado do servidor da classe <!--#include ***--> também são incluídos e processados pelo mecanismo. Se você ler muitos programas, também saberá que alguns objetos <object> cujos atributos runAt estão marcados como Servidor também serão processados. Não os discutiremos em detalhes aqui.
3. O mecanismo executa os scripts no bloco de scripts. Esses scripts do lado do servidor são executados como um todo.
Copie o código do código da seguinte forma:
<%
Escureça eu
Para i = 1 a 5
%> Olá, mundo!
<% Próximo %>
O mecanismo não analisa esses blocos de script separadamente, causando erros de sintaxe em ambos os blocos de script. Portanto, chegamos à seguinte conclusão: nem todo código de script que não seja do servidor será enviado ao cliente. É possível que esse código de script que não seja do servidor seja restringido pelo bloco de script. O servidor definitivamente não se preocupará com a execução de scripts de cliente, mas pode gerar diferentes scripts de cliente por meio de scripts do lado do servidor.
4. Por fim, o mecanismo gera um fluxo de texto, ou resultado da execução do script, que pode ser considerado como uma string, que é o código da página web enviada ao navegador do cliente. O navegador do cliente exibe a página. Neste momento, o código-fonte (arquivo fonte) da página não contém o script do lado do servidor, mas contém o resultado da execução do script do lado do servidor (isso é óbvio).
<% … %> e <script runat=server>…</script>
Todos são scripts do lado do servidor que são processados e executados ao mesmo tempo. Eles atuam como uma unidade.
<%… %> e <linguagem de script=…>…</script>
O primeiro é um script do lado do servidor e o último é um script do lado do cliente. O primeiro é executado primeiro e o último é executado posteriormente.
Na verdade, não é necessariamente assim. É possível que os dois scripts sejam executados ao mesmo tempo, mas os espaços ainda são diferentes: o primeiro é executado no servidor e o segundo é executado no. navegador do cliente. O primeiro deve logicamente ser executado antes do último. Ao mesmo tempo, também chegamos à conclusão: durante a execução da mesma página, o script do lado do cliente não pode realimentar o script do lado do servidor em nenhum caso. Ou seja, o cliente navega em seu livro de visitas e o envia. novas mensagens ou qualquer valor obtido pelo script do lado do cliente. Nenhum dos dois pode ser processado na mesma resposta do servidor.
Sobre chamadas de componentes
Observe que scripts do lado do servidor e scripts do lado do cliente são scripts. Naturalmente, você pode criar componentes xmlhttp, componentes ADODB.Connection, etc., mas eles não podem ser colocados em qualquer lugar.
Se xmlhttp for usado para rastrear páginas da web (como coleção) do servidor, ele deverá ser criado no script do servidor. Se for usado para o ajax do cliente acessar a página do lado do servidor em segundo plano sem atualização, ele será executado. no cliente e, naturalmente, no cliente Criado no final.
O componente ADODB.Connection é usado para acessar o banco de dados. Geralmente, ele é criado no lado do servidor. Afinal, é o programa asp do lado do servidor que executa os dados do banco de dados. lado, então não há dúvida de que será criado no lado do cliente Criado no script do cliente.
Enfim, coisas contraditórias e cada lado tem características próprias. Coisas diferentes têm contradições diferentes; a mesma coisa tem contradições diferentes em processos e estágios de desenvolvimento diferentes, contradições diferentes na mesma coisa e dois aspectos diferentes da mesma contradição, cada um com suas próprias particularidades (você pode omitir aqueles que não entendem). não olhe…). Este princípio exige que sigamos o princípio da análise concreta de problemas específicos e, sob a orientação do princípio da universalidade das contradições, analisemos concretamente a particularidade das contradições e encontremos o método correcto para as resolver. Opomo-nos a usar um método para resolver as contradições de coisas diferentes. Isto é o que significa abrir uma fechadura com uma chave e cantar qualquer música que você vá em qualquer montanha.
Os scripts VBScript do lado do servidor usam o método Server.CreateObject(className) para criar objetos, e os scripts VBScript do lado do cliente usam o método CreateObject(className) para criar objetos.
Erros típicos
Copie o código do código da seguinte forma:
<%
FunçãoTSize(b)
'Esta é minha função personalizada
Tamanho TS=China
função final
%>
<a href=javascript:<%TSize('Variable')%> >Clique aqui para usar a função que defini</a>
Análise de erros:
Confundindo a diferença entre scripts do lado do servidor e scripts do lado do cliente. Durante a execução real, descobriremos que o cliente não recebe nenhum código como TSize, porque TSize é um programa do lado do servidor que é processado pelo mecanismo (observe que o processamento de funções do mecanismo é puramente para script do lado do servidor chamadas e não serão enviadas de volta ao cliente) desaparece e não pode funcionar no cliente. Isso significa que os scripts do lado do cliente não podem chamar diretamente funções de scripts do lado do servidor.
Na verdade, este programa apresenta um erro de sintaxe. Quando o mecanismo processa esse conteúdo, ele primeiro encontra o conteúdo entre <% e %>, ou seja, <%TSize('variable')%>. Obviamente, esse conteúdo não está em conformidade. com regras de sintaxe VBScript. Bem, se você alterar para <%=TSize(variable)%>, não haverá erros de sintaxe no script do lado do servidor. Neste momento, a função TSize pode retornar o valor China normalmente, portanto o atributo href recebido por. o cliente está escrito assim: javascript: China, é inexequível.
Impacto dos scripts do lado do servidor nos scripts do lado do cliente
Como mencionado anteriormente, os scripts do lado do servidor são executados logicamente antes dos scripts do lado do cliente, portanto, códigos como este são viáveis:
Copie o código do código da seguinte forma:
<%
Escureça eu
Para i = 1 a 5
Response.Write <tipo de script = texto/javascript> _
& alert('Olá mundo! & i & ')</script>
Próximo
%>
Em relação à execução de Response.Redirect e javascript
Observe que o código a seguir está escrito incorretamente:
Copie o código do código da seguinte forma:
<%
Resposta.Redirect index.asp
Response.Write <tipo de script = texto/javascript> _
& alert('Senha errada!')</script>
%>
Este é um erro comum. Os escritores geralmente pensam que escrever código dessa maneira fará com que o cliente exiba um prompt de erro de senha e, em seguida, redirecione para index.asp. Na verdade, isso não pode acontecer. código for trocado, isso não acontecerá.
O motivo está relacionado à forma como o servidor lida com as duas linhas de código. É impossível que essas duas linhas de código funcionem ao mesmo tempo.
Response.Write é enviar um trecho de texto ao cliente. O conteúdo deste texto pode ser um script. Então, o navegador do cliente pode executar o script após recebê-lo.
Response.Redirect envia um cabeçalho HTTP para o cliente (o que é cabeçalho HTTP? Vamos colocar desta forma, por exemplo, escrever em cookies do cliente são informações do cabeçalho HTTP, e as informações do cabeçalho HTTP são enviadas de volta ao cliente antes do corpo HTTP Navegador , é por isso que às vezes recebemos um erro ao modificar os Cookies após desligar o buffer do servidor, porque o corpo já começou a transmitir e os cabeçalhos HTTP não podem ser enviados. informações.), o conteúdo das informações informa ao navegador do cliente que ele deve ir para a página para navegar. Observe que essas informações de redirecionamento têm efeito imediato, o que significa que essas informações de redirecionamento são exclusivas quando o buffer é ativado, independentemente de. se Response foi usado. .Write grava quanto conteúdo é gravado no buffer. Assim que Response.Redirect for chamado, o buffer será limpo e esta instrução de cabeçalho será enviada ao navegador do cliente. Se rastrearmos dinamicamente a execução do programa, também descobriremos que após chamar Response.Redirect, o programa para de ser executado, portanto, observe que o programa do lado do servidor deve fechar a conexão de dados e outras operações antes de chamar Response.Redirect.
Então, como o exemplo acima deve ser modificado? Se não quiser modificar o index.asp para adicionar um prompt de script, você só poderá executar a instrução de redirecionamento no script do cliente, assim:
Copie o código do código da seguinte forma:
<%
Response.Write <tipo de script = texto/javascript> _
& alert('!');location.href='index.asp'</script>
%>