Inicio>Tutorial de programación de red>Tutorial de ASP.NET

Reescritura de URL (2): uso de componentes para reescritura de URL

Autor：Eve Cole Fecha de actualización：2009-06-29 23:46:44
El principio del componente de reescritura de URL de nivel asp.net es muy simple. De hecho, simplemente escucha el evento BeginRequest y determina la URL de destino de acuerdo con la configuración. En los proyectos en los que he estado involucrado antes, descubrí que la frecuencia de uso de URLRewriter como componente de reescritura de URL es muy alta, creo que puede deberse a que es algo proporcionado por Microsoft.
Si desea utilizar URLRewriter, el primer paso natural es configurar un HttpModule en web.config:

<httpMódulos>
< agregar
nombre = " MóduloReescritor "
tipo = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModules>

Luego es el momento de configurar (Nota: se recomienda encarecidamente utilizar el atributo configPath para extraer la configuración en archivos adicionales para facilitar la administración):
<seccionesdeconfiguración>
< sección
nombre = " RewriterConfig "
tipo = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>

<Reglas>

<Regla de reescritura>

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

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

</RewriterRule>

</Reglas>​​
</RewriterConfig>

Las expresiones regulares son algo asombroso, pueden coincidir y capturar. En el ejemplo anterior, reubicamos "/tag/xxx" que cumple con las condiciones de LookFor en la página Tags.aspx y usamos xxx como valor del elemento Tag QueryString, de modo que podamos pasar HttpContext.Request.QueryString en el código. . ["Etiqueta"] para obtener el valor.
La funcionalidad de URLRewriter es suficiente para la mayoría de las aplicaciones, pero nunca me ha gustado. Pero si tienes que preguntarme por qué no me gusta, no puedo decirte el feo Yinmao. Quizás sea solo un problema con este método de configuración. Cuando se utiliza URL Rewriter, la sección de configuración suele ser muy larga. Cada elemento de configuración requiere un total de 4 líneas de código desde <RewriterRule> hasta </RewriterRule>. "Esto es demasiado XML", pensé, ¿por qué no utilizar el atributo XML? Esto reduce cada elemento de configuración a 1 línea, pero eso es una digresión.
Entonces, si actualmente quiero reescribir URL, a menudo uso el componente de código abierto UrlRewriter.NET producido por Intelligencia . Aunque este nombre es muy similar al anterior, su funcionalidad es muy superior al anterior. Este componente está relativamente cerca de URLRewriter en uso (de hecho, parece que todos los componentes de URL Rewrite son similares. Todo lo que tenemos que hacer es configurar:

<seccionesdeconfiguración>
< sección
nombre = " reescritor "

 tipo = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Inteligencia.UrlRewriter " />
</configSections>


<reescritor>

< reescribir
URL = " ^/Usuario/(d+)$ "
a = " ~/Usuario.aspx?id=$1 "
procesamiento = " detener " />

< reescribir
URL = " ^/Usuario/(w+)$ "
a = " ~/Usuario.aspx?nombre=$1 "
procesamiento = " detener " />
</reescritor>


< sistema.web >

<httpMódulos>

< agregar
nombre = " UrlRewriter "

 tipo = " Inteligencia.UrlRewriter.RewriterHttpModule,

Inteligencia.UrlRewriter " />

</httpModules>
< /sistema.web >
Veamos principalmente el elemento de configuración <rewriter /> de las reglas de reescritura. A diferencia de URLRewriter, UrlRewriter.NET utiliza mi método favorito de un nodo por regla, lo que simplifica mucho la reescritura de reglas de todo el proyecto. ¿Pero qué significa procesar="detener"? Se trata de la forma en que UrlRewriter.NET maneja las reglas de reescritura. Cuando UrlRewriter.NET encuentra una regla de reescritura coincidente, no se detendrá aquí, sino que continuará buscando otras coincidencias. La última regla de reescritura que pueda coincidir con la solicitud actual eventualmente entrará en vigor. Si necesitamos que UrlRewriter.NET surta efecto después de encontrar una coincidencia, debemos configurar el atributo de procesamiento para que se detenga. Por ejemplo, en la configuración anterior, si "/Usuario/" va seguido de un número, se utilizará el ID de usuario para la búsqueda; de lo contrario, se considerará el nombre de usuario proporcionado actualmente.
Si UrlRewriter.NET tiene una configuración más sencilla, no tiene ninguna ventaja sobre URLRewriter. Pero las capacidades de UrlRewriter.NET van mucho más allá de eso. Lo que acabamos de usar es en realidad solo una de las acciones que proporciona. Además, también proporciona muchas acciones:

  • si
  • a menos que
  • se reescriba
  • el redireccionamiento
  • setstatus
  • prohibido
  • se fue
  • no permitido
  • no encontrado
  • no implementado
  • addheader
  • setcookie
  • setproperty
La acción por sí sola no es suficiente UrlRewriter.NET también proporciona condición, transformación, documento predeterminado, analizador, controlador de errores, registrador y otras funciones, y puede pasar. Expresión para "representar" lógica compleja. ¡Esto no es configuración, es simplemente programación! Así es, UrlRewriter.NET se puede utilizar para expresar cierta lógica de solicitud-respuesta a través de la configuración, lo que sin duda nos brinda una gran comodidad. Es imposible para mí explicar todos los aspectos de UrlRewriter.NET en detalle aquí. Los amigos interesados ​​pueden verlo más de cerca en la referencia proporcionada por su sitio web oficial. "Si tiene componentes como este, ¿qué más se puede pedir?" Sin embargo, todavía quiero recomendar otro componente aquí. Porque en algunos casos especiales, UrlRewriter.NET no puede cumplir con nuestros requisitos. ¿Eh? ¿No puede expandirse por sí solo? Así es, pero primero dejemos esto de lado y explicaré este tema en el último artículo de esta serie. UrlRewriter.NET proporciona URL Rewriter en el nivel ASP.NET. Si desea realizar una reescritura de URL en el nivel de IIS, debe utilizar otros métodos. ISAPI Rewrite es un componente muy conocido para la reescritura de URL a nivel de IIS. Desafortunadamente, este es un componente comercial y requiere que lo compremos en dólares estadounidenses. Por lo tanto, recomiendo otro producto de código abierto aquí: IIRF (Filtro de reescritura Isapi de Ionic) .
Dado que la reescritura de URL se realiza a nivel de IIS, el método de configuración de IIRF es diferente al de UrlRewriter.NET. Si desea utilizar IIRF, debe agregar IsapiRewrite4.dll a la lista de filtros ISAPI del sitio web:
IIRF se configura a través del archivo ini. IsapiRewrite4.ini e IsapiRewrite4.dll se pueden colocar en el mismo directorio:
RewriteRule ^/Usuario/(d+)$ /Usuario.aspx?id=$1 [I, L]
RewriteRule ^/Usuario/(w+)$ /Usuario.aspx?nombre=$1 [I, L]
La regla de reescritura de IIRF es "RewriteRule <url-pattern> <destination> [<modifiers>]". No hay límite en el número de espacios entre cada parte, pero debe ser un espacio, no otros caracteres de espacio en blanco como Tab. . No hace falta decir que "patrón de URL" y "destino", la clave está en el modificador. Hay muchos modificadores para IIRF. Aquí solo presentaré los dos utilizados anteriormente. "I" significa que la coincidencia es independiente de mayúsculas y minúsculas. La función de "L" es similar a procesar="stop" en UrlRewriter.NET y entrará en vigor inmediatamente cuando se encuentre la coincidencia y no continuará la búsqueda.
Aunque IIRF es un componente de código abierto, sus funciones siguen siendo relativamente poderosas. Especialmente después de combinar RewriteCond (Condición de reescritura), se pueden implementar reglas de reescritura más complejas. Por ejemplo, la siguiente configuración reescribe la solicitud del directorio raíz que contiene la palabra Googlebot en UserAgent en un recurso específico:
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
Reescribir regla ^/ $/Googlebot.html [L]
Finalmente, echemos un vistazo a la diferencia entre los dos componentes Rewrite. Obviamente, la mayor diferencia es que son reescrituras en diferentes niveles. Los dos diagramas esquemáticos siguientes describen cómo en los dos casos cambian el "/Usuario/jeffz" que debería haber obtenido el resultado "404 Recurso no encontrado". "/Usuario/nombre=jeffz".
El primero es la reescritura de URL mediante UrlRewriter.NET en el nivel ASP.NET:
Lo siguiente es la reescritura de URL de IIRF a nivel de IIS:

Con estos dos componentes, creo que ya no necesitamos nada más para implementar URL Rewrite.