http://www.cnblogs.com/defias/p/3436517.html

相信大家一定碰到過，打開某個網頁，卻顯示一堆像亂碼，如"б?ЯАзЪСЯ"、"?????????"？還記得HTTP中的Accept-Charset、Accept-Encoding、Accept-Language、Content-Encoding、Content-Language等消息頭字段？這些就是接下來我們要探討的。

目錄：

• 1.基礎知識

• 2.常用字符集和字符編碼

  • 2.1. ASCII字符集&編碼
  • 2.2. GBXXXX字符集&編碼
  • 2.3. BIG5字符集&編碼

• 3.偉大的創想Unicode

  • 3.1.UCS & UNICODE
  • 3.2.UTF-32
  • 3.3.UTF-16
  • 3.4.UTF-8
• 4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language
• 參考文獻&進一步閱讀

1.基礎知識

計算機中儲存的信息都是用二進制數表示的；而我們在屏幕上看到的英文、漢字等字符是二進制數轉換之後的結果。通俗的說，按照何種規則將字符存儲在計算機中，如‘a‘用什麽表示，稱為"編碼"；反之，將存儲在計算機中的二進制數解析顯示出來，稱為"解碼"，如同密碼學中的加密和解密。在解碼過程中，如果使用了錯誤的解碼規則，則導致‘a‘解析成‘b‘或者亂碼。

字符集（Charset）：是一個系統支持的所有抽象字符的集合。字符是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。

字符編碼（Character Encoding）：是一套法則，使用該法則能夠對自然語言的字符的一個集合（如字母表或音節表），與其他東西的一個集合（如號碼或電脈沖）進行配對。即在符號集合與數字系統之間建立對應關系，它是信息處理的一項基本技術。通常人們用符號集合（一般情況下就是文字）來表達信息。而以計算機為基礎的信息處理系統則是利用元件（硬件）不同狀態的組合來存儲和處理信息的。元件不同狀態的組合能代表數字系統的數字，因此字符編碼就是將符號轉換為計算機可以接受的數字系統的數，稱為數字代碼。

2.常用字符集和字符編碼

常見字符集名稱：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。計算機要準確的處理各種字符集文字，需要進行字符編碼，以便計算機能夠識別和存儲各種文字。

2.1. ASCII字符集&編碼

ASCII（American Standard Code for Information Interchange，美國信息交換標準代碼）是基於拉丁字母的一套電腦編碼系統。它主要用於顯示現代英語，而其擴展版本EASCII則可以勉強顯示其他西歐語言。它是現今最通用的單字節編碼系統（但是有被Unicode追上的跡象），並等同於國際標準ISO/IEC 646。

ASCII字符集：主要包括控制字符（回車鍵、退格、換行鍵等）；可顯示字符（英文大小寫字符、阿拉伯數字和西文符號）。

ASCII編碼：將ASCII字符集轉換為計算機可以接受的數字系統的數的規則。使用7位（bits）表示一個字符，共128字符；但是7位編碼的字符集只能支持128個字符，為了表示更多的歐洲常用字符對ASCII進行了擴展，ASCII擴展字符集使用8位（bits）表示一個字符，共256字符。ASCII字符集映射到數字編碼規則如下圖所示：

圖1 ASCII編碼表

圖2 擴展ASCII編碼表

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

2.2. GBXXXX字符集&編碼

計算機發明之處及後面很長一段時間，只用應用於美國及西方一些發達國家，ASCII能夠很好滿足用戶的需求。但是當天朝也有了計算機之後，為了顯示中文，必須設計一套編碼規則用於將漢字轉換為計算機可以接受的數字系統的數。

天朝專家把那些127號之後的奇異符號們（即EASCII）取消掉，規定：一個小於127的字符的意義與原來相同，但兩個大於127的字符連在一起時，就表示一個漢字，前面的一個字節（他稱之為高字節）從0xA1用到 0xF7，後面一個字節（低字節）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裏，還把數學符號、羅馬希臘的 字母、日文的假名們都編進去了，連在ASCII裏本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼，這就是常說的"全角"字符，而原來在127號以下的那些就叫"半角"字符了。

上述編碼規則就是GB2312。GB2312或GB2312-80是中國國家標準簡體中文字符集，全稱《信息交換用漢字編碼字符集·基本集》，又稱GB0，由中國國家標準總局發布，1981年5月1日實施。GB2312編碼通行於中國大陸；新加坡等地也采用此編碼。中國大陸幾乎所有的中文系統和國際化的軟件都支持GB2312。GB2312的出現，基本滿足了漢字的計算機處理需要，它所收錄的漢字已經覆蓋中國大陸99.75%的使用頻率。對於人名、古漢語等方面出現的罕用字，GB2312不能處理，這導致了後來GBK及GB 18030漢字字符集的出現。下圖是GB2312編碼的開始部分（由於其非常龐大，只列舉開始部分，具體可查看GB2312簡體中文編碼表）：

圖3 GB2312編碼表的開始部分

由於GB 2312-80只收錄6763個漢字，有不少漢字，如部分在GB 2312-80推出以後才簡化的漢字（如"啰"），部分人名用字（如中國前總理朱镕基的"镕"字），臺灣及香港使用的繁體字，日語及朝鮮語漢字等，並未有收錄在內。於是廠商微軟利用GB 2312-80未使用的編碼空間，收錄GB 13000.1-93全部字符制定了GBK編碼。根據微軟資料，GBK是對GB2312-80的擴展，也就是CP936字碼表 (Code Page 936)的擴展（之前CP936和GB 2312-80一模一樣），最早實現於Windows 95簡體中文版。雖然GBK收錄GB 13000.1-93的全部字符，但編碼方式並不相同。GBK自身並非國家標準，只是曾由國家技術監督局標準化司、電子工業部科技與質量監督司公布為"技術規範指導性文件"。原始GB13000一直未被業界采用，後續國家標準GB18030技術上兼容GBK而非GB13000。

GB 18030，全稱：國家標準GB 18030-2005《信息技術 中文編碼字符集》，是中華人民共和國現時最新的內碼字集，是GB 18030-2000《信息技術 信息交換用漢字編碼字符集 基本集的擴充》的修訂版。與GB 2312-1980完全兼容，與GBK基本兼容，支持GB 13000及Unicode的全部統一漢字，共收錄漢字70244個。GB 18030主要有以下特點：

• 與UTF-8相同，采用多字節編碼，每個字可以由1個、2個或4個字節組成。
• 編碼空間龐大，最多可定義161萬個字符。
• 支持中國國內少數民族的文字，不需要動用造字區。

• 漢字收錄範圍包含繁體漢字以及日韓漢字

  

  圖4 GB18030編碼總體結構

  本規格的初版使中華人民共和國信息產業部電子工業標準化研究所起草，由國家質量技術監督局於2000年3月17日發布。現行版本為國家質量監督檢驗總局和中國國家標準化管理委員會於2005年11月8日發布，2006年5月1日實施。此規格為在中國境內所有軟件產品支持的強制規格。

  2.3. BIG5字符集&編碼

  Big5，又稱為大五碼或五大碼，是使用繁體中文（正體中文）社區中最常用的電腦漢字字符集標準，共收錄13,060個漢字。中文碼分為內碼及交換碼兩類，Big5屬中文內碼，知名的中文交換碼有CCCII、CNS11643。Big5雖普及於臺灣、香港與澳門等繁體中文通行區，但長期以來並非當地的國家標準，而只是業界標準。倚天中文系統、Windows等主要系統的字符集都是以Big5為基準，但廠商又各自增加不同的造字與造字區，派生成多種不同版本。2003年，Big5被收錄到CNS11643中文標準交換碼的附錄當中，取得了較正式的地位。這個最新版本被稱為Big5-2003。

  Big5碼是一套雙字節字符集，使用了雙八碼存儲方法，以兩個字節來安放一個字。第一個字節稱為"高位字節"，第二個字節稱為"低位字節"。"高位字節"使用了0x81-0xFE，"低位字節"使用了0x40-0x7E，及0xA1-0xFE。在Big5的分區中：

  0x8140-0xA0FE

  保留給用戶自定義字符（造字區）

  0xA140-0xA3BF

  標點符號、希臘字母及特殊符號，包括在0xA259-0xA261，安放了九個計量用漢字：兙兛兞兝兡兣嗧瓩糎。

  0xA3C0-0xA3FE

  保留。此區沒有開放作造字區用。

  0xA440-0xC67E

  常用漢字，先按筆劃再按部首排序。

  0xC6A1-0xC8FE

  保留給用戶自定義字符（造字區）

  0xC940-0xF9D5

  次常用漢字，亦是先按筆劃再按部首排序。

  0xF9D6-0xFEFE

  保留給用戶自定義字符（造字區）

  Unicode字符集&UTF編碼

  3.偉大的創想Unicode

  ——不得不單獨說Unicode

  像天朝一樣，當計算機傳到世界各個國家時，為了適合當地語言和字符，設計和實現類似GB232/GBK/GB18030/BIG5的編碼方案。這樣各搞一套，在本地使用沒有問題，一旦出現在網絡中，由於不兼容，互相訪問就出現了亂碼現象。

  為了解決這個問題，一個偉大的創想產生了——Unicode。Unicode編碼系統為表達任意語言的任意字符而設計。它使用4字節的數字來表達每個字母、符號，或者表意文字(ideograph)。每個數字代表唯一的至少在某種語言中使用的符號。（並不是所有的數字都用上了，但是總數已經超過了65535，所以2個字節的數字是不夠用的。）被幾種語言共用的字符通常使用相同的數字來編碼，除非存在一個在理的語源學(etymological)理由使不這樣做。不考慮這種情況的話，每個字符對應一個數字，每個數字對應一個字符。即不存在二義性。不再需要記錄"模式"了。U+0041總是代表‘A‘，即使這種語言沒有‘A‘這個字符。

  在計算機科學領域中，Unicode（統一碼、萬國碼、單一碼、標準萬國碼）是業界的一種標準，它可以使電腦得以體現世界上數十種文字的系統。Unicode 是基於通用字符集（Universal Character Set）的標準來發展，並且同時也以書本的形式^[1]對外發表。Unicode 還不斷在擴增， 每個新版本插入更多新的字符。直至目前為止的第六版，Unicode 就已經包含了超過十萬個字符（在2005年，Unicode 的第十萬個字符被采納且認可成為標準之一）、一組可用以作為視覺參考的代碼圖表、一套編碼方法與一組標準字符編碼、一套包含了上標字、下標字等字符特性的枚舉等。Unicode 組織（The Unicode Consortium）是由一個非營利性的機構所運作，並主導 Unicode 的後續發展，其目標在於：將既有的字符編碼方案以Unicode 編碼方案來加以取代，特別是既有的方案在多語環境下，皆僅有有限的空間以及不兼容的問題。

  （可以這樣理解：Unicode是字符集，UTF-32/ UTF-16/ UTF-8是三種字符編碼方案。）

  3.1.UCS & UNICODE

  通用字符集（Universal Character Set，UCS）是由ISO制定的ISO 10646（或稱ISO/IEC 10646）標準所定義的標準字符集。歷史上存在兩個獨立的嘗試創立單一字符集的組織，即國際標準化組織（ISO）和多語言軟件制造商組成的統一碼聯盟。前者開發的 ISO/IEC 10646 項目，後者開發的統一碼項目。因此最初制定了不同的標準。

  1991年前後，兩個項目的參與者都認識到，世界不需要兩個不兼容的字符集。於是，它們開始合並雙方的工作成果，並為創立一個單一編碼表而協同工作。從Unicode 2.0開始，Unicode采用了與ISO 10646-1相同的字庫和字碼；ISO也承諾，ISO 10646將不會替超出U+10FFFF的UCS-4編碼賦值，以使得兩者保持一致。兩個項目仍都存在，並獨立地公布各自的標準。但統一碼聯盟和ISO/IEC JTC1/SC2都同意保持兩者標準的碼表兼容，並緊密地共同調整任何未來的擴展。在發布的時候，Unicode一般都會采用有關字碼最常見的字型，但ISO 10646一般都盡可能采用Century字型。

  3.2.UTF-32

  上述使用4字節的數字來表達每個字母、符號，或者表意文字(ideograph)，每個數字代表唯一的至少在某種語言中使用的符號的編碼方案，稱為UTF-32。UTF-32又稱UCS-4是一種將Unicode字符編碼的協定，對每個字符都使用4字節。就空間而言，是非常沒有效率的。

  這種方法有其優點，最重要的一點就是可以在常數時間內定位字符串裏的第N個字符，因為第N個字符從第4×Nth個字節開始。雖然每一個碼位使用固定長定的字節看似方便，它並不如其它Unicode編碼使用得廣泛。

  3.3.UTF-16

  盡管有Unicode字符非常多，但是實際上大多數人不會用到超過前65535個以外的字符。因此，就有了另外一種Unicode編碼方式，叫做UTF-16(因為16位 = 2字節)。UTF-16將0–65535範圍內的字符編碼成2個字節，如果真的需要表達那些很少使用的"星芒層(astral plane)"內超過這65535範圍的Unicode字符，則需要使用一些詭異的技巧來實現。UTF-16編碼最明顯的優點是它在空間效率上比UTF-32高兩倍，因為每個字符只需要2個字節來存儲（除去65535範圍以外的），而不是UTF-32中的4個字節。並且，如果我們假設某個字符串不包含任何星芒層中的字符，那麽我們依然可以在常數時間內找到其中的第N個字符，直到它不成立為止這總是一個不錯的推斷。其編碼方法是：

• 如果字符編碼U小於0x10000，也就是十進制的0到65535之內，則直接使用兩字節表示；

• 如果字符編碼U大於0x10000，由於UNICODE編碼範圍最大為0x10FFFF，從0x10000到0x10FFFF之間 共有0xFFFFF個編碼，也就是需要20個bit就可以標示這些編碼。用U‘表示從0-0xFFFFF之間的值，將其前 10 bit作為高位和16 bit的數值0xD800進行 邏輯or 操作，將後10 bit作為低位和0xDC00做 邏輯or 操作，這樣組成的 4個byte就構成了U的編碼。

  對於UTF-32和UTF-16編碼方式還有一些其他不明顯的缺點。不同的計算機系統會以不同的順序保存字節。這意味著字符U+4E2D在UTF-16編碼方式下可能被保存為4E 2D或者2D 4E，這取決於該系統使用的是大尾端(big-endian)還是小尾端(little-endian)。（對於UTF-32編碼方式，則有更多種可能的字節排列。）只要文檔沒有離開你的計算機，它還是安全的——同一臺電腦上的不同程序使用相同的字節順序(byte order)。但是當我們需要在系統之間傳輸這個文檔的時候，也許在萬維網中，我們就需要一種方法來指示當前我們的字節是怎樣存儲的。不然的話，接收文檔的計算機就無法知道這兩個字節4E 2D表達的到底是U+4E2D還是U+2D4E。

  為了解決這個問題，多字節的Unicode編碼方式定義了一個"字節順序標記(Byte Order Mark)"，它是一個特殊的非打印字符，你可以把它包含在文檔的開頭來指示你所使用的字節順序。對於UTF-16，字節順序標記是U+FEFF。如果收到一個以字節FF FE開頭的UTF-16編碼的文檔，你就能確定它的字節順序是單向的(one way)的了；如果它以FE FF開頭，則可以確定字節順序反向了。

  3.4.UTF-8

  UTF-8（8-bit Unicode Transformation Format）是一種針對Unicode的可變長度字符編碼（定長碼），也是一種前綴碼。它可以用來表示Unicode標準中的任何字符，且其編碼中的第一個字節仍與ASCII兼容，這使得原來處理ASCII字符的軟件無須或只須做少部份修改，即可繼續使用。因此，它逐漸成為電子郵件、網頁及其他存儲或傳送文字的應用中，優先采用的編碼。互聯網工程工作小組（IETF）要求所有互聯網協議都必須支持UTF-8編碼。

  UTF-8使用一至四個字節為每個字符編碼：

1. 128個US-ASCII字符只需一個字節編碼（Unicode範圍由U+0000至U+007F）。
2. 帶有附加符號的拉丁文、希臘文、西裏爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要二個字節編碼（Unicode範圍由U+0080至U+07FF）。
3. 其他基本多文種平面（BMP）中的字符（這包含了大部分常用字）使用三個字節編碼。

4. 其他極少使用的Unicode輔助平面的字符使用四字節編碼。

   在處理經常會用到的ASCII字符方面非常有效。在處理擴展的拉丁字符集方面也不比UTF-16差。對於中文字符來說，比UTF-32要好。同時，（在這一條上你得相信我，因為我不打算給你展示它的數學原理。）由位操作的天性使然，使用UTF-8不再存在字節順序的問題了。一份以utf-8編碼的文檔在不同的計算機之間是一樣的比特流。

   總體來說，在Unicode字符串中不可能由碼點數量決定顯示它所需要的長度，或者顯示字符串之後在文本緩沖區中光標應該放置的位置；組合字符、變寬字體、不可打印字符和從右至左的文字都是其歸因。所以盡管在UTF-8字符串中字符數量與碼點數量的關系比UTF-32更為復雜，在實際中很少會遇到有不同的情形。

   優點

• UTF-8是ASCII的一個超集。因為一個純ASCII字符串也是一個合法的UTF-8字符串，所以現存的ASCII文本不需要轉換。為傳統的擴展ASCII字符集設計的軟件通常可以不經修改或很少修改就能與UTF-8一起使用。
• 使用標準的面向字節的排序例程對UTF-8排序將產生與基於Unicode代碼點排序相同的結果。（盡管這只有有限的有用性，因為在任何特定語言或文化下都不太可能有仍可接受的文字排列順序。）
• UTF-8和UTF-16都是可擴展標記語言文檔的標準編碼。所有其它編碼都必須通過顯式或文本聲明來指定。
• 任何面向字節的字符串搜索算法都可以用於UTF-8的數據（只要輸入僅由完整的UTF-8字符組成）。但是，對於包含字符記數的正則表達式或其它結構必須小心。

• UTF-8字符串可以由一個簡單的算法可靠地識別出來。就是，一個字符串在任何其它編碼中表現為合法的UTF-8的可能性很低，並隨字符串長度增長而減小。舉例說，字符值C0,C1,F5至FF從來沒有出現。為了更好的可靠性，可以使用正則表達式來統計非法過長和替代值（可以查看W3 FAQ: Multilingual Forms上的驗證UTF-8字符串的正則表達式）。

  缺點

  因為每個字符使用不同數量的字節編碼，所以尋找串中第N個字符是一個O(N)復雜度的操作 — 即，串越長，則需要更多的時間來定位特定的字符。同時，還需要位變換來把字符編碼成字節，把字節解碼成字符。

  4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language

  在HTTP中，與字符集和字符編碼相關的消息頭是Accept-Charset/Content-Type，另外主區區分Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language：

  Accept-Charset：瀏覽器申明自己接收的字符集，這就是本文前面介紹的各種字符集和字符編碼，如gb2312，utf-8（通常我們說Charset包括了相應的字符編碼方案）；

  Accept-Encoding：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什麽壓縮方法（gzip，deflate），（註意：這不是只字符編碼）；

  Accept-Language：瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等；

  Content-Type：WEB服務器告訴瀏覽器自己響應的對象的類型和字符集。例如：Content-Type: text/html; charset=‘gb2312‘

  Content-Encoding：WEB服務器表明自己使用了什麽壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip

  Content-Language：WEB服務器告訴瀏覽器自己響應的對象的語言。

補充內容

iso8859-1

最早的編碼是iso8859-1，和ascii編碼相似。但為了方便表示各種各樣的語言，逐漸出現了很多編碼。iso8859-1屬於單字節編碼，最多能表示的字符範圍是0-255，應用於英文系列。比如，字母a的編碼為0x61=97。很明顯，iso8859-1表示的字符範圍很窄，無法表示中文字符。但是，由於是單字節編碼，和計算機最基礎的表示單位一致，所以很多時候，仍舊使用iso8859-1編碼來表示。而且在很多協議上，默認使用該編碼。比如，雖然"中文"兩個字不存在iso8859-1編碼，以gb2312編碼為例，應該是"d6d0 cec4"兩個字符，使用iso8859-1編碼的時候則將它拆開為4個字節來表示："d6 d0 ce c4"（事實上，在進行存儲的時候，也是以字節為單位處理的）。而如果是UTF編碼，則是6個字節"e4 b8 ad e6 96 87"。很明顯，這種表示還需要以另一種編碼為基礎。

漢字編碼:
* GB2312字集是簡體字集，全稱為GB2312(80)字集，共包括國標簡體漢字6763個。
* BIG5字集是臺灣繁體字集，共包括國標繁體漢字13053個。
* GBK字集是簡繁字集，包括了GB字集、BIG5字集和一些符號，共包括21003個字符。
* GB18030是國家制定的一個強制性大字集標準，全稱為GB18030-2000，它的推出使漢字集有了一個“大一統”的標準。

UCS:
通用字符集(Universal Character Set，UCS)是由ISO制定的ISO 10646(或稱ISO/IEC 10646)標準所定義的字符編碼方式，采用4字節編碼。
UCS包含了已知語言的所有字符。
除了拉丁語、希臘語、斯拉夫語、希伯來語、阿拉伯語、亞美尼亞語、格魯吉亞語，還包括中文、日文、韓文這樣的象形文字，UCS還包括大量的圖形、印刷、數學、科學符號。
* UCS-2: 與unicode的2byte編碼基本一樣。
* UCS-4: 4byte編碼, 目前是在UCS-2前加上2個全零的byte。

MIME：

通用因特網郵件擴充協議，它設計的最初目的是為了在發送電子郵件時附加多媒體數據，讓郵件客戶程序能根據其類型進行處理。然而當它被HTTP協議支持之後，它的意義就更為顯著了。它使得HTTP傳輸的不僅是普通的文本，而變得豐富多彩。

因為在因特網上郵件發送協議SMTP存在幾個缺點，主要是不能發送可執行文件和其他的二進制文件，只限於傳送7位的ASCII碼，因此MIME協議起初用於解決該問題，即是在傳送二進制數據時先通過MIME轉換成SMTP可傳送的ACSII碼，接收時再通過MIME還原成原始的二進制碼。為此SMTP也響應增加了MIME-version、content-type等5個新的首部。

其中首部Content-transfer-encoding的值有5種----"7bit"、"8bit"、"binary"、"quoted-printable"和"base64"----其中"7bit"是缺省值，即不用轉化的ASCII字符。真正常用是"quoted-printable"和"base64"兩種，用以指明編碼轉換的方式。

MIME_type類型語法：
media-type=type/subtype
媒體類型(type)與子類型(subtype)組成了MIME，它們之間使用反斜杠/分割，其中type可取值為：application audio example image message model multipart text video，subtype是某種類型的唯一標識符，比如：css gif xml等。
常見的MIME類型：
超文本標記語言文本 .html,.html text/html
普通文本 .txt text/plain
RTF文本 .rtf application/rtf
GIF圖形 .gif image/gif
JPEG圖形 .ipeg,.jpg image/jpeg
au聲音文件 .au audio/basic
MIDI音樂文件 mid,.midi audio/midi,audio/x-midi
RealAudio音樂文件 .ra,.ram audio/x-pn-realaudio
MPEG文件 .mpg,.mpeg video/mpeg
AVI文件 .avi video/x-msvideo
GZIP文件 .gz application/x-gzip
TAR文件 .tar application/x-tar

quoted-printable：

主要用於ACSII文本中夾雜少量非ASCII碼字符的情況，不適合於轉換純二進制文件。它規定將每一個8位的字節，轉換為3個字符。第一個字符是"="號，這是固定不變的。

後面二個字符是二個十六進制數，分別代表了這個字節前四位和後四位的數值。舉例來說，ASCII碼中"換頁鍵"（form feed）是12，二進制形式是00001100，寫成十六進制就是0C，因此它的編碼值為"=0C"。"="號的ASCII值是61，二進制形式是00111101，因為它的編碼值是"=3D"。除了可打印的ASCII碼以外，所有其他字符都必須用這種方式進行轉換。

所有可打印的ASCII碼字符（十進制值從33到126）都保持原樣不變，"="（十進制值61）除外。

base64：

所謂Base64，就是說選出64個字符----小寫字母a-z、大寫字母A-Z、數字0-9、符號"+"、"/"（再加上作為墊字的"="，實際上是65個字符）----作為一個基本字符集。然後，其他所有符號都轉換成這個字符集中的字符。具體來說，轉換方式可以分為四步：

第一步，將每三個字節作為一組，一共是24個二進制位。

第二步，將這24個二進制位分為四組，每個組有6個二進制位。

第三步，在每組前面加兩個00，擴展成32個二進制位，即四個字節。

第四步，根據下表，得到擴展後的每個字節的對應符號，這就是Base64的編碼值。

如果字節數不足三，則這樣處理：

a）二個字節的情況：將這二個字節的一共16個二進制位，按照上面的規則，轉成三組，最後一組除了前面加兩個0以外，後面也要加兩個0。這樣得到一個三位的Base64編碼，再在末尾補上一個"="號。比如，"Ma"這個字符串是兩個字節，可以轉化成三組00010011、00010110、00010000以後，對應Base64值分別為T、W、E，再補上一個"="號，因此"Ma"的Base64編碼就是TWE=。

b）一個字節的情況：將這一個字節的8個二進制位，按照上面的規則轉成二組，最後一組除了前面加二個0以外，後面再加4個0。這樣得到一個二位的Base64編碼，再在末尾補上兩個"="號。比如，"M"這個字母是一個字節，可以轉化為二組00010011、00010000，對應的Base64值分別為T、Q，再補上二個"="號，因此"M"的Base64編碼就是TQ==。

字符集和字符編碼（Charset & Encoding）