6

Tengo un servicio Restlet simple alojado en App Engine. Esto realiza operaciones CRUD básicas con cadenas y funciona bien con todo tipo de caracteres UTF-8 cuando lo pruebo con curl (para todos los verbos).Cadenas UTF-8 codificadas por Restlet en GAE

Esto es consumida por un cliente Restlet sencilla alojada en un servlet en otra aplicación de App Engine:

// set response type 
resp.setContentType("application/json"); 
// Create the client resource 
ClientResource resource = new ClientResource(Messages.SERVICE_URL + "myentity/id"); 
// Customize the referrer property 
resource.setReferrerRef("myapp"); 
// Write the response 
resource.get().write(resp.getWriter()); 

Lo anterior es más o menos todo lo que tengo en el servlet. Muy simple.

El servlet se invoca a través de jQuery Ajax y el JSON que regrese está bien formado y todo, pero el problema es que las cadenas de codificación UTF-8 están regresando revueltos, por ejemplo: Université de Montréal se convierte en Universit?? de Montr??al.

He intentado añadir esta línea en el servlet (antes de todo lo demás):

resp.setCharacterEncoding("UTF-8"); 

Pero la única diference es que en vez de conseguir ?? consigo Universitᅢᄅ de Montrᅢᄅal (ni siquiera sé qué tipo de personajes a los son, asiático, supongo).

Estoy 100% seguro de que el servicio restlet está bien, porque aparte de depurarlo línea por línea, puedo probarlo desde la línea cmd con curl y está devolviendo cadenas bien formadas.

Al mirar el encabezado http de la respuesta de firefox (cuando llamo al servlet mediante javascript) puedo ver que la codificación es de hecho UTF-8, como se esperaba. Después de horas luchando por leer todos los artículos relacionados posibles me encontré con this restlet discussion y noté que de hecho tengo Transfer-Encoding: chunked en el encabezado http de la respuesta. Probé las soluciones propuestas (ClientResource.toRepresentation anulación, no hace ningún bien así que traté Restlet 2.1 como susggested con ClientResource.setRe​questEntityBuffering​(true), sin suerte allí tampoco) pero No estoy convencido de que mi problema está relacionado conTransfer-Encoding: chunkeden absoluto.

En este punto estoy sin ideas, y me gustaría realmente agradecer cualquier sugerencia! O_o

ACTUALIZACIÓN:

He intentado hacer un GET manual con una URLConnection clásica y la cadena va a volver bien:

URL url = new URL(Messages.SERVICE_URL + "myentity/id"); 
URLConnection conn = url.openConnection(); 
InputStream is = conn.getInputStream(); 

StringWriter writer = new StringWriter(); 
IOUtils.copy(is, writer, "UTF-8"); 

resp.getWriter().print(writer.toString()); 

tanto por ser todo tranquilo y elegante ... pero ¡Todavía no tengo idea de por qué la versión original no funciona! :/

+1

La codificación de transferencia fragmentada no debe estar relacionada con los problemas del juego de caracteres ... Si escribe la cadena sin editar en cuestión en 'resp.getWriter()', al pasar por alto a restlet por completo, ¿se transfiere correctamente? – bdonlan

+0

¿Quiere decir haciendo un GET 'manual' a mi servicio desde el servlet? – JohnIdol

+0

Ver la actualización, funciona bien si omito el restlet. Supongo que es un error o smt O_o – JohnIdol

Respuesta

1

He intentado hacer un GET manual con una URLConnection clásica y la cadena va a volver bien:

URL url = new URL(Messages.SERVICE_URL + "myentity/id"); 
URLConnection conn = url.openConnection(); 
InputStream is = conn.getInputStream(); 

StringWriter writer = new StringWriter(); 
IOUtils.copy(is, writer, "UTF-8"); 

resp.getWriter().print(writer.toString()); 

tanto por ser todo tranquilo y elegante ... pero todavía no tengo ni idea de por qué la versión original no funciona! :/

0

¿Su respuesta contiene el encabezado "Content-Type" apropiado? Debería ser algo así como "Content-Type: application/json; charset=UTF-8" (tenga en cuenta el juego de caracteres).

Intenta iniciar tu servidor de desarrollo y recuperar tu recurso desde la línea de comando usando cURL e inspeccionando los encabezados, p. curl -i http://localhost:8080/myentity/id. En teoría, los navegadores deberían asumir UTF-8 para JSON, pero no confiaría en eso.

Cuestiones relacionadas