本質上來說，java.net.UrlEncoder適用于將 String 轉換為 application/x-www-form-urlencoded MIME 格式的靜態方法 時 ，使用

但！一般情況下，web應用中，當你的服務器，頁面編碼，請求時編碼都已經修改為 utf-8后，依然亂碼時，此時則應試著用下方所寫到的方法

使用URLDecoder將所亂碼的數據進行解碼，

而在此處簡單說一下亂碼的場景和簡單轉換時的執行原理：

首先，form表單提示數據時，默認Content-type：為 application/x-www-form-urlencoded，

當然也可以是：multipart/form-data ，multipart/form-data 一般用做form表單以流的形式提交數據時，則設置，enctype為該form-data形式，

不過呢，一般情況下，本寶寶桑面 提到了，提交方式為application/x-www-form-urlencoded, 當 環境等等都已經配置為統一編碼后，仍然出現漢字

傳到后臺 被解碼處理的情況時（也就是所謂的亂碼 ），此時可以嘗試，該文下面所提到的方法，使用URLDecoder進行解碼再轉換，然后轉換為漢字，

當然在使用場景上，其實還是有很多情況下需要區分的，當然 也是必須嚴格按照 格式 來做相對應的處理也才是最正確的方法，目前有些事情需要處理一下

先到這里嘍，^_^ bye

java  使用URLDecoder和URLEncoder對中文進行處理

一 URLEncoder

HTML 格式編碼的實用工具類。該類包含了將 String 轉換為 application/x-www-form-urlencoded MIME 格式的靜態方法。有關 HTML 格式編碼的更多信息，請參閱 HTML 規范。

對 String 編碼時，使用以下規則：

字母數字字符 "a" 到 "z"、"A" 到 "Z" 和 "0" 到 "9" 保持不變。

特殊字符 "."、"-"、"*" 和 "_" 保持不變。

空格字符 " " 轉換為一個加號 "+"。

所有其他字符都是不安全的，因此首先使用一些編碼機制將它們轉換為一個或多個字節。然后每個字節用一個包含 3 個字符的字符串 "%xy" 表示，其中 xy 為該字節的兩位十六進制表示形式。推薦的編碼機制是 UTF-8。但是，出于兼容性考慮，如果未指定一種編碼，則使用相應平臺的默認編碼。

例如，使用 UTF-8 編碼機制，字符串 "The string ü@foo-bar" 將轉換為 "The+string+%C3%BC%40foo-bar"，因為在 UTF-8 中，字符 ü 編碼為兩個字節，C3 （十六進制）和 BC （十六進制），字符 @ 編碼為一個字節 40 （十六進制）。

 二 URLDecoder

該類包含了將 String 從 application/x-www-form-urlencoded MIME 格式解碼的靜態方法。

該轉換過程正好與 URLEncoder 類使用的過程相反。假定已編碼的字符串中的所有字符為下列之一："a" 到 "z"、"A" 到 "Z"、"0" 到 "9" 和 "-"、"_"、"." 以及 "*"。允許有 "%" 字符，但是將它解釋為特殊轉義序列的開始。

轉換中使用以下規則：

字母數字字符 "a" 到 "z"、"A" 到 "Z" 和 "0" 到 "9" 保持不變。

特殊字符 "."、"-"、"*" 和 "_" 保持不變。

加號 "+" 轉換為空格字符 " "。

將把 "%xy" 格式序列視為一個字節，其中 xy 為 8 位的兩位十六進制表示形式。然后，所有連續包含一個或多個這些字節序列的子字符串，將被其編碼可生成這些連續字節的字符所代替。可以指定對這些字符進行解碼的編碼機制，或者如果未指定的話，則使用平臺的默認編碼機制。

該解碼器處理非法字符串有兩種可能的方法。一種方法是不管該非法字符，另一種方法是拋出 IllegalArgumentException 異常

以上這篇詳談java編碼互轉(application/x-www-form-urlencoded)就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持服務器之家。