今天幫小伙伴解決了一個請求參數(shù)亂碼問題，大概花費(fèi)2個小時吧，要不是前段時間自己稍微花時間看了看spring mvc框架的源碼，估計今天要花好長時間解決這個問題了。起先我讓小伙伴試試?yán)胻omcat源碼來進(jìn)行調(diào)試一下，小伙伴感覺有些吃力，就交給我?guī)兔鉀Q一下，還好幫他搞定了這個問題。

　　tomcat的參數(shù)解析涉及到如下幾個類：

　　org.apache.coyote.Request

　　低級別類，用于包裝socket的請求了。

　　org.apache.tomcat.util.http.Parameters

　　集中存放解析的參數(shù)，post請求參數(shù)個get請求的參數(shù)

　　org.apache.catalina.connector.RequestFacade

　　請求門面，包裝請求，是請求的實(shí)現(xiàn)類，但其實(shí)是誰的門面呢？是coyoteRequest，

　　springmvc框架會調(diào)用request的getParameterValues方法，而這個方法又調(diào)用實(shí)際的coyoteRequest的getParameterValues方法，這個方法會首先判斷以前是否已經(jīng)解析過參數(shù)了，如果沒有解析參數(shù)，那么就發(fā)生第一次解析參數(shù)的操作。

　　調(diào)用parseParameters方法解析所有的參數(shù)，包括url的參數(shù)，這個函數(shù)里面，會調(diào)用Rquest類的getParameters方法，你敢相信，每當(dāng)來一個請求，就創(chuàng)建一個Request對象，我們的參數(shù)就預(yù)先創(chuàng)建放到Request對象里面了。

　　獲得Parameters對象，則要解析url里面的參數(shù)，還要解析請求體里面的參數(shù)。一個參數(shù)一個參數(shù)地解析，每解析一個就存放到paramHashValues對象里面。這個對象是個HashMap對象。

　　小伙伴出現(xiàn)亂碼的原因就是Filter放置的順序有些問題，設(shè)置編碼的Filter應(yīng)該放置在第一個位置，首先進(jìn)行配置編碼，而小伙伴的這個Filter放在了一個XSS處理的Filter的后面，可想而知，XSS提前進(jìn)行了參數(shù)解析，沒有使用UTF-8編碼，然后緩存了起來，后續(xù)設(shè)置編碼的Filter沒有起到任何作用，從而發(fā)生了亂碼問題。

　　網(wǎng)絡(luò)程序真是io密集型的啊，解析參數(shù)并非簡簡單單，基本上就是從socket里面取數(shù)據(jù)，都是一個字節(jié)一個字節(jié)的解析的。具體的參數(shù)格式啥的，我們就不深究了，感覺沒有必要啊，到時候有時間再進(jìn)行集中式的回顧學(xué)習(xí)，加深對java web程序的理解和掌握。

　　感覺針對我們開發(fā)常用的開發(fā)框架，還是要稍微了解點(diǎn)源碼，否則，面對陌生的源碼環(huán)境，感覺未必能在非常短的時間內(nèi)解決問題啊。

?

轉(zhuǎn)載于:https://www.cnblogs.com/weiguangyue/p/9374512.html

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的ApacheTomcat解析请求参数的过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。