2017-12-04 24 views
1

私はJersey 2.16を使用しています。残りのインターフェイスのために、私は 'application/xml'を受け入れ、charset = utf-8で 'application/xml'を生成する必要があります。私のコードは、私がクライアントからのリクエストを送信するとき、私はそれがutf-8と一致しないと、サーバーは、いくつかのエラーをスローすることを期待application/xml;charset=iso-8859-1としてContent-Typeを設定し、ある@Consumesのcharset = utf-8は機能していません

@POST 
@Produces("application/xml; charset=utf-8") 
@Consumes("application/xml; charset=utf-8") 
public String process(String request) { 
... 
return response; 

}ここで

。しかし、これは起こらない。しかし、charset=utf-8が応答として設定されます。これはHTTP Requestcharsetをチェックする正しい方法ですか?

+0

文字セットは、単にいくつかの非ASCIIの文字を送信し、 – gtosto

+0

感謝を何が起こるか見てみ...あなたは別の文字セットを使用してデータを送信する場合は、間違った文字を取得します、/デコードバイトをエンコードする方法についてのジャージを指示する属性!私は、文字セットミスマッチの場合に415のエラーがスローされると仮定しました。これは事を明確にします。私はアプリケーションでcharsetチェックを使用します。文字セットの不一致の場合、どのエラーコードを送信する必要がありますか?それは415であろうか? –

+0

@MaliniKennady現在、文字セットの値を提供していないときに、どのようなエラーが表示されますか? – Ravi

答えて

0

@HeaderParamを直接挿入し、コード内の文字セットを検証することができます。

public String process(@HeaderParam("Accept-Charset") String charset, String request) { 

if (charset.equalsIgnoreCase ("utf-8")) 
{ 
    // do something 
} 
else 
{ 
    // update your response. 
} 
... 
return response; 
+0

ありがとう。これは 'accept-type'で動作し、現在servletRequest.getCharacterEncoding()を使用して達成しているコンテンツタイプのcharsetをチェックしようとしていました。 –

+0

@MaliniKennadyが正しい。 '@ H​​eaderParam'は' @ Context'に比べて制限されたヘッダ値を与えます – Ravi

+0

"Accept-Charset"のような "Content-type"エンコーディングを与える別のヘッダです。 '@HeaderParam(" Content-Type ")文字列charset'は、' application \ xml; charset = utf-8'となります。ここで私は 'utf-8'を得るために解析する必要があります。しかし、 'servletRequest.getCharacterEncoding()'を使うと 'utf-8'が得られ、解析する必要がないので、私はそれを選択しました。 –

関連する問題