2011-03-24 9 views
17

Soy un novato de los asuntos relacionados con HTTP. Mi pregunta es en el desarrollo de iOS, me gustaría enviar una cadena usando encabezado HTTP, por lo que estoy usando:Cómo enviar una cadena Unicode que no esté en inglés usando el encabezado HTTP?

servidor
[httpRequest setValue:@"nonEnglishString" forHTTPHeaderField:@"customHeader"]; 

La recepción es Python (Google App Engine), ahorrando el valor de cadena en el PP modelo como StringProperty usando:

dataEntityInstance.nonEnglishString = unicode(self.request.headers.get('customHeader') 

sin embargo, el problema es cuando intento enviar cadena no Inglés como Corea, se guarda en el encabezado HTTP como esto:

Customheader = "\Uc8fc\Uba39\Uc774 \Uc6b4\Ub2e4"; 

y cuando es recibida por Google App Engine y se guarda en almacén de datos, que ha cambiado para ser como:

??? ?? 

como si no puede encontrar los caracteres apropiados para el valor Unicode.

¿No es POSIBLE o PERMITIDO enviar una cadena que no esté en inglés utilizando el encabezado HTTP?

Si mi iOS usa solo setHTTPBody, puede transferir cadenas que no sean en inglés y guardarlas en DataStore de App Engine correctamente.

[httpRequest setHTTPBody:[httpBody dataUsingEncoding:NSUTF8StringEncoding]]; 

Pero simplemente no puedo encontrar el camino correcto para lograr la misma meta usando encabezados HTTP, como lo que muchas API como tareas de Foursquare y ahorro de las cadenas en las formas apropiadas en Python basadas almacén de datos de Google App Engine

Respuesta

23

¿No es POSIBLE o PERMITIDO enviar una cadena que no esté en inglés con el encabezado HTTP?

No es posible, de acuerdo con las normas HTTP, colocar caracteres que no sean ISO-8859-1 directamente en un encabezado HTTP. Eso le da caracteres ASCII ("Inglés"?) Más diacríticos comunes de Europa Occidental.

Sin embargo, en la práctica ni siquiera puede usar los caracteres extendidos ISO-8859-1, porque los servidores y navegadores no aceptan qué hacer con los caracteres que no son ASCII en los encabezados. Safari toma RFC2616 en su palabra y trata bytes altos como caracteres ISO-8859-1; Mozilla toma los bytes bajos de la unidad de código UTF-16, que es similar pero más raro; Decodificación de Opera y Chrome desde UTF-8; IE usa la página de códigos del sistema local.

Así que, en realidad, todo lo que puede poner en un encabezado HTTP es simple ASCII sin códigos de control. Si quieres algo más, tendrás que idear un esquema de codificación (por ejemplo, UTF-8 + base64). El estándar RFC2616 sugiere palabras codificadas RFC2047 como una forma estándar de codificación, pero esto no tiene sentido, dadas las definiciones de cuándo están permitidas en el RFC2047 en sí, y nada lo admite.

+0

¿Qué quiere decir con * (...) esto no tiene sentido, dadas las definiciones de cuándo están permitidas en RFC2047 (...) *? –

+0

RFC 2047 sección 5 establece que las palabras codificadas pueden ir donde RFC 822 'texto', 'comentario' y 'frase' van, pero RFC 2616 no es un estándar de la familia RFC 822 y no tiene tokens que coincidan. (Hay un token de TEXTO pero no se define de la misma manera). Establece explícitamente que no deben ir en una 'cadena citada'; hay un token de "cadena citada" muy similar definido en RFC 2616 y ese es el único lugar donde más se quiere poner en práctica caracteres que no sean ASCII (debido a Content-Disposition y encabezados con parámetros similares). – bobince

+0

De todos modos, desde una perspectiva de estándares esto ya está aclarado: RFC 5987 proporciona una forma estándar de codificar no ASCII en encabezados parametrizados, y RFC 7230 recomienda que los encabezados no heredados sean ASCII. – bobince

4

Es posible usar juegos de caracteres que no sean ISO 8859-1 en encabezados HTTP, pero deben estar codificados como se describe en RFC 2047.

+0

Si significa que el cliente, mi aplicación iOS, debe hacer la codificación de NSString en RFC 2047, antes de establecerse como un valor de encabezado HTTP, ¿me gustaría proporcionarme dónde puedo encontrar iOS o fuente Objective-C para manejar esto? ¿tarea? Parece demasiado difícil encontrar la solución – petershine

+1

Esta prescripción en RFC2616 es, desafortunadamente, falsa. Las palabras codificadas RFC2047 explícitamente no pueden ir en ninguno de los lugares en los que desee utilizarlas en el encabezado HTTP, ya que no están basadas en átomos de la familia RFC-822.La referencia a 2047 se ha eliminado del trabajo de HTTPbis en estándares futuros. Por supuesto, puede usar palabras codificadas como una forma específica de codificación específica de la aplicación, si así lo desea (pero UTF-8 base64 podría ser más sencillo). – bobince

Cuestiones relacionadas