通過MIME可以輕鬆發送帶有電子郵件的文件附件。 這是它的工作原理。
MIME代表“多用途Internet郵件擴展”。 聽起來既複雜又毫無意義，但MIME以令人興奮的方式擴展了互聯網電子郵件的原始功能。
自1982年以來， 電子郵件已由RFC 822（及後來的RFC 2822）定義，他們很可能會在很長一段時間內繼續遵守這一標準。
沒有文字，純文字
不幸的是，RFC 822存在一些缺點。 最值得注意的是，符合該標準的消息不得包含任何東西，除了純ASCII文本。
為了發送文件（如圖片，文本處理器文檔或程序），必須先將它們轉換為純文本，然後將轉換結果發送到電子郵件正文中。 收件人必須從郵件中提取文本並將其再次轉換為二進製文件格式。 這是一個繁瑣的過程，並且在MIME之前，這一切都必須手工完成。
MIME糾正了附加到RFC 822的這個問題，並且它還可以在電子郵件中使用國際字符 。 由於RFC 822限制了簡單（英文）的文本，這在以前是不可能的。
缺乏結構
除了限制為ASCII字符，RFC 822不會識別消息的結構或數據的格式。 由於顯然你總是會得到一個純文本數據的垃圾，所以在標准定義時這是沒有必要的。
相比之下，MIME允許您在一條消息（例如圖片和Word文檔）中發送多個不同數據，並且它會告知收件人的電子郵件客戶端數據的格式，以便他們可以在智能選項中顯示消息。
當你得到一張照片時，你不再需要弄清楚它可以通過圖像查看器查看。 您的電子郵件客戶端顯示圖像本身或在計算機上啟動一個程序。
建立和擴展RFC 822
現在MIME魔法如何工作？ 基本上，它採用了上述以明文形式發送任意數據的麻煩過程。 MIME消息標準不替代RFC 822中規定的標準，但對其進行了擴展。 MIME消息不能包含除ASCII文本以外的任何內容。
這意味著所有電子郵件數據在發送消息之前仍然必須以純文本格式編碼，並且必須在接收端重新解碼為原始格式。 早期的電子郵件用戶必須手動完成。 MIME通常通過稱為Base64編碼的智能流程，為我們舒適無縫地完成它。
作為MIME電子郵件的生活
當您在能夠MIME的電子郵件程序中撰寫郵件時，該程序大致如下：
- 如果消息僅以純文本格式顯示，它將使其保持獨立狀態，並且只會告知收件人的電子郵件客戶端除了純文本外，什麼都不會期望。
- 如果郵件包含一個或多個附件和HTML格式的正文，則每個部分都會分別查看和處理。
首先，確定數據的格式。 這是必要的，以告訴收件人的電子郵件客戶端如何處理數據，並確保正確的編碼，因此在傳輸過程中不會丟失任何內容。
然後，如果數據的格式不是純文本格式，則數據將被編碼。 在編碼過程中 ，數據被轉換為適合RFC 822消息的純文本。
最後，將編碼的數據插入到消息中，並且通知收件人的電子郵件客戶端需要哪些類型的數據：是否有附件？ 他們如何編碼？ 原始文件的格式是什麼？
在收件人的最後，這個過程是相反的。 首先，電子郵件客戶端讀取發件人的電子郵件客戶端添加的信息：是否必須查找附件？ 我如何解碼它們？ 我如何處理結果文件？ 然後，如果需要，消息的每個部分都被提取和解碼。 最後，電子郵件客戶端將結果部分顯示給用戶。 純文本正文與圖像附件一起顯示在電子郵件客戶端中。 該消息附帶的程序也會顯示附件圖標 ，用戶可以決定如何處理。 她可以將其保存在磁盤上的某個位置，也可以直接從電子郵件程序啟動它。