¿Qué codificación de caracteres debo utilizar para un encabezado HTTP?
Estoy usando un carácter especial HTML "divertido" (✰) (consulte http://html5boilerplate.com/ para obtener más información) para un Serverencabezado HTTP y me pregunto si está "permitido" según la especificación.
Al usar la pestaña Red en las herramientas de desarrollo en Chrome en Windows Xp Pro SP 3, veo ✰ bien.
En IE8, la ✰ no se representa correctamente.
El validador HTML de w3.org no lo representa correctamente (
â°en su lugar muestra " ").
Ahora bien, no me gustan mucho las codificaciones de caracteres... y, francamente, no me importan demasiado; Simplemente uso ciegamente UTF-8 porque me dicen que lo haga. :-)
¿La disparidad es causada por errores en los diferentes analizadores/navegadores/motores/(como-se-llamen)?
¿Existe una especificación para esto o tal vez una lista de caracteres permitidos para un "valor" de encabezado HTTP?
En resumen: sólo se garantiza que ASCII funcionará. Se permiten algunos bytes que no son ASCII por compatibilidad con versiones anteriores, pero no se supone que se puedan mostrar.
HTTPbis se dio por vencido y especificó que en los encabezados no hay ninguna codificación útil además de ASCII:
Históricamente, HTTP ha permitido contenido de campo con texto en el juego de caracteres ISO-8859-1 [ISO-8859-1], admitiendo otros juegos de caracteres solo mediante el uso de codificación [RFC2047]. En la práctica, la mayoría de los valores de los campos de encabezado HTTP utilizan sólo un subconjunto del juego de caracteres US-ASCII [USASCII]. Los campos de encabezado recién definidos DEBEN limitar sus valores de campo a octetos US-ASCII. Un destinatario DEBE tratar otros octetos en el contenido del campo (texto obs) como datos opacos.
Anteriormente, RFC 2616 de 1999 definía esto:
Las palabras de *TEXT PUEDEN contener caracteres de conjuntos de caracteres distintos de ISO-8859-1 [22] solo cuando están codificados de acuerdo con las reglas de RFC 2047 [14].
y RFC 2047 es la codificación MIME , por lo que sería:
=?UTF-8?Q?=E2=9C=B0?=
pero no creo que muchos (si es que hay alguno) clientes lo admitan.
Lea primero los comentarios, es probable que esta respuesta extraiga conclusiones erróneas de las fuentes correctas y necesite editarse.
Puede utilizar cualquier carácter ASCII imprimible y ningún carácter especial como ✰ (que no es ASCII )
Consejo : puedes codificar cualquier cosa en JSON.
Editar : puede que no sea obvio al principio, la codificación de caracteres definida en el encabezado solo se aplica al cuerpo de la respuesta, no al encabezado en sí. (Ya que causaría un problema del huevo y la gallina).
Me gustaría resumir todas las definiciones relevantes según la especificación vinculada por Penchant.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
Entonces, buscamos el valor del campo .
LWS = [CRLF] 1*( SP | HT )
CRLF = CR LF
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
LWS significa Espacio en blanco lineal. Básicamente, LWS es Espacio o Tabulador, pero puede dividir el valor de su campo en varias líneas comenzando una nueva línea antes de un Espacio o Tabulador.
Simplifiquémoslo a esto:
field-value = <any field-content or Space or Tab>
Ahora buscamos contenido de campo .
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
OCTET = <any 8-bit sequence of data>
TEXT = <any OCTET except CTLs,
but including LWS>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
TEXTO es el más general e incluye todo el resto -así que olvídate del resto-. Aquí está el juego de caracteres US-ASCII (= ASCII)
Como puede ver, se permiten todos los caracteres ASCII imprimibles.
