La normalización de URI es el proceso mediante el cual las URI se modifican y estandarizan de manera coherente. El objetivo del proceso de normalización es transformar un URI en un URI normalizado para 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 asignar importancia a las páginas web [ aclarar ] y 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é .
Proceso de normalización
Hay varios tipos de normalización que se pueden realizar. Algunos de ellos siempre conservan la semántica y otros pueden no serlo.
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 codificados en porcentaje a mayúsculas. Los dígitos hexadecimales dentro de un triplete de codificación porcentual del URI (p. Ej.,
%3a
Versus%3A
) no distinguen entre mayúsculas y minúsculas y, por lo tanto, deben normalizarse para usar letras mayúsculas para los dígitos AF. [2] Ejemplo:
http://example.com/foo%2a
→http://example.com/foo%2A
- Conversión del esquema y el host a minúsculas. El esquema y los componentes del host del URI no distinguen entre mayúsculas y minúsculas y, por lo tanto, deben normalizarse a minúsculas. [3] Ejemplo:
HTTP://[email protected]/Foo
→http://[email protected]/Foo
- Decodificación de tripletes codificados en porcentaje de caracteres no reservados. Los tripletes codificados porcentualmente del URI en los rangos de ALPHA (
%41
-%5A
y%61
-%7A
), DIGIT (%30
-%39
), guión (%2D
), punto (%2E
), subrayado (%5F
) o tilde (%7E
) no requieren codificación porcentual y deben decodificarse para sus correspondientes caracteres sin reservas. [4] Ejemplo:
http://example.com/%7Efoo
→http://example.com/~foo
- Eliminando segmentos de puntos. Los segmentos de puntos
.
y..
en el componente de ruta del URI deben eliminarse aplicando el algoritmo remove_dot_segments [5] a la ruta descrita en RFC 3986. [6] Ejemplo:
http://example.com/foo/./bar/baz/../qux
→http://example.com/foo/bar/qux
- Conversión de una ruta vacía en una ruta "/". En presencia de un componente de autoridad, un componente de ruta vacío debe normalizarse a un componente de ruta de "/". [7] Ejemplo:
http://example.com
→http://example.com/
- Eliminando el puerto predeterminado. Se debe eliminar un componente de puerto vacío o predeterminado del URI (puerto 80 para el
http
esquema) con su delimitador ":". [8] Ejemplo:
http://example.com:80/
→http://example.com/
Normalizaciones que suelen conservar la semántica
Para http y https URI, las siguientes normalizaciones enumeradas en RFC 3986 pueden dar como resultado URI equivalentes, pero los estándares no lo garantizan:
- Agregar un "/" final a una ruta no vacía. Los directorios (carpetas) se indican con una barra diagonal y deben incluirse en los URI. Ejemplo:
http://example.com/foo
→http://example.com/foo/
- Sin embargo, no hay forma de saber si un componente de ruta de URI representa un directorio o no. RFC 3986 señala que si el primer URI redirige al último URI, 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 puede hacer referencia al mismo recurso:
- Eliminando el índice de directorio. Los índices de directorio predeterminados generalmente no son necesarios en los URI. Ejemplos:
http://example.com/default.asp
→http://example.com/
http://example.com/a/index.html
→http://example.com/a/
- Eliminando el fragmento. El servidor nunca ve el componente de fragmento de un URI y, en ocasiones, puede eliminarlo. Ejemplo:
http://example.com/bar.html#section1
→http://example.com/bar.html
- Sin embargo, las aplicaciones AJAX utilizan con frecuencia el valor del fragmento.
- Reemplazo de IP con nombre de dominio. Compruebe si la dirección IP se asigna a un nombre de dominio. Ejemplo:
http://208.77.188.166/
→http://example.com/
- El reemplazo inverso rara vez es seguro debido a los servidores web virtuales .
- Protocolos limitantes. Limitación de diferentes protocolos de capa de aplicación . Por ejemplo, el esquema "https" podría reemplazarse por "http". Ejemplo:
https://example.com/
→http://example.com/
- Eliminación de barras inclinadas duplicadas Las rutas que incluyen dos barras adyacentes se pueden convertir en una. Ejemplo:
http://example.com/foo//bar.html
→http://example.com/foo/bar.html
- Eliminar o agregar "www" como la primera etiqueta de dominio. Algunos sitios web operan de manera 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/
yhttp://example.com/
puede acceder al mismo sitio web. Muchos sitios web redirigen al usuario de www a la dirección que no es www o viceversa. Un normalizador puede determinar si uno de estos URI redirige al otro y normaliza todos los URI de forma adecuada. Ejemplo:
http://www.example.com/
→http://example.com/
- Ordenar los parámetros de la consulta. Algunas páginas web utilizan más de un parámetro de consulta en el URI. Un normalizador puede ordenar los parámetros en orden alfabético (con sus valores) y reensamblar el URI. Ejemplo:
http://example.com/display?lang=en&article=fred
→http://example.com/display?article=fred〈=en
- Sin embargo, el orden de los parámetros en un 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]
- Eliminando variables de consulta no utilizadas. Una página solo puede esperar que aparezcan ciertos parámetros en la consulta; los parámetros no utilizados se pueden eliminar. Ejemplo:
http://example.com/display?id=123&fakefoo=fakebar
→http://example.com/display?id=123
- Tenga en cuenta que un parámetro sin un valor no es necesariamente un parámetro no utilizado.
- Eliminando los parámetros de consulta predeterminados. Un valor predeterminado en la cadena de consulta se puede representar de manera idéntica, ya sea que esté allí o no. Ejemplo:
http://example.com/display?id=&sort=ascending
→http://example.com/display
- La eliminación de la "?" cuando la consulta está vacía. Cuando la consulta está vacía, es posible que no haya necesidad de "?". Ejemplo:
http://example.com/display?
→http://example.com/display
Normalización basada en listas de URI
Se pueden desarrollar algunas reglas de normalización para sitios web específicos examinando listas de URI obtenidas de rastreos anteriores o registros de servidores web. Por ejemplo, si el URI
http://example.com/story?id=xyz
aparece en un registro de rastreo varias veces junto con
http://example.com/story_xyz
podemos suponer que los dos URI son equivalentes y se pueden normalizar a una de las formas de URI.
Schonfeld y col. (2006) presentan una heurística llamada DustBuster para detectar reglas DUST (diferentes URI con texto similar) que se pueden aplicar a listas de URI. Demostraron que una vez que se encontraron y aplicaron las reglas DUST correctas con un algoritmo de normalización, pudieron encontrar hasta el 68% de los URI redundantes en una lista de URI.
Ver también
Referencias
- ^ RFC 3986, Sección 6. Normalización y comparación
- ^ RFC 3986, sección 6.2.2.1. Normalización de casos
- ^ RFC 3986, sección 6.2.2.1. Normalización de casos
- ^ RFC 3986, sección 6.2.2.3. Normalización del segmento de ruta
- ^ RFC 3986, 5.2.4. Eliminar segmentos de puntos
- ^ RFC 3986, 6.2.2.3. Normalización del segmento 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). Sobre la normalización de URL (PDF) . Actas de la Conferencia Internacional sobre Ciencias Computacionales y sus Aplicaciones (ICCSA 2005). págs. 1076–1085. Archivado desde el original (PDF) el 18 de septiembre de 2006.
- Uri Schonfeld; Ziv Bar-Yossef e Idit Keidar (2006). No se arrastre por el polvo: diferentes URL con texto similar . Actas de la 15ª conferencia internacional sobre World Wide Web . págs. 1015–1016.
- Uri Schonfeld; Ziv Bar-Yossef e Idit Keidar (2007). No se arrastre por el polvo: diferentes URL con texto similar . Actas de la 16ª conferencia internacional sobre World Wide Web. págs. 111-120.