電子郵件的知識及亂碼的處理技巧

作為透過收錄網路熱門郵件來刻劃網路脈絡的網站站長，成天與電子郵件為伍，喜也郵件、怨也郵件。
欣喜的當然是收到分享者的來函，管它是一篇小品、影片、照片，都各有獨特的旨趣。
偶而抱怨的，就是一封封宛如火星文的亂碼郵件或洋蔥郵件。
身為網路界的一員，實在有必要讓大家更了解這類問題的始末，以圖免受其擾。

電子郵件是真實郵件的翻版
電子郵件的運作概念幾乎完全引用真實郵件的模式。
一封真實郵件具備了信封、信紙、收件人、寄件人、郵票、內容、物品、寄送模式等等，而電子郵件也差不多，只是盡可能透過數位訊號來代表實體。
•信封
電子郵件中的寄件人、收件人、主旨、寄送模式等等都被歸為信封，專用術語是 header 或稱為信件標頭。雖然在郵件主機中也有所謂 envelope 的機制，但意義上不盡相同，也與大多使用者無關。
•內容
電子郵件中的內容，包括了文字、網頁和附加檔案，專用術語是 body 或稱為信件本體。而依據資料的打包方式不同，它可能是真實郵件中的內容或物品。
•郵票？
目前大多的電子郵件是免費寄送的，但未來可不一定，有許多組織正致力於改變這個「郵」戲規則，以獲得可觀的利潤。

所以，電子郵件的基本概念就是它是由 header 和 body 所組成的資料串。

電子郵件的內容與傳遞
這點從真實郵件的寄送也能大概了解，例如信封上的地址、收件人、郵遞區號等等。這些資訊必須正確，而且用郵差看得懂的文字書寫，信件才能寄達，國內郵件如是，國外郵件亦然。
但兩者又有一些不同。
首先，電子郵件（甚至網路的發展）基本上都是由英語系國家主導的。所以，到目前為止我們還無法用中文的電子信箱來收發郵件，例如「丁昶文＠搜主意工作室」。這個問題在先前推動中文網址時，有討論過一陣子，但還是不了了之。

再者，原本的電子郵件系統是以英文語系為主的（7Bit），主因是英文字母有限，而越少的位元數，運算效能越高。而無法用文字表示的內容（像附檔），就透過編碼的方式來處理，以便讓檔案也符合 7Bit 的規範。

但是，著眼於各國文字的需求，所以才變為 8Bit（但仍只是選項，還是可以設定為7Bit）。

這個發展是很重要的！因為亂碼的問題就是大家忽略它所造成的。

電子郵件的亂碼原因
當一封電子郵件被完成後準備寄出，這時郵件編寫程式「應該」要作一系列的檢查，然後按照電子郵件的規範將內容妥善處理，然後再寄出。

這裡所謂的檢查並不是指掃毒的動作，而是上述的編碼動作，以確保電子郵件的內容都符合 8Bit 或 7Bit 的規範。這些動作包括把附加檔案轉換成文字型式以及透過特殊方式把內容編碼。

例如：原本的信件主旨「電子郵件亂碼」，被編碼後會變成「=?big5?B?uXGkbLZspfO2w71Y?=」。編碼後的字串符合 7Bit 規範，同時它也註記了內容的編碼方式，以確保電子郵件被收取後能正確的還原、顯示。

=?big5?B?uXGkbLZspfO2w71Y?=
這或許像是大家口中的亂碼，但其實這才是正確的。其中頭尾的「=」是標記符號；「?」是分隔符號，將內容分成三段；第一段「Big5」表示原內容的字集、第二段「B」表示使用 base64 編碼（一種編碼方式）、第三段 uXGkbLZspfO2w71Y 則是編碼後的內容。

因此，當你看到這類的郵件時，應該感到慶幸，因為這是有救的。但相反的，要向信件軟體設計公司抱怨，為什麼程式沒有將這樣的內容還原。

另一種常見的亂碼
這種情況就是電子郵件程式沒有按照規範設計的後果。如上所述，郵件寄發前程式應將內容進行適當的編碼。但有不少信件程式（尤其是網站發出的信件）並沒有作這個動作，而是將內容原封不動寄出，甚至連內容所使用的字集都未指定。
這時問題就來了！
如果你寫的文字是正體中文，寄到使用簡體中文、英文的電腦上時，信件程式要怎麼顯示？
因此，一旦這樣的情況發生時，亂碼郵件就產生了。

亂碼二分之一
不是指那部古老的日本卡漫。
而是說亂碼的成因有二分之一，是內容的還原出問題；另二分之一是未指定內容的字集，以致於信件軟體無法正確地顯示。

對於內容還原出問題的情況
也就是看到一堆

=?big5?B?uXGkbLZspfO2w71Y?=

類型的內容，表示那個程式不完善，可以考慮更換。

對於未指定內容字集
也就是會看到一堆像

´£¨Ñ¹CÀ¸¤¶²Ð¡B«_ÀI¤èªk¡B¤Hª«¨¤¦â¸ê®Æ¤Î¬ÛÃö¤U¸ü¡C

的內容時，這表示來函者使用的程式沒有指定他的內容字集。
這時，可以透過指定內容字集的方式來碰碰運氣。一般來說，華人所用的字集不外乎正體中文（Big5）、簡體中文（GB18030、GB2312、HZ）和萬國碼（UTF-8）三種。稍微調整一下信件軟體的編碼方式，就有機會把內容還原。

附註：
電子郵件的編碼並不是一封郵件共用同一種編碼，而是每個段落可以獨立編碼。
例如寄件者可能是正體中文的字集，而收件者可能是簡體中文的字集，內容則採用 UTF-8 去編，這都是可行的。所以有時你會發現指定字集後，一下子標題正確了，內容卻亂了，而換了另一種字集，又恰恰相反，這也是合理的。這是因為程式設計時，往往只能使用單一字集來顯示，才會有這樣的問題。
不過，現在越來越多程式採用 UTF-8 方式處理字集問題，未來這類問題相信會越來越少，對於電子郵件這個老舊的通訊機制而言，也算是一個令人欣慰的發展了。

實際的郵件長相

From: =?big5?B?t2qlRLdOpHWnQKvHoUCkQs7rpOU=?= <charlie@ics.com.tw>
To: <charlie@ics.com.tw>
Subject: =?big5?B?uXGkbLZspfO2w71Y?=
Date: Tue, 28 Aug 2007 21:06:48 +0800
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: quoted-printable

=B9q=A4l=B6l=A5=F3=B6=C3=BDX

其中紅字為 header，藍字為 body，大家可以發現整封信全由英文字集組成，其中所有的文字都被編碼處理了，此為符合 7Bit 規範的郵件。
若內容部份以原始的文字呈現，則為符合 8Bit 規範。由於 header 處有註明使用字集，因此還不致於無法顯示。而本例中，內容是透過 quoted-printable 這個另一種常見的編碼方式來編碼。