Http協議中極爲重要的兩個協議是請求協議和響應。後端服務器從前端接收回請求後再鏈接數據庫服務器老是會出現亂碼的問題。如今就這個亂碼問題進行一個詳細的總結。html
一、數據展現中的亂碼問題前端
--- 若是是html頁面,那麼須要使用meta標籤的屬性charset指揮瀏覽器以什麼字符集進行顯示。例如:國內的瀏覽器若是不進行設置大都默認爲簡體中文進行頁面展現,若是服務器端工做區的java
字符集格式是utf-8,那麼這時候就會出現中文亂碼問題,因此須要加上一段代碼:mysql
<meta charset="utf-8">
---若是是從服務器端向瀏覽器端打印輸出,例如java中servlet中向瀏覽器端使用response.getWriter().print這種語句,或者是jsp中的el表達式都須要加上這樣一段代碼設置響應的格式sql
servlet中 response.setContentType("UTF-8"); 或jsp中 <%@page contentType="text/html;charset=UTF-8"%> 設置響應的類型和字符集 <%@page pageEncoding="UTF-8"%> 單獨設置響應的字符集
二、數據保存中的亂碼問題數據庫
在這裏須要進行一個判斷,是將數據保存到數據庫以前出現的亂碼,仍是保存後出現的亂碼。後端
---若是是保存以前出現的亂碼,須要在保存以前解決亂碼問題。這裏須要在保存到服務器以前就將亂碼解決掉,問題不在於數據庫。瀏覽器
---若是確認保存以前是正常的,可是一保存到數據庫中就出現亂碼,那麼就有多是數據庫不支持這種字符集,例如:若是數據庫不支持utf-8,則須要進行一下設置tomcat
怎麼設置mysql的字符集呢?
* 全局設置
修改mysql.ini配置文件中全部的字符集,修改以後重啓mysql服務。
* 局部設置
CREATE TABLE `emp` (
`EMPNO` int(4) NOT NULL,
`ENAME` varchar(10) DEFAULT NULL,
`JOB` varchar(9) DEFAULT NULL,
`MGR` int(4) DEFAULT NULL,
`HIREDATE` date DEFAULT NULL,
`SAL` double(7,2) DEFAULT NULL,
`COMM` double(7,2) DEFAULT NULL,
`DEPTNO` int(2) DEFAULT NULL,
PRIMARY KEY (`EMPNO`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
三、數據傳輸中的亂碼問題服務器
---什麼是數據傳輸中的亂碼問題?
form表單提交以後,從服務器端接收數據時出現了亂碼。
---產生這種現象的根本緣由是?
由於瀏覽器傳輸數據統一採用的是國標iso8859-1,瀏覽器將頁面展現中的utf-8格式的數據轉換爲iso8859-1,服務器接收到iso8859-1的數據後殊不知道這些數據原來是什麼字符集什麼格式的。
因此這裏就須要將瀏覽器端傳送來的數據進行一個轉型。
---怎麼作?
i 萬能方法:
能夠解決get以及post,任何一種傳遞中的亂碼採用此方式均可以解決。 byte[] bytes = username.getBytes("ISO-8859-1"); //從新編碼 (網線當中傳送的是ISO-8859-1) username = new String(bytes,"UTF-8"); //從新解碼 (ISO-8859-1以前是UTF-8的方式) 換句話說:瀏覽器的字符集是GBK的時候,第二行代碼修改成GBK就好了。 注意:tomcat7以及7版本以前以上方式均可以解決post和get亂碼。
ii 請求行中的亂碼
get請求發送的請求內容是在請求行中,9.0版本以上的tomcat服務器server.xml配置文件中Connector標籤當中的Encoding屬性默認爲utf-8,可是9.0如下版本Encoding屬性默認爲iso-8859-1,這 裏須要特別注意:若是使用的是9.0如下版本則須要將Encoding屬性進行修改成要使用的字符集纔不會出現亂碼
iii 請求體中亂碼
post請求發送的額請求內容是在請求體中,請求體中的亂碼須要在servlet進行設置接受的字符集,使用如下代碼:
request.setCharacterEncoding("UTF-8");
張先生 郵箱:zg_199101@163.com