Howy 寫:
原文：
Sony客服中心自動回函[@IQCID=2146693]��
應該是＠這個符號造成的吧？
因為該主旨在outlook 與 webmail 上都是正常顯示唷
嗯嗯 outlook上面的decode RFC2047跟Thunderbird不一樣
這類的問題小弟有去追過Thunderbird的source code
基本上Thunderbird會發生這種問題跟RFC2047裡面的一個條文有關
RFC2047上說:An 'encoded-word' may not be more than 75 characters long...
所以在subject中按照標準的做法
每一行應該不可以超過75個字元才對
且在encoded-word裡不能出現任何不可視字元
但很遺憾的是有些mail軟體在送信時並未尊照RFC2047上的做法
(現在大部份的bbs mail sender也都沒有符合標準, EX:ptt)
所以造成長度超過75, 如下所示:
代碼:
Subject: [=?big5?Q?=AB=E6=C5=FD]=BA=F1=AEq=B1=E6=AE=FC=B0a=BA}=ABG=B6W=AD=C8=A5=C1=B1J?=
不符合標準的email就這樣直接被送出去了
但現在問題來了
在有些mail server的實作裡並未考量到像這樣標準外的狀況
所以在他收到第75個時就給予直接斷行
所以原本該在同一行的encoded-word被分成
2行所以收到的mail情況如下:
代碼:
Subject: =?big5?Q?=A8=BE=B8=F5=BC=D1=20=A5~=B0=D3=B3n=C5=E9=B7~=B0=AA=BA=D6=
A7Q=AFd=A4H=A4~?=
原本好好的一串編碼過的字元中間多了 0D 0A 09 這幾個不可視字元 (就是被分為2行之義)
我們再來看一看Thunderbird解encoded subject的source code
代碼:
檔名：nsMIMEHeaderParamImpl.cpp
func name:DecodeRFC2047Str(...)
中某一段
for (r = q + 2; *r != '?'; r++) {
if (*r < ' ') goto badsyntax; --->意思是遇到不可視字元就當做是bad syntax 不解碼
}
所以...亂碼就是這樣產生的
(其實不叫做亂碼,他只是沒解碼直接顯示encoded str而已)
因為之前小弟一開起Thunderbird也是被這種滿是亂碼的email所困擾
所以就自己"亂改"了一下code
用很簡單的方法 逼Thunderbird去解碼
改過的source code檔案附在後面有興趣的大大可以自己去參考
我應該是只有動到DecodeRFC2047Str這個function裡面的code而已
代碼:
另外還有一種情況會造成Thunderbird中間某幾個字亂碼
簡單說就是如果字串太長照RFC2047去分成很多個字串
如果切的不好一個中文字裡的字元剛好被分在不同的encoded str裡
那這個字就亂碼了
因為Thunderbird會對不同的encoded str會各自處理
這是考量到不同的encoded str有可能是不同charset的關係
但如果Thunderbird能把前後一樣的charset的encoded str
合起來處理就能避免上述的亂碼情況
也能對不同charset的encoded str正確解碼
說到outlook...
對! outlook都不會有如上面這2種亂碼出現
但這不是因為他code寫的很好
我覺得是他有一些"bug"的關係
對bad syntax都不予理會
不同的charset encoded str也沒有分開處理
所以遇到不同的charset在subject裡...
就變成outlook亂碼
Thunderbird正確解碼的情況
(MS程式員偷懶,該抓來打屁股
)
PS:
我上面所說的都是針對Subject的部份
我上面的outlook 是 Outlook Express
RFC2047:
http://www.faqs.org/rfcs/rfc2047.html代碼:
有錯誤的話還請大家多多指教
登入
註冊
問答集
搜尋
