编辑“︁UTF-7”︁（章节）

== 簡介 ==

UTF-7首次被提出是在一個實驗性的通訊協定裏（RFC 1642，A Mail-Safe Transformation Format of Unicode），這份[[RFC]]（Request for Comments）提案後來因RFC 2152的提出而被取代（RFC 2152本身為新聞型（informational）的文案）。在RFC 2152當中明確的指出該份RFC本身不為網際網路的標準做出任何明確的定義（明列於文案前頭的Status of this Memo）。儘管這份RFC 2152在IANA（Internet Assigned Numbers Authority）的字元集列表裏被引述為UTF-7，然而UTF-7本身並非Unicode的標準之一，即使在目前最新的Unicode 5.0裏也僅列出UTF-8、UTF-16和UTF-32。

如同引言所提到的，由於在過去SMTP的傳輸僅能接受7位元的字元，而當時Unicode並無法直接滿足既有的SMTP傳輸限制，在這樣地背景下UTF-7被提出。嚴格來說UTF-7不能算是Unicode所定義的字元集之一，較精確的來說，UTF-7是提供了一種將Unicode轉換為7位元US-ASCII字元的轉換方式。

有些字元本身可以直接以單一的ASCII字元來呈現。第一個群組被稱作「direct characters」，其中包含了62個數字與英文字母，以及包含了九個符號字元：<code>' ( ) , - . / : ?</code>。這些「direct characters」被認為可以很安全的直接在文件裡呈現。另一個主要的群組稱作「optional direct characters」，其中包含了所有可被列印的字元，這些字元在U+0020～U+007E之間，除了<code>~ \ +</code>和空白字元以外。這些「optional direct characters」的使用雖可減少空間的使用也可增加人的可閱讀性，但卻會因為一些不良設計的郵件閘道而會產生一些錯誤，導致必須使用額外的跳脫字元。

空白字元、Tab字元、以及換行字元一般雖也可直接是為單一的ASCII字元來使用，然而，若是郵件中有使用了編碼過的字串，則必須特別注意這些字元有無被使用在其他地方。而加號字元<code>+</code>的一種編碼方式''可以''是<code>+-</code>。

其他的字元則必須被編碼成UTF-16然後轉換為[[Base64#UTF-7|修改的Base64]]。這些區塊的開頭會以<code>+</code>符號來標示，結尾則以任何不在Base64裡定義的字元來標示。若是在Base64區塊之後使用<code>-</code>([[連字暨減號]])標示為結束的話，則解碼器會從下個字元繼續解碼，反之則用此字元當非Base64的區塊的開頭繼續解碼。