字符集編碼全方位解析

ascii

最早計算機剛出世時,只有一ascii編碼方式, american strand code for information interchange , ascii 使用7位標識乙個字元, 對於只認識 0 1 的計算機來說, ascii 可以記錄 2^7個字元, 針對歐美國家來說, abc... 再加上一些運算符號 ,ascii足夠用了

但是問題來了,不光是美國,像法國等國家也普及計算機,很快ascii就不夠了

iso-8859-1

於是 iso-8859出現了, 它使用8 位表示乙個字元, 而且完全相容ascii編碼表

iso-8859-1相對於ascii有兩個優點:

iso-8859-1 可以表示 2^8個字元, 對ascii

iso-8859-1使用8位表示乙個字元, 這使得他可以完全使用每個位元組的每一位

然後這還是僅僅對西歐國家而言, 後來計算機普及到了亞洲

gb2312

對我們國家來說,我們同樣需要一種編碼表,讓計算機認識我們的漢字,於是中華人民共和國指定了gb2312 , 國標2312 , 它使用兩個位元組表示乙個漢字, 容納了幾千個常用的漢字

但是問題並沒有打住,gb2312 並沒有包含極少數的生僻字

gbkgbk編碼表彌補了 gb2312並不包含極少數的生僻字的現狀

然而,gbk依然不能表示全部的中國文字

於是:gb18030

gb18030 的擴充套件,使他成為了最完整的漢字的編碼集

但是, 這卻僅僅是對大陸而言

big5

我們的寶島台灣仍然使用繁體字, 他們的編碼表是 big5

隨著計算機的全球化,於是國際標準化組織出現了,他們想統一世界上的編碼方式

unicode

國際標準化組織對全世界的編碼方式進行了彙總, unicode 理論上是可以表示世界上全部的符號的, 它統一使用兩個位元組表示乙個字元, 算算看,他可以表示 256^256個字元

現在unnicode的出現,不再擔心不能表示全所有的字元了,但是問題又來了,對於原來的歐美國家來說, 本來乙個iso-8859-1就夠他們使用的,結果來個unicode, 快取容量急劇上公升,這是個不好的事情, 於是主角來了

utf(unicode translation format)

utf 有三個分支, utf-8 utf-16 utf-32;

其中utf-8使用的變長的位元組表示 , 也就是說,假如是當前的字元是a, 它會使用乙個位元組表示, 假如是漢字,他使用三個位元組表示 .

utf-16和 unicode 一樣的都是使用兩個位元組

utf和unicode的關係 unicode是一種編碼方式,而utf是一種儲存格式

比如說我們的檔案是utf-8這種儲存格式的, 即傳進去的資料都是用utf-8磁碟上檔案都是有自己的儲存格式的, 比如常用的文字檔案的儲存格式都是utf-8如下圖:我們想實現資料從原始檔拷貝到目標檔案

假如原始檔的儲存方式是utf-8, 但是我們使用iso-8859-1對它進行解碼, iso-8859-1碰到乙個位元組就認為他是乙個字元,這顯然和utf-8的動態編碼相衝突, 因此我們解碼得到的結果無異於全是亂碼

緊接著,我們使用iso-8859-1對得到的亂碼,進行編碼,同樣對於iso-8859-1來說,他是認識這些亂碼的,而且iso-8859-1並沒有和utf-8一樣充分了利用了每乙個位元組的每一位,於是它把他們按位編碼會資料原始的狀態

在然後,我們把編碼後的資料寫到用uft-8儲存的目標檔案,對於目標檔案來說,得到的資料就是原始檔中編碼形態故不會出現亂碼

如果我們想用 utf-16型別的編碼器,對 utf-8型別的檔案進行編譯碼呢?結果要麼會報錯,要麼就行出異常malformedinputexception 乙個難看的引數

試想,如果utf-8儲存格式的檔案中, 只有乙個資料 1, 他就是1位元組, 而utf-16預設是兩個位元組, 編碼後的結果也全部是feff0031這樣的, 對於utf-16來說,他是無法對1進行解碼的,直接會報錯

原始檔和目標檔案的儲存格式也要相同,這決定了他們對資料位元組的劃分不同,得到的結果自然不同

出處：https:

字符集編碼全方位解析

微軟WSFC全方位解析

字符集 編碼

字符集編碼

相關推薦

字符集編碼