由於歷史原因，Internet 上有些郵件系統只支援 7Bit 的傳輸
而亞洲語系 CJK (Chinese/Japanese/Korean) 的編碼是 8Bit 的
當在電子郵件中發送 CJK 時， 如果通過這些只支援 7Bit 字元的郵件系統
便會將 CJK 的第八位元的 1 全部變成 0。

以 “中文” 兩字為例，十六進位為 A4A4A4E5
當最 HSB 被清掉時就會變成 24242465
也就是 “$$$e”。
(telnet 也存在這樣子的問題。所以我們會在 telnet 後面加上參數 “-8” )

除了 CJK 郵件外，使用電子郵件傳送圖片、程式、 壓縮文件等也會發生這個問題。
所以在電子郵件中一般採用各種郵件編碼方式來解決這個問題，
將 8Bit 按照一定的規則進行編碼， 便可以完整地通過只支援 7Bit 位元的郵件系統。

常見的郵件編碼有 UU 與 MIME：
而 MIME (Multipurpose Internet Mail Extentions) 一般翻譯成「多媒體傳送模式」
顧名思義，它標榜的就是可以傳送多媒體型式的檔案
可以在一封mail中附加各種型式檔案一起送出。

MIME 定義兩種編碼方法：Base64 與QP(Quote-Printable)， 兩者使用時機不同，QP 的規則是對於資料中的7bits無須重複 encode， 僅8bits資料轉成 7bits。
QP編碼適用於非 US-ASCII 的文字內容， 例如 CJK，而Base64的編碼規則，是將整個檔案重新編碼， 編成7bits，它是用於傳送binary檔案時使用。
由於編碼的方式不同，會影響編碼之後的檔案大小。
有些較懶惰的軟體便都一律採用 Base64 編碼了。

含有 MIME 編碼的文件，查看它的 header ，一般都含有：

“This is a multi-part message in MIME format.”

這樣的句子。

UU 編碼 (uuencode與uudecode)
UU 是指 Unix 之間傳送二進制文件，就是 Unix to Unix。 使用 uuencode 將檔案編成 7Bit ASCII 檔案，把它寄出， 收信人收到後，可以用 uudecode 將這份資料還原為原來的檔案。

begin 644 remotefile
…….
..略…
…….
end

QP – Quote-Printable
Content-Transfer-Encoding: quoted-printable
QP編碼的方式，是將一個字元用二個16進位法的數值表示， 然後前面再加個「=」字元（等號）：

% echo “中文” | mmencode -q
=A4=A4=A4=E5
% echo “=A4=A4=A4=E5” | mmencode -q -u
中文

BASE64
Content-Transfer-Encoding: BASE64

BASE64 的算法很簡單，它將 character stream 順序放入一個 24 位的緩衝區
缺字的地方補零。
然後將緩衝區截斷成 4 個部分，高位在先， 每個部分 6 位，用下面的64個字符重新表示：

“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/”

如果輸入只有一個或兩個 byte，那麼輸出將用等號 “=” 補足。
還可以隔斷附加的信息造成編碼的混亂。這就是 BASE64。

% echo “中文” | mmencode
pKSk5Qo=
% echo “pKSk5Qo=” | mmencode -u
中文

其他亂碼
以 “中文” 兩字為例，整理一下以上的編碼會出現的狀況：
uuencode：%I*2DY0KQ
QP：=A4=A4=A4=E5
BASE64：pKSk5Qo=

以及其他語言性的轉碼可能出現的狀況：
GB2312：笢恅(iconv -t GB2312)
Unicode：U+4E2D U+6587
UCS-2：N-e(iconv -t UCS-2)
UTF-7：+Ti1lhw(iconv -t UTF-7)
UTF-8：銝剜??(iconv -t UTF-8)
UTF-16：??N-e?(iconv -t UTF16)
UTF-32：??N-e?(iconv -t UTF32)
CNS11643：1-4463 1-4546
CCCII：213034 214258