字元格式(gbk utf8等)

2021-07-31 22:41:41 字數 3620 閱讀 6926

gbk就是在儲存你的帖子的時候,乙個漢字占用兩個位元組。。外國人看會出現亂碼,此為我中華為自己漢字編碼而形成之解決方案。

utf8就是在儲存你的帖子的時候,乙個漢字占用3個位元組。。但是外國人看的話不會亂碼,此為西人為了解決多位元組字元而形成之解決方案。

ascii(iso-8859-1)是鼻祖,最簡單的方式,位元組高位為0

gb2312、gbk、gb18030,這幾個是中文編碼方式,並向下相容。gb2312包含7000多個漢字和字元,gbk包含21000多個,gb18030更厲害,到了27000多個。他們都是用2個位元組來表示乙個漢字。跟ascii是怎麼區分的呢?如果高位元組的高位為1(也就是高位元組大於127),就表示是漢字,低位元組並無明顯特徵。

unicode是統一編碼,它建立了乙個全世界統一的碼表。世界上的所有文字,在這張碼表中都是唯一的。

utf-8是unicode的一種儲存、傳輸方式。它將整個unicode碼表分為3部分。

0000 - 007f 這部分是最初的ascii部分,按原始的儲存方式,即0******x。

0080 - 07ff 這部分儲存為110***xx 10******

0800 - ffff 這部分儲存為1110***x 10****** 10******

因此,乙個漢字究竟被儲存為什麼,就需要:先查unicode碼表,然後根據在碼表的位置進行計算。例如:「電」字,在碼表中是3575,計算成utf8就是e794b5,而在gb2312的碼表中為b5e7

utf-8的好處:相容ascii,儲存英文檔案都是單位元組,檔案小。當然,當以存中文為主時就變成了3位元組編碼了,比gb系列還大!如何標明乙個檔案是utf8格式呢?這個標記是可選的:ef bb bf。比如,用windows自帶的記事本建立乙個utf8格式的檔案,就會加上這個標記。但是,如果用ultraedit建立utf8檔案,並不會加上這個標記。這個標記有個術語,叫做bom(byte order mark)。不帶bom的utf8檔案和gb2312檔案怎麼區分呢?我也不知道。唯一能想到的辦法就是:先用一種試,如果出現亂碼,就用另一種再試

utf-16是雙位元組儲存,這就帶來乙個問題,即高低位元組的順序。兩個位元組有兩種順序,它們也用bom來標明。分為大尾碼和小尾碼兩種。大尾碼的bom是feff,小尾碼的bom是fffe

gbk的中文編碼是雙位元組來表示的,英文編碼是用asc||碼表示的,既用單位元組表示。但gbk編碼表中也有英文本元的雙位元組表示形式,所以英文本母可以有2中gbk表示方式。為區分中文,將其最高位都定成1。英文單位元組最高位都為0。當用gbk解碼時,若高位元組最高位為0,則用asc||碼表解碼;若高位元組最高位為1,則用gbk編碼表解碼

至於utf-8編碼則是用以解決國際上字元的一種多位元組編。碼,它對英文使用8位(即乙個位元組),中文使用24位(三個位元組)來編碼。對於英文本元較多的論壇則用utf-8節省空間。

gbk包含全部中文字元,

utf-8則包含全世界所有國家需要用到的字元。

gbk是在國家標準gb2312基礎上擴容後相容gb2312的標準(好像還不是國家標準)

所以,對於英文比較多的論壇 ,使用gbk則每個字元占用2個位元組,而使用utf-8英文卻只佔乙個位元組。

但是如果utf8中出現中文那就是3個位元組~~具體的自己權衡。

各種編碼詳解

ascii 

ascii碼是7位編碼,編碼範圍是0x00-0x7f。ascii字符集包括英文本母、阿拉伯數字和標點符號等字元。其中0x00-0x20和0x7f共33個控制字元。 

只支援ascii碼的系統會忽略每個位元組的最高位,只認為低7位是有效位。hz字元編碼就是早期為了在只支援7位ascii系統中傳輸中文而設計的編碼。早期很多郵件系統也只支援ascii編碼,為了傳輸中文郵件必須使用base64或者其他編碼方式。

gb2312 

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 

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的別名。 

gb18030 

gb18030編碼向下相容gbk和gb2312,相容的含義是不僅字元相容,而且相同字元的編碼也相同。gb18030收錄了所有unicode3.1中的字元,包括中國少數民族字元,gbk不支援的韓文本元等等,也可以說是世界大多民族的文字元號都被收錄在內。 

gbk和gb2312都是雙位元組等寬編碼,如果算上和ascii相容所支援的單位元組,也可以理解為是單位元組和雙位元組混合的變長編碼。gb18030編碼是變長編碼,有單位元組、雙位元組和四位元組三種方式。 

gb18030的單位元組編碼範圍是0x00-0x7f,完全等同與ascii;雙位元組編碼的範圍和gbk相同,高位元組是0x81-0xfe,低位元組的編碼範圍是0x40-0x7e和0x80-fe;四位元組編碼中第

一、三位元組的編碼範圍是0x81-0xfe,二、四位元組是0x30-0x39。

gbk,gb2312以及unicode都既是字符集,也是編碼方式,而utf-8只是編碼方式,並不是字符集

gbk編碼中英文本元只佔乙個位元組

字串編碼轉換 GBK utf8

pagedata 如果網頁編碼是utf 8的,可以這麼轉換為字串 pagesource alloc initwithdata pagedata encoding nsutf8stringencoding 如果網頁是gbk 或者gb2312 用utf8轉換的話,pagesource返回nil。這時需要...

Python字元編碼轉碼之GBK,UTF8互轉

1 須知 在pythonwww.cppcns.com 2中預設編碼是 ascii,而在python 3中預設編碼是 unicode unicode 分為utf 32 佔4個位元組 utf 16 佔兩個位元組 utf 8 佔1 4個位元組 所以utf 16 是最常用的unicode版本,但是在檔案裡存...

PHP 編碼轉化 GBK utf 8

iconv 字串按要求的字元編碼來轉換 iconv有bug 碰到一些生僻字就會無法轉換,當然了配置第二個引數時,可以稍微彌補一下預設缺陷,不至於無法轉換是截斷,用法如下 iconv utf 8 gb2312 ignore data 這樣碰到生僻字轉換失敗時,它就會忽略失敗,繼續轉換下面的內容。ico...