การเขียน URL ใหม่ (2): การใช้ส่วนประกอบสำหรับการเขียน URL ใหม่
ผู้เขียน:Eve Cole
เวลาอัปเดต:2009-06-29 23:46:44
หลักการของคอมโพเนนต์การเขียนซ้ำ URL ระดับ asp.net นั้นง่ายมาก จริงๆ แล้ว คอมโพเนนต์จะรับฟังเหตุการณ์ BeginRequest และกำหนด URL เป้าหมายตามการกำหนดค่า ในโครงการที่ฉันเคยมีส่วนร่วมมาก่อน ฉันพบว่าความถี่ในการใช้ URLRewriter เป็นองค์ประกอบการเขียนซ้ำ URL นั้นสูงมาก ฉันคิดว่าอาจเป็นเพราะเป็นสิ่งที่ Microsoft เตรียมไว้ให้
หากคุณต้องการใช้ URLRewriter ขั้นตอนแรกคือการกำหนดค่า HttpModule ใน web.config:
<httpโมดูล>
< เพิ่ม
ชื่อ = " ModuleRewriter "
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpโมดูล>
จากนั้นก็ถึงเวลากำหนดค่า (หมายเหตุ: ขอแนะนำอย่างยิ่งให้ใช้แอตทริบิวต์ configPath เพื่อแยกการกำหนดค่าออกเป็นไฟล์เพิ่มเติมเพื่อการจัดการที่ง่ายขึ้น):
<configSections>
< ส่วน
ชื่อ = " RewriterConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>
<กฎ>
<กฎนักเขียนใหม่>
< ค้นหา > ~/tag/([w]+)/ </ ค้นหา >
< ส่งไปที่ > ~/Tags.aspx?Tag=$1 </ ส่งไปที่ >
</กฎนักเขียนใหม่>
</ กฎ >
</RewriterConfig>
สำนวนปกติเป็นสิ่งที่น่าทึ่ง ซึ่งสามารถจับคู่และบันทึกภาพได้ ในตัวอย่างข้างต้น เราย้ายตำแหน่ง "/tag/xxx" ที่ตรงตามเงื่อนไข LookFor ไปยังเพจ Tags.aspx และใช้ xxx เป็นค่าของรายการ Tag QueryString เพื่อให้เราสามารถส่งผ่าน HttpContext.Request.QueryString ในโค้ดได้ . ["แท็ก"] เพื่อรับค่า
ฟังก์ชันการทำงานของ URLRewriter นั้นเพียงพอสำหรับแอปพลิเคชันส่วนใหญ่ แต่ฉันไม่ชอบมันมาโดยตลอด แต่ถ้าคุณต้องถามฉันว่าทำไมฉันถึงไม่ชอบมันฉันก็ไม่สามารถบอกคุณ Yinmao ที่น่าเกลียดได้ อาจเป็นเพียงปัญหาเกี่ยวกับวิธีการกำหนดค่านี้ เมื่อใช้ URL Rewriter ส่วนการกำหนดค่ามักจะยาวมาก แต่ละรายการการกำหนดค่าต้องใช้โค้ดทั้งหมด 4 บรรทัดตั้งแต่ <RewriterRule> ถึง </RewriterRule> โปรเจ็กต์ขนาดเล็กสามารถมีการกำหนดค่าได้หลายร้อยบรรทัด ฉันคิดว่า "นี่เป็น XML เกินไป" ทำไมไม่ใช้แอตทริบิวต์ XML ล่ะ สิ่งนี้จะลดแต่ละรายการการกำหนดค่าเหลือ 1 บรรทัด - แต่นั่นเป็นการพูดนอกเรื่อง
ดังนั้นหากฉันต้องการเขียน URL ใหม่ในปัจจุบัน ฉันมักจะใช้คอมโพเนนต์โอเพ่นซอร์ส UrlRewriter.NET ที่ผลิตโดย Intelligencia แม้ว่าชื่อนี้จะคล้ายกับชื่อก่อนหน้ามาก แต่ฟังก์ชันการทำงานของมันก็เหนือกว่าชื่อเดิมมาก ส่วนประกอบนี้ค่อนข้างใกล้เคียงกับการใช้งาน URLRewriter (อันที่จริงแล้ว ดูเหมือนว่าส่วนประกอบการเขียนซ้ำ URL ทั้งหมดจะคล้ายกัน) สิ่งที่เราต้องทำคือกำหนดค่า:
<configSections>
< ส่วน
ชื่อ = " นักเขียนใหม่ "
type = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,
Intelligencia.UrlRewriter " />
</configSections>
<นักเขียนใหม่>
< เขียนใหม่
url = " ^/ผู้ใช้/(d+)$ "
ถึง = " ~/User.aspx?id=$1 "
การประมวลผล = " หยุด " />
< เขียนใหม่
url = " ^/ผู้ใช้/(w+)$ "
ถึง = " ~/User.aspx?name=$1 "
การประมวลผล = " หยุด " />
</เขียนใหม่>
< system.เว็บ >
<httpโมดูล>
< เพิ่ม
ชื่อ = " UrlRewriter "
type = " Intelligencia.UrlRewriter.RewriterHttpModule,
Intelligencia.UrlRewriter " />
</httpโมดูล>
< / /system.เว็บ >
มาดูรายการการกำหนดค่า <rewriter /> ของกฎการเขียนซ้ำเป็นหลัก UrlRewriter.NET แตกต่างจาก URLRewriter โดยใช้วิธีการโปรดของฉันคือหนึ่งโหนดต่อกฎ ซึ่งทำให้กฎการเขียนใหม่ของโครงการทั้งหมดง่ายขึ้นมาก แต่การประมวลผล = "หยุด" หมายถึงอะไร? นี่เป็นเรื่องเกี่ยวกับวิธีที่ UrlRewriter.NET จัดการกับกฎการเขียนใหม่ เมื่อ UrlRewriter.NET พบกฎการเขียนซ้ำที่ตรงกัน จะไม่หยุดเพียงเท่านี้ แต่จะค้นหารายการที่ตรงกันอื่นๆ ต่อไป กฎการเขียนใหม่ล่าสุดที่สามารถตรงกับคำขอปัจจุบันจะมีผลในที่สุด หากเราต้องการให้ UrlRewriter.NET มีผลหลังจากค้นหารายการที่ตรงกัน เราจำเป็นต้องตั้งค่าแอตทริบิวต์การประมวลผลให้หยุด ตัวอย่างเช่น ในการกำหนดค่าข้างต้น หาก "/User/" ตามด้วยตัวเลข ระบบจะใช้ ID ผู้ใช้ในการค้นหา มิฉะนั้นจะพิจารณาชื่อผู้ใช้ที่ให้ไว้ในปัจจุบัน
หาก UrlRewriter.NET มีการกำหนดค่าที่ง่ายกว่า ก็ไม่มีข้อได้เปรียบเหนือ URLRewriter แต่ความสามารถของ UrlRewriter.NET นั้นไปไกลกว่านั้นจริงๆ แล้วสิ่งที่เราเพิ่งใช้เป็นเพียงหนึ่งในการดำเนินการที่มีให้ นอกจากนี้ ยังมีการดำเนินการอีกมากมาย:
- ถ้า
- เว้นแต่
- เขียน
- ใหม่
- setstatus
- ต้องห้าม
- หายไป
- ไม่ได้รับอนุญาต
- ไม่พบ
- ไม่ได้ใช้
- addheader
- setcookie
- setproperty
การดำเนินการเพียงอย่างเดียวไม่เพียงพอ นิพจน์เพื่อ "นำเสนอ" ตรรกะที่ซับซ้อน นี่ไม่ใช่การกำหนดค่า มันเป็นเพียงการเขียนโปรแกรม! ถูกต้อง UrlRewriter.NET สามารถใช้เพื่อแสดงตรรกะการร้องขอและตอบกลับผ่านการกำหนดค่า ซึ่งทำให้เราสะดวกสบายอย่างยิ่งอย่างไม่ต้องสงสัย เป็นไปไม่ได้สำหรับฉันที่จะอธิบายทุกแง่มุมของ UrlRewriter.NET โดยละเอียดที่นี่ เพื่อนที่สนใจสามารถดูได้จาก ข้อมูลอ้างอิง ที่จัดทำโดยเว็บไซต์อย่างเป็นทางการ "หากคุณมีส่วนประกอบเช่นนี้ คุณจะขออะไรได้อีก" อย่างไรก็ตาม ฉันยังอยากจะแนะนำส่วนประกอบอื่นที่นี่ เนื่องจากในบางกรณี UrlRewriter.NET ไม่สามารถตอบสนองความต้องการของเราได้ เอิ่ม? ขยายเองไม่ได้เหรอ? ถูกต้อง แต่มาทำความเข้าใจเรื่องนี้ก่อน แล้วฉันจะอธิบายปัญหานี้ในบทความสุดท้ายของซีรี่ส์นี้ UrlRewriter.NET ให้ URL Rewriter ในระดับ ASP.NET หากคุณต้องการดำเนินการเขียน URL ใหม่ในระดับ IIS คุณต้องใช้วิธีการอื่น ISAPI Rewrite เป็นองค์ประกอบที่รู้จักกันดีสำหรับการเขียน URL ในระดับ IIS ขออภัย นี่เป็นองค์ประกอบเชิงพาณิชย์และกำหนดให้เราซื้อด้วยสกุลเงินดอลลาร์สหรัฐ ดังนั้นฉันขอแนะนำผลิตภัณฑ์โอเพ่นซอร์สอื่นที่นี่: IIRF (ตัวกรอง Isapi Rewrite ของ Ionic)
เนื่องจากการเขียน URL ใหม่จะดำเนินการในระดับ IIS วิธีการกำหนดค่าของ IIRF จึงแตกต่างจาก UrlRewriter.NET ถ้าคุณต้องการใช้ IIRF คุณต้องเพิ่ม IsapiRewrite4.dll ลงในรายการตัวกรอง ISAPI ของเว็บไซต์:
IIRF ได้รับการกำหนดค่าผ่านไฟล์ ini IsapiRewrite4.ini และ IsapiRewrite4.dll สามารถอยู่ในไดเร็กทอรีเดียวกัน:
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
กฎการเขียนใหม่ของ IIRF คือ "RewriteRule <url-pattern> <destination> [<modifiers>]" ไม่มีการจำกัดจำนวนช่องว่างระหว่างแต่ละส่วน แต่ต้องเป็นช่องว่าง ไม่ใช่อักขระช่องว่างอื่น ๆ เช่น Tab . ไม่จำเป็นต้องพูดว่า "รูปแบบ URL" และ "ปลายทาง" คีย์อยู่ที่ตัวแก้ไข มีตัวดัดแปลงมากมายสำหรับ IIRF ในที่นี้ผมจะแนะนำเฉพาะสองตัวที่ใช้ด้านบนเท่านั้น "I" หมายความว่าการจับคู่ไม่ขึ้นกับตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ฟังก์ชันของ "L" จะคล้ายกับการประมวลผล = "หยุด" ใน UrlRewriter.NET จะมีผลทันทีเมื่อพบการจับคู่และจะไม่ทำการค้นหาต่อไป
แม้ว่า IIRF จะเป็นส่วนประกอบแบบโอเพ่นซอร์ส แต่ฟังก์ชันของมันยังคงมีประสิทธิภาพค่อนข้างมาก โดยเฉพาะอย่างยิ่งหลังจากรวม RewriteCond (เงื่อนไขการเขียนซ้ำ) แล้ว สามารถใช้กฎการเขียนใหม่ที่ซับซ้อนมากขึ้นได้ ตัวอย่างเช่น การกำหนดค่าต่อไปนี้จะเขียนคำขอไดเรกทอรีรากที่มีคำว่า Googlebot ใน UserAgent ใหม่ไปยังทรัพยากรเฉพาะ:
เขียนซ้ำ %{HTTP_USER_AGENT} ^Googlebot.*
เขียนกฎใหม่ ^/ $/Googlebot.html [L]
สุดท้ายนี้ เรามาดูความแตกต่างระหว่างองค์ประกอบทั้งสองที่เขียนใหม่กัน ความแตกต่างที่ใหญ่ที่สุดคือมีการเขียนใหม่ในระดับที่ต่างกัน แผนผังทั้งสองด้านล่างนี้อธิบายวิธีการในสองกรณีที่พวกเขาเปลี่ยน "/User/jeffz" ที่ควรได้รับผลลัพธ์ "404 Resource Not Found" "/User/name=เจฟฟ์"
อย่างแรกคือการเขียน URL ใหม่โดย UrlRewriter.NET ที่ระดับ ASP.NET:
ถัดไปคือการเขียน URL ของ IIRF ในระดับ IIS:
ด้วยองค์ประกอบทั้งสองนี้ ฉันเชื่อว่าเราไม่ต้องการสิ่งอื่นใดในการดำเนินการเขียน URL ใหม่อีกต่อไป