電子郵件的發(fā)送和接收方法、終端的制作方法
【專利摘要】本發(fā)明公開一種電子郵件的發(fā)送和接收方法、終端，其發(fā)送方法包括：提交郵件正文，將郵件正文與預(yù)先上傳的附件的存儲ID編碼打包成郵件；判斷郵件收件方是否為本域賬號，若是，則將打包的郵件存儲至存儲服務(wù)器；否則根據(jù)附件的存儲ID從存儲服務(wù)器中獲取附件，將附件與郵件正文重新編碼后發(fā)送至外域服務(wù)器。本發(fā)明可大大減少網(wǎng)絡(luò)帶寬，節(jié)省了對附件的解碼和傳輸，提高了郵件閱讀速度并節(jié)省網(wǎng)絡(luò)資源；此外，上傳附件時，還可以根據(jù)存儲服務(wù)器中是否此附件而對相同附件進行有效排重，從而節(jié)省了終端存儲空間。
【專利說明】電子郵件的發(fā)送和接收方法、終端
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及互聯(lián)網(wǎng)【技術(shù)領(lǐng)域】，尤其涉及ー種電子郵件的發(fā)送和接收方法、終端?！颈尘凹夹g(shù)】
[0002]電子郵件通常包括郵件正文和附件，對電子郵件的處理包括附件的上傳、下載，郵件的發(fā)送和存儲等。
[0003]目前，對電子郵件的處理方式中，附件上傳是將本地的文件通過流式協(xié)議直接上傳到服務(wù)器；在發(fā)送郵件時，服務(wù)器將用戶上傳的文件，連同郵件正文，通過標(biāo)準(zhǔn)編碼格式編碼成一個文件(eml文件)，再通過標(biāo)準(zhǔn)smtp協(xié)議發(fā)送此編碼后的文件；在接收郵件時，月艮務(wù)器將接收到的郵件(即編碼后的eml文件)直接進行存儲。
[0004]但是，現(xiàn)有的郵件處理方式存在以下缺陷:
[0005]1、不能有效利用服務(wù)器上已經(jīng)存在的文件，浪費時間及網(wǎng)絡(luò)資源；
[0006]2、采用整個郵件打包發(fā)送的方式，浪費了網(wǎng)絡(luò)帶寬；
[0007]3、采用整個郵件打包保存的方式，對相同文件重復(fù)存儲，浪費存儲器的存儲空間。
【發(fā)明內(nèi)容】

[0008]本發(fā)明的主要目的在于提供ー種電子郵件的發(fā)送和接收方法、終端，g在節(jié)省網(wǎng)絡(luò)資源。
[0009]為了達(dá)到上述目的，本發(fā)明提出ー種電子郵件的發(fā)送方法，包括:
[0010]提交郵件正文，將所述郵件正文與預(yù)先上傳的附件的存儲ID編碼打包成郵件；[0011 ] 判斷郵件收件方是否為本域賬號，若是，則
[0012]將所述打包的郵件存儲至所述存儲服務(wù)器；否則
[0013]根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。
[0014]本發(fā)明還提出ー種電子郵件的接收方法，包括:
[0015]接收外域服務(wù)器發(fā)送的郵件；
[0016]解析所述郵件，獲取所述郵件的郵件正文和附件；
[0017]將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
[0018]本發(fā)明還提出一種電子郵件的發(fā)送終端，包括:
[0019]郵件打包模塊，用于提交郵件正文，將所述郵件正文與預(yù)先上傳的附件的存儲ID編碼打包成郵件；
[0020]判斷模塊，用于判斷郵件收件方是否為本域賬號，若是，則
[0021]第一存儲模塊，用于當(dāng)郵件收件方為本域賬號時，將所述打包的郵件存儲至所述存儲服務(wù)器；
[0022]發(fā)送模塊，用于當(dāng)郵件收件方為外域賬號時，根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。[0023]本發(fā)明還提出一種電子郵件的接收終端，包括:
[0024]第一接收模塊，用于接收外域服務(wù)器發(fā)送的郵件；
[0025]解析模塊，用于解析所述郵件，獲取所述郵件的郵件正文和附件；
[0026]第二存儲模塊，用于將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
[0027]本發(fā)明提出的一種電子郵件的發(fā)送和接收方法、終端，將郵件正文與附件分離存儲，在發(fā)送郵件時，若是發(fā)送給本域賬號，則無需帶附件發(fā)送，可大大減少網(wǎng)絡(luò)帶寬；在接收郵件后，用戶可根據(jù)需要僅取出郵件正文即可了解附件基本信息，節(jié)省了對附件的解碼和傳輸，提高了郵件閱讀速度并節(jié)省網(wǎng)絡(luò)資源；此外，上傳附件時，還可以根據(jù)存儲服務(wù)器中是否此附件而對相同附件進行有效排重，從而節(jié)省了終端存儲空間。
【專利附圖】

【附圖說明】
[0028]圖1是本發(fā)明電子郵件的發(fā)送方法第一實施例的流程示意圖；
[0029]圖2是本發(fā)明電子郵件的發(fā)送方法第二實施例的流程示意圖；
[0030]圖3是本發(fā)明電子郵件的接收方法第一實施例的流程示意圖；
[0031]圖4是本發(fā)明電子郵件的接收方法第二實施例的流程示意圖；
[0032]圖5a是本發(fā)明電子郵件的接收方法第三實施例的流程示意圖；
[0033]圖5b是本發(fā)明電子郵件的接收方法第四實施例的流程示意圖；
[0034]圖6是本發(fā)明電子郵件的發(fā)送終端較佳實施例的結(jié)構(gòu)示意圖；
[0035]圖7是本發(fā)明電子郵件的接收終端第一實施例的結(jié)構(gòu)示意圖；
[0036]圖8是本發(fā)明電子郵件的接收終端第二實施例的結(jié)構(gòu)示意圖。
[0037]為了使本發(fā)明的技術(shù)方案更加清楚、明了，下面將結(jié)合附圖作進一步詳述。
【具體實施方式】
[0038]本發(fā)明實施例的解決方案主要是:將郵件正文與附件分離存儲，在發(fā)送郵件時，若是發(fā)送給本域賬號，則無需帶附件發(fā)送，以減少網(wǎng)絡(luò)帶寬；在接收郵件后，用戶可根據(jù)需要僅取出郵件正文即可了解附件基本信息，以提高郵件閱讀速度，節(jié)省網(wǎng)絡(luò)資源；此外，上傳附件時，還可以根據(jù)存儲服務(wù)器中是否此附件而對相同附件進行有效排重，以節(jié)省終端存儲空間。
[0039]如圖1所示，本發(fā)明第一實施例提出一種電子郵件的發(fā)送方法，包括:
[0040]步驟S101，上傳附件，將所述附件保存至存儲服務(wù)器，記錄所述附件的存儲ID ；
[0041]在終端瀏覽器上上傳附件，將上傳的附件保存到本地的存儲服務(wù)器中，同時記錄附件在存儲服務(wù)器中的存儲ID，該存儲ID為附件在存儲服務(wù)器中的存儲索引號，比如MD5等，以便后續(xù)可以根據(jù)附件的存儲ID從存儲服務(wù)器中查找對應(yīng)的附件。
[0042]步驟S102，提交郵件正文，將所述郵件正文與所述附件的存儲ID編碼打包成郵件；
[0043]當(dāng)需要發(fā)送郵件時，通過優(yōu)化的郵件編碼協(xié)議將郵件正文與全部附件ID編碼打包成一封郵件。其中，郵件正文包含附件的基本信息，該基本信息包括附件的文件名、大小或附件ID。
[0044]步驟S103，判斷郵件收件方是否為本域賬號，若是，則進入步驟S104 ;否則，進入步驟S105 ；
[0045]其中，本域賬號是指本地郵箱系統(tǒng)內(nèi)部的賬號，比如，騰訊內(nèi)部郵箱系統(tǒng)中的賬號qq.com,相對本域賬號的其他賬號稱為外域賬號，比如網(wǎng)易郵箱系統(tǒng)中的一個賬號163.com
坐寸o
[0046]步驟S104，將所述打包的郵件存儲至所述存儲服務(wù)器；
[0047]步驟S105，根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。
[0048]本實施例將附件與郵件正文分開存儲，井根據(jù)郵件收件方是本域賬號還是外域賬號分別進行處理，若郵件收件方為本域賬號，則直接把打包的郵件存儲到存儲服務(wù)器；如果郵件收件方為外域賬號，則根據(jù)附件的存儲ID，從存儲服務(wù)器中取得附件，再采用通用的郵件編碼協(xié)議，將郵件正文和附件重新編碼后投遞給外域服務(wù)器。
[0049]本實施例通過將附件與郵件正文分開存儲，對于發(fā)送給內(nèi)域帳號的郵件，則整個發(fā)送和投遞過程中傳輸?shù)臄?shù)據(jù)無需包含附件，由此可以大大減少網(wǎng)絡(luò)帶寬。
[0050]需要說明的是，在其他實施例中，上述實施例中步驟SlOl也可以省略，而是預(yù)先上傳附件，并將上傳的附件預(yù)先保存至存儲服務(wù)器，記錄所述附件的存儲ID。
[0051]如圖2所示，本發(fā)明第二實施例提出ー種電子郵件的發(fā)送方法，在上述第一實施例的基礎(chǔ)上，在上述步驟SlOl之前還包括:
[0052]步驟S106，提取所述附件的附件特征；
[0053]步驟S107，根據(jù)所述附件特征判斷所述存儲服務(wù)器中是否存在所述附件；若存在，則進入步驟S108 ;否則，進入步驟SlOl ；
[0054]步驟S108，記錄所述附件的存儲ID ;進入步驟S102。
[0055]本實施例與上述第一實施例的區(qū)別在于，本實施例在上傳附件時，需要對附件進行排重處理，即對于相同的附件僅上傳一次。
[0056]具體地，在上傳附件時，從附件中提取附件的附件特征，該附件特征可以是附件的文件名、附件存儲ID (比如附件MD5)等。根據(jù)該附件的附件特征查找存儲服務(wù)器，判斷所述存儲服務(wù)器中是否存在該附件，若存在，則記錄該附件在存儲服務(wù)器中的存儲ID，若不存在，則直接上傳和存儲附件，并記錄該附件在存儲服務(wù)器中的存儲ID。在判斷存儲服務(wù)器中是否存在查找的附件時，根據(jù)該附件的附件特征，比如附件的MD5等，從存儲服務(wù)器中查找是否存在與該附件的MD5對應(yīng)的附件，若有，則表示存在該附件，否則不存在該附件。
[0057]本實施例在上述第一實施例的基礎(chǔ)上，對附件進行排重處理，進一歩判斷上傳附件在存儲服務(wù)器上是否已存在，若存在，則無需再重復(fù)上傳，從而可省去附件上傳的過程，并節(jié)省網(wǎng)絡(luò)資源。
[0058]如圖3所示，本發(fā)明第一實施例提出ー種電子郵件的接收方法，包括:
[0059]步驟S301，接收外域服務(wù)器發(fā)送的郵件；
[0060]步驟S302，解析所述郵件，獲取該郵件的郵件正文和附件；
[0061]步驟S303，將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
[0062]本實施例對接收的郵件正文和附件進行分離存儲，正文中只保留附件的基本信息，該基本信息包括附件的文件名、大小和附件在存儲服務(wù)器中的存儲ID等。若存儲服務(wù)器中存在該附件，則無需對附件進行重復(fù)存儲。[0063]本實施例通過上述方案，可以實現(xiàn)附件的排重存儲，節(jié)省存儲容量。
[0064]如圖4所示，本發(fā)明第二實施例提出一種電子郵件的接收方法，在上述第一實施例的基礎(chǔ)上，在上述步驟S303之后，還包括:
[0065]步驟S304，接收用戶的郵件讀取指令；
[0066]步驟S305，根據(jù)所述郵件讀取指令從所述存儲服務(wù)器中獲取所述郵件正文；
[0067]步驟S306，將所述郵件正文輸出展示給用戶。
[0068]本實施例與上述第一實施例的區(qū)別在于，本實施例可以根據(jù)用戶需要，將接收的郵件正文輸出展示給用戶，使用戶可以閱讀郵件正文。
[0069]在本實施例中，用戶在閱讀郵件時，只需從存儲服務(wù)器上取出郵件正文，由于郵件正文中包含了附件的基本信息，因此，附件的文件名稱、大小等信息可以同時展示給用戶，由此節(jié)省了對附件的解碼和傳輸，提高了郵件的閱讀速度，并節(jié)省網(wǎng)絡(luò)資源。
[0070]如圖5a所示，本發(fā)明第三實施例提出一種電子郵件的接收方法，在上述第二實施例的基礎(chǔ)上，在上述步驟S306之后，還包括:
[0071]步驟S307，接收用戶的附件下載指令；
[0072]步驟S308，根據(jù)所述附件下載指令，從所述存儲服務(wù)器中獲取所述附件；
[0073]步驟S309，將所述附件輸出展示給用戶。
[0074]本實施例在上述第二實施例的基礎(chǔ)上，可以根據(jù)用戶需要，將接收的附件下載輸出展示給用戶，使用戶可以閱讀郵件正文的同時，還可以下載附件，滿足了用戶的不同需求，為用戶提供了方便。
[0075]此外，上述圖5a所示的第三實施例中附件下載方案，還可以不結(jié)合圖4所示的第二實施例實施，而是結(jié)合圖3所示的第一實施例而實施。
[0076]具體地，如圖5b所示，本發(fā)明第四實施例提出一種電子郵件的接收方法，在上述第一實施例的基礎(chǔ)上，在上述步驟S103之后還包括:
[0077]步驟S307，接收用戶的附件下載指令；
[0078]步驟S308，根據(jù)所述附件下載指令，從所述存儲服務(wù)器中獲取所述附件；
[0079]步驟S309，將所述附件輸出展示給用戶。
[0080]本實施例在上述第一實施例的基礎(chǔ)上，可以根據(jù)用戶需要，將接收的附件下載輸出展示給用戶，使用戶根據(jù)郵件主題選項直接下載附件，而無需閱讀郵件正文，滿足了用戶的不同需求，為用戶提供了方便。
[0081]在具體實施過程中，可以在郵件主題欄中設(shè)置郵件名稱、附件選項，為郵件打開前，提供附件下載入口，從而，通過郵件正文和附件分離存儲的方式，為用戶對郵件的操作提供了方便。
[0082]如圖6所示，本發(fā)明較佳實施例提出一種電子郵件的發(fā)送終端，包括:上傳模塊601、郵件打包模塊602、判斷模塊603、第一存儲模塊604以及發(fā)送模塊605，其中:
[0083]上傳模塊601，用于上傳附件，將所述附件保存至存儲服務(wù)器，記錄所述附件的存儲ID;
[0084]郵件打包模塊602，用于提交郵件正文，將所述郵件正文與所述附件的存儲ID編碼打包成郵件；
[0085]在終端瀏覽器上上傳附件，將上傳的附件保存到本地的存儲服務(wù)器中，同時記錄附件在存儲服務(wù)器中的存儲ID，該存儲ID為附件在存儲服務(wù)器中的存儲索引號，比如MD5等，以便后續(xù)可以根據(jù)附件的存儲ID從存儲服務(wù)器中查找對應(yīng)的附件。
[0086]判斷模塊603，用于判斷郵件收件方是否為本域賬號，若是，則
[0087]第一存儲模塊604，用于當(dāng)郵件收件方為本域賬號時，將所述打包的郵件存儲至所述存儲服務(wù)器；
[0088]發(fā)送模塊605，用于當(dāng)郵件收件方為外域賬號時，根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。
[0089]其中，本域賬號是指本地郵箱系統(tǒng)內(nèi)部的賬號，比如，騰訊內(nèi)部郵箱系統(tǒng)中的賬號qq.com,相對本域賬號的其他賬號稱為外域賬號，比如網(wǎng)易郵箱系統(tǒng)中的一個賬號163.com
坐寸o
[0090]本實施例將附件與郵件正文分開存儲，井根據(jù)郵件收件方是本域賬號還是外域賬號分別進行處理，若郵件收件方為本域賬號，則直接把打包的郵件存儲到存儲服務(wù)器；如果郵件收件方為外域賬號，則根據(jù)附件的存儲ID，從存儲服務(wù)器中取得附件，再采用通用的郵件編碼協(xié)議，將郵件正文和附件重新編碼后投遞給外域服務(wù)器。
[0091]通過將附件與郵件正文分開存儲，對于發(fā)送給內(nèi)域帳號的郵件，則整個發(fā)送和投遞過程中傳輸?shù)臄?shù)據(jù)無需包含附件，由此可以大大減少網(wǎng)絡(luò)帶寬。
[0092]需要說明的是，在其他實施例中，上述實施例中上傳附件，將所述附件保存至存儲服務(wù)器，記錄所述附件的存儲ID的過程也可以由上傳模塊601預(yù)先完成。
[0093]進ー步的，所述上傳模塊601還用于提取所述附件的附件特征；根據(jù)所述附件特征判斷所述存儲服務(wù)器中是否存在所述附件；若存在，則記錄所述附件的存儲ID ;否則直接上傳和存儲附件，并記錄該附件在存儲服務(wù)器中的存儲ID。
[0094]在上傳附件吋，需要對附件進行排重處理，即對于相同的附件僅上傳一次。
[0095]具體地，在上傳附件時，從附件中提取附件的附件特征，該附件特征可以是附件的文件名、附件存儲ID (比如附件MD5)等。根據(jù)該附件的附件特征查找存儲服務(wù)器，判斷所述存儲服務(wù)器中是否存在該附件，若存在，則記錄該附件在存儲服務(wù)器中的存儲ID，若不存在，則直接上傳和存儲附件，并記錄該附件在存儲服務(wù)器中的存儲ID。在判斷存儲服務(wù)器中是否存在查找的附件時，根據(jù)該附件的附件特征，比如附件的MD5等，從存儲服務(wù)器中查找是否存在與該附件的MD5對應(yīng)的附件，若有，則表示存在該附件，否則不存在該附件。
[0096]通過對附件進行排重處理，進ー步判斷上傳附件在存儲服務(wù)器上是否已存在，若存在，則無需再重復(fù)上傳，從而可省去附件上傳的過程，并節(jié)省網(wǎng)絡(luò)資源。
[0097]如圖7所示，本發(fā)明第一實施例提出一種電子郵件的接收終端，包括:第一接收模塊701、解析模塊702以及第ニ存儲模塊703，其中:
[0098]第一接收模塊701，用于接收外域服務(wù)器發(fā)送的郵件；
[0099]解析模塊702，用于解析所述郵件，獲取該郵件的郵件正文和附件；
[0100]第二存儲模塊703，用于將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
[0101]本實施例對接收的郵件正文和附件進行分離存儲，正文中只保留附件的基本信息，該基本信息包括附件的文件名、大小和附件在存儲服務(wù)器中的存儲ID等。若存儲服務(wù)器中存在該附件，則無需對附件進行重復(fù)存儲。
[0102]本實施例通過上述方案，可以實現(xiàn)附件的排重存儲，節(jié)省存儲容量。[0103]如圖8所示，本發(fā)明第二實施例提出一種電子郵件的接收終端，在上述第一實施例的基礎(chǔ)上，還包括:
[0104]第二接收模塊704，用于接收用戶的郵件讀取指令；
[0105]獲取模塊705，用于根據(jù)所述郵件讀取指令從所述存儲服務(wù)器中獲取所述郵件正文；
[0106]輸出模塊706,用于將所述郵件正文輸出展不給用戶。
[0107]本實施例可以根據(jù)用戶需要，將接收的郵件正文輸出展示給用戶，使用戶可以閱讀郵件正文。
[0108]在本實施例中，用戶在閱讀郵件時，只需從存儲服務(wù)器上取出郵件正文，由于郵件正文中包含了附件的基本信息，因此，附件的文件名稱、大小等信息可以同時展示給用戶，由此節(jié)省了對附件的解碼和傳輸，提高了郵件的閱讀速度，并節(jié)省網(wǎng)絡(luò)資源。
[0109]進一步的，所述第二接收模塊704，還用于接收用戶的附件下載指令；
[0110]所述獲取模塊705，還用于根據(jù)所述附件下載指令，從所述存儲服務(wù)器中獲取所述附件；
[0111]所述輸出模塊706，還用于將所述附件輸出展示給用戶。。
[0112]上述方案可以根據(jù)用戶需要，將接收的附件下載輸出展示給用戶，使用戶可以閱讀郵件正文的同時，還可以下載附件，滿足了用戶的不同需求，為用戶提供了方便。
[0113]此外，上述第二實施例中附件下載方案還可以獨立于郵件正文展示方案而。具體地，在上述第一實施例的基礎(chǔ)上，可以根據(jù)用戶需要，將接收的附件下載輸出展示給用戶，使用戶根據(jù)郵件主題選項直接下載附件，而無需閱讀郵件正文，以滿足用戶的不同需求，在具體實施過程中，可以在郵件主題欄中設(shè)置郵件名稱、附件選項，為郵件打開前，提供附件下載入口，從而，通過郵件正文和附件分離存儲的方式，為用戶對郵件的操作提供了方便。
[0114]本發(fā)明實施例電子郵件的發(fā)送和接收方法、終端，將郵件正文與附件分離存儲，在發(fā)送郵件時，若是發(fā)送給本域賬號，則無需帶附件發(fā)送，可大大減少網(wǎng)絡(luò)帶寬；在接收郵件后，用戶可根據(jù)需要僅取出郵件正文即可了解附件基本信息，節(jié)省了對附件的解碼和傳輸，提高了郵件閱讀速度并節(jié)省網(wǎng)絡(luò)資源；此外，上傳附件時，還可以根據(jù)存儲服務(wù)器中是否此附件而對相同附件進行有效排重，從而節(jié)省了終端存儲空間。
[0115]以上所述僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或流程變換，或直接或間接運用在其它相關(guān)的【技術(shù)領(lǐng)域】，均同理包括在本發(fā)明的專利保護范圍內(nèi)。
【權(quán)利要求】
1.ー種電子郵件的發(fā)送方法,其特征在于,包括: 提交郵件正文，將所述郵件正文與預(yù)先上傳的附件的存儲索引號ID編碼打包成郵件； 判斷郵件收件方是否為本域賬號，若是，則 將所述打包的郵件存儲至所述存儲服務(wù)器；否則 根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述提交郵件正文步驟之前還包括: 上傳附件，將所述附件保存至存儲服務(wù)器，記錄所述附件的存儲ID。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述上傳附件之前還包括: 提取所述附件的附件特征； 根據(jù)所述附件特征判斷所述存儲服務(wù)器中是否存在所述附件；若存在，則記錄所述附件的存儲ID ;否則 執(zhí)行上傳附件的步驟。
4.根據(jù)權(quán)利要求1、2或3所述的方法，其特征在于，所述郵件正文包含附件的基本信息，所述基本信息至少包括以下之一:附件的文件名、大小或附件ID。
5.ー種電子郵件的接收方法，其特征在于，包括: 接收外域服務(wù)器發(fā)送的郵件； 解析所述郵件，獲取所述郵件的郵件正文和附件； 將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括: 接收用戶的郵件讀取指令； 根據(jù)所述郵件讀取指令從所述存儲服務(wù)器中獲取所述郵件正文； 將所述郵件正文輸出展示給用戶。
7.根據(jù)權(quán)利要求5或6所述的方法，其特征在于，還包括: 接收用戶的附件下載指令； 根據(jù)所述附件下載指令，從所述存儲服務(wù)器中獲取所述附件； 將所述附件輸出展示給用戶。
8.一種電子郵件的發(fā)送終端，其特征在于，包括: 郵件打包模塊，用于提交郵件正文，將所述郵件正文與預(yù)先上傳的附件的存儲ID編碼打包成郵件； 判斷模塊，用于判斷郵件收件方是否為本域賬號，若是，則 第一存儲模塊，用于當(dāng)郵件收件方為本域賬號時，將所述打包的郵件存儲至所述存儲服務(wù)器； 發(fā)送模塊，用于當(dāng)郵件收件方為外域賬號時，根據(jù)所述附件的存儲ID從所述存儲服務(wù)器中獲取附件，將所述附件與所述郵件正文重新編碼后發(fā)送至外域服務(wù)器。
9.根據(jù)權(quán)利要求8所述的終端，其特征在于，還包括: 上傳模塊，用于上傳附件，將所述附件保存至存儲服務(wù)器，記錄所述附件的存儲ID。
10.根據(jù)權(quán)利要求9所述的終端，其特征在于，所述上傳模塊還用于提取所述附件的附件特征；根據(jù)所述附件特征判斷所述存儲服務(wù)器中是否存在所述附件；若存在，則記錄所述附件的存儲ID ;否則上傳所述附件。
11.一種電子郵件的接收終端，其特征在于，包括: 第一接收模塊，用于接收外域服務(wù)器發(fā)送的郵件； 解析模塊，用于解析所述郵件，獲取所述郵件的郵件正文和附件； 第二存儲模塊，用于將所述郵件正文和附件分離存儲在存儲服務(wù)器中。
12.根據(jù)權(quán)利要求11所述的終端，其特征在于，還包括: 第二接收模塊，用于接收用戶的郵件讀取指令； 獲取模塊，用于根據(jù)所述郵件讀取指令從所述存儲服務(wù)器中獲取所述郵件正文； 輸出模塊，用于將所述郵件正文輸出展示給用戶。
13.根據(jù)權(quán)利要求12所述的終端，其特征在于， 所述第二接收模塊，還用于接收用戶的附件下載指令； 所述獲取模塊，還用于根據(jù)所述附件下載指令，從所述存儲服務(wù)器中獲取所述附件； 所述輸出模塊，還用 于將所述附件輸出展示給用戶。
【文檔編號】H04L29/06GK103595615SQ201210290561
【公開日】2014年2月19日 申請日期:2012年8月15日 優(yōu)先權(quán)日:2012年8月15日
【發(fā)明者】周顥, 李明強, 王曉兵, 王琪, 許家滔, 黃亮, 黃梓群, 杜嘉輝, 譚志遠(yuǎn), 朱建平 申請人:騰訊科技（深圳）有限公司