หากห้องคอมพิวเตอร์กำลังจะปิดหรือคุณกังวลที่จะออกเดทกับผู้หญิง โปรดข้ามไปที่ย่อหน้าปกติที่สี่โดยตรง
สคริปต์ที่อธิบายไว้ด้านล่างประกอบด้วยสคริปต์ฝั่งเซิร์ฟเวอร์และสคริปต์ฝั่งไคลเอ็นต์อ้างอิงถึงส่วนของสคริปต์ที่ทำงานบนเซิร์ฟเวอร์ ตัวอย่างเช่น Response.Write ทั่วไปจะทำงานบนเซิร์ฟเวอร์ สคริปต์สามารถเขียนได้โดยใช้ภาษา VBScript และ JScript , VBScript และ Jscript ทั้งหมดใช้ในบทความนี้
สคริปต์ฝั่งไคลเอ็นต์ยังถือได้ว่ามีสองภาษา: VBScript และ JavaScript ซึ่งเป็นภาษาสคริปต์ที่ทำงานบนเบราว์เซอร์ไคลเอ็นต์ ตัวอย่างเช่น เมื่อเราเยี่ยมชมหน้าเว็บแล้วกล่องข้อความปรากฏขึ้น การดำเนินการนี้ทำได้โดยใช้สคริปต์ฝั่งไคลเอ็นต์ (การแจ้งเตือน msgbox ฯลฯ) และเห็นได้ชัดว่าสคริปต์ฝั่งเซิร์ฟเวอร์ไม่สามารถทำได้ มีความแตกต่างที่สำคัญอีกประการหนึ่งระหว่างสคริปต์ฝั่งไคลเอ็นต์และสคริปต์ฝั่งเซิร์ฟเวอร์ (ในเบราว์เซอร์เช่น IE และ Firefox) ซึ่งก็คือสคริปต์ฝั่งไคลเอ็นต์สามารถเข้าถึง Document Object Model (DOM) และสามารถจัดการวัตถุในหน้า (เช่น เช่น การแก้ไขชื่อหน้า, แก้ไขแอตทริบิวต์ innerHTML ของ div ฯลฯ)
ขั้นแรก มาดูกระบวนการดำเนินการเพจ 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 ฝั่งเซิร์ฟเวอร์ที่รันข้อมูลฐานข้อมูล แต่หากฐานข้อมูลของคุณเชื่อมต่อกับไคลเอนต์จริงๆ (เช่น http://bbs .bccn.net/thread-224966-1-2.html นี้) จากนั้นจะต้องสร้างในสคริปต์ไคลเอ็นต์
สรุปคือสิ่งที่ขัดแย้งกันและแต่ละฝ่ายมีลักษณะเฉพาะของตัวเอง สิ่งที่แตกต่างกันมีความขัดแย้งที่แตกต่างกัน สิ่งเดียวกันมีความขัดแย้งที่แตกต่างกันในกระบวนการและขั้นตอนการพัฒนาที่แตกต่างกัน ความขัดแย้งที่แตกต่างกันในสิ่งเดียวกัน และความขัดแย้งที่เหมือนกันสองด้านต่างก็มีลักษณะเฉพาะของตัวเอง (คุณสามารถละเว้นผู้ที่ไม่เข้าใจได้) อย่ามอง…) หลักการนี้กำหนดให้เราต้องยึดหลักการวิเคราะห์ปัญหาเฉพาะอย่างเป็นรูปธรรม และภายใต้การแนะนำของหลักความเป็นสากลของความขัดแย้ง ให้วิเคราะห์ลักษณะเฉพาะของความขัดแย้งอย่างเป็นรูปธรรมและค้นหาวิธีการที่ถูกต้องในการแก้ไข เราไม่เห็นด้วยกับการใช้วิธีเดียวในการแก้ปัญหาความขัดแย้งของสิ่งต่าง ๆ กุญแจไขกุญแจได้ และนี่คือความหมายของการร้องเพลงใดก็ตามที่คุณไปบนภูเขาลูกใดก็ตาม
สคริปต์ VBScript ฝั่งเซิร์ฟเวอร์ใช้เมธอด Server.CreateObject(className) เพื่อสร้างวัตถุ และสคริปต์ VBScript ฝั่งไคลเอ็นต์ใช้เมธอด CreateObject(className) เพื่อสร้างวัตถุ
ข้อผิดพลาดทั่วไป
-
ฟังก์ชั่นTSize(b)
'นี่คือฟังก์ชันที่กำหนดเองของฉัน
TSize=จีน
ฟังก์ชั่นสิ้นสุด
-
<a href=javascript:<%TSize('Variable')%> >คลิกที่นี่เพื่อใช้ฟังก์ชันที่ฉันกำหนดไว้</a>
(http://bbs.bccn.net/thread-225244-1-1.html)
การวิเคราะห์ข้อผิดพลาด:
สร้างความสับสนระหว่างความแตกต่างระหว่างสคริปต์ฝั่งเซิร์ฟเวอร์และสคริปต์ฝั่งไคลเอ็นต์ ในระหว่างการดำเนินการจริง เราจะพบว่าไคลเอนต์ไม่ได้รับรหัสใด ๆ เช่น 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>
-
ข้อมูลการติดต่อ
หากคุณมีความคิดเห็นและข้อเสนอแนะ โดยเฉพาะอย่างยิ่งข้อผิดพลาดและข้อบกพร่องในบทความ หรือหากคุณต้องการเพิ่มเนื้อหาใหม่ให้กับบทความ คุณสามารถติดต่อฉันผ่านทางฟอรัมการเขียนโปรแกรม แน่นอนคุณสามารถโพสต์คำถามหลังโพสต์นี้ได้
เป็นที่น่าสังเกตว่าหากคุณมีคำถามเกี่ยวกับอัลกอริธึมและโครงสร้างข้อมูล เช่น ไม่เข้าใจว่าทำไมโปรแกรมของคุณถึงผิด หรือถามซอร์สโค้ดของอัลกอริธึมบางตัว คุณอาจไม่ได้รับคำตอบอย่างทันท่วงทีโดยใช้ข้อมูลติดต่อนี้ กรุณาถามในฟอรั่มการเขียนโปรแกรม
-------------------------------------------------- -------------------------------------------------- ----------------------------------
ลิขสิทธิ์
ลิขสิทธิ์ (c) 2008 multiple1902
อนุญาตให้คัดลอก แจกจ่าย และ/หรือแก้ไขเอกสารนี้ภายใต้เงื่อนไขของ GNU Free Documentation License เวอร์ชัน 1.2 หรือเวอร์ชันที่ใหม่กว่าที่เผยแพร่โดย Free Software Foundation