Página Inicial>Tutorial de programação de redes>Tutorial ASP.NET

URL Rewrite(2): Usando componentes para URL Rewrite

Autor：Eve Cole Data da Última Atualização：2009-06-29 23:46:44
O princípio do componente URL Rewrite no nível asp.net é muito simples, ele apenas escuta o evento BeginRequest e determina o URL de destino de acordo com a configuração. Nos projetos em que estive envolvido antes, descobri que a frequência de uso de URLRewriter como componente de reescrita de URL é muito alta, acho que pode ser porque é algo fornecido pela Microsoft.
Se você quiser usar o URLRewriter, o primeiro passo natural é configurar um HttpModule no web.config:

<httpMódulos>
< adicionar
nome = " MóduloRewriter "
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModules>

Então é hora de configurar (Nota: É altamente recomendável usar o atributo configPath para extrair a configuração em arquivos adicionais para facilitar o gerenciamento):
<seções de configuração>
< seção
name = " RewriterConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>

<Regras>

<ReescritorRegra>

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

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

</RewriterRule>

</ Regras >
</RewriterConfig>

Expressões regulares são uma coisa incrível, elas podem combinar e capturar. No exemplo acima, realocamos "/tag/xxx" que atende às condições LookFor para a página Tags.aspx e usamos xxx como o valor do item Tag QueryString, para que possamos passar HttpContext.Request.QueryString no código .["Tag"] para obter o valor.
A funcionalidade do URLRewriter é suficiente para a maioria dos aplicativos, mas sempre não gostei dela. Mas se você tiver que me perguntar por que não gosto disso, não posso dizer o feio Yinmao. Talvez seja apenas um problema com este método de configuração. Ao usar o URL Rewriter, a seção de configuração geralmente é muito longa. Cada item de configuração requer um total de 4 linhas de código de <RewriterRule> a </RewriterRule>. “Isso é muito XML”, pensei, por que não usar o Atributo XML? Isso reduz cada item de configuração a 1 linha - mas isso é uma digressão.
Portanto, se atualmente desejo fazer URL Rewrite, costumo usar o componente de código aberto UrlRewriter.NET produzido pela Intelligencia . Embora este nome seja muito semelhante ao anterior, a sua funcionalidade é muito superior à anterior. Este componente é relativamente próximo do URLRewriter em uso (na verdade, parece que todos os componentes de URL Rewrite são semelhantes. Tudo o que precisamos fazer é configurar:

<seções de configuração>
< seção
nome = " reescritor "

 type = " Inteligência.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Inteligência.UrlRewriter " />
</configSections>


<reescritor>

< reescrever
url = " ^/Usuário/(d+)$ "
para = " ~/User.aspx?id=$1 "
processando = " parar " />

< reescrever
url = " ^/Usuário/(w+)$ "
to = " ~/User.aspx?name=$1 "
processando = " parar " />
</rewriter>


< sistema.web >

<httpMódulos>

< adicionar
nome = " UrlRewriter "

 type = " Inteligência.UrlRewriter.RewriterHttpModule,

Inteligência.UrlRewriter " />

</httpModules>
< /system.web >
Vejamos principalmente o item de configuração <rewriter /> das regras de reescrita. Diferente do URLRewriter, o UrlRewriter.NET usa meu método favorito de um nó por regra, o que torna as regras de reescrita de todo o projeto muito mais simples. Mas o que significa processamento="parar"? É assim que o UrlRewriter.NET lida com regras de reescrita. Quando UrlRewriter.NET encontra uma regra de reescrita correspondente, ele não para aqui, mas continua procurando outras correspondências. A última regra de reescrita que pode corresponder à solicitação atual entrará em vigor. Se precisarmos que UrlRewriter.NET entre em vigor após encontrar uma correspondência, precisamos definir o atributo de processamento como stop. Por exemplo, na configuração acima, se "/Usuário/" for seguido de um número, o ID do usuário será utilizado para pesquisa, caso contrário, o nome de usuário fornecido atualmente será considerado.
Se o UrlRewriter.NET for apenas mais simples na configuração, ele não terá vantagem sobre o URLRewriter. Mas os recursos do UrlRewriter.NET vão muito além disso. O que acabamos de usar é, na verdade, apenas uma das ações que ele fornece.

  • if
  • a menos que
  • reescrever
  • redireccionamento
  • setstatus
  • proibido
  • ido
  • não permitido
  • não encontrado
  • não implementado
  • addheader
  • setcookie
  • setproperty
A acção por si só não é suficiente UrlRewriter.NET também fornece Condição, Transformação, Documento Padrão, Analisador, Manipulador de Erros, Logger e outras funções, e pode passar. Expressão para "representar" lógica complexa. Isto não é configuração, é simplesmente programação! Isso mesmo, UrlRewriter.NET pode ser usado para expressar alguma lógica de solicitação-resposta por meio de configuração, o que sem dúvida nos traz grande comodidade. É impossível explicar todos os aspectos do UrlRewriter.NET em detalhes aqui. Amigos interessados ​​​​podem dar uma olhada mais de perto na Referência fornecida por seu site oficial. “Se você tem componentes como este, o que mais você poderia pedir?” No entanto, ainda quero recomendar outro componente aqui. Porque em alguns casos especiais, UrlRewriter.NET não pode atender aos nossos requisitos. Hum? Ele não pode se expandir sozinho? Isso mesmo, mas - vamos resolver isso primeiro e explicarei esse problema no último artigo desta série. UrlRewriter.NET fornece URL Rewriter no nível ASP.NET. Se quiser executar a reconfiguração de URL no nível do IIS, você deverá usar outros métodos. ISAPI Rewrite é um componente bem conhecido para URL Rewrite no nível IIS. Infelizmente, este é um componente comercial e exige que o compremos com dólares americanos. Portanto, recomendo outro produto de código aberto aqui: IIRF (Ionic's Isapi Rewrite Filter) .
Como a reescrita de URL é executada no nível IIS, o método de configuração do IIRF é diferente do UrlRewriter.NET. Se quiser usar o IIRF, você precisará adicionar IsapiRewrite4.dll à lista de filtros ISAPI do site:
O IIRF é configurado por meio do arquivo ini IsapiRewrite4.ini e IsapiRewrite4.dll podem ser colocados no mesmo diretório:
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
A regra de reescrita do IIRF é "RewriteRule <url-pattern> <destination> [<modifiers>]". Não há limite para o número de espaços entre cada parte, mas deve ser um espaço, não outros caracteres de espaço em branco, como Tab. . Escusado será dizer que "padrão de URL" e "destino" a chave está no modificador. Existem muitos modificadores para IIRF. Aqui apresentarei apenas os dois usados ​​​​acima. "I" significa que a correspondência é independente de maiúsculas e minúsculas. A função de "L" é semelhante a processamento = "stop" em UrlRewriter.NET entrará em vigor imediatamente quando a correspondência for encontrada e não continuará a pesquisa.
Embora o IIRF seja um componente de código aberto, suas funções ainda são relativamente poderosas. Especialmente depois de combinar RewriteCond (Condição de Reescrita), regras de reescrita mais complexas podem ser implementadas. Por exemplo, a configuração a seguir reescreve a solicitação do diretório raiz que contém a palavra Googlebot no UserAgent para um recurso específico:
ReescreverCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
Finalmente, vamos dar uma olhada na diferença entre os dois componentes Rewrite. Obviamente, a maior diferença é que eles são reescritos em níveis diferentes. Os dois diagramas esquemáticos abaixo descrevem como nos dois casos eles alteram o "/User/jeffz" que deveria ter obtido o resultado "404 Resource Not Found". "/Usuário/nome=jeffz".
A primeira é a reescrita de URL por UrlRewriter.NET no nível ASP.NET:
A seguir está a reescrita de URL do IIRF no nível IIS:

Com esses dois componentes, acredito que não precisamos mais de mais nada para implementar o URL Rewrite.