2009-11-07 16 views

Respuesta

20

sí, se puede utilizar en claro en su ruta URL así:

http://example.com/Alice&Bob 

Sólo si desea utilizarlo en la consulta que necesita para codificar con %26:

http://example.com/?arg=Alice%26Bob 

De lo contrario, se interpretaría como separador de argumentos cuando se interpreta como application/x-www-form-urlencoded.

Ver RFC 3986 para más detalles.

+0

Espero que esto sea cierto: marcaría la diferencia entre una respuesta buena y una mala. Las citas con fecha en línea de * RFC3986 * pueden hacer que esto sea excelente – Borodin

2

A menos que agregue variables a la cadena de consulta, codifíquela.

1

codificar '&' con & (esta respuesta se basa en el uso de las etiquetas)

Si se está preguntando qué usar "&" o "y" al registrar el nombre de su URL, me gustaría utilizar "y".

EDITAR: Como se mencionó en los comentarios "& es una entidad de caracteres HTML y no una entidad de caracteres URI. Al poner eso en un URI, todavía tiene el carácter de ampersand y caracteres extraños adicionales". Empecé a responder antes de comprender completamente tu pregunta.

+2

& es una entidad de caracteres HTML y no una entidad de caracteres URI. Al ponerlo en un URI, todavía tiene el carácter ampersand y caracteres extraños adicionales. –

+0

* Cara de palma * Derecha, publicada antes de pensar eso. Vota abajo según corresponda. – MarkPowell

+0

Simplemente elimine su respuesta en lugar de solicitar votos a la baja :) – truppo

6

Un URL es generalmente en forma

scheme://host/some/path/to/file?query1=value&query2=value 

lo tanto, no es aconsejable utilizarla en una dirección URL a menos que desee utilizar para los parámetros. De lo contrario, deberías escapar por ciento usando% 26, p. Ej.

http://www.example.com/hello%26world 

Esto se traduce en el camino de ser presentado como hola & mundo. Hay otros caracteres que se deben escapar cuando se usan fuera de contexto en una URL. Consulte here para obtener una lista.

+0

No es necesario codificarlo cuando se usa en la ruta URL. – Gumbo

+0

Ok, no sabía eso. Acabo de leer la parte sobre codificación en el RFC que vinculó en su respuesta. Pero si entendí esto correctamente, parece que http://example.com/Alice&Bob y http://example.com/Alice%26Bob no se consideran equivalentes y pueden ser interpretados de manera diferente por una aplicación (que no es el caso con HTTP como usted señaló). – Alfonso

Cuestiones relacionadas