在介紹字符集以前,咱們先了解下爲何要有字符集?java
咱們在計算機屏幕上看到的是實體化的文字,而在計算機存儲介質中存放的實際是二進制的比特流。那麼在這二者之間的轉換規則就須要一個統一的標準,不然把咱們的U盤插到老闆的電腦上,文檔就亂碼了;小夥伴QQ上傳過來的文件,在咱們本地打開又亂碼了。因而爲了實現轉換標準,各類字符集標準就出現了。數據庫
什麼是字符集?數組
簡單的說字符集就規定了某個文字對應的二進制數字存放方式(編碼)和某串二進制數值表明了哪一個文字(解碼)的轉換關係。瀏覽器
那麼爲何會有那麼多字符集標準呢?markdown
這個問題實際很是容易回答。問問本身爲何咱們的插頭拿到英國就不能用了呢?爲何顯示器同時有DVI,VGA,HDMI,DP這麼多接口呢?不少規範和標準在最初制定時並不會意識到這將會是之後全球普適的準則,或者處於組織自己利益就想從本質上區別於現有標準。因而,就產生了那麼多具備相同效果但又不相互兼容的標準了。網絡
字符集只是一個規則集合的名字,對應到真實生活中,字符集就是對某種語言的稱呼。測試
例如:英語,漢語,日語。對於一個字符集來講要正確編碼轉碼一個字符須要三個關鍵元素:字庫表(character repertoire)、編碼字符集(coded character set)、字符編碼(character encoding form)。其中字庫表是一個至關於全部可讀或者可顯示字符的數據庫,字庫表決定了整個字符集可以展示表示的全部字符的範圍。編碼字符集,即用一個編碼值code point來表示一個字符在字庫中的位置。字符編碼,將編碼字符集和實際存儲數值之間的轉換關係。通常來講都會直接將code point的值做爲編碼後的值直接存儲。例如在ASCII中A在表中排第65位,而編碼後A的數值是0100 0001也即十進制的65的二進制轉換結果。網站
ASCII碼是7位編碼,編碼範圍是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯數字和標點符號等字符。其中0x00-0x20和0x7F共33個控制字符。編碼
只支持ASCII碼的系統會忽略每一個字節的最高位,只認爲低7位是有效位。HZ字符編碼就是早期爲了在只支持7位ASCII系統中傳輸中文而設計的編碼。早期不少郵件系統也只支持ASCII編碼,爲了傳輸中文郵件必須使用BASE64或者其餘編碼方式。插件
GB2312是基於區位碼設計的,區位碼把編碼表分爲94個區,每一個區對應94個位,每一個字符的區號和位號組合起來就是該漢字的區位碼。區位碼通常 用10進制數來表示,如1601就表示16區1位,對應的字符是「啊」。在區位碼的區號和位號上分別加上0xA0就獲得了GB2312編碼。
區位碼中01-09區是符號、數字區,16-87區是漢字區,10-15和88-94是未定義的空白區。它將收錄的漢字分紅兩級:第一級是經常使用漢字計 3755個,置於16-55區,按漢語拼音字母/筆形順序排列;第二級漢字是次經常使用漢字計3008個,置於56-87區,按部首/筆畫順序排列。一級漢字 是按照拼音排序的,這個就能夠獲得某個拼音在一級漢字區位中的範圍,不少根據漢字能夠獲得拼音的程序就是根據這個原理編寫的。
GB2312字符集中除經常使用簡體漢字字符外還包括希臘字母、日文平假名及片假名字母、俄語西裏爾字母等字符,未收錄繁體中文漢字和一些生僻字。能夠用繁體漢字測試某些系統是否是隻支持GB2312編碼。
GB2312的編碼範圍是0xA1A1-0x7E7E,去掉未定義的區域以後能夠理解爲實際編碼範圍是0xA1A1-0xF7FE。
EUC-CN能夠理解爲GB2312的別名,和GB2312徹底相同。
區位碼更應該認爲是字符集的定義,定義了所收錄的字符和字符位置,而GB2312及EUC-CN是實際計算機環境中支持這種字符集的編碼。HZ和ISO- 2022-CN是對應區位碼字符集的另外兩種編碼,都是用7位編碼空間來支持漢字。區位碼和GB2312編碼的關係有點像 Unicode和UTF-8。
GBK編碼是GB2312編碼的超集,向下徹底兼容GB2312,同時GBK收錄了Unicode基本多文種平面中的全部CJK漢字。同 GB2312同樣,GBK也支持希臘字母、日文假名字母、俄語字母等字符,但不支持韓語中的表音字符(非漢字字符)。GBK還收錄了GB2312不包含的 漢字部首符號、豎排標點符號等字符。
GBK的總體編碼範圍是爲0x8140-0xFEFE,不包括低字節是0×7F的組合。高字節範圍是0×81-0xFE,低字節範圍是0x40-7E和0x80-0xFE。
低字節是0x40-0x7E的GBK字符有必定特殊性,由於這些字符佔用了ASCII碼的位置,這樣會給一些系統帶來麻煩。
有些系統中用0x40-0x7E中的字符(如「|」)作特殊符號,在定位這些符號時又沒有判斷這些符號是否是屬於某個 GBK字符的低字節,這樣就會形成錯誤判斷。在支持GB2312的環境下就不存在這個問題。須要注意的是支持GBK的環境中小於0x80的某個字節未必就 是ASCII符號;另外就是最好選用小於0×40的ASCII符號作一些特殊符號,這樣就能夠快速定位,且不用擔憂是某個漢字的另外一半。Big5編碼中也 存在相應問題。
CP936和GBK的有些許差異,絕大多數狀況下能夠把CP936看成GBK的別名。
每一種語言的不一樣的編碼頁,增長了那些須要支持不一樣語言的軟件的複雜度。於是人們制定了一個世界標準,叫作unicode。unicode爲每一個字符提供 了惟一的特定數值,不論在什麼平臺上、不論在什麼軟件中,也不論什麼語言。也就是說,它世界上使用的全部字符都列出來,並給每個字符一個惟一特定數值。
Unicode的最初目標,是用1個16位的編碼來爲超過65000字符提供映射。但這還不夠,它不能覆蓋所有歷史上的文字,也不能解決傳輸的問題 (implantation head-ache’s),尤爲在那些基於網絡的應用中。已有的軟件必須作大量的工做來程序16位的數據。
所以,Unicode用一些基本的保留字符制定了三套編碼方式。它們分別是UTF-8,UTF-16和UTF-32。正如名字所示,在UTF-8中, 字符是以8位序列來編碼的,用一個或幾個字節來表示一個字符。這種方式的最大好處,是UTF-8保留了ASCII字符的編碼作爲它的一部分,例如,在 UTF-8和ASCII中,「A」的編碼都是0x41.
UTF-16和UTF-32分別是Unicode的16位和32位編碼方式。考慮到最初的目的,一般說的Unicode就是指UTF-16。在討論Unicode時,搞清楚哪一種編碼方式很是重要。
Unicode Transformation Format-8bit,容許含BOM,但一般不含BOM。是用以解決國際上字符的一種多字節編碼,它對英文使用8位(即一個字節),中文使用24爲(三 個字節)來編碼。UTF-8包含全世界全部國家須要用到的字符,是國際編碼,通用性強。UTF-8編碼的文字能夠在各國支持UTF8字符集的瀏覽器上顯 示。如,若是是UTF8編碼,則在外國人的英文IE上也能顯示中文,他們無需下載IE的中文語言支持包。
GBK的文字編碼是用雙字節來表示的,即不論中、英文字符均使用雙字節來表示,爲了區分中文,將其最高位都設定成1。GBK包含所有中文字符,是國家編碼,通用性比UTF8差,不過UTF8佔用的數據庫比GBD大。
GBK、GB2312等與UTF8之間都必須經過Unicode編碼才能相互轉換:
GBK、GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
對於一個網站、論壇來講,若是英文字符較多,則建議使用UTF-8節省空間。不過如今不少論壇的插件通常只支持GBK。 unicode是字符集,ASCII、GB23十二、GBK、GB18030既是字符集也是編碼方式,UTF-8只是編碼方式。
ISO-8859-1:單字節編碼,不能顯示中文;
GB2312/GBK:專門表示漢字,雙字節編碼,
gbk表示簡體字和繁體字, gb2312只能表示簡體字
unicode:最統一的編碼,能夠用來表示全部語言的字符,並且是定長雙字節編碼,不兼容那iso-8859-1,也不兼容任何編碼。
Java中經常使用的編碼轉換
1)getBytes(charset):將字符串以字節方式表示,注意字符串在java內存中老是按unicode編碼存儲;
2)new String(charset):將字節數組按照charset編碼進行組合識別,最後轉成unicode存儲;
Java中注意問題
1)request請求默認的是編碼是iso-8859-1
2)iso-8859-1是java網絡傳輸使用的標準字符集