IIS ค้นหาไฟล์ ASP และส่งไปยังกลไก ASP (โดยปกติคือ ASP.DLL) เพื่อประมวลผล ฯลฯ เพื่อนๆ ที่ต้องการไฟล์ดังกล่าวสามารถอ้างอิงถึงมันได้ ก่อนอื่น เรามาทำความเข้าใจกระบวนการดำเนินการเพจ ASP กันก่อน
1. IIS ค้นหาไฟล์ ASP และส่งไปยังกลไก ASP (โดยปกติคือ ASP.DLL) เพื่อประมวลผล
2. เอ็นจิ้นเปิดไฟล์ ASP และค้นหาเนื้อหาระหว่าง <% ถึง %> และแน่นอนว่าเนื้อหาระหว่าง <script runAt=server> และ </script> ที่เกี่ยวข้อง เนื้อหาเหล่านี้เรียกว่าบล็อกสคริปต์ เฉพาะเนื้อหาในบล็อกสคริปต์เท่านั้นที่จะถูกแยกวิเคราะห์โดยกลไกจัดการ และเนื้อหาอื่นๆ จะถูกละเว้นและแทรกระหว่างบล็อกสคริปต์เป็นอักขระที่ไม่มีความหมาย จำเป็นต้องอธิบายว่า ที่จริงแล้ว เนื้อหาที่กำลังแยกวิเคราะห์มีมากกว่านี้ ไฟล์ฝั่งเซิร์ฟเวอร์รวมของคลาส <!--#include ***--> ก็ถูกรวมและประมวลผลโดยกลไกด้วย หากคุณอ่านโปรแกรมจำนวนมาก คุณจะรู้ด้วยว่าอ็อบเจ็กต์ <object> บางตัวที่มีแอตทริบิวต์ runAt ถูกทำเครื่องหมายเป็นเซิร์ฟเวอร์ก็จะได้รับการประมวลผลเช่นกัน เราจะไม่พูดถึงพวกมันในเชิงลึกที่นี่
3. กลไกดำเนินการสคริปต์ในบล็อกสคริปต์ สคริปต์ฝั่งเซิร์ฟเวอร์เหล่านี้ถูกดำเนินการโดยรวม กล่าวคือ สามารถเขียนโค้ดต่อไปนี้ได้:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
ดิม ไอ
สำหรับ i=1 ถึง 5
%> สวัสดีชาวโลก!
<% ถัดไป %>
กลไกจัดการไม่แยกวิเคราะห์บล็อกสคริปต์เหล่านี้แยกกัน ทำให้เกิดข้อผิดพลาดทางไวยากรณ์ในบล็อกสคริปต์ทั้งสอง ดังนั้นเราจึงได้ข้อสรุปดังต่อไปนี้: โค้ดสคริปต์ที่ไม่ใช่เซิร์ฟเวอร์ทั้งหมดจะไม่ถูกส่งไปยังไคลเอนต์ เป็นไปได้ว่าโค้ดสคริปต์ที่ไม่ใช่เซิร์ฟเวอร์นี้อาจถูกจำกัดโดยบล็อกสคริปต์ เซิร์ฟเวอร์จะไม่ต้องกังวลกับการทำงานของสคริปต์ไคลเอนต์อย่างแน่นอน แต่สามารถส่งออกสคริปต์ไคลเอนต์ที่แตกต่างกันผ่านสคริปต์ฝั่งเซิร์ฟเวอร์
4. ในที่สุด เอ็นจิ้นจะสร้างสตรีมข้อความหรือผลลัพธ์การทำงานของสคริปต์ ซึ่งถือได้ว่าเป็นสตริง ซึ่งเป็นโค้ดของหน้าเว็บที่ส่งไปยังเบราว์เซอร์ไคลเอ็นต์ เบราว์เซอร์ไคลเอนต์แสดงเพจ ในขณะนี้ ซอร์สโค้ด (ไฟล์ต้นฉบับ) ของเพจไม่มีสคริปต์ฝั่งเซิร์ฟเวอร์ แต่มีผลการดำเนินการของสคริปต์ฝั่งเซิร์ฟเวอร์ (ซึ่งชัดเจน)
<% … %> และ <script runat=server>…</script>
เป็นสคริปต์ฝั่งเซิร์ฟเวอร์ทั้งหมดที่ได้รับการประมวลผลและดำเนินการในเวลาเดียวกัน พวกเขาแสดงเป็นหน่วย
<% … %> และ <script language=…>…</script>
แบบแรกเป็นสคริปต์ฝั่งเซิร์ฟเวอร์และแบบหลังเป็นสคริปต์ฝั่งไคลเอ็นต์ แบบแรกจะถูกดำเนินการก่อน และแบบหลังจะถูกดำเนินการในภายหลัง
ในความเป็นจริง ไม่จำเป็นต้องเป็นเช่นนั้น เป็นไปได้ที่สคริปต์ทั้งสองจะถูกดำเนินการพร้อมกัน แต่ช่องว่างยังคงอยู่: สคริปต์แรกถูกดำเนินการบนเซิร์ฟเวอร์ และสคริปต์หลังถูกดำเนินการใน เบราว์เซอร์ไคลเอ็นต์ อย่างแรกจะต้องดำเนินการอย่างมีเหตุผลเร็วกว่าอย่างหลัง ในเวลาเดียวกัน เราก็ได้ข้อสรุป: ในระหว่างการดำเนินการของหน้าเดียวกัน สคริปต์ฝั่งไคลเอ็นต์ไม่สามารถป้อนกลับไปยังสคริปต์ฝั่งเซิร์ฟเวอร์ได้ไม่ว่าในกรณีใด กล่าวคือ ลูกค้าเรียกดูสมุดเยี่ยมของคุณและส่ง ข้อความใหม่หรือค่าใดๆ ที่ได้รับจากสคริปต์ฝั่งไคลเอ็นต์ ไม่สามารถประมวลผลในการตอบกลับของเซิร์ฟเวอร์เดียวกันได้
เกี่ยวกับการเรียกส่วนประกอบ
โปรดทราบว่าสคริปต์ฝั่งเซิร์ฟเวอร์และสคริปต์ฝั่งไคลเอ็นต์นั้นเป็นสคริปต์ทั้งคู่ โดยปกติแล้ว คุณสามารถสร้างส่วนประกอบ xmlhttp, ส่วนประกอบ ADODB.Connection ฯลฯ ได้ แต่ไม่สามารถวางไว้ที่ใดก็ได้
หากใช้ xmlhttp เพื่อรวบรวมข้อมูลหน้าเว็บ (เช่น คอลเลกชัน) จากเซิร์ฟเวอร์ จะต้องสร้างขึ้นในสคริปต์เซิร์ฟเวอร์ หากใช้สำหรับ ajax ของไคลเอ็นต์เพื่อเข้าถึงเพจฝั่งเซิร์ฟเวอร์ในเบื้องหลังโดยไม่ต้องรีเฟรช เพจนั้นจะรัน บนไคลเอนต์และตามธรรมชาติบนไคลเอนต์ที่สร้างขึ้นในตอนท้าย
ส่วนประกอบ ADODB.Connection ใช้เพื่อเข้าถึงฐานข้อมูล โดยทั่วไปแล้วจะถูกสร้างขึ้นบนฝั่งเซิร์ฟเวอร์ ท้ายที่สุดแล้ว มันเป็นโปรแกรม asp ฝั่งเซิร์ฟเวอร์ที่เรียกใช้ข้อมูลฐานข้อมูล แต่หากฐานข้อมูลของคุณเชื่อมต่อกับไคลเอนต์จริงๆ ด้านข้าง ไม่ต้องสงสัยเลยว่ามันจะถูกสร้างขึ้นในฝั่งไคลเอ็นต์
สรุปคือสิ่งที่ขัดแย้งกันและแต่ละฝ่ายมีลักษณะเฉพาะของตัวเอง สิ่งที่แตกต่างกันมีความขัดแย้งที่แตกต่างกัน สิ่งเดียวกันมีความขัดแย้งที่แตกต่างกันในกระบวนการและขั้นตอนการพัฒนาที่แตกต่างกัน ความขัดแย้งที่แตกต่างกันในสิ่งเดียวกัน และความขัดแย้งที่เหมือนกันสองด้านต่างก็มีลักษณะเฉพาะของตัวเอง (คุณสามารถละเว้นผู้ที่ไม่เข้าใจได้) อย่ามอง…) หลักการนี้กำหนดให้เราต้องยึดหลักการวิเคราะห์ปัญหาเฉพาะอย่างเป็นรูปธรรม และภายใต้การแนะนำของหลักความเป็นสากลของความขัดแย้ง ให้วิเคราะห์ลักษณะเฉพาะของความขัดแย้งอย่างเป็นรูปธรรมและค้นหาวิธีการที่ถูกต้องในการแก้ไข เราไม่เห็นด้วยกับการใช้วิธีเดียวในการแก้ปัญหาความขัดแย้งของสิ่งต่าง ๆ นี่คือความหมายของการเปิดล็อคด้วยกุญแจและร้องเพลงอะไรก็ได้ที่คุณไปบนภูเขา
สคริปต์ VBScript ฝั่งเซิร์ฟเวอร์ใช้เมธอด Server.CreateObject(className) เพื่อสร้างวัตถุ และสคริปต์ VBScript ฝั่งไคลเอ็นต์ใช้เมธอด CreateObject(className) เพื่อสร้างวัตถุ
ข้อผิดพลาดทั่วไป
คัดลอกรหัสรหัสดังต่อไปนี้:
-
ฟังก์ชั่นTSize(b)
'นี่คือฟังก์ชันที่กำหนดเองของฉัน
TSize=จีน
ฟังก์ชั่นสิ้นสุด
-
<a href=javascript:<%TSize('Variable')%> >คลิกที่นี่เพื่อใช้ฟังก์ชันที่ฉันกำหนดไว้</a>
การวิเคราะห์ข้อผิดพลาด:
สร้างความสับสนระหว่างความแตกต่างระหว่างสคริปต์ฝั่งเซิร์ฟเวอร์และสคริปต์ฝั่งไคลเอ็นต์ ในระหว่างการดำเนินการจริง เราจะพบว่าไคลเอนต์ไม่ได้รับรหัสใด ๆ เช่น TSize เลย เนื่องจาก TSize เป็นโปรแกรมฝั่งเซิร์ฟเวอร์ที่ประมวลผลโดยกลไก (โปรดทราบว่าการประมวลผลฟังก์ชันของกลไกนั้นมีไว้สำหรับสคริปต์ฝั่งเซิร์ฟเวอร์เท่านั้น และจะไม่ส่งกลับไปยังไคลเอนต์) หายไปและอาจไม่สามารถทำงานกับไคลเอนต์ได้ ซึ่งหมายความว่าสคริปต์ฝั่งไคลเอ็นต์ไม่สามารถเรียกใช้ฟังก์ชันของสคริปต์ฝั่งเซิร์ฟเวอร์ได้โดยตรง
ที่จริงแล้ว โปรแกรมนี้มีข้อผิดพลาดทางไวยากรณ์ เมื่อกลไกประมวลผลเนื้อหานี้ อันดับแรกจะค้นหาเนื้อหาระหว่าง <% ถึง %> นั่นคือ <%TSize('variable')%> ด้วยกฎไวยากรณ์ VBScript ถ้าคุณเปลี่ยนเป็น <%=TSize(variable)%> จะไม่มีข้อผิดพลาดทางไวยากรณ์ในสคริปต์ฝั่งเซิร์ฟเวอร์ ในขณะนี้ ฟังก์ชัน TSize สามารถส่งคืนค่า China ได้ตามปกติ ดังนั้นแอตทริบิวต์ href ที่ได้รับ ลูกค้าเขียนดังนี้: javascript: China ไม่สามารถบังคับใช้ได้
ผลกระทบของสคริปต์ฝั่งเซิร์ฟเวอร์ต่อสคริปต์ฝั่งไคลเอ็นต์
ตามที่กล่าวไว้ก่อนหน้านี้ สคริปต์ฝั่งเซิร์ฟเวอร์จะดำเนินการตามตรรกะก่อนสคริปต์ฝั่งไคลเอ็นต์ ดังนั้นโค้ดลักษณะนี้จึงเป็นไปได้:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
ดิม ไอ
สำหรับ i=1 ถึง 5
การตอบกลับเขียน <script type=text/javascript> _
& alert('Hello World! & i & ')</script>
ต่อไป
-
เกี่ยวกับการดำเนินการของ Response.Redirect และ javascript
โปรดทราบว่ารหัสต่อไปนี้เขียนไม่ถูกต้อง:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
การตอบสนอง เปลี่ยนเส้นทาง index.asp
การตอบกลับเขียน <script type=text/javascript> _
& alert('รหัสผ่านผิด!')</script>
-
นี่เป็นข้อผิดพลาดทั่วไป ผู้เขียนมักคิดว่าการเขียนโค้ดในลักษณะนี้จะทำให้ไคลเอ็นต์แสดงข้อผิดพลาดเกี่ยวกับรหัสผ่านแล้วเปลี่ยนเส้นทางไปที่ index.asp ที่จริงแล้วสิ่งนี้ไม่สามารถเกิดขึ้นได้แม้ว่าจะเรียงลำดับของทั้งสองบรรทัดก็ตาม มีการแลกเปลี่ยนรหัส มันจะไม่เกิดขึ้น มันเป็นไปได้ที่จะบรรลุผลนี้
เหตุผลเกี่ยวข้องกับวิธีที่เซิร์ฟเวอร์จัดการโค้ดสองบรรทัด เป็นไปไม่ได้ที่โค้ดสองบรรทัดนี้จะทำงานพร้อมกันได้
Response.Write คือการส่งข้อความไปยังไคลเอนต์ เนื้อหาของข้อความนี้สามารถเป็นสคริปต์ได้ จากนั้นเบราว์เซอร์ไคลเอนต์จะสามารถรันสคริปต์ได้หลังจากได้รับมันแล้วเท่านั้น
Response.Redirect ส่งส่วนหัว HTTP ไปยังไคลเอ็นต์ (ส่วนหัว HTTP คืออะไร ลองพูดแบบนี้ดู เช่น การเขียนถึงคุกกี้ไคลเอ็นต์คือข้อมูลส่วนหัว HTTP และข้อมูลส่วนหัว HTTP จะถูกส่งกลับไปยังไคลเอ็นต์ก่อนที่เบราว์เซอร์เนื้อหา HTTP นี่คือสาเหตุที่บางครั้งเราได้รับข้อผิดพลาดเมื่อแก้ไขคุกกี้หลังจากปิดการบัฟเฟอร์ของเซิร์ฟเวอร์ เนื่องจากเนื้อหาได้เริ่มส่งสัญญาณแล้ว และส่วนหัว HTTP ไม่ได้รับอนุญาตให้ส่ง ข้อมูล) เนื้อหาของข้อมูลจะบอกเบราว์เซอร์ไคลเอ็นต์ว่าควรข้ามไปที่หน้าเพื่อเรียกดู โปรดทราบว่าข้อมูลการเปลี่ยนเส้นทางนี้จะมีผลทันที ซึ่งหมายความว่าข้อมูลการเปลี่ยนเส้นทางนี้จะมีผลเฉพาะเมื่อเปิดใช้งานบัฟเฟอร์ ไม่ว่าจะใช้ Response หรือไม่ .Write เขียนจำนวนเนื้อหาที่ถูกเขียนลงในบัฟเฟอร์ เมื่อเรียก Response.Redirect บัฟเฟอร์จะถูกล้างและคำสั่งส่วนหัวนี้จะถูกส่งไปยังเบราว์เซอร์ไคลเอ็นต์ หากเราติดตามการทำงานของโปรแกรมแบบไดนามิก เราจะพบว่าหลังจากการเรียก Response.Redirect โปรแกรมจะหยุดทำงาน ดังนั้นโปรดทราบว่าโปรแกรมฝั่งเซิร์ฟเวอร์จะต้องปิดการเชื่อมต่อข้อมูลและการดำเนินการอื่น ๆ ก่อนที่จะเรียก Response.Redirect
แล้วตัวอย่างข้างต้นควรแก้ไขอย่างไร? หากคุณไม่ต้องการแก้ไข index.asp เพื่อเพิ่มพรอมต์สคริปต์ คุณสามารถดำเนินการคำสั่งการเปลี่ยนเส้นทางในสคริปต์ไคลเอนต์ได้เท่านั้น เช่นนี้:
คัดลอกรหัสรหัสดังต่อไปนี้:
-
การตอบกลับเขียน <script type=text/javascript> _
& alert('!');location.href='index.asp'</script>
-