¿Cuál es la codificación correcta de las cadenas de solicitud de obtención HTTP?

Question

¿El estándar HTTP o algo define qué codificación se debe usar en caracteres especiales antes de que se codifiquen en url con% XXs? Si no define, ¿hay alguna manera de definir qué codificación se usa? Parece que la mayoría de los navegadores envían los datos en utf-8.

Answer 1

¿El estándar HTTP o algo define qué codificación se debe utilizar en caracteres especiales antes de que se codifiquen en url con% XXs?

El estándar HTTP, no. Pero otro estándar, IRI, puede entrar en juego.

Los URI son secuencias de bytes explícitamente (una vez codificadas%). Los caracteres Unicode a los que se asignan los bytes no están especificados por el estándar URI o el estándar HTTP para http: -scheme URIs.

Específicamente para los parámetros de consulta: los navegadores web usarán la codificación de la página de origen para hacer un envío de formulario GET URL, de modo que si tiene una página en ISO-8859-1 y pone 'é' en un cuadro de búsqueda, obtendrá '? search =% E9', pero si hace lo mismo en una página codificada como UTF-8, obtendrá '? search =% C3% E9'. Si no sirve su página de formulario con un juego de caracteres en particular, el navegador lo adivinará, lo cual no quiere, ya que hará que sea imposible adivinar en qué formato entrará el envío.

Para las otras partes de una URL, un navegador no las generará, pero si la proporciona con caracteres no ASCII en los enlaces, generalmente las codificará como UTF-8. Esto no es confiable, ya que depende de la configuración del navegador y la configuración regional, por lo que es mejor no usar esto en este momento.

La norma que permite correctamente los caracteres que no son ASCII en los enlaces es IRI. IRI convierte a URI mediante UTF-8 -% - que codifica la mayor parte de la URL, pero el nombre de host se convierte utilizando Punycode. Por compatibilidad, es mejor no confiar en que los navegadores comprendan los IRI en los enlaces. En cambio, UTF-8-then -% - codifica su ruta y los caracteres de parámetros usted mismo. Todavía aparecerán como los caracteres correctos en la barra de direcciones en los navegadores modernos; Desafortunadamente, IE no mostrará el formulario IRI de caracteres decodificados en todos los casos, dependiendo de la configuración del idioma.

El Wiki IRI para el personaje griega gamma es:

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

codifica en un URI, que es:

http://en.wikipedia.org/wiki/%CE%93 

Answer 2

Que yo sepa, no hay forma de definirlo, aunque siempre he supuesto que es ASCII, ya que eso es lo que es el DNS (actualmente, aunque el DNS localizado viene, con todos los problemas eso implica).

Nota: UTF8 es "compatible con ASCII" a menos que intente utilizar caracteres extendidos. Esto probablemente tenga una pequeña parte en el razonamiento detrás de por qué algunos navegadores pueden enviar sus datos GET codificados en UTF8.

EDIT: De tu comentario, parece que no sabes cómo funciona el% de codificación, así que aquí va.

Dada la cadena de consulta de cadena siguiente, "?foo=Hello World!", el "¡Hola mundo!" parte necesita codificación URL. La forma en que esto funciona es que cualquier carácter 'especial' obtiene su valor ASCII tomado y convertido a hexadecimal con el prefijo '%'. Entonces la cadena anterior se convertiría a "?foo=Hello%20World%21".

Answer 3

por RFC 2616,

CHAR   = <any US-ASCII character (octets 0 - 127)> 

y

token   = 1*<any CHAR except CTLs or separators> 

separators  = "(" | ")" | "<" | ">" | "@" 
        | "," | ";" | ":" | "\" | <"> 
        | "/" | "[" | "]" | "?" | "=" 
        | "{" | "}" | SP | HT 

y URIs son token s con varios separadores específicos. Entonces, en teoría, nada más que US-ASCII debería estar allí. (En la práctica, dado que la extensión ISO-8859-1 de US-ASCII se utiliza en muchos otros lugares en las especificaciones HTTP, no es inusual encontrar implementaciones HTTP que admitan ISO-8859-1 en lugar de US-ASCII, pero estrictamente hablando que no es HTTP compatible con los estándares).