La normalización de URI es el proceso mediante el cual se modifican y estandarizan los URI de manera consistente. El objetivo del proceso de normalización es transformar un URI en un URI normalizado de modo que sea posible determinar si dos URI sintácticamente diferentes pueden ser equivalentes.
Los motores de búsqueda emplean la normalización de URI para clasificar correctamente las páginas que se pueden encontrar con múltiples URI y para reducir la indexación de páginas duplicadas. Los rastreadores web realizan la normalización de URI para evitar rastrear el mismo recurso más de una vez. Los navegadores web pueden realizar la normalización para determinar si se ha visitado un enlace o para determinar si una página se ha almacenado en caché . Los servidores web también pueden realizar la normalización por muchas razones (es decir, para poder interceptar más fácilmente los riesgos de seguridad que provienen de las solicitudes de los clientes, para usar solo un nombre de archivo absoluto para cada recurso almacenado en sus cachés, nombrado en archivos de registro, etc.).
Proceso de normalización
Existen varios tipos de normalización que se pueden realizar. Algunos de ellos siempre preservan la semántica y otros no.
Normalizaciones que preservan la semántica
Las siguientes normalizaciones se describen en RFC 3986 [1] para dar como resultado URI equivalentes:
Conversión de tripletes con codificación porcentual a mayúsculas. Los dígitos hexadecimales dentro de un triplete con codificación porcentual del URI (por ejemplo, %3aversus %3A) no distinguen entre mayúsculas y minúsculas y, por lo tanto, se deben normalizar para utilizar letras mayúsculas para los dígitos AF. [2] Ejemplo:
Conversión del esquema y del host a minúsculas. Los componentes del esquema y del host de la URI no distinguen entre mayúsculas y minúsculas y, por lo tanto, se deben normalizar a minúsculas. [3] Ejemplo:
Descodificación de tripletes de caracteres no reservados codificados con porcentaje. Los tripletes de la URI codificados con porcentaje en los rangos de ALFA ( %41– %5Ay %61– %7A), DÍGITO ( %30– %39), guión ( %2D), punto ( %2E), guión bajo ( %5F) o tilde ( %7E) no requieren codificación con porcentaje y deben decodificarse con sus caracteres no reservados correspondientes. [4] Ejemplo:
http://example.com/%7Efoo→http://example.com/~foo
Eliminación de segmentos de puntos. Los segmentos de puntos .y ..los componentes de ruta de la URI se deben eliminar aplicando el algoritmo remove_dot_segments [5] a la ruta descrita en RFC 3986. [6] Ejemplo:
Conversión de una ruta vacía a una ruta "/". En presencia de un componente de autoridad, un componente de ruta vacía debe normalizarse a un componente de ruta "/". [7] Ejemplo:
Normalizaciones que generalmente preservan la semántica
Para las URI http y https, las siguientes normalizaciones enumeradas en RFC 3986 pueden dar como resultado URI equivalentes, pero los estándares no lo garantizan:
Agregar una "/" al final de una ruta que no esté vacía. Los directorios (carpetas) se indican con una barra diagonal al final y deben incluirse en las URI. Ejemplo:
http://example.com/foo→http://example.com/foo/
Sin embargo, no hay forma de saber si un componente de ruta URI representa un directorio o no. El RFC 3986 señala que si el URI anterior redirecciona al URI posterior, eso es una indicación de que son equivalentes.
Normalizaciones que cambian la semántica
La aplicación de las siguientes normalizaciones da como resultado un URI semánticamente diferente aunque pueda referirse al mismo recurso:
Eliminación del índice de directorio. Los índices de directorio predeterminados generalmente no son necesarios en las URI. Ejemplos:
Limitación de protocolos. Limitación de diferentes protocolos de la capa de aplicación . Por ejemplo, el esquema "https" podría reemplazarse por "http". Ejemplo:
https://example.com/→http://example.com/
Cómo eliminar barras duplicadas Las rutas que incluyen dos barras adyacentes se pueden convertir en una sola. Ejemplo:
Eliminar o añadir “www” como primera etiqueta de dominio. Algunos sitios web funcionan de forma idéntica en dos dominios de Internet: uno cuya etiqueta menos significativa es “www” y otro cuyo nombre es el resultado de omitir la etiqueta menos significativa del nombre del primero, siendo este último conocido como dominio simple . Por ejemplo, http://www.example.com/y http://example.com/pueden acceder al mismo sitio web. Muchos sitios web redirigen al usuario desde la dirección www a la dirección sin www o viceversa. Un normalizador puede determinar si una de estas URI redirige a la otra y normalizar todas las URI de forma adecuada. Ejemplo:
http://www.example.com/→http://example.com/
Ordenar los parámetros de consulta. Algunas páginas web utilizan más de un parámetro de consulta en la URI. Un normalizador puede ordenar los parámetros en orden alfabético (con sus valores) y volver a ensamblar la URI. Ejemplo:
Sin embargo, el orden de los parámetros en una URI puede ser significativo (esto no está definido por el estándar) y un servidor web puede permitir que la misma variable aparezca varias veces. [9]
Eliminación de variables de consulta no utilizadas. Es posible que una página solo espere que aparezcan determinados parámetros en la consulta; los parámetros no utilizados se pueden eliminar. Ejemplo:
Tenga en cuenta que un parámetro sin un valor no es necesariamente un parámetro no utilizado.
Eliminación de parámetros de consulta predeterminados. Un valor predeterminado en la cadena de consulta puede mostrarse de forma idéntica independientemente de si está presente o no. Ejemplo:
Se pueden desarrollar algunas reglas de normalización para sitios web específicos examinando listas de URL obtenidas de rastreos anteriores o registros de servidores web. Por ejemplo, si la URL
http://example.com/story?id=xyz
aparece en un registro de rastreo varias veces junto con
http://example.com/story_xyz
Podemos suponer que las dos URI son equivalentes y pueden normalizarse a una de las formas de URI.
Schonfeld et al. (2006) presentan una heurística denominada DustBuster para detectar reglas DUST (URI diferentes con texto similar) que se pueden aplicar a listas de URI. Demostraron que una vez que se encontraron las reglas DUST correctas y se aplicaron con un algoritmo de normalización, pudieron encontrar hasta el 68% de las URI redundantes en una lista de URI.
^ RFC 3986, Sección 6. Normalización y comparación
^ RFC 3986, Sección 6.2.2.1. Normalización de mayúsculas y minúsculas
^ RFC 3986, Sección 6.2.2.1. Normalización de mayúsculas y minúsculas
^ RFC 3986, Sección 6.2.2.3. Normalización de segmentos de ruta
^ RFC 3986, 5.2.4. Eliminar segmentos de puntos
^ RFC 3986, 6.2.2.3. Normalización de segmentos de ruta
^ RFC 3986, Sección 6.2.3. Normalización basada en esquemas
^ RFC 3986, Sección 6.2.3. Normalización basada en esquemas
^ "jQuery 1.4 $.param desmitificado". Ben Alman. 20 de diciembre de 2009. Consultado el 24 de agosto de 2013 .
RFC 3986 - Identificador uniforme de recursos (URI): sintaxis genérica
Sang Ho Lee; Sung Jin Kim y Seok Hoo Hong (2005). On URL normalization (PDF) . Actas de la Conferencia Internacional sobre Ciencias Computacionales y sus Aplicaciones (ICCSA 2005). pp. 1076–1085. Archivado desde el original (PDF) el 18 de septiembre de 2006.
Uri Schonfeld; Ziv Bar-Yossef & Idit Keidar (2006). No te arrastres por el polvo: diferentes URL con texto similar. Actas de la 15.ª conferencia internacional sobre la World Wide Web . Págs. 1015–1016.
Uri Schonfeld; Ziv Bar-Yossef & Idit Keidar (2007). No te arrastres por el polvo: diferentes URL con texto similar. Actas de la 16.ª conferencia internacional sobre la World Wide Web. Págs. 111–120.
