0

所以我认为下图很好地说明了我的问题:

在此处输入图像描述

我希望原始字符串按原样打印,因为当我在响应中发送它(使用 JAX-RS)时,它实际上显示了 \u2018,而不是它应该显示的左引号。但是,将 EncodingUtils.clean(...) 方法(它只是 Apache Commons Lang StringEscapeUtils.unescapeJava(...) 的包装)应用于发送到响应的字符串不会改变响应(它仍然显示 \ u2018)。由于从测试开始它们已经改变,我在这里缺少什么,我需要做什么才能获得预期的替代品?

EDIT1:客户端是一个Android应用程序,麻烦的字符串是上述JSON响应的属性之一。如果我不碰它,手机就会显示这个奇怪的字符“€TM”。如果我使用 Windows-1252 对其进行解码,它会正确打印字符,但会拧紧字符串的其他部分。

EDIT2:我有@Produces(text/json)。这些是报告的标头(请注意,我使用 OkHttp 进行请求处理):

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

此外,从 Android 将接收到的字符串打印到控制台实际上可以正确打印它。我不知道发生了什么。

4

2 回答 2

1

我没有看到任何奇怪的行为。

Java 已经取消了字符串文字中出现的转义码,因此您testObj包含 Unicode 字符 0x2018 和 0x2019,而不是文字字符串“\u2018”和“\u2019”。因此,StringEscapeUtils.unescapeJava(...)返回相同的字符串。这意味着这testObj.contentEqual(postTreatmentTestObj)是真的,因此assertFalse(...)测试失败。

于 2014-12-23T20:28:21.207 回答
0

因此,经过数小时愚蠢地伸展我的头后,我知道正在发生的事情基本上是这样的(请参阅 2013 年 4 月 15 日的评论,了解截至 2014 年 12 月 23 日的有效解决方案):https ://code.google.com/p/安卓/问题/详细信息?id=3552

有时谷歌,有时...

于 2014-12-23T22:48:01.997 回答