يقوم IIS بالبحث عن ملف ASP وإرساله إلى محرك ASP (عادةً ASP.DLL) للمعالجة، وما إلى ذلك. ويمكن للأصدقاء الذين يحتاجون إليه الرجوع إليه أولاً، دعونا نفهم عملية تنفيذ صفحة ASP.
1. يبحث IIS عن ملف ASP ويرسله إلى محرك ASP (عادةً ASP.DLL) للمعالجة.
2. يفتح المحرك ملف ASP ويجد المحتوى بين <% و%>، وبالطبع المحتوى بين <script runAt=server> والمحتوى المقابل </script>، وتسمى هذه المحتويات بكتل البرامج النصية. يتم تحليل المحتوى الموجود في كتلة البرنامج النصي فقط بواسطة المحرك، ويتم تجاهل المحتوى الآخر وإدراجه بين كتل البرنامج النصي كأحرف لا معنى لها. من الضروري توضيح أن المحتوى الذي يتم تحليله هو في الواقع أكثر من ذلك. يتم أيضًا تضمين ملفات التضمين من جانب الخادم من فئة <!--#include ***--> بواسطة المحرك. إذا قرأت الكثير من البرامج، فستعرف أيضًا أن بعض كائنات <object> التي تم وضع علامة على سماتها runAt كخادم ستتم معالجتها أيضًا.
3. يقوم المحرك بتنفيذ البرامج النصية في كتلة البرنامج النصي، ويتم تنفيذ هذه البرامج النصية من جانب الخادم ككل، وهذا يعني أنه يمكن كتابة التعليمات البرمجية التالية:
انسخ رمز الكود كما يلي:
<%
خافت ط
لأني = 1 إلى 5
%> أهلاً بالعالم!
<% التالي %>
لا يقوم المحرك بتحليل كتل البرامج النصية هذه بشكل منفصل، مما يتسبب في حدوث أخطاء في بناء الجملة في كلا كتل البرامج النصية. لذلك توصلنا إلى الاستنتاج التالي: لن يتم إرسال جميع التعليمات البرمجية النصية غير الخاصة بالخادم إلى العميل. من الممكن أن يتم تقييد التعليمات البرمجية النصية غير الخاصة بالخادم بواسطة كتلة البرنامج النصي. بالتأكيد لن يقلق الخادم بشأن تنفيذ البرامج النصية للعميل، ولكن يمكنه إخراج نصوص برمجية مختلفة للعميل من خلال البرامج النصية من جانب الخادم.
4. أخيرًا، يقوم المحرك بإنشاء دفق نصي، أو نتيجة تنفيذ البرنامج النصي، والتي يمكن اعتبارها سلسلة، وهي عبارة عن رمز صفحة الويب المرسلة إلى متصفح العميل. يعرض متصفح العميل الصفحة في هذا الوقت، لا يحتوي الكود المصدري (الملف المصدر) للصفحة على برنامج نصي من جانب الخادم، ولكنه يحتوي على نتيجة تنفيذ البرنامج النصي من جانب الخادم (وهذا واضح).
<% … %> و <script runat=server>…</script>
إنها جميعها نصوص برمجية من جانب الخادم تتم معالجتها وتنفيذها في نفس الوقت. يؤدون كوحدة واحدة.
<%…%> و<script language=…>…</script>
الأول عبارة عن برنامج نصي من جانب الخادم والأخير عبارة عن برنامج نصي من جانب العميل. يتم تنفيذ الأول أولاً ويتم تنفيذ الأخير لاحقًا.
في الواقع، ليس هذا هو الحال بالضرورة، فمن الممكن تنفيذ النصين في نفس الوقت، لكن المسافات مختلفة: يتم تنفيذ الأول على الخادم، ويتم تنفيذ الأخير في متصفح العميل. يجب منطقيا أن يتم تنفيذ الأول في وقت سابق من الأخير. في الوقت نفسه، توصلنا أيضًا إلى الاستنتاج: أثناء تنفيذ نفس الصفحة، لا يمكن للبرنامج النصي من جانب العميل الرد على البرنامج النصي من جانب الخادم في أي حال، وهذا يعني أن العميل يتصفح سجل الزوار الخاص بك ويرسله لا يمكن معالجة الرسائل الجديدة أو أي قيمة تم الحصول عليها بواسطة البرنامج النصي من جانب العميل في نفس استجابة الخادم.
حول استدعاءات المكونات
لاحظ أن البرامج النصية من جانب الخادم والبرامج النصية من جانب العميل كلاهما نصوص برمجية، وبطبيعة الحال، يمكنك إنشاء مكونات xmlhttp، ومكونات ADODB.Connection، وما إلى ذلك، ولكن لا يمكن وضعها في أي مكان.
إذا تم استخدام xmlhttp للزحف إلى صفحات الويب (مثل المجموعة) من الخادم، فيجب إنشاؤه في البرنامج النصي للخادم، وإذا تم استخدامه لأياكس العميل للوصول إلى الصفحة من جانب الخادم في الخلفية دون تحديث، فسيتم تشغيله. على العميل، وبطبيعة الحال على العميل تم إنشاؤه في النهاية.
يتم استخدام مكون ADODB.Connection للوصول إلى قاعدة البيانات، بشكل عام، يتم إنشاؤه من جانب الخادم، فهو برنامج asp من جانب الخادم الذي يقوم بتشغيل بيانات قاعدة البيانات الجانب، فلا شك أنه سيتم إنشاؤه من جانب العميل.
باختصار أشياء متناقضة ولكل طرف خصائصه. الأشياء المختلفة لها تناقضات مختلفة؛ نفس الشيء لديه تناقضات مختلفة في عمليات ومراحل التطور المختلفة؛ تناقضات مختلفة في نفس الشيء وجانبان مختلفان من نفس التناقض لكل منهما خصائصه الخاصة (يمكنك حذف أولئك الذين لا يفهمون). 'لا تنظر...). يتطلب هذا المبدأ منا الالتزام بمبدأ التحليل الملموس لمشاكل محددة، وبتوجيه من مبدأ عالمية التناقضات، تحليل خصوصية التناقضات بشكل ملموس وإيجاد الطريقة الصحيحة لحلها. نحن نعارض استخدام طريقة واحدة لحل تناقضات الأشياء المختلفة. هذا هو ما يعنيه أن تفتح قفلًا بمفتاح وتغني أي أغنية تذهب إليها في أي جبل.
تستخدم البرامج النصية VBScript من جانب الخادم الأسلوب Server.CreateObject(className) لإنشاء الكائنات، وتستخدم البرامج النصية VBScript من جانب العميل الأسلوب CreateObject(className) لإنشاء الكائنات.
أخطاء نموذجية
انسخ رمز الكود كما يلي:
<%
الوظيفة: الحجم (ب)
"هذه هي وظيفتي المخصصة."
TSize = الصين
وظيفة النهاية
%>
<a href=javascript:<%TSize('Variable')%> >انقر هنا لاستخدام الوظيفة التي حددتها</a>
تحليل الخطأ:
الخلط بين البرامج النصية من جانب الخادم والبرامج النصية من جانب العميل. أثناء التنفيذ الفعلي سنجد أن العميل لا يتلقى أي كود مثل TSize على الإطلاق، لأن TSize هو برنامج من جانب الخادم تتم معالجته بواسطة المحرك (لاحظ أن معالجة المحرك للوظائف تكون بحتة من البرنامج النصي من جانب الخادم) المكالمات ولن يتم إعادتها إلى العميل) تختفي ولا يمكن أن تعمل على العميل. وهذا يعني أن البرامج النصية من جانب العميل لا يمكنها استدعاء وظائف البرامج النصية من جانب الخادم مباشرة.
في الواقع، يحتوي هذا البرنامج على خطأ في بناء الجملة عندما يقوم المحرك بمعالجة هذا المحتوى، فإنه يعثر أولاً على المحتوى بين <% و%>، أي <%TSize('variable')%>. ومن الواضح أن هذا المحتوى لا يتوافق مع قواعد بناء الجملة VBScript. حسنًا، إذا قمت بتغييره إلى <%=TSize(variable)%>، فلن تكون هناك أخطاء في بناء الجملة في البرنامج النصي من جانب الخادم. في هذا الوقت، يمكن لوظيفة TSize إرجاع القيمة China بشكل طبيعي، وبالتالي يتم استلام سمة href تتم كتابة العميل على النحو التالي: javascript: China، غير قابل للتنفيذ.
تأثير البرامج النصية من جانب الخادم على البرامج النصية من جانب العميل
كما ذكرنا من قبل، يتم تنفيذ البرامج النصية من جانب الخادم بشكل منطقي قبل البرامج النصية من جانب العميل، لذلك يكون تنفيذ التعليمات البرمجية مثل هذا ممكنًا:
انسخ رمز الكود كما يلي:
<%
خافت ط
لأني = 1 إلى 5
الاستجابة.اكتب <script type=text/javascript> _
& تنبيه ("مرحبًا بالعالم! & i & ')</script>
التالي
%>
فيما يتعلق بتنفيذ Response.Redirect وجافا سكريبت
لاحظ أن الكود التالي مكتوب بشكل غير صحيح:
انسخ رمز الكود كما يلي:
<%
Response.Redirect Index.asp
الاستجابة.اكتب <script type=text/javascript> _
& تنبيه ("كلمة المرور خاطئة!")</script>
%>
هذا خطأ شائع. غالبًا ما يعتقد الكتاب أن كتابة التعليمات البرمجية بهذه الطريقة ستؤدي إلى قيام العميل بإظهار رسالة خطأ في كلمة المرور ثم إعادة التوجيه إلى ملف Index.asp. في الواقع، لا يمكن أن يحدث هذا حتى لو كان ترتيب السطرين إذا تم تبادل الكود، فلن يحدث هذا.
يرتبط السبب بالطريقة التي يتعامل بها الخادم مع سطرين من التعليمات البرمجية. من المستحيل أن يعمل هذين السطرين من التعليمات البرمجية في نفس الوقت.
Response.Write هو إرسال جزء من النص إلى العميل، ويمكن أن يكون محتوى هذا النص عبارة عن برنامج نصي، ثم يمكن لمتصفح العميل تنفيذ البرنامج النصي بعد استلامه.
يرسل Response.Redirect رأس HTTP إلى العميل (ما هو رأس HTTP؟ دعنا نضع الأمر بهذه الطريقة، على سبيل المثال، الكتابة إلى ملفات تعريف الارتباط للعميل هي معلومات رأس HTTP، ويتم إرسال معلومات رأس HTTP مرة أخرى إلى العميل قبل متصفح HTTP الأساسي ولهذا السبب نتلقى أحيانًا خطأ عند تعديل ملفات تعريف الارتباط بعد إيقاف التخزين المؤقت للخادم، لأن النص قد بدأ بالفعل في الإرسال ولا يُسمح بإرسال رؤوس HTTP. information.) يخبر محتوى المعلومات متصفح العميل بأنه يجب عليه الانتقال إلى الصفحة للتصفح. لاحظ أن معلومات إعادة التوجيه هذه تكون فعالة على الفور، مما يعني أن معلومات إعادة التوجيه هذه تكون حصرية عند تشغيل المخزن المؤقت ما إذا كان قد تم استخدام الاستجابة أم لا. يكتب .Write مقدار المحتوى المكتوب في المخزن المؤقت بمجرد استدعاء Response.Redirect، سيتم مسح المخزن المؤقت وسيتم إرسال تعليمات الرأس هذه إلى متصفح العميل. إذا قمنا بتتبع تنفيذ البرنامج ديناميكيًا، فسنجد أيضًا أنه بعد استدعاء Response.Redirect، يتوقف البرنامج عن التنفيذ، لذا يرجى ملاحظة أن البرنامج من جانب الخادم يجب أن يغلق اتصال البيانات والعمليات الأخرى قبل استدعاء Response.Redirect.
فكيف ينبغي تعديل المثال أعلاه؟ إذا لم تكن ترغب في تعديل ملف Index.asp لإضافة موجه برنامج نصي، فيمكنك فقط تنفيذ تعليمات إعادة التوجيه في البرنامج النصي للعميل، مثل هذا:
انسخ رمز الكود كما يلي:
<%
الاستجابة.اكتب <script type=text/javascript> _
& تنبيه('!');location.href='index.asp'</script>
%>