الصفحة الرئيسية>دروس برمجة الشبكات>دروس ASP.NET

إعادة كتابة عنوان URL (2): استخدام مكونات لإعادة كتابة عنوان URL

الكاتب：Eve Cole وقت التحديث：2009-06-29 23:46:44
مبدأ مكون إعادة كتابة عنوان URL على مستوى asp.net بسيط للغاية. في الواقع، فهو يستمع فقط إلى حدث BeginRequest ويحدد عنوان URL المستهدف وفقًا للتكوين. في المشاريع التي شاركت فيها من قبل، وجدت أن معدل تكرار استخدام URLRewriter كمكون إعادة كتابة URL مرتفع جدًا وأعتقد أن السبب في ذلك هو أنه شيء تقدمه Microsoft.
إذا كنت تريد استخدام URLRewriter، فإن الخطوة الطبيعية الأولى هي تكوين HttpModule في web.config:

<httpModules>
< إضافة
الاسم = " وحدة إعادة الكتابة "
اكتب = " URLRewriter.ModuleRewriter، URLRewriter " />
</httpModules>

ثم حان وقت التهيئة (ملاحظة: يوصى بشدة باستخدام سمة configPath لاستخراج التكوين إلى ملفات إضافية لتسهيل الإدارة):
<أقسام التكوين>
< القسم
الاسم = " RewriterConfig "
اكتب = " URLRewriter.Config.RewriterConfigSerializerSectionHandler، URLRewriter " />
</configSections>
<تكوين إعادة الكتابة>

<القواعد>

<قاعدة إعادة الكتابة>

< LookFor > ~/tag/([w]+)/ </ LookFor >

< SendTo > ~/Tags.aspx?Tag=$1 </ SendTo >

</RewriterRule>

</ القواعد >
</RewriterConfig>

التعبيرات العادية شيء مدهش، يمكنها مطابقتها والتقاطها. في المثال أعلاه، قمنا بنقل "/tag/xxx" الذي يفي بشروط LookFor إلى صفحة Tag.aspx، واستخدمنا xxx كقيمة لعنصر Tag QueryString، حتى نتمكن من تمرير HttpContext.Request.QueryString في التعليمات البرمجية ["علامة"] للحصول على القيمة.
تعد وظيفة URLRewriter كافية لمعظم التطبيقات، لكنني لم أحبها دائمًا. ولكن إذا كان عليك أن تسألني لماذا لا أحب ذلك، فلا أستطيع أن أخبرك بـ Yinmao القبيح. ربما تكون مجرد مشكلة في طريقة التكوين هذه. عند استخدام URL Rewriter، غالبًا ما يكون قسم التكوين طويلًا جدًا، ويتطلب كل عنصر تكوين إجمالي 4 أسطر من التعليمات البرمجية من <RewriterRule> إلى </RewriterRule>. "هذا أيضًا XML"، فكرت، لماذا لا تستخدم سمة XML؟ يؤدي هذا إلى تقليل كل عنصر تكوين إلى سطر واحد - ولكن هذا يعد استطرادًا.
لذا، إذا كنت أرغب حاليًا في إعادة كتابة عنوان URL، فغالبًا ما أستخدم المكون مفتوح المصدر UrlRewriter.NET الذي تنتجه شركة Intelligencia . على الرغم من أن هذا الاسم مشابه جدًا للاسم السابق، إلا أن وظيفته أفضل بكثير من الاسم السابق. هذا المكون قريب نسبيًا من URLRewriter قيد الاستخدام (في الواقع، يبدو أن جميع مكونات إعادة كتابة URL متشابهة).

<أقسام التكوين>
< القسم
الاسم = " معيد الكتابة "

 اكتب = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ،

Intelligencia.UrlRewriter " />
</configSections>


<كاتب>

< إعادة الكتابة
URL = " ^/المستخدم/(d+)$ "
إلى = " ~/User.aspx?id=$1 "
المعالجة = " إيقاف " />

< إعادة الكتابة
URL = " ^/المستخدم/(w+)$ "
إلى = " ~/User.aspx?name=$1 "
المعالجة = " إيقاف " />
</الكاتب>


< نظام.ويب >

<httpModules>

< إضافة
الاسم = " UrlRewriter "

 اكتب = " Intelligencia.UrlRewriter.RewriterHttpModule،

Intelligencia.UrlRewriter " />

</httpModules>
< /system.web >
دعونا نلقي نظرة بشكل أساسي على عنصر التكوين <rewriter /> لقواعد إعادة الكتابة. يختلف UrlRewriter.NET عن URLRewriter، حيث يستخدم طريقتي المفضلة المتمثلة في عقدة واحدة لكل قاعدة، مما يجعل قواعد إعادة الكتابة للمشروع بأكمله أكثر بساطة. ولكن ماذا تعني المعالجة = "توقف"؟ يتعلق هذا بالطريقة التي يتعامل بها UrlRewriter.NET مع قواعد إعادة الكتابة. عندما يعثر UrlRewriter.NET على قاعدة إعادة كتابة مطابقة، فلن يتوقف الأمر هنا، ولكنه سيستمر في البحث عن مطابقات أخرى. ستدخل قاعدة إعادة الكتابة الأخيرة التي يمكن أن تطابق الطلب الحالي حيز التنفيذ في النهاية. إذا أردنا تفعيل UrlRewriter.NET بعد العثور على تطابق، فسنحتاج إلى إيقاف سمة المعالجة. على سبيل المثال، في التكوين أعلاه، إذا كان "/User/" متبوعًا برقم، فسيتم استخدام معرف المستخدم للبحث، وإلا فسيتم أخذ اسم المستخدم المقدم حاليًا في الاعتبار.
إذا كان UrlRewriter.NET أبسط في التكوين، فلن يكون له أي ميزة على URLRewriter. لكن إمكانيات UrlRewriter.NET تتجاوز ذلك بكثير، فما استخدمناه للتو هو في الواقع مجرد أحد الإجراءات التي يوفرها، بالإضافة إلى أنه يوفر أيضًا العديد من الإجراءات:

  • إذا
  • لم
  • يتم إعادة كتابة
  • إعادة التوجيه،
    • فإن
  • setstatus
  • المحظور
  • ذهب
  • غير مسموح به
  • ولم يتم العثور عليه
  • ولم يتم تنفيذه،
  • الإجراء
  • setcookie
  • setproperty
وحده لا يكفي، كما يوفر UrlRewriter.NET أيضًا الحالة والتحويل والمستند الافتراضي والمحلل ومعالج الأخطاء والمسجل ووظائف أخرى، ويمكنه المرور. التعبير "لتمثيل" المنطق المعقد. هذا ليس تكوين، بل مجرد برمجة! هذا صحيح، يمكن استخدام UrlRewriter.NET للتعبير عن بعض منطق الطلب والرد من خلال التكوين، مما يوفر لنا بلا شك راحة كبيرة. من المستحيل بالنسبة لي أن أشرح جميع جوانب UrlRewriter.NET بالتفصيل هنا، ويمكن للأصدقاء المهتمين إلقاء نظرة فاحصة على المرجع الذي يوفره موقعه الرسمي على الويب. "إذا كان لديك مكونات مثل هذه، ما الذي يمكن أن تطلبه أكثر من ذلك؟" ومع ذلك، ما زلت أريد أن أوصي بمكون آخر هنا. لأنه في بعض الحالات الخاصة، لا يمكن لـ UrlRewriter.NET تلبية متطلباتنا. أم؟ ألا يمكنها التوسع من تلقاء نفسها؟ هذا صحيح، ولكن - دعنا نتخلص من هذا الأمر أولاً، وسوف أشرح هذه المشكلة في المقالة الأخيرة من هذه السلسلة. يوفر UrlRewriter.NET أداة إعادة كتابة URL على مستوى ASP.NET. إذا كنت تريد إجراء إعادة كتابة URL على مستوى IIS، فيجب عليك استخدام طرق أخرى. يعد ISAPI Rewrite مكونًا معروفًا لإعادة كتابة عنوان URL على مستوى IIS، ولسوء الحظ، يعد هذا مكونًا تجاريًا ويتطلب منا شرائه بالدولار الأمريكي. لذلك أوصي هنا بمنتج آخر مفتوح المصدر: IIRF (مرشح إعادة كتابة Ionic's Isapi) .
نظرًا لأنه يتم تنفيذ إعادة كتابة عنوان URL على مستوى IIS، فإن أسلوب تكوين IIRF يختلف عن UrlRewriter.NET. إذا كنت تريد استخدام IIRF، فأنت بحاجة إلى إضافة IsapiRewrite4.dll إلى قائمة عوامل تصفية ISAPI الخاصة بموقع الويب:
يتم تكوين IIRF من خلال ملف ini ويمكن وضع IsapiRewrite4.ini وIsapiRewrite4.dll في نفس الدليل:
قاعدة إعادة الكتابة ^/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" مشابهة للمعالجة = "stop" في UrlRewriter.NET وستصبح سارية المفعول فور العثور على التطابق ولن تستمر في البحث.
على الرغم من أن IIRF هو مكون مفتوح المصدر، إلا أن وظائفه لا تزال قوية نسبيًا. خاصة بعد الجمع بين RewriteCond (شرط إعادة الكتابة)، يمكن تنفيذ قواعد إعادة كتابة أكثر تعقيدًا. على سبيل المثال، يعيد التكوين التالي كتابة طلب الدليل الجذر الذي يحتوي على كلمة Googlebot في UserAgent إلى مورد محدد:
إعادة كتابة Cond %{HTTP_USER_AGENT} ^Googlebot.*
قاعدة إعادة الكتابة ^/ $/Googlebot.html [L]
أخيرًا، دعونا نلقي نظرة على الفرق بين مكوني إعادة الكتابة. من الواضح أن الاختلاف الأكبر هو أنه يتم إعادة كتابتهما على مستويات مختلفة. يصف المخططان التخطيطيان أدناه كيف يتم في الحالتين تغيير "/User/jeffz" الذي كان من المفترض أن يحصل على نتيجة "404 Resource Not Found" إلى "/ المستخدم/الاسم = جيفز".
الأول هو إعادة كتابة عنوان URL بواسطة UrlRewriter.NET على مستوى ASP.NET:
التالي هو إعادة كتابة عنوان URL الخاص بـ IIRF على مستوى IIS:

مع هذين المكونين، أعتقد أننا لم نعد بحاجة إلى أي شيء آخر لتنفيذ إعادة كتابة عنوان URL.
مقالات ذات صلة