ANSI：系統預設的標準文字儲存格式。ANSI是American National Standards Institute的縮寫。它成立於1918年，是一個自願性的組織，擁有超過1300個會員，包括所有大型的電腦公司。ANSI專為電腦工業建立標準，它是世界上相當重要的標準。
Unicode：世界上所有主要指令文件的聯集，包括商業和個人電腦所使用的公用字集。當採用Unicode格式儲存文件時，可使用Unicode 控制字串輔助說明語言的文字覆蓋範圍，如阿拉伯語、希伯來語。用戶在「記事本」中輸入含有Unicode字串的文字並儲存文件時，系統會提示你必須選取「另存為」中的Unicode編碼，這些字串才不會被遺失。需要提醒大家的是，部分Windows 2000字型無法顯示所有的Unicode 串。如果發現文件中缺少了某些字串，只需將其變更為其它字型即可。
Unicode big endian：在Big-endian處理器（如蘋果Macintosh 電腦）上建立的Unicode文件中的文字位元組（存放服務機構）排列順序，與在Intel處理器上建立的文件的文字位元組排列順序相反。最重要的位元組擁有最低的位址，且會先儲存文字中較大的一端。為使這類電腦的用戶能夠存取你的文件，可選項Unicode big-endian格式。
UTF-8：UTF意為通用字集轉換格式(Universal Character Set Transformation Format)，UTF-8是Unicode的8位元格式。如果使用只能在同類位元組內支持8個位元的重要資料一類的舊式傳輸媒體，可選項UTF-8格式
ANSI最常見於.... BBS
你以上大學的BBS網站或new ,帖文的簽名五花八門且創意實足...
ANSI Esc控制碼讓名字變色就要用 ANSI Esc控制碼
1.ANSI Esc控制碼 以ESC字元和 [ 開始, 這兩個字元之後的字元是參數, 還有一個設定碼字元,此字元有大.小寫的區別.
2.任一字元間不可輸入空格, ANSI Esc設定碼有兩個以上的參數時,應以分號(;)區隔. http://netlab.cse.yzu.edu.tw/~statue/arion/beginner/ansi.html
UTF-8：Unicode Translation Format-8 (UTF-8) 編碼
MS IE 瀏覽器如是簡體的目錄或檔名....
工具>網際網路選項>進階>.永遠都使用UTF-8傳送 (須重啟IE)
你可句選它,可對其下載,不會有...???檔.zip...檔情形.
什麼是 UTF-8?
首先 UCS 和 Unicode 只是分配整數給字串的編碼表. 現在存在好幾種將一串字串表示為一串字元的方法. 最顯而易見的兩種方法是將 Unicode 文本存儲為 2 個 或 4 個字元序列的串. 這兩種方法的正式名稱分別為 UCS-2 和 UCS-4. 除非另外指定, 否則大多數的字元都是這樣的(Bigendian convention). 將一個 ASCII 或 Latin-1 的文件轉換成 UCS-2 只需簡單地在每個 ASCII 字元前插入 0x00. 如果要轉換成 UCS-4, 則必須在每個 ASCII 字元前插入三個 0x00.
在 Unix 下使用 UCS-2 (或 UCS-4) 會導致非常嚴重的問題. 用這些編碼的字串串會包含一些特殊的字串, 比如 '\0' 或 '/', 它們在 檔案名和其他 C 庫函數參數里都有特別的含義. 另外, 大多數使用 ASCII 文件的 UNIX 下的工具, 如果不進行重大修改是無法讀取 16 位的字串的. 關於這些原因, 在檔案名, 文本文件, 環境變量等地方, UCS-2 不適合作為 Unicode 的外部編碼.
在 ISO 10646-1 Annex R 和 RFC 2279 裡定義的 UTF-8 編碼沒有這些問題. 它是在 Unix 風格的操作系統下使用 Unicode 的明顯的方法.
UTF-8 有一下特性:
UCS 字串 U+0000 到 U+007F (ASCII) 被編碼為字元 0x00 到 0x7F (ASCII 相容). 這意味著只包含 7 位 ASCII 字串的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
所有 >U+007F 的 UCS 字串被編碼為一個多個字元的串, 每個字元都有標記位集. 因此, ASCII 字元 (0x00-0x7F) 不可能作為任何其他字串的一部分.
表示非 ASCII 字串的多字元串的第一個字元總是在 0xC0 到 0xFD 的範圍裡, 並指出這個字串包含多少個字元. 多字元串的其餘字元都在 0x80 到 0xBF 範圍裡. 這使得重新同步非常容易, 並使編碼無國界, 且很少受丟失字元的影響.
可以編入所有可能的 231個 UCS 程式碼
UTF-8 編碼字串理論上可以最多到 6 個字元長, 然而 16 位 BMP 字串最多只用到 3 字元長.
Bigendian UCS-4 字元串的排列順序是預定的.
字元 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.
UTF-8 and Unicode FAQ
http://www.ctosoft.com/book/utf8.html
。 郵件編碼介紹及亂碼的解決
E-mail一般在傳送程序中都要對文件進行編碼。這是因為E-mail只能傳送ASCII碼格式的文字信息。ASCII碼為7位程式碼，非ASCII格 式的文件在傳送中必須經過編碼工具編成相應的A SCII碼進行傳輸，接收端在收到後再根據編碼規則進行解碼。若非如此就會在傳輸程序中出現編碼截位的問題，導致收信方出現亂碼。特別是中文內碼的文字， 屬於8 位程式碼，並非標準的ASCII碼形式，由於國內通行的大部分郵件伺服器都能夠處理GB內碼文件，所以可以直接傳送文件而不需要編碼，但如果要將中文郵件 發到國外或在不支持8 位（非標準ASCII碼格式）的某些郵件主機上傳輸，就會產生亂碼。具體的說就是在直接傳送中文或非ASCII碼的郵件時郵件主機無法處理，會把文件中每 個字串的第八位都濾掉（截去第八位）從而使一些信息和原始信息截然不同，或郵件完全損壞成為亂碼無法閱讀。這也是目前造成郵件亂碼的主要原因之一。如果我 們對郵件進行七位編碼然後進行傳輸解碼，就能解決截位亂碼現象。
E-mail中一般採用UU、MIME、BINHEX三種編碼標準，當郵件出現亂碼時，很多是由於E-mail編碼不對而造成的，由於每種編碼其格式都有其各自特徵，這就給了我們一個判別的標誌。我們可以根據這些特徵進行編碼判斷並採取相應的方法來解決。
一、UUENCODE編碼判斷及解決。
UUENCODE內部所用算法為Base64，其格式為:
begin 644 gx.zip Mig)0;....
...
end
其格式特徵為在亂碼之前會有「begin xxx」後緊跟被編碼的原始檔案名稱，然後是編碼郵件內容，在最後一行為「end」。
根據這些特徵我們判斷出編碼方式為UUENCODE方式，就可以使用一些相應DECODE軟體來解碼。具體方法有:
（1）將Uuencode「亂碼」郵件轉寄到自己的郵箱中，再使用能夠支持UU解碼的電子郵件接收程序(如Eudora、OutLook Express等）來接收該郵件。
（2）通過剪貼板將Uuencode「亂碼」存為文本文件，改檔案名後面為UUE，然後使用Winzip解碼。
二、MIME方式編碼判斷及亂碼解決方法
（一）Base64 encode編碼判斷
Base64大體格式為:
MIME-Version:1.0
Content-type:text/plain;Charset="us-ascii"
Content-transfer-encoding;base64
....
在亂碼前面一般有以下幾部分「信頭」:Content - type (內容及類型），Charset（字串集）及Content-Transfer-encoding(內容傳輸編碼方式），根據以上信息非常好判斷。解決方法有:
（1）將Base64 encode「亂碼」郵件存成一個文本文件，改檔案名後面為.UUE，然後使用Winzip解碼。
（2）將Base64 encode「亂碼」郵件存成一個文件，將文件後面改為.EML，由OutLook Express開啟，就可以自動解碼。
（二）QP編碼判斷
QP編碼大體格式如下:
=A1A=B1Z=A6N=A1I=AT=DA
....
採用QP編碼的郵件也很容易判斷，只要亂碼內容有很多符號「=」就可判斷為QP編碼。QP亂碼解決方法有:
（1）將QP-encode「亂碼」郵件轉寄到自己的郵箱中，然後用支持QP解碼的電子郵件接收程序（如Netscape mail、Eudora、OutLookExpress、Becky等）來接收該郵件。
（2）使用Winzip對Quoted-Printable解碼。必須注意:
a.在郵件信頭中檢查、增加這樣兩行:Mime-Version:1.0 Content-Transfer-Encoding: quoted-printable ;
b.信頭中間不要空行，信頭和信體之間要有一個空行。這樣形成的文件，改後面名為UUE，即可雙按啟動Winzip得到解碼。
三、其它原因造成的郵件亂碼:
（一）HZ中文亂碼
由於網友們可能使用不同的電子郵件收發軟體，因此，來自各個網友的郵件內容可能包含著看不懂的亂碼，例如，有時會看到「囊饉跡Z 」這樣奇怪的文字內容，實際上這是一串「簡體中文HZ」編碼。如果使用Outlook Express傳送郵件，選用HZ編碼，而郵件的接收者使用Eudora來閱讀郵件，看到的就是這種亂碼。正確的方法是，在撰寫郵件視窗中，選項「格式」 功能表下的「語言」指令，並選「簡體中文( GB2312)」項，然後傳送郵件。這時，如果你使用OutlookExpress，可以開啟「檢視」功能表點擊「語言」選項中的「簡體中文 (GB2312)」項，或者點擊工作列上「語言」後面的向下箭頭，選項「簡體中文( GB2312)」功能項，螢幕出現一個對話視窗，按擊「是」按鈕，所有郵件主旨中含有指定字串集的郵件套用新的字串集。如果你使用Eudora之類的軟 體，可以用「南極星」之類的軟體自動轉換不同的漢字編碼。如果還看不到的話，可將這些編碼文本，拷貝到一個文本編輯器中檢視。
（二）「半個漢字」亂碼
漢字的另一個問題是所謂的「半個漢字」亂碼。如果看到下面這串亂碼，你一定看不懂它的意思: 「把砑⒂萌砑?]⒙蛉砑暮冒槁隆薄*」
這是由於很多英文編輯軟體以字串為服務機構來處理文本，漢字被刪除一半後，剩餘的部分會和相鄰的漢字重新組合，使得文本面目全非。因此，除了在輸入、 刪除的時候注意這種問題外，還要注意不要在英文字處理軟體中輕易使用「字串替換」功能，否則系統往往會把一個漢字的後一個字串和相鄰漢字的前一個字串當成 一個漢字處理。
對於「半個漢字」亂碼，只要將「亂碼」郵件存成一個文本文件，然後使用以字串為服務機構的編輯軟體，將「亂碼」行的首字串刪除，後面的部分就會和相鄰的「亂碼」重新組合成可識別的漢字。
如果上述方法不能奏效，那麼只好告訴對方正確的傳送方式，請對方重新發一份郵件給你了。
講了這麼多，相信大家對E-MAIL的編碼有了一定瞭解，對於一般的編碼亂碼也有了一定的判別能力了。但E-MAIL亂碼不僅僅是由於編碼不同所造成的，還可能有其它的原因，比如:
1．該郵件採用了其它少見的編碼方法，如Binhex或XXencode編碼等。如果亂碼前面有「信頭」信息（一般顯示了該郵件所用的編碼方式），即可用X ferp111或其它「智能型」Windows程序將其解碼。
2．是否在中文環境內。如果你所用的操作系統是英文環境，而你又沒有外掛中文系統（如中文之星）或未切換為中文編碼方式，則你自然看不到中文（如R ICHWIN四通利方或南極星等），看到的只能是亂碼。注意，雙字元字串有中文簡/繁體的GB和BIG5碼及日文的JIS、EUC和朝鮮文的KSC碼等， 在G B碼環境下看其他雙字元字串時也只能看到亂碼。在這些情況下，須用轉碼工具如Richwin、南極星等進行轉換。
3．郵件未經過編碼造成第8位字元濾掉成為無法還原的死亂碼我的文件。
四、為了儘量避免出現亂碼問題，下面給出幾點建議:
1．利用「附件」功能傳送文件。
2．無法以附件方式傳送文件時，則必須在正文中傳送中文或二進制文件。方法是在你所使用的郵件系統中，選項其首選項或選項配置中的「Q uoted Printalbe」或「MIMEencoding」項。
3．傳送重要信息時先發測試信。
