0

したがって、以下の画像は私の問題をかなりよく示していると思います。

ここに画像の説明を入力

(JAX-RS を使用して) 応答で送信すると、本来の左引用符ではなく \u2018 が実際に表示されるため、元の文字列がそのまま印刷されることを期待しています。ただし、メソッド EncodingUtils.clean(...) (Apache Commons Lang StringEscapeUtils.unescapeJava(...) の単なるラッパー) を応答に送信された文字列に適用しても、応答は変更されません (まだ表示されます \ u2018)。テストの時点でそれらが変更されたため、ここで何が欠けていて、意図した代替品を入手するには何をする必要がありますか?

EDIT1: クライアントは Android アプリで、厄介な文字列は前述の JSON 応答の属性の 1 つです。触らないと、携帯電話に「€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、リテラル文字列 "\u2018" および "\u2019" ではなく、Unicode 文字 0x2018 および 0x2019 が含まれています。したがって、StringEscapeUtils.unescapeJava(...)同じ文字列を返します。これtestObj.contentEqual(postTreatmentTestObj)は真であることを意味するため、assertFalse(...)テストは失敗します。

于 2014-12-23T20:28:21.207 に答える
0

だから、頭をばかげて何時間も伸ばした後、起こっていることは基本的にこれだと思います（2014年12月23日現在の実用的な解決策については、2013年4月15日のコメントを参照してください）：https://code.google.com/p/アンドロイド/問題/詳細?id=3552

時にはグーグル、時には...

于 2014-12-23T22:48:01.997 に答える