從基礎的開始
最小的單元是位（bit），接著是位元組（Byte），一個位元組=8位，英語表示是1 byte=8 bits 。機器語言的單位Byte。接著是KB，1 KB=1024 Byte; 接著是MB，1 MB=1024 KB; 接著是GB，1 GB=1024 MB ;接著是TB, 1TB=1024 GB。
接著是進制：二進制0和1，8進制0-7， 十進制不用說，16進制0-9後面是A,B,C,D,E,F 他們關係如下：
Binary Octal Decimal Hex
0 0 0 00
1 1 1 1
10 2 2 2
11 3 3 3
100 4 4 4
101 5 5 5
110 6 6 6
111 7 7 7
1000 10 8 8
1001 11 9 9
1010 12 10 A
1011 13 11 B
1100 14 12 C
1101 15 13 D
1110 16 14 E
1111 17 15 F
接著是上層建築字元：
字元是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。字元集是多個字元的集合，字元集種類較多，每個字元集包含的字元個數不同，常見字元集名稱：ASCII字元集、GB2312字元集、BIG5字元集、 GB 18030字元集、Unicode字元集等。計算機要準確的處理各種字元集文字，需要進行字元編碼，以便計算機能夠識別和存儲各種文字。
ASCII 字元集
ASCII（American Standard Code for Information Interchange，美國信息互換標準代碼）是基於羅馬字母表的一套電腦編碼系統，它主要用於顯示現代英語和其他西歐語言。它是現今最通用的單位元組編碼系統，並等同於國際標準ISO 646。
包含內容：
控制字元：回車鍵、退格、換行鍵等。
可顯示字元：英文大小寫字元、阿拉伯數字和西文符號
ASCII擴展字元集擴展：表格符號、計算符號、希臘字母和特殊的拉丁符號。
第0～31號及第127號(共33個)是控制字元或通訊專用字元，如控制符：LF（換行）、CR（回車）、FF（換頁）、DEL（刪除）、BEL（振鈴）等；通訊專用字元：SOH（文頭）、EOT（文尾）、ACK（確認）等；
第32～126號(共94個)是字元，其中第48～57號為0～9十個阿拉伯數字；65～90號為26個大寫英文字母，97～122號為26個小寫英文字母，其餘為一些標點符號、運算符號等。
注意：在計算機的存儲單元中，一個ASCII碼值占一個位元組(8個二進制位)，其最高位(b7)用作奇偶校驗位。所謂奇偶校驗，是指在代碼傳送過程中用來檢驗是否出現錯誤的一種方法，一般分奇校驗和偶校驗兩種。奇校驗規定：正確的代碼一個位元組中1的個數必須是奇數，若非奇數，則在最高位b7添1；偶校驗規定：正確的代碼一個位元組中1的個數必須是偶數，若非偶數，則在最高位b7添1。
DEC HEX CHAR CODE C 程式（轉義）
0 00 NUL （’\0’）
1 01 SOH
2 02 STX
3 03 ETX
4 04 EOT
5 05 ENQ
6 06 ACK
7 07 BEL （’\a’）
8 08 BS （’\b’）
9 09 HT （’\t’）
10 0A LF （’\n’）
11 0B VT （’\v’）
12 0C FF （’\f’）
13 0D CR （’\r’）
14 0E SO
15 0F SI
16 10 DLE
17 11 DC1
18 12 DC2
19 13 DC1
20 14 DC4
21 15 NAK
22 16 SYN
23 17 ETB
24 18 CAN
25 19 EM
26 1A SUB
27 1B ESC
28 1C FS
29 1D GS
30 1E RS
31 1F US
32 20 (space，空格)
33 21 !
34 22 "
35 23 #
36 24 $
37 25 %
38 26 &
39 27 ’
40 28 (
41 29 )
42 2A *
43 2B +
44 2C ,
45 2D -
46 2E .
47 2F /
48 30 0
49 31 1
50 32 2
51 33 3
52 34 4
53 35 5
54 36 6
55 37 7
56 38 8
57 39 9
58 3A :
59 3B ;
60 3C <
61 3D =
62 3E >
63 3F ?
64 40 @
65 41 A
66 42 B
67 43 C
68 44 D
69 45 E
70 46 F
71 47 G
72 48 H
73 49 I
74 4A J
75 4B K
76 4C L
77 4D M
78 4E N
79 4F O
80 50 P
81 51 Q
82 52 R
83 53 S
84 54 T
85 55 U
86 56 V
87 57 W
88 58 X
89 59 Y
90 5A Z
91 5B [
92 5C \ （’\\’）
93 5D ]
94 5E ^
95 5F _
96 60 `
97 61 a
98 62 b
99 63 c
100 64 d
101 65 e
102 66 f
103 67 g
104 68 h
105 69 i
106 6A j
107 6B k
108 6C l
109 6D m
110 6E n
111 6F o
112 70 p
113 71 q
114 72 r
115 73 s
116 74 t
117 75 u
118 76 v
119 77 w
120 78 x
121 79 y
122 7A z
123 7B {
124 7C |
125 7D }
126 7E ~
127 7F DEL
GB2312 字元集
GB2312又稱為GB2312-80字元集，全稱為《信息交換用漢字編碼字元集・基本集》，由原中國國家標準總局發布，1981年5月1日實施，是中國國家標準的簡體中文字元集。它所收錄的漢字已經覆蓋99.75%的使用頻率，基本滿足了漢字的計算機處理需要。在中國大陸和新加坡獲廣泛使用。
GB2312收錄簡化漢字及一般符號、序號、數字、拉丁字母、日文假名、希臘字母、俄文字母、漢語拼音符號、漢語注音字母，共 7445 個圖形字元。其中包括6763個漢字，其中一級漢字3755個，二級漢字3008個；包括拉丁字母、希臘字母、日文平假名及片假名字母、俄語西里爾字母在內的682個全形字元。
GB2312中對所收漢字進行了“分區”處理，每區含有94個漢字/符號。這種表示方式也稱為區位碼。
它是用雙位元組表示的，兩個位元組中前面的位元組為第一位元組，後面的位元組為第二位元組。習慣上稱第一位元組為“高位元組” ，而稱第二位元組為“低位元組”。“高位位元組”使用了0xA1-0xF7(把01-87區的區號加上0xA0)，“低位位元組”使用了0xA1-0xFE(把01-94加上0xA0)。
以GB2312字元集的第一個漢字“啊”字為例，它的區號16，位號01，則區位碼是1601，在大多數電腦程式中，高位元組和低位元組分別加0xA0得到程式的漢字處理編碼0xB0A1。計算公式是：0xB0=0xA0+16, 0xA1=0xA0+1。
GBK字元集
GBK字元集是GB2312的擴展(K)，GBK1.0收錄了21886個符號，它分為漢字區和圖形符號區，漢字區包括21003個字元。GBK字元集主要擴展了繁體中文字的支持。
BIG5 字元集
BIG5又稱大五碼或五大碼，1984年由台灣財團法人信息工業策進會和五間軟體公司宏� (Acer)、神通 (MiTAC)、佳佳、零壹 (Zero One)、大眾 (FIC)創立，故稱大五碼。Big5碼的產生，是因為當時台灣不同廠商各自推出不同的編碼，如倚天碼、IBM PS55、王安碼等，彼此不能兼容；另一方面，台灣政府當時尚未推出官方的漢字編碼，而中國大陸的GB2312編碼亦未有收錄繁體中文字。
Big5字元集共收錄13,053箇中文字，該字元集在中國台灣使用。耐人尋味的是該字元集重複地收錄了兩個相同的字：“兀”(0xA461及0xC94A)、“�”(0xDCD1及0xDDFC)。
Big5碼使用了雙位元組儲存方法，以兩個位元組來編碼一個字。第一個位元組稱為“高位位元組”，第二個位元組稱為“低位位元組”。高位位元組的編碼範圍0xA1-0xF9，低位位元組的編碼範圍0x40-0x7E及0xA1-0xFE。
儘管Big5碼內包含一萬多個字元，但是沒有考慮社會上流通的人名、地名用字、方言用字、化學及生物科等用字，沒有包含日文平假名及片假字母。
例如台灣視“著”為“著”的異體字，故沒有收錄“著”字。康熙字典中的一些部首用字(如“亠”、“疒”、“�”、“�”等)、常見的人名用字(如“�”、“煊”、“�”、“�”等) 也沒有收錄到Big5之中。
GB18030 字元集
GB18030的全稱是GB18030-2000《信息交換用漢字編碼字元集基本集的擴充》，是我國政府於2000年3月17日發布的新的漢字編碼國家標準，2001年8月31日後在中國市場上發布的軟體必須符合本標準。GB 18030字元集標準的出台經過廣泛參與和論證，來自國內外知名信息技術行業的公司，信息產業部和原國家質量技術監督局聯合實施。
GB 18030字元集標準解決漢字、日文假名、朝鮮語和中國少數民族文字組成的大字元集計算機編碼問題。該標準的字元總編碼空間超過150萬個編碼位，收錄了27484個漢字，覆蓋中文、日文、朝鮮語和中國少數民族文字。滿足中國大陸、香港、台灣、日本和韓國等東亞地區信息交換多文種、大字量、多用途、統一編碼格式的要求。並且與Unicode 3.0版本兼容，填補Unicode擴展字元字彙“統一漢字擴展A”的內容。並且與以前的國家字元編碼標準（GB2312，GB13000.1）兼容。
編碼方法：
GB 18030標準採用單位元組、雙位元組和四位元組三種方式對字元編碼。單位元組部分使用0×00至0×7F碼(對應於ASCII碼的相應碼)。雙位元組部分，首位元組碼從0×81至0×FE，尾位元組碼位分別是0×40至0×7E和0×80至0×FE。四位元組部分採用GB/T 11383未採用的0×30到0×39作為對雙位元組編碼擴充的後綴，這樣擴充的四位元組編碼，其範圍為0×81308130到0×FE39FE39。其中第一、三個位元組編碼碼位均為0×81至0×FE，第二、四個位元組編碼碼位均為0×30至0×39。
按照程式設計師的稱呼，GB2312、GBK到GB18030都屬於雙位元組字元集 (DBCS)。
接著是國際通用的unicode字元集
ANSI編碼
不同的國家和地區制定了不同的標準，由此產生了 GB2312, BIG5, JIS 等各自的編碼標準。這些使用 2 個位元組來代表一個字元的各種漢字延伸編碼方式，稱為 ANSI 編碼。在簡體中文系統下，ANSI 編碼代表 GB2312 編碼，在日文作業系統下，ANSI 編碼代表 JIS 編碼。
Unicode字元集（簡稱為UCS）
1．名稱的由來
Unicode字元集編碼是（Universal Multiple-Octet Coded Character Set） 通用多八位編碼字元集的簡稱，支持世界上超過650種語言的國際字元集。Unicode允許在同一伺服器上混合使用不同語言組的不同語言。它是由一個名為 Unicode 學術學會(Unicode Consortium)的機構制訂的字元編碼系統，支持現今世界各種不同語言的書面文本的交換、處理及顯示。該編碼於1990年開始研發，1994年正式公布，最新版本是2005年3月31日的Unicode 4.1.0。Unicode是一種在計算機上使用的字元編碼。它為每種語言中的每個字元設定了統一併且唯一的二進制編碼，以滿足跨語言、跨平台進行文本轉換、處理的要求。
2．編碼方法
Unicode 標準始終使用十六進制數字，而且在書寫時在前面加上前綴“U+”，例如字母“A”的編碼為 004116 。所以“A”的編碼書寫為“U+0041”。
3．UTF-8 編碼
UTF-8是Unicode的其中一個使用方式。 UTF是 Unicode Translation Format，即把Unicode轉做某種格式的意思。
UTF-8便於不同的計算機之間使用網路傳輸不同語言和編碼的文字，使得雙位元組的Unicode能夠在現存的處理單位元組的系統上正確傳輸。
UTF-8使用可變長度位元組來儲存 Unicode字元，例如ASCII字母繼續使用1位元組儲存，重音文字、希臘字母或西里爾字母等使用2位元組來儲存，而常用的漢字就要使用3位元組。輔助平面字元則使用4位元組。
4．UTF-16 和 UTF-32 編碼
UTF-32、UTF-16 和 UTF-8 是 Unicode 標準的編碼字元集的字元編碼方案，UTF-16 使用一個或兩個未分配的 16 位代碼單元的序列對 Unicode 代碼點進行編碼；UTF-32 即將每一個 Unicode 代碼點表示為相同值的 32 位整數
通過一個問題了解unicode編碼
問題：使用Windows記事本的“另外儲存為”，可以在ANSI、GBK、Unicode、Unicode big endian和UTF-8這幾種編碼方式間相互轉換。同樣是txt檔案，Windows怎樣識別編碼方式的呢？
我很早前就發現Unicode、Unicode big endian和UTF-8編碼的txt檔案的開頭會多出幾個位元組，分別是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但這些標記是基於什麼標準呢？
答案：
ANSI字元集定義：ASCII字元集，以及由此派生併兼容的字元集，如：GB2312，正式的名稱為MBCS(Multi-Byte Chactacter System，多位元組字元系統)，通常也稱為ANSI字元集。
UNICODE 與 UTF8、UTF16
由於每種語言都制定了自己的字元集，導致最後存在的各種字元集實在太多，在國際交流中要經常轉換字元集非常不便。因此，產生了Unicode字元集，它固定使用16 bits(兩個位元組)來表示一個字元，共可以表示65536個字元
標準的 Unicode 稱為UTF-16(UTF:UCS Transformation Format )。後來為了雙位元組的Unicode能夠在現存的處理單位元組的系統上正確傳輸，出現了UTF-8，使用類似MBCS的方式對Unicode進行編碼。(Unicode字元集有多種編碼形式)
例如"連通"兩個字的Unicode標準編碼UTF-16 (big endian)為：DE 8F 1A 90
而其UTF-8編碼為：E8 BF 9E E9 80 9A
當一個軟體打開一個文本時，它要做的第一件事是決定這個文本究竟是使用哪種字元集的哪種編碼保存的。軟體一般採用三種方式來決定文本的字元集和編碼：
檢測檔案頭標識，提示用戶選擇，根據一定的規則猜測
最標準的途徑是檢測文本最開頭的幾個位元組，開頭位元組 Charset/encoding,如下表：
EF BB BF : UTF-8
FF FE : UTF-16/UCS-2, little endian
FE FF : UTF-16/UCS-2, big endian
FF FE 00 00 : UTF-32/UCS-4, little endian.
00 00 FE FF : UTF-32/UCS-4, big-endian.
1、big endian和little endian
big endian和little endian是CPU處理多位元組數的不同方式。例如“漢”字的Unicode編碼是6C49。那么寫到檔案里時，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。還是將49寫在前面，就是little endian。
“endian”這個詞出自《格列佛遊記》。小人國的內戰就源於吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，其中一個皇帝送了命，另一個丟了王位。
我們一般將endian翻譯成“位元組序”，將big endian和little endian稱作“大尾”和“小尾”。
2、字元編碼、內碼，順帶介紹漢字編碼
字元必須編碼後才能被計算機處理。計算機使用的預設編碼方式就是計算機的內碼。早期的計算機使用7位的ASCII編碼，為了處理漢字，程式設計師設計了用於簡體中文的GB2312和用於繁體中文的big5。
GB2312(1980年)一共收錄了7445個字元，包括6763個漢字和682個其它符號。漢字區的內碼範圍高位元組從B0-F7，低位元組從A1-FE，占用的碼位是72*94=6768。其中有5個空位是D7FA-D7FE。
GB2312支持的漢字太少。1995年的漢字擴展規範GBK1.0收錄了21886個符號，它分為漢字區和圖形符號區。漢字區包括21003個字元。2000年的GB18030是取代GBK1.0的正式國家標準。該標準收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字。現在的PC平台必須支持GB18030，對嵌入式產品暫不作要求。所以手機、MP3一般只支持GB2312。
從ASCII、GB2312、GBK到GB18030，這些編碼方法是向下兼容的，即同一個字元在這些方案中總是有相同的編碼，後面的標準支持更多的字元。在這些編碼中，英文和中文可以統一地處理。區分中文編碼的方法是高位元組的最高位不為0。按照程式設計師的稱呼，GB2312、GBK到GB18030都屬於雙位元組字元集 (DBCS)。
有的中文Windows的預設內碼還是GBK，可以通過GB18030升級包升級到GB18030。不過GB18030相對GBK增加的字元，普通人是很難用到的，通常我們還是用GBK指代中文Windows內碼。
這裡還有一些細節：
GB2312的原文還是區位碼，從區位碼到內碼，需要在高位元組和低位元組上分別加上A0。
在DBCS中，GB內碼的存儲格式始終是big endian，即高位在前。
GB2312的兩個位元組的最高位都是1。但符合這個條件的碼位只有128*128=16384個。所以GBK和GB18030的低位元組最高位都可能不是1。不過這不影響DBCS字元流的解析：在讀取DBCS字元流時，只要遇到高位為1的位元組，就可以將下兩個位元組作為一個雙位元組編碼，而不用管低位元組的高位是什麼。
3、Unicode、UCS和UTF(UCS Transformation Format)
前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下兼容的。而Unicode只與ASCII兼容（更準確地說，是與ISO-8859-1兼容），與GB碼不兼容。例如“漢”字的Unicode編碼是6C49，而GB碼是BABA。
UCS規定了怎么用多個位元組表示各種文字。而怎樣傳輸這些編碼，是由UTF(UCS Transformation Format)規範規定的！常見的UTF規範包括UTF-8、UTF-7、UTF-16。
4、UTF的位元組序和BOM
UTF-8以位元組為編碼單元，沒有位元組序的問題。UTF-16以兩個位元組為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的位元組序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16位元組流“594E”，那么這是“奎”還是“乙”？
Unicode規範中推薦的標記位元組順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：
在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字元，它的編碼是FEFF。而FFFE在UCS中是不存在的字元，所以不應該出現在實際傳輸中。UCS規範建議我們在傳輸位元組流前，先傳輸字元"ZERO WIDTH NO-BREAK SPACE"。
這樣如果接收者收到FEFF，就表明這個位元組流是Big-Endian的；如果收到FFFE，就表明這個位元組流是Little-Endian的。因此字元"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。
UTF-8不需要BOM來表明位元組順序，但可以用BOM來表明編碼方式。字元"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的位元組流，就知道這是UTF-8編碼了。
Windows就是使用BOM來標記文本檔案的編碼方式的。
寫到這裡對編碼有了大致的了解了，就可以理解網上一些文章的話了，比如有一篇很流行的文章《URL編碼與SQL注射》裡面有一段是這么說的：
其實url編碼就是一個字元ascii碼的十六進制。不過稍微有些變動，需要在前面加上“%”。比如“\”，它的ascii碼是92，92的十六進制是5c，所以“\”的url編碼就是%5c。那么漢字的url編碼呢？很簡單，看例子：“胡”的ascii碼是-17670，十六進制是BAFA，url編碼是“%BA%FA”。呵呵，知道怎么轉換的了吧。
這得從ASCII說起，擴展的ASCII字元集採用8bit255個字元顯然不夠用，於是各個國家紛紛制定了自己的文字編碼規範，其中中文的文字編碼規範叫做“GB2312-80”（就是GB2312)，它是和ASCII兼容的一種編碼規範，其實就是用擴展ASCII沒有真正標準化這一點，把一個中文字元用兩個擴展ASCII字元來表示。文中說的的中文ASCII碼實際上就是簡體中文的編碼2312GB！它把ASCII又擴充了一個位元組，由於高位的第一位是0，所以會出現負數的形式，url編碼就是將漢字的這個GB2312編碼轉化成UTF-8的編碼並且每8位即一個位元組前面加上%符號表示。
那為何UTF-8是進行網路的規範傳輸編碼呢？
在Unicode里，所有的字元被一視同仁。漢字不再使用“兩個擴展ASCII”，而是使用“1個Unicode”，注意，現在的漢字是“一個字元”了，於是，拆字、統計字數這些問題也就自然而然的解決了。但是，這個世界不是理想的，不可能在一夜之間所有的系統都使用Unicode來處理字元，所以Unicode在誕生之日，就必須考慮一個嚴峻的問題：和ASCII字元集之間的不兼容問題。
我們知道，ASCII字元是單個位元組的，比如“A”的ASCII是65。而Unicode是雙位元組的，比如“A”的Unicode是0065，這就造成了一個非常大的問題：以前處理ASCII的那套機制不能被用來處理Unicode了
另一個更加嚴重的問題是，C語言使用’\0’作為字元串結尾，而Unicode里恰恰有很多字元都有一個位元組為0，這樣一來，C語言的字元串函式將無法正常處理Unicode，除非把世界上所有用C寫的程式以及他們所用的函式館全部換掉
於是，比Unicode更偉大的東東誕生了，之所以說它更偉大是因為它讓Unicode不再存在於紙上，而是真實的存在於我們大家的電腦中。那就是：UTF
UTF= UCS Transformation Format UCS轉換格式，它是將Unicode編碼規則和計算機的實際編碼對應起來的一個規則。現在流行的UTF有2種：UTF-8和UTF-16
其中UTF-16和上面提到的Unicode本身的編碼規範是一致的，這裡不多說了。而UTF-8不同，它定義了一種“區間規則”，這種規則可以和ASCII編碼保持最大程度的兼容，這樣做的好處是壓縮了字元在西歐一些國家的記憶體消耗，減少了不必要的資源浪費，這在實際套用中是非常有必要的。
UTF-8有點類似於Haffman編碼，它將Unicode編碼為：
00000000-0000007F的字元，用單個位元組來表示；
00000080-000007FF的字元用兩個位元組表示 （中文的編碼範圍）
00000800-0000FFFF的字元用3位元組表示
因為目前為止Unicode-16規範沒有指定FFFF以上的字元，所以UTF-8最多是使用3個位元組來表示一個字元。但理論上來說，UTF-8最多需要用6位元組表示一個字元。
在UTF-8里，英文字元仍然跟ASCII編碼一樣，因此原先的函式館可以繼續使用。而中文的編碼範圍是在0080-07FF之間，因此是2個位元組表示（但這兩個位元組和GB編碼的兩個位元組是不同的）。
看看編碼之多：ANSI,AscII,GB2312,GBK,BIG5,GB18030,Unicode,UCS（就是unicode）Utf-8,utf-16,utf-32 整整10種編碼～，算是夠複雜了
可是這還僅僅是個開始，套用方面變化無窮，不過現在看到這些東西起碼再不會頭大了！呼呼～
喔，漏了一個加密的base64編碼。
什麼是Base64？
按照RFC2045的定義，Base64被定義為：Base64內容傳送編碼被設計用來把任意序列的8位位元組描述為一種不易被人直接識別的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）
為什麼要使用Base64？
在設計這個編碼的時候，我想設計人員最主要考慮了3個問題：
1.是否加密？
2.加密算法複雜程度和效率
3.如何處理傳輸？
加密是肯定的，但是加密的目的不是讓用戶傳送非常安全的Email。這種加密方式主要就是“防君子不防小人”。即達到一眼望去完全看不出內容即可。
基於這個目的加密算法的複雜程度和效率也就不能太大和太低。和上一個理由類似，MIME協定等用於傳送Email的協定解決的是如何收發Email，而並不是如何安全的收發Email。因此算法的複雜程度要小，效率要高，否則因為傳送Email而大量占用資源，路就有點走歪了。
但是，如果是基於以上兩點，那么我們使用最簡單的愷撒法即可，為什麼Base64看起來要比愷撒法複雜呢？這是因為在Email的傳送過程中，由於歷史原因，Email只被允許傳送ASCII字元，即一個8位位元組的低7位。因此，如果您傳送了一封帶有非ASCII字元（即位元組的最高位是1）的Email通過有“歷史問題”的網關時就可能會出現問題。網關可能會把最高位置為0！很明顯，問題就這樣產生了！因此，為了能夠正常的傳送Email，這個問題就必須考慮！所以，單單靠改變字母的位置的愷撒之類的方案也就不行了。關於這一點可以參考RFC2046。
基於以上的一些主要原因產生了Base64編碼。
鑒於算法比較讓人頭大，想看的人自然會有看到的辦法拉，俺是頭大得很，就不放上來了。
=====================================================================
另附推薦資源：
《字元，位元組和編碼》 http://www.regexlab.com/zh/encoding.htm
介紹：本文介紹了字元與編碼的發展過程，相關概念的正確理解。舉例說明了一些實際套用中，編碼的實現方法。然後，本文講述了通常對字元與編碼的幾種誤解，由於這些誤解而導致亂碼產生的原因，以及消除亂碼的辦法。本文的內容涵蓋了“中文問題”，“亂碼問題”。
