Can you summarize the following document?
        
  MIME是通過標準化電子郵件報文的頭部的附加域(fields)而實現的;這些頭部的附加域,描述新的報文型別的內容和組織形式。

  MIME版本(MIME-Version),這個頭部域在郵件訊息的報文用一個版本號碼來指明訊息遵從的MIME規範的版本。目前版本是1.0。

  內容型別(Content-Type),這個頭部領域用於指定訊息的型別。一般以下面的形式出現。  type有下面的形式。  subtype用於指定type的詳細形式。content-type/subtype配對的集合和與此相關的引數,將隨著時間而增長。為了確保這些值在一個有序而且公開的狀態下開發,MIME使用Internet Assigned Numbers Authority (IANA)作為中心的序號產生器制來管理這些值。常用的subtype值如下所示: 此外,尚未被接受為正式資料型別的subtype,可以使用x-開始的獨立名稱(例如application/x-gzip)。vnd-開始的固有名稱也可以使用(例:application/vnd.ms-excel)。  parameter可以用來指定附加的資訊,更多情況下是用於指定text/plain和text/htm等的文字編碼方式的charset引數。MIME根據type制定了預設的subtype,當客戶端不能確定訊息的subtype的情況下,訊息被看作預設的subtype進行處理。Text預設是text/plain,Application預設是application/octet-stream而Multipart預設情況下被看作multipart/mixed。

  內容傳輸編碼(Content-Transfer-Encoding),這個區域使指定ASCII以外的字元編碼方式成為可能。形式如下: 其中,mechanism的值可以指定為“7bit”,“8bit”,“binary”,“quoted-printable”,“base64”。

  7位元ASCII碼。

  8位元ASCII碼。

  Not only may non-ASCII characters be present but the lines are not necessarily short enough for SMTP transport.

  因為歐洲的一些文字和ASCII字符集中的某些字元有部分相同。如果郵件訊息使用的是這些語言的話,與ASCII重疊的那些字元可以原樣使用,ASCII字符集中不存在的字元采用形如“=??”的方法編碼。這裡“??”需要用將字元編碼後的16進位制數字來指定。採用quoted-printable編碼的訊息,長度不會變得太長,而且大部分都是ASCII中的字元,即使不通過解碼也大致可以讀懂訊息的內容。

  base64是一種將二進位制的01序列轉化成ASCII字元的編碼方法。編碼後的文字或者二進位制訊息,就可以運用SMTP等只支援ASCII字元的協議傳送了。Base64一般被認為會平均增加33%的報文長度,而且,經過編碼的訊息對於人類來說是不可讀的。

  這個值是預留的擴充套件。
多用途網際網路郵件擴充套件(,縮寫:MIME)是一個網際網路標準,它擴充套件了電子郵件標準,使其能夠支援: MIME改善了由 RFC 822 轉變而來的 RFC 2822,這些舊標準規定電子郵件標準並不允許在郵件訊息中使用7位ASCII字符集以外的字元。正因如此,一些非英語字元訊息和二進位制檔案,影象,聲音等非文字訊息原本都不能在電子郵件中傳輸(MIME可以)。MIME規定了用於表示各種各樣的資料型別的符號化方法。此外,在全球資訊網中使用的HTTP協議中也使用了MIME的框架,標準被擴充套件為網際網路媒體型別。