1、字符編碼
在計算機中任何數(shù)據(jù)都是以二進制存儲的，要存儲一個字符就要對它進行編碼，用一個二進制數(shù)與這對應，這種對應的規(guī)則，就是字符的編碼。編碼的規(guī)則有很多 種，一種規(guī)則所編碼的“字符”的集合就叫做“字符集”。在制定編碼標準的時候，“字符的集合”和“編碼”一般都是同時制定的，因此，平時我們所說的“字符 集”，例如GB2312、GBK和JIS等，除了有“字符的集合”這層含義外，同時也包含了“編碼”的含義。
最早出現(xiàn)的編碼是ASCII碼，因為早期計算機系統(tǒng)只支持英語。后來每個國家（或區(qū)域）規(guī)定了計算機信息交換用的字符編碼集，例如中國的GB2312等作 為自己國家/區(qū)域內信息處理的基礎。在程序讀取字符到輸出字符的過程中，就需要在不同的字符集之間進行轉換，這個時候就容易出現(xiàn)亂碼，因此要了解亂碼是如 何產(chǎn)生的，首先要了解各種字符編碼。下面對這些編碼做一個簡單介紹。
1）、ASCII
ASCII碼是《美國標準信息交換碼》，簡稱ASCII，它總共規(guī)定了128個字符號所對應的數(shù)字代碼，使用了7位二進制的位來表示這些數(shù)字。其中包含了英文的大小寫字母、數(shù)字和標點符號常用的字符，數(shù)字代號從0~127。
2）、ISO8859
ASCII碼解決了英語國家的字符問題，可是歐洲各個國家的字符問題還沒有解決，例如法語中就有許多英語中沒有的字符，為了解決該問題，國際標準化組織的 ISO8859標準應運而生，在ISO8859的編碼表中，編號0~127與ASCII保持兼容，編號128~159共32個編碼保留給擴充定義的32個 擴充控制碼，160為空格，161~255的95個數(shù)字用于新增加的字符代碼。由于在一張碼表中只能增加95種字符的代碼，因此ISO8859實際上不是 一張碼表，而是一系列標準，包括14個字符碼表。例如，西歐的常用字符就包含在ISO8859-1字符表中，在ISO8859-7中則包含了ASCII和 現(xiàn)代希臘語字符。
3）、GB2312和GBK
GB2312是中國國家標準漢字信息交換用編碼，簡稱國標碼，標準號為GB2312-80。
中國的文字不是拼音文字，漢字的個數(shù)的數(shù)萬之多，遠遠超過區(qū)區(qū)256個字符，ISO8859無能為力，但是通過借鑒ISO8859的編碼思想，研 究人員解決了中文的編碼問題。GB2312使用兩個字節(jié)來表示一個中文，在每個字符的256種可能中，為了與ASCII保持兼容，低于128的我們不使 用。借鑒ISO8859的設計方案，只使用從160以后的96個數(shù)字，兩個字節(jié)分成高位和低位，高位的取值范圍從176~247共72個，低位從 161~254共94個，這樣，兩個字節(jié)就有72*94＝6768種可能，即可表示6768種漢字。
BG2312-80僅收錄了6763個漢字，還有許多漢字沒有被收錄進去，為了對更多的字符進行編碼，全國信息技術化技術委員會于1995年12月1日頒 布了《漢字內碼擴展規(guī)范》，簡稱GBK。在GBK1.0中共收錄了21886個漢字和圖形符號，微軟公司的window95系統(tǒng)的簡體中文版開始即支持 GBK編碼。GBK向下與GB2312完全兼容，向上支持ISO10646國際標準。
（4）、UNICODE
每個國家和地區(qū)都規(guī)定了計算機信息交換編碼，這就造成了不同編碼國家、地區(qū)之間交流上的困難，如果全世界都使用統(tǒng)一的編碼表就好了，為此UNICODE組 織發(fā)布了UNICODE編碼。這種編碼使用雙字節(jié)符號數(shù)對每一個字符進行編碼，在UNICODE3.0.1中包含了49194個字符，將 來，UNICODE中還會增加更多的字符。UNICODE的全稱是“Universal Multiple-Octet Coded Character Set”，簡稱UCS。
（5）、UTF-8
使用UNICODE編碼，一個英文字符也要占據(jù)兩個字節(jié)，對于英文信息而言就增加了一倍數(shù)據(jù)量，為了減少存儲和傳輸英文數(shù)據(jù)的數(shù)據(jù)量，美國人又制定了一系 列用于傳輸和保存UNICODE的編碼標準UTF，這些編碼稱為UCS傳輸格式碼，也就是將UCS的編碼通過一定的轉換來達到使用的目的。常見的有 UTF-7、UTF-8、UTF-16等。其中UTF-8編碼得到了廣泛的應用，UTF-8的全名是UCS Transformation Format 8，即UCS編碼的8位傳輸格式，就是使用單字節(jié)的方式對UCS進行編碼，使UNICODE編碼能夠在單字節(jié)的設備上正常進行處理。
UTF-8編碼是變長的編碼，對不同的UNICODE可能編成不同的長度。
從理論上來說，這些根據(jù)字符集設置而進行的字符轉換不應該產(chǎn)生太多的問題，而事實上由于應用程序的實際運行環(huán)境不同，UNICODE和各個本地字符集的補充、完善以及系統(tǒng)或應用程序實現(xiàn)的不規(guī)范，轉碼時還是會經(jīng)常出現(xiàn)問題而導致亂碼。
2、亂碼產(chǎn)生的原因
Java語言內部是用UNICODE表示字符的，遵守UNICODE V2.0。Java程序無論是以字符流讀/寫磁盤文件，還是向URL轉接寫HTML信息，或從URL連接讀取參數(shù)值，都會由UNICODE作為中介和本地字符編碼進行轉換。
在WEB應用中，瀏覽器、WEB服務器、WEB應用程序和數(shù)據(jù)庫等各個部分都有可能使用不用的字符集，字符在不同的字符集之間進行轉換時，就有可能出現(xiàn)亂碼問題。例如一個中文字符“中”要轉換為ISO-8859-1編碼，在Java中先讀取到的是中文字符的GBK編碼“0xD6D0”，轉換為 UNICODE碼為“0x4E2D”，再從UNICODE編碼轉換ISO-8859-1編碼，如果ISO-8859-1編碼中沒有對應的 “0xD6D0”,于是就得到“0x3F”，也就是我們經(jīng)常在頁面上看到一堆“？”的原因。
在WEB應用中，亂碼可能在多個環(huán)節(jié)產(chǎn)生，下面針對可能出現(xiàn)亂碼的幾個環(huán)節(jié)，給出解決的方案。
3、亂碼解決方案
1）、JSP頁面最基本的亂碼問題
運行下面的代碼，會發(fā)現(xiàn)頁面上出現(xiàn)的是亂碼。
1. <%@ page language="java" pageEncoding="UTF-8"%>
2. <%@ page contentType="text/html; charset=ISO8859-1"%>
3. <html>
4. <head>
5. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6. <title>中文問題</title>
7.
8. <body>
9. </body>
10.</html>
這段代碼產(chǎn)生亂碼的原因在于它有三處設置了編碼格式，但是格式設置的不一致，因此導致了亂碼，下面來分析這三處設置編碼格式的作用。
<%@ page language="java" pageEncoding="UTF-8"%>
此處的pageEncoding="UTF-8"為JSP文件的存儲格式。
<%@ page contentType="text/html; charset=ISO8859-1"%>
此處charset=ISO8859-1為JSP的解碼格式。ISO8859-1是沒有為漢字編碼的，因此按UTF-8編碼存儲的文件如果用 ISO8859-1編碼格式編碼，其中的中文字符就會因為找不到對應的編碼而顯示為亂碼。所以JSP文件的存儲格式和它的解碼格式應該是一致的。
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
此處編碼控制的是瀏覽器的解碼方式，瀏覽器收到的只是一個字節(jié)流，它并不知道
頁面是如何編碼的，因此，需要一個機制來告訴瀏覽器頁面的編碼類型，標準的機制是使用<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">來指定頁面的編碼，當瀏覽器讀取頁面遇到這樣的指示時，將使用這里制定的編碼方式重新加載頁面。
因此只要把三處的都設置為UTF-8或GBK即可解決亂碼問題。
2）、表單使用POST提交方式提交后接收到的是亂碼
WEB容器在內部編碼格式是ISO8859-1，在POST方式提交時，默認的提交編碼格式是ISO8859-1，這樣接收到的中文信息就會是亂碼，解決方式如下：
在請求頁面上開始處，執(zhí)行請求和編碼代碼：
request.setCharacterEncoding(“GBK”);
把提交內容的字符集設為GBK，這樣接受此參數(shù)的頁面就不必再轉碼了，直接使用即可得到漢字參數(shù)。
在每一個接受提交的JSP頁面及Servlet中都加這樣的代碼是比較煩人的，可以用過濾器設置request和response的setCharacterEncoding方法來解決這個問題。
例：過濾器解決問題
1. public class setEncodeingFilter extends HttpServlet implements Filter {
2. private FilterConfig config;
3. @Override
4. public void doFilter(ServletRequest request, ServletResponse response,
5. FilterChain chain) throws IOException, ServletException {
6. request.setCharacterEncoding("GBK");
7. response.setCharacterEncoding("GBK");
8. chain.doFilter(request, response);
9. }
10.
11. @Override
12. public void init(FilterConfig config) throws ServletException {
13. this.config = config;
14. }
15.}
這個過濾器中已經(jīng)在doFilter方法中直接設置了統(tǒng)一使用GBK編碼，然后在web.xml國配置過濾器：
1. <filter>
2. <filter-name>setEncodeingFilter </filter-name>
3. <filter-class>setEncodeingFilter(過濾器的全路徑)</filter-class>
4. </filter>
5. <filter-mapping>
6. <filter-name>setEncodeingFilter </filter-name>
7. <url-pattern>/*</url-pattern>
8. </filter-mapping>
9. <url-pattern>/*</url-pattern>表示所有的頁面都要經(jīng)過此過濾器過濾，這樣就不用在JSP和Servlet中設置encoding了。
3）、表單使用GET方式導致的亂碼的處理方式
如果使用GET方式提交中文，接受參數(shù)的頁面也會出現(xiàn)亂碼，原因是web容器會以GET方式的默認編碼方式ISO8859-1對漢字進行編碼，編 碼后追加到URL，導致接受頁面得到的參數(shù)為亂碼。 因為在進入URL之前已經(jīng)進行了ISO8859-1的編碼處理，所以需要在得到參數(shù)值后進行編碼轉換：
String name = request.getParameter("name");
name = new String(name.getBytes("ISO8859-1"),"GBK");
4）、數(shù)據(jù)庫中讀取和存儲中文時的亂碼問題
大多數(shù)的JDBC驅動都是默認IS-O8859-1為數(shù)據(jù)的傳輸編碼格式，而數(shù)據(jù)庫本身又有自己的字符集，因此在數(shù)據(jù)庫讀寫中文數(shù)據(jù)庫時也經(jīng)常會出現(xiàn)籌碼人。
流行的關系數(shù)據(jù)庫系統(tǒng)都支持數(shù)據(jù)庫Encoding，即在創(chuàng)建數(shù)據(jù)庫時可以指定其自己的字符集設置。數(shù)據(jù)庫的數(shù)據(jù)以指定的編碼形式存儲。當應用程序訪問數(shù)據(jù)時，在入口和出口處都會有Encoding轉換。對于中文數(shù)據(jù)，數(shù)據(jù)庫字符編碼的設置應當保證數(shù)據(jù)的完整性。
GB23212、GBK和UTF-8等都是可選的數(shù)據(jù)庫Encoding，在JSP/Servlet編程時，可以先用數(shù)據(jù)庫管理系統(tǒng)提供的管理功能檢查其中的中文數(shù)據(jù)是否正確。
3.1、解決HTML頁面中的中文問題：
為了使HTML頁面很好地支持中文，就必須在每個HTML頁面的頭部增加如下代碼：
1. <HEAD>
2. ...
3. <META http-equiv=Content-Type content="text/html;charset=GBK">
4. ...
5. <HEAD>
3.2、解決JSP頁面中的中文問題
為了使JSP頁面很好地支持中文，就必須在每個JSP頁面的頭部增加如下代碼：
<%@ page contentType="text/html;charset=GBK" language="java"%>
3.3、解決Servlet響應結果的中文問題
為了使Servlet頁面很好地支持中文，就必須在每個Servlet頁面的頭部增加如下代碼：
response.setCharacterEncoding("GBK");
3.4解決頁面數(shù)據(jù)傳輸?shù)闹形膯栴}
為了使中文數(shù)據(jù)在各頁面（組件）之間正常傳遞，最佳的方法就是采用編碼過濾器來解決。在WEB.XML中配置一個編碼過濾器，內容如下：
1. <!--定義編碼過濾器-->
2.
3. <filter>
4. <filter-name>encodingFilter</filter-name>
5. <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
6. <init-param>
7. <param-name>encoding</param-name>
8. <param-value>GBK</param-value>
9. </init-param>
10.</filter>
11.<filter-mapping>
12. <filter-name>encodingFilter</filter-name>
13. <url-pattern>/*</url-pattern>
14.</filter-mapping>
3.5、解決HTTP(get)請求中的中文問題
在默認情況下，IE瀏覽器發(fā)“ISO-8859-1”的編碼格式發(fā)送請求，如果接收到HTTP的get請求中文參數(shù)時出現(xiàn)亂碼，就可以對其進行編碼轉換，例如：
String param = request.getParameter("param");
param = new String(param.getBytes("ISO-8859-1", "GBK"));
也可以通過修改Tomcat的server.xml文件來解決：
<Connector port = "8080"
.....
URIEncoding="GBK"/> -->增加這項
3.6、解決MySQL數(shù)據(jù)庫的中文問題
解決MySQL數(shù)據(jù)庫中文問題主要在JDBC驅動的URL上，例如：
jdbc:mysql://localhost/test?user=root&password=123456&useUnicode=true&characterEncoding=GBK
3.7、實現(xiàn)加解密過程中，報文是亂碼：設置編碼格式可能有誤。
3.8、在本地測試是正常的，但是發(fā)布到測試環(huán)境后會亂碼的問題
1）可能是編譯不一致，比如，測試環(huán)境要求編譯成1.4版本，而本地編譯的是1.6；
2）可能請求報文的編碼和服務器編碼不同，服務器是UTF-8的編碼，而請求報文是GBK。
該文章在 2023/8/18 11:53:47 編輯過
400 186 1886
