網際網路的的實質大致可以歸結為資料之間的互動，而互動就不得不涉及到資料的編碼解碼轉嗎等等一些問題。

而在實際工作中發現很多開發同事對這些並沒有一個清晰完整的認識，這裡就我目前為止接觸的產品編碼相關做一下全方位的總結。

這裡按照使用者輸入url開啟網頁這一場景的順序進行解析：

1、當在瀏覽器輸入url的時候在瀏覽器端發生了什麼？

url預設使用utf-8，url後帶引數的編碼方面有一個預設編碼的概念，大部分情況下系統預設編碼是utf-8，瀏覽器也會按照系統預設編碼對url後帶的引數進行編碼。

這就會導致一個問題，如果在一個預設編碼不是utf-8的系統下輸入url，且引數中有中文，這是server端解析引數就會出現問題。但是一般是不需要使用者手動輸入url引數的，這個問題可以忽略。如果在頁面中用js或<a>標籤開啟一個url，它的編碼會按照該頁面的編碼設定，也不會存在這個問題。

如果不進行對整個頁面的編碼設定能否保證url的編碼正確呢？這個當然是可以的。

js使用 encodeURI()方法後，url中的某些字元將被十六進位制的轉義序列進行替換，這個替換的本質是二進位制資料的操作，這樣最後得出的字串自然就保留了替換時的編碼方式。server端會自動識別％符號進行解碼。接下來我們到了第二步。

2、在server接收到字串的時候發生了什麼？

上面提到了，當server端發現url資料流中包含％符號的時候會自動將資料流解碼成二進位制資料流，這之後還需要一個過程才能得到我們的中文字元，那就是用預設編碼進行解碼，很多時候是utf-8，但很多都不是，所以需要對server進行進行設定。

tomcat是修改server.xml檔案，

              <Connector port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" URIEncoding="UTF-8" />

這樣在容器解析url的時候使用utf-8的編碼方式。

大家肯定見過 request.setCharacterEncoding("UTF-8"); 這一方法，但它和上面的區別是它只能控制程式中POST方法提交的引數的解碼方式，且它只能在引數被訪問之前設定，訪問後設置無效，因為容器會自動讀取預設編碼對引數進行解析。這麼看最根本的方法還是將預設編碼統一掉。

3、頁面上是如何設定編碼方式的？

html是在瀏覽器端解析的，所以只要在檔案頭部加

<metahttp-equiv="Content-Type"content="text/html; charset=utf-8"/> 標籤就可以對瀏覽器讀取該檔案的編碼方式進行設定，當然如果是在這個標籤之前的內容瀏覽器會使用預設編碼，因為一般頭部都是一些純英文字元，即使用GBK編碼讀取也是沒有問題的。該頁面包含的所有js、css檔案也都會按照html檔案的編碼方式解析。

這個規則無論是對jsp、php、ejs、還是jsx都是有效的:p

當然其中在server端執行的部分還是根據server的預設解碼進行，比如開發過程中IDE會設定預設編碼，直譯器自然會根據預設編碼對程式碼進行解析。比如java將字串轉為unicode。

4、資料庫編碼方式的的設定

這個比較簡單，基本上所有種類的資料庫管理軟體都可以進行選擇設定。