IIS は ASP ファイルを見つけて、処理などのために ASP エンジン (通常は ASP.DLL) に送信します。それを必要とする友人はそれを参照できます。まず、ASP ページの実行プロセスを理解しましょう。
1. IIS は ASP ファイルを見つけて、処理のために ASP エンジン (通常は ASP.DLL) に送信します。
2. エンジンは ASP ファイルを開き、<% と %> の間のコンテンツ、そしてもちろん <script runAt=server> と対応する </script> の間のコンテンツを検索します。これらのコンテンツはスクリプト ブロックと呼ばれます。スクリプト ブロック内のコンテンツのみがエンジンによって解析され、他のコンテンツは無視され、無意味な文字としてスクリプト ブロックの間に挿入されます。実際には、解析されるコンテンツはこれだけではなく、<!--#include ***--> クラスのサーバー側インクルード ファイルも含まれ、エンジンによって処理されることを説明する必要があります。プログラムをよく読んでいると、runAt 属性が Server としてマークされている一部の <object> オブジェクトも処理されることがわかります。ここでは詳しく説明しません。
3. エンジンはスクリプト ブロック内のスクリプトを実行します。つまり、次のコードを記述できます。
次のようにコードをコピーします。
<%
薄暗い私
i=1～5の場合
%> こんにちは、世界!
<% 次へ %>
エンジンはこれらのスクリプト ブロックを個別に解析しないため、両方のスクリプト ブロックで構文エラーが発生します。したがって、次の結論に達します。すべての非サーバー スクリプト コードがクライアントに送信されるわけではありません。この非サーバー スクリプト コードはスクリプト ブロックによって制限される可能性があります。サーバーはクライアント スクリプトの実行をまったく心配しませんが、サーバー側スクリプトを通じてさまざまなクライアント スクリプトを出力できます。
4. 最後に、エンジンはテキスト ストリーム、つまりスクリプトの実行結果を生成します。これは、クライアント ブラウザに送信される Web ページのコードである文字列とみなすことができます。このとき、クライアントのブラウザはページを表示しますが、そのページのソースコード（ソースファイル）にはサーバーサイドスクリプトは含まれていませんが、サーバーサイドスクリプトの実行結果が含まれています（当たり前ですが）。
<% … %> および <script runat=server>…</script>
これらはすべて、同時に処理および実行されるサーバー側のスクリプトです。彼らはユニットとしてパフォーマンスします。
<% … %> および <script language=…>…</script>
前者はサーバー側のスクリプト、後者はクライアント側のスクリプトです。前者は最初に実行され、後者は後で実行されます。
実際、これは必ずしも当てはまりますが、2 つのスクリプトを同時に実行することは可能ですが、スペースは異なります。前者はサーバー上で実行され、後者はサーバー内で実行されます。クライアントブラウザ。前者は論理的に後者よりも早く実行する必要があります。同時に、同じページの実行中、クライアント側のスクリプトはいかなる場合でもサーバー側のスクリプトにフィードバックすることはできない、つまり、クライアントはゲストブックを参照して送信するという結論に達しました。新しいメッセージまたはクライアント側スクリプトによって取得された値は、どちらも同じサーバー応答で処理できません。
コンポーネント呼び出しについて
サーバー側スクリプトとクライアント側スクリプトはどちらもスクリプトであることに注意してください。当然、xmlhttp コンポーネントや ADODB.Connection コンポーネントなどを作成できますが、それらはどこにも配置できません。
xmlhttp を使用してサーバーから Web ページ (コレクションなど) をクロールする場合は、クライアントの ajax が更新せずにバックグラウンドでサーバー側のページにアクセスするために xmlhttp を使用する場合は、サーバー スクリプト内で xmlhttp を作成する必要があります。クライアント上で、そして当然クライアント上で最後に作成されます。
ADODB.Connection コンポーネントはデータベースにアクセスするために使用されます。結局のところ、データベース データを実行するのはサーバー側の ASP プログラムです。側の場合は、クライアント側で作成されることは間違いありません。クライアント スクリプトで作成されます。
つまり、相反するもの、それぞれの側面にはそれぞれの特徴があるのです。異なる事物には異なる矛盾があり、同じ事物の発展の過程や段階によっては異なる矛盾があり、同じ矛盾の二つの異なる側面にはそれぞれ異なる特殊性がある（理解できない人は省いてもよい） ドン見てください…）。この原則は、われわれが具体的な問題を具体的に分析する原則を堅持し、矛盾の普遍性の原則に導かれて、矛盾の特殊性を具体的に分析し、矛盾を解決する正しい方法を見出しなければならない。私たちは、異なる事柄の矛盾を解決するために 1 つの方法を使用することに反対します。どこの山に行っても、鍵で鍵を開けてどんな歌を歌うかというと、こういうことだ。
サーバー側 VBScript スクリプトは Server.CreateObject(className) メソッドを使用してオブジェクトを作成し、クライアント側 VBScript スクリプトは CreateObject(className) メソッドを使用してオブジェクトを作成します。
典型的なエラー
次のようにコードをコピーします。
<%
関数Tサイズ(b)
'これは私のカスタム関数です
Tサイズ=中国
終了関数
%>
<a href=javascript:<%TSize('Variable')%> >ここをクリックして、定義した関数を使用します</a>
エラー分析:
サーバー側スクリプトとクライアント側スクリプトの違いが混同されています。実際の実行中、TSize はエンジンによって処理されるサーバー側プログラムであるため、クライアントは TSize などのコードをまったく受け取らないことがわかります (エンジンによる関数の処理は純粋にサーバー側スクリプト用であることに注意してください)呼び出しは行われ、クライアントには送信されません）が失われ、クライアント上で機能する可能性はありません。これは、クライアント側スクリプトがサーバー側スクリプトの関数を直接呼び出すことができないことを意味します。
実際、このプログラムには構文エラーがあります。エンジンはこのコンテンツを処理するときに、最初に <% と %> の間のコンテンツ、つまり <%TSize('variable')%> を見つけます。明らかに、このコンテンツは準拠していません。 VBScript 構文ルールを使用します。さて、これを <%=TSize(variable)%> に変更すると、サーバー側スクリプトで構文エラーは発生しません。この時点で、TSize 関数は値 China を正常に返すことができるため、href 属性は受け取ります。クライアントは次のように記述されます: JavaScript: China, is unenforceable.
サーバー側スクリプトがクライアント側スクリプトに与える影響
前述したように、サーバー側のスクリプトはクライアント側のスクリプトよりも論理的に先に実行されるため、次のようなコードが可能です。
次のようにコードをコピーします。
<%
薄暗い私
i=1～5の場合
Response.Write <script type=text/javascript> _
&alert('Hello World! & i & ')</script>
次
%>
Response.RedirectとJavaScriptの実行について
次のコードは間違って書かれていることに注意してください。
次のようにコードをコピーします。
<%
Response.リダイレクトインデックス.asp
Response.Write <script type=text/javascript> _
&alert('パスワードが違います!')</script>
%>
これはよくある間違いです。このようにコードを記述すると、クライアントでパスワード エラー プロンプトが表示され、index.asp にリダイレクトされると考えられます。実際には、このようなことは起こりません。コードが交換されると、この効果は発生しません。
その理由は、サーバーが 2 行のコードを処理する方法に関連しています。これら 2 行のコードが同時に動作することは不可能です。
Response.Write は、テキストの一部をクライアントに送信します。このテキストの内容は、受信後にのみ実行できることに注意してください。
Response.Redirect は、HTTP ヘッダーをクライアントに送信します (HTTP ヘッダーとは何ですか? たとえば、クライアントの Cookie への書き込みは HTTP ヘッダー情報であり、HTTP ヘッダー情報は HTTP 本文ブラウザの前にクライアントに返送されます)サーバーのバッファリングをオフにした後に Cookie を変更するとエラーが発生することがあります。これは、本文がすでに送信を開始しており、HTTP ヘッダーの送信が許可されていないためです。情報。)、情報の内容は、参照するページにジャンプする必要があることをクライアントのブラウザーに伝えます。このリダイレクト情報は、バッファーがオンになっているときは排他的であることを意味します。 Response.Redirect が呼び出されると、バッファはクリアされ、このヘッダー命令がクライアント ブラウザに送信されます。プログラムの実行を動的に追跡すると、Response.Redirect を呼び出した後にプログラムが実行を停止することもわかります。そのため、サーバー側プログラムは、Response.Redirect を呼び出す前にデータ接続とその他の操作を閉じる必要があることに注意してください。
では、上記の例をどのように変更すればよいでしょうか? Index.asp を変更してスクリプト プロンプトを追加したくない場合は、次のようにクライアント スクリプトでリダイレクト命令を実行することしかできません。
次のようにコードをコピーします。
<%
Response.Write <script type=text/javascript> _
&alert('!');location.href='index.asp'</script>
%>