0

So I think the image below shows my problem pretty well:

enter image description here

I would be expecting the original string to be printed as-is, since when I send it in a response (using JAX-RS) it actually shows the \u2018, not the left quote it should. However, applying the method EncodingUtils.clean(...) (which is just a wrapper of Apache Commons Lang StringEscapeUtils.unescapeJava(...)) to the string sent to the response doesn't change the response (it still shows \u2018). Since as of the test they have changed, what am I missing here and what do I need to do to get the intended replacements?

EDIT1: the client is an Android app and the troublesome string is one of the attributes of the aforementioned JSON response. If I don't touch it, the phone shows this weird character '€TM'. If I decode it using Windows-1252 it prints the char right, but it screws the other parts of the String.

EDIT2: I have @Produces(text/json). These are the headers reported (note that I'm using OkHttp for request handling): 

Date: Tue, 23 Dec 2014 21:05:49 GMT
Connection: close
Server: Jetty(7.5.3.v20111011)
Via: 1.1 vegur
OkHttp-Selected-Protocol: http/1.1
OkHttp-Sent-Millis: 1419368765324
OkHttp-Received-Millis: 1419368765736

Furthermore, printing to console from Android the received string actually prints it right. I have no clue on what's going on.

Jorge Antonio Díaz-Benito
  • 1,036
  • 12
  • 32
  • What MediaType does your JAX-RS method produce? – VGR Dec 23 '14 at 20:32
  • 1
    Does your web service return JSON? – RealSkeptic Dec 23 '14 at 20:35
  • @RealSkeptic yes, it does. VGR I didn't really set any to be honest. – Jorge Antonio Díaz-Benito Dec 23 '14 at 20:37
  • 1
    Then [this answer](http://stackoverflow.com/a/7665560/4125191) may be of interest to you. – RealSkeptic Dec 23 '14 at 20:40
  • Then it looks like the bad part is the Android part, not the web service. Nevertheless, you may want to show what you put in the `@Produces` tag. Better yet, try to access your web service using a utility that shows both headers and content and response, to see what character set is set in the headers. It could be that the app is trying to decode based on that character set. – RealSkeptic Dec 23 '14 at 20:50
  • 1
    Please add the information to your question by using the `edit` button, and delete it from the comments. The comments are not a good place for code or output, and SO prefers we keep them short. – RealSkeptic Dec 23 '14 at 22:05

2 Answers2

1

I do not see any strange behaviour.

Java already unescapes escape codes occuring in string literals, so your testObj contains Unicode characters 0x2018 and 0x2019, not the literal strings "\u2018" and "\u2019". Thus, StringEscapeUtils.unescapeJava(...) returns the same string. That means that testObj.contentEqual(postTreatmentTestObj) is true, and therefore the assertFalse(...) test fails.

Hoopje
  • 12,677
  • 8
  • 34
  • 50
  • And then why when I print the string to a response of a GET method I see the "\2018"? – Jorge Antonio Díaz-Benito Dec 23 '14 at 20:30
  • If the client sees the 6-byte literal sequence "\u2018" in response bodies then it is because something in the service is performing the equivalent of `StringEscapeUtils.escapeJava()` on it on the way out. This could be a function of the content type, as @RealSkeptic seems to be suggesting. – John Bollinger Dec 23 '14 at 20:40
  • But that would mean that if I take the escapeJava method then it should show the proper response, but it is still the same. – Jorge Antonio Díaz-Benito Dec 23 '14 at 20:42
0

So, after hours of stretching my head stupidly I have that what's happening is basically this (see comment on April 15, 2013, for a working solution as of December 23, 2014): https://code.google.com/p/android/issues/detail?id=3552

Sometimes Google, sometimes...

Jorge Antonio Díaz-Benito
  • 1,036
  • 12
  • 32