UTF-7 (7-位元 Unicode 轉換格式（Unicode Transformation Format，簡寫成 UTF）) 是一種可變長度字元編碼方式，用以將 Unicode 字元以 ASCII 編碼的字元串來呈現，可以套用在電子郵件傳輸之類的套用。
有些可套用於電信電報領域的 UTF-6 和 UTF-5 提案已經被提出 ，然而，截至 2006 年止，這些提案尚未被正式的制定出來。這些提案與 Punycode 並無相關。
基本介紹
- 外文名：Unicode Transformation Format
- 簡寫：UTF
- 類別：一種可變長度字元編碼方式
- 屬於：基本的電子郵件傳輸標準之一
簡介,演算法,安全性,範例,
簡介
SMTP 為基本的電子郵件傳輸標準之一，其指明了傳輸格式為 US-ASCII ，並且不允許超過 ASCII 所定義的字元範圍以外的位元值，也就是說八位元的字串將無法正常的被傳輸。 MIME （RFC 2045 ~ 2049）擴展了網路郵件以支援不同的媒體類型以及字元集，包含 UTF-8 與 UTF-16 的字元集皆可被指定使用。但由於 MIME 並未明確將 Unicode 定義為可支援的字元集，並且也沒有說明其應如何編碼，這使得既有的 SMTP 傳輸架構下仍舊無法保證可正確的處理 8 位元資料。base64 編碼也有其問題，例如甚至連純英文的 US-ASCII 字元也可能會變成不可辨認；至於像是 UTF-8 與 quoted-printable 的編碼結合，則需要 6 ～ 9 個位元來為非 ASCII 的字元（Unicode 的 基本多文種平面中定義的字元）進行編碼，至於在基本多文種平面（BMP）以外的字原則需要多達 12 位元的長度才能完成編碼，這顯得相當沒有效率。
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 個數字與英文字母，以及包含了九個符號字元：' ( ) , - . / : ?。這些“direct characters”被認為可以很安全的直接在檔案里呈現。另一個主要的群組稱作“optional direct characters”，其中包含了所有可被列印的字元，這些字元在 U+0020 ～ U+007E 之間，除了~ \ +和空白字元以外。這些“optional direct characters”的使用雖可減少空間的使用也可增加人的可閱讀性，但卻會因為一些不良設計的郵件閘道而會產生一些錯誤，導致必須使用額外的跳脫字元。
空白字元、Tab字元、以及換行字元一般雖也可直接是為單一的 ASCII 字元來使用，然而，若是郵件中有使用了編碼過的字串，則必須特別注意這些字元有無被使用在其他地方。
其他的字元則必須被編碼成 UTF-16 然後轉換為修改的 Base64。這些區塊的開頭會以 + 符號來標示，結尾則以任何不在 Base64 里定義的字元來標示。
演算法
編碼
首先必須先決定哪些字元呈現為 ASCII 格式，哪些字元呈現在 Unicode 區塊。簡單的編碼器可以假設所有的字元皆可以很安全的被直接編碼。然而要將原本屬於 Unicode 區塊的字元視為 ASCII 來加以編碼的代價是需要額外的2⅔字元。
Unicode 序列一旦被認定後，其必須以下面的程式來加以編碼，並以適當的符號加以標註：
我們將使用 £† (0x00A3) (0x2020) 字元序列來作為以下的範例。
將字元的 Unicode 數值 (UTF-16) 以二進位呈現：
0x00A3 → 0000 0000 1010 0011
0x2020 → 0010 0000 0010 0000
將二進位序列合併
0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
重新將二進位序列編組，以六位數為一組，由左開始：
0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00
如果最後一組小於六位數，則不足的位數以 0 補足尾數：
0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000
將每一組六位數的數值以對應的 Base64 碼取代：
000000 001010 001100 100000 001000 000000 → AKMgIA
解碼
首先訊息必須被拆分到純文字與 Unicode 區塊，緊接著 Unicode 區塊必須以下面的程式來進行解譯（使用上面提到的範例）：
將每一個 Base64 碼以二進位序列來描述，如下：
AKMgIA → 000000 001010 001100 100000 001000 000000
重新將二進位編組，以使其 16 位數一組，從左開始：
000000 001010 001100 → 0000000010100011 0010000000100000 0000
若有其中一組無法完全編成 16 位數一組，則先排除它：
0000000010100011 0010000000100000
每一個 16 位元的一組二進位碼為 Unicode （UTF-16）的數字字元並且可以被改寫為如下：
0000 0000 1010 0011 ≡ 0x00A3 ≡ 16310
安全性
UTF-7 由於允許將相同來源的字串從 base64 的模式被平移，而顯得安全性薄弱。現今的郵件與傳輸方式由於都已支援 UTF-8，UTF-7 則已走入歷史而很少再被使用。即便如此，現今的套用軟體仍應更加考慮支持更安全的編碼方式。
然而，除了郵件傳輸之外，仍有不少傳輸是採用 UTF-7 編碼來進行傳輸。2006年，較著名的安全漏洞發生於 Google 的搜尋漏洞，該漏洞肇因於不當的使用 UTF-7 編碼於網址資訊上，遠端的攻擊將可讀取或修改網頁內容。
範例
"Hello, World!" 會被編碼為 "Hello, World!"
"1 + 1 = 2" 會被編碼為 "1 +- 1 = 2"
"£1" 會被編碼為 "+AKM-1". 第一個字元 £ （英鎊的符號）的 Unicode 碼為 U+00A3 (在 UTF-16 即為 00A3），接著轉換至修改的 Base64格式，如同下表。表中可見有兩個位元多了出來，被以 0 填補上。
16進位碼 0 0 A 3
2進位碼 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0
索引 0 10 12
Base64 編碼 A K M
