線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:5973
推到 Plurk!
推到 Facebook!

亂碼大全

 
jackkcg
站務副站長


發表:891
回覆:1050
積分:848
註冊:2002-03-23

發送簡訊給我
#1 引用回覆 回覆 發表時間:2003-06-25 16:43:09 IP:61.221.xxx.xxx 未訂閱
此為轉憋資料 亂碼大全 http://www.21ds.net/article/print.php/67 亂碼大全  2002-11-27    bluesea (藍海)    BBS 水木清華站  列印自: phpArticle 文章管理系統,PHP,MySQL,WYSIWYG Editor,文章系統 地址: http://www.21ds.net/article/article.php/67  亂碼大全(1)──綜述(第二版)  本文第一版本於98年2月3日發於本板。這一版本修改了原文中關於字元集的一些不確切的說法。  “亂碼大全”,作者:bluesea,水木清華 BBS 成員。歡迎在 BBS 中轉載,幫助電腦初學者解決使用軟體過程中遇到的實際問題。本文原載于水木清華 BBS 的 Internet討論區。地址是: telnet://bbs.tsinghua.edu.cn ,WWW訪問的地址是 http://bbs.tsinghua.edu.cn 。當下面的條件全部滿足時,轉載本文可以不經過作者允許:(1) 轉載水木清華 BBS 的信頭;(2)不修改原文;(3) 轉載僅限於各種 BBS 和非商業性質的個人網點。嚴禁各種形式的抄襲,嚴禁非作者將 本文或局部用於任何正式出版的刊物。請所有轉載文章的網友注意閱讀本文的第一段,遵守網路的慣例、尊重作者的勞動。本自然段是全文的一部分。  謹以該系列的文章,作爲給水木清華 BBS 及諸位網蟲的新春禮物。  字元是電腦表達資訊的主要方式,字元的主體部分是美國資訊交換標準碼 ASCII,現代的 ASCII 是一個七位元的編碼標準,包括可列印符號、控制符號等。由於電腦通常用“位元組(byte)”這個八位元的存儲單位來進行資訊交換,因此不同的電腦廠家對 ASCII 進行了擴充對值大於 127 的 128 個符號予以定義,並賦予符號的形狀。如 MS-DOS 使用 OEM 字元集,Windows 支援 ANSI、Symbol、 OEM 等字元集,它們在值爲 127 以上的部分一般都是不統一的,這些“擴展的 ASCII”字元只有在特定的環境下才具有“交換”的意義。 電腦以及很多電腦網路協定的制定都是建立在ASCII 碼的基礎上的,但是ASCII 碼用於電腦資訊的表示有很大的不足,主要表現在多國文字、圖形、 聲音等二進位文件、資訊壓縮、資訊保密等很多方面。 因此,在 ASCII 和擴展 ASCII 碼的基礎上,用一定的規則定義一些新的資訊表達形式,就形成了資訊傳 輸和處理中的一大類概念和事物,即編碼和解碼。當資訊編碼和解碼能夠統一的時候,資訊是可以交換和被理解的;相反,當資訊編碼和解碼不能夠統一的時候, 資訊就不能被交換和理解,這就是“亂碼”。(以下不再使用引號)  亂碼的産生既然是資訊編碼和解碼不能夠統一的結果,因此,解決亂碼的過程就是找到和編碼相統一的解碼方法,並對電腦軟體不能全自動進行適當解碼的資訊進行重新的處理和解碼,使得恢復資訊可以被理解和交換的目的。  本文針對 BBS 上常見的問題,對初學者比較全的介紹一下各種亂碼的産生、判斷和解決方法。可以說,常見的亂碼有這樣一些規律:(1) 和漢字或其他國家的文字有關;(2) 經常發生在 email 的閱讀中;(3) 和傳送二進位文件有關;(4) 和資訊的加密解密有關。而亂碼的原因正如前面所說的,和軟體的版本,即他們能夠自動識別和使用的解碼協定有密切的關係。本文的寫作主要針對 DOS/Windows 作業系統的用戶。  本文以 email 和 WWW 中經常出現的、初學者不易理解的特殊標記、亂碼等現象,以亂碼的識別、原因和解決方法爲主線,涉及:ROT13、漢字亂碼、ANSI、 UUENCODE、MIMENCODE、QUATED-PRINTABLE、HTML、文件格式和資料加密等方面。是個大雜貨店。  “我遇到亂碼怎麽辦?”這是幾乎我們每個人都曾經遇到的問題。我想稍微總結一下這個大家關心的問題也有一些時間了,不過 Internet 博大精深,到動筆時感到知識實在是極度匱乏。那些曾經熟悉的東西寫出來好像就不是那麽回事。 在做水木清華 BBS 病毒討論區板主的這段時間裏遇到的大量問題中,更多的是出在與病毒相似卻不是病毒的地方,比如電腦硬體軟體本身的問題,某些國產反病毒軟體因質量問題破壞文件和系統等等。所以,要把電腦用的更順手,需要的是更多地瞭解你所使用的這個工具。防範病毒只是一個方面。一個新手,當你有機會邁進 Internet 的時候,你已經擁有這個博大精深的世界的一半了,只是有很多人還渾然不知。 Internet 就是你的老師,你自己就是你的老師。  我希望大家對這個系列提出一些意見、補充和建議,以便修改其中文章中的錯誤、Bug 或充實沒有概括到的內容。   亂碼大全(2)──ROT13  Jvgu n tbbq pbafpvrapr bhe bayl fher erjneq, jvgu uvfgbel gur svany whqtr bs bhe qrrqf, yrg hf tb sbegu gb yrnq gur ynaq jr ybir, nfxvat Uvf oyrffvat naq Uvf uryc, ohg xabjvat gung urer ba rnegu Tbq'f jbex zhfg gehyl or bhe bja.  Wbua Svgmtrenyq Xraarql 如果你自己能夠看懂上面的短文,那麽請忽略本文的其餘部分。  如果有人寫來一封莫名其妙的信, 含有“V Ybir lbh!”這樣的句子,也許你還有可能以爲這是德語。其實這是一種最簡單的通用編碼──ROT13, 這個句子實際上是“I Love you!”。不懂德語的人經常要鬧笑話,Usenet 上經常有這樣的標題:This is not ROT13, it's German. 或者 This isn't German, it's ROT13. 足見這個誤會是世界性的。  ROT13 是一種簡單的編碼,它把字母分成前後兩組,每組13個,編碼和解碼的演算法相同,僅僅交換字母的這兩個部分,即:[a..m] --> [n..z] 和 [n..z] --> [a..m] (--> Caesar 13)。 英國帝國大學電腦在線字典解釋 ROT13 時說: “It is used to enclose the text in a sealed wrapper that the reader must choose to open - e.g. for posting things that might offend some readers, or spoilers. ” ROT13 用簡易的手段使得信件不能直接被識別和閱讀,也不會被搜索匹配程式用通常的方法直接找到。經常用於 USENET 中發表一些攻擊性或令人不快的言論或有簡單保密需要的文章。  常見的 email/news reader 程式都可以對 ROT 13 進行解碼,如 Netscape 和 Microsoft News 等。一些 Text 編輯程式也可以實現 ROT13 的解碼。 比如 EditPad( http://www.tornado.be/~johnfg/ ,雙牛站的 HTML TextEditor分類 下面也可以下載)。由於 ROT13 是自逆演算法,所以,解碼和編碼是同一個過程。 下面的 C 程式是最短的 ROT13 處理程式,它只有78個字元。當然在MSVC編譯中會得到沒有庫聲明的警告或錯誤。  main(c){while((c=getchar())+1)putchar(isalpha(c)?tolower(c)<'n'?c+13:c-13:c);}  (出處: http://www.cis.ohio-state.edu/~fine/rot13.html )  下面的宏可用於 Word6、7 進行 ROT13 編解碼:( 本程式的出處:Subject: Re: ROT13 Macro / From: wncoan@aol.com (WNCOAN) / Date: 1998/01/29 / Newsgroups: microsoft.public.word.programming )  Sub MAIN StartOfDocument While Not AtEndOfDocument() If Asc(Selection$()) > 64 And Asc(Selection$()) < 91 Then newAsc = Asc(Selection$()) + 13 If newAsc > 90 Then newAsc = newAsc - 26 CharRight 1, 1 Insert Chr$(newAsc) ElseIf Asc(Selection$()) > 96 And Asc(Selection$()) < 123 Then newAsc = Asc(Selection$()) + 13 If newAsc > 122 Then newAsc = newAsc - 26 CharRight 1, 1 Insert Chr$(newAsc) Else CharRight EndIf Wend End Sub 下面這些網址以 cgi 的方式提供在線的 ROT13 轉換。 http://otto.cmr.fsu.edu/~davis_t/rot13.cgi http://as.alliancestudio.com/tk/rot13.html http://www.rtg.se/~niclas/reddwarf/rot13.htm 到現在爲止,您已經可以對本文開始的那一段代碼進行解碼了。那是美國前 總統甘乃迪的一段演說。   亂碼大全(3)──漢字與亂碼  漢字亂碼是一個古老的問題了。自從漢字走進電腦,關於漢字亂碼的問題一天也沒有消失過。有關漢字和 HTML 的問題,將在本文系列的稍後的文章中單獨談到。本文不準備重復 GB_2312-80(國標)、BIG5、GBK、HZ 的最基本的互相轉換的問題,相關的內容可以在本 BBS Chinese 板詢問。 這裏以其他角度做一些補充。  由於編碼位置上的巧合和漢字平均出現概率上的統計,用 GB 環境看 BIG5 編碼的文字,將有漢字顯示成爲日語的假名,這個是在 GB 環境下看到 BIG5 漢字的主要特徵。上網時間長一些,就會積累一些經驗,使得你能夠一眼區分亂碼的類型。比如下面的例子就是 BIG5: ¨睹絏h〃明k踀lueseaVれ睲地BBSΘz舧I BBSい鑼更甝 樹@衡訣韭\k稈∕ㄏノ硜ン筁祘い笿涺Y龜悔拜肈セゅk更Vれ睲地 BBS Y Internet癚階跋H箷v telnet://bbs.tsinghua.edu.cn 溦WW砐拜YH 箷v http://bbs.tsinghua.edu.cn 鉯惢燿Y兵ンh場骸ì榃r更セゅl ぃ竒筁明kす砛(1) 鑼更Vれ睲地 BBS Y獺繷(2)ぃVэkゅ(3) 鑼更度 賀 BBS ㎝獶壩穨┦借YR邥I翴 腨窽賀產DYй膿腨窽獶明k盢 セゅ┪Ы場ノヴzタΑ|HY~Jセs礛琿琌hゅY籀だ  常見的漢字亂碼還有 HZ 編碼,這是一種遮罩最高位的漢字表示方法,它是在 GB 和 BIG5 的基礎上,用 ~{ 和 ~} 括起漢字編碼的部分。比如: 很多海外中文雜誌,如著名的《華夏文摘》( http://www.cnd.org )等都仍然採用 HZ 編碼方法。HZ 編碼用額外的控制序列來控制字形的顯示,字母和數位是不被編碼的,它們在 ~{ 和 ~} 標記對的外面。這種編碼不符合漢字與文本字元的固定映射規律,處理起來相對麻煩。著名的漢字平臺──南極星 ( NJWIN 1.6,http://www.njstar.com ) 對 HZ 提供了靈活和強大的支援。 海峽兩岸的語言經過長期的發展,實際上已經不能形成一一對應的關係,GB 和 BIG5 的轉換也是如此。因此這種轉換往往具有不可逆性,倒不是說一段文字不能在 GB 和 BIG5 之間互相轉換,而是說一旦你轉換錯了,資訊就不能復原。比如你拿一段本來的是 GB 的文字當作 BIG5, 然後再實施 BIG5 -> GB 的轉換,就會損失資訊,這時逆變換將不能完全得到原來的文字。比如 SMTH WWW 發文時,本是 GB 的,錯選了 BIG5 按鈕就會如此,反之也類似。 漢字的另一個問題是所謂的“半個漢字”亂碼,由於很多英文編輯軟體以字元爲單位來處理文本,漢字被刪除一半後,剩餘的部分會和相鄰的漢字重新組合,使得文本面目全非。因此,除了注意在輸入、刪除的時候注意這種問題外,還要注意不要在英文書處理軟體中輕易使用“字元替換”功能,這往往會把一個漢字的後一個字元和相鄰漢字的前一個字元當成一個漢字被替換掉。這種亂碼最後往往令人莫名其妙、找不到原因。  需要說明的是,簡體和繁體這兩個概念和 GB、BIG5 並沒有邏輯上的聯繫,GB 的定義是簡體字,BIG5 採用的是繁體字,但是爲了閱讀的方便,在各自的編碼中再做一個內部字形或字體的映射,就形成了所謂 GB 繁體或 BIG5 簡體之類的概念,他們僅僅是一些漢字軟體提供的方便功能,如南極星等。我們常見的 WWW 瀏覽器 Microsoft Internet Explorer 4.x 和 Netscape Navigator 4.x 都已經內置了比較完善的漢字轉換功能。加裝了語言包的 IE 4.0 還使得我們脫離漢字平臺也可以進行中文處理,並且可以處理大字元集 GBK 。詳見 Win95_win3.x 討論區中 “讓Pwin95更順手”系列之(11)。  在中文平臺上,很多人有不同的見解。本文的主旨與此無關,僅僅是綜合各個方面的因素,我個人向電腦的初學者建議選擇中文 PWindows 95 OSR2 或更高的版本作爲最基本的操作環境。中文之星 ( http://www.chinese-star.com 、 http://www.suntendy.com/ ) ,四通利方Richwin( http://www.srsnet.com/ ) 等由於技術和企業行爲的不穩定性,不適合作爲具有依附性的中文平臺。但是這些軟體中的局部,如新拼音輸入法、支援剪輯板的碼轉換器等還是具有一定特色 的。如果有對這個問題感興趣的討論,請到 Chinese 板搜索以前的標題繼續討論。 在 Chinese Community Information Center (CCIC),集中了一些中文處理的比較完整權威的解決方案,該網點位址是 http://www.ifcss.org/software ,其中包括了各種作業系統、各種漢字編碼的處理方案和軟體。 除了常見中文平臺外,通過 http://www.shareware.com、 http://www.download.com 、http://www.hotfiles.com 等共用軟體網點,查詢 GB、BIG5、chinese 等關鍵字可以獲得大量的小型應用程式,包括碼轉換器。儘管如此,本文還要重點推薦一些用於 DOS 的命令行處理工具,具有使用方便、可以進行批次處理等特點。他們是: c2t (將 GB 或 BIG5 轉化爲拼音)  HZ (gb2hz hz2gb zw2hz) (convert gb to hz, hz to gb, zw to hz respectively) hc (convert between GB and BIG5)  下載地址爲:  http://ftpsearch.ntnu.no/cgi-bin/search?query=c2t.zip  http://ftpsearch.ntnu.no/cgi-bin/search?query=hz-20.zip  http://ftpsearch.ntnu.no/cgi-bin/search?query=hc-30.zip  其他軟體請到 http://www.ifcss.org/ftp-pub/software/ 查找。另外,GB 和 BIG5 屬於兩個不同組織各自制定的標準體系,對應漢字編碼的轉換都是通過表格來轉換的,他們之間不存在任何內在的邏輯關係或函數,試圖尋找這種公式的人,請不要白費精力。 幾乎所有新生的軟體在中國使用都會面臨一個漢字相容的問題,比如新生的 Java 及其開發環境、動態HTML領域等都從未倖免。 通過NT的資源存取能力可以實現英文軟體的介面/資源漢化,由於 PWindows 95 對話方塊的缺省宋體的大小爲 9 磅,而英文 Windows 95 的相應值爲 MS Sans Serif 8,所以很多英文軟體在 PWindows 中運行時,介面中的字殘缺不全,這些也可以通過資源的重新編輯予以調整。 但是,軟體內核的漢化不是可以輕易實現的。即使是廠家做的漢化工作也有非常粗糙的痕迹。比如 P-IE 4.0 在安裝繁體漢字包後,PWindows Help 就産生了內碼的混亂。這就是個嚴重的 Bug。有時只能隨意選出一個具體的條目彈出幫助視窗,再反過來調出幫助主題視窗,偶爾還可以對付使用。或者你就再運行一份 NJwin,在 Option 中選擇 Standard English/Western 。其實這一招在以前討論 OutLook Express 看 BIG5 郵件的時候就用過了,也是個亂碼的問題,詳 見 Win95_win3.x 討論區精華區中的“讓PWin 95更順手(9)─南極星與OutLook Express”。  亂碼大全(4)──BBS與ANSI  ANSI (American National Standards Institute ) 規定了一組控制字元和鍵盤的擴充規則,本文不作爲使用 ANSI 彩色和位置控制在 BBS 上進行應用的初級指南。這方面的內容參見 BBSHelp 和 ASCIIart 板及其精華區。 很多 BBS 的 WWW 版本在文本轉換的時候沒有解釋 ANSI 的效果,而是把控制符號 01Bh 解釋成爲 * 號,這就形成了閱讀 BBS 文章的特殊亂碼效果。比如: *[1m (高亮度字)、*[1;5;33m (高亮度黃色閃爍字)、*[1;31;44 (高亮度藍底紅 色字) 等等。  目前,國內的著名 BBS, 水木清華、網易、藍天等站的 WWW 轉換程式都已經解決這個問題。在 Telnet 中發表文章可以使用 ANSI 控制,利用 MS-DOS 的 Help 可以獲得 ANSI 字元控制的詳細資訊。(如 C:\DOS>Help ANSI.SYS)。在使用位置控制的時候,應該儘量使用 ESC[s 和 ESC[u (存儲和恢復游標位置)來控制文本,以免發生位置錯亂,並儘量在每行結束的時候恢復默認的屬性,以免因爲翻頁而造成 ANSI 控制的不完整。 NetTerm 有那麽點不太引人注目的小秘密,這就是它自己支援一些類似 Ansi 控制的擴充控制序列。曾經作爲一個調劑的手段,爲上 BBS 的網蟲增添了不少樂趣。隨著清華 BBS 上的一些網蟲不斷“露一手”,現在全國很多 BBS 都使用了這些擴充的控制來修改標題欄、狀態欄,來表示對網蟲的問候。如北方交大、網易……。NetTerm 的擴充序列參見它的 Readme 文件或 Virus 精華區“反病毒與黑客/工具/趣聞”目錄下面的摘錄。 Ansi 作爲標準字元的一種擴展的表現手段,起到了豐富色彩,活躍氣氛的作用,這些作用的效果會隨著閱讀一篇文章的結束而結束,而很多擴展控制卻可以留下來,改變你的標題欄狀態欄,甚至打開你的瀏覽器,乃至死機。 Netterm 在解釋自己創立的擴充序列的一些 Bug 也很明顯地表現了出來,同時,還有很多終端程式在解釋控制序列的時候,程式不夠嚴密,對於非標準的序列往往會産生意外的後果。利用程式編制上的缺陷,採用類似 Ansi 序列的方法啟動這些 Bug,這就是我們這裏說的所謂“BBS ANSI 炸彈”。 擴展控制序列的濫用,引起了 BBS上的一些爭論,很多人表示反感。誰當初會想到圍繞這個問題會有這樣多的故事呢。不過我們今天不得不通過一種管理的手段來制約它,這一方面說明完整的管理制度是維護一個全局的必要手段,同時也說明在網路這個苑囿中,自覺二字還遠沒有達到理想的程度。經過不太長時間的討論,終於有了結果。就是最終由 Leeward 站長修改 BBS 軟體,把擴充序列的解釋權交給用戶,允許用戶從個人參數設定中禁止這些效果。詳細的資訊請參考sysop 板的討論,以及最後 Leeward 公佈的解決辦法。  亂碼大全(5)──UUENCODE  UUENCODE 在我們水木清華 BBS 已經討論得很多了,關於 UUENCODE 的詳細內容參見水木清華 BBS Virus 和Hacker 精華區中的“UUENCODE/decode 知識與使用入門”(一)~(四)。這裏只簡單提一下並作一些補充。 UUENCODE 的 UU 指用於 Unix 之間傳送二進位文件,就是 Unix to Unix。在 Email 或 News 中 UUENCODE 經常用於 Attach 二進位文件。目前不僅Netscape、Eudora、MS-mail,甚至包括 Hotmail、usa.net之類的 Webmail 在內的絕大多數email程式都支援 UUENCODE 的自動解碼。在一些軟體網點,如 http://www.shareware.com 等,可以找到 UUENCODE 的根源程式。  UUENCODE 代碼有下面的樣子:當軟體不能自動解碼(如在 telnet 中訪問 BBS )時可以轉寄到 email 中或通過剪輯板將 UUENCODE 代碼存入文字檔案,改檔案名尾碼爲 UUE,然後通過 Winzip 解碼。 由於 UUENCODE 的編碼中有小於號“<”, 和某些 HTML 標記會造成衝突或歧義,因此,在 BBS 中出現的 UUENCODE 代碼,通過 BBS2WWW 程式被 WWW 用戶閱讀的時候,會得到混亂的不正確的結果。除非 BBS2WWW 程式做相應的修改。但是這些修改一般是針對 HTML 標記,因此可能不會考慮周全所有的可能情況。因此,即使是目前的水木清華 BBS 也沒有完全解決這個問題。從 WWW 直接閱讀文章或下載精華區都會出現 UUENCODE 代碼出錯的情況,目前還沒有很好的解決方法,只能從 telent 上站,直接閱讀文章。  用 UUENCODE 傳送文件經常用於 ftpmail 或其他傳送較大文件的場合,這個時候往往是將 UUENCODE 編碼後的文件切成小塊再傳送。所以在編號爲第二、第三……的 email 中,我們會見到沒有“begin ………”開頭的 UUENCODE 代碼。( UUENCODE 代碼除了最後兩行外每行都是以字母 M 開頭的)。接收這類 email, 最好不要使用 Eudora, 因爲 Eudora 會將 Attached 文件恢復成二進位文件並存放在另一個目錄裏。對於分成多塊傳送的 UUENCODE 代碼,Eudora 會將這些代碼的第一部分恢復成文件──顯然這是個不完整的東西,後面的就不管了。這會妨礙後面你人工合併這些郵件。很多人使用 The_bat 這種郵件程式,它對 Attached 文件是恢復到目錄中還是留在信體中,是有一個選項可以選擇的,在這種情況下也要注意正確的選擇。   亂碼大全(6)──MIME/BASE64介紹  MIME: Multipurpose Internet Mail Extensions  英國帝國大學電腦在線字典 FOLDOC 對 MIME 的解釋爲:“多部分( multi- part )、多媒體電子郵件和 WWW 超文本的一種編碼標準,用於傳送諸如圖形、聲音和傳真等非文本資料。MIME 定義於 RFC 1341,用 MIMENCODE 的方法將二進位資料轉換成爲一種被稱爲 BASE64 的 ASCII 子集的字元的組合。” Internet 上有專門討論 MIME 的新聞組:comp.mail.mime。該新聞組的 FAQ 可以從下面的網點獲得:  http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/mime0/faq.html  MIMENCODE 最早稱爲 MMENCODE,提出用 MIMENCODE 代替 UUENCODE,是因爲 UUENCODE 使用了一些字元在一些郵件閘道(特別是那些轉換 ASCII 和 EBCDIC 碼的閘道)中造成傳輸障礙,(還有一些軟體不能對所有 UUENCODE 的演算法進行正確解碼而導致郵件的閱讀困難),因此 MIME 被設計用於替代 UUENCODE,但是結果是這些協定共存。 MIME/BASE64 的演算法很簡單,它將字元流順序放入一個 24 位元的緩衝區,缺字元的地方補零。然後將緩衝區截斷成爲 4 個部分,高位在先,每個部分 6 位元,用下面的 64 個字元重新表示:“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop qrstuvwxyz0123456789+/”。如果輸入只有一個或兩個位元組,那麽輸出將用等號“=”補足。這可以隔斷附加的資訊造成編碼的混亂。這就是BASE64。 UEsDBBQAAgAIAEapPiS/mrkHoQEAAEECAAAMAAAAYWNhZDd+dWUudHh0dVFRb5swGHyPlP9Q5Iet TUICzCUJASTiFuIQhwbHRJnUqmRsndqmVQO0CsK/fXbRVvVh+AV9vrvv7txunYiPV8rAW3n33w5B R9FAN3ld34Axr9OHIjtkt7wC3bmKHD+zznjteTGvjBnVFGCdxz265XW7dfI+ZVFyRjegO3hix8nl fGcdjeLqy/rGTp0Sj+Jp8Djho9oIWRSX0IYIwwmWbF4RHKYK0ByCaI9u4u3HukYZIvE32+fZyz7L  含有 MIME/BASE64 編碼的郵件,你查看它的源碼時 一般都含有:“This is a multi-part message in MIME format.”這樣的句子。也可以被絕大多數的 email 程式進行解碼,包括 Netscape、MS Mail、Eudora等。這些程式可以正確識別郵件的正文,恢復 MIME/BASE64 編碼的部分爲正確的文字或夾帶的二進位文件。  如果這些文件不能正確被恢復,可以將郵件原文存成文字檔案,改檔案名尾碼爲 .UUE,讓 Winzip 自動識別並恢復。推薦使用 Winzip 6.3 SR-1 或更高的版本。也可以將文件尾碼改爲 .EML , 由 Microsoft Mail 或 OutLook Express 打開,該軟體也可以自動解碼。另外很多網點,如  http://www.shareware.com 、  http://www.download.com 、  http://www.hotfiles.com 、  http://www.alberts.com  等都可以通過查詢 MIME 關鍵字得到大量的小型應用程式支援 MIME 的轉換。  亂碼大全(7)──MIME/BASE64處理實例  但是,即使是正確的 MIME 編碼也可能因爲文本格式不規範而不能正確解碼,這個時候,你從 email 程式或 Hotmail 裏面只能得到 BASE64 編碼的亂碼,而不能正確解碼。我們在 Pwindiws 95 中推薦使用 UltraEdit 5.0,並以此爲例來講處理過程。我們來看這樣一封典型信:( 行號是爲閱讀清楚,不屬於信的內容)。這封信是根據我幫助一個朋友解碼的實例改的。  01: From: "bluesea"  02: To: "=?gb2312?B?sKLEvg==?=" 03: Subject: A test :) 04: Date: Sat, 3 Jan 1998 15:31:38 0800 05: X-Mime-Autoconverted: from 8bit to BASE64 by ms1.inet.tw id PAA06553 06: Content-Length: 222 07: 08: ICAgIKGwwtLC67TzyKuhsaOs1/fV36O6Ymx1ZXNlYaOsy67Evsflu6pCQlOzydSxoaO7ttOt1Nog 09: QkJT1tDXqtTYo6yw7w0K1vq8xsvju/qz9dGn1d 94r72yrnTw8jtvP65/bPM1tDT9rW9tcTKtbzK 10: zsrM4qGjsb7OxNSt1NjT2suuxL7H5buqIEJCUw0KtcQgSW50ZXJuZXQgzNbC28f4oaO12N 這封信不能通過 OutLook Express 和 Winzip 恢復, 當然,我們還可以找其他程式,或者其他的 email 程式自動恢復信的內容,我們假設這些條件不符合,需要適當的手工恢復。我們能夠認定信體是 MIME/BASE64 編碼,那麽一定可以找到相應的解決辦法。首先備份你的信。然後進行下面的處理: 第一種方法,我們可以把原信的5、6兩行換成下面的兩行,注意第4、5行之間不要有空行。 Content-Type: text/plain;charset="gb2312" Content-Transfer-Encoding: BASE64 然後將檔案名尾碼改爲 EML,再由 OutLook Express 打開。如果不是 GB 漢字,而像是 BIG5,只需將 "gb2312" 改爲 "big5" 再試驗。如果你最終認定不是文本,而是二進位文件;或者是明顯的二進位文件,email 程式卻不能還原成夾帶 (Attached) 的文件,那麽需要將信件中的“Content-Type: text/plain;” 改爲“Content-Type: application/x-download;”。 第二種方法,假如沒有 OutLook Express,我們還可以借助 Winzip 6.3。 你只需在原信中,在 MIME 編碼的那三行中間的任意位置加一個回車,把它搞成四行,然後將文件尾碼改爲 UUE,再用 Winzip 6.3 打開。信體就會被正確解碼。說起來你可能不相信,覺得這個方法聞所未聞,像天方夜譚。這方法連我自己都不信,但是實踐證明是有效的。 最後,還差一點,就是原信第二行的內容:To: "=?gb2312?B?sKLEvg==?=" ,這信是發給誰的呢?這是 email 程式中在標題運用 MIME/BASE64 編碼的例子。我們請南極星 NJWIN 出山。NJWIN 1.58(1.6) 的 Option 有這樣一項:Support Internet MIME encoding,選中此項,即刻可以看到中文。 在 Pwindows 95 中,如果用 Notepad 或選擇了 GB2312 字體的 Ultraedit來 看信,那麽,請不要選中 NJWIN Option 中 My Windows System - Simplified GB 一項,而選擇 Standard English/Western。這樣的目的是讓 NJWIN 的漢字顯示起作用。可以看到收信人這一行是:“To: "阿木" ”。 亂碼大全(8)──Quoted-Printable 先認一認,一定很熟悉了,常見的被稱爲亂碼的東西。 經常出現在 email 中, 這就是 Quoted-Printable,是 MIME 的另一種編碼方式。 =A1=B0=C2=D2=C2=EB=B4=F3=C8=AB=A1=B1=A3=AC=D7=F7=D5=DF bluesea =A3=AC=CB=AE=C4=BE=C7=E5=BB=AABBS=B3=C9=D4=B1=A1=A3=BB=B6=D3=AD=D4=DA BBS=D6=D0=D7=AA=D4=D8=A3=AC=B0=EF=D6=FA=BC=C6=CB=E3=BB=FA=B3=F5=D1=A7 =D5=DF=BD=E2=BE=F6=CA=B9=D3=C3=C8=ED=BC=FE=B9=FD=B3=CC=D6=D0=D3=F6=B5=BD =B5=C4=CA=B5=BC=CA=CE=CA=CC=E2=A1=A3=B1=BE=CE=C4=D4=AD=D4=D8=D3=DA =CB=AE=C4=BE=C7=E5=BB=AA BBS =B5=C4 Internet =CC=D6=C2=DB=C7=F8=A1=A3 在所有郵件處理的各式各樣的編碼中,很多編碼的目的都是通過編碼手段使得七位元字元的郵件協定體系可以傳送八位元的二進位文件、雙位元組語言文字等等。 Quoted-Printable 也是這樣一些編碼中的一個,它的目的同樣是幫助非 ASCII 編碼的信件傳輸通過 SMTP。Quoted-Printable 編碼是字元對應的編碼,每個未編碼的二進位字元被編碼成三個字元,即一個等號和一個十六進位的數位,如 “=A8”。1:3,這種編碼效率實在很低。有關 Quoted-Printable 詳細技術資訊可以參考 RFC 2045。 一些 email 程式,它們不能正確解釋這種編碼。最方便的方法是使用 (如 Forward 到) 支援Quoted-Printable 解碼的 email 程式如 Netscape、Eudora、 OutLook Express 和 Calypso 2.4 等。Calypso 在將郵件另存成純文本的時候,甚至全都採用的是 Quoted-Printable 格式。Winzip 仍然是最方便的解碼工具之一。 用 Winzip 對 Quoted-Printable 解碼的關鍵有兩條:(1) 在email 信頭中檢查、添加這樣的兩行,如果沒有信頭,那麽這兩行就構成信頭,比如這兩行可以添加到本文開始的那段例子前面。 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable (2) 信頭中間不要空行,信頭和信體之間要有一個空行。這樣形成的文件,改尾碼名爲 UUE,即可雙擊啓動 Winzip 得到解碼。email 中的標題或收發信人等信頭位置帶有的 quoted-printable 編碼都可以被一起解決。滿足上面條件的信件也可以改尾碼名爲 EML, 用 OutLook Express 來解碼,類似這樣的標題: Subject: =?gb2312iso-8859-1?Q?=D4=DA=C7=E5=BB=AA=B5=C4BBS=C9=CF?= Subject: =?gb2312?Q?=D4=DA=C7=E5=BB=AA=B5=C4BBS=C9=CF?= 也可以被 OutLook Express 正確復原。 與 BASE64 不同的是 Quoted-Printable 編碼不處理原文中的換行,因此要注意一個漢字是由兩個字元組成的,會對應於 Quoted-Printable 編碼的六個字元,如果經過重新編輯並且換行不當則會造成半個漢字的亂碼,需要相應調整。 除此之外,還有很多方法用於解決 Quoted-Printable 的解碼,例如著名的 Quick View Plus 4.5 ( http://www.inso.com ) 也支援 Quoted-Printable 的解碼和直接閱讀。有些網點以在線 CGI 方式提供 Quated-printable 解碼,例如: http://cactus.aist-nara.ac.jp/~yosita-h/jap/quote.html 在 Unix 中,被 BASE64 或 quoted-printable 編碼的郵件可以用 metamail 等方法來解決。下面這份程式是本 BBS 的 jyj 編寫的,現在收錄在 Networking 板的精華區中,用於quoted-printable 解碼,適合於 Unix/DOS/windows。本文引用時對根源程式的版式做了一些調整。 #include void main(int argc, char * argv[]) { FILE * fp; char ch, ch1, ch2; unsigned char hz; fp = fopen(argv[1], "rt"); for (;;) { ch = getc(fp); if (ch == EOF) break; if (ch == '=') { ch1 = getc(fp); if (ch1 == '\n') continue; ch2 = getc(fp); hz = (ch1>'9'?ch1-'A' 10:ch1-'0')*16 (ch2>'9'?ch2-'A' 10:ch2-'0'); putchar(hz); } else putchar(ch); } fclose(fp); } 在 http://www.kobira.co.jp/sakura/d_net_mail.htm 可以獲得 Quoted- Printable 編碼和解碼的 Pascal 根源程式。很多支援 MIME 編解碼的程式都提供了 MIME BASE64 或 Quoted-Printable 的根源程式。 亂碼大全(9)──中文HTML與Netscape (第二版) 亂碼大全 (9) 的第一版發于 BBS 水木清華站 (Tue Feb 3 01:04:01 1998) Internet 信區,現對原內容做一些補充。 一個好的中文網點,應該能夠做到讓大多數瀏覽者能夠舒服地閱讀網頁,退而求其次應該是讓訪問者可以讀懂。但是,中文 Web 的瀏覽環境是一個複雜的多維空間。對於上面的要求,即便是後者也並不是每個網點都做到了。爲了遷就系統功能的某個設置,往往會忽略另一個設置,網點的設計者需要從很多選擇中進行折衷。 中文 Web 的瀏覽環境這個複雜的多維空間的組成是什麽呢? 我想至少包括這樣幾個因素: (1) 作業系統及其版本、語種;(2) 中文平臺的種類; (3) 瀏覽器的品種及其版本。由上面的幾個因素相互組合,可以形成幾十種瀏覽環境,它們在瀏覽同一個網頁時的效果都會有所不同。我們有理由認爲: 由中英文 Windows95/NT、常見中文環境(NjWin、Cstar、Richwin)和常見瀏覽器(Netscape 3.x/4.x、中英文IE3/4)構成了中國 Web 訪問的主要瀏覽環境。 順便說一句我們曾經多次提到的一個問題,很多網頁的設計者都在追求中文文本的自動折行,但是只要你承認上面的瀏覽環境的構成因素,那麽請不要費勁了,這個特性不僅取決於網頁的製作,還取決於瀏覽環境。當然,還有無數自信的網頁設計者在設計其他特性時也是在自己那裏試驗通過後就認爲一切都大功告成了。 在上面提到的瀏覽環境中,常見的漢字亂碼有兩種。這兩種情況依靠調節瀏覽器的各項參數和選項是無法克服的。 一、所有的漢字都顯示成矩形的小方塊。比如: □□□□ Windows 95 □□□□□□□□□□□□,□□□□ 70% □□□□ □□ 25% □□□□□□□□, Microsoft □□□□ Netscape □□□□... (實際的方塊是瘦一些的矩形,是 Windows 的某種字體。) 這種情況的發生有這樣四個條件: (1) 瀏覽網頁用的是 Netscape Communicator (Navigator) 4.x 版本;(2) 使用的作業系統是英文 Windows; (3) 使用的漢字平臺是中文之星或 RichWin;(4) 出現這種情況的網頁一定使用了包含“gb2312”的標記:() 沒有遇到過這個問題的人也許覺得不可思議, Netscape 會有這麽低級的問題。但是事實上卻是如此的。 解決方法之一是使用南極星 NJwin 1.5x/1/6x 做中文環境。在 SMTH 中, yuhj 是首先提出用 NJwin 來解決這個問題的人。他在述及這個問題時曾提到:“具體我沒有去研究過,總之用了 Njstar 英文win95 Netscape 4.x 看一般中文網頁都沒有問題了。 Njstar 使用中文 95 模式主要是不要它用自己的字體,那個字體比較難看,因爲是和 Richwin 同時運行,這樣螢幕上顯示的是 Richwin 的 Truetype 字體。而 Njstar 在前面提供中文識別。這裏 Richwin 換做 Cstar 應該一樣有效,沒有其他什麽要求。” 在 USENET 的 alt.chinese.text 討論組中,G.Chen 最近發文章說:“Netscape Communicator 默認使用 Unicode,而現有大多數漢字平臺不支援,這可以通過修改 Windows 95 註冊簿來解決這個問題”。即將下面的內容存成 fix-mozilla.reg,然後雙擊解決: ----------- fix-mozilla.reg cut from here -------------- REGEDIT4 [HKEY_CURRENT_USER\Software\Netscape\Netscape Navigator\INTL] "useUnicodeFont"=dword:00000000 ----------- fix-mozilla.reg file end ------------------- 當然,繞道解決也是克服這個問題方法,比如:換用 Netscape Navigator 3.x、Microsoft Internet Explorer 3.x/4.x;或乾脆換用 PWindows (95) 等。 對於本文的問題,就涉及到一個主頁製作的問題。中文 HTML 尚無標準可循,所以我個人認爲讓現有瀏覽環境的大多數人可以讀懂應該是網頁設計者的主要目標。“charset=gb2312”的用法是 Netscape 首先提出的 (Microsoft 開始採用的是gb_2312-80),那麽這種用法到底是用,還是不用? 這樣用的好處是能夠讓 Netscape 瀏覽器在閱讀網頁的時候支援漢字自動折行。至少出現亂碼的讀者和英文 Windows/IE 的用戶無法享受這個特性。因此 charset=gb2312 不如不用。 或者在主頁明確提示用戶可能會發生的麻煩及其解決方法。 亂碼大全(10)──中文HTML與MSIE 二、所有的漢字都是不可辨認的亂碼,有點像在英文環境下閱讀中文時沒有啓動中文環境似的。這種問題都出現在中文 Internet Explorer 中,造成這個現象的具體原因有兩種情況,我們先說第一種。因爲無法用 GB 漢字來表達那些亂碼,下面就給出這樣的例子,一個能夠産生亂碼的 HTML 文件。 <HTML> <BODY> ¡°ÂÒÂë´ óÈ«¡±£×÷Õ ß£ºbluesea£Ë®Ä¾Ç 廪BBS³ÉÔ±¡£ </BODY> </HTML> 看這個(類)文件會導致漢字無法識別的條件是使用的是中文 Windows 和中文 Internet Explorer,呵呵,很多人因此罵 Microsoft 弱智。實際上這是 HTML 中用於規範表示歐洲字元的方法。 這些字元在 Windows 字元集中可以方便地用於表示法語、德語等使用特殊拉丁字母的文字。這些字元到底是這些語言還是漢語,如果遵從 Microsoft 的解釋方法,將有可能在同一個中文的網頁中同時表達。 我們可以通過 IE 瀏覽器的功能表“查看/原始檔案”功能,看看 HTML 原始檔案中是否包含上面這樣的“漢字”,來判斷亂碼是否屬於這個情況。解決這種亂碼的只有兩個途徑:(1) 換用 Netscape 3.x 或 4.x 瀏覽器;(2) 在英文 Windows 下面使用英文 IE 3.x,通過中文之星或 Richwin 來閱讀。 對於有保存價值的網點,可以通過手工的方法進行一下轉換。方法是首先安裝一套 Netscape Navigator Gold 3.x 或 Communicator 4.x;對於你需要的網點先用瀏覽器保存(Save as)到本地,然後用 Netscape Composer ( Netscape的 簡易網點編輯器 ) 讀入這個網頁,然後選擇功能表 “ View / Encoding / Simplified chinese (GB2312) ”,然後再保存。 這個轉換方法實際上也指出了,當你用 Netscape Composer 製作一個中文網頁的時候,應該怎樣設置使得用 中文MSIE 的用戶也能夠閱讀這個網頁。這實際上又一次爲我們提出了網點製作的一些問題。顯然上面的亂碼一定是由 HTML 編輯工具産生的。很多網頁編輯工具,不像 Netscape Composer 這樣存在一個語言的設置,例如 Adobe PageMill 2.0 等工具,你在裏面輸入中文,它無論如何都會存成上面的樣子。這樣的工具顯然就不適合來製作中文網頁和網點。 因此我們在選擇一個新的工具(尤其是所見即所得的設計工具)的時候,不妨多花點時間去找一找、試一試它的相關選項,然後輸入幾個漢字並存一個 HTML 文件,看看中文是不是肉眼可以識別的,如果不行就只能放棄。當然你如果賭氣偏不讓那些用中文 IE 的人來看你的網點,那麽另當別論。 第二種情況,HTML 原始檔案中,漢字是肉眼可見的,爲什麽中文 IE 看上去還是亂碼呢?這是因爲網頁的作者沒有在 HTML 文件中正確標識網頁的語言類型,如在英文 Windows 中使用 Frontpage,網頁會自動被加上 iso-8859-1 標記,如: <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> </HEAD> <BODY> 脊柱是我們這種生命的重要特徵,在此基礎上我們才有了光芒的智慧和
豐富的情感。上帝賦予我們自由的意志,同時也賦予我們選擇的重擔。 </BODY> </HTML> 這樣的網頁就會是導致中文 IE 不認中文的後果,只需將 “iso-8859-1” 改成 “gb_2312-80”、“gb2312”(會産生本文上一篇導致的問題) 或者乾脆去掉這一行。具體選擇什麽方案需要 WebMaster 進行權衡。當然,這個改變只能由網頁的製作者來做,閱讀網點的人是無法改變 WWW 伺服器上的內容的,只能將原始檔案存到本地,去掉上面的標記再將就地看,或換 Netscape 瀏覽器。 儘管 Netscape 3.x 不會出現上面兩篇文章提到的兩種類型的亂碼,但是除了漢字的亂碼外, IE 和 Netscape 瀏覽器在很多方面都表現出顯著的差異,正是網點設計的千差萬別,決定了我們單純使用一種瀏覽器顯然不如同時擁有兩個瀏覽器更方便一些。有的網友耽心它們之間有衝突是不必要的,除了你自己拿注意定下誰是缺省(默認)瀏覽器外,它們之間相安無事,無論是Netscape 3.x/4.x 還是 IE 3.x/4.x。 最後再提示一下,關於解決安裝 P IE4 後,Windows 95 的 Help 成爲亂碼的問題參見《亂碼大全(3)──漢字與亂碼》最後的介紹。 亂碼大全(11)──常見文件格式 在亂碼大全之(7)中,我們提到了 email 在進行文件編碼的時候要進行適當的說明,比如:Content-Type: text/plain;charset="gb2312",而如果是二進位文件則需要“Content-Type: application/x-download”或其他說明。也就是說 email (客戶)程式如何進行(正確地)解碼或恢復 Attached 文件,取決於發送 email 的程式如何組織 email 的全文。當它們配合不當的時候,亂碼就會發生。 還有很多情況,二進位文件沒有經過任何編碼就傳到 email 中了, email 程式不僅沒有還原二進位文件,而且傳來的 email 連檔案名都沒有帶。例如: MZ....莦S髛)沈ㄣs羖帶h=)膄溮鄐Hb戸El傽1gf溮鄐ore膏934sLLJD……………… …………………………………………………………………………………………… 這種情況現在是比較少了,但是並不是沒有。最好是讓對方重發。在你思考如何處理的時候,先判斷它們是什麽類型的文件有助於你採取合適的措施。由於文件類型是無法列全的,我們只能舉一些常見的例子。這些在其他場合,對於我們進行文件的恢復、判斷都有一些幫助。 這些亂碼在 email 中並不是有規律地顯示的,而是一長串的亂碼。只有碰巧遇到回車、換行符號才換行顯示。我們至少需要辨認的是這些文件的開頭: 辨認文件的開頭並不能 100% 地鑒別一個文件的類型,但是對於我們常見的情況往往是有效的。 如果 e
------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind
系統時間:2024-05-17 16:48:32
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!