¿Qué encoding de caracteres debería usar para un encabezado HTTP?

Estoy usando un carácter especial HTML “divertido” (http://) (vea http://html5boilerplate.com/ para más información) para un encabezado HTTP del Server y me pregunto si está “permitido” por especificación.

  • Usando la pestaña Red en las herramientas de desarrollo en Chrome en Windows Xp Pro SP 3, veo que ✰ está bien.

  • En IE8, el ✰ no se representa correctamente.

  • El validador HTML de w3.org no lo procesa correctamente (muestra ” â° ” en su lugar).

Ahora, no estoy muy interesado en las codificaciones de los personajes … y, francamente, no me preocupan demasiado por ellos; Simplemente uso a ciegas UTF-8 porque me lo pidieron. 🙂


¿La disparidad causada por los errores en los diferentes analizadores / navegadores / motores / (sea lo que sea que se llame)?

¿Hay alguna especificación para esta o quizás una lista de caracteres permitidos para un “valor” de encabezado HTTP?

En resumen: solo ASCII está garantizado para funcionar. Algunos bytes que no son ASCII tienen compatibilidad retroactiva, pero se supone que no se pueden visualizar.

HTTPbis se dio por vencido y especificó que en los encabezados no hay encoding útil además de ASCII:

Históricamente, HTTP ha permitido contenido de campo con texto en el conjunto de caracteres ISO-8859-1 [ISO-8859-1], y admite otros conjuntos de caracteres solo mediante el uso de la encoding [RFC2047]. En la práctica, la mayoría de los valores de campo del encabezado HTTP usan solo un subconjunto del juego de caracteres US-ASCII [USASCII]. Los campos de encabezado definidos recientemente DEBERÍAN limitar sus valores de campo a octetos US-ASCII. Un destinatario DEBERÍA tratar otros octetos en el contenido de campo (obs-texto) como datos opacos.


Previamente, RFC 2616 de 1999 definió esto:

Las palabras de * TEXT PUEDEN contener caracteres de juegos de caracteres que no sean ISO- 8859-1 [22] solo cuando están codificados según las reglas de RFC 2047 [14].

y RFC 2047 es la encoding MIME , por lo que sería:

 =?UTF-8?Q?=E2=9C=B0?= 

pero no creo que muchos clientes (si alguno) lo soporten.

Por favor, lea los comentarios primero, esta respuesta probablemente extrae conclusiones erróneas de las fonts correctas, necesita editarlas.


Puede utilizar cualquier carácter ASCII imprimible y sin caracteres especiales como ✰ (que no es ASCII )

Sugerencia : puede codificar cualquier cosa en JSON.

Editar : puede que no sea obvio al principio, la encoding de caracteres definida en el encabezado solo se aplica al cuerpo de la respuesta, no para el encabezado en sí. (Ya que causaría un problema de pollo y huevo).


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, estamos buscando el valor del campo .

 LWS = [CRLF] 1*( SP | HT ) CRLF = CR LF CR =  LF =  SP =  HT =  

LWS significa Linear White Space. Esencialmente, LWS es Espacio o Pestaña, pero puede dividir su valor de campo en varias líneas comenzando una nueva línea antes de un Espacio o una Pestaña.

Simplifiquemos esto:

 field-value =  

Ahora buscamos contenido de campo .

 field-content =  OCTET =  TEXT =  CTL =  token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT 

TEXTO es el más general e incluye todo el rest, así que olvídate del rest. Aquí está el juego de caracteres US-ASCII (= ASCII)

Como puede ver, todos los caracteres CAD ASCII imprimibles están permitidos.