gwt meta - Es un colon `:` seguro para el uso amigable de URL?




tags ejemplos (9)

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.

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 : modo que las partes de la sección de la URL no sean ambiguas. El código se dividiría primero en / y luego en : esta manera:

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

Por supuesto, estamos haciendo esto para la compatibilidad con 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 ​​terminan con una url como esta:

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

¿Utilizar los dos puntos de este modo es seguro (con lo que quiero decir que no se codificará automáticamente) para navegadores, sistemas de marcadores, incluso código JavaScript o Java?


No veo que Firefox o IE8 codifiquen algunas de las URLs Wikipedia que incluyen el personaje.


No contaría con eso. Es probable que muchos usuarios-agente lo codifiquen como %3A .



Desde URLEncoder javadoc:

Para obtener más información sobre la codificación de formularios HTML, consulte la specification 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 son inseguros y se convierten primero en uno o más bytes utilizando algún esquema de codificación. Entonces cada byte se representa con 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, entonces se utiliza la codificación predeterminada de la plataforma.

Es decir,: no es seguro.


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

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

Entonces estás de suerte. ":" está explícitamente permitido. Y nadie debería "%" - escapar, no solo porque "%" es ilegal char allí, sino también porque el fragmento coincide mucho con el nombre de anclaje char-by-char, por lo tanto, ningún agente debe tratar de atenuarse con ellos de todos modos.

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



Los puntos se usan como la división entre el nombre de usuario y la contraseña si un protocolo requiere autenticación.


Codificar cadena de URL

    var url = $(location).attr('href'); //get current url
    //OR
    var url = 'folder/index.html?param=#23dd&noob=yes'; //or specify one

var encodedUrl = encodeURIComponent(url);
console.log(encodedUrl);
//outputs folder%2Findex.html%3Fparam%3D%2323dd%26noob%3Dyes


for more info go http://www.sitepoint.com/jquery-decode-url-string




url gwt special-characters friendly-url