¿Son los dos puntos `:` seguros para el uso de URL amigables?

Estamos diseñando un sistema de URL que especificará las secciones de la aplicación como palabras separadas por barras. Específicamente, esto está en GWT, por lo que las partes relevantes de la URL estarán en el hash (que será interpretado por una capa de controlador en el lado del cliente):

http://site/gwturl#section1/section2

Algunas secciones pueden necesitar atributos adicionales, que nos gustaría especificar con un :, para que las partes de la sección de la URL no sean ambiguas. El código se dividiría primero /y luego :, así:

http://site/gwturl#user:45/comments

Por supuesto, estamos haciendo esto para facilitar la URL, por lo que nos gustaría asegurarnos de que ninguno de estos caracteres que tengan un significado especial sea codificado en URL por los navegadores o cualquier otro sistema, y ​​termine con una URL como esta:

http://site/gwturl#user%3A45/comments <--- BAD

¿Es seguro usar los dos puntos de esta manera (con lo que quiero decir que no se codificará automáticamente) para navegadores, sistemas de marcadores, incluso código Javascript o Java?

Recientemente escribí un codificador de URL, por lo que esto está bastante fresco en mi mente.

http://site/gwturl#user:45/comments

Todos los caracteres en la parte del fragmento ( user:45/comments) son perfectamente legales para RFC 3986 URI.

Las partes relevantes de la ABNF :

fragment      = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Aparte de estas restricciones, la parte del fragmento no tiene una estructura definida más allá de la que le da su aplicación. El esquema, http, solo dice que no envíe esta parte al servidor.

EDITAR:

¡Oh!

A pesar de mis afirmaciones sobre la especificación URI, irreputable proporciona la respuesta correcta cuando señala que la especificación HTML 4 restringe los nombres / identificadores de elementos .

Tenga en cuenta que las reglas de identificación están cambiando en HTML 5 . Las restricciones de URI se seguirán aplicando (en el momento de redactar este documento, hay algunos problemas sin resolver en torno al uso de URI de HTML 5).

Además del análisis de McDowell sobre el estándar URI, recuerde también que el fragmento debe ser un nombre de anclaje HTML válido. Según http://www.w3.org/TR/html4/types.html#type-name

Los tokens de ID y NOMBRE deben comenzar con una letra ([A-Za-z]) y pueden ir seguidos de cualquier número de letras, dígitos ([0-9]), guiones ("-"), guiones bajos ("_") , dos puntos (":") y puntos (".").

Así que estás de suerte. ":" está explícitamente permitido. Y nadie debería "%" - escapar de él, no sólo porque "%" es un carácter ilegal allí, sino también porque el fragmento debe coincidir con el nombre del ancla char-by-char, por lo que ningún agente debería intentar manipularlos de ninguna manera.

Sin embargo tienes que probarlo. Los estándares web no se siguen estrictamente, a veces los estándares están en conflicto. Por ejemplo, HTTP / 1.1 RFC 2616 no permite una cadena de consulta en la URL de la solicitud, mientras que HTML construye una cuando se envía un formulario con el método GET. Cualquiera que sea implementado en el mundo real gana al final del día.

MediaWiki y otros motores wiki utilizan dos puntos en sus URL para designar espacios de nombres, aparentemente sin problemas importantes.

por ejemplo, http://en.wikipedia.org/wiki/Template:Welcome

No contaría con eso. Es probable que obtenga la URL codificada como %3Apor muchos agentes de usuario.

Desde URLEncoderjavadoc:

Para obtener más información sobre la codificación de formularios HTML, consulte la especificación HTML .

Al codificar una cadena, se aplican las siguientes reglas:

• Los caracteres alfanuméricos "a" a "z", "A" a "Z" y "0" a "9" siguen siendo los mismos.
• Los caracteres especiales ".", "-", "*" y "_" siguen siendo los mismos.
• El carácter de espacio "" se convierte en un signo más "+".
• Todos los demás caracteres no son seguros y primero se convierten en uno o más bytes utilizando algún esquema de codificación. Luego, cada byte está representado por la cadena de 3 caracteres "% xy", donde xy es la representación hexadecimal de dos dígitos del byte. El esquema de codificación recomendado para usar es UTF-8. Sin embargo, por razones de compatibilidad, si no se especifica una codificación, se utiliza la codificación predeterminada de la plataforma.

Es decir, :no es seguro.

No veo que Firefox o IE8 codifiquen algunas de las URL de Wikipedia que incluyen el carácter.

Los dos puntos se utilizan para dividir el nombre de usuario y la contraseña si un protocolo requiere autenticación.

Colon no está seguro. Mira aquí

No es un carácter seguro y se usa para distinguir a qué puerto se conecta cuando está justo después de su nombre de dominio.