¿Pueden los URI HTTP tener caracteres que no sean ASCII?

Intenté encontrar esto en el RFC pertinente, IETF RFC 3986, pero no pude encontrarlo.¿Pueden los URI HTTP tener caracteres que no sean ASCII?

¿Los URI para HTTP permiten Unicode, o no ASCII de ningún tipo?

Puede citar la sección y el RFC que respalda su respuesta.

NB: Para aquellos que puedan pensar que esto no está relacionado con la programación, lo es. Está relacionado con un filtro ISAPI que estoy construyendo.

Adición

He leído la sección 2.5 del RFC 3986. Sin embargo, RFC 2616, que creo que es el protocolo HTTP actual, es anterior a 3986, y por esa razón por la que habría que suponer no puede cumplir con 3986. Además, incluso si se actualiza el HTTP RFC, seguirá existiendo el problema de la racionalización; en otras palabras, hace que un URI HTTP sea compatible con TODAS las estipulaciones de RFC3986, incluido lo que sea apropiado para incluir no Caracteres de US-ASCII?

Fuente

2010-03-24 Cheeso

No, no están permitidos. Simplemente verifique el ABNF en RFC 3986.

Fuente

2010-03-24 05:49:31

y de su comentario en la otra respuesta: * Los URI no contienen caracteres que no sean ASCII. Por definición. Nunca. IRI (RFC 3987) sí. Puede asignar IRI a URI. HTTP solo usa URI en el cable. * – Cheeso

Aquí hay un ejemplo: ☃.net.

En cuanto a la sección correspondiente de RFC 3986, creo que está buscando 2.5.

EDIT:

desbordamiento de pila Al parecer no detecta esto como una dirección URL apropiada. Tendrá que copiar & pegar en su navegador.

Fuente

2010-03-24 00:17:16 mlsteeves

No tengo clara su respuesta. ¿Los URI HTTP con caracteres no US-ASCII son compatibles o no? Proporcionar un ejemplo no es "apoyo". Además, tengo claro RFC3986. Quiero decir que leí la sección 2.5. Pero RFC 2616, que creo que es el protocolo HTTP actual, es anterior a 3986, y por esa razón supongo que no puede cumplir con 3986.Además, incluso si/cuando se actualiza el HTTP RFC, seguirá existiendo el problema de la racionalización; en otras palabras, ¿un URI HTTP admite * TODOS * las estipulaciones de RFC3986, incluido lo que sea apropiado para incluir caracteres que no sean US-ASCII? – Cheeso

Así que, para mí, su respuesta aquí proporciona información, pero no una respuesta * real. * Además, como nota al margen, no pude lograr que esa URL funcione, en ningún navegador, sin importar lo que hice. – Cheeso

El HTTP RFC * está * siendo actualizado, y hará referencia al RFC 3986, vea la página de inicio del IETF HTTPbis WG. –

Solía ser que los caracteres no ingleses no estaban permitidos en DNS y URL/URI. Hubo un truco para permitirlos mediante el uso de% de codificación en URI. Sin embargo, muchos países como Rusia y China están empezando a implementar DNS utilizando caracteres no latinos. Aquí es una referencia a uno de estos standards

Fuente

2010-03-24 00:20:42 Vlad

"no inglés" → "no ASCII". Hay muchos caracteres en inglés que tampoco son válidos en nombres de dominio. – bignose

Así que mi punto de partida es que ... los estándares son # 1, aún en evolución, y # 2, todavía están siendo adoptados. En otras palabras, el soporte para caracteres no-US-ASCII en URIs HTTP aún no es sólido. ¿Sería eso correcto? – Cheeso

no, eso no es exacto. Los URI no contienen caracteres que no sean ASCII. Por definición. Nunca. IRI (RFC 3987) do. Puede asignar IRI a URI. HTTP solo usa URI en el cable. –

http://en.wikipedia.org/wiki/Internationalized_domain_name

Fuente

2010-03-24 00:20:45 dan04

muy útil. . .. – Cheeso

-1

Muchos navegadores no son el apoyo URI con caracteres Unicode (yo los he implementado en un sitio web que he llamado a construir - blogvani.com) y Google debidamente escanea y los mantiene intactos. No creo que funcione en dominios de nivel superior, al menos no con el registrador y no directamente.

Para dominios de nivel superior si tiene un dominio registrado en Unicode (por ejemplo, las personas pueden registrar dominios en hindi), se convertirá en un código correspondiente en ASCII (algo que puede ir como jdhfks3243-32434.com) ...

Es bastante divertido ver cómo se enruta esto y darse cuenta de que en realidad no vas a un dominio Unicode aunque parezca así.

Fuente

2010-03-24 00:34:17

RFC 3986 está siendo reemplazado por RFC 3987, que es totalmente compatible con Unicode, y proporciona reglas de mapeo a/desde URI de estilo RFC 3986.

Fuente

2010-03-24 09:59:59

RFC 3987 (IRI) no es un reemplazo de RFC 3986 (URI). Mejor pensar en eso como algo superpuesto. –

Sin capas en la parte superior, pero definido al costado de la misma. Los IRI reflejan la estructura de los URI, pero no se basan en ellos. IRI es un esquema independiente, con la Sección 3 definiendo ahora moverse entre los dos esquemas cuando sea necesario. Dije que era un reemplazo porque muchos sistemas que anteriormente dependían de los URI antes se han actualizado para confiar en los IRI. –

¿Pueden los URI HTTP tener caracteres que no sean ASCII?

Respuesta

Cuestiones relacionadas