一、編碼進程

【01編碼】——很久很久以前，為了表示二極管的通、分，我們引入的高電平、低電平，之后又引入的1、0編碼進行代替。

【ASCII編碼】——很久以前，也就是上個世紀60年代，美國佬為了把計算機的“0101010”編碼與文字進行對應起來，制定了一套ASCII編碼方案。人總是自私的，他只對自己的語言進行編碼，26個字母、數字、其他符號，只用了7位二進制數搞定，第一位用0表示，預留著。所以ASCII編碼最多127編碼。

【“二代”ASCII編碼】——不單單是美國佬想把計算機語言和英文聯系起來，其他國家也想把自己的語言關聯起來，我法文、俄文就基于ASCII編碼，利用上ASCII第一位(未使用)變成1，來對自己國家的語言進行編碼。

介樣，每一個國家都基于ASCII，讓第一位變成1，完成對本國的語言的編碼。由于他們各干各的，沒有溝通，從而導致了同一種編碼出現不同的文字。

【gb2312碼】——我們偉大的祖國80年代也開始對漢字進行編碼，由于我們的文字較多，即使是基于ASCII將第一位變成1，也不夠我們使用（國語博大精深拉），所以就制定了一套gb2312編碼，使用2個字節表示。

【BIG5編碼】——我國的港澳地區，他們是使用繁體字（gb2312編碼最初并沒有考慮到繁體字），怎么辦了？他們就出了自己的區域編碼BIG5

【中國一統GBK編碼】——為了統一漢字，迫切的需要設計出一種既能支持簡體字又能表示繁體的新編碼方案，GBK誕生了！他兼容了絕大部分gb2312編碼（gb2312編碼的文字用gbk可以讀出來，但是不兼容BIG5編碼）

【世界大統unicode編碼】——各國編碼各做各的，總不是意見好事，為了便于交流，國際社會引入了unicode——（uni統一的意思，code編碼）把所有國家的文字都進行了編碼。

【統一后浪費空間問題】——統一是一件好事，但是也是有問題的。英文只要1個字節ASCII編碼就可以表示，你unicode還需要2個字節或更多，導致unicode表示英文的時候前面有很多無用的000000000000000000，對吧。

【解決問題，UTF編碼】——解決方法是使用utf8編碼，它是基于unicode編碼上的一種優化，英文使用1個字節，中文使用2、3個（絕大部分是3個，個別有看到2、4個的一般不用）字節。好處：我能屈能伸，我可以變化長度來保存，就不會浪費空間了吧。

來看看unicode和utf對應吧

<!--[if !supportLists]-->·         <!--[endif]-->0000 0000-0000 007F | 0xxxxxxx

<!--[if !supportLists]-->·         <!--[endif]-->0000 0080-0000 07FF | 110xxxxx 10xxxxxx

<!--[if !supportLists]-->·         <!--[endif]-->0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

<!--[if !supportLists]-->·         <!--[endif]-->0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

舉例說明：

漢      Unicode        utf8

        0x6c49         0xe6b189

二、java編程的轉碼

   1、JVM內存中保存的文字編碼

       從源文件àclass文件過程中的轉碼情況。最終的class文件都是以unicode編碼的，我們前面所做的工作就是把各種不同的編碼轉換為unicode編碼，比如從GBK轉換為unicode,從UTF-8轉換為unicode。因為只有采用正確的編碼來轉碼才能保證不出現亂碼。Jvm在運行時其內部都是采用unicode編碼的，其實在輸出時，又會做一次編碼的轉換。

比如：Sysout.out.println(“我們”)。經過正確的解碼后”我們”是unicode保存在內存中的，但是在向標準輸出(控制臺)輸出時，jvm又做了一次轉碼，它會采用操作系統默認編碼(中文操作系統是GBK)，將內存中的unicode編碼轉換為GBK編碼，然后輸出到控制臺。

參考文獻：http://www.blogjava.net/zhangchao/archive/2011/05/26/351051.html

   2、愛也getBytes，恨也getBytes

       一般我們是通過getBytes來進行編碼，如下

         public byte[] getBytes(String charsetName)       //使用規定的編碼

         public byte[] getBytes(Charset charset) //使用規定的編碼

         public byte[] getBytes() //使用啟動JVM設置的編碼（如果沒有設置一般是系統默認編碼），避免使用，默認編碼和平臺有關

    一般我們通過new String來進行解碼，如下

       public String(byte bytes[], String charsetName)        

                  public String(byte bytes[], Charset charset)

                  public String(byte bytes[])

    原則1：使用某一種編碼集對文字進行編碼，就得使用同一種編碼集進行解碼

       比如：“漢”是在java文件中的，此java文件是utf-8或者gbk編碼的

         getBytes使用utf-8編碼，new String使用utf-8解密

    原則2：看清楚對方給你的是什么編碼，使用逆過程進行編碼、解碼（像出棧操作），最終得到你想要文字

    比如：對方進行了如下操作，將“漢”進行utf-8編碼，然后使用iso8859-1進行解碼生成對應的文字：，最后通過文本發送給你。對方可能的操作應該是：

         String x = new String("漢".getBytes("utf-8"), "iso8859-1");

         我們需要對文本中文字x：進行iso8859-1編碼，得到的是“漢”utf-8的譯碼，然后我們在對“漢”進行解碼得到其utf8的文字

    原則3：慎用getBytes()，他是基于平臺的，你得看看JVM啟動的時候file.encoding這個屬性值到底是什么（請注意tomcat的啟動JVM時候設置的編碼）

    源碼：特別注意黃底部分

-Dfile.encoding解釋：
在命令行中輸入java，在給出的提示中會出現-D的說明：
-D<name>=<value>
set a system property
-D后面需要跟一個鍵值對，作用是通過命令行向java虛擬機傳遞一項系統屬性
對-Dfile.encoding=UTF-8來說就是設置系統屬性file.encoding為UTF-8

在java.nio.charset包中的Charset.java中。這段話的意思說的很明確了，簡單說就是默認字符集是在java虛擬機啟動時決定的，后面無法動態改變了。默認字符集就是從file.encoding這個屬性中獲取的。

參考文獻：http://www.cnblogs.com/vigarbuaa/archive/2012/04/11/2442582.html

三、url網址的編碼規范

一、url編碼規范

一般來說，URL只能使用英文字母、阿拉伯數字和某些標點符號，不能使用其他文字和符號。比如，世界上有英文字母的網址“http://www.abc.com”，但是沒有希臘字母的網址“http://www.aβγ.com”（讀作阿爾法-貝塔-伽瑪.com）。這是因為網絡標準RFC 1738做了硬性規定：

"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."

“只有字母和數字[0-9a-zA-Z]、一些特殊符號“$-_.+!*'(),”[不包括雙引號]、以及某些保留字，才可以不經過編碼直接用于URL。”

這意味著，如果URL中有漢字，就必須編碼后使用。但是麻煩的是，RFC 1738沒有規定具體的編碼方法，而是交給應用程序（瀏覽器）自己決定。這導致“URL編碼”成為了一個混亂的領域。

參考文獻：http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

四、瀏覽器的編碼

下面就讓我們看看，“URL編碼”到底有多混亂。我會依次分析四種不同的情況，在每一種情況中，瀏覽器的URL編碼方法都不一樣。把它們的差異解釋清楚之后，我再說如何用Javascript找到一個統一的編碼方法。

情況1：網址路徑中包含漢字

打開IE（我用的是8.0版），輸入網址“http://zh.wikipedia.org/wiki/春節”。注意，“春節”這兩個字此時是網址路徑的一部分。

查看HTTP請求的頭信息，會發現IE實際查詢的網址是“http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82”。也就是說，IE自動將“春節”編碼成了“%E6%98%A5%E8%8A%82”。

我們知道，“春”和“節”的utf-8編碼分別是“E6 98 A5”和“E8 8A 82”，因此，“%E6%98%A5%E8%8A%82”就是按照順序，在每個字節前加上%而得到的。（具體的轉碼方法，請參考我寫的《字符編碼筆記》。）

在Firefox中測試，也得到了同樣的結果。所以，結論1就是，網址路徑的編碼，用的是utf-8編碼。

情況2：查詢字符串包含漢字

在IE中輸入網址“http://www.baidu.com/s?wd=春節”。注意，“春節”這兩個字此時屬于查詢字符串，不屬于網址路徑，不要與情況1混淆。

查看HTTP請求的頭信息，會發現IE將“春節”轉化成了一個亂碼。

切換到十六進制方式，才能清楚地看到，“春節”被轉成了“B4 BA BD DA”。

我們知道，“春”和“節”的GB2312編碼（我的操作系統“Windows XP”中文版的默認編碼）分別是“B4 BA”和“BD DA”。因此，IE實際上就是將查詢字符串，以GB2312編碼的格式發送出去。

Firefox的處理方法，略有不同。它發送的HTTP Head是“wd=%B4%BA%BD%DA”。也就是說，同樣采用GB2312編碼，但是在每個字節前加上了%。

所以，結論2就是，查詢字符串的編碼，用的是操作系統的默認編碼。(我使用谷歌瀏覽器，他會是使用utf-8編碼的)

情況3：Get方法生成的URL包含漢字

前面說的是直接輸入網址的情況，但是更常見的情況是，在已打開的網頁上，直接用Get或Post方法發出HTTP請求。

根據臺灣中興大學呂瑞麟老師的試驗，這時的編碼方法由網頁的編碼決定，也就是由HTML源碼中字符集的設定決定。

<meta http-equiv="Content-Type" content="text/html;charset=xxxx">

如果上面這一行最后的charset是UTF-8，則URL就以UTF-8編碼；如果是GB2312，URL就以GB2312編碼。

舉例來說，百度是GB2312編碼，Google是UTF-8編碼。因此，從它們的搜索框中搜索同一個詞“春節”，生成的查詢字符串是不一樣的。

百度生成的是%B4%BA%BD%DA，這是GB2312編碼。

Google生成的是%E6%98%A5%E8%8A%82，這是UTF-8編碼。

所以，結論3就是，GET和POST方法的編碼，用的是網頁的編碼。

參考文獻：http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

五、網頁、js編碼

情況4：Ajax調用的URL包含漢字

前面三種情況都是由瀏覽器發出HTTP請求，最后一種情況則是由Javascript生成HTTP請求，也就是Ajax調用。還是根據呂瑞麟老師的文章，在這種情況下，IE和Firefox的處理方式完全不一樣。

舉例來說，有這樣兩行代碼：

url = url + "?q=" +document.myform.elements[0].value; // 假定用戶在表單中提交的值是“春節”這兩個字

http_request.open('GET', url, true);

那么，無論網頁使用什么字符集，IE傳送給服務器的總是“q=%B4%BA%BD%DA”，而Firefox傳送給服務器的總是“q=%E6%98%A5%E8%8A%82”。也就是說，在Ajax調用中，IE總是采用GB2312編碼（操作系統的默認編碼），而Firefox總是采用utf-8編碼。這就是我們的結論4。

六、Javascript函數：escape()

好了，到此為止，四種情況都說完了。

假定前面你都看懂了，那么此時你應該會感到很頭痛。因為，實在太混亂了。不同的操作系統、不同的瀏覽器、不同的網頁字符集，將導致完全不同的編碼結果。如果程序員要把每一種結果都考慮進去，是不是太恐怖了？有沒有辦法，能夠保證客戶端只用一種編碼方法向服務器發出請求？

回答是有的，就是使用Javascript先對URL編碼，然后再向服務器提交，不要給瀏覽器插手的機會。因為Javascript的輸出總是一致的，所以就保證了服務器得到的數據是格式統一的。

Javascript語言用于編碼的函數，一共有三個，最古老的一個就是escape()。雖然這個函數現在已經不提倡使用了，但是由于歷史原因，很多地方還在使用它，所以有必要先從它講起。

實際上，escape()不能直接用于URL編碼，它的真正作用是返回一個字符的Unicode編碼值。比如“春節”的返回結果是%u6625%u8282，也就是說在Unicode字符集中，“春”是第6625個（十六進制）字符，“節”是第8282個（十六進制）字符。

它的具體規則是，除了ASCII字母、數字、標點符號“@ * _ + - . /”以外，對其他所有字符進行編碼。在\u0000到\u00ff之間的符號被轉成%xx的形式，其余符號被轉成%uxxxx的形式。對應的解碼函數是unescape()。

所以，“Hello World”的escape()編碼就是“Hello%20World”。因為空格的Unicode值是20（十六進制）。

還有兩個地方需要注意。

首先，無論網頁的原始編碼是什么，一旦被Javascript編碼，就都變為unicode字符。也就是說，Javascipt函數的輸入和輸出，默認都是Unicode字符。這一點對下面兩個函數也適用。

其次，escape()不對“+”編碼。但是我們知道，網頁在提交表單的時候，如果有空格，則會被轉化為+字符。服務器處理數據的時候，會把+號處理成空格。所以，使用的時候要小心。

七、Javascript函數：encodeURI()

encodeURI()是Javascript中真正用來對URL編碼的函數。

它著眼于對整個URL進行編碼，因此除了常見的符號以外，對其他一些在網址中有特殊含義的符號“; / ? : @ & = + $ , #”，也不進行編碼。編碼后，它輸出符號的utf-8形式，并且在每個字節前加上%。

它對應的解碼函數是decodeURI()。

需要注意的是，它不對單引號'編碼。

八、Javascript函數：encodeURIComponent()

最后一個Javascript編碼函數是encodeURIComponent()。與encodeURI()的區別是，它用于對URL的組成部分進行個別編碼，而不用于對整個URL進行編碼。

因此，“; / ? : @ & = + $ , #”，這些在encodeURI()中不被編碼的符號，在encodeURIComponent()中統統會被編碼。至于具體的編碼方法，兩者是一樣。

它對應的解碼函數是decodeURIComponent()。

參考文獻：http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

九、tomcat容器的編碼

   1、啟動tomcat容器時的編碼

    在第二節中，說道：慎用getBytes()，他是基于平臺的，tomcat中JVM啟動的時候file.encoding這個屬性值到底是什么，由誰決定？

    如果你像上面這樣告訴JVM，啟動我tomcat容器的時候，使用GBK來編碼，后續的getBytes返回的就是GBK編碼的東西，這點特別在部署的tomcat的時候注意。

   2、tomcat對表單中get提交的數據，出亂碼看哪里？

    get提交的tomcat從4.x之后不是使用request.setCharacterEncoding("字符集"),從這里獲取，它直接使用直接對參數進行編碼，這個編碼他是從tomcat的配置文件中獲取<Connector port="8080" protocol="HTTP/1.1" maxThreads="150" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/> 

   3、tomcat對表單中post提交的數據，出亂碼看哪里？

    對于post需要在web.xml里面配置攔截器，主要是在程序第一次從request里面獲取參數之前把request給設定了具體的編碼

 還有一點需要注意的是：你在web.xml里面配置過濾器的優先級是不是最高，一定要在request出現之前攔截。

   4、tomcat對jsp頁面的編碼，看哪里？

    你還記得jsp頁面中有下面這句話么？pageEncoding="utf-8"告訴tomcat，你編譯我jsp文件的時候使用他來編譯，如果這句話沒有，他默認使用charset=utf-8"這句話來編譯，同時注意保存jsp的時候使用編碼也應該與pageEncoding="utf-8"保持一致

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>

   你還記得下面這句話么？由他來告訴瀏覽器使用什么編碼的

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

十、mysql數據庫的編碼

1、查看數據庫編碼

需要以root用戶身份登陸才可以查看數據庫編碼方式(以root用戶身份登陸的命令為：

>mysql -u root –p,之后兩次輸入root用戶的密碼)，查看數據庫的編碼方式命令為:

 >show variables like 'character%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

從以上信息可知數據庫的編碼為latin1，需要修改為gbk或者是utf8；

其中，character_set_client為客戶端編碼方式；character_set_connection為建立連接使用的編碼；character_set_database數據庫的編碼；

character_set_results結果集的編碼；

character_set_server數據庫服務器的編碼；

只要保證以上四個采用的編碼方式一樣，就不會出現亂碼問題。

2、更改數據庫編碼

停止MySQL的運行
/etc/init.d/mysql start (stop) 為啟動和停止服務器

MySQL主配置文件為my.cnf，一般目錄為/etc/mysql

var/lib/mysql/ 放置的是數據庫表文件夾，這里的mysql相當于windows下mysql的date文件夾

當我們需要修改MySQL數據庫的默認編碼時，需要編輯my.cnf文件進行編碼修改,在linux下修改mysql的配置文件my.cnf，文件位置默認/etc/my.cnf文件

找到客戶端配置[client] 在下面添加
default-character-set=utf8 默認字符集為utf8
在找到[mysqld] 添加
default-character-set=utf8 默認字符集為utf8
init_connect='SET NAMES utf8' （設定連接mysql數據庫時使用utf8編碼，以讓mysql數據庫為utf8運行）

3、改了之后，為什么win里面cmd中的那個console控制臺還是顯示亂碼了？

         Mysql通過客戶端發送到控制臺展示之前是utf8，但是console是使用系統的默認編碼（gbk），所以在中文的時候發生了亂碼顯示，但是不影響程序操作，只是顯示的時候有問題。

         如何解決了？

         方法一：（只對當前窗口有用，推薦使用）

         方法二：將控制臺展示編碼改成utf8（對所有的窗口，不推薦）