結論
添付ファイルが開けないときは、届いた名前と、相手が送るつもりだった形式を先に照合します。 特にwinmail.datでは、目的の資料が別の形式で包まれていることがあります。末尾を.pdfへ変えるだけでは、その資料をPDFに変換したことにはなりません。
winmail.dat変換中に含まれる添付と本文を確認する登録なしで使えます開く
ここでは自作データ3入力を使い、winmail.datの読取りと、名前だけを変えた場合の違いを確かめました。実際に届いたメールを検査したものではありません。普通のPDFやZIPで起きる開封失敗まで、同じ原因と判断する記事ではありません。
winmail.datには元の添付が入っている場合がある
winmail.datは、送信時のメール情報をまとめるTNEF形式のファイルとして届くことがあります。 Microsoftは、そこに含まれる場合がある情報の1つを、一次資料の節に引用したとおり説明しています。
https://learn.microsoft.com/ja-jp/troubleshoot/outlook/message-body/how-tnef-affects-email-messages（2026-09-30 到達）
元の資料が1つでも、メール上で見える名前がその資料名とは限りません。 ただし、すべての.datファイルがTNEFという意味ではありません。名前だけを根拠に、本文や添付の存在を決めることはできません。
同資料では通常の添付にTNEFは不要とし、送信側でHTMLやプレーンテキストを選ぶ方法を説明しています。Outlookの機能によってはTNEFが必要な例外もあります。 本文の形式を変えれば、どの環境でも絶対に発生しなくなる、とは読み替えられません。
自作3入力で、名前と中身の違いを測った
n=3の入力を、当サイトのwinmail.dat展開の既存処理で各1回読み取りました。 2026年9月30日、Windows・Node.jsで画面から独立した読取処理を実行しました。送受信やメールアプリの操作は含みません。
元のTNEFは自作の497バイトです。日本語の短い本文、memo.txt、2×2画素のPNGを入れました。2つ目は同じバイト列をrenamed.pdfの名前で保存し、3つ目は普通の英語のテキストに.datの末尾を付けています。
| 自作入力 | 中身 | winmail展開の結果 |
|---|---|---|
| winmail.dat・497バイト | TNEF | 添付2件と日本語本文を取得 |
| renamed.pdf・497バイト | 上と同じTNEF | 同じ添付2件と本文を取得 |
| plain-winmail.dat・31バイト | 普通のテキスト | TNEF形式ではないと判定 |
最初の2入力は中身が完全に同じなので、同じ結果になるのは想定内です。独立した3種類のメールを受信した成功率ではなく、同一データの名前変更を含む比較です。
取り出した添付も、作成時の値と別経路で照合しました。
| 添付名 | 大きさ | 作成時の値との照合 |
|---|---|---|
| memo.txt | 34バイト | Shift_JISの日本語文字列と全バイト一致 |
| 写真.png | 75バイト | 自作PNGと全バイト一致、2×2画素 |
2入力とも、取り出した添付の名前・大きさ・内容が一致しました。PNGには短い名前も含めましたが、結果は長い名前の「写真.png」でした。これは今回作った最小データでの結果です。
一方、renamed.pdfを別のPDF読取処理で開くと、PDFとしては読取りエラーになりました。winmail展開が読めたことと、PDFのアプリが読めることは同じではありません。
再送を頼む時は、届いた状態を具体的に伝える
拡張子を直すことと、別の形式に保存し直すことは別の操作です。MicrosoftのWindows向け説明にも、次の記載があります。
https://support.microsoft.com/ja-jp/windows/experience/storage-filemanagement/common-file-name-extensions-in-windows（2026-09-30 到達）
名前を変えて試し続けるより、相手が送った元の資料名と、こちらに届いた添付名の差を伝えると、確認対象が明確になります。MozillaのThunderbird向け説明でも、送信側の設定について次の相手を挙げています。
https://support.mozilla.org/en-US/kb/what-winmaildat-attachment（2026-09-30 到達）
送信者またはそのシステム管理者、という意味です。設定の確認を含む説明であり、受信者側で一律に直せるという案内ではありません。
再送の連絡には、届いた名前・想定していた資料・希望する受け取り方を入れると整理できます。たとえば、元がPDFの請求書だと分かっている場面なら、次の文面が考えられます。
「添付がwinmail.datとして届き、請求書の内容を確認できていません。元のPDFファイルを通常の添付として再送いただけますでしょうか。再送後も同じ状態になる場合は、送信形式の確認をお願いいたします。」
これは本記事の自作文例です。相手が実際にPDFを用意しているか不明な場合は、その前提を置かず、元の資料名や形式を尋ねる内容になります。受信側のアプリ名とエラー文も、判明している範囲で添えられます。
一次資料
本文で参照した一次資料の引用と出典をまとめます。
「元のメッセージに追加された通常の添付ファイル」
出典：Microsoft Learn「メッセージ形式が電子メール メッセージに与える影響」、TNEFの詳細。
「拡張子を変更してもファイルが別の形式に変換されるわけではなく」
出典：Microsoft「Windows の一般的なファイル名拡張子」。
“the sender of the message (or their system administrator)”
出典：Mozilla「What is the winmail.dat attachment?」。
測っていないこと・ここから先は推論
Outlook・Exchange・Thunderbird・iPhoneでの実送受信と、設定変更後の再発防止は測っていません。 自作TNEFの本文と添付を確認しただけで、すべての実メール、壊れたデータ、特殊な添付に対応する結果ではありません。
RTFの書式再現や、安全性の検査も行っていません。 実測に含まれるRTF部分は模型であり、展開・表示の成功例として数えていません。取り出せることと、ファイルの内容を信頼できることは別に残ります。
次の1手
届いた添付名をそのまま控え、送信者が用意した資料名と比べるところから確認できます。winmail.datなら中の添付を確かめる方法があります。元の形式が分からない、または取り出しても確認できない場合は、届いた状態を伝える再送依頼が次の確認につながります。