java字符編碼

 

• 位（bit）：計算機存儲信息的最小單位,音譯比特，0和1兩個值

字節(Byte)：8個bit一字節，在ASCII碼中，一個標準英文字母（不分大小寫）佔一個字節位置，一個標準漢字佔二個字節位置。
平常生活說的好比：1M光纖寬帶,指的是1024*1024"位"(bit)而不是否是"字節"(Byte).
可是文件大小說的是"字節"(Byte),如文件大小是1M,是1024*1024 字節(Byte)
因此若是大家家安裝了電信的100M光纖寬帶：下載電影速度的理論極限是:100/8=12.5M(字節)
字符：計算機中使用的全部文字和符號，在不一樣的編碼中，一個字符所佔的字節大小是不同的。
如在ASCII碼中，一個標準英文字母（不分大小寫）佔一個字節位置，一個標準漢字佔二個字節位置。

• ASCII碼 全名是American Standard Code for Information Interchange， 叫作「美國信息交換標準碼」

只有0~127個字符
0~31 是控制字符
32~127是打印字符
詳見 ascii表

• ANSI碼 American National Standard Institite，美國國家標準協會

ANSI編碼是一種對ASCII碼的拓展：ANSI編碼用0x00~0x7f 範圍的1 個字節來表示 1 個英文字符，超出一個字節的 0x80~0xFFFF 範圍來表示其餘語言的其餘字符。也就是說，ANSI碼僅在前126個與ASCII碼相同，以後的字符全是某個國家語言的全部字符。值得注意的是，兩個字節最多能夠存儲的字符數目是2的16次方，即65536個字符，這對於一個語言的字符來講，絕對夠了。還有ANSI編碼其實包括不少編碼：中國製定了GB2312編碼，用來把中文編進去另外，日本把日文編到Shift_JIS裏，韓國把韓文編到Euc-kr裏，各國有各國的標準。受制於當時的條件，不一樣語言之間的ANSI碼之間不能互相轉換，這就會致使在多語言混合的文本中會有亂碼。

• Unicode編碼

爲了解決不一樣國家ANSI編碼的衝突問題，Unicode應運而生：若是全世界每個符號都給予一個獨一無二的編碼，那麼亂碼問題就會消失。這就是Unicode，就像它的名字都表示的，這是一種全部符號的編碼。
Unicode標準也在不斷髮展，但最經常使用的是用兩個字節表示一個字符（若是要用到很是偏僻的字符，就須要4個字節）。現代操做系統和大多數編程語言都直接支持Unicode。
java程序中(內存中)全部的char、String(char數組)都是unicode編碼，如「中」字unicode編碼是 '\u4e2d'是一個16進制的數字，轉成10進制是 20013

• utf-8編碼

Unicode已經能夠包含全部國家和地區的文字和符號，爲何還須要utf-8呢？
本來能夠用一個字節存儲的英文字母在Unicode裏面必須存兩個字節（規則就是在原來英文字母對應ASCII碼前面補0），這就產生了浪費。utf-8是用來減小浪費的。
utf-8編碼一種變長的編碼方式：它可使用1~4個字節表示一個符號，根據不一樣的符號而變化字節長度，當字符在ASCII碼的範圍時，就用一個字節表示，保留了ASCII字符一個字節的編碼作爲它的一部分，如此一來UTF-8編碼也能夠是爲視爲一種對ASCII碼的拓展。值得注意的是unicode編碼中一箇中文字符佔2個字節，而UTF-8一箇中文字符佔3個字節。從unicode到uft-8並非直接的對應，而是要過一些算法和規則來轉換。

• gb2312和gbk編碼

gb2312能夠認爲是ANSI碼的一種實現，是對ascii的一個擴展，gbk是對gb2312的擴展

 

GBK、GB2312等與UTF8之間都必須經過Unicode編碼才能相互轉換

在計算機內存中，統一使用Unicode編碼，當須要保存到硬盤或者須要傳輸的時候，就轉換爲UTF-8或者GBK等編碼。
用記事本編輯的時候，從文件讀取的UTF-8或者GBK字符被轉換爲Unicode字符到內存裏，編輯完成後，保存的時候再把Unicode轉換爲UTF-8或者GBK保存到文件。

iso8859-1：屬於單字節編碼，最多能表示的字符範圍是0-255

java中的編碼問題
http://www.cnblogs.com/zj0208/p/7019102.html

字符編碼ANSI和ASCII區別、Unicode和UTF-8區別
https://blog.csdn.net/xiangxianghehe/article/details/77574965

URLEncode和URLDecode
request.getParameter("name")
request.setCharacterEncoding("字符集") //這裏設置的字符集合，只到post請求生效，對get請求無效

get請求

瀏覽器端：get請求？號後含有 非ascaii編碼的字符(若是中文，特殊字符等)，瀏覽器 在發送請求時會先 URL encode這些字符(以什麼編碼encode和瀏覽器有關)
這樣，整個url就符合url規範了，而後以iso-8859-1的編碼方式轉換成二進制隨着請求頭一塊兒發送出去。
服務器端（tomcat）是如何將數據獲取到進行解碼的

服務端能夠設置默認的編碼格式。不設置默認爲 iso-8859-1， 不建議設置。
<Connector port="8080" protocol="HTTP/1.1" maxThreads="150" connectionTimeout="20000" redirectPort="8443" URIEncoding="GBK"/>

post請求
在post方法裏所要傳送的數據也要URL encode，那麼他是用什麼編碼方式的呢？
在form所在的html文件裏若是有段<meta http-equiv="Content-Type" content="text/html; charset=字符集（GBK，utf-8等）"/>，那麼post就會用此處指定的編碼方式編碼。通常你們都認爲這段代碼是爲了讓瀏覽器知道用 什麼字符集來對網頁解釋，因此網站都會把它放在html代碼的最前端，儘可能不出現亂碼，其實它還有個做用就是指定form表單的post方法提交數據的 URL encode編碼方式。從這裏能夠看出對於get方法來數，瀏覽器對數據的URL encode的編碼方式是有瀏覽器設置來決定，（能夠用js作統一指定），而post方法，開發人員能夠指定。

服務端 request.setCharacterEncoding("字符集") 就會起做用了。