JavaMail常見問題之編程問題

2019-11-18 13:15:35

字體：大中小

來源：轉載

供稿：網友

　　問. 從哪里可以學習有關 Internet 郵件的基礎知識，它是我高效編寫 javaMail 程序需要知道的？
　　答：參見我們的 Web 頁中提及的參考圖書中的一本，獲得有關 Internet 電子郵件、MIME、SMTP、IMAP 和 POP3 等的背景信息。
　　問. 如何調試使用 JavaMail API 的應用程序？
　　答：可通過在代碼中調用 session 對象上的 setDebug(true) 方法來打開調試模式。這將造成在控制臺中打印調試消息，包括協議跟蹤信息。假如您認為在 JavaMail 中發現了 bug，就將這個跟蹤及以下信息發送給我們：重生成問題的測試用例、使用的平臺、使用的 JDK 的版本和使用的郵件服務器 (IMAP, SMTP) 的名稱和版本。
　　問. 如何發送帶有附件的消息？
　　答：帶有附件的消息采用 MIME 多部分消息來表示，其中第一部分是消息的主體，其他的部分是附件。有大量的例子，它們展示了如何在演示程序中構建這種消息，JavaMail 下載包包含了這些演示程序。
　　問. 如何閱讀帶有附件的消息并保存附件？
　　答：如前面描述，在 MIME 中，帶有附件的消息是作為多部分消息表示的。在簡單的例子中，Message 對象的 getContent 方法的結果將是一個 MimeMultipart 對象。多部分對象的第一個主體部分將是消息的主文本。其他的主體部分將是附件。msgshow.java 演示程序展示了如何在消息中遍歷所有的多部分對象，并提取各個主體部分數據。getDisposition 方法將給你一個提示，指出主體部分是否應該內嵌顯示，或者應該將其考慮成附件（但請注重，不是所有的發件人都提供這一信息）。
　　為了將主體部分中的數據保存到文件（比如），請使用 getInputStream 方法來訪問附件內容，并將數據復制到 FileOutputStream。
　　注重，也有一些更復雜的情形也要處理。例如，一些發件人把主體作為純文本和 Html 發送。通常，這將作為 multipart/alternative 內容（和 MimeMultipart 對象）出現在簡單的文本主體部分的位置中。經過數字簽名或加密的消息甚至會更復雜。處理所有的這些情形可能具有挑戰性。請參考各種 MIME 規范和我們主頁上列出的其他參考資料。
　　問. 什么是“中斷支持”（disconnected support）？
　　答：支持中斷操作的郵件客戶端將答應用戶訪問遠程消息存儲（比如 IMAP）中消息，緩存這些消息中的一些消息的（部分）到本地，然后斷開到服務器的連接。當處在斷開連接狀態中，郵件客戶端可以訪問已經緩存的消息，可能也可以刪除它們或將它們保存到其他文件夾。當郵件客戶端下一次連接到遠程消息存儲時，本地所做變更會與遠程存儲同步。同樣，中斷支持可以答應客戶端在斷開與服務器連接時“發送”消息，在到服務器的連接可用前，消息會進行排隊。也請參閱 RFC1733。
　　問. 如何使用 JavaMail API 來支持中斷操作？
　　答：JavaMail API 規范定義了一些接口，郵件客戶端可以使用這些接口來支持中斷操作。我們的 IMAP 提供程序實現了這些接口（UIDFolder 接口）。
　　問. 我如何使用 JavaMail API 來發送安全的電子郵件？
　　答：JavaMail API 目前不支持發送或接收安全電子郵件。JavaMail API 的體系結構使得可以在以后很輕易地添加這一支持，我們可以添加支持，第三方也可以添加支持。有關當前電子郵件安全標準（S/MIME 和 PGP）的信息，可以從如下站點找到： http://www.imc.org/smime-pgpmime.html。請瀏覽我們的第三方產品頁，獲取來自其他供給商的解決方案。
　　問. writeTo() 方法生成了消息文件，但消息中的一些行既不是數據的規范 MIME 表示（即使用 CRLF 來結束行），又沒有使用我的平臺的規范行分隔符（例如 UNIX 上的“/n”）。假如我需要這些表示時，如何獲得它們當中的任何一種表示？
　　答：不管是哪種情形，你都將需要創建合適的 FilterOutputStream 對象來傳遞給 writeTo()。FilterOutputStream 將需要接受特定的一些行，它們具有任何常見終止符，然后寫出另外的一些特定行，它們只具有期望的行終止符。下面是這種過濾器的一些例子。NewlineOutputStream 轉換到本地平臺的行終止符，當將消息寫到文件時，它是有用的。CRLFOutputStream 轉換到 MIME 規范 CRLF 終止符，當需要規范 MIME 格式時（比如計算數字簽名），它是有用的。
　　問. 我可以使用 JavaMail API 來實現郵件服務器嗎？
　　答：JavaMail API 設計目的不是幫你實現郵件服務器。但是，對你來說，一些實用工具類，比如 MIME 消息解析類，可能是有用的。通常您會發現，JavaMail API 是在“簡單”而不是在“強有力”方面出錯。對于郵件客戶端，那是合適的，但對于郵件服務器，結果可能是不同的。
　　問. 我可以使用 JavaMail API 在我的郵件服務器上添加新的用戶賬戶、刪除用戶賬戶或改變用戶賬戶的密碼嗎？
　　答：JavaMail API 不包括任何工具，用于添加、刪除或修改用戶賬戶。在這一方面是沒有標準的，每個郵件服務器對它的處理是不同的。
　　問. 為什么 MimeMessage 類沒有實現 Serializable，這樣我就可以將消息序列化到磁盤，并在以后讀回它？
　　答：JavaMail API 是在現有電子郵件系統上面設計的，并使用了現有的消息格式。對于這樣的一些實現，使用 Java 序列化能力既不是必要的，也不是有用的，因此，不能將它作為 JavaMail API 的目標來考慮。
　　有關序列化 Message 的困難部分是保留某些指針，它們指向 Folder（文件夾）、Store（存儲）和 Session（會話）。假如只想保存消息的內容，而不是對象本身，消息的 writeTo 方法將為你完成這一切。假如想根據序列化消息創建整個電子郵件系統，您應該能夠編寫 Message 等的子類，并在子類中實現 Serializable。
　　假如想序列化自己的引用了 MimeMessages的其他對象，那么你的對象的 writeObject 方法可以使用 MimeMessage 的 writeTo 方法，對象的 readObject 方法可以使用 MimeMessage 構造函數，該構造函數會得到 InputStream。在構造 MimeMessage 時，你的類將需要提供一個 Session。
　　問. 我如何編寫服務提供程序？
　　答：請閱讀服務提供程序文檔，獲取一些細節信息。通常，假如想編寫 Store 提供程序，那就編寫 javax.mail.Store 和 javax.mail.Folder的子類，也可能要編寫 javax.mail.Message 及其他一些類的子類。對于 Transport 提供程序，編寫 javax.mail.Transport 的子類，也可能需要編寫 javax.mail.Message 及其他的一些類的子類。然后在 javamail.PRoviders 注冊表中，添加描述提供程序的條目。假如對編寫非凡的服務提供程序感愛好，并且它所針對的協議或郵件系統目前沒有得到 JavaMail API 實現的支持，請通過 [email protected] 聯系我們。
　　問. 我在登錄 Microsoft Exchange 服務器時碰到了麻煩，我確信正在使用的用戶名和密碼是正確的，我做錯了什么？
　　答：當登錄 Exchange 時，需要使用比簡單登錄名更多的用戶名。例如，假如你的電子郵件地址是“[email protected]”，Windows NT 登錄名是“juser”，NT 域名是“dom”，而且 Exahange 郵箱名是“Joe User”，那么在使用 JavaMail 登錄時，你將需要使用用戶名 “dom/juser/J.User”。
　　問. 在發送二進制文件前，我如何編碼它？當收到它時，我又如何解碼它？
　　答：你不必這樣的做！JavaMail 將自動決定合適的編碼用于消息部分，然后才發送消息。而且當讀取它們時，將自動解碼消息部分。getInputStream 方法將返回解碼數據。
　　問. 假如我不需要自己編碼和解碼附件，我應該何時使用 MimeUtility 方法？
　　答：在 JavaMail 沒有自動處理的情況下，MimeUtility 方法是有用的。經常發生的這樣的一種情形是文件名的編碼。基本的 MIME spec（規范）不答應按某種方式編碼標題參數值（比如文件名參數），該方式與（比如）編碼 Subject（主題）標題相同。這限制了參數值，從而限制了文件名到 ASCII。但一些發件人卻實際使用 MIME 文本編碼來做非 ASCII 文件名的編碼工作。想與這種非標準發件人互操作的應用程序可以使用 encodeText 方法來編碼文件名，然后調用 MimeBodyPartsetFileName 方法，而且可以使用 decodeText 方法來解碼返回的文件名。
　　問. 盡管 JavaMail 完成了所有的編碼和解碼工作，但我仍需要手動控制一些主體部分的編碼。
　　答：在少數的場合需要控制編碼，這里有幾個方法來重寫 JavaMail 的默認行為。下面是一個簡單的方法。在創建整個消息后，調用 msg.saveChanges()，然后使用像 mbp.setHeader("Content-Transfer-Encoding", "base64") 的語句來強制對指定主體部分做 base64 編碼。
　　另一種辦法是編寫 MimeBodyPart 的子類，并重寫 updateHeaders 方法，讓它首先調用 super.updateHeaders()，然后像上面那樣設置 Content-Transfer-Encoding 標題。
　　問. 為什么 JavaMail 沒有在非 ASCII 字符集中正確編碼和解碼文件名？
　　答：文件名是作為參數存儲在 MIME 標題中的。形如 =?ISO-8859-15?B?5OTkLUluZm8UCGRm?= 的編碼文件名不是 MIME spec（規范）的一部分。形如 =?A?B?C?= 的文件名是一個完全有效的文件名，而不是一個不正確編碼的文件名。JavaMail 沒有編碼和解碼文件名，因為這樣做會違反 MIME 規范。
　　基本的 MIME 規范不答應編碼參數。RFC 2231 定義了一種新的方式，使得可以在 MIME 標題中包括編碼參數，包括文件名。它與下面的事實方式不兼容：許多應用程序非法編碼文件名。支持 RFC 2231 將不答應 JavaMail 與這些現有的程序互操作。據我所知，很少現有的程序支持 RFC 2231。
　　假如你選擇違反 MIME 規范是為了與其他也違反了 MIME的程序互操作，那么 JavaMail 會給您所有需要的工具來完成這件事。
　　編碼文件名的解決方法是簡單的：
　　mbp.setFileName(MimeUtility.encodeText(filename));
　　解碼文件名的解決方法同樣簡單：
　　String filename = MimeUtility.decodeText(part.getFi

上一篇：JavaMail常見問題之發送郵件問題

下一篇：修改ZipInputStream支持中文名文件解壓