URL y las letras raras

Una de las preguntas recursivas en SEO, y sobre todo cuando se plantea un proyecto muy internacional es el de qué tipo de caracteres en las URL hay que usar en un sitio web que no es «occidental». Supongo que cuando se hace uso del concepto «occidental» se hace referencia al sistema de caracteres ASCII.

La respuesta a este tipo de preguntas es un poco complejo. Si bien está permitido y es posible codificar las URL, la recomendación (de principios de Internet) es que no se haga uso de otros caracteres que no sean parte de un rango concreto del ASCII.

Para explicarlo todo mejor me voy a basar en la documentación oficial, es decir, los RFC, en este caso los siguientes:

• RFC 1630: Universal Resource Identifiers in WWW
• RFC 1736: Functional Recommendations for Internet Resource Locators
• RFC 1737: Functional Requirements for Uniform Resource Names
• RFC 1738: Uniform Resource Locators (URL)
• RFC 1808: Relative Uniform Resource Locators
• RFC 2368: The mailto URL scheme
• RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax
• RFC 2732: Format for Literal IPv6 Addresses in URL’s
• RFC 3491: Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
• RFC 3987: Internationalized Resource Identifiers (IRIs)
• RFC 4248: The telnet URI Scheme
• RFC 4266: The gopher URI Scheme
• RFC 5987: Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
• RFC 6196: Moving mailserver: URI Scheme to Historic
• RFC 6270: The ‘tn3270’ URI Scheme

Principalmente los RFC que hablan o que dejan de forma definitiva cómo ha de ser la estructura y qué y cómo funciona son el 1630 (documento de Tim Berners-Lee de Junio de 1994), 3986 y el 3987, con el añadido del 5987. ¿Y qué dicen estos estándar?

En el primer documento se habla de las diferencias entre URI, URL y URN, de la necesidad de establecer un sistema universal. El objetivo final tenía 3 propósitos: que fuera extensible para que se pudieran añadir nuevos formatos y estructuras en el futuro, completo de forma que se pudiera codificar cualquier sistema e «imprimible» por lo que se sugería el uso del ASCII 7-bits para que se pudiera escribir cualquier dirección «a mano» (vamos, en un papel, de forma sencilla).

NOTA sobre los recursos:

Una URI es lo que conocemos como la dirección completa que aparece en el navegador, lo que incluye el «protocolo» o «schema».

Ejemplo: http://example.com/example.html?test=1#seccion

Una URL es la dirección sin necesidad de incorporar el protocolo…

Ejemplo: //example.com/example.html?test=1#seccion

Un URN es simplemente el nombre de un recurso…

Ejemplo: urn:isbn:9788441527829

Por eso, cuando hablemos de SEO propiamente dicho, habría que hablar de las URL ya que -en principio- no hay que tener en cuenta el protocolo (seguro o no) del HTTP.

Como detalles curiosos, se prefirió elegir la escritura de izquierda a derecha que la de derecha a izquierda por se la más común, y el hecho de haber elegido los «dos puntos» como separador (en los protocolos) fue algo de forma «arbitraria».

Se definió el uso de los llamados caracteres «seguros» y «no-seguros». Es por esto que quedaron algunos caracteres con funciones especiales:

• «%» (ASCII 25 hex): Se usa para la codificación de caracteres «extraños».
• «/» (ASCII 2F hex): Se usa para delimitar subfragmentos de texto que dependen por herencia (vamos, lo que conocemos como «carpetas» o «niveles»). También se definía lo mismo con un punto (.) o dos puntos (..).
• «#» (ASCII 23 hex): Se usa como delimitador para separar la URL de un objeto de un identificador.
• «?» (ASCII 3F hex): Se usa como delimitador de la URI de un objeto «consultable» (vamos, un parámetro). En estos parámetros el símbolo «+» se usaría como «unión». En el caso de tener que poner un símbolo «+» habría que codificarlo.
• «*» (ASCII 2A hex) y «!» (ASCII 21 hex) se reservan para significados distintos según el schema pertinente (es decir, según el protocolo que se use: HTTP, Telnet, Mail, Gopher…).

Un detalle curioso es que, si os fijáis, hoy en día usamos otra serie de caracteres como habituales que en su momento no pasaron este corte. El caso más claro era el del «guión». En aquel momento se planteaba que el guión no era un carácter especial.

Y tras esta base llegan un montón de RFC que, hoy en día, acaban siendo actualizados por el 3986. Este es el documento que hoy en día indica cómo han de ser las URI, en una sintaxis genérica. Es curioso que este documento es de 11 años después del primero, o sea, de enero de 2005, lo que significa que se podría plantear como una versión 2 muy importante y que deja claro cómo ha de ser el futuro de Internet.

Cuando hablamos de cómo ha de ser una URI (siguiendo lo que comentaba de los 3 grandes puntos al principio) tenemos que:

• Una URI es una secuencia de caracteres que no siempre representa una secuencia de «octetos».
• Una URI debe poder ser transcrita desde una «no-red» (un papel, vamos) y debería constar de una serie de caracteres que pueden ser introducidos a un ordenador a través de un teclado, independientemente del idioma.
• Una URI debería ser fácilmente recordable por las personas, y para ello debe estar formada por subpartes fácilmente familiares y significantes.

¿Qué caracteres deberíamos usar? Básicamente todo se basa en el US-ASCII. El símbolo % quedará como sistema de codificación. Esto implica que los caracteres no-seguros se pintarán como % seguido de 2 números. Estos números harán referencia al hexadecimal. Por ejemplo, el %20 hace referencia al caracter 20 del ASCII, que es el «espacio». El resto de caracteres especiales queda definido en la lista: «!», «$», «&», «‘», «(«, «)», «*», «+», «,», «;» y «=». Los caracteres no reservados son: «letras», «números», «-«, «.», «_» y «~». En estos últimos casos, cuando uno de ellos se encuentre codificado en la URL, se debe convertir a su valor original. Esto significa que si nos encontramos con una dirección así:

//example.com/ejemplo%2Dde%2Durl%2Ehtml

el navegador (o cualquier sistema) debe dejarlo estandarizado en:

//example.com/ejemplo-de-url.html

De esta forma, estos son caracteres semi-reservados ya que tienen un trato especial.

Las direcciones URI estarán formadas por los siguientes componentes:

  foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |           |            |            |        |
scheme     authority       path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

No voy a entrar en qué ha de tener el «schema» o el «authority», porque eso está muy limitado. De cara al SEO y a la Arquitectura de la Información, lo importante es el «path», el «query» y el «fragment».

¿Qué elementos son destacables en el «path»? Pues para empezar el uso de «.» o de «..». Esto indica un nivel actual o un nivel «anterior». Otros elementos serían el punto y coma «;» y el igual «=» que se reservan frecuentemente para delimitar parámetros y valores. La coma «,» también se reserva para un uso similar al anterior.

¿Qué elementos son destacables en el «query»? Pues principalmente el signo de interrogación «?» que indica el comienzo.

¿Qué elementos son destacables en el «fragment»? Pues principalmente el signo almohadilla «#» que indica el comienzo.

A lo largo de lo que llevo comentado he hablado de los dos puntos «..». Este caso es muy concreto porque, al igual que los caracteres normales se han de recodificar, las direcciones URL que incluyan este caso también deberían codificarse. Esto es como ejemplo, lo siguiente:

//example.com/ejemplo-1/../ejemplo-2/

En realidad quedaría como:

//example.com/ejemplo-2/

Con respecto a la normalización del «schema» hay que tener presente que estas 4 direcciones son iguales:

http://example.com

http://example.com/

http://example.com:/

http://example.com:80/

HTTP://EXAMPLE.COM/

Pero de entre estas 4 direcciones hay que plantearse que una es la óptima. Esto significa que hay que aplicar algunas reglas. Para comenzar lo ideal es que acabe en «barra», y que si el puerto es el de por defecto no se incluya. Además, esta primera parte debe estar en minúsculas. Esto significa que la dirección URI óptima sería la siguiente:

http://example.com

Con respecto a otros componentes, y que hacen referencia a la «barra final», tenemos por ejemplo estas dos direcciones:

http://example.com/data

http://example.com/data/

Aquí hay un detalle. Si estas dos direcciones acaban mostrando el mismo contenido (que es lo habitual), es más que recomendable que se utilice la de la barra final como principal.

http://example.com/data

Cambiando al RFC 3987 tenemos un nuevo concepto delante: Internationalized Resource Identifier (IRI). Esto es un complemento de las URI, que es una secuencia de caracteres del Unicode / ISO 10646, formado por cerca de cien mil caracteres abstractos. Al final, como resumen, podemos decir que es el formato conocido como UTF-16.

¿Por qué hacer aparecer el IRI? Básicamente porque aunque se recomienda convertir caracteres no-ASCII a ASCII, hay veces que es conversión implica que algunas palabras no acaben de ser completamente razonables, o pueden implicar ambigüedad.

¿Cuándo se debe usar un IRI sobre un URI? Los protocolos deben estar designados para los IRI, algo que a priori no nos debería importar mucho para SEO y para nuestro trabajo habitual, pero, sí que hay otro punto y es el de usar IRI cuando la URI está codificada en UTF-8. El objetivo es cambiar las IRI a la codificación estándar de URI.

Personalmente las direcciones tales como:

http://example.com/???

deberían transcribirse a una dirección tal que esta:

http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82

Otro ejemplo de IRI es el tema de los dominios IDN (International Domain Name). En este caso la transcripción debe hacerse con el sistema PunyCode. Un ejemplo sería que la dirección del texto:

PorquénopuedensimplementehablarenEspañol

Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol

acabaría siendo, en modo PunyCode así:

xn--PorqunopuedensimplementehablarenEspaol-fmd56a

Está claro que tener direcciones URI así está bien, porque todo son caracteres comprensibles, pero desde el unto de vista SEO no acaba de estar del todo bien.

Otro ejemplo, por ejemplo en checo, sería esto:

Pročprostěnemluvíčesky

Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky

acabaría como:

xn--Proprostnemluvesky-uyb24dma41a

Lo más difícil sería ya con algo tal que así, en ruso:

почемужеонинеговорятпорусски

que en formato PunyCode quedaría así:

xn--b1abfaaepdrnnbgefbaDotcwatmq2g4l

Hay que tener en cuenta otra cosa. Por norma general los elementos que incluyen una dirección URL (como por ejemplo los «a» o «img») deben permitir que la dirección esté codificada. Es cosa de los navegadores la migración de la codificación a la codificación correspondiente. Esto significa que cuando en HTML se pone un enlace, habría que indicarlo de esta forma:

<a href="//ejeñplo.com/quéquieresdecirniño/">ejemplo</a>

En principio esto sería correcto, y el propio navegador hará la codificación, pero… ¿qué ocurre con los robots tipo Googlebot? Pues la verdad es que se puede decir que no hay mucha documentación sobre ello, y documentación oficial no parece haber ninguna, lo que significa que las codificaciones «extrañas» no acaban de quedar muy claras de cara al SEO y a la interpretación por parte de Google y otros.

¿Cuál es mi opinión personal y basada en la experiencia? Es mejor limitarse a usar sólo el rango [a-z0-9], ni siquiera mayúsculas para evitar problemas de duplicidades.