Http://www.360doc.com/content/09/0915/15/61497_6003890.shtml in practice, however, it is found that UTF-8 encoding is not supported when calling HttpClient in the most basic way. On the network to find some articles, also no avail, and then looked at some of the commons-httpclient3.0.1 code, first found in the Postmethod generaterequestentity () method:
/**
* Generates a request entity from the post parameters, if present. Calls
* {@link entityenclosingmethod#generaterequestbody ()}If parameters has not been set.
*
*@since3.0
*/
protected requestentity generaterequestentity() {
if(! This. Params.isempty()) {
//Use a bytearrayrequestentity instead of a stringrequestentity.
//This was to avoid potential encoding issues. Form URL encoded strings
//is ASCII by definition but the content type is not a be . Treating the Content
//As bytes allows us to keep, the current charset without worrying on how
//This charset would effect the encoding of the form URL encoded string.
String content = Encodingutil.formurlencode(GetParameters(), Getrequestcharset());
bytearrayrequestentity entity = Newbytearrayrequestentity(
encodingutil.getasciibytes(content),
Form_url_encoded_content_type
);
returnentity;
}Else{
return Super. Generaterequestentity();
}
} |
The parameters of the HTTP request that were originally added with Namevaluepair will eventually be converted to requestentity submission to the HTTP server, followed by the following code in the parent class Entityenclosingmethod of Postmethod:
/**
* Returns The request ' s CharSet. The charset is parsed from the request entity ' s
* Content type, unless the content type header has been set manually.
*
*@seeRequestentity#getcontenttype ()
*
*@since3.0
*/
PublicString Getrequestcharset() {
if(Getrequestheader("Content-type")==NULL) {
//Check the content type from request entity
//We can ' t call Getrequestentity () since it'll probably call
//This method.
if( This. requestentity! =NULL) {
returnGetcontentcharset(
NewHeader("Content-type", Requestentity.getcontenttype()));
} Else{
return Super. Getrequestcharset();
}
} Else{
return Super. Getrequestcharset();
}
} |
Solution SolutionsFrom the above two pieces of code can be seen is how HttpClient is based on "Content-type" to obtain the requested encoding (character set), and how this code is applied to the content of the submission of the encoding process. According to this, in fact, we only need to overload the Getrequestcharset () method, return the encoding (character set) we need to name, we can solve the UTF-8 or other non-default encoding to submit the POST request garbled problem.
TestFirst, a page test.jsp is deployed under Tomcat ROOT WebApp, and as a test page, the main code snippet is as follows:
<%@ page contenttype="Text/html;charset=utf-8"%>
<%@ page session="false"%>
<%
request.setcharacterencoding("UTF-8");
String val = request.getparameter("TEXT");
System.out.println(">>>> The result is"+ Val);
%> |
Then write a test class, the main code is as follows:
Public StaticvoidMain(String[]args)throwsException, IOException{
String url ="http://localhost:8080/test.jsp";
Postmethod Postmethod =NewUtf8postmethod(URL);
//Fill in the values of each form field
Namevaluepair[]data ={
NewNamevaluepair("TEXT","Chinese"),
};
//Put the value of the form into Postmethod
Postmethod.setrequestbody(Data);
//Execute Postmethod
HttpClient httpclient=NewHttpClient();
Httpclient.executemethod (postmethod);
}
//inner class for UTF-8 support
Public Static ClassUtf8postmethodextendsPostmethod{
Public Utf8postmethod(String URL){
Super(URL);
}
@Override
PublicString Getrequestcharset() {
//return Super.getrequestcharset ();
return"UTF-8";
}
} |
Running this test program, the ">>>> The result is Chinese" can be printed correctly in Tomcat's background output.
HttpClient POST's UTF-8 encoding problem
