ホーム>ネットワークプログラミングチュートリアル>ASP.NET チュートリアル

URL 書き換え(2): URL 書き換え用コンポーネントの使用

著者：Eve Cole 更新時間：2009-06-29 23:46:44
実際、 asp.netレベルの URL 書き換えコンポーネントの原理は非常に単純で、BeginRequest イベントをリッスンし、構成に従ってターゲット URL を決定するだけです。私がこれまで関わったプロジェクトでは、URL Rewrite コンポーネントとしてURLRewriter を使用する頻度が非常に高かったのは、Microsoft が提供しているものであるためだと思います。
URLRewriter を使用する場合、最初の自然な手順は、web.config で HttpModule を構成することです。

<httpモジュール>
<追加
名前= "モジュールリライター"
type = " URLRewriter.ModuleRewriter、URLRewriter " />
</httpモジュール>

次に、構成を行います (注: 管理を容易にするために、configPath 属性を使用して構成を追加ファイルに抽出することを強くお勧めします)。
<configSections>
<セクション
名前= " RewriterConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler、URLRewriter " />
</configSections>
<リライター構成>

<ルール>

<リライタールール>

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

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

</リライタールール>

</ルール>
</RewriterConfig>

正規表現は素晴らしいもので、一致させてキャプチャすることができます。上記の例では、LookFor 条件を満たす「/tag/xxx」を Tags.aspx ページに再配置し、タグ QueryString 項目の値として xxx を使用して、コード内で HttpContext.Request.QueryString を渡すことができるようにします。 . ["タグ"] を使用して値を取得します。
URLRewriterの機能はほとんどのアプリケーションには十分ですが、私はずっとそれが嫌いでした。でも、なぜ嫌いなのかと問われたら、醜い陰毛を言うことはできません。もしかしたら、この設定方法に問題があるだけかもしれません。 URL Rewriter を使用する場合、構成セクションは多くの場合、<RewriterRule> から </RewriterRule> までの合計 4 行のコードが必要になります。小規模なプロジェクトでは、簡単に数百行の構成が必要になります。 「これは XML すぎる」と思ったので、XML 属性を使用すればよいのではないかと考えました。これにより、各構成項目が 1 行に減りますが、それは余談です。
したがって、現在 URL Rewrite を実行したい場合は、 Intelligenciaが作成したオープン ソース コンポーネントUrlRewriter.NET を使用することがよくあります。この名前は以前の名前とよく似ていますが、機能は以前の名前よりもはるかに優れています。このコンポーネントは、使用されている URLRewriter に比較的似ています (実際、すべての URL Rewrite コンポーネントは似ているようです)。

<configSections>
<セクション
名前= "リライター"

 type = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler 、

Intelligencia.UrlRewriter " />
</configSections>


<リライター>

<書き換える
URL = " ^/ユーザー/(d+)$ "
to = " ~/User.aspx?id=$1 "
処理= "停止" />

<書き換える
URL = " ^/ユーザー/(w+)$ "
to = " ~/User.aspx?name=$1 "
処理= "停止" />
</リライター>


<システム.ウェブ>

<httpモジュール>

<追加
名前= " URLリライター"

 type = " Intelligencia.UrlRewriter.RewriterHttpModule,

Intelligencia.UrlRewriter " />

</httpモジュール>
< /system.web >
主に書き換えルールの設定項目 <rewriter /> を見てみましょう。 URLRewriter とは異なり、UrlRewriter.NET はルールごとに 1 つのノードという私のお気に入りの方法を使用しており、プロジェクト全体の書き換えルールがはるかに単純になります。しかし、処理 = "停止" とは何を意味するのでしょうか?これは、UrlRewriter.NET が書き換えルールを処理する方法についてです。 UrlRewriter.NET は、一致する書き換えルールを見つけると、ここで停止せず、他の一致を探し続け、最終的には現在の要求に一致する最後の書き換えルールが有効になります。一致が見つかった後に UrlRewriter.NET を有効にする必要がある場合は、処理属性を stop に設定する必要があります。たとえば、上記の設定では、「/User/」の後に数字が続く場合、ユーザー ID が検索に使用されます。それ以外の場合は、現在指定されているユーザー名が考慮されます。
UrlRewriter.NET の構成が単純であるだけであれば、URLRewriter に比べて利点はありません。しかし、UrlRewriter.NET の機能はそれをはるかに超えており、実際には、ここで使用したものは、それが提供するアクションの 1 つにすぎません。さらに、次のような多くのアクションも提供します。

  • if
  • until
  • rewrite
  • redirect
  • setstatus
  • 禁止していませ
    • ん
  • go
  • not-allowed
  • not-found
  • not-implemented
  • addheader
  • setcookie
  • setproperty
UrlRewriter.NET は、Action だけでは十分ではなく、Condition、Transform、Default Document、Parser、Error Handler、Logger などの関数も提供しており、渡すことができます。複雑なロジックを「表現」するための式。これは設定ではなく、単なるプログラミングです。そうです、UrlRewriter.NET を使用すると、構成を通じて要求と応答のロジックを表現することができ、これは間違いなく大きな利便性をもたらします。ここで UrlRewriter.NET のすべての側面を詳しく説明することは不可能です。興味のある方は、公式 Web サイトで提供されている リファレンスを参照してください。 「このようなコンポーネントがある場合、これ以上何を求めることができますか? しかし、ここでは別のコンポーネントをお勧めしたいと思います。」特殊なケースでは、UrlRewriter.NET が要件を満たせないためです。えっと？単独では拡張できないのでしょうか？その通りですが、まずは本題から外して、この問題についてはこのシリーズの最後の記事で説明します。 UrlRewriter.NET は、ASP.NET レベルで URL リライターを提供します。 IIS レベルで URL 書き換えを実行する場合は、他の方法を使用する必要があります。 ISAPI Rewrite は、IIS レベルでの URL Rewrite のよく知られたコンポーネントです。残念ながら、これは商用コンポーネントであり、米ドルで購入する必要があります。したがって、ここでは別のオープンソース製品、 IIRF (Ionic の Isapi Rewrite Filter)をお勧めします。
URL Rewrite は IIS レベルで実行されるため、IIRF の設定方法は UrlRewriter.NET とは異なります。 IIRF を使用する場合は、IsapiRewrite4.dll を Web サイトの ISAPI フィルター リストに追加する必要があります。
IIRF は、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>]」です。各部分間のスペースの数に制限はありませんが、タブなどの他の空白文字は使用できません。 。 「url-pattern」と「destination」は言うまでもなく、修飾子が鍵となります。 IIRF には多数の修飾子がありますが、ここでは上で使用した 2 つだけを紹介します。 「I」は、一致が大文字と小文字を区別しないことを意味します。「L」の機能は、一致が見つかったときにすぐに有効になり、検索は続行されません。
IIRF はオープンソース コンポーネントですが、その機能は依然として比較的強力です。特に RewriteCond (書き換え条件) を組み合わせた後は、より複雑な書き換えルールを実装できます。たとえば、次の構成は、UserAgent に Googlebot という単語を含むルート ディレクトリ リクエストを特定のリソースに書き換えます。
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
最後に、Rewrite の 2 つのコンポーネントの違いを見てみましょう。明らかに、最大の違いは、異なるレベルで書き換えられることです。以下の 2 つの概略図は、「404 Resource Not Found」結果を取得するはずの「/User/jeffz」を 2 つのケースでどのように変更するかを示しています。 「/ユーザー/名前=jeffz」。
1 つ目は、ASP.NET レベルでの UrlRewriter.NET による URL 書き換えです。
次は、IIS レベルでの IIRF の URL 書き換えです。

これら 2 つのコンポーネントがあれば、URL Rewrite を実装するために他に何も必要はなくなると思います。
関連記事