如何開啟 winmail.dat 檔案

在瀏覽器裡開啟 winmail.dat,把被困住的附件取回來。說明這個檔案到底是什麼、你為什麼會收到,以及寄件者要怎麼做才不會再發生。

winmail.dat 不是壞掉的檔案,也不是病毒。它是寄件者的 Outlook 把郵件打包成微軟專有的 TNEF 格式、而中間的郵件系統無法還原時,你會收到的東西。排版過的內文,以及真正讓你困擾的那部分 —— 所有真正的附件 —— 全都封在裡面。

你為什麼會收到這個檔案

Outlook 可以用 RTF(Rich Text Format)寄信,那是微軟專有的格式,標準的網際網路郵件沒有辦法表達。這種時候,Outlook 會把所有塞不進去的東西 —— 排版,以及每一個附件 —— 打包成一個叫做 TNEF(Transport Neutral Encapsulation Format)的區塊。如果收件方也是 Outlook,它會安靜地拆開,你根本不會發現發生過這件事。

但其他任何系統 —— Gmail、Apple Mail、Thunderbird、手機、工單系統、封存系統 —— 都不知道該怎麼拆,於是就把這個原始區塊照 Outlook 給的名字丟給你:winmail.dat。由此可以得到兩個結論:

這不是你的錯,也不是寄件者的錯。問題出在某一封信、或某一筆 Outlook 聯絡人資料上的一個設定,而你們兩邊大概都不知道它存在。
你的附件沒有不見。它們就在這個檔案裡面。這才是重點,也是為什麼值得把 winmail.dat 打開,而不是回信請對方重寄。

在這裡開啟

把郵件中的 winmail.dat 存下來。
拖到檢視器上。
閱讀郵件內容,並單獨下載附件或打包成 ZIP。

解析在你的瀏覽器內執行,不會上傳。這一點在這裡比平常更重要:winmail.dat 幾乎都出現在本來就不該離開公司的討論串裡,而最直覺的替代方案 —— 一個要你上傳檔案的轉檔網站 —— 等於是把那份東西送到一台你一無所知的伺服器上。

能取回什麼、不能取回什麼

主旨、寄件者、日期、排版後的內文,以及每一個附件,都存在這個檔案裡,全部都能取回。

收件者清單則不行,而且沒有任何工具能從這個檔案還原它。TNEF 是夾在一封「載體郵件」裡面的附件,而收件者、副本與網際網路標頭都屬於那封載體郵件,不屬於這個附件。如果你需要那些資訊,它們就在你收到 winmail.dat 的那封信上 —— 去看那封信的標頭。任何宣稱能從 winmail.dat 顯示收件者清單的工具,都是在猜。

這個檔案裡面實際上是什麼

winmail.dat 不是壓縮檔,也不是 .msg。它是一串長度前綴的屬性,規格為 MS-OXTNEF, 開頭是一個四位元組的簽章:0x223E9F78(小端序)。讀取器就是靠這個簽章辨識它 —— 不管檔案被改成什麼名字。這件事很重要,因為郵件閘道一天到晚在改這種檔案的名字。

簽章之後是一連串記錄,每一筆帶著:一個層級位元組(說明它屬於郵件本身, 還是屬於當下正在描述的那個附件)、一個屬性 id、長度、資料,以及一個檢查碼。走訪它並不難;有趣的是那些記錄裡裝了什麼。

有些裝的是單純的值 —— 主旨、寄送日期、寄件者的顯示名稱。另一些裝的是序列化的 MAPI 屬性區塊: 跟 .msg 用的是同一套屬性模型,只是被攤平成位元組。真正的內容在那裡,這也是為什麼一個 TNEF 讀取器最後會跟 .msg讀取器共用大部分邏輯 —— 儘管這兩種格式在結構上毫無相似之處。

為什麼這裡的內文通常也不是 HTML

內文遵循跟 .msg 相同的優先順序:有 PidTagHtml 就用它, 否則反封裝 PidTagRtfCompressed,再否則用純文字。

而它通常就是 RTF。這不是巧合 —— 那正是這個檔案存在的全部理由。winmail.dat 之所以會產生,就是因為 Outlook 當時正在用 RTF 格式寄送, 所以它承載的郵件幾乎依定義就是 RTF。一個「能取出附件、但內文只顯示純文字」的工具,是跳過了反封裝那一步 —— 你看到的是一封就擺在眼前的完整郵件的降級版本。同樣的問題也發生在 .msg 上, 只是那裡是「非常常見」,這裡則接近「一定如此」。

為什麼收件者清單是真的沒有了

這一點值得精確地講,因為宣稱做得到的工具是在猜。

TNEF 保留寄件者。它不保留收件者、副本或網際網路標頭 —— 不是因為格式裡沒有位置放,而是因為這個檔案所處的位置。winmail.dat 是夾在一封載體郵件裡面的附件。收件者和傳遞路徑屬於那封載體郵件,而這個附件從來就沒有拿到過副本。

所以如果你需要知道還有誰收到了這封信,答案在你收到 winmail.dat的那封信上 —— 去看那封信的標頭。任何顯示「從 winmail.dat 取出的收件者清單」的檢視器, 給你看的是它自己編出來的東西。

為什麼附件還保有真正的檔名

一個相當實用的細節:TNEF 把附件的名字存了兩次。一個是舊式的 8.3 標題 —— INVOIC~1.PDF —— 另一個在 MAPI 屬性區塊裡,PidTagAttachLongFilename,存的是真名:Invoice 2026-03.pdf。

只讀舊式屬性的讀取器,會給你一個裝滿截斷大寫檔名的資料夾。優先採用長檔名,是「取回你的文件」和「取回一堆還要一個一個辨認的東西」的差別。 MIME 類型也有存,在 PidTagAttachMimeTag 裡, 所以檔案回來時帶著正確的類型,而不是從一個被截斷的副檔名猜出來的。

內嵌圖片會標上 content id,那正是它們能出現在內文裡、而不是塞滿附件清單的原因 —— 跟一般 HTML 郵件裡 cid: 參照是同一套機制。

如果你要自己寫讀取器,有個 bug 值得知道

TNEF 屬性區塊裡的字串是以 NUL 結尾儲存的。要去掉那個填充,最直覺的做法是把尾端的零位元組修掉 —— 而那對任何 Unicode 內容都是錯的。

在 UTF-16LE 裡,每一個拉丁字元的高位位元組都是 0x00。Whitfield 這個字結尾是 64 00, 加上終止符之後緩衝區尾端是 64 00 00 00。按位元組修剪會吃掉三個零,剩下奇數個位元組,最後一個字母就解碼成替代字元。每一個字串都會少掉最後一個字,而且是安靜地少 —— 看起來像顯示問題,而不是解碼錯誤。

正確做法是以完整的 code unit 為單位修剪,UTF-16 就是一次兩個位元組。這是件小事,而且是那種「只有在你拿非 ASCII 的東西測試時才會現形」的小事。

寄件者要怎麼做才不會再發生

這一段值得轉告對方,因為它是從源頭解決,而不是一封一封處理。在 Windows 版 Outlook 中:

只改這一封:在撰寫視窗中開啟文字格式, 把 RTF 文字改成 HTML 或純文字。
全部都改:檔案 → 選項 → 郵件,在「撰寫郵件」下把格式設為 HTML。
只有某個人特別會這樣:如果每次都是同一個人,通常就是這個原因。開啟那筆聯絡人,連按兩下電子郵件地址,把「網際網路格式」設成傳送純文字或 HTML, 而不是 Outlook RTF。自動完成的快取可能還留著舊設定,所以請先用下拉選單上的 X 把該地址從收件者欄刪掉,再重新輸入一次。