字符編碼詳解_第1頁
字符編碼詳解_第2頁
字符編碼詳解_第3頁
字符編碼詳解_第4頁
字符編碼詳解_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

每一個程序員都不可避免的遇到字符編碼的問題,特別是做Web開發(fā)的程序員,“亂碼問題”一直是讓人頭疼的問題,也許您已經(jīng)很少遇到“亂碼”問題,然而,對解決亂碼的方法的內(nèi)在原理,您是否明白?本人作為一個程序員,在字符編碼方面同樣遇到不少問題,而且一直對各種編碼懵懵懂懂、不清不楚;在工作中也曾經(jīng)遇到一個很煩人的編碼問題。這兩天在網(wǎng)上收集了大量編碼方面的資料,對字符編碼算是理解的比較清楚了。下面把我認為比較重要的知識點記錄下來,一方面方便以后復習;另一方面也希望給跟我一樣懵懵懂懂的人一個參考。不對或不妥之處,請批評指正。

在此之前,先了解一些有用概念:“字符集”、“字符編碼”和“內(nèi)碼”。1、字符集與字符編碼字符是各種文字和符號的總稱,包括各個國家文字、標點符號、圖形符號、數(shù)字等。字符集是多個字符的集合,字符集種類較多,每個字符集包含的字符個數(shù)不同,常見字符集有:ASCII字符集、ISO8859字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。計算機要準確的處理各種字符集文字,需要進行字符編碼,以便計算機能夠識別和存儲各種文字。

編碼(encoding)和字符集不同。字符集只是字符的集合,不一定適合作網(wǎng)絡傳送、處理,有時須經(jīng)編碼(encode)后才能應用。如Unicode可依不同需要以UTF-8、UTF-16、UTF-32等方式編碼。

字符編碼就是以二進制的數(shù)字來對應字符集的字符。

因此,對字符進行編碼,是信息交流的技術基礎。

使用哪些字符。也就是說哪些漢字,字母和符號會被收入標準中。所包含“字符”的集合就叫做“字符集”。規(guī)定每個“字符”分別用一個字節(jié)還是多個字節(jié)存儲,用哪些字節(jié)來存儲,這個規(guī)定就叫做“編碼”。

各個國家和地區(qū)在制定編碼標準的時候,“字符的集合”和“編碼”一般都是同時制定的。因此,平常我們所說的“字符集”,比如:GB2312,GBK,JIS等,除了有“字符的集合”這層含義外,同時也包含了“編碼”的含義。

注意:Unicode字符集有多種編碼方式,如UTF-8、UTF-16等;ASCII只有一種;大多數(shù)MBCS(包括GB2312)也只有一種。2、什么是內(nèi)碼?2.1維基百科的解釋

在計算機科學及相關領域當中,內(nèi)碼指的是“將資訊編碼后,透過某種方式儲存在特定記憶裝置時,裝置內(nèi)部的編碼形式”。在不同的系統(tǒng)中,會有不同的內(nèi)碼。在以往的英文系統(tǒng)中,內(nèi)碼為ASCII。在繁體中文系統(tǒng)中,目前常用的內(nèi)碼為大五碼(Big5)。在簡體中文系統(tǒng)中,內(nèi)碼則為國標碼(國家標準代碼:現(xiàn)在強制要求使用GB18030標準;較舊計算機仍然使用GB2312)。而統(tǒng)一碼(Unicode)則為另一常見內(nèi)碼。

2.2百度百科的解釋

內(nèi)碼是指整機系統(tǒng)中使用的二進制字符編碼,是溝通輸入、輸出與系統(tǒng)平臺之間的交換碼,通過內(nèi)碼可以達到通用和高效率傳輸文本的目的。比如MSWord中所存儲和調(diào)用的就是內(nèi)碼而非圖形文字。英文ASCII字符采用一個字節(jié)的內(nèi)碼表示,中文字符如國標字符集中,GB2312、GB12345、GB13000皆用雙字節(jié)內(nèi)碼,GB18030(27,533漢字)雙字節(jié)內(nèi)碼漢字為20,902個,其余6,631個漢字用四字節(jié)內(nèi)碼。3、字符編碼分類總結下面從計算機對多國語言支持的角度來總結字符編碼。

3.1ASCII編碼

以下來自“維基百科”:ASCII(AmericanStandardCodeforInformationInterchange,美國信息互換標準代碼)是基于拉丁字母的一套電腦編碼系統(tǒng)。它主要用于顯示現(xiàn)代英語,而其擴展版本EASCII則可以勉強顯示其他西歐語言。它是現(xiàn)今最通用的單字節(jié)編碼系統(tǒng)(但是有被UniCode追上的跡象),并等同于國際標準ISO/IEC646。ASCII第一次以規(guī)范標準的型態(tài)發(fā)表是在1967年,最后一次更新則是在1986年,至今為止共定義了128個字符;其中33個字符無法顯示(這是以現(xiàn)今操作系統(tǒng)為依歸,但在DOS模式下可顯示出一些諸如笑臉、撲克牌花式等8-bit符號),且這33個字符多數(shù)都已是陳廢的控制字符??刂谱址挠猛局饕怯脕聿倏匾呀?jīng)處理過的文字。在33個字符之外的是95個可顯示的字符,包含用鍵盤敲下空白鍵所產(chǎn)生的空白字符也算1個可顯示字符(顯示為空白)。ASCII表:見/zh-cn/ASCII

ASCII缺點:ASCII的最大缺點是只能顯示26個基本拉丁字母、阿拉伯數(shù)目字和英式標點符號,因此只能用于顯示現(xiàn)代美國英語(而且在處理英語當中的外來詞如na?ve、café、élite等等時,所有重音符號都不得不去掉,即使這樣做會違反拼寫規(guī)則)。而EASCII雖然解決了部份西歐語言的顯示問題,但對更多其他語言依然無能為力。因此現(xiàn)在的蘋果電腦已經(jīng)拋棄ASCII而轉用Unicode。

最早的英文DOS操作系統(tǒng)的系統(tǒng)內(nèi)碼是:ASCII。計算機這時候只支持英語,其他語言不能夠在計算機存儲和顯示。

在該階段,單字節(jié)字符串使用一個字節(jié)存放一個字符(SBCS,SingleByteCharacterSystem)。如:"Bob123"占6個字節(jié)。

3.2ANSI編碼

為使計算機支持更多語言,通常使用0x800~xFF范圍的2個字節(jié)來表示1個字符。比如:漢字'中'在中文操作系統(tǒng)中,使用[0xD6,0xD0]這兩個字節(jié)存儲。

不同的國家和地區(qū)制定了不同的標準,由此產(chǎn)生了GB2312,BIG5,JIS等各自的編碼標準。這些使用2個字節(jié)來代表一個字符的各種漢字延伸編碼方式,稱為ANSI編碼。在簡體中文系統(tǒng)下,ANSI編碼代表GB2312編碼,在日文操作系統(tǒng)下,ANSI編碼代表JIS編碼。

不同ANSI編碼之間互不兼容,當信息在國際間交流時,無法將屬于兩種語言的文字,存儲在同一段ANSI編碼的文本中。

中文DOS、中文/日文Windows95/98時代系統(tǒng)內(nèi)碼使用的是ANSI編碼(本地化)

在使用ANSI編碼支持多語言階段,每個字符使用一個字節(jié)或多個字節(jié)來表示(MBCS,Multi-ByteCharacterSystem),因此,這種方式存放的字符也被稱作多字節(jié)字符。比如,"中文123"在中文Windows95內(nèi)存中為7個字節(jié),每個漢字占2個字節(jié),每個英文和數(shù)字字符占1個字節(jié)。

在非Unicode環(huán)境下,由于不同國家和地區(qū)采用的字符集不一致,很可能出現(xiàn)無法正常顯示所有字符的情況。微軟公司使用了代碼頁(Codepage)轉換表的技術來過渡性的部分解決這一問題,即通過指定的轉換表將非Unicode的字符編碼轉換為同一字符對應的系統(tǒng)內(nèi)部使用的Unicode編碼??梢栽凇罢Z言與區(qū)域設置”中選擇一個代碼頁作為非Unicode編碼所采用的默認編碼方式,如936為簡體中文GBK,950為正體中文Big5(皆指PC上使用的)。在這種情況下,一些非英語的歐洲語言編寫的軟件和文檔很可能出現(xiàn)亂碼。而將代碼頁設置為相應語言中文處理又會出現(xiàn)問題,這一情況無法避免。從根本上說,完全采用統(tǒng)一編碼才是解決之道,但目前尚無法做到這一點。代碼頁技術現(xiàn)在廣泛為各種平臺所采用。UTF-7的代碼頁是65000,UTF-8的代碼頁是65001。

3.3Unicode編碼

為了使國際間信息交流更加方便,國際組織制定了UNICODE字符集,為各種語言中的每一個字符設定了統(tǒng)一并且唯一的數(shù)字編號,以滿足跨語言、跨平臺進行文本轉換、處理的要求。

Unicode字符集可以簡寫為UCS(UnicodeCharacterSet)。早期的unicodeUnicode標準有UCS-2、UCS-4的說法。UCS-2用兩個字節(jié)編碼,UCS-4用4個字節(jié)編碼。

在UNICODE被采用之后,計算機存放字符串時,改為存放每個字符在UNICODE字符集中的序號。目前計算機一般使用2個字節(jié)(16位)來存放一個序號(DBCS,DoubleByteCharacterSystem),因此,這種方式存放的字符也被稱作寬字節(jié)字符。比如,字符串"中文123"在Windows2000下,內(nèi)存中實際存放的是5個序號,一共10個字節(jié)。

Unicode字符集包含了各種語言中使用到的所有“字符”。用來給UNICODE字符集編碼的標準有很多種,比如:UTF-8,UTF-7,UTF-16,UnicodeLittle,UnicodeBig等。4、常用編碼規(guī)則4.1單字節(jié)字符編碼

(1)編碼標準:ISO-8859-1。(2)說明:最簡單的編碼規(guī)則,每一個字節(jié)直接作為一個UNICODE字符。比如,[0xD6,0xD0]這兩個字節(jié),通過iso-8859-1轉化為字符串時,將直接得到[0x00D6,0x00D0]兩個UNICODE字符,即"?D"。

反之,將UNICODE字符串通過iso-8859-1轉化為字節(jié)串時,只能正常轉化0~255范圍的字符。

4.2ANSI編碼

(1)GB2312,BIG5,Shift_JIS,ISO-8859-2。(2)把UNICODE字符串通過ANSI編碼轉化為“字節(jié)串”時,根據(jù)各自編碼的規(guī)定,一個UNICODE字符可能轉化成一個字節(jié)或多個字節(jié)。

反之,將字節(jié)串轉化成字符串時,也可能多個字節(jié)轉化成一個字符。比如,[0xD6,0xD0]這兩個字節(jié),通過GB2312轉化為字符串時,將得到[0x4E2D]一個字符,即'中'字。

“ANSI編碼”的特點:(1)這些“ANSI編碼標準”都只能處理各自語言范圍之內(nèi)的UNICODE字符。(2)“UNICODE字符”與“轉換出來的字節(jié)”之間的關系是人為規(guī)定的。

4.3UNICODE編碼

(1)編碼標準:UTF-8,UTF-16,UnicodeBig。(2)與“ANSI編碼”類似的,把字符串通過UNICODE編碼轉化成“字節(jié)串”時,一個UNICODE字符可能轉化成一個字節(jié)或多個字節(jié)。

與“ANSI編碼”不同的是:(1)這些“UNICODE編碼”能夠處理所有的UNICODE字符。(2)“UNICODE字符”與“轉換出來的字節(jié)”之間是可以通過計算得到的。

我們實際上沒有必要去深究每一種編碼具體把某一個字符編碼成了哪幾個字節(jié),我們只需要知道“編碼”的概念就是把“字符”轉化成“字節(jié)”就可以了。對于“UNICODE編碼”,由于它們是可以通過計算得到的,因此,在特殊的場合,我們可以去了解某一種“UNICODE編碼”是怎樣的規(guī)則。5、編碼的區(qū)別5.1GB2312、GBK和GB18030

(1)GB2312

當中國人們得到計算機時,已經(jīng)沒有可以利用的字節(jié)狀態(tài)來表示漢字,況且有6000多個常用漢字需要保存,于是想到把那些ASCII碼中127號之后的奇異符號們直接取消掉,規(guī)定:一個小于127的字符的意義與原來相同,但兩個大于127的字符連在一起時,就表示一個漢字,前面的一個字節(jié)(稱之為高字節(jié))從0xA1用到0xF7,后面一個字節(jié)(低字節(jié))從0xA1到0xFE,這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼里,我們還把數(shù)學符號、羅馬希臘的字母、日文的假名們都編進去了,連在ASCII里本來就有的數(shù)字、標點、字母都統(tǒng)統(tǒng)重新編了兩個字節(jié)長的編碼,這就是常說的"全角"字符,而原來在127號以下的那些就叫"半角"字符了。這種漢字方案叫做"GB2312"。GB2312是對ASCII的中文擴展。兼容ASCII。

(2)GBK

但是中國的漢字太多了,我們很快就就發(fā)現(xiàn)有許多人的人名沒有辦法在這里打出來,不得不繼續(xù)把GB2312沒有用到的碼位找出來用上。后來還是不夠用,于是干脆不再要求低字節(jié)一定是127號之后的內(nèi)碼,只要第一個字節(jié)是大于127就固定表示這是一個漢字的開始,不管后面跟的是不是擴展字符集里的內(nèi)容。結果擴展之后的編碼方案被稱為“GBK”標準,GBK包括了GB2312的所有內(nèi)容,同時又增加了近20000個新的漢字(包括繁體字)和符號。

(3)GB18030

后來少數(shù)民族也要用電腦了,于是我們再擴展,又加了幾千個新的少數(shù)民族的字,GBK擴成了GB18030。從此之后,中華民族的文化就可以在計算機時代中傳承了。

中國的程序員們看到這一系列漢字編碼的標準是好的,于是通稱他們叫做"DBCS"(DoubleByteCharecterSet雙字節(jié)字符集)。在DBCS系列標準里,最大的特點是兩字節(jié)長的漢字字符和一字節(jié)長的英文字符并存于同一套編碼方案里,因此他們寫的程序為了支持中文處理,必須要注意字串里的每一個字節(jié)的值,如果這個值是大于127的,那么就認為一個雙字節(jié)字符集里的字符出現(xiàn)了。在這種情況下,"一個漢字算兩個英文字符!"。然而,在Unicode環(huán)境下卻并非總是如此。

5.1Unicode和BigEndianUnicode

這兩個指示存儲順序不同,如"A"的Unicode編碼為6500,而BigEndianUnicode編碼為0065。

5.2UTF-7、UTF-8和UTF-16

在Unicode里,所有的字符被一視同仁。漢字不再使用“兩個擴展ASCII”,而是使用“1個Unicode”,注意,現(xiàn)在的漢字是“一個字符”了,于是,拆字、統(tǒng)計字數(shù)這些問題也就自然而然的解決了。

但是,這個世界不是理想的,不可能在一夜之間所有的系統(tǒng)都使用Unicode來處理字符,所以Unicode在誕生之日,就必須考慮一個嚴峻的問題:和ASCII字符集之間的不兼容問題。

我們知道,ASCII字符是單個字節(jié)的,比如“A”的ASCII是65。而Unicode是雙字節(jié)的,比如“A”的Unicode是0065,這就造成了一個非常大的問題:以前處理ASCII的那套機制不能被用來處理Unicode了。

另一個更加嚴重的問題是,C語言使用'\0'作為字符串結尾,而Unicode里恰恰有很多字符都有一個字節(jié)為0,這樣一來,C語言的字符串函數(shù)將無法正常處理Unicode,除非把世界上所有用C寫的程序以及他們所用的函數(shù)庫全部換掉。

于是,比Unicode更偉大的東東誕生了,之所以說它更偉大是因為它讓Unicode不再存在于紙上,而是真實的存在于我們大家的電腦中。那就是:UTF。

UTF=UCSTransformationFormat,即UCS轉換(傳輸)格式。它是將Unicode編碼規(guī)則和計算機的實際編碼對應起來的一個規(guī)則?,F(xiàn)在流行的UTF有2種:UTF-8和UTF-16。

這兩種都是Unicode的編碼實現(xiàn)。

5.2.1UTF-8

UCS-2編碼(16進制)

UTF-8字節(jié)流(二進制)0000-007F

0xxxxxxx0080-07FF

110xxxxx10xxxxxx0800-FFFF

1110xxxx10xxxxxx10xxxxxx

例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間,所以肯定要用3字節(jié)模板了:1110xxxx10xxxxxx10xxxxxx。將6C49寫成二進制是:0110110001001001,用這個比特流依次代替模板中的x,得到:111001101011000110001001,即E6B189。

可見UTF-8是變長的,將Unicode編碼為00000000-0000007F的字符,用單個字節(jié)來表示;00000080-000007FF的字符用兩個字節(jié)表示;00000800-0000FFFF的字符用3字節(jié)表示。因為目前為止Unicode-16規(guī)范沒有指定FFFF以上的字符,所以UTF-8最多是使用3個字節(jié)來表示一個字符。但理論上來說,UTF-8最多需要用6字節(jié)表示一個字符。

UTF-8兼容ASCII。

5.2.2UTF-16(標準的Unicode成為UTF-16)

UTF-16和上面提到的Unicode本身的編碼規(guī)范是一致的。

UTF-16以16位為單元對UCS進行編碼。對于小于0x10000的UCS碼,UTF-16編碼就等于UCS碼對應的16位無符號整數(shù)。對于不小于0x10000的UCS碼,定義了一個算法。不過由于實際使用的UCS2,或者UCS4的BMP必然小于0x10000,所以就目前而言,可以認為UTF-16和UCS-2基本相同。但UCS-2只是一個編碼方案,UTF-16卻要用于實際的傳輸,所以就不得不考慮字節(jié)序的問題。

UTF-16不兼容ASCII。

5.2.3UTF-7

UTF-7(7-位元Unicode轉換格式(UnicodeTransformationFormat,簡寫成UTF))是一種可變長度字元編碼方式,用以將Unicode字元以ASCII編碼的字元串來呈現(xiàn),可以應用在電子郵件傳輸之類的應用。

UTF-7并非Unicode標準之一。想要詳細了解的可以查閱相關資料。6、Unicode與UTFUnicode是內(nèi)存編碼表示方案(是規(guī)范),而UTF是如何保存和傳輸Unicode的方案(是實現(xiàn))。

6.1UTF的字節(jié)序和BOM

6.1.1字節(jié)序

UTF-8以字節(jié)為編碼單元,沒有字節(jié)序的問題。UTF-16以兩個字節(jié)為編碼單元,在解釋一個UTF-16文本前,首先要弄清楚每個編碼單元的字節(jié)序。例如收到一個“奎”的Unicode編碼是594E,“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節(jié)流“594E”,那么這是“奎”還是“乙”?

Unicode規(guī)范中推薦的標記字節(jié)順序的方法是BOM。BOM不是“BillOfMaterial”的BOM表,而是ByteOrderMark。BOM是一個有點小聰明的想法:

在UCS編碼中有一個叫做"ZEROWIDTHNO-BREAKSPACE"的字符,它的編碼是FEFF。而FFFE在UCS中是不存在的字符,所以不應該出現(xiàn)在實際傳輸中。UCS規(guī)范建議我們在傳輸字節(jié)流前,先傳輸字符"ZEROWIDTHNO-BREAKSPACE"。

這樣如果接收者收到FEFF,就表明這個字節(jié)流是Big-Endian的;如果收到FFFE,就表明這個字節(jié)流是Little-Endian的。因此字符"ZEROWIDTHNO-BREAKSPACE"又被稱作BOM。

UTF-8不需要BOM來表明字節(jié)順序,但可以用BOM來表明編碼方式。字符"ZEROWIDTHNO-BREAKSPACE"的UTF-8編碼是EFBBBF(讀者可以用我們前面介紹的編碼方法驗證一下)。所以如果接收者收到以EFBBBF開頭的字節(jié)流,就知道這是UTF-8編碼了。

6.1.2BOM

(1)BOM的來歷

為了識別Unicode文件,Microsoft建議所有的Unicode文件應該以ZEROWIDTHNOBREAKSPACE(U+FEFF)字符開頭。這作為一個“特征符”或“字節(jié)順序標記(byte-ordermark,BOM)”來識別文件中使用的編碼和字節(jié)順序。

(2)不同的系統(tǒng)對BOM的支持

因為一些系統(tǒng)或程序不支持BOM,因此帶有BOM的Unicode文件有時會帶來一些問題。

①JDK1.5以及之前的Reader都不能處理帶有BOM的UTF-8編碼的文件,解析這種格式的xml文件時,會拋出異常:Contentisnotallowedinprolog?!皩τ诮鉀Q方法,之后我會寫篇文章專門討論該問題。”

②Linux/UNIX并沒有使用BOM,因為它會破壞現(xiàn)有的ASCII文件的語法約定。

③不同的編輯工具對BOM的處理也各不相同。使用Windows自帶的記事本將文件保存為UTF-8編碼的時候,記事本會自動在文件開頭插入BOM(雖然BOM對UTF-8來說并不是必須的)。而其它很多編輯器用不用BOM是可以選擇的。UTF-8、UTF-16都是如此。

(3)BOM與XML

XML解析讀取XML文檔時,W3C定義了3條規(guī)則:

①如果文檔中有BOM,就定義了文件編碼;②如果文檔中沒有BOM,就查看XML聲明中的編碼屬性;③如果上述兩者都沒有,就假定XML文檔采用UTF-8編碼。

6.2決定文本的字符集與編碼

軟件通常有三種途徑來決定文本的字符集和編碼。

(1)對于Unicode文本最標準的途徑是檢測文本最開頭的幾個字節(jié)。如:

開頭字節(jié)

Charset/encoding

EFBBBFUTF-8

FEFFUTF-16/UCS-2,littleendian(UTF-16LE)

FFFEUTF-16/UCS-2,bigendian(UTF-16BE)

FFFE0000UTF-32/UCS-4,littleendian.

0000FEFFUTF-32/UCS-4,big-endia

(2)采取一種比較安全的方式來決定字符集及其編碼,那就是彈出一個對話框來請示用戶。

然而MBCS文本(ANSI)沒有這些位于開頭的字符集標記,現(xiàn)在很多軟件保存文本為Unicode時,可以選擇是否保存這些位于開頭的字符集標記。因此,軟件不應該依賴于這種途徑。這時,軟件可以采取一種比較安全的方式來決定字符集及其編碼,那就是彈出一個對話框來請示用戶。

(3)采取自己“猜”的方法。

如果軟件不想麻煩用戶,或者它不方便向用戶請示,那它只能采取自己“猜”的方法,軟件可以根據(jù)整個文本的特征來猜測它可能屬于哪個charset,這就很可能不準了。使用記事本打開那個“聯(lián)通”文件就屬于這種情況。(把原本屬于ANSI編碼的文件當成UTF-8處理,詳細說明見:/omohe/archive/2007/05/29/1630186.aspx)

6.3記事本的幾種編碼

(1)ANSI編碼

記事本默認保存的編碼格式是:ANSI,即本地操作系統(tǒng)默認的內(nèi)碼,簡體中文一般為GB2312。這個怎么驗證呢?用記事本保存后,使用EmEditor、EditPlus和UltraEdit之類的文本編輯器打開。推薦使用EmEditor,打開后,在又下角會顯示編碼:GB2312。

(2)Unicode編碼

用記事本另存為時,編碼選擇“Unicode”,用EmEditor打開該文件,發(fā)現(xiàn)編碼格式是:UTF-16LE+BOM(有簽名)。用十六進制方式查看,發(fā)現(xiàn)開頭兩字節(jié)為:FFFE。這就是BOM。

(3)Unicodebigendian

用記事本另存為時,編碼選擇“Unicode”,用EmEditor打開該文件,發(fā)現(xiàn)編碼格式是:UTF-16BE+BOM(有簽名)。用十六進制方式查看,發(fā)現(xiàn)開頭兩字節(jié)為:FEFF。這就是BOM。

(4)UTF-8

用記事本另存為時,編碼選擇“UTF-8”,用EmEditor打開該文件,發(fā)現(xiàn)編碼格式是:UTF-8(有簽名)。用十六進制方式查看,發(fā)現(xiàn)開頭三個字節(jié)為:EFBBBF。這就是BOM。7、幾種誤解,以及亂碼產(chǎn)生的原因和解決辦法7.1誤解一

在將“字節(jié)串”轉化成“UNICODE字符串”時,比如在讀取文本文件時,或者通過網(wǎng)絡傳輸文本時,容易將“字節(jié)串”簡單地作為單字節(jié)字符串,采用每“一個字節(jié)”就是“一個字符”的方法進行轉化。

而實際上,在非英文的環(huán)境中,應該將“字節(jié)串”作為ANSI字符串,采用適當?shù)木幋a來得到UNICODE字符串,有可能“多個字節(jié)”才能得到“一個字符”。

通常,一直在英文環(huán)境下做開發(fā)的程序員們,容易有這種誤解。

7.2誤解二

在DOS,Windows98等非UNICODE環(huán)境下,字符串都是以ANSI編碼的字節(jié)形式存在的。這種以字節(jié)形式存在的字符串,必須知道是哪種編碼才能被正確地使用。這使我們形成了一個慣性思維:“字符串的編碼”。

當U

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論