2010-03-10 58 views
12

Un simple archivo HTML:Cómo forzar navegador para establecer conjunto de caracteres en el encabezado HTTP de tipo de contenido

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 

<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
</head> 
<body> 
<form method="POST" action="test.jsp" accept-charset="utf-8" method="post" enctype="application/x-www-form-urlencoded" > 
    <input type="text" name="P"/> 
    <input type="submit" value="subMit"/> 
</form> 
</body> 
</html> 

El archivo HTML es servida por el servidor utilizando cabecera Content-Type:text/html; charset=utf-8. Todo dice: "querido navegador cuando publiques este formulario, publícalo utf-8 codificado". El navegador realmente hace esto. Cada valor ingresado en el campo de entrada será codificado en UTF-8. PERO ¡el navegador no le dirá esto al servidor! El encabezado HTTP de la solicitud posterior contendrá un campo Content-Type:application/x-www-form-urlencoded pero el juego de caracteres se omitirá (probado con FF3.6 e IE8).

El problema es que el servidor de aplicaciones que uso (Tomcat6) espera el juego de caracteres en el encabezado Content-Type (como se indica en RFC2388). De esta manera: Content-Type:application/x-www-form-urlencoded;charset=utf-8. Si se omite el juego de caracteres asumirá ISO-8859-1, que no es el juego de caracteres utilizado para la codificación. El resultado es datos rotos.

¿Alguien tiene una pista de cómo obligar a los navegadores actuales a agregar el juego de caracteres al encabezado Content-Type?

+0

Me encuentro exactamente en el mismo problema, y ​​le he pedido a FF en los grupos de google una forma de resolver este problema http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/f3fd16b217a956c6 # –

Respuesta

11

¿Alguien tiene una idea de cómo forzar a los navegadores actuales a agregar el juego de caracteres al encabezado Content-Type?

No, no hay ningún navegador ha suministrado alguna vez un parámetro charset con el tipo application/x-www-form-urlencoded medios de comunicación. Además, la especificación HTML que define ese tipo no propone un parámetro charset, por lo que el servidor no puede esperar obtener uno.

(HTML 4 no espera una charset de las subpartes de una presentación multipart/form-data, pero incluso en ese caso, no hay ningún navegador cumple realmente.)

accept-charset = "UTF-8"

accept-charset está roto en IE, y no debe utilizarse. No hará la diferencia de ninguna manera para los formularios en las páginas servidas como UTF-8, pero en otros casos puede terminar con resultados inconsistentes.

No, con los formularios solo tiene que mostrar la página en la que se encuentran como UTF-8, y los resultados deberían aparecer como UTF-8 (sin marcas de identificación para informarle (excepto potencialmente para el _charset_ hack, pero Tomcat no admite eso).

Por lo tanto, debe indicarle al contenedor del servlet qué codificación usar para los parámetros si no desea que vuelva a su valor predeterminado (que generalmente es incorrecto). En este caso, puede llamar al ServletRequest.setCharacterEncoding(), pero esto tiende a ser frágil y no funciona en absoluto para los parámetros tomados de la cadena de consulta. Por desgracia, no hay una solución de nivel de servlet estandarizada para esto. Tomcat generalmente tiene que muck about with the server.xml en lugar de poder arreglarlo la aplicación.

+1

Buena respuesta, espere de la parte de Tomcat. El 'ServletRequest # setCharacterEncoding()' en realidad establece el conjunto de caracteres que se utilizará para analizar el ** cuerpo ** de la solicitud (en otras palabras: parámetros POST) y 'URIEncoding' en' server.xml' en realidad establece el conjunto de caracteres que se utilizará para analizar solicitud ** URI ** (en otras palabras: parámetros GET).Como está usando POST en su ejemplo, basta con usar 'ServletRequest # setCharacterEncoding()'. Más detalles en este artículo: http://balusc.blogspot.com/2009/05/unicode-how-to-get-characters-right.html – BalusC

+0

Es suficiente, puede ser frágil. Si se lee cualquier parámetro de solicitud, hará que el cuerpo de la solicitud sea leído y decodificado, después de lo cual cualquier llamada a 'setCharacterEncoding' será ineficaz. Es fácil para un componente astuto de middleware complicar las cosas saltando y leyendo un parámetro ... – bobince

+0

te refieres a "http spec" no "html spec", ¿verdad? En realidad, la especificación http dice "Los datos en juegos de caracteres que no sean 'ISO-8859-1' o sus subconjuntos DEBEN etiquetarse con un valor de juego de caracteres apropiado". en la sección "3.7 Tipos de medios": http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 –

Cuestiones relacionadas