字节、编码、字符、字符集 专题
1.2 字符,字節(jié),字符串
理解編碼的關(guān)鍵,是要把字符的概念和字節(jié)的概念理解準確。這兩個概念容易混淆,我們在此做一下區(qū)分:
?
| 概念描述 | 舉例 | |
| 字符 | 人們使用的記號,抽象意義上的一個符號。 | '1', '中', 'a', '$', '¥', …… | 
| 字節(jié) | 計算機中存儲數(shù)據(jù)的單元,一個8位的二進制數(shù),是一個很具體的存儲空間。 | 0x01, 0x45, 0xFA, …… | 
| ANSI 字符串 | 在內(nèi)存中,如果“字符”是以?ANSI 編碼形式存在的,一個字符可能使用一個字節(jié)或多個字節(jié)來表示,那么我們稱這種字符串為?ANSI 字符串或者多字節(jié)字符串。 | "中文123" (占7字節(jié)) | 
| UNICODE 字符串 | 在內(nèi)存中,如果“字符”是以在 UNICODE 中的序號存在的,那么我們稱這種字符串為UNICODE 字符串或者寬字節(jié)字符串。 | L"中文123" (占10字節(jié)) | 
?
由于不同 ANSI 編碼所規(guī)定的標準是不相同的,因此,對于一個給定的多字節(jié)字符串,我們必須知道它采用的是哪一種編碼規(guī)則,才能夠知道它包含了哪些“字符”。而對于?UNICODE 字符串來說,不管在什么環(huán)境下,它所代表的“字符”內(nèi)容總是不變的。
1.3 字符集與編碼
各個國家和地區(qū)所制定的不同 ANSI 編碼標準中,都只規(guī)定了各自語言所需的“字符”。比如:漢字標準(GB2312)中沒有規(guī)定韓國語字符怎樣存儲。這些 ANSI 編碼標準所規(guī)定的內(nèi)容包含兩層含義:
各個國家和地區(qū)在制定編碼標準的時候,“字符的集合”和“編碼”一般都是同時制定的。因此,平常我們所說的“字符集”,比如:GB2312, GBK, JIS 等,除了有“字符的集合”這層含義外,同時也包含了“編碼”的含義。
“UNICODE 字符集”包含了各種語言中使用到的所有“字符”。用來給 UNICODE 字符集編碼的標準有很多種,比如:UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig 等。
1.4 常用的編碼簡介
簡單介紹一下常用的編碼規(guī)則,為后邊的章節(jié)做一個準備。在這里,我們根據(jù)編碼規(guī)則的特點,把所有的編碼分成三類:
?
| 分類 | 編碼標準 | 說明 | 
| 單字節(jié)字符編碼 | ISO-8859-1 | 最簡單的編碼規(guī)則,每一個字節(jié)直接作為一個 UNICODE 字符。比如,[0xD6, 0xD0] 這兩個字節(jié),通過 iso-8859-1 轉(zhuǎn)化為字符串時,將直接得到 [0x00D6, 0x00D0] 兩個 UNICODE 字符,即 "?D"。 反之,將 UNICODE 字符串通過 iso-8859-1 轉(zhuǎn)化為字節(jié)串時,只能正常轉(zhuǎn)化 0~255 范圍的字符。  | 
| ANSI 編碼 | GB2312, BIG5, Shift_JIS, ISO-8859-2 …… | 把 UNICODE 字符串通過 ANSI 編碼轉(zhuǎn)化為“字節(jié)串”時,根據(jù)各自編碼的規(guī)定,一個 UNICODE 字符可能轉(zhuǎn)化成一個字節(jié)或多個字節(jié)。 反之,將字節(jié)串轉(zhuǎn)化成字符串時,也可能多個字節(jié)轉(zhuǎn)化成一個字符。比如,[0xD6, 0xD0] 這兩個字節(jié),通過 GB2312 轉(zhuǎn)化為字符串時,將得到 [0x4E2D] 一個字符,即 '中' 字。 “ANSI 編碼”的特點: 1. 這些“ANSI 編碼標準”都只能處理各自語言范圍之內(nèi)的 UNICODE 字符。 2. “UNICODE 字符”與“轉(zhuǎn)換出來的字節(jié)”之間的關(guān)系是人為規(guī)定的。  | 
| UNICODE 編碼 | UTF-8, UTF-16, UnicodeBig …… | 與“ANSI 編碼”類似的,把字符串通過 UNICODE 編碼轉(zhuǎn)化成“字節(jié)串”時,一個 UNICODE 字符可能轉(zhuǎn)化成一個字節(jié)或多個字節(jié)。 與“ANSI 編碼”不同的是: 1. 這些“UNICODE 編碼”能夠處理所有的 UNICODE 字符。 2. “UNICODE 字符”與“轉(zhuǎn)換出來的字節(jié)”之間是可以通過計算得到的。  | 
?
我們實際上沒有必要去深究每一種編碼具體把某一個字符編碼成了哪幾個字節(jié),我們只需要知道“編碼”的概念就是把“字符”轉(zhuǎn)化成“字節(jié)”就可以了。對于“UNICODE 編碼”,由于它們是可以通過計算得到的,因此,在特殊的場合,我們可以去了解某一種“UNICODE 編碼”是怎樣的規(guī)則。
?
2. 字符與編碼在程序中的實現(xiàn) 2.1 程序中的字符與字節(jié)
在 C++ 和 Java 中,用來代表“字符”和“字節(jié)”的數(shù)據(jù)類型,以及進行編碼的方法:
?
| 類型或操作 | C++ | Java | 
| 字符 | wchar_t | char | 
| 字節(jié) | char | byte | 
| ANSI 字符串 | char[] | byte[] | 
| UNICODE 字符串 | wchar_t[] | String | 
| 字節(jié)串→字符串 | mbstowcs(), MultiByteToWideChar() | string = new String(bytes, "encoding") | 
| 字符串→字節(jié)串 | wcstombs(), WideCharToMultiByte() | bytes = string.getBytes("encoding") | 
?
以上需要注意幾點:
字符串類 String 中的內(nèi)容是 UNICODE 字符串:
?
| // Java 代碼,直接寫中文 String string = "中文123"; // 得到長度為 5,因為是 5 個字符 System.out.println(string.length());  | 
?
字符串 I/O 操作,字符與字節(jié)轉(zhuǎn)換操作。在 Java 包 java.io.* 中,以“Stream”結(jié)尾的類一般是用來操作“字節(jié)串”的類,以“Reader”,“Writer”結(jié)尾的類一般是用來操作“字符串”的類。
// 字符串與字節(jié)串間相互轉(zhuǎn)化// 按照 GB2312 得到字節(jié)(得到多字節(jié)字符串) byte [] bytes = string.getBytes("GB2312");// 從字節(jié)按照 GB2312 得到 UNICODE 字符串 string = new String(bytes, "GB2312");// 要將 String 按照某種編碼寫入文本文件,有兩種方法:// 第一種辦法:用 Stream 類寫入已經(jīng)按照指定編碼轉(zhuǎn)化好的字節(jié)串 OutputStream os = new FileOutputStream("1.txt"); os.write(bytes); os.close();// 第二種辦法:構(gòu)造指定編碼的 Writer 來寫入字符串 Writer ow = new OutputStreamWriter(new FileOutputStream("2.txt"), "GB2312"); ow.write(string); ow.close();/* 最后得到的 1.txt 和 2.txt 都是 7 個字節(jié) */如果 java 的源程序編碼與當(dāng)前默認 ANSI 編碼不符,則在編譯的時候,需要指明一下源程序的編碼。比如:
E:\>javac -encoding BIG5 Hello.java以上需要注意區(qū)分源程序的編碼與 I/O 操作的編碼,前者是在編譯時起作用,后者是在運行時起作用。?
3. 幾種誤解,以及亂碼產(chǎn)生的原因和解決辦法 3.1 容易產(chǎn)生的誤解?
| 對編碼的誤解 | |
| 誤解一 | 在將“字節(jié)串”轉(zhuǎn)化成“UNICODE 字符串”時,比如在讀取文本文件時,或者通過網(wǎng)絡(luò)傳輸文本時,容易將“字節(jié)串”簡單地作為單字節(jié)字符串,采用每“一個字節(jié)”就是“一個字符”的方法進行轉(zhuǎn)化。 而實際上,在非英文的環(huán)境中,應(yīng)該將“字節(jié)串”作為 ANSI 字符串,采用適當(dāng)?shù)木幋a來得到 UNICODE 字符串,有可能“多個字節(jié)”才能得到“一個字符”。 通常,一直在英文環(huán)境下做開發(fā)的程序員們,容易有這種誤解。  | 
| 誤解二 | 在 DOS,Windows 98 等非 UNICODE 環(huán)境下,字符串都是以 ANSI 編碼的字節(jié)形式存在的。這種以字節(jié)形式存在的字符串,必須知道是哪種編碼才能被正確地使用。這使我們形成了一個慣性思維:“字符串的編碼”。 當(dāng) UNICODE 被支持后,Java 中的 String 是以字符的“序號”來存儲的,不是以“某種編碼的字節(jié)”來存儲的,因此已經(jīng)不存在“字符串的編碼”這個概念了。只有在“字符串”與“字節(jié)串”轉(zhuǎn)化時,或者,將一個“字節(jié)串”當(dāng)成一個 ANSI 字符串時,才有編碼的概念。 不少的人都有這個誤解。  | 
?
第一種誤解,往往是導(dǎo)致亂碼產(chǎn)生的原因。第二種誤解,往往導(dǎo)致本來容易糾正的亂碼問題變得更復(fù)雜。
在這里,我們可以看到,其中所講的“誤解一”,即采用每“一個字節(jié)”就是“一個字符”的轉(zhuǎn)化方法,實際上也就等同于采用 iso-8859-1 進行轉(zhuǎn)化。因此,我們常常使用 bytes = string.getBytes("iso-8859-1") 來進行逆向操作,得到原始的“字節(jié)串”。然后再使用正確的 ANSI 編碼,比如 string = new String(bytes, "GB2312"),來得到正確的“UNICODE 字符串”。?
3.2 非 UNICODE 程序在不同語言環(huán)境間移植時的亂碼非 UNICODE 程序中的字符串,都是以某種 ANSI 編碼形式存在的。如果程序運行時的語言環(huán)境與開發(fā)時的語言環(huán)境不同,將會導(dǎo)致 ANSI 字符串的顯示失敗。
比如,在日文環(huán)境下開發(fā)的非 UNICODE 的日文程序界面,拿到中文環(huán)境下運行時,界面上將顯示亂碼。如果這個日文程序界面改為采用 UNICODE 來記錄字符串,那么當(dāng)在中文環(huán)境下運行時,界面上將可以顯示正常的日文。
由于客觀原因,有時候我們必須在中文操作系統(tǒng)下運行非 UNICODE 的日文軟件,這時我們可以采用一些工具,比如,南極星,AppLocale 等,暫時的模擬不同的語言環(huán)境。?
3.3 網(wǎng)頁提交字符串當(dāng)頁面中的表單提交字符串時,首先把字符串按照當(dāng)前頁面的編碼,轉(zhuǎn)化成字節(jié)串。然后再將每個字節(jié)轉(zhuǎn)化成 "%XX" 的格式提交到 Web 服務(wù)器。比如,一個編碼為 GB2312 的頁面,提交 "中" 這個字符串時,提交給服務(wù)器的內(nèi)容為 "%D6%D0"。
在服務(wù)器端,Web 服務(wù)器把收到的 "%D6%D0" 轉(zhuǎn)化成 [0xD6, 0xD0] 兩個字節(jié),然后再根據(jù) GB2312 編碼規(guī)則得到 "中" 字。
在 Tomcat 服務(wù)器中,request.getParameter() 得到亂碼時,常常是因為前面提到的“誤解一”造成的。默認情況下,當(dāng)提交 "%D6%D0" 給 Tomcat 服務(wù)器時,request.getParameter() 將返回 [0x00D6, 0x00D0] 兩個 UNICODE 字符,而不是返回一個 "中" 字符。因此,我們需要使用 bytes = string.getBytes("iso-8859-1") 得到原始的字節(jié)串,再用 string = new String(bytes, "GB2312") 重新得到正確的字符串 "中"。?
3.4 從數(shù)據(jù)庫讀取字符串通過數(shù)據(jù)庫客戶端(比如 ODBC 或 JDBC)從數(shù)據(jù)庫服務(wù)器中讀取字符串時,客戶端需要從服務(wù)器獲知所使用的 ANSI 編碼。當(dāng)數(shù)據(jù)庫服務(wù)器發(fā)送字節(jié)流給客戶端時,客戶端負責(zé)將字節(jié)流按照正確的編碼轉(zhuǎn)化成 UNICODE 字符串。
如果從數(shù)據(jù)庫讀取字符串時得到亂碼,而數(shù)據(jù)庫中存放的數(shù)據(jù)又是正確的,那么往往還是因為前面提到的“誤解一”造成的。解決的辦法還是通過 string = new String( string.getBytes("iso-8859-1"), "GB2312") 的方法,重新得到原始的字節(jié)串,再重新使用正確的編碼轉(zhuǎn)化成字符串。?
3.5 電子郵件中的字符串當(dāng)一段 Text 或者 HTML 通過電子郵件傳送時,發(fā)送的內(nèi)容首先通過一種指定的字符編碼轉(zhuǎn)化成“字節(jié)串”,然后再把“字節(jié)串”通過一種指定的傳輸編碼(Content-Transfer-Encoding)進行轉(zhuǎn)化得到另一串“字節(jié)串”。比如,打開一封電子郵件源代碼,可以看到類似的內(nèi)容:
?
| Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 sbG+qcrQuqO17cf4yee74bGjz9W7+b3wudzA7dbQ0MQNCg0KvPKzxqO6uqO17cnnsaPW0NDEDQoNCg==  | 
?
最常用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable 兩種。在對二進制文件或者中文文本進行轉(zhuǎn)化時,Base64 得到的“字節(jié)串”比 Quoted-Printable 更短。在對英文文本進行轉(zhuǎn)化時,Quoted-Printable 得到的“字節(jié)串”比 Base64 更短。
郵件的標題,用了一種更簡短的格式來標注“字符編碼”和“傳輸編碼”。比如,標題內(nèi)容為 "中",則在郵件源代碼中表示為:
?
| // 正確的標題格式 Subject: =?GB2312?B?1tA=?=  | 
?其中,
- 第一個“=?”與“?”中間的部分指定了字符編碼,在這個例子中指定的是 GB2312。
 - “?”與“?”中間的“B”代表 Base64。如果是“Q”則代表 Quoted-Printable。
 - 最后“?”與“?=”之間的部分,就是經(jīng)過 GB2312 轉(zhuǎn)化成字節(jié)串,再經(jīng)過 Base64 轉(zhuǎn)化后的標題內(nèi)容。
 
如果“傳輸編碼”改為 Quoted-Printable,同樣,如果標題內(nèi)容為 "中":
?
| // 正確的標題格式 Subject: =?GB2312?Q?=D6=D0?=  | 
如果閱讀郵件時出現(xiàn)亂碼,一般是因為“字符編碼”或“傳輸編碼”指定有誤,或者是沒有指定。比如,有的發(fā)郵件組件在發(fā)送郵件時,標題 "中":
| // 錯誤的標題格式 Subject: =?ISO-8859-1?Q?=D6=D0?=  | 
這樣的表示,實際上是明確指明了標題為 [0x00D6, 0x00D0],即 "?D",而不是 "中"。?
4. 幾種錯誤理解的糾正誤解:“ISO-8859-1 是國際編碼?”非也。iso-8859-1 只是單字節(jié)字符集中最簡單的一種,也就是“字節(jié)編號”與“UNICODE 字符編號”一致的那種編碼規(guī)則。當(dāng)我們要把一個“字節(jié)串”轉(zhuǎn)化成“字符串”,而又不知道它是哪一種 ANSI 編碼時,先暫時地把“每一個字節(jié)”作為“一個字符”進行轉(zhuǎn)化,不會造成信息丟失。然后再使用 bytes = string.getBytes("iso-8859-1") 的方法可恢復(fù)到原始的字節(jié)串。
誤解:“Java 中,怎樣知道某個字符串的內(nèi)碼?”Java 中,字符串類 java.lang.String 處理的是 UNICODE 字符串,不是 ANSI 字符串。我們只需要把字符串作為“抽象的符號的串”來看待。因此不存在字符串的內(nèi)碼的問題。
1. gb2312
規(guī)定: 一個小于127的字符的意義與原來相同, 但兩個大于127的字符連在一起時, 就表示一個漢字, 前面的一個字節(jié)(他稱之為高字節(jié))從0xA1用到 0xF7, 后面一個字節(jié)(低字節(jié))
從0xA1到0xFE, 這樣我們就可以組合出大約7000多個簡體漢字了. 
在這些編碼里, 我們還把數(shù)學(xué)符號,羅馬希臘的 字母,日文的假名們都編進去了, 連在 ASCII 里本來就有的數(shù)字,標點,字母都統(tǒng)統(tǒng)重新編了兩個字節(jié)長的編碼, 這就是常說的"全角"字符, 而原來在127號以下的那些就叫"半角"字符了.
中國人民看到這樣很不錯, 于是就把這種漢字方案叫做 "GB2312". GB2312 是對 ASCII的中文擴展.
2. GBK
但是中國的漢字太多了, 我們很快就就發(fā)現(xiàn)有許多人的人名沒有辦法在這里打出來. 于是我們不得不繼續(xù)把 GB2312 沒有用到的碼位找出來用上.
后來還是不夠用, 于是干脆不再要求低字節(jié)一定是127號之后的內(nèi)碼, 只要第一個字節(jié)是大于127就固定表示這是一個漢字的開始, 不管后面跟的是不是擴展字 符集里的內(nèi)容. 結(jié)果擴展之后的編碼方案被稱為 "GBK" 標準, GBK 包括了 GB2312 的所有內(nèi)容, 同時又增加了近20000個新的漢字(包括繁體字)和符號.
Note: Unicode相關(guān)的基礎(chǔ)知識請參數(shù)上一篇博文.
3. Unicode與GBK互轉(zhuǎn)
3.1 GBK --> Unicode
Unicode 與 GBK 是兩個完全不樣的字符編碼方案, 其兩者沒有直接關(guān)系, 要對其進行相
互轉(zhuǎn)換, 最直接最高效的方法是查表.
GBK與Unicode的映射表可以從網(wǎng)上下載:
????http://www.gnu.org/directory/libiconv.html
顯然, 只需要把下載下來的映射表用一個二維數(shù)組表示即可,
InputStreamReader和OutputStreamWriter:InputStreamReader是字節(jié)流通向字符流的橋梁:它使用指定的charset?讀取字節(jié)并將其解碼為字符。它使用的字符集可以由名稱指定或顯式給定,或者可以接受平臺默認的字符集。
OutputStreamWriter是字符流通向字節(jié)流的橋梁:可使用指定的charset?將要寫入流中的字符編碼成字節(jié)。它使用的字符集可以由名稱指定或顯式給定,否則將接受平臺默認的字符集。
總結(jié)
以上是生活随笔為你收集整理的字节、编码、字符、字符集 专题的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
                            
                        - 上一篇: bitmapdata的知识点
 - 下一篇: Scribefire发CSDN博客