http://www.xuebuyuan.com/1287083.html
***********************************
经常会被乱码问题搅得头晕脑胀。事实上，乱码问题涉及的地方比较多，所以常常有了问题也很难定位，比如，可以发生在容器，可以发生在MVC框架，可以发生在数据库，可以发生在响应等等。
这里分析一下tomcat中是如何编解码的。
以"http://localhost:8080/测试?网络=编程"为例，可以将tomcat中编解码分解为这么几个地方：
1. pathInfo.即“测试”这个部分
2. queryParameter，即”网络=编程“这个部分
3. http header，即浏览器发送的http头部分
4. requestBody，http正文部分，即post的正文部分
1. pathInfo，Http11Processor中的process方法会调用InternelInputBuffer来解析请求 URL(inputBuffer.parseRequestLine)以及请求头(inputBuffer.parseHeaders)，但是这里并不是 解码的地方。
public void process(Socket theSocket)
throws IOException {
...
inputBuffer.parseRequestLine();
request.setStartTime(System.currentTimeMillis());
keptAlive = true;
if (disableUploadTimeout) {
socket.setSoTimeout(soTimeout);
} else {
socket.setSoTimeout(timeout);
}
// Set this every time in case limit has been changed via JMX
request.getMimeHeaders().setLimit(endpoint.getMaxHeaderCount());
inputBuffer.parseHeaders();
...
}
真正解码的地方是CoyoteAdapter的convertURI
protected void convertURI(MessageBytes uri, Request request)
throws Exception {
ByteChunk bc = uri.getByteChunk();
int length = bc.getLength();
CharChunk cc = uri.getCharChunk();
cc.allocate(length, -1);
String enc = connector.getURIEncoding();
if (enc != null) {
B2CConverter conv = request.getURIConverter();
try {
if (conv == null) {
conv = new B2CConverter(enc);
request.setURIConverter(conv);
}
} catch (IOException e) {
// Ignore
log.error("Invalid URI encoding; using HTTP default");
connector.setURIEncoding(null);
}
if (conv != null) {
try {
conv.convert(bc, cc);
uri.setChars(cc.getBuffer(), cc.getStart(),
cc.getLength());
return;
} catch (IOException e) {
log.error("Invalid URI character encoding; trying ascii");
cc.recycle();
}
}
}
// Default encoding: fast conversion
byte[] bbuf = bc.getBuffer();
char[] cbuf = cc.getBuffer();
int start = bc.getStart();
for (int i = 0; i < length; i++) {
cbuf[i] = (char) (bbuf[i + start] & 0xff);
}
uri.setChars(cbuf, 0, length);
}
而这里的解码使用的是connector的URIEncoding，所以pathInfo的解码可以通过配置server.xml中的URIEncoding来改变。
2. queryParameter部分，这里其实有几个地方可以控制，首先，我们还是找到解码queryParameter的地方。在调用 request.getParameter时最终会调用到coyote内部的Parameter中的handleQueryParameters方法，可 以看到这里的queryStringEncoding。
public void handleQueryParameters() {
if( didQueryParameters ) return;
didQueryParameters=true;
if( queryMB==null || queryMB.isNull() )
return;
if(log.isDebugEnabled()) {
log.debug("Decoding query " + decodedQuery + " " +
queryStringEncoding);
}
try {
decodedQuery.duplicate( queryMB );
} catch (IOException e) {
// Can't happen, as decodedQuery can't overflow
e.printStackTrace();
}
processParameters( decodedQuery, queryStringEncoding );
}
queryStringEncoding是由什么地方决定的呢？事实上，有几个地方决定。第一个是CoyoteAdapter中的service方法，另 外就是FormAuthenticator，这两个地方都使用了connector.getURIEncoding()。
public void service(org.apache.coyote.Request req,
org.apache.coyote.Response res)
throws Exception {
if (request == null) {
...
// Set query string encoding
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
}
}
也就是说跟pathInfo是一样的，但是千万不要以为就这样了，其实还有另一个地方会让整个事情变得很奇怪。在调用 request.getParameter时，事实上会先调用parseParameters方法，然后才调用 handleQueryParameters，而parseParameters就是第三个设置queryStringEncoding的地方。 getCharacterEncoding首先会去找request中设置的charEncoding，找不到就去找requestHeader中 contentType的编码，还找不到就返回null，这时如果在server.xml中设置了 useBodyEncodingForURI=true，则queryStringEncoding编码就会变成默认编码，即IS08859-1；而考虑 另一种情况，如果contentType能找到这个编码（如UTF-8），则queryStringEncoding跟随contentType。
所以，结论是，queryStringEncoding编码的优先级是，第一是随contentType，第二随URIEncoding（即没有设 置contentType编码，同时也没有设置useBodyEncodingForURI），第三则是默认编码（即没有设置contentType，设 置了useBodyEncodingForURI=true）
protected void parseParameters() {
parametersParsed = true;
Parameters parameters = coyoteRequest.getParameters();
// Set this every time in case limit has been changed via JMX
parameters.setLimit(getConnector().getMaxParameterCount());
// getCharacterEncoding() may have been overridden to search for
// hidden form field containing request encoding
String enc = getCharacterEncoding();
boolean useBodyEncodingForURI = connector.getUseBodyEncodingForURI();
if (enc != null) {
parameters.setEncoding(enc);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding(enc);
}
} else {
parameters.setEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
if (useBodyEncodingForURI) {
parameters.setQueryStringEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
}
3. httpheader， 在InternalInputBuffer的parseHeader中解析，最终会调用到ByteChunk的toStringInternal，里面用 到的是DEFAULT_CHARSET，这个默认字符集就是ISO8859-1，意味着不能更改httpheader
public String toStringInternal() {
if (charset == null) {
charset = DEFAULT_CHARSET;
}
// new String(byte[], int, int, Charset) takes a defensive copy of the
// entire byte array. This is expensive if only a small subset of the
// bytes will be used. The code below is from Apache Harmony.
CharBuffer cb;
cb = charset.decode(ByteBuffer.wrap(buff, start, end-start));
return new String(cb.array(), cb.arrayOffset(), cb.length());
}
4. post中的参数正是上面解析queryStringEncoding中的parameters，也就是说post请求仍然是contentType中的编码方式优先，其次就是默认的ISO8859-1。
到这里，tomcat的编码基本上算是分析完了。但是编码问题涉及的点太多，比如数据库，可以修改数据库的编码或者jdbc连接时指定编码；比如一些框 架，如springmvc中的ResponseBody就硬编码了ISO8859-1，可以换用ResponseEntity，或者 Response.getWriter直接输出。总之，查到什么地方有问题，才能对症下药。