Todos manejamos URL a diario, pero sin pensar mucho qué son, cómo se componen y cómo funcionan. Eso es aceptable para un usuario, pero todo desarrollador tiene que entender ciertos mínimos de HTTP y sus componentes principales, como son las URL y URI. Así que vamos a por ello, que seguro que es sencillo y no hay ñapas.
Una red de recursos
Lo primero que hay que tener claro es que la web, tal como fue inventada por Tim Berners Lee allá en el CERN en tiempos primigenios (¡usando lo que hoy son macOS y Objective-C!), era una red de recursos.
Un recurso es cualquier cosa que puede ser identificada y localizada.
Por ejemplo, son recursos: un documento, una imagen, un página web, un endpoint de una API, etc.
¿Qué es una URI?
Una URI (Uniform Resource Identifier) es algo que identifica de forma única un recurso.
Por ejemplo, el número de DNI 10837665G permite identificar a una persona, pero no localizarla.
¿Qué es una URL?
Una URL (Uniform resource locator) es un subconjunto de las URI que, además de identificar, también te permite encontrar ese recurso. Toda URL es una URI, pero no todas las URI son URL.
Volviendo a la analogía de las personas, si el número de DNI es la URI, su dirección sería la URL.
Sintaxis de las URL
Todas las URI y URL tienen una sintaxis muy específica:
<scheme>://<host>:<port>/<path>?<query>#<fragment>
Scheme
Describe cómo acceder al recurso, no dónde está. Veamos algunos ejemplos:
- http: http mondo lirondo
- https: http encriptado
- ftp: File transfer protocol. ¿te acuerdas?
- gopher: seguro que no te acuerdas
- mailto: para enviar emails desde una página html
- file: para localizar ficheros en tu propia máquina
- chrome: para cosas específicas de chrome
Host
El servidor que hospeda el recurso.
Path
La ruta a donde está el recurso dentro del host. No tiene por qué ser un fichero en un sistema de ficheros, es una interfaz abstracta. La ruta (path) es sensible a la caja, aunque la mayoría de los servidores lo ignoran. Se hace así para evitar enlaces rotos por un error mínimo de tipografía por parte del usuario.
Port
El puerto en que el host está esperando la conexión. Por defecto, para http es el 80.
Query
La query, también llamada query string, contiene información extra para que la use el destinatario de la URL. No hay un estándar formal de cómo empaquetar esa información, pero en la práctica totalidad de los casos es una lista de parejas clave/valor del tipo:
nombre1=valor1&nombre2=valor2
Por ejemplo:
https://foo.com?first=Lucas&last=Grijander
Fragment
El fragment es distinto de todo lo demás, porque no lo procesa el servidor. El fragment se usa solo en el cliente e identifica una sección (o fragmento) particular del recurso.
En general, fragment se usa para identificar un elemento específico de HTML en un página mediante su ID.
Ejemplo completo de URL:
http://localhost:8888/lab/tree/HTTP-101-1-Resources.ipynb#fragment
- Scheme: http
- Host: localhost
- Port: 8888
- Path: lab/tree/HTTP-101-1-Resources.ipynb
- Query: Nada
- Fragment: fragment
Caracteres permitidos en las URI y URL
El RFC 3986 (la LEY de las URL) define que solo se puede usar los caracteres de US-ASCII junto con algunos extras, como “:” y “/”. Todo lo demás debe de ser codificado usando un esquema llamado URL Encode. En URL Encode, los caracteres que se salen de lo permitido se representan de la siguiente manera:
%<algún número>
¿Coño y la ñ? Caracteres unicode en URI y URL
Pues sí, hamijo, la ñ está fuera. También lo están todos los caracteres UNICODE, pero no te preocupes, que está resuelto. Mal, pero está resuelto.
Caracteres unicode en el host
Empecemos por el caso de tener una ñ (o cualquier carácter unicode) en el host, es decir, en el nombre del dominio. Por ejemplo: www.aceleraespaña.org
Tendrá que ser codificado usando un esquema llamado Punycode.
Caracteres unicode en el path o query
Aquí se utiliza otro tipo de codificación distinta (sí ya lo sé…). Los caracteres se codifican mediante url encode (con un montón de porcentajes), pero el browser normalmente te lo oculta.
Por ejemplo:
http://ko.wikipedia.org/wiki/%EC%9C%84%ED%82%A4%EB%B0%B1%EA%B3%BC:%EB%8C%80%EB%AC%B8
Pega eso en un browser y verás que te salen los caracteres coreanos, pero si lo copias en un fichero de texto, te saldrá el horror lleno de porcentajes.
Por cierto, lo que tienes ahí ya no es una URI o URL, sino una IRI (Internationalized Uniform Identifier).
La verdad es que casi mejor lo vamos dejando, porque esto se vuelve un lío. Eso sí, antes de despedirnos, veamos tres cosas más.
¿Uso IRI o URL?
Usa URL. Las IRI, además de ser un lío, como acabas de ver, hacen más fácil el phishing al colarte caracteres parecidos. Por ejemplo, si quisiera atacar a los usuarios del banco Santander, podría convencerlos para que hagan login en la siguiente dirección, donde he cambiado la letra a por el carácter unicode α, que se le parece mucho:
¿Y la ñ?
La tilde de la ñ proviene de una abreviatura medieval para la doble n. Es decir, es perfectamente correcto escribir Espanna en vez de España.
¿Cómo sabías que aquel texto raro era coreano?
De los sistemas de escritura asiáticos más comunes, como el chino simplificado, chino tradicional, japonés o coreano, el coreano es el único que tiene círculos o bolitas. Así que si ves un texto raruno con bolitas, seguro que es coreano.
Ya sabes más de lo que querías sobre URL y otras yerbas, así que 안녕히! (Adiós en coreano, como ya habrás detectado por las bolitas).
