SpringMVC 獲取請求參數1、通過 Servlet API 獲取 将HttpServletRequest作為控制器方法的形參，此時HttpServletRequest類型的參數表示封裝了當前請求的請求報文的對象

　　後台測試代碼

　　@RequestMapping(/testServletAPI) public String testServletAPI(HttpServletRequest request) { String username = request.getParameter(username String password = request.getParameter(password System.out.println(username= username ,password= password); return success } 複制代碼

　　前台測試代碼

　　a th:href=@{/paramController/testServletAPI(username=admin,password=123456通過 Servlet API 獲取 複制代碼

　　測試結果

　　後台日志信息

　　username=admin,password=123456 複制代碼

　　Q：為何将HttpServletRequest request傳入 testServletAPI() 方法中就可以使用？

　　A：SpringMVC 的 IOC 容器幫我們注入了HttpServletRequest請求對象，同時DispatherServlet為我們調用 testServletAPI() 方法時自動給request參數賦了值，因此可以在方法形參位置傳入請求對象HttpServletRequest就可以直接使用其getParameter()方法獲取參數

　　盡管上述 Servlet API 原生方式可以獲取請求參數，但是這樣做就沒有必要了。因為 SpringMVC 中幫我們封裝好了更加便捷的方式獲取請求參數

　　2、通過控制器方法形參獲取 在控制器方法的形參位置，設置和請求參數同名的形參，當浏覽器發送請求，匹配到請求映射時，在DispatcherServlet中就會将請求參數賦值給相應的形參

　　注意：在@RequestMapping注解的“路徑中的占位符”一節中，我們測試過了 restful 風格在不使用@PathVariable轉而通過同名形參的方式，試圖獲取占位符的值，不過 SpringMVC 并沒有很智能地給我們為同名參數賦值。但是這裡 SpringMVC 允許我們使用同名形參為請求參數賦值。這是占位符和請求參數的一個區别，需要注意區分！！！

　　2.1、同名形參 後台測試代碼

　　@RequestMapping(/testParam) public String testParam(String username, String password) { System.out.println(username= username ,password= password); return success } 複制代碼

　　前台測試代碼

　　a th:href=@{/paramController/testParam(username=admin,password=123456通過控制器方法形參獲取 複制代碼

　　測試結果

　　後台日志信息

　　username=admin,password=123456 複制代碼

　　2.2、同名形參多值 若請求所傳輸的請求參數中有多值情況，此時可以在控制器方法的形參中設置字符串數組或者字符串類型的形參接收此請求參數

　　若使用字符串數組類型的形參，此參數的數組中包含了每一個數據若使用字符串類型的形參，此參數的值為每個數據中間使用逗号拼接的結果 當某個請求參數有多個值時，比如前台含有複選框的情況，還能否使用這種方式呢？“實踐出真知”，現在就進行測試

　　後台測試代碼

　　@RequestMapping(/testParam2) public String testParam2(String username, String password, String hobby) { System.out.println(username= username , password= password , hobby= hobby); return success } 複制代碼

　　前台測試代碼

　　form th:action=@{paramController/testParam2} method=get 用戶名：input type=text name=username 密碼：input type=password name=password 愛好：input type=checkbox name=hobby value=SpringSpring input type=checkbox name=hobby value=SpringMVCSpringMVC input type=checkbox name=hobby value=SpringBootSpringBoot input type=submit value=測試請求參數 /form 複制代碼

　　測試結果

　　前台請求路徑中複選框的值為hobby=Spring&hobby=SpringMVC&hobby=SpringBoot，即出現了多個hobby=value的情況

　　後台日志信息

　　username=hah, password=111111, hobby=Spring,SpringMVC,SpringBoot 複制代碼

　　可見 SpringMVC 的控制器方法，對多個hobby值使用了,進行拼接并賦值給同名形參

　　擴展：如果這裡使用 Servlet API 進行獲取請求參數，就不能使用getParameter()方法獲取 hobby 值了，而要使用getParameterValues()方法

　　後台代碼測試

　　後台日志信息：通過getParameter()隻能獲取到 hobby 的第一個值，而getParameterValues()可以以數組的形式返回 hobby 的所有值

　　當然還是那句話：不建議在 SpringMVC 中使用原生 Servlet API 方法！！！這裡稍作回顧和了解即可

　　@RequestMapping(/testServletAPI2) public String testServletAPI2(HttpServletRequest request) { String hobby = request.getParameter(hobby String[] hobby2 = request.getParameterValues(hobby System.out.println(hobby= hobby , hobby2= Arrays.toString(hobby2)); return success } 複制代碼

　　username=sdfg, password=sdfg, hobby=Spring, hobby2=[Spring, SpringMVC, SpringBoot] 複制代碼

　　另外，控制器方法中使用String類型的數組接收 hobby 值也是可以的

　　@RequestMapping(/testParam3) public String testParam3(String username, String password, String[] hobby) { System.out.println(username= username , password= password , hobby= Arrays.toString(hobby)); return success } 複制代碼

　　後台日志信息

　　username=aaaaaaaaa, password=aaaaaaaa, hobby=[Spring, SpringMVC, SpringBoot] 複制代碼

　　3、@RequestParam @RequestParam是将請求參數和控制器方法的形參創建映射關系

　　一共有三個屬性：

　　value：指定為形參賦值的請求參數的參數名required：設置是否必須傳輸此請求參數，默認值為true若設置為true，則當前請求必須傳輸value所指定的請求參數，若沒有傳輸該請求參數，且沒有設置defaultValue屬性，則頁面報錯400：Required String parameterxxxis not present；若設置為false，則當前請求不是必須傳輸value所指定的請求參數，若沒有傳輸，則注解所标識的形參的值為nulldefaultValue：不管required屬性值為true或false，當value所指定的請求參數沒有傳輸或傳輸的值為空值時，則使用默認值為形參賦值 實際開發中，請求參數與控制器方法形參未必一緻，一旦出現這種情況，還能否接收到請求參數了呢？

　　這裡簡單地将前台name=username改為name=user_name進行測試，看下後台日志信息，果然沒有接收到 user_name 這個請求參數

　　username=null, password=aaaaaaaa, hobby=[Spring, SpringMVC, SpringBoot] 複制代碼

　　擴展思考：這裡也側面證明一件事，SpringMVC 中對請求參數的賦值是根據是否同名來決定的，而不會根據參數在方法上的第幾個位置決定，也就是說 SpringMVC 沒有考慮将請求參數個數、類型與順序與控制器方法形參個數、類型與順序進行綁定。如果我們來設計 SpringMVC，應該考慮這種方案麼？

　　個人覺得，這種方案雖然可以實現與 Java 重載方法的一一綁定關系，但實際操作起來有一定難度：

　　比如數字類型可以當作 String 處理，也可以當作 Integer 處理，不好區分 退一步來講，如果考慮重載方法，SpringMVC 底層勢必要對類中所有重載方法進行循環，判斷是否滿足個數、類型和順序的要求，性能上一定有所影響

　　而限制請求路徑和請求方式不能完全相同的話，就沒有這種苦惱了。即使是重載方法，通過不同請求路徑或請求方法來界定到底訪問哪個方法就可以了

　　SpringMVC 借助注解的方式，将請求參數與控制器方法形參關系綁定的決定權，交到開發者的手中。這種開發思維啟發我們，如果有些功能不能很好地在底層進行實現，甚至可能會留下很多隐患時，還不如交給實際使用者，由他們去決定，否則很容易被使用者诟病（沒有，我沒有暗示某語言啊(●◡●)）

　　此時使用@RequestParam注解就可以實現請求參數與控制器方法形參的綁定

　　後台測試代碼

　　@RequestMapping(/testParam3) public String testParam3(@RequestParam(user_name) String username, String password, String[] hobby) { System.out.println(username= username , password= password , hobby= Arrays.toString(hobby)); return success } 複制代碼

　　後台日志信息

　　username=ss, password=aaaaa, hobby=[Spring, SpringMVC, SpringBoot] 複制代碼

　　關于@RequestParam怎麼使用，可以看下源碼

　　@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface RequestParam { @AliasFor(name) String value() default @AliasFor(value) String name() default boolean required() default true; String defaultValue() default ValueConstants.DEFAULT_NONE; } 複制代碼

　　name和value：綁定的請求參數名，互為别名，用哪個都一樣required屬性：默認為true，表示必須要有此參數，不傳則報錯；不确定是否傳參又不想報錯，賦值為false即可defaultValue屬性：不管required是true還是false，隻要請求參數值為空（或null），就為形參附上此值3.1、required required默認為true，即要求該請求參數不能為空。因為是默認值，所以添加required=true與不寫required屬性是一樣的

　　這裡先測試下默認情況下不傳對應請求參數時系統的反應如何，隻需要将user_name一行注釋即可，或直接在浏覽器地址欄删除該請求參數也一樣

　　測試結果

　　報錯信息：400錯誤的請求，必須的請求參數user_name...不存在

　　HTTP Status 400 - Required request parameter user_name for method parameter type String is not present 複制代碼

　　經測試，不論是為 username 傳空值還是不傳值，都是400錯誤

　　/testParam3?user_name=&password=11&hobby=Spring&hobby=SpringMVC /testParam3?password=11&hobby=Spring&hobby=SpringMVC 複制代碼

　　如果将required設置為false，還會報錯嗎？

　　後台測試代碼：隻需要對@RequestParam(user_name)稍作改動，修改為@RequestParam(value = user_name, required = false)即可

　　@RequestMapping(/testParam3) public String testParam3(@RequestParam(value = user_name, required = false) String username, String password, String[] hobby) { System.out.println(username= username , password= password , hobby= Arrays.toString(hobby)); return success } 複制代碼

　　測試結果：可以發現，這次并沒有報400錯誤

　　後台日志信息

　　username=null, password=1111, hobby=[Spring, SpringMVC] 複制代碼

　　這是不傳 user_name 的情況，如果是傳空值呢？

　　測試結果：同樣訪問成功，沒有報400錯誤

　　後台日志信息

　　username=, password=111, hobby=[Spring, SpringMVC] 複制代碼

　　Q：不是說默認是true嗎？為什麼在沒有使用@RequestParam注解時，也能正常訪問呢？

　　A：這個默認值本身就是在使用@RequestParam注解時生效的，如果都沒有使用到@RequestParam，就沒有相應限制了

　　3.2、defaultValue 後台測試代碼

　　@RequestMapping(/testParam3) public String testParam3( @RequestParam(value = user_name, required = false, defaultValue = heh) String username, String password, String[] hobby) { System.out.println(username= username , password= password , hobby= Arrays.toString(hobby)); return success } 複制代碼

　　請求路徑：傳空值和不傳值兩種情況

　　/testParam3?user_name=&password=asdf&hobby=Spring&hobby=SpringMVC /testParam3?password=asdf&hobby=Spring&hobby=SpringMVC 複制代碼

　　後台日志信息

　　username=heh, password=asdf, hobby=[Spring, SpringMVC] 複制代碼

　　可以發現，不管是為 username 傳空值還是不傳值，最終都會被賦上默認值

　　這裡将required修改為true，即默認值的情況，發現也是可以請求成功的

　　注意：required一節測試中，在required的默認值情況下，沒有為請求參數賦值傳值或傳空值，會産生400的錯誤。

　　而隻要為請求參數設置默認值，即使用@RequestParam注解的defaultValue屬性賦上值，就不會有400錯誤了。

　　換句話說，隻要設置了defaultValue屬性值，required屬性就失效形同虛設了

　　4、@RequestHeader @RequestHeader是将請求頭信息和控制器方法的形參創建映射關系

　　一共有三個屬性：value、required、defaultValue，用法同@RequestParam

　　因為@RequestHeader與@RequestParam别無二緻，所以這裡我們簡單測試下效果

　　後台測試代碼

　　@RequestMapping(/testHeader) public String testHeader( @RequestHeader(value = Host) String host, @RequestHeader(value = Test, required = false, defaultValue = RequestHeader) String test) { System.out.println(Host= host , test= test); return success } 複制代碼

　　請求路徑

　　http://localhost:8080/SpringMVC/paramController/testParam4 複制代碼

　　後台日志信息

　　Host=localhost:8080, test=RequestHeader 複制代碼

　　5、@CookieValue @CookieValue是将 Cookie 數據和控制器方法的形參創建映射關系

　　一共有三個屬性：value、required、defaultValue，用法同@RequestParam

　　注意：

　　在JSP中，Session依賴于Cookie，Session是服務器端的會話技術，Cookie是客戶端的會話技術。 會話技術默認的生命周期是浏覽器開啟和浏覽器關閉，隻要浏覽器不關閉，Cookie将一直存在。 調用getSession()方法時，首先會檢測請求報文中是否有攜帶JSESSIONID的Cookie。如果沒有，說明當前會話是第一次創建Session對象，則 在服務端創建一個Cookie，以鍵值對形式存儲。鍵是固定的JSESSIONID，值是一個 UUID 随機序列 在服務端創建一個HttpSession對象，并放在服務器所維護的 Map 集合中。Map 的鍵是JSESSIONID的值，值就是HttpSession對象 最後把Cookie相應給浏覽器客戶端，此時JSESSIONID的Cookie存在于響應報文中。每次浏覽器向服務器發送請求都會攜帶Cookie，此後JSESSIONID的Cookie将存在于請求報文中

　　為了能獲取到Cookie值，需要先調用下getSession()方法。我們直接在之前的 testServletAPI() 方法中稍作修改

　　@RequestMapping(/testServletAPI) public String testServletAPI(HttpServletRequest request) { HttpSession session = request.getSession(); // ... } 複制代碼

　　首次發送請求後，F12 查看前台該請求的響應報文信息

　　會發現在Set-Cookie屬性中存在JSESSIONID=xxx的信息

　　Set-Cookie: JSESSIONID=C3DFF845C38BF655C02DDA0BD2DD5638; Path=/SpringMVC; HttpOnly 複制代碼

　　後面每次發送請求，JSESSIONID的Cookie将會放在請求報文信息

　　會發現在Cookie屬性中存在JSESSIONID=xxx的信息

　　Cookie: JSESSIONID=C3DFF845C38BF655C02DDA0BD2DD5638 複制代碼

　　經過上面的折騰，我們産生了Cookie數據，現在我們就可以使用@CookieValue注解進行操作了。正片開始~

　　後台測試代碼

　　@RequestMapping(/testCookie) public String testCookie( @CookieValue(value = JSESSIONID) String jSessionId, @CookieValue(value = Test, required = false, defaultValue = CookieValue) String test) { System.out.println(jSessionId= jSessionId , test= test); return success } 複制代碼

　　前台請求報文信息

　　後台日志信息

　　jSessionId=C3DFF845C38BF655C02DDA0BD2DD5638, test=CookieValue 複制代碼

　　6、通過實體類獲取 可以在控制器方法的形參位置設置一個實體類類型的形參，此時浏覽器傳輸的請求參數的參數名和實體類中的屬性名一緻，那麼請求參數就會為此屬性賦值

　　前台測試代碼

　　form th:action=@{/paramController/testBean} method=post 用戶名：input type=text name=username 密碼：input type=password name=password 性别：input type=radio name=gender value=男人男 input type=radio name=gender value=女人女 年齡：input type=text name=age 郵箱：input type=text name=email input type=submit value=測試請求參數 /form 複制代碼

　　後台測試代碼

　　@RequestMapping(/testBean) public String testBean(User user) { System.out.println(user); return success } 複制代碼

　　User 類：要求屬性名與請求參數名一緻

　　public class User { private String username; private String password; private String gender; private String age; private String email; // Setter、Getter方法略 @Override public String toString() { return User{username= username , password= password , gender= gender , age= age , email= email } } } 複制代碼

　　測試結果

　　後台日志信息

　　User{username=, password=, gender=女人, age=, email=123@qq.com} User{username=, password=, gender=男人, age=, email=123@qq.com} 複制代碼

　　貌似基本成功了，但卻出現了亂碼的情況，什麼原因呢？

　　7、處理亂碼問題 注意：在 Servlet 階段，是通過request.setCharacterEncoding(UTF-8的方式解決亂碼問題的。雖然 SpringMVC 中可以使用HttpServletRequest對象，但是沒有效果。原因也很簡單，是因為請求參數獲取在前，設置編碼格式在後

　　事實勝于雄辯，簡單測試下

　　後台測試代碼

　　@RequestMapping(/testServletAPI3) public String testServletAPI3(HttpServletRequest request) throws UnsupportedEncodingException { request.setCharacterEncoding(UTF-8 String username = request.getParameter(username System.out.println(username= username); return success } 複制代碼

　　前台測試代碼

　　form th:action=@{/paramController/testServletAPI3} method=post 用戶名：input type=text name=username input type=submit value=測試請求參數 /form 複制代碼

　　後台日志信息

　　username=å¼ ä¸ 複制代碼

　　可能你會說，上面的測試都是post請求，如果是get請求呢？問得好，下次不要問了

　　a th:href=@{/paramController/testServletAPI3(username=張三通過setCharacterEncoding設置編碼 複制代碼

　　後台日志信息

　　username=張三 複制代碼

　　Q：這是為什麼呢？怎麼get請求還搞特殊？

　　A：這是因為 Tomcat 的 conf 目錄下的 server.xml中配置了URIEncoding=UTF-8的原因。這樣get請求的亂碼問題就可以一次性解決了

　　如果一開始就沒有配置，那get請求也會亂碼，所以拜托不是get請求搞特殊了喂！

　　Q：既然在server.xml配置下編碼格式就行了，為什麼隻支持get請求啊？還說不是搞特殊？

　　A：...你赢了

　　Q：退一步來說，post請求能不能在請求參數獲取之後再去處理也可以吧，隻要知道其本身的編碼

　　A：試一下咯

　　Connector port=8080 protocol=HTTP/1.1 connectionTimeout=20000 redirectPort=8443 URIEncoding=UTF-8 複制代碼

　　我們先通過 在線亂碼恢複 看下，亂碼的文本實際編碼是什麼

　　很顯然，亂碼本身為ISO-8859-1格式，我們轉換為UTF-8編碼格式即可

　　後台測試代碼

　　// 對其進行iso-8859-1解碼并重新UTF-8編碼 username = new String(username.getBytes(ISO-8859-1), UTF-8 System.out.println(username= username); 複制代碼

　　後台日志信息

　　username=張三 複制代碼

　　有上述測試可知，要想處理亂碼問題，思路有二：

　　獲取請求參數之後，手動解碼編碼。但是這種方式要求每次處理post請求的請求參數都要手動處理，太不人性化了吧。你嫌煩，我還嫌煩呢（❌） 獲取請求參數之前“做手腳”：發送請求之前，也就是在Servlet處理請求之前（）

　　那什麼組件時在Servlet之前執行的呢？

　　衆所周知 （我不知道），JavaWeb 服務器中三大組件：監聽器、過濾器、Servlet。很顯然，監聽器和過濾器都在Servlet之前

　　ServletContextListener監聽器：隻是來監聽ServletContext的創建和銷毀，都是隻執行一次 Filter過濾器：隻要設置了過濾路徑，隻要當前所訪問的請求地址滿足過濾路徑，那麼都會被過濾器過濾

　　很顯然，用過濾器就可以做到在發送請求之前“做手腳”，這樣所有請求都要經過過濾器的處理，再交給DispatherServlet處理

　　但是，這個過濾不需要我們寫，SpringMVC 已為我們準備好了，隻要再web.xml中進行配置即可

　　我們先對web.xml進行配置

　　filter filter-namecharacterEncodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceResponseEncoding/param-name param-value/param-value /init-param/filterfilter-mapping filter-namecharacterEncodingFilter/filter-name url-pattern/url-pattern/filter-mapping 複制代碼

　　重啟後測試，看下後台日志信息

　　username=張三 複制代碼

　　Perfect! 配置很簡單，測試結果立竿見影，亂碼問題得到了解決

　　“知其然，知其所以然”

　　這個神奇的CharacterEncodingFilter到底幹了什麼？我們一起來看下源碼一探究竟

　　我們知道，在init-param标簽中配置的屬性值，其實就是為對應類進行的屬性注入。這裡可以很清楚地看到encoding和forceResponseEncoding兩個屬性值，同時注意到encoding被@Nullable注解修飾，表示其可以為空，forceResponseEncoding默認為false，即不配置不生效

　　另外，看一個Filter最重要的找它的doFilter()方法

　　可以看到，CharacterEncodingFilter類中并沒有doFilter()方法，那去它的基類中找找吧~

　　直接讀源碼

　　@Override public final void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { // 就是判斷是不是http請求和相應，不管 if (!(request instanceof HttpServletRequest) || !(response instanceof HttpServletResponse)) { throw new ServletException(OncePerRequestFilter just supports HTTP requests } // 拿到一些了對象和參數，繼續往下看看有什麼用處 HttpServletRequest httpRequest = (HttpServletRequest) request; HttpServletResponse httpResponse = (HttpServletResponse) response; String alreadyFilteredAttributeName = getAlreadyFilteredAttributeName(); boolean hasAlreadyFilteredAttribute = request.getAttribute(alreadyFilteredAttributeName) != null; // 三個條件判斷，一一看下 // 1、跳過轉發或不過濾的，就直接進行過濾鍊的下一個請求（确信） if (skipDispatch(httpRequest) || shouldNotFilter(httpRequest)) { filterChain.doFilter(request, response); } // 2、已經過濾屬性的，多了一層判斷，貌似時處理錯誤轉發的？（不太懂） else if (hasAlreadyFilteredAttribute) { if (DispatcherType.ERROR.equals(request.getDispatcherType())) { doFilterNestedErrorDispatch(httpRequest, httpResponse, filterChain); return; } filterChain.doFilter(request, response); } // 3、其他情況（應該就是正常情況吧）：設置下屬性，再走 doFilterInternal 方法（還有印象嗎？這個方法我們在其子類CharacterEncodingFilter中看到過的，那就順藤摸瓜） else { request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE); try { doFilterInternal(httpRequest, httpResponse, filterChain); } finally { request.removeAttribute(alreadyFilteredAttributeName); } } } 複制代碼

　　回到CharacterEncodingFilter中看下doFilterInternal()方法

　　@Override protected void doFilterInternal( HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { // 獲取編碼格式，很明顯就是獲取web.xml中的配置值了（确信） String encoding = getEncoding(); if (encoding != null) { // 二選一：配置了forceRequestEncoding為true或者請求的字符編碼沒有被設置，就給請求對象設置編碼格式 if (isForceRequestEncoding() || request.getCharacterEncoding() == null) { request.setCharacterEncoding(encoding); } // 配置了forceResponseEncoding為true，就給響應對象設置編碼格式 if (isForceResponseEncoding()) { response.setCharacterEncoding(encoding); } } filterChain.doFilter(request, response); } 複制代碼

　　可以看出

　　沒有在web.xml設置編碼格式就不管了，愛咋咋地設置了encoding就看下是請求對象還是響應對象請求對象：如果打開了forceRequestEncoding即強制請求編碼開關，就給設置下編碼；就算沒打開這個開關，隻要請求對象還沒有設置過字符編碼格式，那就給它設置下響應對象：隻有打開了forceResponseEncoding即強制響應編碼開關，才給設置編碼總結 獲取請求的方式有兩種：

　　通過 Servlet API 獲取（不推薦）通過控制器方法獲取（就是要用它，不然學 SpringMVC 幹什麼，不是） SpringMVC 獲取請求參數的注解：@RequestParam、@RequestHeader、@CookieValue

　　都是作用在控制器方法上的形參的（就是獲取請求參數的，還能作用在别的地方？）都有三個屬性：value/name、required、defaultValue（這不是四個嗎？呸）主要解決形參和請求參數名不同名的問題，其次是必填問題，最後是缺省值的問題（順序确定對嗎？别誤人子弟了，不是，我錯了） 如果請求參數與控制器方法形參同名，就可以不用上述的@RequestParam注解

　　如果請求參數有多個值，通過字符串類型或字符數組類型都可以獲取

　　如果請求參數與控制器方法形參對象屬性同名，同理。即滿足同名條件時，SpringMVC 中允許通過實體類接收請求參數

　　Q：那請求頭和Cookie呢，同名也可以不加注解麼？

　　A：大哥，這剛開始我是沒想到的，不過我又回頭試了下，确信不可以！

　　最後附上導圖，僅供參考

　　原文鍊接：htt

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!