經常會被亂碼問題攪得頭暈腦脹。事實上，亂碼問題涉及的地方比較多，所以常常有了問題也很難定位，比如，可以發生在容器，可以發生在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());
<span style="white-space:pre">	</span>}
}

    也就是說跟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直接輸出。總之，查到什麼地方有問題，才能對症下藥。