Le signe deux-points `:` est-il sûr pour une utilisation avec une URL conviviale?

Nous concevons un système d'URL qui spécifiera les sections d'application sous forme de mots séparés par des barres obliques. Plus précisément, c'est dans GWT, donc les parties pertinentes de l'URL seront dans le hachage (qui sera interprété par une couche de contrôleur côté client):

http://site/gwturl#section1/section2

Certaines sections peuvent nécessiter des attributs supplémentaires, que nous aimerions spécifier avec un :, afin que les parties de section de l'URL soient sans ambiguïté. Le code se diviserait d'abord sur /, puis sur :, comme ceci:

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

Bien sûr, nous le faisons pour la convivialité des URL, nous souhaitons donc nous assurer qu'aucun de ces caractères qui auront une signification particulière ne sera encodé par les navigateurs, ou tout autre système, et se retrouvera avec une URL comme ce:

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

Est-ce que l'utilisation des deux points de cette manière est sûre (ce que je veux dire ne sera pas automatiquement encodée) pour les navigateurs, les systèmes de signets, même le code Javascript ou Java?

J'ai récemment écrit un encodeur d'URL, donc c'est assez frais dans mon esprit.

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

Tous les caractères de la partie fragment ( user:45/comments) sont parfaitement légaux pour RFC 3986 URI .

Les parties pertinentes de l' ABNF :

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

En dehors de ces restrictions, la partie fragment n'a pas de structure définie au-delà de celle que votre application lui donne. Le schéma, http, dit seulement que vous n'envoyez pas cette partie au serveur.

ÉDITER:

Oh!

Malgré mes affirmations sur la spécification URI, irreputable fournit la réponse correcte quand il souligne que la spécification HTML 4 restreint les noms / identificateurs d'élément .

Notez que les règles d'identifiant changent dans HTML 5 . Les restrictions d'URI s'appliqueront toujours (au moment de la rédaction de cet article, il y a des problèmes non résolus concernant l'utilisation des URI par HTML 5).

En plus de l'analyse de McDowell sur la norme URI, rappelez-vous également que le fragment doit être un nom d'ancre HTML valide. Selon http://www.w3.org/TR/html4/types.html#type-name

Les jetons ID et NOM doivent commencer par une lettre ([A-Za-z]) et peuvent être suivis de n'importe quel nombre de lettres, chiffres ([0-9]), tirets ("-"), traits de soulignement ("_") , deux points (":") et des points (".").

Alors vous avez de la chance. ":" est explicitement autorisé. Et personne ne devrait "%" - y échapper, non seulement parce que "%" est un caractère illégal, mais aussi parce que le fragment doit correspondre au nom de l'ancre char-par-caractère, donc aucun agent ne doit essayer de les altérer de quelque manière que ce soit.

Cependant, vous devez le tester. Les standards du Web ne sont pas strictement respectés, parfois les standards sont contradictoires. Par exemple, HTTP / 1.1 RFC 2616 n'autorise pas la chaîne de requête dans l'URL de la requête, tandis que HTML en construit une lors de la soumission d'un formulaire avec la méthode GET. Celui qui est mis en œuvre dans le monde réel l'emporte à la fin de la journée.

MediaWiki et d'autres moteurs wiki utilisent des deux-points dans leurs URL pour désigner les espaces de noms, sans apparemment aucun problème majeur.

par exemple http://en.wikipedia.org/wiki/Template:Bienvenue

Je ne compterais pas dessus. Il sera probablement encodé en URL comme %3Apar de nombreux agents utilisateurs.

De URLEncoderjavadoc:

Pour plus d'informations sur l'encodage de formulaire HTML, consultez la spécification HTML .

Lors de l'encodage d'une chaîne, les règles suivantes s'appliquent:

• Les caractères alphanumériques «a» à «z», «A» à «Z» et «0» à «9» restent les mêmes.
• Les caractères spéciaux ".", "-", "*" et "_" restent les mêmes.
• Le caractère espace "" est converti en signe plus "+".
• Tous les autres caractères ne sont pas sûrs et sont d'abord convertis en un ou plusieurs octets à l'aide d'un schéma de codage. Ensuite, chaque octet est représenté par la chaîne de 3 caractères "% xy", où xy est la représentation hexadécimale à deux chiffres de l'octet. Le schéma de codage recommandé à utiliser est UTF-8. Cependant, pour des raisons de compatibilité, si un encodage n'est pas spécifié, alors l'encodage par défaut de la plateforme est utilisé.

Autrement dit, :n'est pas sûr.

Je ne vois pas Firefox ou IE8 encoder certaines des URL de Wikipédia qui incluent le caractère.

Les deux points sont utilisés pour séparer le nom d'utilisateur et le mot de passe si un protocole nécessite une authentification.

Colon n'est pas sûr. Vois ici

Ce n'est pas un caractère sûr et est utilisé pour distinguer le port auquel vous vous connectez lorsqu'il se trouve juste après votre nom de domaine