互聯網的的實質大致可以歸結爲數據之間的交互，而交互就不得不涉及到數據的編碼解碼轉嗎等等一些問題。
而在實際工作中發現很多開發同事對這些並沒有一個清晰完整的認識，這裏就我目前爲止接觸的產品編碼相關做一下全方位的總結。
這裏按照用戶輸入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、數據庫編碼方式的的設置
這個比較簡單，基本上所有種類的數據庫管理軟件都可以進行選擇設置。