字符，字節和編碼

轉自字符，字節和編碼

引言 「字符與編碼」是一個被常常討論的話題。即便這樣，時常出現的亂碼仍然困擾着你們。雖然咱們有不少的辦法能夠用來消除亂碼，但咱們並不必定理解這些辦法的內在原理。而有的亂碼產生的緣由，實際上因爲底層代碼自己有問題所致使的。所以，不只是初學者會對字符編碼感到模糊，有的底層開發人員一樣對字符編碼缺少準確的理解。 1. 編碼問題的由來，相關概念的理解 1.1 字符與編碼的發展 從計算機對多國語言的支持角度看，大體能夠分爲三個階段：   系統內碼 說明 系統 階段一 ASCII 計算機剛開始只支持英語，其它語言不可以在計算機上存儲和顯示。 英文 DOS 階段二 ANSI編碼 （本地化） 爲使計算機支持更多語言，一般使用 0x80~0xFF 範圍的 2 個字節來表示 1 個字符。好比：漢字 '中' 在中文操做系統中，使用 [0xD6,0xD0] 這兩個字節存儲。 不一樣的國家和地區制定了不一樣的標準，由此產生了 GB2312, BIG5, JIS 等各自的編碼標準。這些使用 2 個字節來表明一個字符的各類漢字延伸編碼方式，稱爲 ANSI 編碼。在簡體中文系統下，ANSI 編碼表明 GB2312 編碼，在日文操做系統下，ANSI 編碼表明 JIS 編碼。 不一樣 ANSI 編碼之間互不兼容，當信息在國際間交流時，沒法將屬於兩種語言的文字，存儲在同一段 ANSI 編碼的文本中。 中文 DOS，中文 Windows 95/98，日文 Windows 95/98 階段三 UNICODE （國際化） 爲了使國際間信息交流更加方便，國際組織制定了 UNICODE 字符集，爲各類語言中的每個字符設定了統一而且惟一的數字編號，以知足跨語言、跨平臺進行文本轉換、處理的要求。 Windows NT/2000/XP，Linux，Java 字符串在內存中的存放方法： 在 ASCII 階段，單字節字符串使用一個字節存放一個字符（SBCS）。好比，"Bob123" 在內存中爲： 42 6F 62 31 32 33 00 B o b 1 2 3 \0 在使用 ANSI 編碼支持多種語言階段，每一個字符使用一個字節或多個字節來表示（MBCS），所以，這種方式存放的字符也被稱做多字節字符。好比，"中文123" 在中文 Windows 95 內存中爲7個字節，每一個漢字佔2個字節，每一個英文和數字字符佔1個字節： D6 D0 CE C4 31 32 33 00 中 文 1 2 3 \0 在 UNICODE 被採用以後，計算機存放字符串時，改成存放每一個字符在 UNICODE 字符集中的序號。目前計算機通常使用 2 個字節（16 位）來存放一個序號（DBCS），所以，這種方式存放的字符也被稱做寬字節字符。好比，字符串 "中文123" 在 Windows 2000 下，內存中實際存放的是 5 個序號： 2D 4E 87 65 31 00 32 00 33 00 00 00      ← 在 x86 CPU 中，低字節在前 中 文 1 2 3 \0   一共佔 10 個字節。 1.2 字符，字節，字符串 理解編碼的關鍵，是要把字符的概念和字節的概念理解準確。這兩個概念容易混淆，咱們在此作一下區分：   概念描述 舉例 字符 人們使用的記號，抽象意義上的一個符號。 '1', '中', 'a', '$', '￥', …… 字節 計算機中存儲數據的單元，一個8位的二進制數，是一個很具體的存儲空間。 0x01, 0x45, 0xFA, …… ANSI 字符串 在內存中，若是「字符」是以 ANSI 編碼形式存在的，一個字符可能使用一個字節或多個字節來表示，那麼咱們稱這種字符串爲 ANSI 字符串或者多字節字符串。 "中文123" （佔7字節） UNICODE 字符串 在內存中，若是「字符」是以在 UNICODE 中的序號存在的，那麼咱們稱這種字符串爲 UNICODE 字符串或者寬字節字符串。 L"中文123" （佔10字節） 因爲不一樣 ANSI 編碼所規定的標準是不相同的，所以，對於一個給定的多字節字符串，咱們必須知道它採用的是哪種編碼規則，纔可以知道它包含了哪些「字符」。而對於 UNICODE 字符串來講，無論在什麼環境下，它所表明的「字符」內容老是不變的。 1.3 字符集與編碼 各個國家和地區所制定的不一樣 ANSI 編碼標準中，都只規定了各自語言所需的「字符」。好比：漢字標準（GB2312）中沒有規定韓國語字符怎樣存儲。這些 ANSI 編碼標準所規定的內容包含兩層含義： 使用哪些字符。也就是說哪些漢字，字母和符號會被收入標準中。所包含「字符」的集合就叫作「字符集」。 規定每一個「字符」分別用一個字節仍是多個字節存儲，用哪些字節來存儲，這個規定就叫作「編碼」。 各個國家和地區在制定編碼標準的時候，「字符的集合」和「編碼」通常都是同時制定的。所以，日常咱們所說的「字符集」，好比：GB2312, GBK, JIS 等，除了有「字符的集合」這層含義外，同時也包含了「編碼」的含義。 「UNICODE 字符集」包含了各類語言中使用到的全部「字符」。用來給 UNICODE 字符集編碼的標準有不少種，好比：UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig 等。 1.4 經常使用的編碼簡介 簡單介紹一下經常使用的編碼規則，爲後邊的章節作一個準備。在這裏，咱們根據編碼規則的特色，把全部的編碼分紅三類： 分類 編碼標準 說明 單字節字符編碼 ISO-8859-1 最簡單的編碼規則，每個字節直接做爲一個 UNICODE 字符。好比，[0xD6, 0xD0] 這兩個字節，經過 iso-8859-1 轉化爲字符串時，將直接獲得 [0x00D6, 0x00D0] 兩個 UNICODE 字符，即 "ÖÐ"。 反之，將 UNICODE 字符串經過 iso-8859-1 轉化爲字節串時，只能正常轉化 0~255 範圍的字符。 ANSI 編碼 GB2312, BIG5, Shift_JIS, ISO-8859-2 …… 把 UNICODE 字符串經過 ANSI 編碼轉化爲「字節串」時，根據各自編碼的規定，一個 UNICODE 字符可能轉化成一個字節或多個字節。 反之，將字節串轉化成字符串時，也可能多個字節轉化成一個字符。好比，[0xD6, 0xD0] 這兩個字節，經過 GB2312 轉化爲字符串時，將獲得 [0x4E2D] 一個字符，即 '中' 字。 「ANSI 編碼」的特色： 1. 這些「ANSI 編碼標準」都只能處理各自語言範圍以內的 UNICODE 字符。 2. 「UNICODE 字符」與「轉換出來的字節」之間的關係是人爲規定的。 UNICODE 編碼 UTF-8, UTF-16, UnicodeBig …… 與「ANSI 編碼」相似的，把字符串經過 UNICODE 編碼轉化成「字節串」時，一個 UNICODE 字符可能轉化成一個字節或多個字節。 與「ANSI 編碼」不一樣的是： 1. 這些「UNICODE 編碼」可以處理全部的 UNICODE 字符。 2. 「UNICODE 字符」與「轉換出來的字節」之間是能夠經過計算獲得的。 咱們實際上沒有必要去深究每一種編碼具體把某一個字符編碼成了哪幾個字節，咱們只須要知道「編碼」的概念就是把「字符」轉化成「字節」就能夠了。對於「UNICODE 編碼」，因爲它們是能夠經過計算獲得的，所以，在特殊的場合，咱們能夠去了解某一種「UNICODE 編碼」是怎樣的規則。 2. 字符與編碼在程序中的實現 2.1 程序中的字符與字節 在 C++ 和 Java 中，用來表明「字符」和「字節」的數據類型，以及進行編碼的方法： 類型或操做 C++ Java 字符 wchar_t char 字節 char byte ANSI 字符串 char[] byte[] UNICODE 字符串 wchar_t[] String 字節串→字符串 mbstowcs(), MultiByteToWideChar() string = new String(bytes, "encoding") 字符串→字節串 wcstombs(), WideCharToMultiByte() bytes = string.getBytes("encoding") 以上須要注意幾點： Java 中的 char 表明一個「UNICODE 字符（寬字節字符）」，而 C++ 中的 char 表明一個字節。 MultiByteToWideChar() 和 WideCharToMultiByte() 是 Windows API 函數。 2.2 C++ 中相關實現方法 聲明一段字符串常量： // ANSI 字符串，內容長度 7 字節 char     sz[20] = "中文123"; // UNICODE 字符串，內容長度 5 個 wchar_t（10 字節） wchar_t wsz[20] = L"\x4E2D\x6587\x0031\x0032\x0033"; UNICODE 字符串的 I/O 操做，字符與字節的轉換操做： // 運行時設定當前 ANSI 編碼，VC 格式 setlocale(LC_ALL, ".936"); // GCC 中格式 setlocale(LC_ALL, "zh_CN.GBK"); // Visual C++ 中使用小寫 %s，按照 setlocale 指定編碼輸出到文件 // GCC 中使用大寫 %S fwprintf(fp, L"%s\n", wsz); // 把 UNICODE 字符串按照 setlocale 指定的編碼轉換成字節 wcstombs(sz, wsz, 20); // 把字節串按照 setlocale 指定的編碼轉換成 UNICODE 字符串 mbstowcs(wsz, sz, 20); 在 Visual C++ 中，UNICODE 字符串常量有更簡單的表示方法。若是源程序的編碼與當前默認 ANSI 編碼不符，則須要使用 #pragma setlocale，告訴編譯器源程序使用的編碼： // 若是源程序的編碼與當前默認 ANSI 編碼不一致， // 則須要此行，編譯時用來指明當前源程序使用的編碼 #pragma setlocale(".936") // UNICODE 字符串常量，內容長度 10 字節 wchar_t wsz[20] = L"中文123"; 以上須要注意 #pragma setlocale 與 setlocale(LC_ALL, "") 的做用是不一樣的，#pragma setlocale 在編譯時起做用，setlocale() 在運行時起做用。 2.3 Java 中相關實現方法 字符串類 String 中的內容是 UNICODE 字符串： // Java 代碼，直接寫中文 String string = "中文123"; // 獲得長度爲 5，由於是 5 個字符 System.out.println(string.length()); 字符串 I/O 操做，字符與字節轉換操做。在 Java 包 java.io.* 中，以「Stream」結尾的類通常是用來操做「字節串」的類，以「Reader」，「Writer」結尾的類通常是用來操做「字符串」的類。 // 字符串與字節串間相互轉化 // 按照 GB2312 獲得字節（獲得多字節字符串） byte [] bytes = string.getBytes("GB2312"); // 從字節按照 GB2312 獲得 UNICODE 字符串 string = new String(bytes, "GB2312"); // 要將 String 按照某種編碼寫入文本文件，有兩種方法： // 第一種辦法：用 Stream 類寫入已經按照指定編碼轉化好的字節串 OutputStream os = new FileOutputStream("1.txt"); os.write(bytes); os.close(); // 第二種辦法：構造指定編碼的 Writer 來寫入字符串 Writer ow = new OutputStreamWriter(new FileOutputStream("2.txt"), "GB2312"); ow.write(string); ow.close(); /* 最後獲得的 1.txt 和 2.txt 都是 7 個字節 */ 若是 java 的源程序編碼與當前默認 ANSI 編碼不符，則在編譯的時候，須要指明一下源程序的編碼。好比： E:\>javac -encoding BIG5 Hello.java 以上須要注意區分源程序的編碼與 I/O 操做的編碼，前者是在編譯時起做用，後者是在運行時起做用。 3. 幾種誤解，以及亂碼產生的緣由和解決辦法 3.1 容易產生的誤解   對編碼的誤解 誤解一 在將「字節串」轉化成「UNICODE 字符串」時，好比在讀取文本文件時，或者經過網絡傳輸文本時，容易將「字節串」簡單地做爲單字節字符串，採用每「一個字節」就是「一個字符」的方法進行轉化。 而實際上，在非英文的環境中，應該將「字節串」做爲 ANSI 字符串，採用適當的編碼來獲得 UNICODE 字符串，有可能「多個字節」才能獲得「一個字符」。 一般，一直在英文環境下作開發的程序員們，容易有這種誤解。 誤解二 在 DOS，Windows 98 等非 UNICODE 環境下，字符串都是以 ANSI 編碼的字節形式存在的。這種以字節形式存在的字符串，必須知道是哪一種編碼才能被正確地使用。這使咱們造成了一個慣性思惟：「字符串的編碼」。 當 UNICODE 被支持後，Java 中的 String 是以字符的「序號」來存儲的，不是以「某種編碼的字節」來存儲的，所以已經不存在「字符串的編碼」這個概念了。只有在「字符串」與「字節串」轉化時，或者，將一個「字節串」當成一個 ANSI 字符串時，纔有編碼的概念。 很多的人都有這個誤解。 第一種誤解，每每是致使亂碼產生的緣由。第二種誤解，每每致使原本容易糾正的亂碼問題變得更復雜。 在這裏，咱們能夠看到，其中所講的「誤解一」，即採用每「一個字節」就是「一個字符」的轉化方法，實際上也就等同於採用 iso-8859-1 進行轉化。所以，咱們經常使用 bytes = string.getBytes("iso-8859-1") 來進行逆向操做，獲得原始的「字節串」。而後再使用正確的 ANSI 編碼，好比 string = new String(bytes, "GB2312")，來獲得正確的「UNICODE 字符串」。 3.2 非 UNICODE 程序在不一樣語言環境間移植時的亂碼 非 UNICODE 程序中的字符串，都是以某種 ANSI 編碼形式存在的。若是程序運行時的語言環境與開發時的語言環境不一樣，將會致使 ANSI 字符串的顯示失敗。 好比，在日文環境下開發的非 UNICODE 的日文程序界面，拿到中文環境下運行時，界面上將顯示亂碼。若是這個日文程序界面改成採用 UNICODE 來記錄字符串，那麼當在中文環境下運行時，界面上將能夠顯示正常的日文。 因爲客觀緣由，有時候咱們必須在中文操做系統下運行非 UNICODE 的日文軟件，這時咱們能夠採用一些工具，好比，南極星，AppLocale 等，暫時的模擬不一樣的語言環境。 3.3 網頁提交字符串 當頁面中的表單提交字符串時，首先把字符串按照當前頁面的編碼，轉化成字節串。而後再將每一個字節轉化成 "%XX" 的格式提交到 Web 服務器。好比，一個編碼爲 GB2312 的頁面，提交 "中" 這個字符串時，提交給服務器的內容爲 "%D6%D0"。 在服務器端，Web 服務器把收到的 "%D6%D0" 轉化成 [0xD6, 0xD0] 兩個字節，而後再根據 GB2312 編碼規則獲得 "中" 字。 在 Tomcat 服務器中，request.getParameter() 獲得亂碼時，經常是由於前面提到的「誤解一」形成的。默認狀況下，當提交 "%D6%D0" 給 Tomcat 服務器時，request.getParameter() 將返回 [0x00D6, 0x00D0] 兩個 UNICODE 字符，而不是返回一個 "中" 字符。所以，咱們須要使用 bytes = string.getBytes("iso-8859-1") 獲得原始的字節串，再用 string = new String(bytes, "GB2312") 從新獲得正確的字符串 "中"。 3.4 從數據庫讀取字符串 經過數據庫客戶端（好比 ODBC 或 JDBC）從數據庫服務器中讀取字符串時，客戶端須要從服務器獲知所使用的 ANSI 編碼。當數據庫服務器發送字節流給客戶端時，客戶端負責將字節流按照正確的編碼轉化成 UNICODE 字符串。 若是從數據庫讀取字符串時獲得亂碼，而數據庫中存放的數據又是正確的，那麼每每仍是由於前面提到的「誤解一」形成的。解決的辦法仍是經過 string = new String( string.getBytes("iso-8859-1"), "GB2312") 的方法，從新獲得原始的字節串，再從新使用正確的編碼轉化成字符串。 3.5 電子郵件中的字符串 當一段 Text 或者 HTML 經過電子郵件傳送時，發送的內容首先經過一種指定的字符編碼轉化成「字節串」，而後再把「字節串」經過一種指定的傳輸編碼（Content-Transfer-Encoding）進行轉化獲得另外一串「字節串」。好比，打開一封電子郵件源代碼，能夠看到相似的內容： Content-Type: text/plain;         charset="gb2312" Content-Transfer-Encoding: base64 sbG+qcrQuqO17cf4yee74bGjz9W7+b3wudzA7dbQ0MQNCg0KvPKzxqO6uqO17cnnsaPW0NDEDQoNCg== 最經常使用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable 兩種。在對二進制文件或者中文文本進行轉化時，Base64 獲得的「字節串」比 Quoted-Printable 更短。在對英文文本進行轉化時，Quoted-Printable 獲得的「字節串」比 Base64 更短。 郵件的標題，用了一種更簡短的格式來標註「字符編碼」和「傳輸編碼」。好比，標題內容爲 "中"，則在郵件源代碼中表示爲： // 正確的標題格式 Subject: =?GB2312?B?1tA=?= 其中， 第一個「=?」與「?」中間的部分指定了字符編碼，在這個例子中指定的是 GB2312。 「?」與「?」中間的「B」表明 Base64。若是是「Q」則表明 Quoted-Printable。 最後「?」與「?=」之間的部分，就是通過 GB2312 轉化成字節串，再通過 Base64 轉化後的標題內容。 若是「傳輸編碼」改成 Quoted-Printable，一樣，若是標題內容爲 "中"： // 正確的標題格式 Subject: =?GB2312?Q?=D6=D0?= 若是閱讀郵件時出現亂碼，通常是由於「字符編碼」或「傳輸編碼」指定有誤，或者是沒有指定。好比，有的發郵件組件在發送郵件時，標題 "中"： // 錯誤的標題格式 Subject: =?ISO-8859-1?Q?=D6=D0?= 這樣的表示，其實是明確指明瞭標題爲 [0x00D6, 0x00D0]，即 "ÖÐ"，而不是 "中"。 4. 幾種錯誤理解的糾正 誤解：「ISO-8859-1 是國際編碼？」 非也。iso-8859-1 只是單字節字符集中最簡單的一種，也就是「字節編號」與「UNICODE 字符編號」一致的那種編碼規則。當咱們要把一個「字節串」轉化成「字符串」，而又不知道它是哪種 ANSI 編碼時，先暫時地把「每個字節」做爲「一個字符」進行轉化，不會形成信息丟失。而後再使用 bytes = string.getBytes("iso-8859-1") 的方法可恢復到原始的字節串。 誤解：「Java 中，怎樣知道某個字符串的內碼？」 Java 中，字符串類 java.lang.String 處理的是 UNICODE 字符串，不是 ANSI 字符串。咱們只須要把字符串做爲「抽象的符號的串」來看待。所以不存在字符串的內碼的問題。