6

Mam prostą usługę Restlet hostowaną w AppEngine. To wykonuje podstawowe operacje CRUD z ciągami i działa dobrze z różnymi rodzajami znaków UTF-8, kiedy testuję to z curl (dla wszystkich czasowników).Strumienie UTF-8, które są wymieszane przez Restlet na GAE

ta zużywana jest przez prosty restlet klienta gospodarzem w serwletu na innej aplikacji AppEngine:

// 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()); 

powyższe jest dość dużo wszystko mam w serwletu. Bardzo proste.

Aplet jest wywoływany poprzez jquery ajax json i że wrócę jest dobrze uformowane i wszystko, ale problemem jest to, że kodowanie UTF-8 ciągi wracają jajecznica, na przykład: Université de Montréal staje Universit?? de Montr??al.

Próbowałem dodanie tej linii w serwletu (przed wszystkim innym):

resp.setCharacterEncoding("UTF-8"); 

Ale tylko diference jest to, że zamiast się ?? uzyskać Universitᅢᄅ de Montrᅢᄅal (ja nawet nie wiem jakiego rodzaju tych znaków są, jak sądzę, azjatyckimi).

Mam 100% pewności, że usługa uzupełniania jest w porządku, ponieważ inne niż debugowanie linii po linii, jestem w stanie przetestować ją z linii cmd z curl i zwraca dobrze uformowane ciągi.

Patrząc na nagłówek http odpowiedzi z firefox (podczas wywoływania serwletu za pośrednictwem javascript), widzę, że kodowanie jest rzeczywiście zgodne z oczekiwaniami UTF-8. Po wielu godzinach czytania każdego możliwego pokrewnego artykułu natknąłem się na this restlet discussion i zauważyłem, że rzeczywiście mam Transfer-Encoding: chunked na nagłówku http odpowiedzi. Próbowałem proponowanych rozwiązań (override ClientResource.toRepresentation, nie zrobił nic dobrego więc próbowałem restlet 2.1 jako susggested z ClientResource.setRe​questEntityBuffering​(true), nie ma szczęścia tam też), ale Nie jestem przekonany, mój problem jest związany zTransfer-Encoding: chunkedwcale.

W tym momencie nie mam pomysłów, a ja bym naprawdę naprawdę docenić wszelkie sugestie! O_o

UPDATE:

Próbowałem robić ręcznie wejść z klasycznym URLConnection a łańcuch wraca w porządku:

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()); 

Tyle bycia wszystkim spokojny i wyobraźnia ... ale nadal nie mam pojęcia, dlaczego oryginalna wersja nie działa! :/

+1

Kodowane kodowanie transferu nie powinno mieć związku z problemami z zestawem znaków ... Jeśli wpisujesz surowy ciąg w pytaniu do 'resp.getWriter()', całkowicie pomijając wypełnienie, czy jest on poprawnie przesyłany? – bdonlan

+0

Masz na myśli, wykonując "ręczny" GET do mojej usługi z serwletu? – JohnIdol

+0

Zobacz aktualizację, działa poprawnie, jeśli pomijam uzupełnienie. Domyślam się, że to błąd lub smt na temat remontu. O_o – JohnIdol

Odpowiedz

1

Próbowałem robić ręcznie wejść z klasycznym URLConnection a łańcuch wraca w porządku:

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()); 

Tyle bycia wszystkim spokojny i wyobraźnia ... ale nadal nie mam pojęcia dlaczego oryginalna wersja nie działa! :/

0

Czy twoja odpowiedź zawiera odpowiedni nagłówek "Content-Type"? Powinno to być coś w rodzaju "Content-Type: application/json; charset=UTF-8" (zwróć uwagę na zestaw znaków).

Spróbuj uruchomić serwer programistyczny i pobrać zasoby z wiersza poleceń, używając cURL i sprawdzając nagłówki, np. curl -i http://localhost:8080/myentity/id. Teoretycznie przeglądarki powinny przyjmować kodowanie UTF-8 dla JSON, ale nie ufałbym temu.

Powiązane problemy